Security Architecture#

Cloud security is fundamentally different from on-premises security. There’s no physical perimeter to defend. Instead, identity becomes the perimeter, encryption becomes the default, and automation replaces manual audit. This section covers the architectural patterns for securing cloud environments without slowing down delivery.

Zero-Trust in the Cloud#

Zero-trust is not a product — it’s an architecture principle: never trust, always verify. Every request is authenticated and authorised, regardless of its origin.

Traditional vs Zero-Trust#

Traditional (Perimeter-Based)             Zero-Trust (Identity-Based)
┌────────────────────────────┐           ┌────────────────────────────┐
│         TRUSTED ZONE       │           │  Every request verified:   │
│                            │           │                            │
│  ┌────┐  ┌────┐  ┌────┐  │           │  ┌────┐  ┌────┐  ┌────┐  │
│  │Svc │──│Svc │──│Svc │  │           │  │Svc │─?│Svc │─?│Svc │  │
│  │ A  │  │ B  │  │ C  │  │           │  │ A  │  │ B  │  │ C  │  │
│  └────┘  └────┘  └────┘  │           │  └────┘  └────┘  └────┘  │
│                            │           │  ? = authn + authz + mTLS │
│  "Inside = trusted"       │           │  "Nothing is trusted"     │
│  (one breach = full access)│           │  (breach is contained)    │
└────────────────────────────┘           └────────────────────────────┘

Zero-Trust Principles#

Identity-Based Perimeter#

In the cloud, the network is no longer the security boundary — identity is. Every request carries an identity, and every resource has a policy.

Identity Architecture#

┌─────────────────────────────────────────────────────────────────┐
│                      Identity Provider (IdP)                     │
│                   (Okta, Entra ID, Google Workspace)             │
└──────────┬──────────────────────────────┬───────────────────────┘
           │ OIDC / SAML                  │ Workload Identity
           ▼                              ▼
┌──────────────────────┐       ┌──────────────────────────────┐
│  Human Access         │       │  Machine/Service Access       │
│                      │       │                              │
│  SSO → Assume Role   │       │  IRSA / Workload Identity    │
│  MFA enforced        │       │  Federation                  │
│  Session: 1 hour     │       │  No long-lived keys          │
│  Audited             │       │  Short-lived tokens           │
└──────────────────────┘       └──────────────────────────────┘

Service-to-Service Authentication#

The IAM Decision Hierarchy#

Can you use the cloud provider's identity? (IRSA, workload identity)
├── Yes → Use it. No keys, automatic rotation, audit trail built in.
└── No
    ├── Can you use mTLS? (service mesh, internal services)
    │   └── Yes → Use it. Identity tied to certificate.
    └── No
        ├── Can you use OAuth 2.0 with short-lived tokens?
        │   └── Yes → Use it. Machine-to-machine flow.
        └── Last resort → API key, but:
            ├── Rotate frequently (90 days max)
            ├── Store in secrets manager
            └── Never embed in code or config files

Encryption Patterns#

Encryption at Rest#

Encryption in Transit#

Encryption in Use (Confidential Computing)#

Emerging pattern where data is encrypted even while being processed:

Secrets Management#

Secrets (API keys, database passwords, certificates) must never be in code, config files, or environment variables baked into images.

Secrets Architecture#

┌──────────────────────────────────────────────┐
│               Secrets Manager                  │
│         (Vault, AWS SM, GCP SM, AKV)          │
│                                                │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐   │
│  │ DB pass  │  │ API keys │  │ TLS certs│   │
│  │ (auto-   │  │ (rotated │  │ (auto-   │   │
│  │  rotated)│  │  90 days)│  │  renewed)│   │
│  └──────────┘  └──────────┘  └──────────┘   │
└───────────────────────┬──────────────────────┘
                        │ IAM-authenticated request
                        ▼
            ┌──────────────────────┐
            │  Application         │
            │  (fetches at startup │
            │   or via sidecar)    │
            └──────────────────────┘

Secrets Management Rules#

Compliance Automation#

Manual compliance audits are slow, expensive, and point-in-time. Cloud-native compliance is continuous, automated, and evidence-generating.

Compliance as Code Architecture#

┌─────────────────────────────────────────────────────────────┐
│                   Compliance Pipeline                         │
│                                                               │
│  ┌──────────────┐   ┌────────────────┐   ┌──────────────┐  │
│  │ Policy as     │──►│ Continuous     │──►│ Evidence     │  │
│  │ Code          │   │ Evaluation     │   │ Collection   │  │
│  │               │   │                │   │              │  │
│  │ (OPA, Config  │   │ (Config Rules, │   │ (Automated   │  │
│  │  Rules, Azure │   │  Security Hub, │   │  reports,    │  │
│  │  Policy)      │   │  SCC)          │   │  dashboards) │  │
│  └──────────────┘   └────────────────┘   └──────────────┘  │
│                                                               │
│  Detect → Alert → Auto-remediate (or block)                  │
└─────────────────────────────────────────────────────────────┘

Common Compliance Controls#

Security as Code#

Security controls should be version-controlled, peer-reviewed, tested, and deployed through the same pipeline as application code.

What Gets Codified#

Security in the CI/CD Pipeline#

Code Push
    │
    ▼
┌──────────────┐
│ Static Analysis │  ← SAST (SonarQube, Semgrep)
│ Secret Scanning │  ← gitleaks, truffleHog
└──────┬───────┘
       │
       ▼
┌──────────────┐
│ Dependency    │  ← SCA (Snyk, Dependabot, Trivy)
│ Scanning      │     CVE database check
└──────┬───────┘
       │
       ▼
┌──────────────┐
│ Container     │  ← Image scanning (Trivy, ECR scan)
│ Scanning      │     Base image CVEs, misconfigurations
└──────┬───────┘
       │
       ▼
┌──────────────┐
│ IaC Scanning  │  ← tfsec, checkov, cfn-nag
│               │     Misconfigured resources
└──────┬───────┘
       │
       ▼
┌──────────────┐
│ Deploy        │  ← Only if all gates pass
└──────────────┘

Cloud-Native SIEM#

Traditional SIEMs are on-premises appliances designed for network logs. Cloud-native SIEM aggregates and correlates cloud-specific signals.

Signal Sources#

Detection Architecture#

Signal Sources                  Analysis                     Response
┌───────────────┐              ┌──────────────┐            ┌──────────────┐
│ CloudTrail    │─┐            │              │            │ Alert →      │
│ VPC Flow Logs │─┤            │ Correlation  │            │ Slack/Pager  │
│ DNS Logs      │─┼───────────►│ Engine       │───────────►│              │
│ GuardDuty     │─┤            │ (SIEM /      │            │ Auto-        │
│ App Logs      │─┘            │  Security    │            │ Remediate    │
│               │              │  Lake)       │            │ (Lambda /    │
└───────────────┘              └──────────────┘            │  Step Fn)    │
                                                            └──────────────┘

Key Takeaways#

• Zero-trust treats every request as untrusted regardless of network origin — identity is the new perimeter
• Prefer cloud-native workload identity (IRSA, workload identity federation) over long-lived API keys
• Encrypt at rest by default (provider-managed keys); use customer-managed keys when regulation demands it
• Centralise secrets in a secrets manager with automatic rotation — never in code, CI variables, or config files
• Automate compliance with policy-as-code (OPA, Config Rules, Azure Policy) and integrate security scanning into CI/CD
• Cloud-native SIEM correlates audit logs, flow logs, DNS logs, and identity events to detect threats automatically
• Security controls are code: version-controlled, peer-reviewed, tested, and deployed through pipelines