Cloud misconfiguration: the same five findings, everywhere

Cloud security assessments across AWS, Azure and Google Cloud converge on a short list. The platforms differ, the specifics differ, but the underlying failures repeat. If you want to know what a review would find before commissioning one, start here.

1. Identity permissions far wider than the workload needs

This is the most common finding and the one with the largest blast radius. A role is created during development with broad permissions because narrowing them takes time and the deadline is real. It works, so nobody revisits it.

The result is a service that needs to read one storage location holding permissions to modify the account. Every cloud provider offers tooling to identify unused permissions from actual access history. Run it, and grant what was used rather than what was requested.

The related finding is human standing privilege: administrators with permanent elevated access rather than time-bound elevation.

2. Management interfaces reachable from the internet

SSH and RDP open to the world, database ports exposed for a migration that finished last year, management endpoints without IP restriction. Almost always this was a temporary measure that outlived the reason for it.

Bastion services, just-in-time access and private connectivity all solve this. The obstacle is rarely capability; it is that nobody has an inventory of what is exposed. Generate one, and the list is usually shorter and more alarming than expected.

3. Logging that is incomplete or not retained

Audit logging is frequently enabled in the primary region and not others, or enabled without an export, so it ages out before anyone needs it. Data-plane logging — who read which object — is often off entirely, because it costs more.

The consequence only appears during an incident, at the point where you need to determine what an attacker accessed and find that the record does not exist. Decide retention deliberately, protect the logs against deletion by the account being logged, and confirm coverage across every region, not just the busy one.

4. Secrets in places secrets should not be

Credentials in environment variables committed to a repository, connection strings in application configuration, long-lived access keys shared between engineers, keys that have never rotated.

Managed secret stores exist on every platform, and workload identity removes the need for a static credential in most service-to-service cases. The work is not technically difficult. It is that migrating a working credential feels like risk for no visible benefit, until it is.

5. Drift, because nothing watches the configuration

An environment hardened during a project does not stay hardened. Resources are created manually during an incident, a policy is relaxed to unblock a deployment, a new account is set up outside the standard process.

Posture management addresses this by evaluating configuration continuously rather than at review time. Where infrastructure is defined as code, remediating in the code rather than the console keeps the fix from being reverted by the next deployment — a fix applied only through the console is a fix with an expiry date.

Where to start

In order of value returned for effort: inventory your internet-exposed surface, review identity permissions against actual usage, confirm audit logging is complete and exported, then look at secrets. Posture monitoring comes after, because it is most useful once the backlog is cleared.

None of this requires additional licensing on any major platform. It requires someone to look.