Key Takeaways: Cloud Security

A one-page reference. Reread this before an exam or before moving on. Dense by design.

The core vocabulary (memorize cold)

Term One-line definition
Shared responsibility model Provider secures of the cloud (hardware, hypervisor, facilities); customer secures in the cloud (config, data, identity)
IaaS Provider gives VMs/network/storage; you own OS upward (e.g., EC2, Azure VM, GCP Compute)
PaaS Provider also owns OS/runtime; you own code + config + access (e.g., Lambda, RDS, App Service)
SaaS Provider owns the whole app; you own how you use it — accounts, permissions, config (e.g., M365, Salesforce)
Cloud IAM The cloud platform's access plane: who (principal) may do what (action) to which resource, under what conditions
Cloud misconfiguration A resource left insecure via a customer-controlled setting; the #1 cause of cloud breaches
Security group A virtual, stateful firewall on cloud resources (Azure: NSG; GCP: VPC firewall rules)
CSPM Cloud security posture management — continuously scans configuration for misconfigs/compliance gaps
CWPP Cloud workload protection — secures running workloads (VMs, containers, functions) against vulns/runtime threats
CloudTrail AWS service logging every API call (who/what/when/where/result); Azure Activity+Entra logs; GCP Cloud Audit Logs
Container A lightweight, isolated unit packaging an app + dependencies (introduced here; image scanning in Ch. 31)
Serverless Run code without managing servers (e.g., Lambda); a PaaS pattern where you own only code + config + access

Shared responsibility — who secures what, by model

Layer On-Prem IaaS PaaS SaaS
Data + classification You You You You
Identity & access (IAM) You You You You
Application logic You You You Provider
Runtime / middleware You You Provider Provider
Operating system You You Provider Provider
Virtualization / host You Provider Provider Provider
Physical network + datacenter You Provider Provider Provider

Rule: your share shrinks moving up the stack, but data and identity are ALWAYS yours — which is why most cloud breaches live in those two layers. "Shared" duties (e.g., encryption at rest) are the trap: provider supplies the capability; you must turn it on.

The top cloud misconfigurations (find these on sight)

Misconfig What it looks like Exploit Prevent / detect
Public storage Bucket ACL grants AllUsers READ (or WRITE) Automated scanners enumerate + download via HTTP GET Block Public Access (guardrail); default private + encrypt; CSPM; alert on PutBucketAcl/PutBucketPolicy
Over-broad IAM "Action":"*" + "Resource":"*" on Allow Leaked credential = total account compromise Least privilege; access-analyzer right-sizing; deny * policies; require MFA; prefer roles over long-lived keys
Open security group 0.0.0.0/0 on 22 / 3389 / 3306 / 5432 Continuous brute-force of admin/DB ports Restrict source to app subnet / bastion; SCP denying 0.0.0.0/0 on sensitive ports; CSPM
Exposed metadata SSRF + un-hardened IMDS at 169.254.169.254 + wildcard role Read VM role credentials → act as that role IMDSv2; least-privilege instance role; fix SSRF (Ch. 13) — three independent controls
Long-lived access keys AKIA... keys in code/config Leak into a repo → durable account access Prefer roles + short-lived creds; rotate; secret scanning (Ch. 20)
Logging disabled / partial CloudTrail off or single-region Breach leaves no trace; attacker covers tracks Enable all-region, delete-proof (object-lock, separate account); SCP denying StopLogging/DeleteTrail

Cloud IAM — the least-privilege pattern

// LEAST PRIVILEGE: exactly what's needed, scoped resource, TLS required
{ "Version": "2012-10-17",
  "Statement": [{ "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:ListBucket"],
    "Resource": ["arn:aws:s3:::meridian-loan-docs", "arn:aws:s3:::meridian-loan-docs/*"],
    "Condition": { "Bool": { "aws:SecureTransport": "true" } } }] }
  • Design every policy assuming the credential will leak (assume breach → identity). Minimize blast radius.
  • Roles + short-lived credentials over long-lived AKIA... keys. Require MFA via policy conditions.
  • The wildcard policy ("Action":"*"/"Resource":"*") is the canonical anti-pattern — treat every wildcard as a finding.

CSPM vs. CWPP vs. guardrails — the control-plane hierarchy

