Microsoft Sentinel is now supported in Unified RBAC with row-level access

Enabling streamlined, granular, and scalable permissions

We’re excited to announce the Public Preview of Unified Role Based Access Control (URBAC) for Microsoft Sentinel, together with row-level access. This new capability, available April 1^st, extends the Microsoft Defender Unified RBAC model to Sentinel, enabling streamlined, granular, and scalable permissions management across your security workloads. With the addition of row-level scoping, multiple teams can operate securely within a shared Sentinel environment while using consistent and reusable scope definitions across tables and experiences.

What’s new?

Unified RBAC for Sentinel

• Manage in Defender portal: Sentinel permissions can now be managed directly in the Microsoft Defender portal. Assignments can automatically include future data sources and workspaces as they’re added.
• Unified permissions model: Manage user privileges for Sentinel and other Defender workloads in a single, consistent system.
• Easy role migration: Import existing roles and assignments from Azure Sentinel for easy migration.

Sentinel Scoping

• Create and assign scope: Scope can now be created from the permissions page and assigned to users or user groups across workspaces.
• Tag data: Scope tags can be applied to rows in tables, using ‘Table Management’, allowing you to create rules that tag newly ingested data automatically with the scope.
• Access data: Scoped users can manage alerts, incidents, and hunt over scoped data (including the lake), allowing them to see only the data within their own scope.

Common use-cases include accommodating multiple SOC teams within a shared environment (for example segregated by business unit, geography or discipline), providing access to teams outside of the SOC, or restricting sensitive data.

How does it work?

Sentinel in Unified RBAC

1) Create a custom role

• Go to the Permissions page in Defender, and select Defender XDR -> Roles

• You can also click Import roles to re-create existing roles in URBAC automatically.
• In the Roles page, click Create a custom role.
• Enter a role name and description, and select the required permissions using this mapping:

 

• Click Add assignment and name the assignment.
• Select users and/or groups.

• Choose the Sentinel workspaces for the assignment.
• (Optional) Enable Include future data sources automatically.
• Click Submit.

2) Activate Unified RBAC for Sentinel

• Go back to the Roles page.
• Click on Activate workloads button in the top.

• Click on Manage workspaces.
• Select the desired workspaces to enable URBAC on.
• Click Activate workspaces.

 

3) Edit, Delete, or Export Roles

• To edit: Select the role, click Edit, and update as needed.
• To delete: Select the role and click Delete.
• To export: Click Export to download a CSV of roles, permissions, and assignments.

Prerequisites

• Access to the Microsoft Defender portal: Ensure you can sign in at https://security.microsoft.com.
• Global administrator, combined with being a subscription owner OR combined with having user access administrator + Sentinel contributor role on the workspace.
• Sentinel workspaces onboarded to Defender portal: Sentinel workspaces must be available in the Defender portal before roles and permissions can be assigned.

Learn more

For more information, see Microsoft Defender XDR Unified role-based access control (RBAC) - Microsoft Defender XDR | Microsoft Learn

Sentinel Scoping

1) Create & assign scope

• First, we are going to create a scope tag that we will use to assign to users
• Navigate to the Permissions page in the Defender portal
• Click Microsoft Defender XDR, and then the Scopes tab

• Click on Add Sentinel scope
• On this screen, fill out a name for your scope, and optionally a description
• That’s it! Scope is created. You can create more scope tags if you like.

Next, we are going to assign this scope tag to users:

• Go back to the Permissions page, this time to the Roles tab.
• Click on Create custom role.
• Fill out the basics (role name, description).
• Next, assign permissions as appropriate.
• In the assignments screen, select the right users or user groups, the data. sources and data collections (Sentinel workspaces) as appropriate.
• Now, select the Sentinel scope Edit button.

• Select the scopes (one or more) that you want to assign to this role.
• Once you are happy with all the settings, go ahead and submit to save the role.

2) Tag tables with scope

• Now that we have created scope and assigned it to users, we are going to tag the tables from which these users should be allowed to see data.
• Navigate to the Tables page under Microsoft Sentinel.
• Select the table you would like to assign scope to.
• Click the Scope tag rule button.

