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, you need finer distinctions; the team adds ‘billing-admin,’ ‘content-editor,’ ‘reports-viewer.’ Roles multiply.

At 50 roles, nobody can answer who has access to what.

The four-tier model

• Tier 1: capabilities (read, write, delete) for resource types.
• Tier 2: roles bundle capabilities for an audience (developer, support).
• Tier 3: groups assign roles to teams.
• Tier 4: users belong to 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.