Blog 15 September 2026 3 min read
The ten cloud misconfigurations found in almost every account
In short
Cloud incidents rarely come from a sophisticated attack. They come from ten ordinary settings, forgotten or left at their defaults, often combined. Here is the list, with what to look for in each case, whatever your cloud and your tooling.
Cloud incident reports look alike. No zero-day, no state actor: a resource exposed that nobody thought was exposed, an identity broader than needed, and a log that was not enabled to prove it. Here are the ten settings that keep coming back, in the order we meet them.
1. The publicly accessible bucket
The classic. A bucket policy that grants read to everyone, a public-access block disabled “just for a test”, an inherited access control list. Data leaves without any alert, since there is no intrusion.
Check: the public-access block at account level and on each bucket, policies containing an “everyone” principal, static websites that should not be one.
2. The admin port open to the world
SSH, RDP, a database port, an admin interface: a security group that accepts any source address on these ports exposes the machine to the whole internet, and to the bots that scan it continuously.
Check: every inbound rule without a source restriction, admin ports first, then all the others.
3. The database reachable from the internet
A managed database with a public address and a wide security group. Never intended; it is the default of a creation wizard or a leftover of a migration.
Check: the “publicly accessible” option on each database, then its security group.
4. Eternal access keys
An access key created three years ago for a script, never rotated, still valid, and nobody remembers where it lives. The day it leaks (code repository, workstation, support ticket), nothing distinguishes it from legitimate use.
Check: the age of each key, its last use, and whether a role could replace it.
5. The administrator identity without a second factor
An account with full rights, protected by a password alone. Phishing campaigns target exactly these accounts.
Check: the list of identities with broad rights, and the state of the second factor for each.
6. The role that can do everything
A wildcard policy attached to an instance or function role “so it works”. The machine that carries it becomes the entry point to the whole account.
Check: the effective permissions of each role, not the declared policies; what the role actually used in the last ninety days.
7. The metadata service in version 1
On an exposed instance, an ordinary web flaw is then enough to steal the role’s credentials. One setting to change, often left at its default.
Check: instances whose metadata tokens are optional, starting with those that have a public address.
8. Logs disabled or not retained
Account activity log not enabled in one region, bucket logs missing, network flow logs never created. When the incident comes, impossible to say what happened, or since when.
Check: the activity log in every region, its retention, its protection against deletion.
9. Encryption at rest left aside
A volume, a snapshot, a database or a bucket unencrypted. Rarely the origin of an incident, always an aggravating factor, and a direct non-compliance on most frameworks.
Check: storage resources without encryption, and snapshots shared with other accounts.
10. The secret in a readable place
A password in a function’s environment variable, a private key in a bucket, a token in a code repository. The secret always ends up where someone can read it.
Check: environment variables of functions and containers, the contents of buckets and disks, repository history.
What the list does not say
None of these ten points is serious on its own. A public bucket that holds only public images is not an incident. A wide role on an isolated machine is not either. The incident is the combination: the public machine (2) with IMDSv1 (7) and a wide role (6) that reads a bucket (1) holding customer data. Check the list, then check the combinations.
That is the job of a configuration scanner coupled with a graph of the relationships between resources. Ctadel checks these ten points on six clouds, and connects the findings to show the paths they form together. The Cloud configuration page details what is checked; the online demonstration shows the result on a fictitious account.