Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community
Azure Monitor: Manage Data Access for Your Log Analytics Workspace
Published Dec 12 2022 12:00 AM 5,856 Views
Microsoft

Gooooood morning readers :smile:

 

I am back with another important topic arising from my customers’ visits. How can I give very specific access to Log Analytics data, whether they be Security or Monitoring data?

 

Tricky one, isn’t it? A very simplistic answer could be: “manage your access list through IAM on the workspace”, but this is not enough. Say, for instance, that you would give scoped access to data coming from specific resources or, even more complicated, you would like that given the same resource one team can see some info and another one all the rest.

 

Looks complicated, but hey … good news: this is doable BrunoGabrielli_0-1670327281891.png

 

To understand how we can achieve this complicated goal, we need to explore how data access works in Log analytics. First of all, we need to bear in mind that data access is a combination of factors that fall under 2 main categories: Access and Permission. The picture below should anticipate the idea that we will be explained right after:

 

BrunoGabrielli_1-1670327338104.png

 

As you can see, on the left side there is Access Control Mode and Access Mode.

The first one, Access Control Mode, is a setting that controls which permission set will be used: the one defined at the workspace level (IAM on the workspace) or the one defined at the resource level (IAM on the resource sending data)

 

BrunoGabrielli_2-1670327338114.png

 

Using Require workspace permission will allow any configured user on the workspace to access all contained data with no restrictions. On the other hand, with Use resource or workspace permission user will access data based on the permission they have been granted on the resource. If the same user has been granted permissions at workspace level, these will be ignored.

Access Mode, instead, is a method that controls the scope of data to be accessed. We have 2 options here: accessing data from the Log Analytics workspace, which gives access to all the contained data, or accessing collected data from the resource emitting the data. In this case, the query scope will be automatically restricted to the logs created by the given resource and access will happen only on this data.

 

BrunoGabrielli_3-1670327338120.png

 

Now that we have clear in mind how data access can be configured and how it is evaluated, let’s look at scenarios which can clarify the real life:

Scenario #1: Full access to workspace data.

This is the simplest case. We will set the Access control mode to Workspace permission and configure the necessary RBAC on the workspace. In this case Log Analytics queries, Dashboard and workbook will work automatically with no additional effort for all the users who have been given at least reader permissions.

 

BrunoGabrielli_4-1670327338125.png

 

Running a query against on the Log Analytics workspace, the granted user will be able to see everything logged so far:

 

BrunoGabrielli_5-1670327338130.png

 

Scenario #2: Access to specific resource data.

Here is where the long explanation above applies. Pretending to have a situation where:

  • Operations User 1 needs to access only data produced by Windows virtual machines
  • Operations User 2 needs to access only data produced by Linux virtual machines

it will be enough granting:

  • Read permission to Operations User 1 to Windows VMs (or to the resource group hosting them)

 

BrunoGabrielli_6-1670327338135.png

 

  • Read permission to Operations User 2 to Linux VMs (or to the resource group hosting them)

 

BrunoGabrielli_7-1670327338139.png

 

Running the same above query from the Logs item in the vm-Demo01 (or 02) blade, the Windows-based virtual machines, being logged as Operations User 1 will only return the data scoped to that VM:

 

BrunoGabrielli_8-1670327338145.png

 

Running the same query from the workspace, always being logged as Operations User 1, will return data for both virtual machines we granted the user read access on:

 

BrunoGabrielli_9-1670327338151.png

 

The same goes for the Linux-based virtual machine accessing the data as Operations User 2

 

Scenario #3: Access to specific tables

There is also a third possible scenario which makes things a bit more complicated and requires the definition of a Table-Level RBAC through custom role(s). We might need to give Access to specific resource data in specific tables. To give you an idea, imagine the following:

  • Performance User 1 only needs access to VM Performance data
  • Networking User 1 only needs access to VM Connection data

regardless of the Operating System. The solution for this scenario is to create 2 different azure custom roles each with the necessary reader permission and configure these custom roles on the virtual machines (or resource group containing them). Custom roles can be created by following 2 approaches:

  1. Give access to specific table(s). This approach is preferred if you need to grant access to a few tables.
  2. Start with full access and enforce the necessary restrictions. This second approach is helpful when access needs to be granted to many table so it is easier to manage the restrictions.

For this scenario I went on creating custom roles through the Azure portal starting from the built-in Log Analytics Reader role and changing it accordingly. You can see a sample for the VM Performance data Reader:

 

BrunoGabrielli_10-1670327338157.png

 

 

NOTE: Pay attention to the Action section which contains, together with the first 2 permissions which are necessary to enumerate the workspace and to read and use built-in queries, a specific entry for the InsightsMetrics table.

 

 

and for the VM Connection Reader:

 

BrunoGabrielli_11-1670327338164.png

 

 

NOTE: Pay attention to the Action section which contains, together with the first two permissions which are necessary to enumerate the workspace and to read and use built-in queries, a specific entry for the VMConnection table

 

 

For both scenario #2 and #3, access to data will be granted based on the flow below:

 

BrunoGabrielli_12-1670327338175.png

 

Now that you have an idea on how to grant data access rights, how can you control who is really accessing data and which portion has been accessed? Luckily, Azure helps us in collecting the Audit data for our log analytics workspace(s). You only need to enable the capture using the Diagnostics Setting and configure the Audits to be sent to a workspace (it could be the same you are configuring or a different one)

 

BrunoGabrielli_13-1670327338181.png

 

Once the collection of audit logs is enabled, go to the Insights under the Monitoring section on the workspace blade, select the Query Audit tab to see data about query performance, Slow and Inefficient queries as well as the number of queries run by users.

 

BrunoGabrielli_14-1670327338187.png

 

But I know you :cool: … you think this is not enough. Here is why I am keeping the little cherry as last. Having audit data stored in a Log Analytics workspace we can always, as for any other data type, run our custom queries.

A very simple one that also shows the query text to better understand the research scope, is the following one:

 

 

LAQueryLogs
| top 10 by TimeGenerated desc
| project TimeGenerated, AADEmail, QueryText, RequestClientApp, ResponseRowCount

 

 

BrunoGabrielli_15-1670327450348.png

Hope that the long explanation and the scenario walkthrough will be of help :smile:

 

Disclaimer

The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.

2 Comments
Version history
Last update:
‎Nov 09 2023 03:28 PM
Updated by: