Роли, разрешения и безопасность в Azure Monitor
В этой статье показано, как применить роли мониторинга на основе ролей (RBAC) для предоставления или ограничения доступа, а также обсудить вопросы безопасности для ресурсов, связанных с Azure Monitor.
Built-in monitoring roles (Встроенные роли мониторинга)
Управление доступом на основе ролей Azure (Azure RBAC) предоставляет встроенные роли для мониторинга, которые можно назначать пользователям, группам, субъектам-службам и управляемым удостоверениям. Наиболее распространенными ролями являются читатель мониторинга и участник мониторинга для разрешений на чтение и запись соответственно.
Дополнительные сведения о ролях мониторинга см. в разделе "Роли мониторинга RBAC".
Monitoring Reader (Читатель данных мониторинга)
Пользователи, которым назначена роль Monitoring Reader, могут просматривать все данные мониторинга в подписке, но не могут изменять какие-либо ресурсы или параметры, связанные с ресурсами мониторинга. Эта роль подходит для тех пользователей в организации (например, инженеров службы поддержки или инженеров по операциям), которым необходимо выполнять следующие операции:
- Просмотр панелей мониторинга на портале Azure.
- Просмотр правил генерации оповещений, определенных в интерфейсе оповещений Azure.
- Запрос метрик Azure Monitor с помощью REST API Azure Monitor, командлетов PowerShell или кроссплатформенного интерфейса командной строки.
- Запрос журнала действий с помощью портала, REST API Azure Monitor, командлетов PowerShell или кроссплатформенного интерфейса командной строки.
- Просмотр параметров диагностики для ресурса.
- Просмотр профиля журнала для подписки.
- Просмотр параметров автомасштабирования.
- Просмотр действий и параметров оповещений.
- Поиск данных рабочей области Log Analytics, включая данные об использовании рабочей области.
- Получение схем таблиц в рабочей области Log Analytics.
- Получение и выполнение запросов журналов в рабочей области Log Analytics.
- Доступ к данным приложения Аналитика.
Примечание.
Эта роль не предоставляет доступ на чтение к данным журнала, переданным в потоковом режиме в концентратор событий или сохраненным в учетной записи хранения. Сведения о настройке доступа к этим ресурсам см. в разделе Вопросы безопасности данных мониторинга далее в этой статье.
Monitoring Contributor (Участник мониторинга)
Пользователи, которым назначена роль Monitoring Contributor, могут просматривать все данные мониторинга в подписке и создавать или изменять параметры мониторинга, но не могут изменять какие-либо другие ресурсы.
Эта роль включает в себя все разрешения роли Monitoring Reader и подходит для участников команды мониторинга в организации или поставщиков управляемых служб, которым, помимо приведенных выше разрешений, также необходимо иметь следующие возможности:
- Просмотр панелей мониторинга на портале и создание собственных частных панелей мониторинга.
- Создание и изменение параметров диагностики для ресурса. 1
- Задайте действие правила генерации оповещений и параметры с помощью оповещений Azure.
- Получение списка общих ключей для рабочей области Log Analytics.
- Создание и удаление сохраненных поисков в рабочей области Log Analytics.
- Создание и удаление конфигурации хранилища рабочей области Log Analytics.
- Создание веб-тестов и компонентов Application Insights.
1 . Чтобы создать или изменить параметр диагностики, пользователям также необходимо отдельно предоставить разрешение 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
Примечание.
Для доступа к оповещениям, параметрам диагностики и метрикам для ресурса пользователь должен иметь доступ на чтение к типу этого ресурса и его области применения. Создание параметра диагностики, отправляющего данные в учетную запись хранения или потоки в центры событий, требует от пользователя также разрешения ListKeys на целевом ресурсе.
Назначение роли
Примечание.
Мы рекомендуем использовать модуль Azure Az PowerShell для взаимодействия с Azure. Сведения о начале работы см. в статье "Установка Azure PowerShell". Дополнительные сведения см. в статье Перенос Azure PowerShell с AzureRM на Az.
Сведения о назначении роли см. в статье "Назначение ролей 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 для учетных записей хранения или центров событий в подписке область если пользователю требуется доступ только к данным мониторинга. Вместо этого предоставьте пользователю эти разрешения в области применения ресурса или группы ресурсов (при наличии выделенной группы ресурсов мониторинга).
Ограничение доступа к учетным записям хранения, связанным с мониторингом
Когда пользователю или приложению требуется доступ к данным мониторинга в учетной записи хранения, создайте подписанный URL-адрес (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 для этой конкретной учетной записи хранения. Это разрешение необходимо для пользователей, которым необходимо задать параметр диагностики для отправки данных в учетную запись хранения. Например, можно создать следующую настраиваемую роль RBAC для пользователя или приложения, которому требуется только считывать данные из одной учетной записи хранения.
$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
Предупреждение
Разрешение ListKeys позволяет пользователю получать список первичных и вторичных ключей учетной записи хранения. Эти ключи предоставляют пользователю все подписанные разрешения (таких как чтение, запись, создание и удаление больших двоичных объектов) для всех подписанных служб (больших двоичных объектов, очередей, таблиц, файлов) в данной учетной записи хранения. Рекомендуется при возможности использовать SAS учетной записи.
Ограничение доступа к концентраторам событий, связанным с мониторингом
Аналогичная схема используется и для концентраторов событий, но сначала необходимо создать выделенное правило авторизации прослушивания. Если вы хотите предоставить доступ приложению, которому требуется только прослушивать концентраторы событий, связанные с мониторингом, выполните следующее:
На портале создайте политику общего доступа для концентраторов событий, созданных для потоковой передачи данных мониторинга с утверждениями только прослушивания. Например, ее можно назвать "monitoringReadOnly". При возможности вы предоставите этот ключ непосредственно потребителю и пропустите следующий шаг.
Если потребитель должен получить ключ по запросу, предоставьте пользователю действие 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