The Classic Cloud Mistakes

Cloud breaches rarely come from exotic, sophisticated attacks. Read the post-mortems — the published reports of what went wrong — and the same handful of mistakes appear again and again. They are not caused by brilliant adversaries. They are caused by people who were busy, moving fast, or simply did not know the rule they were about to break.

None of these mistakes are hard to understand, and understanding them is most of the protection. A short checklist, applied consistently, prevents the majority of the worst outcomes.

Think of a pre-flight checklist. A pilot checking the instruments before take-off is not doing anything clever. They are doing something systematic: making sure no item on a known list of failure points was missed. None of the items is exotic; any one of them, if skipped, is how accidents happen.

The Exposed Bucket

Cloud storage is organized into containers often called buckets. By default, a bucket is private — only identities you explicitly allow can read from it. But misconfiguration is possible: one wrong setting, and the bucket is readable by anyone on the internet. Patient health records, customer payment data, internal documents, database backups — the most headline-generating cloud breaches have come from exactly this mistake. The fix is to check access settings, to make "public" require a deliberate action, and to monitor for buckets that become public accidentally.

Over-Broad Access

The previous topic introduced least privilege: give each identity only what it needs. The opposite — giving everyone admin rights, or never reviewing what each service account is permitted to do — is called over-broad access or over-permissioning. It is extremely common because it is the path of least resistance: give full access once and never have to think about permissions again. The cost comes when one of those over-permissioned identities is compromised. A leaked key with admin rights can delete an entire account. A leaked key with narrow read-only access can do much less damage.

Weak Account Protection

Two related mistakes often appear together. First: not enabling multi-factor authentication (MFA) on important accounts. MFA means that logging in requires something in addition to a password — a code from a phone app, a hardware key. A stolen password alone is not enough. Without MFA, a single leaked password is all an attacker needs. Second: using the root account (the all-controlling master login that owns everything in the cloud account) for everyday tasks. If the root account is compromised, nothing is off-limits. Best practice is to lock the root account away and use it only when strictly necessary, protected by its own MFA.

Hard-Coded Secrets and Forgotten Resources

Two smaller but costly mistakes round out the list. Hard-coded secrets — passwords and API keys written directly into application code — were covered in the last topic: code leaks, and secrets inside it leak with it. The fix is a secrets vault. Forgotten resources are a different kind of problem: machines, databases, and services left running after a project ends or a test finishes, racking up charges and presenting an unmonitored attack surface. Cloud accounts can accumulate years of forgotten infrastructure. A periodic review — asking "should this still be running?" — catches both the security exposure and the unnecessary spend.