Table of Contents
- Nobody Broke the Cloud
- The Shared Responsibility Gap
- Where Misconfigurations Concentrate
- Why IAM Is the Hard Part
- The Metadata Service Problem
- Detecting Drift From Intent
- Controls That Prevent Rather Than Report
- Common Pitfalls
- Conclusion
- Frequently Asked Questions
Key takeaway: Cloud providers secure the infrastructure competently. Nearly all incidents originate in customer configuration — excessive permissions, public storage, unrotated credentials, and network rules that were temporary two years ago.
Nobody Broke the Cloud
Read the technical detail of publicly analysed cloud breaches and a pattern emerges immediately: the provider’s security held. What failed was configuration.
A storage bucket set to public. An identity role permitting far more than it needed. An access key committed to a repository and never rotated. A security group opened to the internet for troubleshooting and left open. A management interface exposed without authentication.
None of these require attacker sophistication. Several require nothing more than a scan for open buckets, which is automated and continuous across the entire public address space.
This is not a criticism of cloud adoption — the providers’ infrastructure security genuinely exceeds what most organisations achieve on their own hardware. The issue is that cloud platforms are configuration-driven systems with enormous option surfaces, and the defaults are chosen for functionality rather than restriction.
The practical consequence is that cloud security is primarily a configuration management problem. That framing is more useful than treating it as a threat problem, because configuration is inspectable, testable, and enforceable in ways that attacker behaviour is not.
The Shared Responsibility Gap
Every provider publishes a shared responsibility model. Most teams have seen the diagram and few have worked through its implications.
The provider secures the physical facilities, the hypervisor, the host operating system, and the managed service infrastructure. You secure everything you configure: identity and access, network rules, data classification and encryption choices, operating systems on instances you run, application code, and the configuration of every managed service you consume.
Where teams get caught is the boundary within managed services. A managed database is patched by the provider — and its network exposure, authentication requirements, encryption settings, and backup retention are yours. The service being managed does not mean the service being secured.
A useful exercise is to enumerate every service in use and write down, explicitly, which security properties you control for each. The gaps this reveals are usually the actual risk, and they are usually surprising. Managed services multiply the number of small configuration decisions, and small decisions made inattentively across dozens of services is how the exposure accumulates.
Where Misconfigurations Concentrate
Consistently, a handful of categories account for most exposure:
Public storage. Buckets and containers readable by anyone. Providers have improved defaults substantially, and explicit permissions, bucket policies, and access control lists still permit it. Compounding this, storage granted to a broad principal is functionally public even when not marked so.
Excessive identity permissions. Wildcard actions, wildcard resources, or administrative policies attached because narrowing them was tedious. This is the most consequential category because it converts any single compromise into a broad one.
Long-lived static credentials. Access keys embedded in code, configuration, container images, or CI variables. Keys that never expire and are never rotated remain valid indefinitely after leaking.
Permissive network rules. Ingress from the entire internet on administrative ports. Frequently created for a legitimate temporary reason and never removed.
Unencrypted data with accessible keys. Encryption enabled while the key is usable by every role in the account provides limited protection.
Disabled or unmonitored logging. Audit logging off, or on and never queried. This determines whether you can reconstruct an incident at all.
Public snapshots and images. Disk snapshots and machine images shared publicly, sometimes containing credentials and data.
Notice that most of these are single settings. That is what makes automated detection effective and manual review unreliable — the surface is too large for human attention and perfectly suited to machine checking.
Why IAM Is the Hard Part
Identity and access management is where cloud security is genuinely difficult, and understanding why prevents unrealistic expectations.
The permission surface is enormous. Major providers expose thousands of distinct actions across hundreds of services. Constructing a minimal policy requires knowing exactly which actions an application performs, which is frequently undocumented and discovered only through failure.
Failure is asymmetric. Too few permissions produces an immediate, visible error attributed to whoever tightened the policy. Too many produces nothing observable. The incentive gradient points toward over-permissioning, consistently.
Permissions compose in non-obvious ways. Identity policies, resource policies, permission boundaries, service control policies, and session policies interact. Determining effective permissions for a principal is genuinely hard, and intuition is unreliable.
Privilege escalation paths hide in combinations. A role that cannot do something directly may be able to modify a policy, assume another role, or launch a compute instance with a more privileged role attached. Individually innocuous permissions can chain into administrative access, and this is not visible from reading any single policy.
Practices that help:
Start from nothing and add on failure, rather than starting broad and narrowing later — narrowing later never happens. Use the provider’s access analysis tooling to identify permissions granted but never exercised, which is usually most of them. Prefer short-lived role assumption over static keys everywhere it is possible. Apply permission boundaries so that even a compromised role cannot exceed a ceiling. And review the escalation paths specifically, because they are not apparent from policy documents.
The Metadata Service Problem
A cloud-specific attack pattern worth understanding in detail, because it converts a common web vulnerability into credential theft.
Compute instances retrieve their credentials from a metadata endpoint at a link-local address. Any process on the instance can request them, and no authentication is required by design.
The attack is server-side request forgery. An application that fetches a URL supplied by a user can be directed at the metadata endpoint. The response contains temporary credentials for the instance’s role, which the attacker then uses from anywhere.
This is why a seemingly minor input validation flaw in a web application becomes a cloud account compromise. The severity of server-side request forgery in cloud environments is substantially higher than the same bug on traditional hosting.
Mitigations, layered: use the session-based metadata protocol version that requires a PUT request to obtain a token, which defeats simple forgery; set the metadata hop limit to prevent responses reaching containers; attach minimal permissions to instance roles so that stolen credentials are worth little; and validate outbound URLs in application code with an allowlist rather than a blocklist.
The first of those is a configuration setting and should be enforced organisation-wide. It is one of the higher-value single settings available in cloud configuration.
Detecting Drift From Intent
Configuration decays. A correctly configured environment becomes incorrect through emergency changes, experiments, and accumulated exceptions.
Infrastructure as code with drift detection. Declaring the intended state makes divergence detectable. Without a declared intent, there is nothing to compare against, and “correct” becomes a matter of opinion.
Continuous posture assessment. Automated checks against a baseline, running continuously rather than at audit time. Both providers and third parties offer this.
Alert on the changes that matter. Not every configuration change deserves attention. Storage becoming public, an administrative policy being attached, logging being disabled, and a security group opening to the internet all do.
Public access analysis. Provider tooling that reports which resources are reachable externally, including through the indirect paths that manual review misses.
Credential age reporting. Simply listing access keys by age surfaces the long-lived credentials that accumulate unnoticed.
The detection-to-action gap matters more than detection coverage. Most organisations running posture assessment have hundreds of findings and remediate few of them. A smaller set of critical checks with an enforced response is more effective than comprehensive reporting into a backlog.
Controls That Prevent Rather Than Report
Preventive controls beat detective controls, because they eliminate the window between mistake and remediation.
| Control | Prevents | Effort |
|---|---|---|
| Organisation-wide policy blocking public storage | The most common breach cause | Low |
| Deny-list guardrails at the organisation level | Region use, service use, disabling logs | Low |
| Enforced metadata session requirement | SSRF-based credential theft | Low |
| Mandatory encryption at rest | Snapshot and storage exposure | Low |
| No static keys; role assumption only | Credential leakage value | Moderate |
| Permission boundaries on all roles | Privilege escalation ceiling | Moderate |
| Policy-as-code in the deployment pipeline | Misconfiguration reaching production | Moderate |
| Separate accounts per environment | Blast radius | Moderate |
The first four are configuration changes achievable in an afternoon that eliminate entire categories of incident. They are the highest-return security work available in most cloud environments and they are frequently skipped in favour of tooling purchases.
Account separation deserves emphasis as an architectural control. Separate accounts for production, staging, and development create a hard boundary that no permission mistake crosses. It is more effective than any within-account permission scheme, because the isolation is structural rather than policy-based.
Common Pitfalls
Assuming managed services are secured for you. The provider patches them; you configure their exposure, authentication, and encryption.
Starting with broad permissions to narrow later. Narrowing later does not happen. Start minimal.
Static credentials anywhere. Role assumption and workload identity federation remove the leakage risk entirely.
Posture findings without remediation. Hundreds of unaddressed findings provide no protection.
Ignoring privilege escalation paths. Individually safe permissions chain into administrative access.
One account for everything. No boundary means any mistake is a total exposure.
Logging disabled or unqueried. Determines whether an incident can be investigated at all.
Conclusion
Cloud breaches are configuration failures. The provider’s infrastructure holds; the customer’s permissions, network rules, and storage settings are where incidents originate.
That framing points to specific, achievable work. Enforce organisation-level guardrails that make public storage and disabled logging impossible rather than merely discouraged. Eliminate static credentials in favour of short-lived role assumption. Require the session-based metadata protocol to defeat request forgery. Separate environments into distinct accounts so no permission error crosses the boundary. Declare infrastructure as code so drift is detectable.
Then focus detection on the small number of changes that genuinely indicate danger, with an actual response process. Comprehensive findings nobody addresses are documentation of your exposure rather than protection from it.
Frequently Asked Questions
Is cloud less secure than on-premises infrastructure? Generally more secure at the infrastructure layer, since provider security engineering exceeds what most organisations achieve independently. The configuration surface is larger and changes faster, which shifts where the risk lives rather than removing it.
What is the single highest-value cloud security control? Organisation-level guardrails preventing public storage and enforcing audit logging. These eliminate the most common breach cause and preserve investigation capability, both through configuration rather than tooling.
How can excessive permissions be reduced safely? Use access analysis tooling to identify permissions granted but never used over a meaningful period, remove those first, and monitor for failures. This is empirical rather than theoretical and considerably safer than guessing.
Are static access keys ever acceptable? Rarely, and only where role assumption is genuinely unavailable. Where required, scope them minimally, rotate them on a schedule, and monitor their use. Modern federation options cover nearly all previous use cases.
Why is server-side request forgery so severe in cloud environments? Because the metadata endpoint returns credentials to any local request. A forgery vulnerability becomes credential theft, which becomes account access. The same bug on traditional hosting is far less consequential.
How many accounts should an organisation use? At minimum, separate accounts per environment. Larger organisations typically separate per team or workload as well. The boundary is the strongest isolation available and it is cheap to create.
Do compliance frameworks make an environment secure? They establish a floor and are not equivalent to security. Compliant environments are breached regularly, usually through configuration issues the framework did not enumerate specifically.
