Создание определения роли
Определение роли состоит из наборов разрешений, определенных в JSON-файле. Каждый набор разрешений имеет имя, например Actions или NotActions , описывающие разрешения. Ниже приведен ряд примеров наборов разрешений.
Разрешения Actions определяют, какие действия разрешены.
Разрешения NotActions определяют, какие действия запрещены.
Разрешения DataActions указывают, как можно изменять или использовать данные.
Разрешения AssignableScopes — это список областей, которым можно назначать определение роли.
На следующей схеме показаны сведения о роли участника в Azure RBAC.
Из разрешений Actions видно, что роль Участник имеет права на выполнение любых действий. Подстановочный знак в виде звездочки "*" означает "все". Разрешения NotActions ограничивают права, предоставляемые набором Actions, и запрещают три действия:
Authorization/*/Delete: удаление запрещено всем.Authorization/*/Write: создание и изменение запрещено всем.Authorization/elevateAccess/Action: повышение уровня или расширение области действия прав доступа запрещено всем.
Роль участника также имеет два разрешения, чтобы указать, как могут повлиять данные:
"NotDataActions": []: никаких конкретных действий не указано. Поэтому любые действия могут влиять на данные."AssignableScopes": ["/"]: роль может быть назначена любым областям, влияющим на данные.
Важные сведения об определениях ролей
Имейте в виду следующие особенности определений ролей:
В Azure RBAC имеются встроенные роли и наборы разрешений. Вы также можете создавать настраиваемые роли и разрешения.
Встроенная роль Владелец имеет наивысший уровень прав доступа в Azure.
Система исключает разрешения NotActions из разрешений Actions, чтобы определить действующие разрешения для роли.
Разрешения AssignableScopes для роли могут представлять собой группы управления, подписки, группы ресурсов или ресурсы.
Разрешения роли
Используйте разрешения Actions и NotActions в сочетании, чтобы предоставить каждой роли конкретные права. Разрешения Actions могут обеспечить ширину доступа, а разрешения NotActions могут сузить доступ.
В таблице ниже показано, как разрешения Actions и NotActions используются в определениях трех встроенных ролей: Владелец, Участник и Читатель. Разрешения доступа ролей сужаются в следующем порядке: Владелец, Участник, Читатель.
| Имя роли | Description | Разрешения Actions | Разрешения NotActions |
|---|---|---|---|
| Ответственное лицо | Предоставляет полный доступ для управления всеми ресурсами, включая возможность назначать роли в Azure RBAC. | * |
Н/Д |
| Участник | Предоставляет полный доступ для управления всеми ресурсами, но не позволяет назначать роли в системе управления доступом на основе ролей Azure (Azure RBAC), управлять назначениями в Azure Blueprints или предоставлять общий доступ к галереям изображений. | * |
- Microsoft.Authorization/*/Delete - Microsoft.Authorization/*/Write - Microsoft.Authorization/elevateAccess/Action |
| Читатель | Дает возможность просматривать все ресурсы, но не позволяет вносить изменения. | /*/read |
Н/Д |
Области ролей
Определив разрешения роли, используйте разрешения AssignableScopes, чтобы указать, где может назначаться роль. Рассмотрим несколько примеров.
Сделайте роль доступной для назначения в двух подписках:
"/subscriptions/c276fc76-9cd4-44c9-99a7-4fd71546436e", "/subscriptions/e91d47c4-76f3-4271-a796-21b4ecfe3624"Сделайте роль доступной для назначения только в группе сетевых ресурсов:
"/subscriptions/c276fc76-9cd4-44c9-99a7-4fd71546436e/resourceGroups/Network"Сделайте роль доступной для назначения любой запрашивающей стороне:
"/"
Факторы, которые следует учитывать при создании ролей
При создании определений ролей в Azure RBAC учитывайте следующие моменты:
Рассмотрите возможность использования встроенных ролей. Просмотрите список встроенных определений ролей в Azure RBAC. Существует более 100 предопределенных определений ролей для выбора, таких как владелец, оператор резервного копирования, участник веб-сайта и диспетчер безопасности SQL. Встроенные роли определены для нескольких категорий служб, задач и пользователей, в том числе "Общее", "Сеть", "Хранение", "Базы данных" и т. д.
Рассмотрите необходимость создания пользовательских определений. Определите собственные настраиваемые роли для определенных бизнес-сценариев в организации. Вы можете изменить разрешения встроенной роли в соответствии с требованиями вашей организации. Вы также можете создавать определения настраиваемых ролей с нуля.
Рассмотрите необходимость ограничения области доступа. Предоставляйте ролям минимальный уровень доступа, необходимый для выполнения рабочих обязанностей. Некоторым пользователям, таким как администраторы, требуется полный доступ к корпоративным ресурсам для обслуживания инфраструктуры. Другим пользователям в организации может требоваться доступ на запись к личному или командному ресурсу и доступ только для чтения к общим ресурсам компании.
Рассмотрите необходимость управления изменениями, вносимыми в данные. Определите данные или ресурсы, которые следует изменять только в определенных ситуациях, и примените строгий контроль доступа. Ограничьте доступ пользователей минимальными правами, необходимыми для выполнения работы. Грамотно спланированная стратегия управления доступом помогает поддерживать инфраструктуру в работоспособном состоянии и предотвращать проблемы с безопасностью.
Рассмотрите необходимость применения назначений запрета. Определите, нужно ли реализовать функцию запрета назначения. Запрет назначений, как и назначение ролей, привязывает набор запрещающих действий к пользователю, группе или субъекту-службе в определенной области с целью отказа в доступе. Запрещающие назначения блокируют выполнение определенных действий ресурсов Azure пользователями, даже если назначение роли предоставляет им доступ.