Log Analytic Workspace - Permissions in Enterprise

Question

We are in the process of planning our RBAC for a new Azure environment within an Enterprise scale organisation. I'm trying to determine how we best provide access to logs. Within the non-production environments, it seems that the resource-context workspace permissions will do everything we require. The developers who have read permission on their resources will also have the necessary rights to see the logs - all is good! Within our production environment, the support team will have read access to resources but as the logs could contain sensitive information, access should be by exception. We'd like to control access to production logs via PIM. Can anyone offer some insight into how we can deliver this? I think that because we don't want the 'read' access to deliver access to production logs, we need to run the production environment with workspace-context permissions. By doing so, we'd then need to create roles for each of the resource types - so that a PIM role could only see the logs for that particular resource type e.g. Storage account log viewer My concern with that approach is that when we are operating a central log analytic workspace, it would enable the person with the PIM role to see ALL storage account logs - rather than restrict the access to a single resource. It would be good to understand if there is a better way in which to design this?

Answer 1

@a8ree1 The granular restriction with different workspace is usually better approach in sense of giving limited access to various users on basis of different workspaces. However, in your case for a central workspace for Log analytics you can definitely try with custom roles.

To grant a user access to log data from their resources without being able to read security events and send data, perform the following:

Configure the workspace access control mode to use workspace or resource permissions

Grant users the following permissions to their resources: Microsoft.Insights/logs/*/read.

Add the following NonAction to block users from reading the SecurityEvent type:
Microsoft.Insights/logs/SecurityEvent/read.
The NonAction shall be in the same custom role as the action that provides the read permission (Microsoft.Insights/logs/*/read). If the user inherent the read action from another role that is assigned to this resource or to the subscription or resource group, they would be able to read all log types. This is also true if they inherit */read, that exist for example, with the Reader or Contributor role.

Read more about the custom roles scenarios and implementations here

-----------------------------------------------------------------------------------------------------------------

If the suggested response helped you resolve your issue, please do not forget to accept the response as Answer and "Up-Vote" for the answer that helped you for benefit of the community.