Роли, разрешения и безопасность в Azure Monitor

В этой статье показано, как применить контроль доступа на основе ролей (RBAC) для предоставления или ограничения доступа, и рассматриваются вопросы безопасности для ресурсов, связанных с Azure Monitor.

Встроенные роли мониторинга

Управление доступом на основе ролей Azure (Azure RBAC) предоставляет встроенные роли для мониторинга, которые можно назначать пользователям, группам, служебным субъектам и управляемым удостоверениям. Наиболее распространенными ролями являются Мониторинг Читатель и Мониторинг Участник для разрешений на чтение и запись соответственно. При назначении роли можно указать область назначения роли. Роли можно назначать на уровне подписки, группы ресурсов или ресурса. Чем шире охват, тем больше ресурсов покрывается назначением роли. Убедитесь, что роль назначается в соответствующей области, чтобы ограничить доступ только к ресурсам, к которым должен получить доступ пользователь.

Дополнительные сведения о ролях мониторинга см. в разделе "Роли мониторинга RBAC".

Monitoring Reader (Читатель данных мониторинга)

Пользователи, которым назначена роль Monitoring Reader, могут просматривать все данные мониторинга в подписке, но не могут изменять какие-либо ресурсы или параметры, связанные с ресурсами мониторинга. Эта роль подходит для тех пользователей в организации (например, инженеров службы поддержки или инженеров по операциям), которым необходимо выполнять следующие операции:

• Просмотр панелей мониторинга на портале Azure.
• Просмотр правил генерации оповещений, определенных в интерфейсе оповещений Azure.
• Запрашивайте метрики Azure Monitor с помощью REST API Azure Monitor, командлетов PowerShell или кроссплатформенного CLI.
• Можно запросить журнал активности через портал, REST API Azure Monitor, командлеты PowerShell или кроссплатформенный интерфейс командной строки.
• Просмотр параметров диагностики для ресурса.
• Просмотр профиля журнала для подписки.
• Просмотр параметров автомасштабирования.
• Просмотр активности и параметров оповещений.
• Выполните поиск данных в рабочей области Log Analytics, включая данные об использовании рабочей области.
• Получение схем таблиц в рабочей области Log Analytics.
• Получение и выполнение запросов журналов в рабочей области Log Analytics.
• Доступ к данным Application Insights.

Участник мониторинга

Пользователи, которым назначена роль Monitoring Contributor, могут просматривать все данные мониторинга в подписке и создавать или изменять параметры мониторинга, но не могут изменять какие-либо другие ресурсы.

Эта роль является надмножеством роли Monitoring Reader. и подходит для участников команды мониторинга в организации или поставщиков управляемых служб, которым, помимо приведенных выше разрешений, также необходимо иметь следующие возможности:

• Просмотр панелей мониторинга на портале и создание собственных частных панелей мониторинга.
• Создание и изменение параметров диагностики для ресурса. ¹
• Настройте действия и параметры правил оповещений с помощью Azure Alerts.
• Перечисление общих ключей для пространства Log Analytics.
• Создание и удаление сохраненных поисков в рабочей области Log Analytics.
• Создайте и удалите конфигурацию хранилища рабочей области Log Analytics.
• Создание веб-тестов и компонентов Application Insights.

¹ . Чтобы создать или изменить параметр диагностики, пользователям также необходимо отдельно предоставить разрешение ListKeys на целевой ресурс (учетную запись хранения или пространство имен концентратора событий).

Разрешения на мониторинг и настраиваемые роли Azure

Если встроенные роли не соответствуют потребностям вашей команды, можно создать пользовательскую роль Azure с подробными разрешениями.

Например, можно использовать детализированные разрешения для создания настраиваемой роли Azure для средства чтения журналов действий с помощью следующего скрипта PowerShell.

$role = Get-AzRoleDefinition "Reader"
$role.Id = $null
$role.Name = "Activity Log Reader"
$role.Description = "Can view activity logs."
$role.Actions.Clear()
$role.Actions.Add("Microsoft.Insights/eventtypes/*")
$role.AssignableScopes.Clear()
$role.AssignableScopes.Add("/subscriptions/mySubscription")
New-AzRoleDefinition -Role $role 

