Роли, разрешения и безопасность в Azure Monitor
В этой статье показано, как быстро применить к пользователю в Azure встроенные роли для мониторинга или создать собственную настраиваемую роль для пользователя, которому нужен ограниченный набор разрешений для мониторинга. Далее в статье рассматриваются вопросы безопасности ресурсов, связанных с Azure Monitor, и способы ограничения доступа к данным, которые они содержат.
Built-in monitoring roles (Встроенные роли мониторинга)
Встроенные роли Azure Monitor помогают ограничить доступ к ресурсам в подписке, то же время позволяя сотрудникам, ответственным за мониторинг инфраструктуры, получать и настраивать необходимые данные. Azure Monitor предоставляет две готовые роли: Monitoring Reader и Monitoring Contributor. Журналы Azure Monitor также предоставляют встроенные роли для управления доступом к данным в рабочей области Log Analytics, как описано в статье "Управление доступом к рабочим областям Log Analytics".
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 с более тонко настраиваемыми разрешениями. Далее перечислены стандартные операции управления доступом на основе ролей (RBAC) Azure для Azure Monitor.
| Операция | Description |
|---|---|
| Microsoft.Insights/ActionGroups/[Read, Write, Delete] | Чтение, запись и удаление групп действий. |
| Microsoft.Insights/ActivityLogAlerts/[Read, Write, Delete] | Чтение, запись и удаление оповещений журнала действий. |
| Microsoft.Insights/AlertRules/[Read, Write, Delete] | Чтение, запись и удаление правил генерации оповещений (для классического интерфейса оповещений). |
| Microsoft.Insights/AlertRules/Incidents/Read | Вывод списка инцидентов (журнала активации правила генерации оповещений) для правила генерации оповещений. Это относится только к порталу. |
| Microsoft.Insights/AutoscaleSettings/[Read, Write, Delete] | Чтение, запись и удаление параметров автомасштабирования. |
| Microsoft.Insights/DiagnosticSettings/[Read, Write, Delete] | Чтение, запись и удаление параметров диагностики. |
| Microsoft.Insights/EventCategories/Read | Перечисление всех возможных категорий в журнале действий. Используется на портале Azure. |
| Microsoft.Insights/eventtypes/digestevents/Read | Это разрешение необходимо пользователям, которым требуется доступ к журналам действия на портале. |
| Microsoft.Insights/eventtypes/values/Read | Вывод списка событий журнала действий (событий управления) в подписке. Это разрешение применяется для доступа к журналу действий посредством кода или портала. |
| Microsoft.Insights/ExtendedDiagnosticSettings/[Read, Write, Delete] | Чтение, запись и удаление параметров диагностики для журналов сетевого потока. |
| Microsoft.Insights/LogDefinitions/Read | Это разрешение необходимо пользователям, которым требуется доступ к журналам действия на портале. |
| Microsoft.Insights/LogProfiles/[Read, Write, Delete] | Чтение, запись и удаление профилей журналов (потоковая передача журнала действий в концентратор событий или учетную запись хранения). |
| Microsoft.Insights/MetricAlerts/[Read, Write, Delete] | Чтение, запись или удаление правил генерации оповещений метрик. |
| Microsoft.Insights/MetricDefinitions/Read | Чтение определений метрик (вывод списка доступных типов метрик для ресурса). |
| Microsoft.Insights/Metrics/Read | Чтение метрик для ресурса. |
| Microsoft.Insights/Register/Action | Регистрация поставщика ресурсов Azure Monitor. |
| Microsoft.Insights/ScheduledQueryRules/[Read, Write, Delete] | Чтение, запись или удаление оповещений поиска по журналам в Azure Monitor. |
Примечание.
Для доступа к оповещениям, параметрам диагностики и метрикам для ресурса пользователь должен иметь доступ на чтение к типу этого ресурса и его области применения. Создание параметра диагностики, отправляющего данные в учетную запись хранения или потоки в центры событий, требует от пользователя также разрешения ListKeys на целевом ресурсе.
Например, можно использовать предыдущую таблицу для создания настраиваемой роли Azure для средства чтения журналов действий с помощью следующих элементов:
$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 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