7.12 RBAC, Multi-Workspace, and Governance

RBAC, Multi-Workspace, and Governance

Introduction

As your Sentinel deployment matures from a single-analyst lab to a multi-team production environment, governance becomes essential: who can see which data, who can modify which rules, who can execute which playbooks, and how are changes tracked and audited. This subsection covers the RBAC model, multi-workspace operational patterns, and the governance framework that keeps Sentinel operations controlled and auditable.

Sentinel RBAC: the four built-in roles

Sentinel provides four built-in roles assigned through Azure (Entra ID) and scoped to a specific workspace.

Microsoft Sentinel Reader — view incidents, alerts, workbooks, analytics rules, and all Sentinel content. Cannot modify anything. Appropriate for: stakeholders who need visibility (security managers, compliance officers), junior analysts in training, and audit reviewers.

Microsoft Sentinel Responder — Reader permissions plus: change incident status (assign, close, reopen), change incident severity, add comments and tags, and run playbooks on incidents. Cannot create or modify analytics rules, automation rules, or data connectors. Appropriate for: Tier 1 SOC analysts who triage and respond to incidents but do not configure detection infrastructure.

Microsoft Sentinel Contributor — Responder permissions plus: create and modify analytics rules, automation rules, workbooks, hunting queries, and data connectors. Full Sentinel configuration access. Cannot manage workspace-level settings (retention, pricing tier) or Azure RBAC assignments. Appropriate for: Tier 2/3 analysts and detection engineers who build and maintain the detection and automation infrastructure.

Microsoft Sentinel Playbook Operator — run playbooks on incidents. This role does not include Reader permissions — it must be combined with another Sentinel role (typically Responder) to be useful. Appropriate for: service accounts or automation identities that need playbook execution without broader Sentinel access.

Workspace-level roles vs Sentinel roles

Sentinel roles control what users can do within the Sentinel experience. Workspace-level Azure roles control access to the underlying Log Analytics workspace.

Log Analytics Reader — query any data in the workspace. Combined with Sentinel Reader for stakeholders who need to run ad-hoc KQL queries but should not modify Sentinel content.

Log Analytics Contributor — query data and modify workspace settings (retention, daily cap, table management). Required for administrators who manage the workspace infrastructure.

Monitoring Contributor — manage diagnostic settings, workbooks, and alert rules at the Azure Monitor level. Needed for teams managing operational monitoring alongside security monitoring.

In practice, most SOC team members need both a Sentinel role (for Sentinel-specific actions) and a Log Analytics role (for KQL query access). The combination determines their effective permissions: a Tier 1 analyst with Sentinel Responder + Log Analytics Reader can triage incidents and run investigation queries, but cannot modify workspace settings or Sentinel configuration.

Table-level and resource-context RBAC

For organisations that need data access control within a single workspace — without splitting into separate workspaces — two granular RBAC options are available.

Table-level RBAC restricts access to specific tables. Configure through Azure RBAC custom roles that include or exclude specific table read permissions. Example: the HR security team can access AuditLogs and SigninLogs for identity investigations, but cannot access DeviceProcessEvents or EmailEvents. The endpoint security team has the inverse permissions.

Resource-context RBAC limits data visibility based on the Azure resource that generated it. If an analyst is granted access only to the “Production-Web” resource group, they can query data from resources in that group but not data from “Production-Database” or “Development” resources — even though all data resides in the same workspace.

Resource-context RBAC is particularly useful for large organisations where different teams manage different environments: the cloud security team sees Azure resource data, the endpoint team sees device data, the identity team sees Entra data. Cross-team visibility remains available for incident commanders and senior analysts through broader role assignments.

Multi-workspace governance for large enterprises

Large enterprises and MSSPs operating multiple workspaces need standardised governance practices to maintain consistency.

Centralised rule management with CI/CD. Store analytics rules, automation rules, and workbooks as code in a Git repository (Azure DevOps or GitHub). Deploy to all workspaces using CI/CD pipelines. This ensures: every workspace has identical detection coverage, all rule changes are tracked through version control, changes require pull request review before deployment, and rollback is a simple Git revert.

The Sentinel-as-code model treats detection rules the same way development teams treat application code: versioned, reviewed, tested, and deployed through automation. For a single-workspace environment, this is a best practice. For a multi-workspace environment, it is a necessity — manual rule management across 10+ workspaces is error-prone and unscalable.

Cross-workspace queries for correlation. When investigation requires data from multiple workspaces, use the workspace() function:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// Cross-workspace correlation: sign-ins across UK and EU workspaces
union
    (workspace("sentinel-northgateeng-prod-uksouth").SigninLogs
    | where TimeGenerated > ago(1h)),
    (workspace("sentinel-northgateeng-prod-westeurope").SigninLogs
    | where TimeGenerated > ago(1h))
| where RiskLevelDuringSignIn in ("medium", "high")
| project TimeGenerated, UserPrincipalName, IPAddress,
    _ResourceId
| order by TimeGenerated desc

Cross-workspace queries are slower and more expensive than single-workspace queries. They require the querying user to have read permissions on both workspaces. Use them only when cross-region or cross-environment correlation is necessary for investigation — not for routine queries.

Azure Lighthouse for MSSPs. MSSPs use Azure Lighthouse to manage customer workspaces from their own tenant. Lighthouse provides: delegated access (MSSP analysts use their own credentials to access customer workspaces), granular scope control (each analyst is authorised for specific customers only), full audit trail (all MSSP actions in customer workspaces are logged in the customer’s activity log), and scalable deployment (deploy rules, playbooks, and workbooks to all customer workspaces from a central repository).

Sentinel governance framework

Document and enforce governance that covers configuration management, change control, and operational standards.

