Cloud security is one of those topics where the threat landscape diverges sharply from popular intuition. There is a great deal of attention paid to "cloud zero-days" and to platform-level cryptographic flaws. The actual cause of nearly every public cloud-related breach is misconfiguration: a setting toggled wrong, a policy too broad, an exposed asset nobody remembered. The Cloud Security Alliance’s "Top Threats to Cloud Computing 2024" report at cloudsecurityalliance.org/research/top-threats lists misconfiguration in the top three for the eighth consecutive year. CISA’s cloud advisories repeat the pattern.
Pulling apart what those misconfigurations actually are helps explain why platform security alone does not solve cloud security.
1. Public storage buckets
The original cloud breach archetype, still common in 2026. An S3 bucket, Azure Blob container, or GCS bucket configured with public-read access, often during a quick test, often forgotten. Bulk-discovery tools (GrayhatWarfare, Trufflehog) scan continuously for exposed buckets and surface their contents.
Notable incidents include the 2017 Verizon partner exposure (six million customer records), the 2019 Capital One breach (different mechanism but same root: an over-permissive IAM role on an S3 bucket), and a steady drumbeat of smaller cases. AWS’s defaults have improved, block-public-access is on for new buckets, but legacy buckets remain. The fix is mechanical: enable account-level block-public-access; audit every bucket against an explicit access list; alert on bucket policy changes.
2. Over-broad IAM roles
The single most consequential cloud misconfiguration. An EC2 instance, Lambda function, or Kubernetes pod is given an IAM role with permissions far in excess of what it needs, frequently *:* or admin-equivalent, because that was easier than scoping properly. When that workload is compromised (often by application-layer vulnerability, not platform flaw), the attacker inherits cloud-API privileges to read every secret, list every resource, and pivot.
The 2019 Capital One incident was a case study: an SSRF in a web application allowed the attacker to query the EC2 instance metadata service, retrieve the instance’s IAM credentials, and use them to enumerate and exfiltrate over a hundred million records. The IAM role had s3:List* across many buckets when it needed access to one.
The defensive practice is least-privilege IAM with explicit deny boundaries, and IMDSv2 (which requires a session token and blocks SSRF retrieval). AWS’s "Permissions Reference" and Azure’s "Built-in Roles" documentation give the policy primitives; the discipline is in actually using them.
3. Public-facing management APIs
Kubernetes API servers, Docker daemons, Elasticsearch and MongoDB instances, Jenkins, Redis, Memcached. All have a documented history of being deployed with no authentication and exposed to the internet, particularly in the early days of "cloud-native" tooling.
Shodan publishes a weekly count of exposed Elasticsearch instances; the number remains in the high tens of thousands as of 2026. The Volkswagen / VWAG data exposure of 2024 traced to an unauthenticated Elasticsearch in their North American cloud environment.
The mitigation is straightforward: management interfaces are not on the public internet, ever. They sit behind a bastion host, a ZTNA proxy, or a VPN, and they require authentication.
4. Hardcoded secrets in source and infrastructure
Secrets, API keys, database passwords, signing keys, committed to GitHub repositories, embedded in Lambda environment variables, baked into container images, exposed via misconfigured CI/CD pipelines. GitHub’s secret-scanning service publishes detection counts in the millions per year; researchers like Trufflehog and GitGuardian publish similar telemetry.
The 2024 Toyota subsidiary leak traced to a long-lived AWS access key in a public GitHub repository. The 2023 Microsoft AI research leak (38TB of internal data) traced to a misconfigured SAS token in a public GitHub repo.
Fix list: secret scanning enabled on every repo (free in GitHub, GitLab, Bitbucket); secrets stored in proper vaults (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault) and rotated; CI/CD pipelines that fetch secrets at runtime rather than embedding them.
5. Open security groups and overly permissive NSGs
The cloud equivalent of a flat-network LAN. A security group that allows 0.0.0.0/0 to port 22, 3389, or 1433. Inbound RDP exposure is the bread-and-butter of ransomware initial access; AWS’s own Trusted Advisor reports continue to flag tens of thousands of accounts with public RDP exposure.
Compounding factor: cloud security groups are easy to create and easy to forget. The "any/any allow temporary for testing" rule that survives the project. Tools like Steampipe and Prowler can audit security groups against compliance baselines.
6. Logging and monitoring not enabled
The breach happens; the logs that would have revealed it are not on. CloudTrail not enabled. Azure Activity Log retention set to default. Kubernetes audit logging disabled. The forensic value of cloud logs is enormous, and it depends on the logs existing in the first place.
CIS benchmarks for AWS, Azure, and GCP have explicit baseline requirements for logging coverage. Most cloud-security posture management tools (Prisma Cloud, Wiz, Lacework, Orca, the open-source Cloud Custodian) check these continuously.
7. Disabled or unused encryption
Storage encryption disabled on databases, S3 buckets, EBS volumes; unencrypted RDS snapshots; SSL/TLS termination at the load balancer with cleartext to the origin. Cloud platforms make encryption easy and often default-on, but exceptions accumulate. CIS Cloud Benchmarks and the cloud providers’ Well-Architected Framework reviews explicitly check for these gaps.
8. Unmanaged shadow IT
The marketing team’s WordPress on a colleague’s personal AWS account. The data-science team’s Snowflake instance with public network policy. The developer’s Heroku app holding production data. Shadow IT in cloud is structurally easy to create and structurally hard to detect, because it does not appear in central inventory.
The credible response is a corporate cloud broker model: no production data on personal cloud accounts; centralised access via SSO; cloud-account discovery tooling; and a permissive but supervised path for legitimate experimentation.
What good cloud posture management looks like
Mature cloud security in 2026 is built on three layers:
CSPM (Cloud Security Posture Management) tools that continuously evaluate configuration against benchmarks. Wiz, Orca, Prisma Cloud, Lacework, AWS Security Hub, Azure Defender for Cloud, GCP Security Command Center all do this; the open-source equivalents (Prowler, ScoutSuite) cover the basics.
Identity-centric monitoring. Modern CIEM (Cloud Infrastructure Entitlement Management) tools track who can do what and surface excessive privilege. Identity is the cloud’s perimeter; auditing it continuously is the highest-leverage detection investment.
Workload-level telemetry. Runtime EDR or eBPF-based tools (Falco, Sysdig, Datadog Workload Security, AWS GuardDuty) catch the things that misconfiguration analysis cannot, actual exploitation behaviour inside the workload.
The headline lesson, after a decade of cloud incidents: the platforms are largely secure, the configurations largely are not, and the operational discipline of running them right is the actual security model. The cloud providers’ shared-responsibility documentation says exactly this. Reading it carefully and acting on it remains the cheapest and most effective cloud-security investment any organisation can make.