Общие сведения об определениях ролей Azure

Чтобы составить представление о роли Azure или создать собственную настраиваемую роль Azure, полезно узнать, как определяются роли. В этой статье подробно описаны определения ролей и приведены примеры.

Определение роли

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

Ниже показан пример свойств в определении роли при отображении с помощью Azure PowerShell:

Name
Id
IsCustom
Description
Actions []
NotActions []
DataActions []
NotDataActions []
AssignableScopes []
Condition
ConditionVersion

Ниже показан пример свойств в определении роли при отображении с помощью Azure CLI или REST API:

roleName
name
id
roleType
type
description
actions []
notActions []
dataActions []
notDataActions []
assignableScopes []
condition
conditionVersion
createdOn
updatedOn
createdBy
updatedBy

В следующей таблице описано значение свойств роли.

Формат действий

Действия указываются со строками, имеющими следующий формат:

• {Company}.{ProviderName}/{resourceType}/{action}

Часть {action} строки действия указывает тип действий, которые можно выполнить в типе ресурса. Например, в {action} могут содержаться следующие подстроки:

Примеры определений роли

Ниже показано определение роли участника, отображаемое в Azure PowerShell и Azure CLI. Действия с использованием подстановочного знака (*) под Actions указывают, что главный, назначенный к этой роли, может выполнять все действия или, другими словами, управлять всем. Сюда входят и действия, определяемые в будущем (по мере добавления новых типов ресурсов в Azure). Действия под NotActions вычитаются из Actions. В случае роли Участника, NotActions удаляет возможность этой роли управлять доступом к ресурсам, а также управлять назначениями Azure Blueprints.

Роль участника, отображаемая в Azure PowerShell:

{
  "Name": "Contributor",
  "Id": "b24988ac-6180-42a0-ab88-20f7382dd24c",
  "IsCustom": false,
  "Description": "Grants full access to manage all resources, but does not allow you to assign roles in Azure RBAC, manage assignments in Azure Blueprints, or share image galleries.",
  "Actions": [
    "*"
  ],
  "NotActions": [
    "Microsoft.Authorization/*/Delete",
    "Microsoft.Authorization/*/Write",
    "Microsoft.Authorization/elevateAccess/Action",
    "Microsoft.Blueprint/blueprintAssignments/write",
    "Microsoft.Blueprint/blueprintAssignments/delete",
    "Microsoft.Compute/galleries/share/action",
    "Microsoft.Purview/consents/write",
    "Microsoft.Purview/consents/delete"
  ],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/"
  ],
  "Condition": null,
  "ConditionVersion": null
}

Роль участника, отображаемая в Azure CLI:

[
  {
    "assignableScopes": [
      "/"
    ],
    "createdBy": null,
    "createdOn": "2015-02-02T21:55:09.880642+00:00",
    "description": "Grants full access to manage all resources, but does not allow you to assign roles in Azure RBAC, manage assignments in Azure Blueprints, or share image galleries.",
    "id": "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c",
    "name": "b24988ac-6180-42a0-ab88-20f7382dd24c",
    "permissions": [
      {
        "actions": [
          "*"
        ],
        "condition": null,
        "conditionVersion": null,
        "dataActions": [],
        "notActions": [
          "Microsoft.Authorization/*/Delete",
          "Microsoft.Authorization/*/Write",
          "Microsoft.Authorization/elevateAccess/Action",
          "Microsoft.Blueprint/blueprintAssignments/write",
          "Microsoft.Blueprint/blueprintAssignments/delete",
          "Microsoft.Compute/galleries/share/action",
          "Microsoft.Purview/consents/write",
          "Microsoft.Purview/consents/delete"
        ],
        "notDataActions": []
      }
    ],
    "roleName": "Contributor",
    "roleType": "BuiltInRole",
    "type": "Microsoft.Authorization/roleDefinitions",
    "updatedBy": null,
    "updatedOn": "2023-07-10T15:10:53.947865+00:00"
  }
]

Действия управления и данных

Управление доступом на основе ролей для действий в плоскости управления указывается в свойствах Actions и NotActions определения роли. Ниже приведены некоторые примеры действий уровня управления в Azure:

• управление доступом к учетной записи хранения;
• Создание, обновление или удаление контейнера BLOB.
• удаление группы ресурсов со всеми ее ресурсами.

Доступ на уровне управления не наследуется к плоскости данных, если для метода проверки подлинности контейнера задана учетная запись пользователя Microsoft Entra, а не ключ доступа. Такое разделение предотвращает неограниченный доступ ролей с подстановочными знаками (*) к вашим данным. Например, если у пользователя в подписке есть роль Читатель, он может просматривать учетную запись хранения, но по умолчанию не имеет возможности просматривать базовые данные.

Ранее управление доступом на основе ролей не использовалось для действий с данными. Авторизация для действий с данными варьировалась в зависимости от поставщиков услуг ресурсов. Та же модель управления доступом на основе ролей (RBAC), используемая для действий уровня управления, была расширена до действий уровня данных.

Для поддержки действий уровня данных в определение роли добавлены новые свойства данных. Действия плоскости данных указываются в свойствах DataActions и NotDataActions. Добавляя эти свойства данных, сохраняется разделение между плоскостем управления и плоскостем данных. Это предотвращает внезапный доступ текущих назначений ролей с подстановочными знаками (*) к данным. Ниже приведены некоторые действия плоскости данных, которые можно указать в DataActions и NotDataActions:

• Чтение списка BLOB-объектов в контейнере.
• Записать BLOB в контейнер хранилища.
• Удаление сообщения из очереди.

Ниже представлено определение роли чтения данных BLOB-объектов хранилища, которое включает действия как в Actions, так и в DataActions свойствах. Эта роль позволяет считывать контейнер блобов, а также данные самих блобов.

Роль "Модуль чтения данных BLOB-объектов хранилища", отображаемая в Azure PowerShell:

{
  "Name": "Storage Blob Data Reader",
  "Id": "2a2b9908-6ea1-4ae2-8e65-a410df84e7d1",
  "IsCustom": false,
  "Description": "Allows for read access to Azure Storage blob containers and data",
  "Actions": [
    "Microsoft.Storage/storageAccounts/blobServices/containers/read",
    "Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey/action"
  ],
  "NotActions": [],
  "DataActions": [
    "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read"
  ],
  "NotDataActions": [],
  "AssignableScopes": [
    "/"
  ],
  "Condition": null,
  "ConditionVersion": null
}

Роль "Чтец данных в Blob-хранилище", отображаемая в Azure CLI:

[
  {
    "assignableScopes": [
      "/"
    ],
    "createdBy": null,
    "createdOn": "2017-12-21T00:01:24.797231+00:00",
    "description": "Allows for read access to Azure Storage blob containers and data",
    "id": "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/2a2b9908-6ea1-4ae2-8e65-a410df84e7d1",
    "name": "2a2b9908-6ea1-4ae2-8e65-a410df84e7d1",
    "permissions": [
      {
        "actions": [
          "Microsoft.Storage/storageAccounts/blobServices/containers/read",
          "Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey/action"
        ],
        "condition": null,
        "conditionVersion": null,
        "dataActions": [
          "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read"
        ],
        "notActions": [],
        "notDataActions": []
      }
    ],
    "roleName": "Storage Blob Data Reader",
    "roleType": "BuiltInRole",
    "type": "Microsoft.Authorization/roleDefinitions",
    "updatedBy": null,
    "updatedOn": "2021-11-11T20:13:55.297507+00:00"
  }
]

Только действия плоскости данных могут быть добавлены к свойствам DataActions и NotDataActions. Поставщики ресурсов определяют, какие действия являются действиями данных, установив значение свойства isDataAction на true. Список действий, в которых isDataAction находится true, см. в разделе "Операции поставщика ресурсов". Роли, для которых отсутствуют действия с данными, не обязаны иметь свойства DataActions и NotDataActions в определении роли.

Авторизация для всех вызовов API уровня управления обрабатывается Azure Resource Manager. Авторизация вызовов API плоскости данных обрабатывается поставщиком ресурсов или Azure Resource Manager.

Пример действий с данными

Чтобы лучше понять, как работают действия плоскости управления и плоскости данных, рассмотрим конкретный пример. Алисе назначена роль Владелец на уровне подписки. Бобу назначена роль Участник данных BLOB-объектов хранилища на уровне области учетной записи хранилища. Этот пример показан на схеме ниже.

Роли владельца для Алисы и участника Blob-хранилища данных для Боба имеют следующие действия:

Владелец

    Действия
    *

Автор данных хранилища BLOB-объектов

    Действия
    Microsoft.Storage/storageAccounts/blobServices/containers/delete
    Microsoft.Storage/storageAccounts/blobServices/containers/read
    Microsoft.Storage/storageAccounts/blobServices/containers/write
    Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey/action
    Действия с данными
    Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete
    Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
    Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
    Microsoft.Storage/storageAccounts/blobServices/containers/blobs/move/action
    Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action

