Controlling access to Azure Sentinel Data: Resource RBAC

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.

Overview

In no organization, everyone is allowed to see all information. The same is true for the data collected by your SIEM system. Luckily, Azure Sentinel has the tools needed to limit such access. The primary methods to enable such role-based access to control to data, or data RBAC for short, are either to split your Azure Sentinel implementation into multiple workspaces or to use Resource RBAC. In this blog post, I discuss when you should use each of those methods and describe how to implement the latter. To learn more about using multiple workspaces in Azure Sentinel, you review out Azure Sentinel architecture webinar (YouTube, Slides) or get deeper listening to the forthcoming Azure Sentinel for MSSPs webinar (register here).

For completeness, there are two additional methods for controlling access to data in Azure Sentinel, both serve well some use cases but are less general and which I don't discuss in detail in this post:

1. Table level RBAC enables you to set access control for each table in the Azure Sentinel workspace.  
2. You can provide access to data using Workbooks and use Workbook access permissions to control who has access to a workbook.

Lastly, it is worth mentioning the ability to control access to the different features in Azure Sentinel. Azure Sentinel feature RBAC is typically used to differentiate between roles in the SOC, rather than to control access to data.

Understanding Resource RBAC

When using resource RBAC, users who have access to the Azure Sentinel workspace can typically view all the data. Resource RBAC helps by enabling users, let's call them none SOC users, who do not have access to the workspace to view telemetry collected for resources they have log reader permissions for.

None SOC users can view logs by navigating to a resource they have log read access to, or to a resource group containing it and use the "logs" and "workbooks" options to query the data and visualize it, respectively as demonstrated below:

Alternatively, none SOC users can navigate to Azure Monitor and use the "Logs" or "Workbooks" options. Using Azure Monitor enables the user to select the scope of the query or workbook, spanning multiple resource groups and optionally selecting specific resources.

A third option is to create an empty Log Analytics workspace, without data for the none SOC users to use. In this case, users need to know in what workspaces the data is stored and use cross-workspace queries to access the data. While this sounds complicated, it has the advantage that this workspace can host workbooks, saved KQL queries, and saves KQL functions to get the user starting.

When is resource RBAC useful?

The resource RBAC description above implies a significant distinction. In essence, for a SOC user to get full Azure Sentinel experience, you need permissions for the workspace, which implies access to all data. Resource RBAC enables external users to get access to their data, but not a full Azure Sentinel experience.

To summarize:

There are use cases for which resource RBAC does not provide a solution. One such scenario is when a subsidiary has a security operations team which requires a full Azure Sentinel experience. In this case, using a multi-workspace architecture, as described above, is the preferred option.

Another challenge is data RBAC, which is not based on resources, for example, limiting access based on the user an event references. You might encounter this requirement when trying to limit access to Office 365 logs based on the subsidiary of the user.

The full solution for this would be to use custom collection, as described later. A more straightforward solution, even if partial, would be to enrich the relevant log with the subsidiary information, as described in Chris Boehm's blog post. Once enriched, use the information in workbooks, so that each none SOC team gets access to a workbook pre-filtered to display only its data.

Implementing Resource RBAC

The best practice for implementing resource RBAC requires the following steps:

1. Enable resource RBAC for the workspace as described here. 
2. Create a resource group for each none SOC team and assign log reader permissions for team members.
3. Follow the guidelines below for each event type to group resources to the team resource groups you created above, and tag events with the right resource ID.

Once you completed those steps, team members have access to their logs through the "logs" and "workbooks" options of their team resource group.

In some cases, especially when collecting from Azure resources, the resource group assignment must follow a different methodology preventing you from grouping resources to the team resource groups described above. In those cases, using the alternatives suggested above for none SOC team use, namely a dedicated workspace or through Azure Monitor, work.

Tagging events for Azure resources

When Azure resources, whether VMs using the Log Analytics agent or PaaS services, send telemetry to Azure Sentinel, the log records are automatically tagged with the resource ID of the originating resource. Ideally, group the resource under the resource group you created. If you cannot do that, make sure that the none SOC team has log reader permission to the resources themselves.

Tagging events with Collector VMs: CEF, Syslog, and WEF*

When collecting events using CEF, Syslog, or WEF*, a collector VM is used to collect events from multiple source systems. For example, when a Syslog collector VM listens to different sources sending Syslog and forwards it to Azure Sentinel, the collector VM resource ID is assigned to all events. When using an on-prem or another cloud collector VM, you can ensure it has a resource ID by implementing Azure Arc.

As a result, you need to ensure that separate collector VMs are processing events that belong to different none SOC teams. So that all the Syslog events which belong to team A are collected using collector VM A.

To summarize, to allow a user group access to its data:

• Deploy a separate collector VM (or VM scale set) to collect events belonging to this user group.
• Associate the collector VM with the resource group allocated to this user group above.
• If an on-prem collector VM, enroll it in Azure Arc.

* WEF is in private preview at this time.

Resource RBAC for custom collection

When collecting using the Log Analytics data collector API, you can assign to events a resource ID using a special HTTP header x-ms-AzureResourceId. As you may expect, the resource ID must be a real resource ID. So which resource ID should you use? While you can use any valid resource ID, the best practice is to use the ID of the resource group you created for the none SOC team, which the events should be accessible by.