Who else has the keys to your cloud?

Ask a team how many people can change production in their cloud account and they will usually give you a small number. Ask how many identities can do it and the answer is very different.

Every CI pipeline, monitoring integration, backup tool, data connector and serverless function has an identity of its own. In the estates we review, these non-human identities routinely outnumber human ones many times over. They do not use MFA, they rarely change, and nobody feels responsible for them.

Why non-human identities are a favourite target

• They have static credentials. Long-lived access keys sit in configuration files, CI variables and third-party dashboards.
• They are over-privileged. Broad permissions are granted to get an integration working on a deadline, and nobody comes back to tighten them.
• Nobody watches them. An unusual action by a human administrator might get noticed. The same action by a service account looks like automation.

Build an inventory first

You cannot reduce what you cannot see. For each cloud account, list:

1. Every user, role, service account and access key that is not tied to a named person.
2. What each one can do, and what it has actually done in the last 90 days.
3. Who owns it: a team or person who can say whether it is still needed.

Most cloud providers offer access analysis tools that show unused permissions and external access. Run them before you start debating policy.

Cut, then tighten

Work in this order, because each step is cheaper than the next:

• Delete identities with no owner and no activity. Disable first if you are nervous, then delete after a few weeks.
• Replace static keys with short-lived credentials. Workload identity for your own services, and federation for CI pipelines and supported vendors.
• Right-size permissions using what the identity has really used. Start with anything that has administrator or wildcard access.

Watch for unusual behaviour

Non-human identities are predictable, which makes anomalies easier to spot than with people. Alert when a service account:

• Is used from a new IP range or country.
• Calls APIs it has never called, especially identity changes such as creating users or keys.
• Is used interactively in the console, which automation should never do.

Make ownership stick

Tag every non-human identity with an owning team and a review date. Bring it up in the same quarterly access review you already do for people. The goal is simple: every key to your cloud should have a name next to it, and a reason it still exists.