Access is granted for a reason and removed for none. Every role, key and service account should have an owner, a purpose and an expiry. What has none of the three is where reviews should start.
How access accumulates
A contractor needed broad access for a migration. A CI pipeline got an extra permission to unblock a release on a Friday. A test environment was connected to production data “for a week”. Each decision made sense at the time. None of them had an end date.
Months later, nobody remembers why the access exists, so nobody feels safe removing it. It stays, and it grows.
Unowned access is not a technical problem. It is a decision nobody is responsible for anymore.
Three questions for every identity
- Who owns it? A person or a team, not “platform” or “legacy”.
- What is it for? One sentence. If it takes a paragraph, it probably does too much.
- When does it end? A date, or a review cycle that actually happens.
Where to start
- Unused permissions. Cloud providers can show which granted permissions have not been used in months. Those are the cheapest to remove.
- Long-lived keys. Static credentials for people or pipelines, where short-lived, federated access would work.
- Wildcards. Policies with
*in actions or resources deserve an owner and a written reason. - Cross-environment access. Anything in test or staging that can reach production.
Keeping it from coming back
Cleanups decay. What lasts is making the right path the easy one: access requested through a form that asks for owner, purpose and expiry; defaults that expire; and an alert when a new wildcard or long-lived key appears.
- Owner for every role and keyAssigned
- Unused permissionsRemoved
- Long-lived credentialsReplaced or justified
- Expiry on temporary accessDefault
- Alerts on new broad accessEnabled
None of this is glamorous. It is also where most real cloud incidents begin.