Why This Matters#

Cloud environments are the primary target for modern attacks. Misconfigurations — not sophisticated exploits — cause most cloud breaches. The shared responsibility model means YOU are responsible for securing your workloads, data, and configurations.

Shared Responsibility Model#

flowchart TD
    subgraph You["YOUR Responsibility"]
        Data["Data & Encryption"]
        IAM["IAM & Access Control"]
        App["Application Security"]
        OS["OS & Network Config"]
        FW["Firewall Rules"]
    end
    
    subgraph Provider["PROVIDER Responsibility"]
        Physical["Physical Security"]
        Network["Global Network"]
        Hypervisor["Hypervisor"]
        Hardware["Hardware"]
        Regions["Regions & AZs"]
    end

Responsibility by Service Type#

Key insight: Moving to managed services (PaaS/SaaS) shifts more responsibility to the provider — but data and access control are ALWAYS yours.

Cloud IAM#

AWS IAM Principles#

IAM Policy Evaluation#

flowchart TD
    Request["API Request"] --> Explicit["Explicit Deny?"]
    Explicit -->|Yes| Deny["DENY"]
    Explicit -->|No| SCP["SCP Allow?"]
    SCP -->|No| Deny
    SCP -->|Yes| Permission["Permission Boundary?"]
    Permission -->|No| Deny
    Permission -->|Yes| Policy["Identity Policy Allow?"]
    Policy -->|No| Resource["Resource Policy Allow?"]
    Policy -->|Yes| Allow["ALLOW"]
    Resource -->|No| Deny
    Resource -->|Yes| Allow

Common IAM Mistakes#

Common Cloud Misconfigurations#

Storage#

Compute#

Network#

Cloud Security Posture Management (CSPM)#

Automated, continuous scanning for misconfigurations:

AWS-Native Tools#

Third-Party CSPM#

Infrastructure as Code Security (Shift-Left)#

Catch misconfigurations BEFORE deployment:

Container and Kubernetes Security#

Container Image Security#

flowchart LR
    Build["Build Image"] --> Scan["Scan for CVEs"]
    Scan --> Sign["Sign Image"]
    Sign --> Registry["Push to Private Registry"]
    Registry --> Admit["Admission Control"]
    Admit --> Run["Deploy (if policy passes)"]

Kubernetes Security Layers#

Pod Security Standards#

Cloud Logging and Detection#

Essential Logs#

Detection Patterns#

Multi-Account Strategy#

Isolate environments and workloads in separate AWS accounts:

flowchart TD
    Org["AWS Organization (Management Account)"]
    Org --> Security["Security Account<br/>(GuardDuty, Security Hub)"]
    Org --> Log["Log Archive Account<br/>(CloudTrail, Config)"]
    Org --> Prod["Production Account"]
    Org --> Pre["Pre-Production Account"]
    Org --> Test["Test Account"]
    Org --> Shared["Shared Services<br/>(CI/CD, DNS, networking)"]

Benefits#

Key Takeaways#

1. Shared responsibility means YOUR data, YOUR IAM, YOUR config — always
2. Misconfigurations cause most cloud breaches — not sophisticated attacks
3. Shift left — scan IaC before deployment (Checkov, tfsec)
4. No long-lived credentials — use roles, OIDC federation, temporary tokens
5. Multi-account isolation — separate environments, separate blast radius
6. Enable everything — CloudTrail, GuardDuty, Config, flow logs (cost is minimal vs. breach cost)
7. IMDSv2 is mandatory — blocks the most common cloud SSRF attack