Cloud security: the misconfigurations that matter most

Most cloud incidents do not come from a sophisticated flaw in the provider, but from a misconfiguration on the customer side. A permission that is too broad, an exposed store, a key forgotten in a repository. The cloud is not less secure than the data centre: it is secure differently, and it assumes you know exactly which half of the work is yours.

The value of cloud — speed, elasticity, managed services — arrives with a surface that changes constantly. Every new resource is a configuration, and every configuration can be right or wrong. The mistakes that matter most are few and recurring.

The shared responsibility model, understood for real

Every provider publishes a version of the same deal: they secure the infrastructure, you secure what you put on it — data, identities, configurations, code. The line moves with the service: with a virtual machine you manage almost the whole stack; with a serverless or managed service the provider’s responsibility rises, but access configuration and data protection always stay yours.

Incidents often begin in the grey zone, where each side assumes the other has it covered. The first control is understanding, service by service, where the line falls.

IAM: where almost everything is decided

In the cloud, identity is the control plane. Who can create, read, modify and destroy resources is defined by IAM policy, and most of the risk concentrates here. Over-permissioned roles, principals with admin privileges “for convenience”, inherited permissions nobody has reviewed: these turn a single compromised access into an environment-wide problem.

The principle is always least privilege, with permissions tied to the task rather than the person, and a periodic review of what is actually used. Roles able to modify the policies themselves or disable logging deserve particular care: they are the keys to the kingdom.

Secrets management

Access keys, tokens and passwords do not belong in code, in container images or in environment variables left in the clear. Yet it is one of the most common mistakes: a secret committed to a repository — private today, perhaps public tomorrow — stays in version history even after it is removed.

The answer is a dedicated secrets management service, with retrieval at runtime, regular rotation and — where possible — short-lived credentials tied to the workload’s identity rather than static keys. The fewer long-lived secrets exist, the fewer things can be stolen.

Logs and visibility: seeing what happens

You cannot investigate an incident you never recorded. Management-plane logging — who made which API call, when and from where — is the trail that separates a question you can answer in an hour from an impossible reconstruction months later. It should be enabled across all accounts and all regions, not only the ones you remember.

But logs only help if someone looks at them. You need adequate retention, tamper protection and at least basic detection on the signals that matter: credential creation, policy changes, access from unexpected places. Visibility is what makes cloud security verifiable instead of assumed.

Data exposure: public by mistake

One of the most costly mistakes is also one of the most banal: an object store, a database or a backup made reachable from the outside without anyone really deciding so. All it takes is a loosened network permission, an access policy that is too open, a test environment copied from production with real data inside. The data was not “stolen”: it was public, and someone simply found it.

The defence is layered: encryption at rest and in transit as a baseline, but above all controls that prevent public exposure by default, so that making something accessible requires an explicit, logged act rather than being a silent accident. And it is worth knowing, at any moment, where the data that truly matters actually lives.

Make the default secure, not the exception

Fixing configurations one by one is a battle that never ends. The real lever is how resources come into being: infrastructure as code with secure-by-default settings, automated checks that block known mistakes before release, and company-level guardrails that prevent the most dangerous configurations everywhere, not account by account.

That way security stops being perpetual cleanup and becomes a property of how you build.

The takeaway

In the cloud the mistakes that matter are few: assumed responsibility boundaries, over-generous IAM, mishandled secrets and absent logs. Address them at the source — with secure defaults, least privilege and real visibility — and you will have removed most incidents before they become incidents.