Manage access to Microsoft Sentinel data by resource

Article
01/09/2023

Typically, users who have access to a Microsoft Sentinel workspace also have access to all the workspace data, including security content. Administrators can use Azure roles to configure access to specific features in Microsoft Sentinel, depending on the access requirements in their team.

However, you may have some users who need to access only specific data in your Microsoft Sentinel workspace, but shouldn't have access to the entire Microsoft Sentinel environment. For example, you may want to provide a non-security operations (non-SOC) team with access to the Windows event data for the servers they own.

In such cases, we recommend that you configure your role-based access control (RBAC) based on the resources that are allowed to your users, instead of providing them with access to the Microsoft Sentinel workspace or specific Microsoft Sentinel features. This method is also known as setting up resource-context RBAC.

When users have access to Microsoft Sentinel data via the resources they can access instead of the Microsoft Sentinel workspace, they can view logs and workbooks using the following methods:

Via the resource itself, such as an Azure Virtual Machine. Use this method to view logs and workbooks for a specific resource only.
Via Azure Monitor. Use this method when you want to create queries that span multiple resources and/or resource groups. When navigating to logs and workbooks in Azure Monitor, define your scope to one or more specific resource groups or resources.

Enable resource-context RBAC in Azure Monitor. For more information, see Manage access to log data and workspaces in Azure Monitor.

Note

If your data is not an Azure resource, such as Syslog, CEF, or AAD data, or data collected by a custom collector, you'll need to manually configure the resource ID that's used to identify the data and enable access. For more information, see Explicitly configure resource-context RBAC.

Additionally, functions and saved searches are not supported in resource-centric contexts. Therefore, Microsoft Sentinel features such as parsing and normalization are not supported for resource-context RBAC in Microsoft Sentinel.

Scenarios for resource-context RBAC

The following table highlights the scenarios where resource-context RBAC is most helpful. Note the differences in access requirements between SOC teams and non-SOC teams.

Requirement type	SOC team	Non-SOC team
Permissions	The entire workspace	Specific resources only
Data access	All data in the workspace	Only data for resources that the team is authorized to access
Experience	The full Microsoft Sentinel experience, possibly limited by the functional permissions assigned to the user	Log queries and Workbooks only

If your team has similar access requirements to the non-SOC team described in the table above, resource-context RBAC may be a good solution for your organization.

Alternative methods for implementing resource-context RBAC

Depending on the permissions required in your organization, using resource-context RBAC may not provide a full solution.

The following list describes scenarios where other solutions for data access may fit your requirements better:

Scenario	Solution
A subsidiary has a SOC team that requires a full Microsoft Sentinel experience.	In this case, use a multi-workspace architecture to separate your data permissions. For more information, see: - Extend Microsoft Sentinel across workspaces and tenants - Work with incidents in many workspaces at once
You want to provide access to a specific type of event.	For example, provide a Windows administrator with access to Windows Security events in all systems. In such cases, use table-level RBAC to define permissions for each table.
Limit access to a more granular level, either not based on the resource, or to only a subset of the fields in an event	For example, you might want to limit access to Office 365 logs based on a user's subsidiary. In this case, provide access to data using built-in integration with Power BI dashboards and reports.

Explicitly configure resource-context RBAC

Use the following steps if you want to configure resource-context RBAC, but your data is not an Azure resource.

For example, data in your Microsoft Sentinel workspace that are not Azure resources include Syslog, CEF, or AAD data, or data collected by a custom collector.

To explicitly configure resource-context RBAC:

Make sure that you've enabled resource-context RBAC in Azure Monitor.
Create a resource group for each team of users who needs to access your resources without the entire Microsoft Sentinel environment.

Assign log reader permissions for each of the team members.
Assign resources to the resource team groups you created, and tag events with the relevant resource IDs.

When Azure resources send data to Microsoft Sentinel, the log records are automatically tagged with the resource ID of the data source.

Tip

We recommend that you group the resources you are granting access for under a specific resource group created for the purpose.

If you can't, make sure that your team has log reader permissions directly to the resources you want them to access.

For more information about resource IDs, see:

Resource IDs with log forwarding

When events are collected using Common Event Format (CEF) or Syslog, log forwarding is used to collect events from multiple source systems.

For example, when a CEF or Syslog forwarding VM listens for the sources sending Syslog events, and forwards them to Microsoft Sentinel, the log forwarding VM resource ID is assigned to all the events they forward.

If you have multiple teams, make sure that you have separate log forwarding VMs processing the events for each separate team.

For example, separating your VMs ensures that Syslog events that belong to Team A are collected using the collector VM A.

Tip

When using an on-premises VM or another cloud VM, such as AWS, as your log forwarder, ensure that it has a resource ID by implementing Azure Arc.
To scale your log forwarding VM environment, consider creating a VM scale set to collect your CEF and Sylog logs.

Resource IDs with Logstash collection

If you are collecting your data using the Microsoft Sentinel Logstash output plugin, use the azure_resource_id field to configure your custom collector to include the resource ID in your output.

If you are using resource-context RBAC and want the events collected by API to be available to specific users, use the resource ID of the resource group you created for your users.

For example, the following code shows a sample Logstash configuration file:

 input {
     beats {
         port => "5044"
     }
 }
 filter {
 }
 output {
     microsoft-logstash-output-azure-loganalytics {
       workspace_id => "4g5tad2b-a4u4-147v-a4r7-23148a5f2c21" # <your workspace id>
       workspace_key => "u/saRtY0JGHJ4Ce93g5WQ3Lk50ZnZ8ugfd74nk78RPLPP/KgfnjU5478Ndh64sNfdrsMni975HJP6lp==" # <your workspace key>
       custom_log_table_name => "tableName"
       azure_resource_id => "/subscriptions/wvvu95a2-99u4-uanb-hlbg-2vatvgqtyk7b/resourceGroups/contosotest" # <your resource ID>   
     }
 }

Tip

You may want to add multiple output sections to differentiate the tags applied to different events.

Resource IDs with the Log Analytics API collection

When collecting using the Log Analytics data collector API, you can assign to events with a resource ID using the HTTP x-ms-AzureResourceId request header.

If you are using resource-context RBAC and want the events collected by API to be available to specific users, use the resource ID of the resource group you created for your users.

Next steps

For more information, see Permissions in Microsoft Sentinel.