Так как у Алисы есть универсальное действие (*) на уровне подписки, ее разрешения наследуются для выполнения всех действий на уровне управления. Алиса может выполнять чтение, запись и удаление контейнеров. Однако Алиса не может выполнять действия плоскости данных, не выполняя дополнительных действий. Например, по умолчанию Алиса не может читать блобы внутри контейнера. Чтобы выполнять чтение больших двоичных объектов, Алиса должна извлечь ключи доступа к хранилищу и использовать их для получения доступа к большим двоичным объектам.

Разрешения Боба ограничены только Actions и DataActions, указанными в роли Участник данных хранилища Blob. В зависимости от роли Боб может выполнять действия плоскости управления и плоскости данных. Например, Боб может читать, записывать и удалять контейнеры в указанном аккаунте хранилища, а также читать, записывать и удалять блобы.

Дополнительные сведения о безопасности контрольной и плоскости данных для хранилища см. в руководстве по безопасности Azure Storage.

Какие средства поддерживают использование ролей Azure для действий с данными?

Для просмотра и работы с действиями с данными необходимо иметь правильные версии средств или пакетов SDK:

Чтобы просмотреть и использовать действия данных в REST API, необходимо задать параметр версии API для следующей версии или более поздней:

• 01.07.2018

Действия

Разрешение Actions указывает действия уровня управления, которые позволяет выполнять роль. Это коллекция строк, которые определяют защищаемые действия поставщиков ресурсов Azure. Ниже приведены некоторые примеры действий плоскости управления, которые можно использовать в Actions.

NotActions

Разрешение NotActions указывает действия уровня управления, вычитаемые или исключенные из разрешенного Actions с подстановочным знаком (*). Используйте разрешение NotActions, если набор действий, которые вы хотите разрешить, проще определить, вычитая их из Actions, который содержит подстановочный знак (*). Доступ, предоставленный ролью (эффективные разрешения), вычисляется путем вычитания действий NotActions из действий Actions.

Actions - NotActions = Effective control plane permissions

В следующей таблице показаны два примера эффективных разрешений плоскости управления для действия подстановочного знака Microsoft.CostManagement :

Различия между NotActions и назначениями отказа

NotActions и назначения запрета не одинаковы и служат разным целям. NotActions являются удобным способом вычитания определенных действий из действия подстановочного знака (*).

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

Операции с данными

Разрешение DataActions указывает действия уровня данных, которые роль позволяет выполнять на ваших данных в этом объекте. Например, если у пользователя есть доступ на чтение объектов BLOB для учетной записи для хранения данных, он может считывать объекты BLOB в этой учетной записи. Ниже приведены некоторые примеры действий с данными, которые можно использовать в DataActions.

NotDataActions

Разрешение NotDataActions указывает действия плоскости данных, вычитаемые или исключенные из разрешенного DataActions с подстановочным знаком (*). Используйте разрешение NotDataActions, если набор действий, которые вы хотите разрешить, проще определить, вычитая их из DataActions, содержащих подстановочный знак (*). Доступ, предоставляемый ролью (эффективные разрешения), вычисляется путем вычитания действий NotDataActions из действий DataActions. Каждый поставщик ресурсов предоставляет соответствующий набор API для выполнения действий с данными.

DataActions - NotDataActions = Effective data plane permissions

В следующей таблице показаны два примера разрешений для плана даты действия подстановочного символа в Microsoft.Storage:

AssignableScopes

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

Например, если AssignableScopes назначено подпиской, это означает, что пользовательская роль доступна для назначения на уровне подписки для указанной подписки, на уровне группы ресурсов для любой группы ресурсов в подписке или на уровне ресурса для любого ресурса в подписке.

Для встроенных ролей в качестве AssignableScopes задана корневая область ("/"). Корневая область указывает, что роль доступна для назначения во всех областях.

Примеры допустимых назначаемых областей:

В AssignableScopes настраиваемой роли можно определить только одну группу управления.

Хотя можно создать пользовательскую роль с экземпляром ресурса с AssignableScopes помощью командной строки, не рекомендуется. Каждый клиент поддерживает не более 5 000 пользовательских ролей. Использование этой стратегии может потенциально исчерпать доступные пользовательские роли. В конечном счете уровень доступа определяется назначением настраиваемой роли (областью и разрешениями ролей и субъектом безопасности), а не AssignableScopes указанным в настраиваемой роли. Таким образом, создайте пользовательские роли с AssignableScopes группой управления, подпиской или группой ресурсов, но назначьте пользовательские роли с узкой областью, например ресурсом или группой ресурсов.

Дополнительные сведения о пользовательских ролях см. в AssignableScopes статье о пользовательских ролях Azure.

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

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

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

• Понимание назначений ролей
• Встроенные роли Azure
• Настраиваемые роли Azure
• Операции с поставщиками ресурсов Azure