Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Примечание.
Эта статья относится только к Microsoft Azure и не применяется к другим предложениям Microsoft Cloud, таким как Microsoft 365 или Microsoft Dynamics 365.
Некоторым организациям может потребоваться протестировать определения и назначения платформы целевых зон Azure, определения и назначения политики Azure, управление доступом на основе ролей (RBAC) и т. д. Тесты можно выполнить с помощью автоматизации с помощью шаблонов Azure Resource Manager (шаблонов ARM), Terraform, Bicepили вручную с помощью портала Azure. Это руководство предоставляет подход, который можно использовать для тестирования изменений и их влияния на развертывание платформы целевых зон Azure.
Эту статью также можно использовать вместе с руководством по автоматизации платформы и критическим областям проектирования DevOps, связанным с группами и задачами PlatformOps и центральных функций. Кроме того, его можно объединить с рекомендациями в разделе внедрение ограничений, управляемых политикой, для методов внесения изменений политики в развертывание целевых зон Azure.
Это руководство наиболее подходит для организаций с надежными процессами управления изменениями, которые управляют изменениями в иерархии рабочей группы управления. Канареечная иерархия групп управления может применяться независимо для создания и тестирования развертываний перед внедрением в рабочую среду.
Примечание.
Термин канарейка используется во избежание путаницы со средами разработки или тестирования. Это название используется только для иллюстрации. Вы можете выбрать любое название, которое вы считаете подходящим для тестовой среды посадочных зон Azure.
Аналогичным образом, термин производственная среда/иерархия используется в этом руководстве для обозначения иерархии группы управления целевыми зонами Azure, которую может иметь организация, содержащая подписки и ресурсы Azure для рабочих нагрузок.
Определение платформы
Внимание
Это руководство не предназначено для сред разработки или тестовых сред, которые будут использоваться владельцами приложений или служб, известными как целевые зоны, рабочие нагрузки, приложения или службы. Они размещаются и обрабатываются в иерархии группы управления зонами размещения Azure в рабочей среде и связанной системы управления (RBAC и политики Azure).
Рекомендации по разработке, тестированию, тестированию пользователей (UAT) и рабочим средам для рабочих нагрузок приложений и команд см. в статье "Управление средами разработки приложений в целевых зонах Azure".
Это руководство предназначено только для тестирования на уровне платформы и изменений в контексте целевых зон Azure.
Зоны приземления Azure помогают разрабатывать и развертывать необходимые компоненты платформы Azure для создания и внедрения в эксплуатацию зон приземления в масштабе.
Ресурсы платформы в контексте этой статьи и подхода к тестированию включают следующее:
| Продукт или служба | Поставщик и тип ресурса |
|---|---|
| Группы управления | Microsoft.Management/managementGroups |
| Ассоциация подписки групп управления | 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 с выделением песочниц.
Для тестирования Политики Azure и RBAC в этом сценарии необходима одна подписка Azure с ролью Владельца RBAC, назначенной удостоверению, которое вы хотите использовать для тестирования, например, учетной записи пользователя, сервисному принципалу или удостоверению управляемой службы. Эта конфигурация позволяет создавать, назначать и устранять определения и назначения политики Azure только в пределах подписки песочницы.
Метод песочницы можно также применять для тестирования RBAC в подписке, например при разработке новой настраиваемой роли RBAC для предоставления разрешений в отношении конкретного варианта использования. Полностью провести это тестирование можно в среде песочницы до создания и назначения ролей на более высоких уровнях иерархии.
Преимущество этого подхода в том, что подписки песочницы можно использовать столько, сколько требуется, а потом удалять из среды.
Однако этот подход не позволяет выполнять тестирование, используя наследование политик RBAC и Azure из иерархии групп управления.
Методические указания по внедрению
Ниже приведены инструкции по реализации и использованию иерархии группы управления canary для зон высадки Azure вместе с иерархией группы управления для зон высадки в рабочей среде Azure.
Предупреждение
Если вы используете портал для развертывания среды целевых зон Azure и управления ею сегодня, может быть сложно эффективно внедрить и использовать канареечный подход. Это связано с высоким риском того, что рабочая и канареечная среды часто выходят из синхронизации, и, следовательно, не обеспечивают иерархию и среду, аналогичную рабочей.
Если вы используете этот сценарий, рассмотрите возможность перехода на инфраструктуру как код (IaC) для целевых зон Azure, как описано выше. Или будьте в курсе потенциальных рисков смещения конфигурации между тестовой и рабочей средой и действуйте осторожно. Дополнительные сведения см. в статье Об обновлении целевых зон Azure с помощью IaC.
- Используйте отдельные субъекты-службы Microsoft Entra (SPN) или управляемые удостоверения (MI), которым предоставлены разрешения для управления соответствующей рабочей или канареечной средой в иерархии групп управления посадочными зонами Azure.
- Это руководство соответствует принципу наименьших привилегий (PoLP).
- Используйте отдельные папки в репозитории Git, ветви или репозитории для хранения IaC для рабочей среды и развертываний целевых зон Azure.
- Использование соответствующих субъектов-служб (SPN) или управляемых удостоверений (MIs) в рамках конвейеров CI/CD в зависимости от того, какая иерархия развертывается.
- Реализуйте для канареечной среды такие же политики ветвления и безопасности Git, как и для рабочей среды.
- Рассмотрите возможность сокращения количества утверждающих и проверок для канареечной среды для быстрого выявления ошибок.
- Используйте конвейеры Azure или действия GitHub, которые используют переменные среды для изменений в развертываемой иерархии. Другой вариант — это клонировать конвейеры и корректировать прописанные в коде параметры для определения развертываемой иерархии.
- Использование шаблонов Azure Pipelines DevOps или шаблонов рабочих процессов GitHub Actions поможет вам придерживаться принципа "Не повторять себя ( DRY).
- У вас есть набор канарских подписок в отдельной учетной записи выставления счетов, например учетная запись Соглашения Enterprise (EA) или раздел счета microsoft Customer Agreement (MCA), который можно перемещать по иерархии канарной группы управления по мере необходимости.
- Это может быть полезно — всегда иметь набор ресурсов, развернутых в подписках канарной среды, чтобы ускорить тестирование и проверку изменений в этой среде.
- Укажите набор образцов архитектур рабочей нагрузки для приложений, которые можно развертывать в тестовых подписках в тестовом окружении, чтобы проверить изменения в политике Azure и RBAC. Это помогает проверить изменения перед развертыванием и внедрением изменений в продакшн.
- Эти примеры рабочих нагрузок можно развернуть с помощью одинаковых шаблонов IaC, которые используются для развертывания рабочих нагрузок рабочего приложения. Это поможет убедиться, что канарская среда синхронизирована с рабочей средой и что изменения, которые вы тестируете, являются допустимыми и применимыми к рабочей среде.
- Вы должны постоянно просматривать и обновлять примеры рабочих нагрузок, чтобы убедиться, что они актуальны и актуальны с использованием последних архитектур и шаблонов проектирования в вашей организации.
- Если вы предоставляете эталонные архитектуры группам приложений, рассмотрите возможность их развертывания и в тестовой среде. Это помогает проверить изменения в эталонных архитектурах и убедиться, что они применимы к рабочей среде.
- Отправьте все журналы действий Azure для всех подписок Azure, включая любые подписки на канарную среду, в рабочую среду Azure Log Analytics в соответствии с рекомендациями по проектированию целевых зон Azure.
- Это помогает группам безопасности и операций отслеживать канареечную среду на предмет любых изменений или проблем, которые могут возникнуть при тестировании изменений политики Azure и RBAC в производственной среде.
Совет
Если у вас уже есть зоны размещения Azure, развернутые в рабочей среде, и теперь вы хотите добавить канареечную среду. Рекомендуется клонировать текущее развертывание иерархии рабочей среды и изменить имена ресурсов, чтобы префиксировать их с помощью схемы именования канарной среды.
Это позволяет убедиться, что вы развертываете, чтобы включить канарскую среду в синхронизации с рабочей средой с самого начала. Это легко достигается при использовании средства IaC вместе с репозиторием git.
Использование одного клиента Microsoft Entra
Рекомендации, которые следует учитывать при использовании одного клиента Microsoft Entra:
- Использование одного клиента следует рекомендациям по проектированию целевых зон Azure для клиентов Microsoft Entra.
- В одном клиенте Microsoft Entra можно использовать различные группы Microsoft Entra как для продуктивных, так и для тестовых зон приземления Azure (canary) с теми же пользователями, назначенными в соответствующую иерархию групп управления.
- Увеличение или дублирование расходов на лицензирование Microsoft Entra ID из-за нескольких идентичностей в разных арендаторах Microsoft Entra. Это особенно важно для клиентов, использующих функции Microsoft Entra ID P1 или P2.
- Изменения RBAC являются более сложными в предварительной и рабочей средах, так как, скорее всего, пользователи и группы не идентичны в различных арендаторах Microsoft Entra.
- Учитывайте, что идентификаторы пользователей и групп не будут одинаковыми для клиентов Microsoft Entra, так как они глобально уникальны.
- Снижает сложность и затраты на управление, вызванные управлением несколькими клиентами Microsoft Entra.
- Привилегированные пользователи, которые должны поддерживать доступ и вход в отдельные клиенты для выполнения тестирования, могут внести случайные изменения в рабочую среду вместо канарной среды, как пример.
- Уменьшается вероятность отклонения конфигурации и сбоев при развертывании.
- Не требуется создание дополнительных процессов для обеспечения или аварийного доступа.
- Снижает трение и время, необходимое для реализации изменений в развертывании целевых зон Azure.
Следующие шаги
После создания среды Canary можно начать тестировать изменения политики Azure и RBAC перед их развертыванием в производственной иерархии групп управления посадочными зонами Azure.
Когда вы проверили изменения политик Azure в канарной среде, вы можете внедрить их в рабочую среду, следуя тому же подходу, как описано в руководстве Применение защитных мер, управляемых политиками. Это делается с помощью функции режима принудительного применения назначений политик. Используя подход, описанный в этом руководстве, вы сможете пройти дополнительный этап тестирования перед применением политики Azure в рабочей среде в требуемом эффекте, что поможет вам обеспечить уверенность в внесенных изменениях политики Azure.
Вы также можете просмотреть среды песочницы для команд приложений, которые используются для разработки и тестирования рабочих нагрузок. Это отдельная концепция от канареечной среды и используется для обеспечения безопасной среды для команд по разработке приложений, чтобы разрабатывать и тестировать свои нагрузки перед внедрением в рабочей среде.