Control objective
Role-based access control assigns permissions to roles and assigns subjects to those roles. Roles represent stable job or system functions. Role hierarchy and constraints can reduce repeated grants and enforce separation of duties.
Role design
Start with tasks, resources, and actions. Build roles from reviewed permission sets, not organizational titles alone. Separate administration of role definitions from role assignment. Define incompatible roles, activation conditions, and temporary elevation where needed.
Lifecycle and review
Record owners for each role and permission. Review membership and actual use. Remove obsolete permissions and direct grants. Recompute access after role change instead of only adding the new role. Test the effective permission set, including hierarchy.
Failure and residual risk
Role explosion makes review difficult. Broad roles create excessive authority. Nested groups can hide effective membership. Roles cannot express every resource, relationship, time, or transaction condition without added policy. A correct route role does not imply application object permission.
Pomerium boundary
Pomerium policy can use identity-provider groups and other claims as role-like inputs for route access. The operator owns group lifecycle and meaning. Applications must map their own roles and permissions to internal resources and actions.
Evaluation checklist
- Does each role map to reviewed tasks, resources, and actions?
- Are hierarchy, incompatible roles, and direct grants visible?
- Do mover and leaver events remove obsolete membership?
- Can context or relationship rules express what roles cannot?
- Is effective access tested rather than inferred from role names?
