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

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

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

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

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

Средство чтения мониторинга и участник мониторинга

Участник мониторинга — это супермножество средства чтения мониторинга. В следующей таблице сравниваются две роли на первый взгляд. Полный список возможностей см. в следующих разделах.

¹Предварительные требования ListKeys. Создание или изменение параметра диагностики, отправляющего данные в учетную запись хранения или потоки в концентратор событий, требует разрешения ListKeys для целевого ресурса (учетной записи хранения или пространства имен Центров событий) в дополнение к роли участника мониторинга. Предоставление ListKeys в области ресурсов или группы ресурсов никогда не в области подписки для пользователей, которым требуется только мониторинг доступа. Дополнительные сведения см. в разделе "Вопросы безопасности" для мониторинга данных.

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

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

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

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

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

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

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

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

Разрешения на мониторинг и настраиваемые роли 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/<SubscriptionId>")
New-AzRoleDefinition -Role $role 

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

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

Сведения о назначении роли см. в статье "Назначение ролей 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 для определения членства в группах ролей

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

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

Параметр -IncludeClassicAdministrators и классические ServiceAdministratorCoAdministrator роли являются устаревшими. Azure устаревших классических ролей администратора в августе 2024 года, поэтому этот запрос часто не возвращает никаких классических записей администратора. Он остается здесь только для сред, которые по-прежнему ссылаться на эти роли.

(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/<SubscriptionId>/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/<SubscriptionId>/resourceGroups/myResourceGroup/providers/Microsoft.EventHub/namespaces/myEventHubNamespace")
   New-AzRoleDefinition -Role $role 
   

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

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