2.1.1. Sentinel Roles and Permissions
💡 First Principle: Sentinel is a collection of Azure resources (a workspace, a solution, rules, workbooks, Logic Apps), so access is governed by Azure role-based access control. Microsoft provides Sentinel-specific roles sized to SOC jobs, and the least-privilege answer is always the smallest role that covers the task, assigned at the resource group that holds the workspace.
The Sentinel built-in roles stack like this:
| Role | Can do | Cannot do |
|---|---|---|
| Microsoft Sentinel Reader | View data, incidents, workbooks, recommendations | Change incidents or content |
| Microsoft Sentinel Responder | Reader + manage incidents (assign, change status, comment) | Create or edit rules, workbooks, solutions |
| Microsoft Sentinel Contributor | Responder + install and update Content hub solutions, create and edit analytics rules, workbooks, and other Sentinel resources | Create, edit, or run playbooks |
| Microsoft Sentinel Playbook Operator | List, view, and manually run playbooks | Create or edit playbooks |
| Microsoft Sentinel Automation Contributor | Lets Sentinel itself attach and run playbooks from automation rules | Not for user accounts |
Playbooks are Azure Logic Apps, so authoring them sits outside the Sentinel role family: Logic App Contributor on the playbook's resource group creates and edits them. The automation trap deserves its own paragraph. When an automation rule runs a playbook, the caller is the Microsoft Sentinel service account, not the analyst. That account needs explicit permissions on the resource group containing the playbooks (granted through the Sentinel settings page, which requires Owner rights to assign). Once granted, any automation rule can run any playbook in that resource group.
Microsoft's recommended assignments map to job titles: analysts get Sentinel Responder plus Playbook Operator; security engineers get Sentinel Contributor plus Logic App Contributor; service principals that automate management get Sentinel Contributor. A few edge cases recur: creating or deleting workbooks needs Sentinel Contributor, or a lesser Sentinel role (Reader or Responder) plus Workbook Contributor; connecting a data source needs write permission on the workspace (plus whatever the connector itself requires); and guest users who must be assigned incidents need Sentinel Responder and the Entra Directory Reader role.
Scope matters as much as role. Assign at the resource group that contains the workspace, because that scope also covers the playbooks and workbooks living beside it. Assigning only on the workspace means you must also assign on the SecurityInsights solution resource. Remember that role assignments are cumulative: a user holding both Reader and Contributor effectively has Contributor. When you need to restrict access to particular data rather than the whole workspace, use resource-context RBAC or table-level RBAC.
Once Sentinel is onboarded to the Defender portal, the newer platform features use a second permission system. Data lake access, KQL jobs, and similar operations are governed by Microsoft Entra roles (such as Security Operator and Security Administrator) and Defender XDR unified RBAC custom roles, not by the Azure Sentinel roles above.
⚠️ Exam Trap: "Analysts must be able to run existing playbooks on incidents but must not modify them" is Microsoft Sentinel Playbook Operator, not Logic App Contributor (too much) or Sentinel Contributor (doesn't include playbooks). "Automation rules fail to run a playbook" points at the Sentinel service account's missing permission on the playbook's resource group.
Reflection Question: Why does Microsoft make the Sentinel service account, rather than the analyst who wrote the automation rule, the identity that needs permission to run a playbook? What would break if it were the analyst's permissions instead?
