Azure Sentinel: designing access and authorizations that meet the enterprise needs

You’ve successfully deployed Azure Sentinel and are collecting data and using it for monitoring and hunting purposes. Quickly after, your company’s privacy offer or auditor points out that both the law (for instance: GDPR & AVG) and the company’s requirements don’t allow all admins to have access all the time to all of that personal identifiable data.

You need to come up with a solution to design access to Azure Sentinel in a way that the SecOps people can work with the alerts, the SIEM admins can create/modify rules, and that hunters can sift through all the data to find what they are looking for. How should you do that? In this blog we’ll share some design considerations.

Azure Log Analytics

Azure Sentinel uses a Log Analytics workspace to store its data. Recently, Microsoft introduced a more granular role-based access module for Log Analytics. Previously, we only had the workspace-context access mode, but now we also have a resource-context access mode. For each Log Analytics workspace you can chose the desired access mode.

Resource-context access mode allows you to set permissions all the way down to individual tables in the Log Analytics workspace, aka Table Level RBAC.

You can change the current workspace access control mode from the Properties page of the workspace, which can be found under the Workspace settings node in the Azure Sentinel UI. (Changing the setting will be disabled if you don’t have permissions to configure the workspace)

PRO TIP: Want to quickly know if your Log Analytics workspace is enabled for resource-context access mode? Run this Powershell command:

Get-AzResource -ResourceType Microsoft.OperationalInsights/workspaces -ExpandProperties | foreach {$_.Name + “: “ + $_.Properties.features.enableLogAccessUsingOnlyResourcePermissions}

Want to enabled resource-context permissions for all your workspaces? Run this script:

