Five cloud misconfigurations we find almost every time

Cloud platforms are not insecure by default, but they are permissive by default, and the gap between those two things is where most of our cloud findings live. The five below appear in the majority of the estates we review, across AWS, Azure and Google Cloud alike.

1. Storage that is more public than anyone intended

Object storage remains the most reliable place to find exposed data. It is rarely a bucket deliberately marked public — the providers have made that hard and loud. It is the subtler variants: a bucket policy that grants read to any authenticated principal (which means any account on the platform, not any account of yours), a pre-signed URL generated with a ten-year expiry and pasted into a ticket, or a CDN distribution that fronts a private bucket and quietly serves paths nobody meant to publish.

What to do: enumerate every bucket and check effective access rather than the visible toggle. Turn on the account-level public-access block and treat exceptions as changes that need approval. Cap pre-signed URL lifetimes in code, not in convention.

2. Roles that grew and never shrank

Identity is where cloud security actually happens, and permission sets accumulate. A role gets a wildcard action during an incident at two in the morning and keeps it for three years. A CI/CD pipeline is granted administrator because someone could not work out which twelve permissions it needed. A service account created for one function is reused for four more.

The consequence is that a single compromised credential yields far more than it should. In one review, an application server's role could not only read the database it needed but also modify the identity policies that constrained it — which turns a foothold into full control of the account.

What to do: use the platform's own access analyser to compare granted permissions against those actually used over the last ninety days, and cut the difference. Prohibit wildcards in resource and action fields for anything non-human. Separate the roles that deploy from the roles that run.

3. Long-lived access keys

Static keys are the credential most likely to end up somewhere it should not be: a repository, a CI variable that was copied into a Slack message, a laptop image, a container layer. We routinely find keys that were created years ago, belong to a person who has left, and still work.

What to do: replace static keys with short-lived credentials wherever the platform supports it — instance roles, workload identity federation, OIDC from your CI provider. For the keys you genuinely cannot remove, rotate on a schedule that is enforced rather than requested, and alert on any key that has not been used in thirty days, because unused keys are pure downside.

4. Networks that are flat behind the perimeter

The external edge is usually reasonable — a load balancer, a couple of open ports. Behind it, everything can reach everything. Security groups reference wide CIDR ranges, internal services listen on all interfaces, and databases accept connections from the whole VPC rather than from the two subnets that need them.

This does not create the breach, but it determines how bad the breach is. Lateral movement from a compromised web instance to a database or an internal admin service is the step that turns an incident into a disclosure.

What to do: default-deny between tiers and open only the specific paths required. Put managed databases on private subnets with no route to the internet. Check the egress rules too — outbound-anywhere is how data leaves and how second-stage payloads arrive.

5. Logging that exists but is not usable

Nearly everyone has audit logging switched on. Rather fewer have it in a form that answers a question during an incident. Common gaps: logs written to a bucket in the same account an attacker would already control, no retention beyond thirty days, data-plane events (who read which object) never enabled because of cost, and no alerting on the handful of events that genuinely matter.

What to do: ship logs to a separate account or project with write-only access from the source. Set retention against your actual investigation needs, not the default. Enable data-plane logging at least for storage holding personal or financial data. Then define a small number of high-signal alerts — root account use, identity policy changes, disabling of logging itself — and confirm they reach a human.

The pattern underneath

None of these are exotic. They are what happens when infrastructure is built quickly under delivery pressure and never revisited, which describes almost every growing company. The most effective countermeasure we see is unglamorous: a quarterly review with a written checklist, and infrastructure defined as code so that the review has something to read other than a web console.

If you do only one of these this quarter, do the identity review. Over-broad roles are the finding that most reliably turns a small incident into a large one.