Securing a cloud account: the controls that actually matter

Cloud security incidents are, with rare exceptions, unglamorous. Somebody committed an access key. Somebody reused a password on an account without a second factor. Somebody attached an administrative policy because the specific one was fiddly and never went back to fix it.

The controls that prevent this are small in number and the same on every platform.

The privileged identity

Every provider has an identity that cannot be restricted: the AWS root user, the Azure account owner, the Google Cloud billing administrator, the single login on a smaller provider. It exists to recover the account and to do the handful of things nothing else can.

Treat it as a break glass credential:

• Long, unique password in a password manager.
• Hardware security key where supported, an authenticator app otherwise.
• No access keys attached to it, ever.
• A contact email that somebody actually reads, and alternate contacts set.
• Documented recovery process, tested once so you know it works.

Then create separate identities for day to day work and leave the privileged one alone.

Credentials that expire beat credentials that do not

A long lived access key is a permanent password with no expiry, no session and no second factor. It sits in files, in environment variables, in CI configuration and eventually in a repository.

The fix is architectural rather than procedural:

• Inside the provider, use roles. An instance profile, a workload identity, a managed identity: whatever the platform calls it, the machine receives temporary credentials automatically and there is nothing to leak.
• For CI systems, use OpenID Connect federation. GitHub Actions, GitLab and most modern CI platforms can exchange a short lived token for cloud credentials with no stored key at all.
• For humans, use single sign on with short sessions rather than personal access keys.
• For the remainder, where an external system genuinely cannot federate, scope the key tightly, rotate it on a schedule, and record where it is used.

Run secret scanning on your repositories. Every major platform offers it and it catches the mistake before it becomes an incident.

Least privilege, done pragmatically

The counsel of perfection is to write a bespoke policy for every task. In practice, teams do that for a week and then attach an administrator policy under deadline pressure.

A workable middle path:

1. Start from the provider’s managed job function policies rather than from a blank document. They are usually close enough.
2. Separate environments at the account, subscription or project level. A compromise in staging should not reach production.
3. Use the access analysis tooling each provider ships to find permissions granted but never used, then remove them.
4. Never attach permissions to individuals. Use groups or roles, so removing somebody is one action.
5. Review quarterly. Permissions accumulate; nothing removes them automatically.

Visibility

Audit logging is the control that costs almost nothing and is worthless if you switch it on after the incident. AWS CloudTrail, Azure activity logs and Google Cloud audit logs should all be enabled and delivered somewhere durable, ideally an account other than the one being logged.

Add the free or cheap detection services each provider offers, and alert on a small number of things you would genuinely act on: privileged identity sign in, policy changes granting administrative access, new access keys, and unusual spend. Alerting on everything means alerting on nothing.

Network and data

• Default to private. Databases and internal services should have no public address at all.
• Block public access to object storage at the account level, then grant exceptions deliberately.
• Encrypt at rest, which is generally on by default and worth confirming, and in transit, which is not always.
• Use security groups referencing other security groups rather than IP ranges, so the rules survive instance replacement. See AWS VPC networking basics.

Money is a security control

A compromised account is usually noticed as a bill rather than as an alert. Budget alerts at a threshold you would question are genuinely part of your detection stack, not just finance hygiene. Cryptocurrency mining on stolen credentials shows up as an unusual spend curve long before anything else flags it.

Smaller providers, same principles

DigitalOcean, Hetzner, Linode, UpCloud and the rest have simpler permission models, which means fewer controls and less to get wrong. The essentials still apply: multi factor authentication on the login, API tokens scoped and rotated, SSH keys rather than passwords, and no public database.

The AWS specific version of this checklist is in the first hour in a new AWS account.