Использование ролей для управления доступом к ресурсам
Встроенные роли для ресурсов Azure (используется PowerShell)
Azure предоставляет несколько встроенных ролей для покрытия наиболее распространенных сценариев безопасности. Чтобы понять, как работают роли, рассмотрим три роли, которые применяются ко всем типам ресурсов.
- Владелец: имеет полный доступ ко всем ресурсам, включая право делегировать доступ другим пользователям.
- Участник: может создавать все типы ресурсов Azure и управлять ими, но не может предоставлять доступ другим пользователям.
- Читатель — может просматривать существующие ресурсы Azure.
Определения ролей
Каждая роль представляет собой набор свойств, определенных в файле нотации объектов JavaScript (JSON). Это определение роли включает Имя, Идентификатор и Описание. Оно также включает допустимые разрешения (Actions), запрещенные разрешения (NotActions) и область (например, доступ для чтения) для роли.
Для роли владельца это означает все действия, обозначенные звездочкой (*); отсутствие запрещенных действий; все области, обозначенные косой чертой (/).
Эти сведения можно получить с помощью командлета PowerShell Get-AzRoleDefinition Owner.
Get-AzRoleDefinition Owner
После выполнения кода должен отобразиться следующий результат:
Name : Owner
Id : 8e3af657-a8ff-443c-a75c-2fe8c4bcb635
IsCustom : False
Description : Lets you manage everything, including access to resources.
Actions : {*}
NotActions : {}
DataActions : {}
NotDataActions : {}
AssignableScopes : {/}
Попробуйте то же самое для ролей Участник и Читатель, чтобы увидеть разрешенные и запрещенные действия.
Изучение встроенных ролей
Теперь рассмотрим некоторые из других встроенных ролей.
Откройте портал Azure.
На домашней странице Azure выберите группы ресурсов в меню слева.
Выберите группу ресурсов. Появится панель группы ресурсов.
В левой области меню выберите Access control (IAM) (Элемент управления доступом (IAM)). Отобразится панель элемента управления доступом (IAM) для группы ресурсов.
Чтобы просмотреть список доступных ролей, во внутренней строке меню выберите вкладку Roles (Роли), как показано ниже.
Что такое определение роли?
Определение роли представляет собой коллекцию разрешений. Определение роли содержит список операций, которые может выполнять роль, например чтение, запись и удаление. В ней также перечисляются операции, которые нельзя выполнить, или операции, которые относятся к базовым данным.
Как описано ранее, определение роли имеет следующую структуру:
| Имя | Описание |
|---|---|
Id |
Уникальный идентификатор роли, назначенный Azure |
IsCustom |
Значение True, если пользовательская роль, значение False, если встроенная роль |
Description |
Читаемое описание роли |
Actions [] |
Разрешенные разрешения; * указывает все |
NotActions [] |
Запрещенные разрешения |
DataActions [] |
Конкретные допустимые разрешения, применяемые к данным, например Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read. |
NotDataActions [] |
Конкретные запрещенные разрешения, примененные к данным. |
AssignableScopes [] |
Области, в которых применяется эта роль; / указывает глобальный, но может достичь иерархического дерева |
Эта структура представлена в формате JSON при использовании в управлении доступом на основе ролей (RBAC) или из базового API. Например, здесь приведено определение роли Участник в формате JSON.
{
"Name": "Contributor",
"Id": "b24988ac-6180-42a0-ab88-20f7382dd24c",
"IsCustom": false,
"Description": "Lets you manage everything except access to resources.",
"Actions": [
"*"
],
"NotActions": [
"Microsoft.Authorization/*/Delete",
"Microsoft.Authorization/*/Write",
"Microsoft.Authorization/elevateAccess/Action"
],
"DataActions": [],
"NotDataActions": [],
"AssignableScopes": [
"/"
]
}
Actions и NotActions
Вы можете настроить свойства Actions и NotActions, чтобы предоставить и отклонить необходимые разрешения. Эти свойства всегда имеют формат {Company}.{ProviderName}/{resourceType}/{action}.
Например, ниже приведены действия для трех ролей, которые мы рассмотрели ранее:
| Встроенная роль | Действия | NotActions |
|---|---|---|
| Владелец (разрешить все действия) | * |
- |
| Участник (разрешить все действия, кроме записи или удаления назначений ролей) | * |
Microsoft.Authorization/*/Delete, Microsoft.Authorization/*/Write, Microsoft.Authorization/elevateAccess/Action |
| Читатель (разрешить все действия чтения) | */read |
- |
Операция подстановочного знака (*) в разделе Actions указывает, что участник, назначенный этой роли, может выполнять все действия; иными словами, эта роль может управлять всем, включая действия, определенные в будущем, по мере того, как Azure добавляет новые типы ресурсов. Для роли Читатель разрешается только действие read.
Операции, указанные в разделе NotActions, вычитаются из раздела Actions. Для роли Contributor (Участник)NotActions удаляет возможность управлять доступом к ресурсам, а также назначать доступ к ресурсам.
DataActions и NotDataActions
Операции с данными указаны в свойствах DataActions и NotDataActions. Можно указать операции данных отдельно от операций управления. За счет этого текущие назначения ролей с подстановочными знаками (*) не будут неожиданно получать доступ к данным. Ниже приведены некоторые операции с данными, в которых можно указать DataActions и NotDataActions:
- Чтение списка BLOB-объектов в контейнере.
- Запись BLOB-объекта хранилища в контейнер.
- Удаление сообщения из очереди.
Операции с данными DataActions можно добавлять только в свойства и NotDataActions свойства. Поставщики ресурсов определяют операции, которые являются операциями с данными, задавая для свойства isDataAction значение true. Роли, у которых нет операций с данными, могут опустить эти свойства из определения роли.
Эти действия работают точно так же, как их аналоги в области управления. Можно указать действия, которые нужно разрешить (или * для всех), а затем указать список конкретных действий для удаления в NotDataActions коллекции. Ниже приведены некоторые примеры. Полный список действий и действий с данными можно найти в документации по поставщику ресурсов:
| Операция с данными | Description |
|---|---|
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete |
Удаление данных большого двоичного объекта |
Microsoft.Compute/virtualMachines/login/action |
Вход в виртуальную машину в качестве обычного пользователя |
Microsoft.EventHub/namespaces/messages/send/action |
Отправка сообщений в концентратор событий |
Microsoft.Storage/storageAccounts/fileServices/fileshares/files/read |
Возврат файла или папки или вывод списка файлов и папок |
Microsoft.Storage/storageAccounts/queueServices/queues/messages/read |
Чтение сообщения в очереди |
Назначаемые области
Определения свойств Actions и NotActions недостаточно для полной реализации роли. Вам также необходимо правильно задать область действия роли.
Свойство роли AssignableScopes определяет области (подписки, группы ресурсов или ресурсы), в которых эта роль доступна для назначения. Вы можете разрешить использование пользовательской роли только в тех подписках или группах ресурсов, в которых она действительно нужна. В остальных подписках и группах ресурсов она просто не будет отображаться, чтобы не отвлекать пользователей.
Ниже приведено несколько примеров:
| По | Область использования |
|---|---|
| Ограничение подписки | "/subscriptions/{sub-id}" |
| Ограничение определенной группы ресурсов в определенной подписке | "/subscriptions/{sub-id}/resourceGroups/{rg-name}" |
| Ограничение определенного ресурса | "/subscriptions/{sub-id}/resourceGroups/{rg-name}/{resource-name}" |
| Сделать роль доступной для назначения в двух подписках | "/subscriptions/{sub-id}", "/subscriptions/{sub-id}" |
Создание ролей
Идентификатор Microsoft Entra поставляется со встроенными ролями, которые, скорее всего, охватывают 99% от того, что вы когда-либо хотите сделать. Если это возможно, предпочтительнее использовать встроенную роль. Но можно создавать пользовательские роли, если это необходимо.
Примечание.
Для создания пользовательской роли требуется идентификатор Microsoft Entra ID P1 или P2; Вы не можете создавать пользовательские роли на уровне "Бесплатный".
Вы можете создать новую роль с помощью нескольких механизмов:
портал Azure. Для создания настраиваемой роли можно использовать портал Azure, выбрав роли идентификатора Microsoft Entra ID>и администраторов.>
Azure PowerShell. Для определения новой роли можно использовать
New-AzRoleDefinitionкомандлет.API Azure Graph. Для программного создания новой роли можно использовать вызов REST к API Graph.
В этом разделе "Сводка" модуля содержится ссылка на документацию для всех трех подходов.