Security Architecture Example

Example: SkyLink Security Architecture¶

This section presents a hypothetical security architecture for the SkyLink Connected Aircraft Platform, comprising a set of data flow diagrams and associated security controls.

Document Information¶

Overview¶

Purpose¶

This document describes the security architecture of the SkyLink platform using Data Flow Diagrams (DFD) to illustrate:

• How data moves through the system

• Where trust boundaries exist

• What security controls are applied at each boundary

• How data is classified and protected

Scope¶

This architecture covers:

• API Gateway (authentication, routing, rate limiting)

• Telemetry Service (aircraft data ingestion)

• Weather Service (external API integration)

• Contacts Service (Google OAuth integration)

• PostgreSQL Database (persistent storage)

• External integrations (WeatherAPI, Google People API)

Audience¶

• Security Engineers (threat modeling, penetration testing)

• Developers (secure implementation guidance)

• Auditors (compliance verification)

• Operations (deployment and monitoring)

System Context (Level 0)¶

Context Diagram¶

External Actors¶

Trust Boundaries¶

Boundary Definitions¶

Security Controls per Boundary¶

TB1: Internet → Gateway (CRITICAL)¶

TRUST BOUNDARY: Internet → API Gateway

AUTHENTICATION FLOW:

1. TLS handshake (mutual authentication)

2. Client certificate validation (CA-signed)

3. CN extraction from certificate

4. JWT token issuance (sub = CN)

5. Cross-validation on subsequent requests (CN == sub)

TB2: Gateway → Services (MEDIUM)¶

TRUST BOUNDARY 2 : Gateway → Internal Services

ASSUMPTION:

• Gateway has validated all requests

CONTROLS:

• Docker bridge network isolation

• Services not exposed to Internet

• Internal DNS resolution only

• Request forwarding via httpx (async)

DATA FLOW:

• Gateway ──[HTTP/JSON]──► Telemetry/Weather/Contacts

NOTE:

• No authentication between internal services(trusted internal network model)

TB3: Services → External APIs (HIGH)¶

TB4: Services → Database (HIGH)¶

Data Flow Diagrams (Level 1)¶

Flow 1: Aircraft Authentication¶

Security Controls Applied:

• mTLS handshake (mutual authentication)

• Certificate validation (CA-signed, not expired)

• CN extraction and binding

• JWT RS256 signing (2048-bit RSA)

• Short token expiry (15 minutes)

Flow 2: Telemetry Ingestion¶

HTTP Response Codes:

Flow 3: Weather Query¶

Data Protection:

• GPS coordinates passed as query parameters (not logged)

• API key never exposed to clients

• Demo mode prevents external API calls during testing

Flow 4: Contacts OAuth¶

OAuth Security:

• Minimal scope: contacts.readonly

• State parameter for CSRF protection

• Tokens encrypted before storage (AES-256-GCM)

• Tokens never logged

Security Controls by Layer¶

Control Matrix¶

Defense in Depth Visualization¶

Data Classification¶

Classification Matrix¶

Data Handling Rules¶

Attack Surface Analysis¶

Attack Surface Map¶

Exposed Endpoints¶

Cryptographic Inventory¶

Algorithms and Key Sizes¶

Key Management¶

Network Security¶

Network Topology¶

Network Policies¶

Kubernetes Network Policies¶

For production Kubernetes deployments, network policies enforce zero-trust networking:

# Default: deny all traffic
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: skylink-default-deny
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Kubernetes Network Policy Matrix:

Security Headers¶

X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Cache-Control: no-store, no-cache, must-revalidate, max-age=0
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
Referrer-Policy: no-referrer
Permissions-Policy: geolocation=(), microphone=(), camera=()

JWT Claims¶

{
  "sub": "aircraft_id (from mTLS CN)",
  "aud": "skylink",
  "iat": 1734600000,
  "exp": 1734600900,
  "role": "aircraft_standard"
}

RBAC Roles¶

Rate Limits¶