Manage access to Microsoft Sentinel data by resource

Typically, users who have access to a Log Analytics workspace enabled for Microsoft Sentinel 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 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 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 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.

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.

For example, the following image shows a simplified version of a workspace architecture where security and operations teams need access to different sets of data, and resource-context RBAC is used to provide the required permissions.

In this image:

• The Log Analytics workspace enabled for Microsoft Sentinel is placed in a separate subscription to better isolate permissions from the subscription that the applications teams use to host their workloads.
• The applications teams are granted access to their respective resource groups, where they can manage their resources.

This separate subscription and resource-context RBAC allows these teams to view logs generated by any resources they have access to, even when the logs are stored in a workspace where they don't have direct access. The applications teams can access their logs via the Logs area of the Azure portal, to show logs for a specific resource, or via Azure Monitor, to show all of the logs they can access at the same time.

Explicitly configure resource-context RBAC for non-Azure resources

Azure resources have built-in support for resource-context RBAC, but might require additional fine-tuning when working with non-Azure resources. For example, data in your Log Analytics workspace enabled for Microsoft Sentinel that are not Azure resources include Syslog, CEF, or AAD data, or data collected by a custom collector.

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

To explicitly configure resource-context RBAC:

1. Make sure that you've enabled resource-context RBAC in Azure Monitor.

2. 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.

3. 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
   • Resource IDs with Logstash collection
   • Resource IDs with the Log Analytics API collection

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.

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>   
     }
 }

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.

Alternatives to resource-context RBAC

Depending on the permissions required in your organization, using resource-context RBAC may not provide a full solution. For example, consider if the organization whose architecture is described in the previous section must also grant access to Office 365 logs to an internal audit team. In this case, they might use table-level RBAC to grant the audit team with access to the entire OfficeActivity table, without granting permissions to any other table.

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.
Limit access by management group	Place Microsoft Sentinel under a separate management group that's dedicated to security, ensuring that only minimal permissions are inherited to group members. Within your security team, assign permissions to different groups according to each group function. Since all teams have access to the entire workspace, they'll have access to the full Microsoft Sentinel experience, restricted only by the Microsoft Sentinel roles they're assigned. For more information, see Permissions in Microsoft Sentinel.

Next steps

For more information, see Permissions in Microsoft Sentinel.