Cloud security: the configuration is the attack surface

The shared responsibility model is stated clearly by every cloud provider and misunderstood constantly. The provider secures the hardware, the hypervisor, the physical network and the managed service internals. You secure identity, access, network exposure, encryption choices, and what your applications do.

Essentially every publicised cloud breach has been on the customer side of that line. Not a broken provider, but an over-permissive role, a storage bucket left open, or logging that was never switched on.

Identity first

Network perimeters matter less when everything is API-addressable. Identity is the control plane, and it is where an attacker who gets any foothold will look next.

Eliminate long-lived credentials. Static access keys sitting in CI configuration, developer laptops and scripts are the single most common initial access vector. Replace them with federated short-lived credentials for humans and roles for machines. Where a static key genuinely cannot be avoided, rotate it on a schedule and alert on use from unexpected locations.

Least privilege, derived from actual usage. Most roles accumulate permissions and never lose them. Access Analyzer on AWS, and equivalent tooling on Azure, can generate a policy from what a role has actually used over a period. Start from that rather than from a wildcard.

Enforce MFA on anything privileged, and remove standing administrative access in favour of time-bound elevation.

This is where the largest reduction in blast radius comes from. A compromised credential that can read one bucket is an incident; one that can assume an administrative role is a catastrophe.

Know what is exposed

Map every public endpoint deliberately and justify each one. Storage buckets, databases with public addresses, management interfaces reachable from the internet, and security groups open to the world.

The recurring failure is not that someone exposed something on purpose. It is that a temporary rule was added during troubleshooting and never removed, and nobody was watching.

Encryption and keys

Encrypt in transit and at rest — both are close to default on modern cloud services, so the work is in verifying rather than implementing. The decisions that matter are about keys: who can use them, who can administer them, and whether key policy is separated from data access.

Customer-managed keys are worth the extra operational cost where regulation demands control over key lifecycle. Where it does not, provider-managed keys are usually the more reliable choice, because the failure mode of a mismanaged customer key is permanent data loss.

Detection you can prove works

Enable audit logging across every account, writing to a central destination the accounts themselves cannot modify. Enable the native threat detection services. Then route findings somewhere a human actually reads.

The last part is where most implementations fail. Findings accumulating in a console nobody opens are not detection. Route high-severity findings into whatever channel your team genuinely watches, tune out the noise, and test the path end to end by generating a benign finding on purpose.

Prevention beats detection

A scanner tells you afterwards that someone created a public bucket. A service control policy or Azure Policy means they could not.

Remediation without prevention is a task you repeat every quarter. Once you have fixed a class of misconfiguration, add the guardrail that stops it recurring — deny public storage, deny disabling audit logging, deny deployment outside approved regions, require encryption.

Where to start

If you are beginning from nothing, in this order: enable and centralise audit logging, remove long-lived access keys, enforce MFA on privileged access, map and justify public exposure, then add guardrails for whatever you just fixed.

That sequence front-loads the changes that reduce risk most per hour spent, and each one makes the next easier to prove.