Настраиваемые роли Azure

Если встроенные роли Azure не соответствуют потребностям вашей организации, вы можете создать собственные настраиваемые роли. Как и встроенные роли, ваши пользовательские роли можно назначать пользователям, группам и субъектам-службам на уровне группы управления, подписки и группы ресурсов.

Пользовательские роли можно совместно использовать между подписками, которые доверяют одному клиенту Microsoft Entra. Существует ограничение в 5 000 пользовательских ролей для каждого клиента. (Для Microsoft Azure, управляемой 21Vianet, ограничение составляет 2000 пользовательских ролей.) Пользовательские роли можно создавать с помощью портал Azure, Azure PowerShell, Azure CLI или REST API.

Процедура создания пользовательской роли

Ниже представлены основные шаги создания настраиваемой роли.

1. Определите нужные разрешения.

   При создании настраиваемой роли необходимо знать действия, доступные для определения разрешений. В общем случае вы начинаете с существующей встроенной роли и видоизменяете ее под свои потребности. Вы добавите действия в Actions определение роли или NotActions свойства. Если у вас есть действия с данными DataActions , вы добавите их в свойства или NotDataActions свойства.

   Дополнительные сведения см. в следующем разделе — Определение нужных разрешений.

2. Выберите способ создания настраиваемой роли.

   Настраиваемые роли можно создать с помощью портала Azure, Azure PowerShell, Azure CLI или REST API.

3. Создайте настраиваемую роль.

   Проще всего сделать это на портале Azure. Инструкции по созданию настраиваемой роли с помощью портала Azure см. в статье Создание или изменение настраиваемых ролей Azure с помощью портала Azure.

4. Проверьте настраиваемую роль.

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

Определение нужных разрешений

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

• Просмотрите существующие встроенные роли.

  Может понадобиться изменить существующую роль или объединить разрешения, используемые в нескольких ролях.

• Составьте список служб Azure, к которым нужно предоставить доступ.

• Определите поставщики ресурсов, сопоставляемые со службами Azure.

  Службы Azure предоставляют свои функции и разрешения с помощью поставщиков ресурсов. Например, поставщик ресурсов Microsoft.Compute предоставляет ресурсы виртуальной машины, а поставщик ресурсов Microsoft.Billing предоставляет ресурсы подписки и выставления счетов. Знание поставщиков ресурсов поможет сузить и определить разрешения, нужные для настраиваемой роли.

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

  

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

  При создании настраиваемой роли с помощью портала Azure можно выполнять поиск разрешений по ключевому слову. Например, можно выполнить поиск разрешений длявиртуальной машины или выставления счетов. Можно также скачать все разрешения в виде CSV-файла, а затем выполнить поиск в этом файле. Эта функция поиска описана в статье Создание или изменение настраиваемых ролей Azure с помощью портала Azure.

  

Пример пользовательской роли

Ниже показано, как выглядит настраиваемая роль, отображаемая в формате JSON с помощью Azure PowerShell. Эта пользовательская роль позволяет выполнять мониторинг и перезапуск виртуальных машин.

{
  "Name": "Virtual Machine Operator",
  "Id": "88888888-8888-8888-8888-888888888888",
  "IsCustom": true,
  "Description": "Can monitor and restart virtual machines.",
  "Actions": [
    "Microsoft.Storage/*/read",
    "Microsoft.Network/*/read",
    "Microsoft.Compute/*/read",
    "Microsoft.Compute/virtualMachines/start/action",
    "Microsoft.Compute/virtualMachines/restart/action",
    "Microsoft.Authorization/*/read",
    "Microsoft.ResourceHealth/availabilityStatuses/read",
    "Microsoft.Resources/subscriptions/resourceGroups/read",
    "Microsoft.Insights/alertRules/*",
    "Microsoft.Insights/diagnosticSettings/*",
    "Microsoft.Support/*"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/{subscriptionId1}",
    "/subscriptions/{subscriptionId2}",
    "/providers/Microsoft.Management/managementGroups/{groupId1}"
  ]
}

Ниже показано, как отображается эта же роль с помощью Azure CLI.

[
  {
    "assignableScopes": [
      "/subscriptions/{subscriptionId1}",
      "/subscriptions/{subscriptionId2}",
      "/providers/Microsoft.Management/managementGroups/{groupId1}"
    ],
    "description": "Can monitor and restart virtual machines.",
    "id": "/subscriptions/{subscriptionId1}/providers/Microsoft.Authorization/roleDefinitions/88888888-8888-8888-8888-888888888888",
    "name": "88888888-8888-8888-8888-888888888888",
    "permissions": [
      {
        "actions": [
          "Microsoft.Storage/*/read",
          "Microsoft.Network/*/read",
          "Microsoft.Compute/*/read",
          "Microsoft.Compute/virtualMachines/start/action",
          "Microsoft.Compute/virtualMachines/restart/action",
          "Microsoft.Authorization/*/read",
          "Microsoft.ResourceHealth/availabilityStatuses/read",
          "Microsoft.Resources/subscriptions/resourceGroups/read",
          "Microsoft.Insights/alertRules/*",
          "Microsoft.Insights/diagnosticSettings/*",
          "Microsoft.Support/*"
        ],
        "dataActions": [],
        "notActions": [],
        "notDataActions": []
      }
    ],
    "roleName": "Virtual Machine Operator",
    "roleType": "CustomRole",
    "type": "Microsoft.Authorization/roleDefinitions"
  }
]

Свойства пользовательской роли

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

