Поделиться через


Что такое группы управления Azure?

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

Группы управления предоставляют управление корпоративным классом в масштабе независимо от типа подписок, которые у вас могут быть. Однако все подписки в одной группе управления должны доверять одному клиенту Идентификатора Microsoft Entra.

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

Иерархия групп управления и подписок

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

Схема примера иерархии группы управления.

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

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

Примечание.

Сейчас группы управления не поддерживаются в функциях Управления затратами для подписок с Клиентским соглашением Майкрософт (MCA).

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

Важные факты о группах управления

  • Один каталог может поддерживать 10 000 групп управления.
  • Дерево групп управления может поддерживать до шести уровней вложенности.
    • Это ограничение не включает уровень корня или подписки.
  • Каждая группа управления и подписка может поддерживать только одну родительскую группу.
  • Каждая группа управления может иметь множество дочерних элементов.
  • Все группы управления и подписки включены в иерархию в каждом каталоге. См. важные сведения о корневой группе управления.

Корневая группа управления для каждого каталога

Каждому каталогу присваивается одна группа управления верхнего уровня, которая называется корневой группой управления. Эта группа встроена в иерархию, чтобы в нее входили все группы управления и подписки. Эта корневая группа управления позволяет применять глобальные политики и назначения ролей Azure на уровне каталогов. Глобальный администратор Microsoft Entra ID должен повысить роль администратора доступа пользователей этой корневой группы. После повышения привилегий администратор сможет назначить любую роль Azure другим пользователям или группам в каталоге для управления иерархией. Администратор может назначить свою учетную запись владельцем корневой группы управления.

Важные сведения о корневой группе управления

  • По умолчанию корневая группа управления имеет имя Корневая группа клиента и работает в качестве группы управления. Идентификатор совпадает с идентификатором клиента Microsoft Entra ID.
  • Чтобы изменить отображаемое имя, учетной записи необходимо назначить роль Владелец или Участник в корневой группе управления. Инструкции по изменению имени группы управления представлены здесь.
  • Корневую группу управления нельзя переместить или удалить, в отличие от других групп управления.
  • Все подписки и группы управления объединяются в одну корневую группу управления в каталоге.
    • Все ресурсы в каталоге добавляются в корневую группу управления для глобального управления.
    • Новые подписки автоматически попадают в корневую группу управления при создании.
  • Все клиенты Azure могут видеть корневую группу управления, но не у всех клиентов есть доступ к управлению этой корневой группой управления.
    • Все, кто имеет доступ к подписке, могут видеть контекст расположения подписки в иерархии.
    • Никто не получает доступ к корневой группе управления по умолчанию. Глобальные администраторы Microsoft Entra ID являются единственными пользователями, которые могут повысить уровень доступа. Получив доступ к корневой группе управления, глобальные администраторы могут назначить любую роль Azure другим пользователям для управления этой группой.

Внимание

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

Начальная настройка групп управления

Когда любой пользователь начинает использовать группы управления, выполняется начальная настройка. Сначала в каталоге создается корневая группа управления. После создания этой группы все существующие подписки из каталога становятся дочерними элементами корневой группы управления. Это делается для того, чтобы в каталоге существовала только одна иерархия групп управления. Одна иерархия в каталоге позволяет административным клиентам применять глобальный доступ и политики, которые другие клиенты в каталоге не могут обойти. Все, что назначено в корне, будет применяться ко всей иерархии, которая включает все группы управления, подписки, группы ресурсов и ресурсы в клиенте Идентификатора Microsoft Entra.

Доступ к группе управления

Группы управления Azure поддерживают управление доступом на основе ролей в Azure (Azure RBAC) для любого доступа к ресурсам и определения ролей. Эти разрешения наследуются дочерними ресурсами, которые есть в иерархии. Любую роль Azure можно назначить группе управления, и она будет наследоваться ресурсами вниз по иерархии. Например, группе управления можно назначить роль Azure участника виртуальной машины. Эта роль не имеет действий в группе управления, но наследует все виртуальные машины в этой группе управления.

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

Имя роли Azure Создание Переименовать Перемещение** Удаление Назначение доступа Назначение политики Читать
Ответственный X X X X X X X
Участник X X X X X
Участник группы управления* X X X X X
Читатель X
Читатель группы управления* X
Участник политики ресурсов X
Администратор доступа пользователей X X

*. Роли Участник группы управления и Читатель группы управления позволяют пользователям выполнять эти действия только в рамках группы управления.

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

Сведения о перемещении элементов в пределах иерархии см. в статье Manage your resources with management groups (Управление ресурсами с помощью групп управления).

Определение и назначение настраиваемой роли Azure

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

Пример определения

Определение и создание настраиваемой роли не изменяется при добавлении групп управления. Используйте полный путь для определения группы /providers/Microsoft.Management/managementgroups/{_groupId_}управления.

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

...
{
  "Name": "MG Test Custom Role",
  "Id": "id",
  "IsCustom": true,
  "Description": "This role provides members understand custom roles.",
  "Actions": [
    "Microsoft.Management/managementGroups/delete",
    "Microsoft.Management/managementGroups/read",
    "Microsoft.Management/managementGroups/write",
    "Microsoft.Management/managementGroups/subscriptions/delete",
    "Microsoft.Management/managementGroups/subscriptions/write",
    "Microsoft.resources/subscriptions/read",
    "Microsoft.Authorization/policyAssignments/*",
    "Microsoft.Authorization/policyDefinitions/*",
    "Microsoft.Authorization/policySetDefinitions/*",
    "Microsoft.PolicyInsights/*",
    "Microsoft.Authorization/roleAssignments/*",
    "Microsoft.Authorization/roledefinitions/*"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
        "/providers/microsoft.management/managementGroups/ContosoCorporate"
  ]
}
...

Проблемы с нарушением иерархии наследования для определения и назначения роли

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

Например, давайте рассмотрим небольшой фрагмент иерархии для визуального элемента.

Схема подмножества примеров иерархии группы управления.

На схеме основное внимание уделяется корневой группе управления с дочерними целевыми зонами и группами управления песочницами. Группа управления целевыми зонами имеет две дочерние группы управления с именем Corp и Online, а группа управления песочница имеет две дочерние подписки.

Предположим, что в группе управления песочницей определена настраиваемая роль. Затем эта настраиваемая роль назначается двум подпискам песочницы.

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

Существует несколько вариантов, позволяющих исправить ситуацию.

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

Ограничения

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

  • В назначаемых областях новой роли можно определить только одну группу управления. Это ограничение позволяет сократить количество ситуаций, в которых определения и назначения ролей теряют связь. Эта ситуация возникает, когда подписка или группа управления с назначением роли перемещается в другой родительский элемент, который не имеет определения этой роли.
  • Настраиваемые роли с DataActions нельзя назначить в области группы управления. Дополнительные сведения см. в разделе "Ограничения пользовательских ролей".
  • Azure Resource Manager не проверяет существование группы управления, указанной в назначаемой области определения роли. Если вы допустите опечатку или примените неверный идентификатор группы управления, определение роли все равно будет создано.

Перемещение групп управления и подписок

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

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

  • Разрешения на запись сведений о группе управления и назначении роли в дочерней подписке или группе управления.
    • Пример встроенной роли: Владелец
  • Разрешения на запись сведений о группе управления в целевой родительской группе управления.
    • Встроенный пример роли: владелец, участник, участник группы управления
  • Разрешения на запись сведений о группе управления в нынешней родительской группе управления.
    • Встроенный пример роли: владелец, участник, участник группы управления

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

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

Внимание

Azure Resource Manager кэширует сведения об иерархии группы управления на срок до 30 минут. В результате перемещение группы управления может не сразу отражаться на портале Azure.

Аудит групп управления с помощью журналов действий

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

Снимок экрана журналов действий и операций, связанных с выбранной группой управления.

Если нужно создать запрос к группам управления вне портала Azure, целевая область для групп управления будет такой: "/providers/Microsoft.Management/managementGroups/{management-group-id}".

Примечание.

С помощью REST API Azure Resource Manager можно включить параметры диагностики в группе управления, чтобы отправлять связанные записи журнала действий Azure в рабочую область Log Analytics, службу хранилища Azure или Концентратор событий Azure. Дополнительные сведения см. в статье Параметры диагностики группы управления — создание или обновление.

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

Дополнительные сведения о группах управления: