Cloud environments rarely become insecure through a single bad decision. They drift. One reasonable-looking permission grant at a time, over months and across several teams, they accumulate into an escalation path that nobody designed and nobody can see.
That is the pattern behind most of the cloud findings we report. This guide covers the misconfigurations we encounter most often, why each survives, and what actually fixes it.
Over-Permissive Identity and Access Management
Excessive permissions are the most common serious finding in cloud assessments, and the most consequential, because they determine how bad any other problem becomes.
The mechanism is familiar. A role is created for an application. A new feature needs an additional permission, so one is granted. Something breaks in production at an inconvenient hour, so a broader permission is applied to resolve it and never narrowed afterward. Repeat across several years and several teams and the result is a set of roles with reach far beyond their function.
What makes this dangerous is chaining. A web server role that can assume a data processing role that can read backups is three reasonable grants and one serious problem. Attack paths in cloud identity work exactly like Active Directory attack paths: each edge is defensible and the graph is not.
What fixes it: start from what the workload actually does rather than from what it currently has. Use the provider's access analyzer to identify permissions granted but never used, and remove them. Eliminate wildcards in policy. Review role assumption chains specifically, since that is where escalation lives. And treat this as recurring work, because permissions regrow.
Exposed Storage
Storage exposure produces the incidents that make the news, which has made it the best-known cloud risk and, encouragingly, one of the better-managed ones. Public bucket defaults have improved substantially across providers.
It still appears, in three forms. Genuinely public storage, now rarer. Storage reachable by any authenticated user of the platform, which people frequently mistake for private. And storage that is correctly restricted but whose contents are reachable through an over-permissive role, which is the version that survives longest because it does not appear in a public-exposure check.
What fixes it: enforce public access blocks at the account level rather than per bucket. Audit access policies for grants to broad principals. Encrypt at rest with keys you control for sensitive data, and turn on access logging, since a storage location with no logging cannot tell you afterward what was read.
Secrets in the Wrong Places
Credentials appear in environment variables, in code, in repository history, in container images, in infrastructure-as-code templates and in the parameter store with permissions broad enough that anything can read them.
The repository history case deserves particular note, because a credential removed in a later commit remains fully retrievable in the history, and scanning that only inspects the current state will not find it.
What fixes it: a managed secret store with tight access policies, automatic rotation, and repository scanning that covers history. Where a platform supports workload identity, use it and eliminate the long-lived credential entirely, which is strictly better than protecting it well.
Logging That Would Not Help
Logging is the control most often present and least often useful. Cloud audit logging is enabled, retained somewhere, and connected to nothing that would alert on it.
The specific gaps we find: control plane logging enabled in one region or one account and absent in others; data plane access to storage not logged at all, so nobody can establish what was read during an incident; logs written to a location the compromised account can delete; and retention shorter than the time it typically takes to notice an intrusion.
What fixes it: enable control plane logging across every region and account, without exception. Enable data access logging on anything holding sensitive data. Write logs to a separate account that production credentials cannot reach. Set retention against how long detection realistically takes, not against storage cost. Then connect it to something that alerts.
Network and Exposure Assumptions
Cloud networking is easy to get subtly wrong because the defaults are reasonable and the exceptions accumulate.
Security groups widen over time in the same way IAM policies do. Databases end up with public endpoints, usually because a developer needed access and the temporary change stayed. Management interfaces and internal tools are reachable from the internet because they were deployed into a public subnet by a template nobody read closely. And where peering or transit connections exist, the blast radius of one compromised environment extends into others.
What fixes it: review security group rules against actual traffic, keep data stores off public networks entirely and reach them through private connectivity, and map what your peering relationships actually connect.
The Multi-Cloud Problem
Organizations running more than one platform consistently show a weaker posture on the one used less. The identity models differ, the defaults differ, and the conventions a team has developed on its primary platform do not transfer.
This is worth naming because it is predictable and therefore preventable. Decide the baseline once, express it as policy, and apply it deliberately to both platforms rather than allowing the secondary environment to develop its own habits.
Assessing It Properly
Posture management tooling is worth running and will find benchmark deviation efficiently. What it will not do is reason about attack paths, which is where the findings that matter live, so pair it with periodic human assessment focused on identity relationships and reachability.
The question worth asking is not whether your configuration matches a benchmark. It is what an attacker reaches from each starting point: a compromised developer laptop, a compromised web server, a leaked CI credential. Answering that is what turns a configuration report into an understanding of risk.
To have your cloud environment assessed, get in touch.
Frequently asked questions
What is the most common serious cloud misconfiguration?
Over-permissive identity and access management, consistently. Storage exposure attracts more attention because it produces visible incidents, but excessive permissions are more common and more dangerous, because they turn any single compromise into a much larger one. A role with broader rights than its function requires is the difference between a contained incident and an account takeover.
Who is responsible for cloud security, us or the provider?
Both, under the shared responsibility model. The provider secures the infrastructure; you secure what you configure and what you put in it. The overwhelming majority of cloud incidents originate on the customer side, not because customers are careless but because configuration is where the complexity lives and the defaults are permissive in places.
Does a cloud security posture management tool replace assessment?
No, though it is worth having. CSPM tools are good at detecting deviation from a benchmark and poor at reasoning about attack paths, which is where the serious findings are. A tool will tell you a role has broad permissions. It will not tell you that a specific chain of three roles lets a compromised web server reach your backups.
How often should we assess our cloud environment?
Continuously for configuration drift, using automated posture monitoring, and comprehensively at least annually with a human assessment focused on identity and attack paths. Cloud environments change daily, so an annual snapshot is stale almost immediately, but the annual depth is what finds the escalation chains automation misses.
Is multi-cloud harder to secure?
Materially, yes. Each provider has its own identity model, its own defaults and its own logging behavior, and expertise rarely transfers cleanly. In practice the weaker platform is usually the one a team uses less, because that is where the conventions are least established. Multi-cloud environments benefit disproportionately from a consistent baseline applied deliberately across both.