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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • По умолчанию отображаемое имя корневой группы управления — это имя корневой группы клиента. В качестве идентификатора используется идентификатор Azure Active Directory.
  • Чтобы изменить отображаемое имя, учетной записи необходимо назначить роль владельца или участника в корневой группе управления. Инструкции по изменению имени группы управления представлены здесь.
  • Корневую группу управления нельзя переместить или удалить, в отличие от других групп управления.
  • Все группы управления и подписки добавляются в единую корневую группу управления в каталоге.
    • Все ресурсы в каталоге добавляются в корневую группу управления для глобального управления.
    • Новые подписки автоматически попадают в корневую группу управления при создании.
  • Все клиенты Azure могут видеть корневую группу управления, но не у всех клиентов есть доступ к управлению этой корневой группой управления.
    • Все, кто имеет доступ к подписке, могут видеть контекст расположения подписки в иерархии.
    • Никто не получает доступ к корневой группе управления по умолчанию. Только глобальные администраторы Azure AD могут повысить свои права для получения доступа. Получив доступ к корневой группе управления, глобальные администраторы могут назначить любую роль Azure другим пользователям для
      управления.
  • В пакете SDK корневая группа управления ("корень клиента") действует как группа управления.

Важно!

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

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

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

Проблемы с отображением всех подписок

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

Способы устранения проблемы

Устранить эту проблему можно двумя способами.

  • Удалить все назначения ролей и политик из корневой группы управления.
    • Если удалить все назначения политик и ролей из корневой группы управления, служба снова заполнит все подписки в иерархии в следующем цикле. Это позволяет проверить, не был ли случайно предоставлен доступ ко всем подпискам клиентов или назначена политика всем подпискам клиентов.
    • Чтобы выполнить эту проверку без влияния на работу служб, лучше всего применить назначения ролей или политик на один уровень ниже корневой группы управления. После этого можно удалить все назначения из корневой области.
  • Вызвать API напрямую, чтобы начать процесс обратного заполнения.
    • Любой клиент в каталоге может вызвать API TenantBackfillStatusRequest или StartTenantBackfillRequest. Если вызвать API StartTenantBackfillRequest, запустится процесс начальной настройки для перемещения всех подписок в иерархию. В рамках этого процесса также все новые подписки принудительно назначаются в качестве дочерних для корневой группы управления. Это можно сделать, не изменяя назначения на корневом уровне. Вызывая API, вы соглашаетесь с тем, что любое назначение политики или доступа будет применяться ко всем подпискам.

Если у вас есть вопросы о процессе обратного заполнения, свяжитесь с нами: managementgroups@microsoft.com

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

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

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

Имя роли Azure Создание Переименовать Перемещение** DELETE Назначение доступа Назначение политики Чтение
Владелец 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/{идентификатор_группы} .

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

...
{
  "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/managementgroup/write",
    "Microsoft.Management/managementgroup/subscriptions/delete",
    "Microsoft.Management/managementgroup/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"
  ]
}
...

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

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

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

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

Схема посвящена корневой группе управления с дочерними группами управления IT и Marketing. Для группы управления IT имеется одна дочерняя группа управления с именем Production, а для группы управления Marketing — две пробные дочерние подписки.

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

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

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

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

Ограничения

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

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

Важно!

В настоящее время добавление группы управления в AssignableScopes доступно в режиме предварительной версии. Эта предварительная версия предоставляется без соглашения об уровне обслуживания и не рекомендована для использования рабочей среде. Некоторые функции могут не поддерживаться или их возможности могут быть ограничены. Дополнительные сведения см. в статье Дополнительные условия использования предварительных выпусков Microsoft Azure.

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

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

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

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

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

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

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

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

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

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

Дальнейшие действия

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