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

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

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

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

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

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

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

Еще один сценарий, в котором можно использовать группы управления, — предоставление пользователю доступа к нескольким подпискам. Переместив несколько подписок в группу управления, можно создать одно назначение ролей Azure в группе управления. Роль наследует доступ ко всем подпискам. Одно назначение в группе управления может позволить пользователям иметь доступ к всем нужным пользователям, а не выполнять скрипты управления доступом на основе ролей Azure (RBAC) по разным подпискам.

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

• Один каталог может поддерживать 10 000 групп управления.

• Дерево групп управления может поддерживать до шести уровней вложенности.

  Данное ограничение не включает корневой уровень или уровень подписки.

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

• Каждая группа управления может иметь множество дочерних элементов.

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

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

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

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

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

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

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

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

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

Все, что назначено корневому каталогу, применяется ко всей иерархии. То есть он применяется ко всем группам управления, подпискам, группам ресурсов и ресурсам в клиенте Microsoft Entra.

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

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

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

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

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

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

Дополнительные сведения о перемещении элементов в иерархии см. в статье "Управление ресурсами с помощью групп управления".

Определение и назначение настраиваемой роли 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, вы разорете путь от назначения ролей подписки к определению роли для группы управления песочницами. В этом сценарии вы получите сообщение об ошибке, в котором говорится, что перемещение запрещено, так как это приведет к разрыву этой связи.

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

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

Ограничения

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

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

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

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

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

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

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

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

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

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

Связанный контент

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

• Создание групп управления для организации ресурсов Azure
• Изменение, удаление или управление группами управления
• Защита иерархии ресурсов