Строки разрешений не учитывают регистр. При создании пользовательских ролей разрешения рекомендуется указывать так, как они приводятся в статье Операции с поставщиками ресурсов Azure.

Разрешения с подстановочными знаками

Actions, NotActions, DataActions и NotDataActions поддерживают подстановочные знаки (*) для определения разрешений. Подстановочный знак (*) расширяет действие разрешения на все, что соответствует введенной строке действий. Пусть, например, решено добавить все разрешения, связанные с Управлением затратами Azure и экспортом. Можно добавить все следующие строки действий.

Microsoft.CostManagement/exports/action
Microsoft.CostManagement/exports/read
Microsoft.CostManagement/exports/write
Microsoft.CostManagement/exports/delete
Microsoft.CostManagement/exports/run/action

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

Microsoft.CostManagement/exports/*

Кто может создавать, удалять, обновлять или просматривать пользовательскую роль

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

Поиск назначений ролей для удаления настраиваемой роли

Прежде чем удалить пользовательскую роль, необходимо удалить все назначения ролей, которые используют пользовательскую роль. При попытке удалить пользовательскую роль с назначениями ролей вы получите следующее сообщение: There are existing role assignments referencing role (code: RoleDefinitionHasAssignments)

Ниже приведены инструкции по поиску назначений ролей перед удалением настраиваемой роли:

• Перечисление определения настраиваемой роли.
• В разделе AssignableScopes получите группы управления, подписки и группы ресурсов.
• Переключите и перечислите AssignableScopes назначения ролей.
• Удалите назначения ролей, которые используют пользовательскую роль.
• Если вы используете microsoft Entra управление привилегированными пользователями, удалите соответствующие настраиваемые назначения ролей.
• Удалите пользовательскую роль.

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

Ограничения настраиваемых ролей

В следующем списке описаны ограничения для настраиваемых ролей.

• Каждый клиент может иметь до 5000 пользовательских ролей.
• Microsoft Azure, управляемый 21Vianet, может иметь до 2000 пользовательских ролей для каждого клиента.
• Нельзя задать AssignableScopes в качестве корневой области ("/").
• В AssignableScopes нельзя использовать подстановочные знаки (*). Это ограничение на применение подстановочных знаков позволяет гарантировать, что пользователь не сможет получить доступ к области, изменив определение роли.
• В строке действия можно использовать только один подстановочный знак.
• В AssignableScopes настраиваемой роли можно определить только одну группу управления.
• Azure Resource Manager не проверяет существование группы управления в определении AssignableScopesроли.
• Настраиваемые роли с DataActions нельзя назначить в области группы управления.
• Вы можете создать настраиваемую роль с DataActions одной группой управления и в AssignableScopesней. Вы не можете назначить пользовательскую роль в самой области группы управления; однако можно назначить пользовательскую роль в области подписок в группе управления. Это может быть полезно, если необходимо создать одну настраиваемую роль с DataActions помощью нескольких подписок, а не создавать отдельную пользовательскую роль для каждой подписки.

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

Форматы входных и выходных данных

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

Azure PowerShell

Чтобы создать настраиваемую роль с помощью Azure PowerShell, необходимо указать следующие входные данные.

{
  "Name": "",
  "Description": "",
  "Actions": [],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": []
}

Чтобы изменить настраиваемую роль с помощью Azure PowerShell, необходимо указать следующие входные данные. Обратите внимание, что было добавлено свойство Id.

{
  "Name": "",
  "Id": "",
  "Description": "",
  "Actions": [],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": []
}

Ниже приведен пример выходных данных при перечислении настраиваемой роли с помощью Azure PowerShell и команды ConvertTo-JSON.

{
  "Name": "",
  "Id": "",
  "IsCustom": true,
  "Description": "",
  "Actions": [],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": []
}

Azure CLI

Чтобы создать или изменить настраиваемую роль с помощью Azure CLI, необходимо указать следующие входные данные. Этот формат совпадает с форматом, используемым при создании настраиваемой роли с помощью Azure PowerShell.

{
  "Name": "",
  "Description": "",
  "Actions": [],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": []
}

Ниже приведен пример выходных данных при перечислении настраиваемой роли с помощью Azure CLI.

[
  {
    "assignableScopes": [],
    "description": "",
    "id": "",
    "name": "",
    "permissions": [
      {
        "actions": [],
        "dataActions": [],
        "notActions": [],
        "notDataActions": []
      }
    ],
    "roleName": "",
    "roleType": "CustomRole",
    "type": "Microsoft.Authorization/roleDefinitions"
  }
]

REST API

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

{
  "properties": {
    "roleName": "",
    "description": "",
    "assignableScopes": [],
    "permissions": [
      {
        "actions": [],
        "notActions": [],
        "dataActions": [],
        "notDataActions": []
      }
    ]
  }
}

Ниже приведен пример выходных данных при перечислении настраиваемой роли с помощью REST API.

{
    "properties": {
        "roleName": "",
        "type": "CustomRole",
        "description": "",
        "assignableScopes": [],
        "permissions": [
            {
                "actions": [],
                "notActions": [],
                "dataActions": [],
                "notDataActions": []
            }
        ],
        "createdOn": "",
        "updatedOn": "",
        "createdBy": "",
        "updatedBy": ""
    },
    "id": "",
    "type": "Microsoft.Authorization/roleDefinitions",
    "name": ""
}

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

• Руководство. Создание настраиваемой роли Azure с помощью Azure PowerShell
• Руководство. Создание настраиваемой роли Azure с помощью Azure CLI
• Определения ролей Azure
• Устранение неполадок Azure RBAC