Least Privilege Without Slowing Your Team Down
Least privilege fails when it is applied as a blanket restriction. Starting from real usage rather than guesses makes it practical.
Everyone agrees with least privilege in principle. It fails in practice for a predictable reason: permissions guessed in advance are always wrong, and the cost of being wrong lands on someone who cannot do their job.
After two or three such incidents, somebody attaches an administrator policy to make the problem go away, and the effort has produced the opposite of its intent.
A method that survives contact with a team
- Start with a broad but not unlimited role.
- Let people work normally for a few weeks.
- Read the access logs to see which actions were actually used.
- Write a policy from that evidence.
- Apply it in a warning mode first if the provider supports one.
- Enforce, and keep a fast path for exceptions.
The essential element is step six. A restriction with no quick way to request more becomes an obstacle people route around, usually by sharing credentials.
Where tightening is genuinely worth it
Not every identity deserves equal effort. Concentrate on:
- Automation. A deployment pipeline does a fixed set of things forever. Its permissions can be narrow and stay correct.
- Destructive actions. Deleting storage, terminating instances, changing billing. Restrict these to few people even when read access is broad.
- Production versus everything else. If one boundary is worth enforcing, it is this one.
- Third parties. External tools should receive the minimum scope that makes them work.
Prefer roles to long-lived users
Where a provider supports assuming a role, use it. The credentials are short-lived, expire automatically, and cannot be pasted into a configuration file and forgotten. Static keys are the ones that leak, as discussed in rotating credentials and API keys.
Group by job, not by person
Attach permissions to groups or roles named after functions, and put people in them. Per-person permissions drift immediately and nobody can answer who can do what.
Review on a schedule
Access grows. People change teams, projects end, contractors leave. A quarterly review asking whether each identity still needs what it has takes an hour and prevents the slow accumulation that makes an account impossible to reason about.
On an inherited account this is not a review but a starting inventory, covered in auditing an unfamiliar cloud account.
Cloud accounts on OldCloudShop
Ten providers, every configuration and the starting price for each.
Continue in the library
Other entries covering account structure, billing, security and provider infrastructure.