Назначение роли

Сведения о назначении роли см. в статье "Назначение ролей Azure с помощью Azure PowerShell".

Например, следующий скрипт PowerShell назначает роль указанному пользователю.

Замените <RoleId> идентификатором роли мониторинга RBAC, которую вы хотите назначить.

Замените <SubscriptionID>, <ResourceGroupName> и <UserPrincipalName> соответствующими значениями из своей среды.

# Define variables
$SubscriptionId = "<SubscriptionID>"
$ResourceGroupName = "<ResourceGroupName>"
$UserPrincipalName = "<UserPrincipalName>"  # The UPN of the user to whom you want to assign the role
$RoleId = "<RoleId>"  # The ID of the role

# Get the user object
$User = Get-AzADUser -UserPrincipalName $UserPrincipalName

# Define the scope (e.g., subscription or resource group level)
$Scope = "/subscriptions/$SubscriptionId/resourceGroups/$ResourceGroupName"

# Assign the role
New-AzRoleAssignment -ObjectId $User.Id -RoleDefinitionId $RoleId -Scope $Scope

Вы также можете назначить роли Azure через портал Azure.

Запрос PowerShell для определения членства в группах ролей

Это может быть полезно для создания списков пользователей, принадлежащих определенной роли. Чтобы помочь в создании этих типов списков, можно настроить следующие примеры запросов в соответствии с конкретными потребностями.

Запрос ролей администратора и участника по всей подписке

(Get-AzRoleAssignment -IncludeClassicAdministrators | Where-Object {$_.RoleDefinitionName -in @('ServiceAdministrator', 'CoAdministrator', 'Owner', 'Contributor') } | Select -ExpandProperty SignInName | Sort-Object -Unique) -Join ", "

Запрос в контексте конкретного ресурса Application Insights для владельцев и участников

$resourceGroup = "ResourceGroupName"
$resourceName = "AppInsightsName"
$resourceType = "microsoft.insights/components"
(Get-AzRoleAssignment -ResourceGroup $resourceGroup -ResourceType $resourceType -ResourceName $resourceName | Where-Object {$_.RoleDefinitionName -in @('Owner', 'Contributor') } | Select -ExpandProperty SignInName | Sort-Object -Unique) -Join ", "

Запрос в контексте конкретной группы ресурсов для владельцев и участников

$resourceGroup = "ResourceGroupName"
(Get-AzRoleAssignment -ResourceGroup $resourceGroup | Where-Object {$_.RoleDefinitionName -in @('Owner', 'Contributor') } | Select -ExpandProperty SignInName | Sort-Object -Unique) -Join ", "

Вопросы безопасности данных мониторинга

Данные в Azure Monitor можно отправлять в учетную запись хранения или передаваться в концентратор событий, оба из которых являются ресурсами Azure общего назначения. Создание, удаление и доступ к ресурсам общего назначения — это привилегированная операция, доступная только администратору. Так как эти данные могут содержать конфиденциальную информацию, например IP-адреса или имена пользователей, используйте следующие методики для мониторинга ресурсов, чтобы предотвратить неправильное использование:

• Используйте отдельную учетную запись хранения для данных мониторинга. Если необходимо разделить данные мониторинга на несколько учетных записей хранения, учетные записи хранения должны использоваться только для мониторинга данных. Если вы предоставляете общий доступ к учетным записям хранения для мониторинга и других типов данных, вы можете непреднамеренно предоставить доступ к другим данным организациям, которые должны получать доступ только к данным мониторинга. Например, организации, отличной от Майкрософт, для управления сведениями о безопасности и событиями, должны иметь доступ только к данным мониторинга.
• По этой же причине используйте отдельное пространство имен служебной шины или концентратора событий во всех параметрах диагностики.
• Ограничьте доступ к учетным записям хранения или концентраторам событий, связанным с мониторингом, держа их в отдельной группе ресурсов. Используйте область применения для ролей мониторинга, чтобы ограничить доступ только к этой группе ресурсов.
• Вы никогда не должны предоставлять разрешение ListKeys ни для учетных записей хранения, ни для центров событий на уровне подписки, если пользователю нужен доступ только к данным мониторинга. Вместо этого предоставьте пользователю эти разрешения в области применения ресурса или группы ресурсов (при наличии выделенной группы ресурсов мониторинга).

