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

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

Группы управления позволяют управлять корпоративным уровнем в большом масштабе независимо от типа подписок. При этом все подписки в одной группе управления должны доверять одному и тому же арендатору Azure Active Directory (Azure AD).

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

Важно!

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

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

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

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

Группы управления 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/{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/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"
  ]
}
...

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

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

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

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

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

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

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

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

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

Ограничения

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

  • В назначаемых областях новой роли можно определить только одну группу управления. Это ограничение позволяет сократить количество ситуаций, в которых определения и назначения ролей теряют связь. Эта ситуация возникает, когда подписка или группа управления с назначением роли перемещается в другой родительский элемент, который не имеет определения этой роли.
  • Действия в плоскости данных поставщика ресурсов невозможно определить в пользовательских ролях для группы управления. Это ограничение связано с тем, что существует задержка при обновлении поставщиков ресурсов в плоскости данных. Мы работаем над устранением этой проблемы с задержкой, но пока для снижения рисков эти действия не поддерживаются в определениях ролей.
  • 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. Дополнительные сведения см. в статье Параметры диагностики группы управления — создание или обновление.

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

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