Действия по назначению роли Azure

Управление доступом на основе ролей Azure (Azure RBAC) — это система авторизации, используемая для управления доступом к ресурсам в Azure. Чтобы предоставить доступ, необходимо назначить роли пользователям, группам, служебным принципалам или управляемым удостоверениям в определенном контексте. В этой статье описываются высокоуровневые шаги по назначению ролей Azure с помощью портал Azure, Azure PowerShell, Azure CLI или REST API.

Шаг 1. Определение пользователей, которым требуется доступ

Сначала необходимо определить, кому нужен доступ. Роль можно назначить пользователю, группе, служебному принципалу или управляемому удостоверению. Его также называют субъектом безопасности.

• Пользователь — отдельный пользователь, имеющий профиль в идентификаторе Microsoft Entra. Роли можно также назначать пользователям в других арендаторах. Сведения о пользователях в других организациях см. в разделе Microsoft Entra B2B.
• Группа — набор пользователей, созданных в идентификаторе Microsoft Entra. При назначении роли группе все пользователи этой группы получают эту роль.
• Субъект-служба — это идентификатор безопасности, который используется приложениями или службами для доступа к определенным ресурсам Azure. Это что-то вроде удостоверения пользователя (имя пользователя и пароль или сертификат) для приложения.
• Управляемое удостоверение — это удостоверение в Microsoft Entra ID, которое автоматически администрируется Azure. Как правило, управляемые удостоверения используются при разработке облачных приложений. Эти удостоверения нужны для управления учетными данными, которые используются при проверке подлинности в службах Azure.

Шаг 2. Выбор подходящей роли

Разрешения объединяются в определение роли. Обычно это просто называют ролью. Вы можете выбрать из списка нескольких встроенных ролей. Если встроенные роли не соответствуют потребностям вашей организации, вы можете создать собственные пользовательские роли.

Роли упорядочены по ролям функций работы и ролям привилегированных администраторов.

Роли рабочих функций

Роли служебных функций позволяют управлять конкретными ресурсами Azure. Например, роль Участник виртуальных машин позволяет пользователю создавать виртуальные машины и управлять ими. Чтобы выбрать нужную роль рабочей функции, выполните следующие действия.

1. Для начала ознакомьтесь со статьей Встроенные роли Azure. Таблица в верхней части статьи является индексом для сведений, приведенных далее в этой статье.

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

3. Просмотрите роли, перечисленные для категории службы, и определите необходимые действия. Опять же, всегда начинайте с наиболее ограниченных ролей.

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

4. Если подходящая роль не найдена, можно создать пользовательскую роль.

Роли привилегированного администратора

Роли привилегированного администратора — это роли, предоставляющие привилегированный доступ администратора, например возможность управлять ресурсами Azure или назначать роли другим пользователям. Следующие роли считаются привилегированными и применяются ко всем типам ресурсов.

Рекомендации по использованию назначений ролей привилегированного администратора см. в рекомендациях по Azure RBAC. Дополнительные сведения см. в разделе "Определение роли привилегированного администратора".

Шаг 3. Определение необходимой области

Область — это набор ресурсов, к которым предоставляется доступ. В Azure область действия можно задать на четырех уровнях: группы управления, подписки, группы ресурсов и ресурса. Структура областей строится на отношениях "родитель-потомок". Каждый уровень иерархии делает область более конкретной. Вы можете назначать роли на любом из этих уровней области действия. Выбранный уровень определяет, насколько широка область применения роли. Нижние уровни наследуют разрешения ролей от более высоких уровней.

При назначении роли в родительской области дочерние области наследуют эти разрешения. Например:

• Если назначить роль Читатель пользователю в области действия группы управления, такой пользователь может читать все во всех подписках в группе управления.
• Если вы назначаете роль Billing Reader группе в области подписки, участники этой группы могут читать финансовые данные для каждой группы ресурсов и ресурса в подписке.
• Если вы назначаете роль Участник приложению в области группы ресурсов, оно может управлять ресурсами всех типов в этой группе ресурсов, но не в других группах ресурсов в подписке.

Рекомендуется предоставлять субъектам безопасности минимальные привилегии, необходимые для выполнения их работы. Старайтесь не назначать более широкие роли в более широких областях, даже если изначально это кажется более удобным. При ограничении ролей и областей вы ограничиваете ресурсы, которые подвержены риску, если субъект безопасности когда-либо будет скомпрометирован. Для получения дополнительной информации см. Понимание области применения.

Шаг 4. Проверьте ваши предварительные условия

Чтобы назначить роли, необходимо войти в систему с пользователем, которому назначена роль с разрешением на запись назначений ролей в заданной области, например, Администратор контроля доступа на основе ролей. Аналогично, чтобы удалить назначение ролей, необходимо иметь разрешение на удаление назначений ролей.

• Microsoft.Authorization/roleAssignments/write
• Microsoft.Authorization/roleAssignments/delete

Если у вашей учетной записи пользователя нет разрешения на назначение роли в подписке, появится сообщение об ошибке, что у вашей учетной записи нет авторизации для выполнения действия "Microsoft.Authorization/roleAssignments/write". В этом случае обратитесь к администраторам подписки, так как они могут назначить разрешения от вашего имени.

Если вы используете учетную запись службы для назначения ролей, может появиться сообщение об ошибке "Недостаточно привилегий для завершения операции". Вероятнее всего, эта ошибка возникает из-за того, что Azure пытается найти удостоверение назначаемого пользователя в Microsoft Entra ID, а учетная запись службы по умолчанию не может прочитать Microsoft Entra ID. В этом случае необходимо предоставить служебному принципалу разрешения на чтение данных в каталоге. Кроме того, если вы используете Azure CLI, вы можете создать назначение роли, используя идентификатор объекта назначаемого, чтобы пропустить проверку в Microsoft Entra. Дополнительные сведения см. в статье об устранении неполадок службы Azure RBAC.

Шаг 5: Назначьте роль

Узнав субъект безопасности, роль и область, вы сможете назначить роль. Назначать роли можно с помощью портала Azure, Azure PowerShell, Azure CLI, пакетов SDK Azure или REST API.

В каждой подписке может быть до 4000 назначений ролей. Это ограничение распространяется на назначения ролей в пределах подписки, группы ресурсов и областей ресурсов. Подходящие назначения ролей и запланированные на будущее назначения ролей не учитываются в этом пределе. В каждой группе управления можно назначить до 500 ролей. Дополнительные сведения см. в разделе "Устранение неполадок с ограничениями Azure RBAC".

Подробные инструкции по назначению ролей см. в следующих статьях.

• Назначение ролей Azure с помощью портала Azure
• Назначение ролей Azure с помощью Azure PowerShell
• Назначение ролей Azure с помощью Azure CLI
• Назначение ролей Azure с помощью REST API

Следующие шаги

• Руководство по предоставлению пользователям доступа к ресурсам Azure с помощью портала Azure