Manage access to Microsoft Sentinel data by resource
Access to a workspace is managed by using Azure RBAC. 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.
Note
If your data is not an Azure resource, such as Syslog, CEF, or Microsoft Entra ID 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 for non-Azure resources.
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.
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:
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.
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: |
| 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. |
Related content
For more information, see: