Why this matters
An auditor asks why a given person can see a given table. This module gives you the chain of policy, role and assignment that answers it.
Before you start
A policy is a rule, a role is a bundle of rules
Policies describe what may be done. Roles collect policies into something you can hand to a person or a team. Separating them means you can change a rule everywhere at once by editing the policy, instead of hunting down every role that restated it.
Start from no access
Start from no access and add what a role needs. Starting broad and trimming later never gets trimmed, because nobody wants to remove access that turns out to be load bearing.
Separation of duties has to be designed in
In a regulated environment the person who proposes a change should not be the person who approves it. That property does not emerge from a permission model on its own. It comes from deliberately splitting the relevant policies across different roles.
The interactive demo
Work through the demo below. It runs in your browser with nothing to install. Watch for:
- Creating a policy
- Creating a role
- Relating the role to a policy
- Adding the role to a user
This demo is also available on its own at the Learning Center.
After this module you should be able to
- Build a policy and attach it to a role
- Trace why a specific user has a specific permission
- Design a role split that enforces separation of duties