Reviewing Security Roles in Dynamics 365

Security roles are where Dynamics 365 actually decides who sees which data. They are also where the most disorder builds up over the years. During a project, privileges only ever get extended. They are practically never taken back.

The model in two sentences

A role consists of privileges per table: create, read, write, delete, append, append to, assign and share. Each of these privileges has an access level: own records only, the user's business unit, the business unit including its child units, or the entire organization.

One thing matters for every review: roles add up. If someone has two roles, the broader privilege applies in each case. A restrictive role can therefore never limit a generous one. Anyone who only looks at roles one by one regularly misses what the combination adds up to.

The four patterns I look for first

Organization-wide privileges where business unit would have been enough. This is the most common finding. Read access in particular is handed out generously. Something did not work, and widening the privilege fixed the problem right away.

Delete privileges of unusual breadth. Delete is the only privilege whose effects cannot be undone. Combined with cascading relationships, it quickly turns into data loss far beyond the one record someone wanted to remove. How these things connect is covered in Security Issues in Dynamics 365 Solutions.

Privileges for exporting and bulk retrieval. If you protect sensitive data but still allow every role to export to Excel, you have given up control over copies outside the system. These privileges are not listed with the tables but under the miscellaneous privileges, which is why they are easily overlooked.

Roles without a recognizable purpose. Names like "Test" or "New", or a role that is an exact copy of another one. Duplicates like these make every later change twice as expensive, because nobody knows anymore which one is authoritative.

The approach that has proven itself

Do not start with the roles, start with the data. Which tables contain something that not everyone should see? Then check every role against those tables, instead of working through forty roles in full.

Second: for every privilege, ask for the reason, not for the function. "It works" is no argument for an access level, because organization-wide always works. The question is why the next smaller level is not enough.

Third: check the combinations that actually occur. A list of the role combinations really assigned tells you more than any look at single roles.

What the solution export shows and what it does not

The export contains the roles with every single privilege and its access level, as a complete inventory. That makes evaluations possible that are tedious in the user interface: all organization-wide delete privileges across every role, or all roles with export permission, in one list.

What the export does not contain is the assignment: which user or team has which role? That is environment data. An audit therefore has two parts, and the second one needs access to the system. The export is enough to answer "is this privilege model built cleanly?". It is not enough to answer "who has too much right now?".

The rhythm

Once a year, plus at every larger rollout and every organizational change. And one rule for everyday work that does more than any review: whenever a privilege is extended while troubleshooting, add a note saying why. Without that note, nobody will later dare to take the extension back.