Переход существующей среды Azure на эталонную архитектуру Azure Landing Zone

Многие организации имеют существующий объем ресурсов Azure, одну или несколько подписок и потенциально существующую структуру группы управления. В зависимости от бизнес-требований и сценариев они могут развертывать ресурсы Azure, такие как VPN-шлюз Azure или Azure ExpressRoute для гибридного подключения.

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

Перемещение ресурсов в Azure

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

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

Перемещение подписок

Как правило, вы перемещаете подписки, чтобы упорядочить их в группы управления или перенести подписки в новый клиент Идентификатора Microsoft Entra. Перемещение подписки к новому арендатору в основном предназначено для передачи права владения выставлением счетов. Дополнительные сведения о перемещении подписок между группами управления в одном клиенте см. в статье "Перемещение групп управления и подписок".

Требования к Azure RBAC

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

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

Политики

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

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

После перемещения подписок в группу управления с существующими политиками и RBAC Azure, рассмотрите следующие факторы:

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

• Политика, в которой область действия включает перемещаемые подписки, выполняет аудит только существующих ресурсов. Существующий ресурс в подписке, на который распространяется определённое условие или политика.

  • DeployIfNotExists Эффект политики отображается как несоответствующий и не исправлен автоматически. Пользователь должен вручную выполнить исправление.

  • Deny Эффект политики отображается как несоответствующий и не отвергается. Пользователь должен вручную устранить этот результат соответствующим образом.

  • Append и Modify эффект политики отображается как несоответствующий и требует, чтобы пользователь принял меры для исправления.

  • Audit и AuditIfNotExist эффект политики отображается как несоответствующий и требует, чтобы пользователь принял меры для исправления.

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

Перемещение ресурсов

Как правило, ресурсы перемещаются при необходимости консолидации ресурсов в одну и ту же группу ресурсов, если они используют один и тот же жизненный цикл. Или если вы хотите переместить ресурсы в другую подписку из-за затрат, владения или требований Azure RBAC.

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

Дополнительные сведения о том, как перемещать ресурсы между группами ресурсов и подписками в одном клиенте, см. в статье "Перемещение ресурсов в новую группу ресурсов или подписку".

Перед перемещением ресурсов

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

После перемещения ресурсов

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

Сценарии

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

• Сценарии выравнивания

  • Переход одной подписки без групп управления к эталонной архитектуре посадочной зоны Azure
  • Управление переходом групп к эталонной архитектуре стартовой площадки Azure
  • Переход региональной организации на эталонную архитектуру посадочной зоны Azure

• Подходы к выравниванию

  • Переход в среду путем дублирования группы управления границей посадки (рекомендуется)