Get-AzResource -ResourceType Microsoft.OperationalInsights/workspaces -ExpandProperties | foreach {
if ($_.Properties.features.enableLogAccessUsingOnlyResourcePermissions -eq $null)
{ $_.Properties.features | Add-Member enableLogAccessUsingOnlyResourcePermissions $true -Force }
else
{ $_.Properties.features.enableLogAccessUsingOnlyResourcePermissions = $true }
Set-AzResource -ResourceId $_.ResourceId -Properties $_.Properties -Force

Azure Active Directory

Because Azure Sentinel uses Log Analytics as the backend, part of the Azure platform, it therefore also uses Azure Active Directory for its identities. Azure has two built-in user roles for Log Analytics workspaces: Log Analytics Reader and Log Analytics Contributor. Members of the Log Analytics Reader role can:

· View and search all monitoring data
· View monitoring settings, including viewing the configuration of Azure diagnostics on all Azure resources.

Members of the Log Analytics Contributor role can:

· Read all monitoring data as Log Analytics Reader can
· Create and configure Automation accounts
· Add and remove solutions
· Read storage account keys
· Configure collection of logs from Azure Storage
· Edit monitoring settings for Azure resources

These roles can be given to uses at different scopes:

· Subscription — Access to all workspaces in the subscription
· Resource Group — Access to all workspace in the resource group
· Resource — Access to only the specified workspace

Custom roles

If the built-in roles don’t meet the specific needs of your enterprise, you can create your own custom roles. Just like built-in roles, you can assign custom roles to users, groups, and service principals at subscription, resource group, and resource scopes.

PRO TIP: Custom roles are stored in an Azure Active Directory (Azure AD) directory and can be shared across subscriptions. Each directory can have up to 5000 custom roles. (For specialized clouds, such as Azure Government, Azure Germany, and Azure China 21Vianet, the limit is 2000 custom roles.)

You implement table access control with Azure custom roles to either grant or deny access to specific tables in the workspace. These roles are applied to workspaces with either workspace-context or resource-context access control modes regardless of the user’s access mode.

Create a custom role with the following actions to define access to table access control.

· To grant access to a table, include it in the Actions section of the role definition.
· To deny access to a table, include it in the NotActions section of the role definition.
· Use * to specify all tables.

For example, to create a SecOps role for investigations with access only to the SecurityAlert and AzureActivity tables, create a custom role as follows:

{
“Name”: “SecOps investigator”,
“Id”: “88888888–8888–8888–8888–888888888888”,
“IsCustom”: true,
“Description”: “Can access security alerts and query the azure activities for a user.”,
“Actions”: [
“Microsoft.OperationalInsights/workspaces/query/SecurityAlerts/read”,
“Microsoft.OperationalInsights/workspaces/query/AzureActivity/read”
],
“NotActions”: [],
“DataActions”: [],
“NotDataActions”: [],
“AssignableScopes”: [
“/subscriptions/{subscriptionId1}”,
“/subscriptions/{subscriptionId2}”
]
}

Custom Logs

You can’t currently grant or deny access to individual custom logs, but you can grant or deny access to all custom logs. To create a role with access to all custom logs, create a custom role using the following actions:

“Actions”: [
“Microsoft.OperationalInsights/workspaces/query/Tables.Custom/read”
],

PRO TIP: Tobias Zimmergren wrote a great blog how to log custom application security events in Azure Sentinel. You can read it here. These custom log tables end with _CL in their naming in the Log Analytics workspace.

Considerations

• If a user is granted global read permission with the standard Reader or Contributor roles that include the */read action, it will override the per-table access control and give them access to all log data.
• If a user is granted per-table access but no other permissions, they would be able to access log data from the API but not from the Azure portal. To provide access from the Azure portal, take the actions from Log Analytics Reader role into your custom role.
• Administrators of the subscription will have access to all data types regardless of any other permission settings.
• Workspace owners are treated like any other user for per-table access control.
• You should assign roles to security groups instead of individual users to reduce the number of assignments. This will also help you use existing group management tools to configure and verify access

PRO TIP: Unsure who has what access? Use the ‘Access control IAM’ node from the Advanced Settings pane of your Log Analytics workspace to find out:

Privileged Identity Management

Azure AD Privileged Identity Management (PIM) enables you to set up IAM in a way that users and accounts don’t carry the required roles and permissions all the time.

Accounts are ahead of time enabled to request a certain role. Once they want to use that role, just in time they put in a request to use that role and for how long and, depending on the configuration in PIM, that request can then be evaluated and granted or denied. The great thing is that Azure AD PIM also works for custom roles.

And example would be where a Threat Hunter would use a regular Azure AD account and then go to the PIM interface to request the SecOps investigator role to access all the required information in Azure Sentinel for his or her investigation.

More information on Azure AD PIM and how to set it up, can be found here.

PRO TIP: Azure AD PIM is a premium feature in Azure. You need either a Azure AD P2 license for the user that needs PIM functionality, or license it through an EM+S E5 or Microsoft 365 E5 license.

Monitoring PIM usage

Most enterprises and auditors will also require you to monitor that role usage. This can be easily done using the Azure AD audit logs. Make sure you enable the Azure Active Directory connector in Azure Sentinel so that the data type ‘AuditLogs’ is collected.

The PIM operations are stored in the AuditLogs table. You need to filter on the category for ‘ResourceManagement’ and operationname containing ‘PIM’. Here’s a base KQL query for hunting:

AuditLogs
| where Category == “ResourceManagement”
and OperationName contains “PIM”

You could use a similar query to create a rule to alert the SOC when that role is being used:

Conclusion

Using a combination of the new resource-context access mode for your Log Analytics workspace, custom Azure AD roles, and Privileged Identity Management, you can achieve most if not all of the requirements that your enterprise and auditors have for your Azure Sentinel deployment.

Happy hunting!

— Maarten Goet, MVP & RD

UPDATE: Oleg Ananiev, group program manager at Microsoft for Azure Log Analytics, adds the following remark:

“Resource-centric RBAC and table-level RBAC are orthogonal. In fact, you can use table-level RBAC for workspace queries, it does not require access control mode change for the workspace. This is especially important, as most Azure Sentinel users will likely be using workspace-centric access. Why? The prerequisite for using resource-centric access is that data must be tagged with a valid Azure resource id. This is typically not true for many types of security data, for example: Office 365.”