Jan 9, 2024
Author
Brian Rowe, Security Architect

Microsoft Sentinel Data Segregation Options

So, you want to segregate your data in Sentinel? Well, you came to the right place!

In this blog we are going to review four different ways that you can segregate data in Microsoft Sentinel. Keep in mind that there are pros and cons to every segregation option and that the best choice for your organization may even be a hybrid approach combining more than one discussed option.

Also note that this blog is focused on data segregation, but you can also create custom roles that can provide different read/write/action privileges to the underlying log analytics workspace if you want to be more specific than the built-in roles. You can find more information on custom roles in a Log Analytics Workspace here.

1. Sentinel Data Segregation Primer

It is important to understand that Microsoft Sentinel itself does not have any granular access control or data segregation options. Once you grant a user access to Microsoft Sentinel through one of the Sentinel roles, or by assigning Reader/Contributor/Owner permissions to the Resource Group that Sentinel exists within, they have access to all data that exists within Sentinel. The differences in the Microsoft Sentinel roles only pertain to what actions the user can perform within the Sentinel instance. This makes sense as Microsoft Sentinel is designed to be your SIEM (Security Information and Event Management) that has access to all of the environment’s security data to provide a single pane of glass for your security event investigations. Therefore, if you are looking to configure users for different levels of log access in the environment, the underlying configuration will be performed for your Log Analytics Workspace.

2. Log Analytics Workspace (LAW) Data Segregation Primer

There are 2 different access control modes for accessing logs stored in a Log Analytics Workspace: Workspace-context and Resource-context. The access control mode is a setting on each workspace that defines how permissions are set for the workspace. You can find and change your configuration at the Properties section underneath the Settings header on your Log Analytics Workspace, where it will either be set to “Require workspace permissions” for Workspace-context configuration or “Use resource or workspace permissions” for Resource-context configuration.

 

For each of the segmentation options we’ll provide requirements on which LA Workspace mode has to be configured for the environment. This helpful guide on Microsoft Learn will help you understand how different which access mode is best for your organization, but we’ve summarized the most pertinent pieces below.

  • Workspace-context – default for all LA Workspaces that were created prior to March 2019
    • This mode does not allow granular Azure RBAC to be configured, instead access must either be granted to users for the entire LA Workspace or access can be granted granularly to specific tables within the workspace.
  • Resource-context – default for all LA Workspaces created since March 2019
    • This control mode allows granular Azure RBAC to be configured. Users can be granted access to only data associated with resources they are assigned with Azure permissions. When you access the LA Workspace for a particular resource, resource group, or subscription, you can view logs for only resources that you have access to. Queries in this mode are scoped to only data associated with that resource. To grant resource-context permissions, remove a user’s assigned workspace permissions and instead configure the resource permissions for the user.
    • Resource-context limitations:
      • Only works if the resources support the _ResourceId column (ie: works with AMA but not MMA)
      • Does not work for hosts outside of Azure unless they are Arc-connected servers
      • Does not work for Azure Service Fabric
      • Does not work for Application insights unless using a workspace-based Application Insights resource

Now that we’ve reviewed the required foundational principles of Microsoft Sentinel, let’s jump into our four segregation options below.

Option 1: Multiple Sentinel Instances

The first option is just as simple as it sounds, create a Sentinel instance for each of your teams that needs access, affording the option to restrict permissions to each Sentinel instance. As we’re using Sentinel permissions, the LA Workspace access mode for this option is not relevant.

To get logs into the right LA Workspace and subsequent Sentinel instance, you will use the Azure Monitor Agent (AMA). With this you can create Data Collection Rules that can send pertinent logs to the proper workspace, preventing the need to install multiple solutions on your hosts to forward the logs to their rightful destination. You can even send data to other tenants utilizing Azure Lighthouse if you have multiple Azure tenants.

In addition, integrating Azure Lighthouse in your environment can allow your security team to review and access both instances, including things like a multi-workspace view to view all active incidents across all Sentinel instances as well as the ability to use cross-workspace queries to view incidents and data across workspaces. Additionally, you can use these multi-workspace queries to create workbooks and playbooks (logic apps).

Implementation consists of standing up 2 or more Sentinel deployments. For any/all of the department-level or child Sentinel instances, onboard pertinent log sources directly to the child Sentinel instance. The Security Office or parent Sentinel instance should have all of the tenant-level log sources including the Defender suite, Microsoft Entra logs, and any other log sources that don’t fall under a child instance’s management. Then, provide Sentinel permissions for the security team to all Sentinel resource groups while the department level users should only have permissions applied to their resource group. Sentinel-specific roles should follow best practices and users should only be provided the permissions they need to fulfill their jobs. For Sentinel-specific role information, please see this page.

Advantages:

  • Ease and speed of configuration
  • Users only get access to the data that they need

Disadvantages:

  • Requires multiple pairs of LA Workspaces and Sentinel to be created
  • Requires multiple data collection rules/endpoints to be configured
  • Must search in multiple Sentinel instances, although this is made easier by implementing Lighthouse then using the multi-workspace view as well as cross-tenant queries (see section above for details)
  • Sentinel UEBA will not work between the 2 instance’s data
  • Analytic rules will not work out of the box and will instead need to be rewritten with cross-workspace queries
  • Assuming a single tenant is in-use, tables such as AzureActivity and Defender alerts will only be in the main security Sentinel instance
    • For a workaround to overcome this limitation, see Option 3 – Splitting logs to child instances below
  • Will have to manage/push all alert rules to both instances creating instance management overhead

Option 2: Per-Table RBAC

