Five cloud misconfigurations we keep finding

Every cloud assessment is different on the surface: different services, different team sizes, different histories. Underneath, the same handful of problems appears with remarkable consistency. None of them require an advanced attacker to exploit. All of them are cheap to check.

Here are the five we look for first, with the quickest way to check each in your own environment.

1. Long-lived access keys for humans

Engineers create an access key to run a script once, and three years later it still exists, still has administrator rights, and lives in a dotfile on a laptop that has since been replaced.

How to check: generate the credential report for your account and list every human user with an active access key older than 90 days. For most teams the right number is zero; humans should sign in through single sign-on and receive temporary credentials.

2. Roles that trust too much

Cross-account roles and CI roles often carry trust policies far broader than intended: any principal in another account, any repository in your source control organisation, or a wildcard condition that matches more than it looks like it should.

How to check: list every role with a trust relationship to an external account or a federated identity provider, and read the conditions. If a condition is missing, assume it matches everything.

3. Storage that is public by accident

Public buckets are rarer than they were, thanks to safer defaults, but they have been replaced by subtler exposure: pre-signed URLs with week-long expiry pasted into tickets, website buckets that also hold exports, and snapshots shared with "all accounts".

How to check: confirm the account-level public access block is on, then search for snapshots and images shared publicly. These are easy to miss because they do not show up in the storage console.

4. Logging that exists but nobody reads

Audit logging is often enabled in one region, retained for a short period, and stored in the same account an attacker would compromise. When an incident happens, the record of it is either gone or editable.

How to check: make sure an organisation-wide audit trail covers all regions, writes to a separate log-archive account, and is retained for at least a year. Then confirm someone receives an alert when it is stopped or modified.

5. Management interfaces on the internet

Database ports, Kubernetes API servers, admin dashboards and remote desktop, reachable from anywhere because a security group was opened "temporarily" during a migration.

How to check: query your security groups for inbound rules open to the whole internet on anything other than ports 80 and 443. Each result needs either a business reason written next to it or a fix today.

Fix the pattern, not the instance

Each of these can be fixed in an afternoon. The harder work is keeping them fixed. Guardrails at the organisation level, such as service control policies that block public sharing and deny long-lived keys for humans, stop the next engineer from recreating the problem without anyone noticing.