Общие сведения о назначении ролей в Azure
Назначения ролей позволяют предоставить субъекту (например, пользователю, группе, управляемому удостоверению или субъекту-службе) доступ к конкретному ресурсу Azure. В этой статье описываются сведения о назначениях ролей.
Назначение ролей
Доступ к ресурсам Azure предоставляется путем создания назначения роли и отмены доступа путем удаления назначения ролей.
Назначение роли состоит из нескольких компонентов, в том числе:
- Субъект или которому назначена роль.
- Назначенная им роль.
- Область назначения роли.
- Имя назначения роли и описание, которое помогает объяснить, почему роль назначена.
Например, можно использовать Azure RBAC для назначения ролей, таких как:
- Пользователь Sally имеет доступ владельца к учетной записи хранения contoso123 в группе ресурсов ContosoStorage.
- У всех пользователей группы "Администраторы облака" в идентификаторе Microsoft Entra ID есть доступ читателя ко всем ресурсам в группе ресурсов ContosoStorage.
- Управляемое удостоверение, связанное с приложением, разрешено перезапускать виртуальные машины в подписке Contoso.
Ниже показан пример свойств назначения ролей при отображении с помощью Azure PowerShell:
{
"RoleAssignmentName": "00000000-0000-0000-0000-000000000000",
"RoleAssignmentId": "/subscriptions/11111111-1111-1111-1111-111111111111/providers/Microsoft.Authorization/roleAssignments/00000000-0000-0000-0000-000000000000",
"Scope": "/subscriptions/11111111-1111-1111-1111-111111111111",
"DisplayName": "User Name",
"SignInName": "user@contoso.com",
"RoleDefinitionName": "Contributor",
"RoleDefinitionId": "b24988ac-6180-42a0-ab88-20f7382dd24c",
"ObjectId": "22222222-2222-2222-2222-222222222222",
"ObjectType": "User",
"CanDelegate": false,
"Description": null,
"ConditionVersion": null,
"Condition": null
}
Ниже показан пример свойств назначения ролей при отображении с помощью Azure CLI или REST API:
{
"canDelegate": null,
"condition": null,
"conditionVersion": null,
"description": null,
"id": "/subscriptions/11111111-1111-1111-1111-111111111111/providers/Microsoft.Authorization/roleAssignments/00000000-0000-0000-0000-000000000000",
"name": "00000000-0000-0000-0000-000000000000",
"principalId": "22222222-2222-2222-2222-222222222222",
"principalName": "user@contoso.com",
"principalType": "User",
"roleDefinitionId": "/subscriptions/11111111-1111-1111-1111-111111111111/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c",
"roleDefinitionName": "Contributor",
"scope": "/subscriptions/11111111-1111-1111-1111-111111111111",
"type": "Microsoft.Authorization/roleAssignments"
}
В следующей таблице описывается, что означает свойства назначения ролей.
| Свойство | Description |
|---|---|
RoleAssignmentNamename |
Имя назначения роли, которое является глобально уникальным идентификатором (GUID). |
RoleAssignmentIdid |
Уникальный идентификатор назначения роли, который включает имя. |
Scopescope |
Идентификатор ресурса Azure, которому назначена роль. |
RoleDefinitionIdroleDefinitionId |
Уникальный идентификатор роли. |
RoleDefinitionNameroleDefinitionName |
Имя роли. |
ObjectIdprincipalId |
Идентификатор объекта Microsoft Entra для субъекта, которому назначена роль. |
ObjectTypeprincipalType |
Тип объекта Microsoft Entra, который представляет субъект. Допустимыми значениями являются User, Group и ServicePrincipal. |
DisplayName |
Для назначений ролей для пользователей отображаемое имя пользователя. |
SignInNameprincipalName |
Уникальное имя субъекта-пользователя или имя приложения, связанного с субъектом-службой. |
Descriptiondescription |
Описание назначения роли. |
Conditioncondition |
Оператор условия, созданный с помощью одного или нескольких действий из определения и атрибутов роли. |
ConditionVersionconditionVersion |
Номер версии условия. По умолчанию используется версия 2.0 и является единственной поддерживаемой версией. |
CanDelegatecanDelegate |
Не реализовано. |
Область
При создании назначения роли необходимо указать область применения. Область представляет ресурс или набор ресурсов, к которым разрешен доступ субъект. Можно ограничить назначение роли одним ресурсом, группой ресурсов, подпиской или группой управления.
Совет
Используйте наименьшую область, которую необходимо выполнить в соответствии с вашими требованиями.
Например, если нужно предоставить управляемому удостоверению доступ к одной учетной записи хранения, для обеспечения безопасности целесообразно создать назначение роли в области действия учетной записи хранения, а не группы ресурсов или подписки.
Дополнительные сведения об областях см. в статье Общие сведения об областях для Azure RBAC.
Роль для назначения
Назначение роли связано с определением роли. Определение роли указывает разрешения, которые субъект должен иметь в области назначения роли.
Можно назначить встроенное определение роли или пользовательское определение роли. При создании назначения ролей некоторые средства требуют использования идентификатора определения роли, а другие средства позволяют указать имя роли.
Дополнительные сведения об определениях ролей см. в разделе "Общие сведения о определениях ролей".
Субъект
Субъекты включают пользователей, группы безопасности, управляемые удостоверения, удостоверения рабочей нагрузки и субъекты-службы. Субъекты создаются и управляются в клиенте Microsoft Entra. Вы можете назначить роль любому субъекту. Используйте идентификатор объекта Идентификатора Microsoft Entra, чтобы определить субъект, которому требуется назначить роль.
При создании назначения ролей с помощью Azure PowerShell, Azure CLI, Bicep или другой инфраструктуры в качестве кода (IaC) укажите тип субъекта. К основным типам относятся User, Group и ServicePrincipal. Важно указать правильный тип субъекта. Иначе могут возникнуть ошибки, вызывающие прерывания в развертывании, особенно при работе с субъектами-службами и управляемыми экземплярами.
Имя.
Имя ресурса назначения роли должно быть глобально уникальным идентификатором (GUID).
Имена ресурсов назначения ролей должны быть уникальными в клиенте Microsoft Entra, даже если область назначения роли является более узкой.
Совет
При создании назначения ролей с помощью портал Azure, Azure PowerShell или Azure CLI процесс создания автоматически присваивает уникальное имя роли.
Если вы создаете назначение ролей с помощью Bicep или другой инфраструктуры в качестве кода (IaC), необходимо тщательно спланировать имя назначений ролей. Дополнительные сведения см. в статье "Создание ресурсов Azure RBAC с помощью Bicep".
Поведение при удалении ресурсов
При удалении пользователя, группы, субъекта-службы или управляемого удостоверения из идентификатора Microsoft Entra рекомендуется удалить все назначения ролей. Они не удаляются автоматически. Все назначения ролей, которые ссылаются на удаленный идентификатор участника, становятся недействительными.
При попытке повторно использовать имя назначения роли для другого назначения роли развертывание будет завершено ошибкой. Эта проблема, скорее всего, возникает при использовании Bicep или шаблона Azure Resource Manager (шаблона ARM) для развертывания назначений ролей, так как при использовании этих средств необходимо явно задать имя назначения ролей. Чтобы обойти это поведение, необходимо либо удалить старое назначение ролей, прежде чем повторно создать его, либо убедиться, что при развертывании нового назначения роли используется уникальное имя.
Description
Вы можете добавить текстовое описание в назначение роли. Хотя описания являются необязательными, рекомендуется добавить их в назначения ролей. Укажите краткое обоснование того, почему субъекту требуется назначенная роль. Когда кто-то выполняет аудит назначений ролей, описания могут помочь понять, почему они были созданы, и независимо от того, применяются ли они.
Условия
Некоторые роли поддерживают условия назначения ролей на основе атрибутов в контексте конкретных действий. Условие назначения роли — это дополнительная проверка, которую можно дополнительно добавить к назначению роли, чтобы обеспечить более детализированный контроль доступа.
Например, можно добавить условие, требующее наличия определенного тега для пользователя для чтения объекта.
Обычно вы создаете условия с помощью редактора визуальных условий, но вот как выглядит пример условия в коде:
((!(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read'} AND NOT SubOperationMatches{'Blob.List'})) OR (@resource[Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags:Project<$key_case_sensitive$>] StringEqualsIgnoreCase 'Cascade'))
Предыдущее условие позволяет пользователям считывать большие двоичные объекты с помощью ключа тега индекса BLOB-объектов Project и значения Каскада.
Дополнительные сведения об условиях см. в статье "Что такое управление доступом на основе атрибутов Azure( Azure ABAC)?
Интеграция с управление привилегированными пользователями (предварительная версия)
Внимание
Интеграция назначения ролей Azure с управление привилегированными пользователями сейчас доступна в предварительной версии. Юридические условия, применимые к функциям Azure, которые находятся в состоянии бета-версии, предварительной версии или иным образом еще не выпущены в общедоступной версии, см. на странице Дополнительные условия использования предварительных версий в Microsoft Azure.
Если у вас есть лицензия Microsoft Entra ID P2 или Управление идентификацией Microsoft Entra, Microsoft Entra управление привилегированными пользователями (PIM) интегрирована в шаги назначения ролей. Например, можно назначить роли пользователям в течение ограниченного периода времени. Вы также можете сделать пользователей подходящими для назначений ролей, чтобы они должны активировать эту роль, например утверждение запроса. Допустимые назначения ролей предоставляют JIT-доступ к роли в течение ограниченного периода времени. Невозможно создать подходящие назначения ролей для приложений, субъектов-служб или управляемых удостоверений, так как они не могут выполнить действия активации. Вы можете создавать соответствующие назначения ролей в группе управления, подписке и области группы ресурсов, но не в области ресурсов. Эта возможность развертывается на этапах, поэтому она может быть недоступна в клиенте или интерфейсе может выглядеть иначе.
Параметры типа назначения, доступные для вас, могут отличаться в зависимости от политики PIM. Например, политика PIM определяет, можно ли создавать постоянные назначения, максимальную длительность назначения с привязкой к времени, требования к активации ролей (утверждение, многофакторную проверку подлинности или контекст проверки подлинности условного доступа) и другие параметры. Дополнительные сведения см. в разделе "Настройка параметров роли ресурсов Azure" в управление привилегированными пользователями.
Если вы не хотите использовать функцию PIM, выберите тип активного назначения и параметры длительности постоянного назначения. Эти параметры создают назначение ролей, где субъект всегда имеет разрешения в роли.
Чтобы лучше понять PIM, ознакомьтесь со следующими условиями.
| Термин или понятие | Категория назначения ролей | Description |
|---|---|---|
| допустимое | Тип | Назначение роли, в соответствии с которым пользователь должен выполнить одно или несколько действий для использования роли. Назначение роли пользователю означает, что он может активировать роль, когда ему необходимо выполнить привилегированные задачи. Доступы, предоставленные пользователю с постоянной ролью и пользователю с временной ролью, ничем не отличаются. Единственное различие состоит в том, что второму типу пользователей доступ не требуется постоянно. |
| active | Тип | Назначение роли, которое не требует от пользователя выполнения каких-либо действий для ее использования. Пользователи, назначенные в качестве активных, имеют все полномочия, присвоенные роли. |
| активировать | Процесс выполнения одного или нескольких действий для использования роли, на которую имеет право пользователь. Действия могут включать выполнение проверки многофакторной проверки подлинности (MFA), предоставление бизнес-обоснования или запрос утверждения от назначенных утверждающих. | |
| постоянное допустимое | Duration | Назначение роли, где пользователь всегда имеет право активировать роль. |
| постоянное активное | Duration | Назначение роли, где пользователь всегда может использовать роль, не выполняя каких-либо действий. |
| допустимое ограничение по времени | Duration | Назначение роли, когда пользователь может активировать роль в только в период между указанными датами начала и окончания. |
| активное ограничение по времени | Duration | Назначение роли, когда пользователь может использовать роль в только в период между указанными датами начала и окончания. |
| JIT-доступ | Это модель, в которой пользователи получают временные разрешения для выполнения привилегированных задач, что не позволяет злоумышленникам или неавторизованным пользователям получить доступ по истечении срока действия разрешения. Доступ предоставляется только в том случае, если он необходим пользователю. | |
| Принцип доступа с минимальными привилегиями | Рекомендуемый метод обеспечения безопасности, когда каждому пользователю предоставляются только минимальные привилегии, необходимые для выполнения задач, которые ему разрешено выполнять. Такой подход позволяет свести к минимуму количество глобальных администраторов. Вместо этого используются определенные роли администратора для конкретных сценариев. |
Дополнительные сведения см. в разделе "Что такое Microsoft Entra управление привилегированными пользователями?".