Review

Role review process

Overview

Reaper algorithm

• Gather all audit entries for selected users
• Look up resource action mappings for each audit entry
• Check condition for each permission set within the user's current roles
  • $ResourceIsSelf: Check if the resource being accessed is the user's own account and then if the mapped resource action is defined in this permission set.
  • $SubjectIsOwner: Check if the subject (user) is the owner of the resource being accessed and if the mapped resource action is defined in this permission set.
  • empty: Tenant-wide permissions (more privileged) - Check if the mapped resource action is defined in this permission set.
• Return all current roles that match for each audit entry
• If same audit entry has multiple matching roles, and some have a tenant-wide condition - assume one or more activities needed a tenant-wide permission. If only $ResourceIsSelf or $SubjectIsOwner are present, then it is likely that the activity was performed on the user's own resources and no special role was needed.
• For every relevant role after the previous evaluations:
  • Determine the namespace and resource of each mapped resource action (microsoft.core/users is the namespace and resource for microsoft.core/users/basic/update)
  • Group all the resource actions in a permission set based on namespace+resource and count the actions
  • Determine how much of the total resource actions configured in a permission set belongs to mapped resource actions
  • The role definition with the highest count of eligible resource actions configured will be the one assumed to be created with the purpose of handling the related activity