Change control for analytics rules. All rule changes (creation, modification, deletion, disabling) must be: proposed by the detection engineer or senior analyst, reviewed by a second team member, tested against historical data to verify the change does not introduce false positives or detection gaps, and deployed through CI/CD (not the portal UI). The Git commit history serves as the audit trail for every rule change.

Naming conventions. Standardise analytics rule names so the SOC team can identify a rule’s purpose from its name: [Source] - [Detection Pattern] - [Severity]. Examples: “Entra ID - Sign-in from sanctioned country - High”, “Endpoint - Encoded PowerShell execution - Medium”, “TI - IP match to SigninLogs - High”, “Email - Phishing URL clicked by multiple users - Medium”.

Severity assignment criteria. Document when to use each severity level: Informational (automated enrichment, no analyst action required), Low (minor policy violation, review within 24 hours), Medium (potential threat requiring investigation within 4 hours), High (confirmed or likely threat requiring immediate investigation and response).

MITRE ATT&CK mapping requirement. Every analytics rule must map to at least one MITRE ATT&CK technique. This enables ATT&CK coverage reporting (which techniques are you detecting?) and gap analysis (which techniques have no detection rules?).

Quarterly access review. Review all Sentinel and workspace role assignments: who has Contributor access — is it still justified? Remove departed or transferred staff. Verify service accounts have minimum necessary permissions. Document the review for compliance.

Audit trail. Sentinel operations generate events in the Activity Log and SentinelAudit table: who created or modified rules, who changed connector configuration, who ran playbooks, who accessed data through KQL. Retain audit data for your compliance period (1-7 years depending on regulation).

Sentinel-as-code: the CI/CD pipeline for detection

For teams beyond 2-3 analysts, managing analytics rules through the Azure portal UI becomes error-prone and unauditable. The Sentinel-as-code approach treats detection rules as software: version-controlled, reviewed, tested, and deployed through automation.

Repository structure. Store analytics rules as ARM templates or YAML definitions in a Git repository. Organise by category:

sentinel-content/
├── analytics-rules/
│   ├── identity/
│   │   ├── entra-sign-in-from-sanctioned-country.json
│   │   ├── entra-suspicious-app-consent.json
│   │   └── entra-mfa-fraud-report.json
│   ├── endpoint/
│   │   ├── mde-encoded-powershell.json
│   │   └── mde-suspicious-scheduled-task.json
│   ├── email/
│   │   └── mdo-phishing-url-clicked-multiple-users.json
│   └── threat-intelligence/
│       ├── ti-ip-match-signinlogs.json
│       └── ti-domain-match-devicenetwork.json
├── automation-rules/
├── watchlists/
├── workbooks/
└── hunting-queries/

CI/CD pipeline. Configure Azure DevOps or GitHub Actions to deploy rules when changes are merged to the main branch. The pipeline: validates the ARM template syntax, runs the KQL query against a development workspace to verify it executes without errors, deploys the rule to the production workspace, and reports the deployment status. Failed deployments are automatically rolled back.

Pull request workflow. All rule changes require a pull request. The PR includes: the rule definition (ARM template), the rationale for the change (description, linked incident if the rule was created from an investigation finding), and the test results (KQL query output from the development workspace). A second team member reviews the change before merging. This review catches: KQL errors that would cause rule execution failure, overly broad queries that generate excessive false positives, missing entity mappings, and incorrect severity assignments.

Auditing Sentinel operations

The SentinelAudit table records configuration changes to Sentinel resources. This is your audit trail for governance and compliance.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// Who modified analytics rules in the last 30 days?
SentinelAudit
| where TimeGenerated > ago(30d)
| where SentinelResourceType == "Alerting rule"
| where Description has_any ("created", "modified", "deleted", "disabled")
| project TimeGenerated, 
    OperationName = Description,
    RuleName = SentinelResourceName,
    ModifiedBy = ExtendedProperties.CallerName
| order by TimeGenerated desc

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// Detect unauthorized rule modifications (outside CI/CD)
// If your governance requires all changes through CI/CD,
// any portal-based modification is a policy violation
SentinelAudit
| where TimeGenerated > ago(24h)
| where SentinelResourceType == "Alerting rule"
| where Description has_any ("created", "modified", "deleted")
| where ExtendedProperties.CallerName != "deployment-service-principal@tenant.onmicrosoft.com"
| project TimeGenerated, Description, SentinelResourceName,
    ModifiedBy = ExtendedProperties.CallerName

The second query is particularly valuable for governance enforcement: if your policy requires all rule changes through CI/CD, any modification by a human user (not the deployment service principal) is a policy violation that should be investigated and corrected.

Compliance documentation for Sentinel operations

Regulated industries (financial services, healthcare, government) require documentation of security monitoring capabilities and governance. Sentinel operations documentation should include:

Architecture document. Workspace architecture (single/multi), region, pricing tier, data retention policies, data classification for each table tier. Updated annually or when architecture changes.

RBAC matrix. Who has which role, why, and when the assignment was last reviewed. Updated quarterly at the access review.

Detection coverage report. Active analytics rules mapped to MITRE ATT&CK techniques, showing which techniques are detected and which have coverage gaps. Updated monthly or when rules change.

Incident response metrics. Mean time to detect (MTTD), mean time to respond (MTTR), incidents by severity and classification, false positive rate by rule. Generated monthly from SecurityIncident table queries.

Change log. All analytics rule, automation rule, and connector changes with date, author, rationale, and approval. Generated automatically from the CI/CD pipeline and SentinelAudit table.

This documentation package satisfies most regulatory audit requirements for security monitoring governance. The key insight: almost all of this documentation can be generated automatically from Sentinel data and the CI/CD pipeline — it does not require manual document creation if the operational practices are in place.

Knowledge check