• Enable scoping by clicking the toggle on Allow use of scope tags for RBAC.
• Then, click the toggle under Scope tag rule to enable your first rule.
• Add a KQL rule/expression which will specify which rows in this table should be tagged to the scope that you will attach. This will create a Data Collection Rule, and supports transformKQL supported operators and limits. Be aware of how to write expressions here: for example, to scope by location you can write: Location == 'Spain'.
• Then, select the scope tag that should be assigned to those rows.
• Once you are done, go ahead and click Save. From now on, all data/each row that gets ingested into this table that meets the KQL rule/expression will be tagged with the scope tag that you’ve selected.

3) Access data

a) Now that we’ve created scope, assigned it to users, and tagged the right data, we are ready to start using the scope.

b) From now on, newly ingested data automatically gets tagged with scope. Historic (previously ingested) data is not included.

c) You can add this scope to your detection rules by referencing the ‘SentinelScope_CF’ field.

d) Alerts generated based on scoped data are now automatically tagged with the associated scope.

e) Your scoped users can now access the different experiences where scoped data is visible, for example:

f) View alerts that have resulted from data tagged with scope.

g) View incidents that contain alerts with data tagged with scope.

h) Run advanced hunting queries over the rows in the tables that the user is allowed to see.

i) Run KQL queries over the Sentinel lake.

Prerequisites

• Access to the Microsoft Defender portal: https://security.microsoft.com.
• Sentinel workspaces onboarded to Defender portal: Sentinel workspaces must be available in the Defender portal before roles and permissions can be assigned.
• Sentinel in URBAC: You must have enabled Sentinel in URBAC before using this feature.
• Permissions (for the person creating/assigning scope and tagging tables).
• Security Authorization (Manage) permission (URBAC): Allowing you to create scope and assignments.
• Data Operations (Manage) permission (URBAC): for Table Management.
• Subscription owner or assigned with the “Microsoft.Insights/DataCollectionRules/Write” permission.

FAQ

What happens to legacy Sentinel roles after activating Unified RBAC?

URBAC becomes the primary source of your permissions for Sentinel instead of Azure RBAC, so ensure the right permissions are set up on URBAC. Once URBAC is activated for a Sentinel workspace, continue to manage your permissions in URBAC.

What about roles that are not yet supported?

For example, the Automation Contributor role. You can assign these on Azure RBAC and they will continue to be respected.

Can I revert to managing Sentinel roles in Azure after enabling Unified RBAC?

Yes, you can deactivate Unified RBAC for Sentinel in the Defender portal’s workload settings. This will revert to legacy Sentinel roles and their associated access controls.

Does Unified RBAC support both Sentinel Analytics and Lake workspaces?

Yes, Unified RBAC supports both Sentinel Analytics and lake workspaces for consistent access management.

What happens if an alert contains data outside of the user’s scope?

The scoped user can only see the data associated with their scope. If the alert contains entities/evidence that the user has no access to, they will not be able to see those. If the user has access to at least one of the associated entities, they can see the alert itself.

What happens to incidents that contain multiple alerts?

The scoped user can see an incident if they have access to at least one of the underlying alerts. A scoped user can manage the incident if they have access to all of the underlying alerts and if they have the required permission. Unscoped users can see all alerts and incidents.

What about other experiences; detection rules, playbooks, etc.?

A scoped user can only have read access to other resources/experiences for the moment, unless you create a separate assignment where you grant them elevated permissions. In the next few months, we will be introducing scoping for resources such as detection rules, automation rules, playbooks, etc.

Is Sentinel Scoping also applicable to the Sentinel lake?

Yes, to any tables that support transformations (data collection rules).

Can I apply scope to a full table? What about previously ingested data?

You can create a KQL query that captures all fields in the table, which essentially creates ‘table level’ scope. Currently, it is not possible to grant access at full-table level (meaning, scoping previously ingested data).

Can I scope XDR tables?

Not currently. This includes XDR tables which received extended retention in the lake.

If I ingest Defender data into Sentinel, is their scope (e.g. Device Groups, Cloud Scopes) maintained in Sentinel tables?

No, if you ingest Defender data into Sentinel, that scoping is not propagated. Please keep this in mind when deciding how to apply scope to Sentinel tables.

 

Interested in learning more? Stay tuned for a webinar coming in April.