An enterprise platform's permission model has grown to thousands of roles and profiles, and nobody can determine what access a given user actually has. What is the diagnosis and the remediation?
Show the full answer Hide the answer
The diagnosis
Roles were created per exception and never consolidated. The cost of creating a role is borne once by the person who needs access; the cost of removing one is unbounded risk, because nobody knows who depends on it. So the count grows monotonically.
Compounding factors:
- Roles named after people or teams rather than after capabilities, so a reorganisation orphans them.
- Additive permission accumulation. Users gain access when they change roles and never lose the old access — the classic privilege creep, where a long-tenured employee has more access than anyone intended.
- No expiry. Access granted for a project completed three years ago persists.
- Effective permissions unanswerable, because they derive from a union of profiles, roles, groups, sharing rules and record-level exceptions.
The remediation
1. Make effective access computable and visible. Before changing anything, build the ability to answer "what can this user actually do, and why". Without it, every remediation is guesswork, and the ability to answer it is what makes everything else possible.
2. Attribute-based rules where the population is large. Instead of a role per team per region, express access as rules over attributes — department, region, employment type — evaluated dynamically. This collapses combinatorial role explosion, at the cost of rules that are harder to audit point-in-time.
3. Access reviews driven by usage, not by inventory. Reviewing thousands of roles annually is a rubber-stamp exercise. Reviewing unused access — permissions not exercised in ninety days — is short, evidence-based and defensible. Usage data is what makes revocation politically possible.
4. Time-bound elevation for privileged access. Standing administrative access replaced by just-in-time elevation with an expiry and an audit record. This removes the highest-risk permissions from the permanent grant set entirely.
5. Joiner-mover-leaver automation, with the mover case handled properly — access recalculated on role change rather than accumulated. The mover case is the one almost every organisation gets wrong.
6. Ownership per role, with unowned roles proposed for deletion automatically.
What not to do
A big-bang redesign. Rebuilding the permission model in one change breaks access for people who need it, in ways that are discovered by them being unable to work. The remediation is incremental: make access visible, remove unused access with evidence, consolidate duplicates, and prevent new sprawl with better defaults.
The prevention
Make the request path produce good permissions. If asking for access yields a narrow, time-bounded, correctly-named grant with an owner, sprawl slows. If it yields a new bespoke role because that is the only thing the tooling makes easy, no amount of review keeps up.