Автоматизация целевых зон Azure в нескольких клиентах
Если в вашей организации есть несколько клиентов Microsoft Entra с целевыми зонами Azure (ALZ) в каждом из них, один или несколько раз, автоматизация является ключом. Автоматизация помогает успешно работать и поддерживать развертывание ALZ в большом масштабе во всех клиентах. Существует множество подходов для автоматизации развертываний ALZ в нескольких клиентах. Подход зависит от причин, по которым у вашей организации несколько клиентов Microsoft Entra.
Например, у вас может быть несколько клиентов Microsoft Entra, если вы являетесь независимым поставщиком программного обеспечения. Скорее всего, вы хотите отделить корпоративные и решения SaaS от клиентов Microsoft Entra. Риск операции или развертывания, влияющих на другой клиент, будь то предполагаемый или по ошибке, уменьшается.
В следующих разделах приведены схемы и рекомендации по подходам, которые можно принять. Выберите подход, который лучше всего подходит для вас на основе ваших требований, рекомендаций и рекомендаций по автоматизации развертываний целевых зон Azure при обработке нескольких клиентов Microsoft Entra.
Примечание.
Ознакомьтесь со следующими статьями, чтобы получить общие сведения о клиентах Microsoft Entra:
Подходы
Существует два подхода к автоматизации развертывания целевых зон Azure в нескольких клиентах Microsoft Entra.
Подход 1. Полная изоляция является наиболее распространенным подходом в сценариях с несколькими клиентами. Этот подход обеспечивает необходимое разделение и изоляцию между клиентами Microsoft Entra, что является наиболее распространенным требованием при использовании мультитенантного подхода.
Подход 2. Общая регистрация приложений (мультитенантная) с несколькими субъектами-службами обычно используется в сценариях управляемого поставщика служб (MSP). В этом подходе шаблон меток развертывания можно использовать для автоматизации развертывания почти идентичной архитектуры в нескольких клиентах в масштабе.
Оба этих подхода представлены в качестве примеров и вдохновения. Вы можете смешивать и соответствовать подходам в развертываниях на основе требований вашей организации.
Важно!
В этой статье описывается автоматизация развертывания и эксплуатации целевых зон Azure в качестве платформы в каждом клиенте Microsoft Entra, который имеет ваша организация. Подходы, рекомендации и рекомендации в этой статье не предназначены для использования командами приложений, которые развертывают и управляют своими службами и приложениями в своих целевых зонах (подписках). Дополнительные сведения о различных типах целевых зон см. в разделе "Платформа и целевые зоны приложений".
Подход 1. Полная изоляция
В этом подходе основная цель заключается в том, чтобы каждый клиент Microsoft Entra изолирован друг от друга во всех компонентах автоматизации, например:
- Репозиторий Git.
- Действия GitHub или Azure Pipelines (включая локальные средства выполнения, если они используются).
- Удостоверения, используемые для выполнения задач из автоматизации, например управляемых удостоверений, назначенных локальным запускам, именам субъектов-служб (SPN), пользователям или администраторам.
В этом подходе существует больше компонентов для управления повторяющимися для каждого клиента Microsoft Entra. В некоторых организациях могут применяться меры контроля соответствия нормативным требованиям, которые предписывают этому типу сегрегации и изоляции.
Примечание.
Если ваша организация допускает использование управляемых удостоверений для автоматизации платформы, необходимо использовать этот подход или подход, который входит в каждый клиент по отдельности. Управляемые удостоверения не поддерживают сценарии между клиентами. Дополнительные сведения см. в этом разделе «Вопросы и ответы».
Удостоверения для администраторов и разработчиков платформ — подход 1
В этом подходе удостоверения также должны быть изолированы в каждом клиенте Microsoft Entra, что означает, что каждому администратору платформы или разработчику требуется отдельная учетная запись пользователя в каждом клиенте для выполнения операций в этом клиенте. Эти учетные записи также используются для доступа к инструментам разработчика, таким как GitHub или Azure DevOps для каждого клиента. Тщательно рассмотрите последствия повышения производительности администратора и разработчика после этого подхода.
Microsoft Entra B2B и(или) Azure Lighthouse можно использовать, но этот параметр задает причины для отдельных клиентов Microsoft Entra.
Подход 2. Регистрация совместного приложения (мультитенантная) с несколькими субъектами-службами
В этом подходе регистрация приложения создается в клиенте Microsoft Entra. В каждом клиенте Microsoft Entra, который вы хотите управлять, в этом клиенте создается имя субъекта-службы (SPN) на основе регистрации приложения. Это действие позволяет работникам выполнять задачи конвейера и шаги для входа в любой из клиентов Microsoft Entra с одним набором учетных данных.
Совет
Сведения о связи между регистрацией приложений и корпоративными приложениями (принципами службы) см. в разделе "Объекты приложения и субъекта-службы" в идентификаторе Microsoft Entra.
Важно!
В этом подходе следует отслеживать регистрацию одного приложения и связанные корпоративные приложения (субъекты-службы) для любых ненормальных действий в инструментах управления безопасностью и событиями (SIEM), так как это высоко привилегированная учетная запись. Он должен отправлять оповещения и, возможно, автоматически принимать меры в зависимости от серьезности оповещений.
В предыдущем примере одна регистрация приложений находится в contoso.onmicrosoft.com клиенте Microsoft Entra, а корпоративное приложение находится в каждом из клиентов Microsoft Entra, связанных с регистрацией приложения. Эта настройка позволяет конвейеру проходить проверку подлинности и авторизацию для всех клиентов Microsoft Entra с помощью единой регистрации приложения. Дополнительные сведения см. в разделе "Создание мультитенантного приложения".
При использовании централизованного конвейера может потребоваться создать небольшую таблицу сопоставления, содержащую данные, коррелирующие клиенты 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. Они используют ту же учетную запись из управляющего клиента или могут иметь отдельные учетные записи, например пример в первом подходе.