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.

Risky IP’s and Traffic Analytics

Risky IP feature of AAD Connect Health came to public preview in early May. With AAD Connect Health you can monitor sign-ins and send data to the cloud where it will be analyzed. Together with ADFS Extranet Lockout it helps to monitor and detect password brute force and spray attacks.

AAD Connect Health can be used for:

Installation guidance found from here

What’s Risky IPs in ADFS (docs.microsoft.com)

Additionally, it is possible for a single IP address to attempt multiple logins against multiple users. In these cases, the number of attempts per user may be under the threshold for account lockout protection in AD FS. Azure AD Connect Health now provides the “Risky IP report” that detects this condition and notifies administrators when this occurs. The following are the key benefits for this report:

  • Detection of IP addresses that exceed a threshold of failed password-based logins
  • Supports failed logins due to bad password or due to extranet lockout state
  • Email notification to alert administrators as soon as this occurs with customizable email settings
  • Customizable threshold settings that match with the security policy of an organization
  • Downloadable reports for offline analysis and integration with other systems via automation

Risky IPs in Action

As a pre-requirement I have configured on-premises Active Directory Domain account lockout policy and password policy to following values:

  • Account Lockout duration & Reset Account lockout counter after: 15min
  • Account Lockout threshold: 10

Extranet account lockout policy with following values:

  • ExtranetLockoutThreshold: 5
  • ExtranetObservationWindow: 30min

Command:

$Timespan = New-TimeSpan -Minutes 30
Set-AdfsProperties -EnableExtranetLockout $True -ExtranetLockoutThreshold 5 -ExtranetObservationWindow $Timespan

13

After pre-reguirements configuration it’s time to perform attack simulation against my ADFS instance. Trying to logon multiple times with my test account.

1

Because of ”Extranet Account Lockout” policy my test account stays active and is not locked out at on-premises AD. This policy defines that authentication requests are not sent after 5 attempts to the domain controller.

14

After short period of time I navigated to Azure AD portal and AAD Connect Health blade where my Risky IP’s were visible

4.1

I tried to find same IP from Azure Traffic Analytics as malicious traffic but was unable to do so. Either my queries were build wrongly or this kind of traffic is not visible from Network Analytics. If latter is the case it would be nice to see Risky IP traffic as malicious traffic in Traffic Analytics. Of course then assumption is that VMs needs to be located at Azure datacenters as I have in my environment.  15

What I found was all traffic I generated to random ports during test sessions.

16

After I frustrated myself with Traffic Analytics I tried to find my Risky IP from NSG Flow logs from storage accounts and it was successful.  This data was then imported to human readable format to  JSON editor.

10.PNG

Now the Risky IP has been identified, what’s next

  • It can be blocked at firewall
  • If we take another angle and look this from identity point of view, Trusted locations can be defined to Azure AD which helps to define Conditional Access policies when protecting identities