The second option utilizes the Log Analytics Workspace and direct table-level read permissions to allow teams to access the data that they need to accomplish their jobs; for example, Windows Admins get access to the Windows SecurityEvent and Event tables, your network team to get access to the CommonSecurityLog table, Azure administrators access to the AzureActivity table, etc. As we’re using Log Analytic Workspace table-level permissions, the LA Workspace access mode for this option is not relevant.

Your individual teams will use Sentinel’s underlying Log Analytics Workspace to query the tables that they are assigned to, while your security team would still have access to all of the data in Sentinel using the traditional Azure RBAC roles for Sentinel. Learn more here.

Implementation for table-level access for your non-security team users requires 2 steps. First, a custom role needs to be created that grants users access to see the workspace and run queries but does not provide them visibility into any tables. Second, navigate to the Log Analytics Workspace -> Tables, selecting the proper table and clicking the 3-dot menu on the right of the table then selecting Access control (IAM). Within here, add a role assignment of Reader then add the AAD user (or AAD group) that you would like to provide access. With no other Sentinel-related or Azure permission applied to the LA Workspace instance, the non-security team users would then navigate to the LA Workspace and would only have access to the table explicitly defined with table-level read permissions assigned above. For more information and full instructions, please see here.

Advantages:

  • Users only get access to the tables that they need
  • Affords the creation of a single paired LA Workspace and Sentinel instance
    • All analytic rule and Sentinel UEBA correlations will work across all data

Disadvantages:

  • Users configured with these permissions will not have access within Sentinel to see incidents/alerts and will instead only have access to log sources based upon their configured RBAC
  • Requires custom roles to be created and assigned to grant table-level access
  • This approach would provide all individuals in a custom RBAC group access to the entire table that access is being provided to, for example all of the Syslog or AzureActivity table

 

Option 3: Splitting Logs to Child Instances

The third option requires onboarding all log sources to a main/parent Sentinel instance and then using a solution such as logic apps or function apps to push the pertinent alerts and data to child Sentinel instances. This option might be needed for organizations that need to break down tenant-level tables and security solutions (Defender, Entra, Purview, non-Microsoft security solutions, etc) to child instances. As we’re using separate Sentinel instances for data segregation, the LA Workspace access mode for this option is not relevant.

Implementation consists of standing up 2 or more Sentinel instances, then creating push/synchronization logic/function apps (or similar solution) that can identify data for the child instance and configuring permission required to be able to write from the logic/function app (or other solution) to the child instance running at set intervals.

Advantages:

  • It might be necessary if a single instance of a tenant-level application or 3rd party security solution needs to be split to child instances
  • Explicit control of precisely what is shared to a child Sentinel instance

Disadvantages:

  • Requires multiple pairs of LA Workspaces and Sentinel to be created; double billing for Microsoft Sentinel ingest for any logs that need to exist in both Sentinel instances
  • For this to work, the underlying data must have something that can be used as a discernibly different identifier for which data needs to be pushed to the child instance
  • Sentinel UEBA will not work in the child instance as custom tables are not supported
  • Custom tables are handled different from the CommonSecurityLog table in Microsoft Sentinel so searching & parsing will be slower
  • Incidents will be duplicated between the parent and child tenant so this will have to be accounted for
  • Will have to manage/push all alert rules to both instances creating instance management overhead
  • This has been made easier with Microsoft’s Workspace Manager

 

Option 4: Resource-Level Splitting

The fourth option requires that any log sources you’d like to segment support resource-level access, meaning that the logs have a _ResourceId column (Azure VMs, Arc-connected hosts, etc). This is extremely powerful as you can granularly provide access to supported resources with a little scoping/planning and minimal continued configuration. This method does require that the LA Workspace access mode is set to “Use resource or workspace permissions”. Learn more here.

Implementation requires configuration of Resource Groups to restrict access to the logs of the resources that support resource-level access, meaning that the logs have a _ResourceId column. Providing the users access to the resource group that they manage, for example with read permissions, allows them to use the Monitoring -> Logs section under each resource group or resource, or use Azure Monitor directly to access the logs of all Resources that the user has access to.

Advantages:

  • Minimal configuration after initial planning
  • Users have access to only specific data that they need to access
  • Affords the creation of a single paired LA Workspace and Sentinel instance
    • All analytic rule and Sentinel UEBA correlations will work across all data

Disadvantages:

  • Users configured with these permissions will not have access within Sentinel to see incidents/alerts and will instead only have access to log sources based upon their configured RBAC
  • Requires planning of resource groups to provide access needed
  • For computers outside of Azure, resource-context is only supported with servers onboarded with Azure Arc
  • For Application Insights, this is supported only when using a workspace-based Application Insights resource
  • Does not work for Azure Service Fabric

Summary

  • Microsoft Sentinel itself does not have any granular access control or data segregation options. Once you grant a user access to Microsoft Sentinel through one of the Sentinel roles, or by assigning Reader/Contributor/Owner permissions to the Resource Group that Sentinel exists within, they have access to all data that exists within Sentinel
  • Simpler is usually better and most organizations do not need complex solutions to segregate their data. Ensure that if you are evaluating one of these segregation options that you have either Business or Compliance requirements that dictate this need as extra risk can be introduced, especially in the case of multiple Microsoft Sentinel instances
  • There are pros and cons to every segregation option and that the best choice for your organization may even be a hybrid approach combining more than one discussed option

Discover the potential of data segregation for your organization with our expert guidance. At BlueVoyant, we’re not just a service provider; we’re your partners in navigating the complex world of data solutions. Let us walk you through the process in detail and tailor a solution that meets your specific needs. Contact us for a more in-depth discussion.

Close