Control What it does Type
Guardrail Makes the dangerous config impossible / auto-rejected (Block Public Access; SCPs; policy-as-code) Preventive
CSPM Continuously scans config; flags misconfigs/compliance gaps Detective
CWPP Protects the running workload (vuln scan, runtime threat detection, malware) Protective

Order: prevent with guardrails, detect with CSPM, protect workloads with CWPP — defense in depth on the control plane. Guardrail vs. gate: a guardrail auto-blocks only the unsafe action (engineers move fast); a gate halts a deployment for a human (bottleneck, gets bypassed). Guardrails scale in the cloud.

Cloud logging — the detections every SOC needs

Detection Key event(s) Why
Bucket became public PutBucketAcl, PutBucketPolicy #1 exposure vector
SG opened to 0.0.0.0/0 AuthorizeSecurityGroupIngress Internet exposure
* IAM policy created/attached PutUserPolicy, AttachUserPolicy, CreatePolicyVersion Privilege escalation
Logging disabled StopLogging, DeleteTrail Highest-value alert — attacker covering tracks
Root account used userIdentity.type = "Root" Root should be near-zero after setup
New access key for a user CreateAccessKey Possible persistence
Login from new region sign-in events + geolocation Possible credential compromise

Turn logging on in all regions, make it comprehensive, and protect it from deletion (separate locked-down account + object-lock). A log an attacker can erase is theater.

Decision aid — "which control when?"

If you want to… Use… Because…
Make a dangerous config impossible a guardrail (Block Public Access, SCP, policy-as-code) prevention scales; no human in the loop per change
Find misconfigs that already exist CSPM detective backstop for what guardrails miss or don't cover
Protect a running VM/container/function CWPP configuration security ≠ workload security
Know who did what in the account CloudTrail / Activity / Audit Logs (all regions, delete-proof) control-plane evidence; the basis of every investigation
Know who read the data in a bucket data-plane access logging (e.g., S3 access logs) CloudTrail does NOT record object reads; without this you assume the worst
Bound a leaked credential's damage least-privilege IAM + roles/short-lived creds the policy is often the only thing behind a leaked key
Stop a stolen password from acting MFA via policy condition turns a credential into a dead end
Give a VM credentials safely an attached IAM role (not a long-lived AKIA... key) no durable secret to leak

Shortcut reflex: see AllUsers on a bucket → public, fix + guardrail. See "Action":"*"/"Resource":"*" → admin-equivalent, right-size. See 0.0.0.0/0 on 22/3389/3306/5432 → internet-exposed admin/DB, restrict source. See StopLogging/DeleteTrail → page someone now.

Certification crosswalk

Concept CompTIA Security+ (ISC)² CISSP domain
Shared responsibility; IaaS/PaaS/SaaS 3.0 Security Architecture Security Architecture & Engineering
Cloud misconfiguration; public storage; SGs 2.0 Threats/Vulns; 3.0 Architecture Security Architecture; Security Operations
Cloud IAM; least privilege 4.0 Security Operations Identity & Access Management
CSPM / CWPP / guardrails 3.0 Architecture; 4.0 Operations Security Operations
Cloud logging (CloudTrail) & detection 4.0 Security Operations Security Operations

Project additions this chapter

  • Meridian program: cloud security baseline — Block Public Access (guardrail), all-region delete-proof CloudTrail, least-privilege IAM (no *, MFA, no long-lived keys), SCP denying 0.0.0.0/0 on sensitive ports, default encryption, CSPM against the CIS AWS Benchmark wired to the SOC.
  • bluekit toolkit: cloudpost.pys3_public(acl) (public-bucket check) and iam_overbroad(policy) (wildcard-policy check).

Common pitfalls

  • Assuming a secure provider means a secure deployment (it does not — your config is your job).
  • Misreading a shared duty (encryption at rest) as the provider's — leaving data unencrypted.
  • The "Action":"*" policy "to get it working," never tightened — total compromise if the credential leaks.
  • A 0.0.0.0/0 rule on an admin/DB port — a breach with a countdown timer.
  • Buying a CSPM tool and treating the 4,000-finding dashboard as "the work" (the unwatched-SIEM trap).
  • Running CloudTrail but never monitoring it — or running it where an attacker can delete it.
  • "A researcher found it, not an attacker" — backwards; it proves the exposure was trivially discoverable.