Автоматизация посадочных зон Azure в нескольких тенантах
Если в вашей организации есть несколько арендаторов Microsoft Entra с целевыми зонами Azure (ALZ) в каждом из них, которые используются один или несколько раз, автоматизация является ключом. Автоматизация помогает успешно работать и поддерживать развертывание ALZ в большом масштабе для всех арендаторов. Существует множество подходов для автоматизации развертываний ALZ в нескольких арендаторах. Подход зависит от причин, по которым у вашей организации несколько клиентов Microsoft Entra.
Например, у вас может быть несколько клиентов Microsoft Entra, если вы являетесь независимым поставщиком программного обеспечения. Скорее всего, вы хотите держать корпоративные арендаторы и арендаторы SaaS решений Microsoft Entra отдельно. Риск операции или развертывания, влияющих на другого арендатора, будь то намеренный или по ошибке, уменьшается.
В следующих разделах приведены схемы и рекомендации по подходам, которые можно принять. Выберите подход, который лучше всего соответствует вашим требованиям, соображениям и рекомендациям по автоматизации развертываний целевых зон Azure при управлении несколькими арендаторами Microsoft Entra.
Заметка
Ознакомьтесь со следующими статьями, чтобы получить общие сведения о клиентах Microsoft Entra:
- Обзор для нескольких клиентов Microsoft Entra
- сценарии для нескольких клиентов Microsoft Entra
- Рекомендации и учитываемые аспекты для мультитенантных сценариев целевой зоны Azure &
Подходы
Существует два подхода к автоматизации развертывания целевых зон Azure в нескольких клиентах Microsoft Entra.
подход 1. Полная изоляция является наиболее распространенным подходом в мультитенантных сценариях. Этот подход обеспечивает необходимое разделение и изоляцию между клиентами Microsoft Entra, что является наиболее распространенным требованием при использовании мультитенантного подхода.
Подход 2 — регистрация общих приложений (многопользовательская) с несколькими сервисными принципалами часто используется в сценариях управляемого поставщика услуг (УПС). В этом подходе шаблон маркировки развертывания может быть использован для автоматизации развертывания почти идентичной архитектуры на уровне всего предприятия, охватывающего несколько клиентов.
Оба этих подхода представлены в качестве примеров и вдохновения. Вы можете сочетать и комбинировать подходы в развертывания вашей организации в соответствии с её требованиями.
Важный
В этой статье описывается автоматизация развертывания и эксплуатации целевых зон Azure в качестве платформы в каждом клиенте Microsoft Entra, который имеет ваша организация. Подходы, рекомендации и соображения в этой статье не предназначены для использования командами приложений, которые развертывают и управляют своими решениями в целевых зонах (подписки). Дополнительные сведения о различных типах целевых зон см. в платформа и целевые зоны приложений.
Подход 1. Полная изоляция
В этом подходе основная цель заключается в том, чтобы каждый клиент Microsoft Entra изолирован друг от друга во всех компонентах автоматизации, например:
- Репозиторий Git.
- Действия GitHub или Azure Pipelines (включая локальные средства выполнения, если они используются).
- Идентичности, используемые для выполнения задач автоматизации, такие как управляемые удостоверения, назначаемые запускателям, размещённым на собственной инфраструктуре, имена субъектов-служб (SPN), пользователи или администраторы.
В этом подходе необходимо управлять большим числом компонентов, которые дублируются для каждого арендатора Microsoft Entra. В некоторых организациях могут применяться меры контроля соответствия нормативным требованиям, которые предписывают этому типу сегрегации и изоляции.
Заметка
Если ваша организация допускает только использование управляемых удостоверений для автоматизации платформы, необходимо использовать этот подход или подход, который выполняет вход в каждого арендатора по отдельности. Управляемые удостоверения сегодня не поддерживают сценарии между арендаторами в общедоступном состоянии. Дополнительные сведения см. в этом разделeFAQ.
Однако теперь это доступно в общедоступной предварительной версии для Управляемых Идентичностей User-Assigned путем настройки доверия между собой и мультиарендным приложением Entra ID. Смотрите дополнительную информацию о настройке этого в Настройка приложения для доверия к управляемой идентичности (предварительный просмотр). Теперь это может сделать подход 2 — регистрация общих приложений (многопользовательская) с несколькими основными службами жизнеспособным вариантом для вашего развертывания.
Идентификации для администраторов и разработчиков платформ — подход 1
В этом подходе удостоверения также должны быть изолированы в каждом клиенте Microsoft Entra, что означает, что каждому администратору платформы или разработчику требуется отдельная учетная запись пользователя в каждом клиенте для выполнения операций в этом клиенте. Эти учетные записи также используются для доступа к инструментам разработчика, таким как GitHub или Azure DevOps для каждого клиента. Тщательно рассмотрите последствия повышения производительности администратора и разработчика после этого подхода.
Microsoft Entra B2B и(или) Azure Lighthouse можно использовать, но этот вариант ставит под вопрос необходимость раздельных арендаторов Microsoft Entra.
Подход 2. Общая регистрация приложения (мультитенантная) с несколькими принципалами службы
В этом подходе регистрация приложения создается в управляющем клиенте Microsoft Entra. В каждом клиенте Microsoft Entra, который вы хотите управлять, в этом клиенте создается имя субъекта-службы (SPN) на основе регистрации приложения. Это действие позволяет работникам, выполняющим задачи и этапы конвейера, войти в любой из арендаторов Microsoft Entra с одним набором учетных данных.
Совет
Сведения о связи между регистрацией приложений и корпоративными приложениями (главными службами) см. в разделе Объекты приложений и субъекты службы в Microsoft Entra ID.
Важный
В этом подходе следует отслеживать регистрацию одного приложения и связанные корпоративные приложения (субъекты-службы) для любых ненормальных действий в инструментах управления безопасностью и событиями (SIEM), так как это высоко привилегированная учетная запись. Он должен отправлять оповещения и, возможно, автоматически принимать меры в зависимости от серьезности оповещений.
В предыдущем примере одна регистрация приложения находится в клиенте Microsoft Entra contoso.onmicrosoft.com, а корпоративное приложение находится в каждом из клиентов Microsoft Entra, связанных с регистрацией приложения. Эта настройка позволяет конвейеру аутентифицироваться и авторизоваться для всех тенантов Microsoft Entra с помощью единой регистрации приложения. Дополнительные сведения см. в статье Создание мультитенантных приложений и предоставление согласия администратора на уровне клиентаприложения.
Совет
Назначенные пользователем управляемые идентификаторы в общедоступной предварительной версии теперь могут поддерживать мультитенантные сценарии, настраивая доверие между собой и мультитенантным приложением Entra ID. Дополнительные сведения о настройке этого в настройка приложения для доверия управляемому удостоверению (предварительная версия).
При использовании централизованного конвейера может потребоваться создать небольшую таблицу сопоставления, содержащую данные, коррелирующие клиенты Microsoft Entra и другие метаданные, такие как среда, связанные подписки, имя организации и идентификатор объекта удостоверения, используемые для проверки подлинности и авторизации. Эти данные можно вызывать в ходе выполнения конвейера на этапе, где используется определённая логика и условия, чтобы контролировать, в какой клиент Microsoft Entra осуществляется развертывание и с какими удостоверениями. Эти данные можно хранить в службах, таких как Azure Cosmos DB или хранилище таблиц Azure.
При обработке нескольких сред, таких как разработка, тестирование или производство, они могут управляться таким же образом, используя одинаковые или отдельные регистрации приложений и корпоративные приложения с конвейерами.
Вы можете выбрать отдельные конвейеры для каждого клиента Microsoft Entra или использовать один конвейер. Выбор зависит от ваших требований.
Заметка
Azure Lighthouse работает аналогично этому подходу, но Azure Lighthouse не разрешает назначение владельца RBAC, администратора доступа пользователей и ролей с разрешениями DataActions. Дополнительные сведения см. в статье Поддержка ролей для Azure Lighthouse.
Роли владельца и доступа пользователей обычно требуются во всех сценариях развертывания целевой зоны Azure. Это требование исключает Azure Lighthouse как вариант для всего аспекта развертывания автоматизации платформы в рамках посадочных зон Azure, но это все еще полезно в некоторых сценариях. См. дополнительную информацию о использовании Azure Lighthouse в мультиарендномALZ.
Идентификации для администраторов и разработчиков платформ — подход 2
В этом подходе администраторы платформ и разработчики обычно нуждаются только в доступе к управлению клиентом Microsoft Entra. Этот доступ предоставляет им возможность использовать инструменты разработчика, такие как GitHub или Azure DevOps, на которых развертываются и из которых управляются все арендаторы.
У них может быть доступ к другим клиентам Microsoft Entra через Microsoft Entra B2B или Azure Lighthouse. Они используют ту же учетную запись, что и управляющий арендатор, или могут иметь отдельные учетные записи, как в примере в первом подходе .