Resource Context Rbac

@@ -3,8 +3,10 @@ title: Manage access to Microsoft Sentinel data by resource description: This article explains you can manage access to Microsoft Sentinel data by the resources a user can access. Managing access by resource enables you to provide access to specific data only, without the entire Microsoft Sentinel experience. This method is also known as resource-context RBAC. author: EdB-MSFT ms.topic: how-to-ms.date: 01/09/2023+ms.date: 07/02/2026 ms.author: edbaynash+ai-usage: ai-assisted+ms.custom: msecd-doc-authoring-1016   #Customer intent: As a security administrator, I want to understand when to use Azure RBAC at the resource-context level so that I can grant specific data access to users without exposing the entire Microsoft Sentinel environment.@@ -16,7 +18,7 @@ Access to a workspace is managed by using Azure RBAC. Typically, users who have  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**.+For users who need access only to specific data in the workspace, we recommend that you configure your role-based access control (RBAC) based on the resources that are allowed to those 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: @@ -48,19 +50,19 @@ For example, the following image shows a simplified version of a workspace archi  [ ![Diagram of a sample architecture for resource-context RBAC.](media/resource-context-rbac/resource-context-rbac-sample.png) ](media/resource-context-rbac/resource-context-rbac-sample.png#lightbox) -In this image:+In the sample resource-context RBAC architecture diagram:  - 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.+Placing the workspace in a separate subscription and using resource-context RBAC allows application 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.+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 Microsoft Entra ID 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 configure resource-context RBAC for non-Azure data, complete the following procedure.  **To explicitly configure resource-context RBAC**: @@ -106,9 +108,9 @@ For example, separating your VMs ensures that Syslog events that belong to Team  If you are collecting your data using the Microsoft Sentinel [Logstash output plugin](connect-logstash.md), 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](#explicitly-configure-resource-context-rbac-for-non-azure-resources).+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 configured in [Explicitly configure resource-context RBAC for non-Azure resources](#explicitly-configure-resource-context-rbac-for-non-azure-resources). -For example, the following code shows a sample Logstash configuration file:+For example, the following Logstash configuration file shows how to ingest events via Beats input and send them to a Log Analytics workspace using the Microsoft Sentinel output plugin, with the `azure_resource_id` field set to tag events with a specific resource group for resource-context RBAC:  ``` ruby  input {@@ -135,11 +137,11 @@ For example, the following code shows a sample Logstash configuration file:  When collecting using the [Log Analytics data collector API](/azure/azure-monitor/logs/data-collector-api), you can assign to events with a resource ID using the HTTP [*x-ms-AzureResourceId*](/azure/azure-monitor/logs/data-collector-api#request-headers) 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](#explicitly-configure-resource-context-rbac-for-non-azure-resources).+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 configured in [Explicitly configure resource-context RBAC for non-Azure resources](#explicitly-configure-resource-context-rbac-for-non-azure-resources).  ## 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.+Depending on the permissions required in your organization, using resource-context RBAC may not fully satisfy all data-access requirements in your organization. For example, consider if an organization that uses the separate-subscription workspace architecture described in [Scenarios for resource-context RBAC](#scenarios-for-resource-context-rbac) 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: