Azure Log Analytics – Permission Models

This blog post is all about Log Analytics workspace (later referred as LA) permission models which changed at May 2019. The options (at time of writing) for granting permissions are:

  • Grant access using Azure role-based access control (RBAC).
  • Grant access to the workspace using workspace permissions.
  • Grant access using a specific table in the workspace using Azure RBAC.

These new options gives more granular controls for granting permission to Log Analytics workspaces instead of old model. Anyway, I see still place for granting workspace permissions. It comes back to Log Analytics’ workspace design and organization needs. How operating teams, development teams, and security organization needs to access the performance and security-related events.

There are basically two approaches for Log Analytics design:

  • Centralized
  • Siloed

If you have chosen the centralized model then more granularity access controls might be needed and you can leverage more about new access control modes table (Resource centric RBAC & Table level RBAC).

Access control mode

The new access model is automatically configured to all workspaces created after March 2019.

How to check which access model is in use?

Navigate to Azure Log Analytics and overview page where you can find ”access control mode” options for the workspace.

  • If you are using legacy model ”Access Control mode = require workspace permissions”
  • If new model is in place ”Access Control mode = Use resource or workspace permissions”

With PowerShell

  • If output is true – Log Analytics is using new access model
  • If output is false or null – Log Analytics is using legacy model
Get-AzResource -ResourceType Microsoft.OperationalInsights/workspaces -ExpandProperties | foreach {$_.Name + ": " + $_.Properties.features.enableLogAccessUsingOnlyResourcePermissions}

How to change access model?

Access model can be changed directory from resource properties and verified from Activity log.

If Powershell is the favorite tool for changes here you go (code from docs.microsoft.com)

$WSName = "my-workspace"
$Workspace = Get-AzResource -Name $WSName -ExpandProperties
if ($Workspace.Properties.features.enableLogAccessUsingOnlyResourcePermissions -eq $null)
    { $Workspace.Properties.features | Add-Member enableLogAccessUsingOnlyResourcePermissions $true -Force }
else
    { $Workspace.Properties.features.enableLogAccessUsingOnlyResourcePermissions = $true }
Set-AzResource -ResourceId $Workspace.ResourceId -Properties $Workspace.Properties -Force

New Model In Action

The scenario

Siloed Log Analytics workspace design is in use and operational team members needs to maintain Virtual Machines. In practical person needs to read Virtual Machine metrics and performance data from LA.

If new access model is in use members of the team can access the needed logs directly from the resource blade. They cannot see the LA at all because they don’t have global read access to the resource. If user browses to Azure Monitor the user can see logs he/she has access to.

When log search is opened from a resource menu, the search is automatically scoped to that resource and resource-centric queries are used. This means that if users have access to a resource, they’ll be able to access their logs.

Built-in Roles (from docs.microsoft.com)

Azure has two built-in user roles for Log Analytics workspaces:

  • Log Analytics Reader
  • 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.

Nothing prevents from using built-in roles but keep in mind that these are top level permissions. If user has Log Analytics reader permission 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.

Table Level Access

More granular controls can be achieved with Table level access in case its needed. If centralized Log Analytics model is chosen scenario it might be necessary to grant permissions to different teams to read data from LA tables. This can be achieved with Table level RBAC permissions.

With table level RBAC you can grant permissions only to needed LA tables depending on your needs.

Considerations

If a user has global read permission (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 has access to specific LA table but no other permissions, they would be able to access log data through the API but not from the Azure portal.

Summary

Most cases I have worked with, multi-homing Log Analytics design has been used and workspace centric model is enough to satisfy the needs. If centralized model (as few LA’s as possible) would be in use new access model gives more granularity.

Enable Microsoft Security Graph Alerts in Log Analytics

While its not yet configurable in GUI, you can already today configure (with proper prerequisites) the preview for Security Graph API and Log Analytics Integration.

Side note: Similar Integration can be done for Event Hub, and its recommended while enabling LA integration to enable EH integration (if EH exists in tenant)
https://docs.microsoft.com/en-us/graph/security-qradar-siemintegration

While its not yet configurable in GUI, you can already today configure (with proper prerequisites) the preview for Security Graph API and Log Analytics Integration.

Alerts today include  (Check link for original reference)

https://docs.microsoft.com/en-us/graph/api/resources/security-api-overview?view=graph-rest-1.0

I will avoid using the word Azure Monitor here, as this integration is not really in my opinion tapping into any resource API in the Azure Monitor (unless you consider Azure Monitor as umbrella term

AAD Identity Protection Alert
Same alert in Log Analytics
The target in event hub ( I will do separate blog about ELK integration)

integration includes also Event Hub – which has been available for a good while already via similar method

Before proceeding: As always – read the disclaimer in the bottom of the page) I put the disclaimer up also here to emphasize its matter, not just as an escape clause

How To: integration with Log Analytics

  • Disclaimer: The behavior may vary per tenant
  • It took few hours till events started popping up in Log Analytics and event hub
  • To enable the integration You can use existing AAD tokens in cache to achieve this
    • I’ve usually preffered the ADAL libraries to do this bit more simply, but in this case we want to use the AzureRM module to populate parts of the script simply (/done similarly here)


Login-AzureRmAccount
$ctx =Get-AzureRmContext
Get-AzureRmSubscription | Out-GridView -PassThru |Set-AzureRmContext

$rmEndpoint ="https://management.azure.com/providers/Microsoft.SecurityGraph/diagnosticSettings/securityApiAlerts?api-version=2017-04-01-preview"

#Details from IAM API
$Token = Invoke-RestMethod "https://login.windows.net/common/oauth2/token" -Method POST -Body @{
   grant_type="refresh_token"
   refresh_token = ($ctx.TokenCache.ReadItems() | Out-GridView -PassThru ).refreshToken
   content_type = "application/json"
   resource="https://management.core.windows.net/"
}

$json = '
{
  "location": "",
  "properties": {
      "workspaceId": null,
    "name": "securityApiAlerts",
    "serviceBusRuleId": "/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.EventHub/namespaces/EVENT_HUB_NAMESPACE/authorizationrules/RootManageSharedAccessKey",
    "logs": [
      {
        "category": "Alert",
        "enabled": true,
        "retentionPolicy": {
          "enabled": true,
          "days": 7
        }
      }
    ]
  }
}
' | ConvertFrom-Json 

$json.properties.serviceBusRuleId = ( (Get-AzureRmResource | where {$_.ResourceType -match "Eventhub"}| Out-GridView -PassThru).resourceID  + "/authorizationrules/RootManageSharedAccessKey")

$json.properties.workspaceId = ((Get-AzureRmOperationalInsightsWorkspace | Out-GridView -PassThru ).resourceID)

$data = Invoke-RestMethod -Uri $rmEndpoint -Method Put -Body ($json | ConvertTo-Json -Depth 4) -UseBasicParsing -Headers @{
Authorization = ($Token.token_type) +" "+ ($Token.access_token)
} -ContentType "application/json; charset=utf-8"



Comment from @samilamppu

its quite likely, that you need to have Security Center Standard with proper event coverage enabled, to get the Node for security alerts under LA

Br,

Joosua