RBAC Beyond Three Roles: Sustainable Permission Models
RBAC starts with three roles, becomes ungovernable at twelve. The four-tier model is the durable shape.
Why three-role rots
Three roles work for 10 people. At 50, the team needs finer distinctions and starts adding "billing-admin," "content-editor," "reports-viewer." Roles multiply quickly; at 50 roles, nobody can answer "who has access to what?"
- Three roles work small. At 10 people, admin/user/read-only covers everyone with predictable mapping.
- Roles multiply at 50. Each new use case adds a role; the catalog grows linearly with team size, then super-linearly.
- Audit becomes impossible. At 50 roles with overlapping permissions, the question "who has access to X?" has no clean answer.
- The fix. Four-tier model: capabilities, roles, groups, users; each tier does one thing; composition is explicit.
The four-tier model
The four-tier model decomposes RBAC into orthogonal layers. Each tier has one job; composition replaces sprawl. The model survives org growth where flat-role models do not.
- Tier 1: capabilities. Read, write, delete for resource types; the atomic permissions; per-resource granularity.
- Tier 2: roles. Bundle capabilities for an audience (developer, support, ops); roles are reusable templates.
- Tier 3: groups. Assign roles to teams; the org structure maps to groups; supports inheritance.
- Tier 4: users. Belong to groups; users do not get roles directly; the lifecycle flows through groups.
Migration from sprawl
From one-role-per-user-need: define capabilities first; collapse existing roles into combinations of capabilities.
Most orgs find their 50 roles collapse to 5-8 distinct capability bundles.
Quarterly audit
Quarterly: report ‘users with privilege X.’ Anyone with privilege not used in 90 days → downscope.
Tools (SailPoint, native cloud IGA) automate the report; the discipline is reviewing it.
Antipatterns
- One role per micro-permission. Sprawl.
- Inheriting roles forever. Lingering access from prior team.
- No quarterly audit. Drift wins.
What to do this week
Three moves. (1) Pick one production system to apply this pattern to first. (2) Measure the security signal before/after. (3) Document the gap and write a follow-up ticket so the program stays alive between quarterly reviews.