Подход к тестированию для целевых зон Azure

Примечание.

Эта статья относится только к Microsoft Azure и не применяется к другим предложениям Microsoft Cloud, таким как Microsoft 365 или Microsoft Dynamics 365.

Некоторые организации могут потребовать проверить развертывание платформы целевых зон Azure для Политика Azure определений и назначений, управления доступом на основе ролей (RBAC) настраиваемых ролей и назначений и т. д. Тесты можно выполнить с помощью автоматизации с помощью шаблонов Azure Resource Manager (шаблонов ARM), AzOps, Terraform, Bicep или вручную с помощью портал Azure. Это руководство предоставляет подход, который можно использовать для тестирования изменений и их влияния на развертывание платформы целевых зон Azure.

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

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

Примечание.

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

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

Определение платформы

Важно!

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

Это руководство предназначено только для тестирования на уровне платформы и изменений в контексте целевых зон Azure.

На корпоративном уровне можно разрабатывать и развертывать необходимые компоненты платформы Azure и, таким образом, создавать и эксплуатировать целевые зоны в широком масштабе.

Ресурсы платформы в контексте этой статьи и подхода к тестированию включают следующее:

Продукт или служба	Поставщик и тип ресурса
Группы управления	Microsoft.Management/managementGroups
Management groups subscription association	Microsoft.Management/managementGroups/subscriptions
Определения политик	Microsoft.Authorization/policyDefinitions
Определения инициатив или наборов политик	Microsoft.Authorization/policySetDefinitions
Назначения политик	Microsoft.Authorization/policyAssignments
Определения ролей RBAC	Microsoft.Authorization/roleDefinitions
Назначения ролей RBAC	Microsoft.Authorization/roleAssignments
Подписки	Microsoft.Subscription/aliases

Примеры сценариев и результатов

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

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

Аналогичный сценарий может быть изменением назначений ролей Azure RBAC и членства в группах Microsoft Entra. Перед внесением изменений в рабочей среде может потребоваться форма тестирования.

Важно!

Этот подход к развертыванию или шаблон для большинства клиентов не подходит, Это не обязательно для развертываний целевых зон Azure.

Рисунок 1. Канареечная иерархия групп управления.

Как показано на схеме, вся иерархия групп управления рабочей средой в целевых зонах Azure дублируется под Tenant Root Group. К отображаемым названиям и идентификаторам групп управления добавляется слово canary (канареечная). Идентификаторы должны быть уникальными в одном клиенте Microsoft Entra.

Примечание.

Отображаемые названия групп управления канареечной средой могут совпадать с отображаемыми названиями групп управления рабочей средой. В результате пользователи могут запутаться. В связи с этим рекомендуем добавлять к отображаемым названиям и идентификаторам слово "canary" (канареечный).

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

• Группы управления
  • Размещение подписки
• RBAC
  • Роли (встроенные и пользовательские)
  • Задания
• Политика Azure
  • Определения (встроенные и пользовательские)
  • Инициативы (также называются определениями наборов)
  • Задания

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

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

Рис. 2. Корпоративная иерархия групп управления с указанием песочниц.

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

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

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

Однако этот подход не позволяет выполнять тестирование, используя наследование политик RBAC и Azure из иерархии групп управления.

Использование одного клиента Microsoft Entra

Рекомендации, которые следует учитывать при использовании одного клиента Microsoft Entra:

• Следуйте рекомендациям по проектированию корпоративного масштаба для клиентов Microsoft Entra.
• В зависимости от рекомендаций Azure Cloud Adoption Framework стандартизируйте в одном каталоге и руководстве по удостоверениям , для большинства клиентов Microsoft Entra рекомендуется использовать один клиент Microsoft Entra.
  • В одном клиенте Microsoft Entra можно использовать разные группы Microsoft Entra как для рабочих сред, так и для локальных зон Azure с одинаковыми пользователями, назначенными соответствующей иерархии групп управления в одном клиенте Microsoft Entra.
• Увеличение или дублирование расходов на лицензирование идентификатора Microsoft Entra из-за нескольких удостоверений в разных клиентах Microsoft Entra.
  • Эта точка особенно актуальна для клиентов, использующих функции Microsoft Entra ID P1 или P2.
• Изменения RBAC будут более сложными как в канарских средах, так и в рабочих средах, так как, скорее всего, пользователи и группы не совпадают как в клиентах Microsoft Entra.
  • Кроме того, идентификаторы пользователей и групп не будут одинаковыми в клиентах Microsoft Entra из-за того, что они глобально уникальны.
• Снижает сложность и затраты на управление, вызванные управлением несколькими клиентами Microsoft Entra.
  • Привилегированные пользователи, которым нужно сохранять доступ и входить в разные клиенты для выполнения тестирования, могут случайно вносить изменения в рабочую, а не в канареечную среду или наоборот.
• Уменьшается вероятность отклонения конфигурации и сбоев при развертывании.
• Не требуется создание дополнительных процессов для обеспечения или аварийного доступа.
• Снижает трение и время, необходимое для реализации изменений в развертывании целевых зон Azure.

Методические указания по внедрению

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

Предупреждение

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

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

1. Используйте отдельные субъекты-службы Microsoft Entra (SPN) или управляемые удостоверения службы (MSIs), которые предоставляются разрешения на соответствующую рабочую среду или иерархию групп управления канарной средой.
   • Это руководство соответствует принципу наименьших привилегий (PoLP).
2. Используйте отдельные папки в репозитории Git, ветви или репозитории для хранения инфраструктуры как кода для рабочей среды и развертывания целевых зон Azure.
   • Использование соответствующих субъектов-служб (SPN) или управляемых удостоверений служб (MSIs) в рамках конвейеров CI/CD в зависимости от того, какая иерархия развертывается.
3. Реализуйте для канареечной среды такие же политики ветви и средства обеспечения безопасности Git, как для рабочей среды.
   • По возможности можно сократить количество утверждающих и проверок для канареечной среды, чтобы обеспечить устранение ошибок на раннем этапе.
4. Используйте конвейеры Azure или действия GitHub, которые используют переменные среды для изменений в развертываемой иерархии. Другой вариант — это клонировать конвейеры и корректировать прописанные в коде параметры для определения развертываемой иерархии.
   • Шаблоны Azure Pipelines DevOps и Шаблоны рабочих процессов GitHub Actions помогут вам не повторяться.
5. Подготовьте набор канареечных подписок в отдельном отделе и учетной записи EA — при необходимости вы сможете перемещать их по канареечной иерархии групп управления.
   • Не лишним будет набор ресурсов, всегда развернутых в подписках канареечной среды.
   • Также может пригодиться наличие шаблонов инфраструктуры как кода, таких как шаблоны ARM, Bicep или Terraform, создающих набор ресурсов для проверки изменений в канареечной среде.
6. Отправьте все журналы действий Azure для всех подписок Azure, включая любые подписки на канарную среду, в рабочую среду Azure Log Analytics в соответствии с рекомендациями по проектированию целевых зон Azure.

Совет

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

Это позволяет обеспечить синхронизацию канарной среды с рабочей средой с самого начала. Это легко достигается при использовании средства infrastructure-as-Code вместе с репозиторием git.

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

Узнайте, как реализовать среды песочницы целевой зоны.

Реализация сред песочницы целевой зоны