Ограничение доступа к учетным записям хранения, связанным с мониторингом

Когда пользователю или приложению требуется доступ к данным мониторинга в учетной записи хранения, создайте общий ключ доступа (SAS) для учетной записи хранения с данными мониторинга, предоставляющий доступ на чтение уровня службы к BLOB-хранилищу. В PowerShell учетная запись SAS может выглядеть как в следующем коде:

$context = New-AzStorageContext -ConnectionString "[connection string for your monitoring Storage Account]"
$token = New-AzStorageAccountSASToken -ResourceType Service -Service Blob -Permission "rl" -Context $context

Затем можно передать токен сущности, которой требуется считывать из этой учетной записи хранения. и она сможет получить список всех больших двоичных объектов в этой учетной записи хранения и считывать данные из них.

Кроме того, если необходимо управлять данным разрешением с помощью Azure RBAC, то вы можете предоставить сущности разрешение Microsoft.Storage/storageAccounts/listkeys/action для этой конкретной учетной записи хранения. Это разрешение необходимо для пользователей, которым необходимо задать параметр диагностики для отправки данных в учетную запись хранения. Например, можно создать описанную ниже настраиваемую роль Azure для пользователя или приложения, которому нужно только читать данные из одной учетной записи хранения.

$role = Get-AzRoleDefinition "Reader"
$role.Id = $null
$role.Name = "Monitoring Storage Account Reader"
$role.Description = "Can get the storage account keys for a monitoring storage account."
$role.Actions.Clear()
$role.Actions.Add("Microsoft.Storage/storageAccounts/listkeys/action")
$role.Actions.Add("Microsoft.Storage/storageAccounts/Read")
$role.AssignableScopes.Clear()
$role.AssignableScopes.Add("/subscriptions/mySubscription/resourceGroups/myResourceGroup/providers/Microsoft.Storage/storageAccounts/myMonitoringStorageAccount")
New-AzRoleDefinition -Role $role 

Ограничение доступа к концентраторам событий, связанным с мониторингом

Аналогичная схема используется и для концентраторов событий, но сначала необходимо создать выделенное правило авторизации прослушивания. Если вы хотите предоставить доступ приложению, которому требуется только прослушивать концентраторы событий, связанные с мониторингом, выполните следующее:

1. На портале создайте политику совместного доступа для концентраторов событий, которые были созданы для потоковой передачи данных мониторинга, с разрешениями только на прослушивание. Например, ее можно назвать "monitoringReadOnly". При возможности вы предоставите этот ключ непосредственно потребителю и пропустите следующий шаг.

2. Если потребитель должен получить ключ по запросу, предоставьте пользователю действие ListKeys для этого концентратора событий. Это также необходимо пользователям, которым необходимо настраивать параметры диагностики или профиль журнала для потоковой передачи данных в концентраторы событий. Например, можно создать правило Azure RBAC, как показано ниже.

   $role = Get-AzRoleDefinition "Reader"
   $role.Id = $null
   $role.Name = "Monitoring Event Hub Listener"
   $role.Description = "Can get the key to listen to an event hub streaming monitoring data."
   $role.Actions.Clear()
   $role.Actions.Add("Microsoft.EventHub/namespaces/authorizationrules/listkeys/action")
   $role.Actions.Add("Microsoft.EventHub/namespaces/Read")
   $role.AssignableScopes.Clear()
   $role.AssignableScopes.Add("/subscriptions/mySubscription/resourceGroups/myResourceGroup/providers/Microsoft.ServiceBus/namespaces/mySBNameSpace")
   New-AzRoleDefinition -Role $role 
   

Дальнейшие шаги

• Ознакомьтесь с информацией об Azure RBAC и разрешениях в Azure Resource Manager
• Прочитайте общие сведения о мониторинге в Azure