The 10 Cloud Security Mistakes Behind Most Breaches
Cloud security incidents have a depressingly consistent shape. Year after year, the public post-mortems describe the same handful of root causes: a misconfigured bucket, a stolen access key, an over-privileged role, a forgotten admin user. The good news is that most of them are fixable in days, not quarters.
Here are the ten mistakes that show up most often, and what good looks like in each case.
1. Long-lived access keys in code or env files
The classic. A developer needs to call an AWS API from a script, generates an access key, drops it in .env, accidentally commits it. GitHub crawlers pick it up within 60 seconds. Crypto-mining starts within 5 minutes.
Good looks like: no long-lived keys for humans or workloads. Humans use federated identity (SSO + IAM Identity Center, Workload Identity Federation, Azure AD). Workloads use IAM roles, managed identities, or workload identity. The rare cases where a long-lived key is unavoidable, the secret lives in a secret manager and rotates automatically.
2. Wildcard IAM policies
“It works” is a powerful force. The path of least resistance is "Action": "*", "Resource": "*" — and now your CI runner has god mode. When the CI runner gets compromised (and it will, eventually), so does your entire account.
Good looks like: least-privilege policies, generated from observed usage where possible (Access Analyzer, Policy Generator). Periodic policy review. No wildcards for production roles. Human admin access via JIT elevation, not standing privilege.
3. Public storage buckets and databases
S3 buckets, Azure Blob containers, Cloud Storage buckets — accidentally set to public. Or worse, a database open to 0.0.0.0/0 with default credentials.
Good looks like: default-deny network policies. Block-public-access enabled at the account level. Public exposure flagged loudly by your CSPM. Databases never directly internet-exposed; access via VPN, ZTNA, or bastion.
4. No control-plane logging
CloudTrail, Activity Log, Audit Logs — these record every API call against your cloud account. They are forensic gold during an incident. Many organisations have them enabled in their primary account but forgot about the dozens of other accounts and subscriptions.
Good looks like: control-plane logging enabled for every account/subscription, centralised to a separate logging account that the production team can’t modify. Retention long enough for incident investigation (12+ months for serious organisations).
5. The “DevOps god account”
One human account or one service principal that has full access to everything because untangling the permissions would be hard. Maybe it’s the IAM user who set up the account in 2018 and was never offboarded. Maybe it’s the Terraform service principal that runs the pipeline.
Good looks like: no permanent god accounts. Break-glass accounts are sealed in a vault and monitored. Service principals follow least privilege and are scoped to the resources they manage. Human admins use JIT to elevate for specific tasks, time-bound.
6. Click-ops infrastructure
Resources created in the console, never captured in IaC. Drift accumulates. The next admin doesn’t know why the security group has that one weird rule. The audit trail of who-changed-what is muddled.
Good looks like: 90%+ of infrastructure managed via IaC (Terraform, CloudFormation, Bicep, Pulumi). Drift detection runs continuously. PR-reviewed changes. Console access for emergencies, with the change captured back into IaC after the fact.
7. Misconfigured CSPM (or no CSPM)
A cloud security posture management tool tells you which of the 1,000+ controls in your environment are misconfigured against best practice. Many organisations buy a CSPM, look at it once, get overwhelmed, and never act on it. Worse: turn it on but ignore the alerts.
Good looks like: CSPM scoring tracked as a metric. Critical findings auto-remediated where safe (auto-disabling public access, auto-enabling encryption). Non-auto-remediable findings ticketed with SLAs. Posture score reviewed monthly with platform engineering.
8. Secrets in environment variables and config files
Slightly better than secrets in code, still bad. Environment variables leak via process listings, error messages, log streams. Config files often end up checked into version control accidentally.
Good looks like: dedicated secret manager (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, HashiCorp Vault). Access via SDK, with access logged. Rotation automated. No secrets in env files, period.
9. No cloud-specific incident response
Generic IR plans don’t translate well to cloud. The container has 30-second lifetime — your forensic snapshot needs to happen automatically. The CloudTrail record matters more than the disk image. The first responder needs to disable an IAM user, not pull the network cable.
Good looks like: cloud-specific IR runbooks for the top 5 scenarios (credential exposure, suspicious API activity, public exposure, supply chain compromise, ransomware-in-cloud). Tabletop those scenarios. Automation for evidence collection (snapshot, log export, IAM session revocation).
10. The metadata service still being exploitable
The instance metadata service is the gateway to credentials in many cloud environments. SSRF + metadata = stolen role credentials. AWS introduced IMDSv2 in 2019; many environments still have IMDSv1 enabled out of inertia.
Good looks like: IMDSv2-only at the account level, no exceptions. Equivalent hardening for Azure (instance metadata service header requirement) and GCP. SSRF defences at the application layer. Periodic scanning for instances allowing IMDSv1.
Where to start
If you can do only three things this quarter:
- Eliminate long-lived access keys for humans (federated SSO).
- Turn on CSPM and fix the top 10 critical findings.
- Centralise control-plane logging to a separate, immutable logging account.
Those three close the door on the most common breach paths and give you visibility for the rest.
Take the 20-question Cloud Security Maturity assessment → for a domain-by-domain read on identity, configuration, data, monitoring and DevSecOps.