Least Privilege Is an Ongoing Lifecycle

Least privilege is not a one-time configuration.

People join, change responsibilities, leave, take temporary assignments, and move between systems. Services change too.

A permission that was reasonable six months ago can become unnecessary today.

Think in lifecycle events

Join

What minimum access is required for the new role?

Move

Which old permissions should be removed when responsibilities change?

Temporary elevation

How is temporary authority approved, time-bounded, logged, and removed?

Leave

Which accounts, sessions, keys, and group memberships must be disabled or revoked?

Periodic review

Can the owner still justify every privileged relationship?

This is identity governance in plain language.

Permission accumulation creates privilege drift

Fictional history:

August: alice → viewer
October: alice temporarily helps operators → viewer + operator
November: temporary assignment ends
February: alice still has operator

No attacker is required. The system drifted because removal was not part of the process.

That is a governance failure with a technical effect.

Service identities need least privilege too

Applications often use non-human identities to reach databases, storage, APIs, or message systems.

A status web service that only reads public match data may not need permission to:

• change roles;
• delete backups;
• alter database schema; or
• administer log storage.

Restricting service identity privileges can reduce the impact of software failure or misuse.

Again, the control comes from architecture: which operations does required function actually need?

Privileged actions deserve stronger evidence

For sensitive changes, useful logs might include:

time
authorized account
action
target
previous role/state
new role/state
approval/reference if required
result
request/change ID

Do not include passwords or secret tokens.

The goal is accountability for state change.

Lab: role-review exercise

Given the fictional current state:

alice: viewer, operator
bob: operator
coach: admin
archive-service: database-read, database-write, role-admin
status-service: database-read, database-write

Required functions:

alice: view status only
bob: update match notes
coach: manage roles + restore backup
archive-service: copy approved database export to backup store
status-service: read status + update operator-submitted notes

Identify permissions that cannot be justified from the required functions.

Potential findings:

• Alice no longer needs operator.
• archive-service has no stated need for role-admin.
• whether archive-service needs database-write depends on the stated backup mechanism; do not assume.

The important part is evidence-based justification.

Apply a controlled privilege correction

In the model:

alice: remove operator
archive-service: remove role-admin

Then retest:

Required function

• Alice can still read status.
• archive service can still perform the represented backup task.

Negative boundary

• Alice cannot update match notes.
• archive service cannot alter role data.

Evidence

• role-change record exists;
• stale privileged sessions are invalidated or rechecked according to the architecture.

This is least privilege with proof.

Privilege reduction can break systems

Do not remove permissions blindly.

A service may have hidden dependencies or undocumented operations.

That is why strong privilege reduction follows:

MODEL REQUIRED FUNCTION
     ↓
BASELINE
     ↓
CHANGE ONE RELATIONSHIP
     ↓
NEGATIVE TEST
     ↓
REQUIRED-FUNCTION TEST
     ↓
MONITOR

If you cannot identify required function, you are not ready to remove access confidently.

Finish the Identity and Authorization Evidence Map

Submit:

1. identities and roles;
2. action/authorization matrix;
3. authentication vs authorization distinction;
4. session lifecycle;
5. stale-session test;
6. privilege review findings;
7. two controlled privilege reductions;
8. required-function and negative retests;
9. evidence fields for privileged changes; and
10. residual risk.

A strong final claim:

In the Week 11 identity model, removing unjustified operator and role-admin privileges preserved the represented required functions while the negative tests denied the removed actions. The exercise does not establish the correctness of identity systems or session mechanisms not represented in the model.

That is least privilege as engineering rather than a slogan.