Cloud security posture
Most publicized cloud breaches aren't zero-days in AWS's hypervisor — they're a public storage bucket, an over-permissioned role, or a management port left open to the internet, all inside the part of the stack the customer was always responsible for. This page draws the line between what the provider secures and what you do, names the misconfiguration categories that account for the bulk of real incidents, and covers the two mechanisms — Cloud Security Posture Management and organization-wide guardrails — that keep that line from quietly drifting. By the end you should be able to explain, for your own cloud account, exactly what's detected versus what's structurally prevented.
Think of it like renting an apartment. The landlord is responsible for the building's foundation, the wiring behind the walls, the plumbing, and the lock on the main entrance — you never touch any of that, and you couldn't fix it if you wanted to. But once you're inside your own unit, it's on you to lock your own door, decide who gets a copy of the key, and not leave your valuables sitting in the hallway. A studio apartment with hotel-style service (SaaS) has staff handling almost everything except your own belongings and who you let in; a bare plot of serviced land (IaaS) leaves you responsible for building and maintaining nearly the whole structure yourself. Same landlord relationship, very different split of duties, depending on how much the landlord is already doing for you.
The shared responsibility model
Every public cloud provider draws the same line, and every real-world cloud breach lands on one side of it or the other. AWS, Microsoft, and Google each publish some version of the same document: the provider is responsible for security of the cloud — the physical data centers, the hardware, the hypervisor that isolates one tenant's virtual machine from the next, and the network fabric connecting it all — and the customer is responsible for security in the cloud: how they configure what they provision on top of that infrastructure, meaning their data, their identity and access management (IAM) policies, their application code, and, depending on the service model, their operating system and runtime.
Where that line sits isn't fixed — it moves depending on how much of the stack the provider manages for you. Rent a raw virtual machine (IaaS: EC2, Azure VMs, Compute Engine) and you inherit almost everything above the hypervisor: OS patching, runtime, middleware, application code, data, and IAM are all yours. Move up to a managed platform (PaaS: RDS, App Engine, Azure App Service) and the provider absorbs the OS and runtime, leaving you with application code, data, and access configuration. Move up again to SaaS (Salesforce, Microsoft 365, Workday) and the provider runs essentially the entire stack — you're left with exactly two things: your data, and who's allowed to touch it.
CSPM: continuous, automated posture checking
Gartner coined Cloud Security Posture Management (CSPM) in 2019 to describe a category of tooling that does one job continuously: connect to a cloud account or an entire organization through the provider's own APIs, read its live configuration, and check it against a known-good baseline — the CIS Benchmarks for AWS, Azure, and GCP, an internal policy set, or a compliance framework like PCI DSS or SOC 2. The distinguishing word is continuously. A quarterly configuration audit is a snapshot; cloud configuration drifts far faster than that — someone opens a security group for a debugging session and forgets to close it, a Terraform module ships without an encryption flag set, a bucket policy gets loosened during an incident and never gets tightened back.
CSPM tools — Wiz, Palo Alto Prisma Cloud, Orca Security, Microsoft Defender for Cloud, AWS Security Hub layered on Config rules, Google Security Command Center — re-scan on a cadence measured in hours, not quarters, and increasingly offer one-click or fully automated remediation for well-understood findings, like re-attaching a bucket policy that blocks public access. See the tooling landscape for how these products actually compare in scope and depth.
The misconfigurations that actually cause breaches
Ask any CSPM vendor which finding categories dominate their scan results across thousands of real accounts, and the same four keep coming back:
- Publicly exposed storage. An S3 bucket, Azure Blob container, or GCS bucket with a public-read or public-write ACL, usually set once for a legitimate reason — serving static assets, sharing a report — and never revisited.
- Over-permissive IAM. Roles and policies granting
"Action": "*"or"Resource": "*"far beyond what the attached workload needs, plus stale cross-account trust relationships nobody remembers creating. - Unencrypted data. Volumes, snapshots, and database instances created without a KMS-managed key, or load balancers accepting plaintext HTTP alongside — or instead of — TLS.
- Exposed management ports. Security groups with SSH (22), RDP (3389), or a database port (5432, 6379, 27017) open to
0.0.0.0/0instead of restricted to a bastion host or VPN CIDR.
These categories aren't independent — the worst breaches chain them. The 2019 Capital One breach started with a server-side request forgery (SSRF) vulnerability in a misconfigured web application firewall, which let the attacker query the EC2 instance metadata service and pull temporary credentials off an IAM role scoped far wider than the workload required. That one over-permissioned role turned a single SSRF bug into unauthorized access to over 100 million customer records across S3. Fixing the SSRF would have stopped that specific exploit; fixing the IAM role would have stopped that exploit and every other path to the same data. See incident response & forensics for how a team is expected to react once something like this turns up in production.
Least privilege as the starting posture
The principle of least privilege says an identity — a human, a service account, a CI/CD pipeline — gets exactly the permissions its job requires, granted that way from the start, not trimmed down later after an audit flags the excess. In practice that means building IAM policies from an explicit allow-list of actions and resources instead of starting from a broad managed policy and hoping nobody exercises what it also grants. AWS IAM Access Analyzer, Azure AD Privileged Identity Management (PIM), and GCP's IAM Recommender all exist because the retrofit almost never happens on its own: cloud security vendors that analyze real permission-usage logs consistently find that most granted permissions go unexercised, often in the single digits as a percentage of what's actually used within 90 days of being granted.
Least privilege also means time-boxing elevated access — just-in-time role assumption for a production incident instead of a standing admin credential sitting in someone's profile for months — and codifying the policy itself as reviewable text rather than a console click; see IaC security & policy as code for how that gets enforced before a change ever merges.
Turn on IAM Access Analyzer (or the equivalent in your cloud) and a CSPM scan on day one of a new account, not after twelve months of unreviewed grants have accumulated. The cost of reviewing a role at creation time is one design decision; the cost of reviewing it a year later is an archaeology project against logs nobody kept long enough.
Guardrails: making misconfiguration impossible, not just visible
CSPM answers "is something wrong right now," which is a detective control — the misconfiguration has to exist before a scan can flag it. Organization-wide guardrails answer a different question: can this category of misconfiguration exist at all? AWS Organizations enforces this with Service Control Policies (SCPs) — JSON policies attached at the account or organizational-unit level that set a hard ceiling on what any identity in that scope can do, no matter how permissive their own IAM policy is. An SCP that denies s3:PutBucketAcl calls setting public-read makes a public bucket structurally impossible to create in that account, not just something a scan will eventually catch. Azure Policy, applied with a Deny effect at the management-group level, and GCP's Organization Policy Service, with constraints like constraints/storage.publicAccessPrevention, play the same role in their respective platforms.
This is the same shift-left logic covered in the secure SDLC, applied at the account layer instead of the code layer: a preventive control that closes off a whole class of mistake is worth more than a detective control that catches individual instances of it after the fact. Mature programs run both — guardrails for what should never happen, CSPM for everything the guardrails don't yet cover — and compliance & governance covers how those org-level policies get mapped back to actual regulatory requirements.
1. In the shared responsibility model, which two things does the customer always retain responsibility for, regardless of IaaS, PaaS, or SaaS? 2. What does CSPM actually check, and how is that different from an annual compliance audit? 3. Name two of the most common cloud misconfiguration categories, and the real incident that chained them. 4. What's the practical difference between a detective control like a CSPM alert and a preventive guardrail like an SCP?
Check your answers
- Data and IAM/access configuration — the customer decides who can access what and secures the data itself, in every service model, even SaaS.
- CSPM continuously and automatically scans an account or organization's live configuration against a baseline like the CIS Benchmarks and flags drift as it happens, hours apart, rather than checking once a year like a compliance audit.
- Publicly exposed storage and over-permissive IAM are two; the 2019 Capital One breach chained an SSRF against the instance metadata service with an over-permissioned IAM role to exfiltrate over 100 million customer records.
- A detective control finds a misconfiguration after it exists and tells someone to fix it. A preventive guardrail blocks the underlying API call so that category of misconfiguration can never be created in the first place.