Cloud security: the misconfigurations that cause real incidents

Cloud providers run infrastructure more securely than almost any individual customer could. That is not where cloud incidents come from. They come from the configuration layer — the part that remains the customer's responsibility — and the same mistakes recur with striking consistency.

Identity is the perimeter

In cloud environments, network position matters far less than it used to. What matters is what a set of credentials can do.

Over-permissioned roles. The most common finding in any cloud assessment. A service that needs to read one storage bucket is granted broad storage permissions because that was faster during development, and it is never narrowed. When that service is compromised, so is everything the role can reach.

Grant the narrowest permission that works, then verify with the provider's access analyser which permissions are actually being exercised. The gap is usually large.

Long-lived access keys. Static credentials committed to a repository, embedded in a container image, or sitting in a developer's shell history remain among the most reliable initial access vectors. Use short-lived, automatically rotated credentials — instance roles, workload identity federation, OIDC from your CI provider. If a static key must exist, it should have an owner, an expiry, and monitoring.

Unprotected root and break-glass accounts. These should have hardware-key MFA, no access keys at all, and alerting on every use.

Storage exposure

Public object storage remains a leading cause of disclosed breaches, and modern defaults have improved considerably. The remaining problem is usually not a bucket marked public — it is a bucket reachable through an over-broad policy, or through a role that a compromised service holds.

Enable account-level public access blocks. Encrypt at rest with customer-managed keys where the data warrants it. Turn on access logging, and alert on bulk read patterns that do not match normal application behaviour.

Network configuration

Management interfaces exposed to the internet. Databases, container orchestration APIs, admin consoles, and remote access services reachable from anywhere are found in nearly every external assessment. Restrict these to known networks or place them behind an identity-aware proxy.

Flat internal networks. A single compromised workload should not have network reach to every other workload. Segment by function and environment.

Absent egress control. Most environments carefully filter inbound traffic and permit unrestricted outbound. Exfiltration and command-and-control both depend on outbound connectivity. Restricting it is unglamorous and effective.

Visibility

Logging that was never enabled. Control-plane audit logs, storage access logs, and network flow logs cost relatively little and are the difference between understanding an incident and guessing at it. Enable them before you need them, and store them somewhere the compromised account cannot delete them.

Unknown accounts and projects. Large organisations routinely discover cloud accounts created by a team years ago, still running, still billed, and monitored by nobody. Inventory at the organisation level, and enforce that new accounts inherit baseline controls automatically.

Multi-cloud reality

Teams end up in multiple clouds through acquisition, team preference, or a specific managed service. The security cost is real: each provider has a different identity model, different defaults, and different terminology for similar concepts.

If you are genuinely multi-cloud, invest in a consistent posture management layer and a single identity source federating into each provider. What you should not do is assume your expertise in one provider transfers cleanly to another — the defaults differ in ways that matter.

A practical priority order

If you are starting from an unknown position:

1. 1Enumerate every cloud account your organisation owns.
2. 2Enable audit logging everywhere and centralise it.
3. 3Enforce MFA on all human identities; hardware keys for administrators.
4. 4Find and remove static long-lived credentials.
5. 5Block public access to storage at the account level.
6. 6Identify management interfaces exposed to the internet and restrict them.
7. 7Review the most permissive roles against actual usage and narrow them.
8. 8Segment the network, starting with your most sensitive workloads.

Nothing in that list is novel, and none of it requires a new product. Together it prevents the substantial majority of cloud incidents we are called to investigate.