Automatiser les zones d’atterrissage Azure sur plusieurs locataires
Si votre organisation a plusieurs locataires Microsoft Entra avec des zones d’atterrissage Azure (ALZ) dans chacune d’elles, une ou plusieurs fois, l’automatisation est essentielle. Automation permet d’exploiter et de maintenir le déploiement ALZ à grande échelle sur tous les locataires. Il existe de nombreuses approches pour automatiser les déploiements ALZ sur plusieurs locataires. L’approche que vous adopterez dépend des raisons pour lesquelles votre organisation a plusieurs locataires Microsoft Entra.
Par exemple, vous pouvez avoir plusieurs locataires Microsoft Entra si vous êtes éditeur de logiciels indépendant. Vous souhaiterez probablement séparer les locataires Microsoft Entra de vos solutions d’entreprise et SaaS. Le risque d’une opération ou d’un déploiement affectant l’autre locataire, intentionnellement ou par erreur, diminue.
Les sections suivantes fournissent des diagrammes et des conseils sur les approches que vous pouvez adopter. Choisissez l’approche qui vous convient le mieux en fonction de vos besoins, considérations et recommandations pour automatiser vos déploiements de zones d’atterrissage Azure lors de la gestion de plusieurs locataires Microsoft Entra.
Remarque
Consultez d’abord les articles suivants pour obtenir une vue d’ensemble des locataires Microsoft Entra :
Approches
Il existe deux approches pour automatiser le déploiement de zones d’atterrissage Azure sur plusieurs locataires Microsoft Entra.
L’Approche 1 : Isolation complète est la plus courante dans les scénarios multi-locataires. Cette approche conserve la séparation et l’isolation requises entre les locataires Microsoft Entra, ce qui est l’exigence la plus courante lors de l’utilisation d’une approche multi-locataire.
L’Approche 2 : Inscription d’applications partagées (mutualisée) avec plusieurs principaux de service est couramment utilisée dans les scénarios de fournisseur de services managés (MSP). Dans cette approche, un modèle d’empreintes de déploiement peut être utilisé pour automatiser le déploiement d’une architecture presque identique sur plusieurs locataires à grande échelle.
Ces deux approches sont fournies à titre d’exemples et d’inspiration. Vous pouvez combiner les approches de vos déploiements en fonction des besoins de votre organisation.
Important
Cet article traite de l’automatisation du déploiement et du fonctionnement des zones d’atterrissage Azure en tant que plateforme dans chaque locataire Microsoft Entra dont dispose votre organisation. Les approches, recommandations et considérations de cet article ne sont pas destinées à être utilisées par les équipes d’application qui déploient et exploitent leurs services et applications dans leurs zones d’atterrissage (abonnements). Pour plus d’informations sur les différents types de zones d’atterrissage, consultez Zones d’atterrissage de plateforme et d’application.
Approche 1 : Isolation complète
Dans cette approche, l’objectif principal est de maintenir les locataires Microsoft Entra isolés les uns des autres sur tous les composants d’automatisation, comme :
- Un référentiel Git.
- GitHub Actions ou Azure Pipelines (y compris les exécuteurs auto-hébergés, s’ils sont utilisés).
- Identités utilisées pour effectuer des tâches à partir de l’automatisation, comme les identités managées attribuées à des exécuteurs auto-hébergés, les noms de principaux de service (SPN), les utilisateurs ou les administrateurs.
Dans cette approche, il existe d’autres composants à gérer qui sont dupliqués par un locataire Microsoft Entra. Certaines organisations peuvent avoir des contrôles de conformité réglementaires qui leur imposent ce type de ségrégation et d’isolation.
Notes
Si votre organisation autorise uniquement l’utilisation d’identités managées pour l’automatisation de la plateforme, vous devez utiliser cette approche ou une approche qui se connecte à chaque locataire individuellement. Les identités managées ne prennent pas en charge les scénarios inter-locataires. Pour plus d’informations, consultez cette FAQ .
Identités pour les administrateurs et développeurs de plateforme - Approche 1
Dans cette approche, les identités doivent également être isolées dans chaque locataire Microsoft Entra, ce qui signifie que chaque administrateur ou développeur de plateforme a besoin d’un compte d’utilisateur distinct au sein de chaque locataire pour effectuer des opérations dans chacun d’eux. Ces comptes sont également utilisés pour accéder aux outils de développement, comme GitHub ou Azure DevOps, pour chacun des locataires. Étudiez attentivement les effets sur la productivité des administrateurs et des développeurs avec cette approche.
Microsoft Entra B2B et/ou Azure Lighthouse peuvent être utilisés, mais cette option remet en question le raisonnement conduisant à avoir des locataires Microsoft Entra distincts.
Approche 2 : Inscription d’applications partagée (mutualisée) avec plusieurs principaux de service
Dans cette approche, une inscription d’application est créée dans le locataire Microsoft Entra de gestion. Dans chaque locataire Microsoft Entra que vous souhaitez gérer, un nom de principal de service (SPN) est créé dans ce locataire, en fonction de l’inscription de l’application. Cette action permet aux collaborateurs qui exécutent les tâches et les étapes du pipeline de se connecter à l’un des locataires Microsoft Entra avec un seul ensemble d’informations d’identification.
Conseil
Pour plus d’informations sur la relation existant entre les inscriptions d’application et les applications d’entreprise (principaux de service), consultez Objets application et principal de service dans Microsoft Entra ID.
Important
Dans cette approche, l’inscription d’une application unique et les applications d’entreprise associées (principaux de service) doivent être surveillés pour détecter toute activité anormale dans vos outils SIEM (Gestion des informations et des événements de sécurité), car il s’agit d’un compte hautement privilégié. Il doit envoyer des alertes et éventuellement prendre des mesures automatiquement, en fonction de la gravité de l’alerte.
Dans l’exemple précédent, une seule inscription d’application se trouve dans le locataire Microsoft Entra contoso.onmicrosoft.com, et une application d’entreprise se trouve dans chacun des locataires Microsoft Entra liés à l’inscription d’application. Cette configuration permet à un pipeline d’être authentifié et autorisé dans tous les locataires Microsoft Entra avec la même inscription d’application. Pour plus d’informations, consultez Rendre votre application multilocataire.
Lorsque vous utilisez un pipeline centralisé, vous devrez peut-être créer un petit tableau de correspondances contenant les données en corrélation avec les locataires Microsoft Entra et d’autres métadonnées, comme l’environnement, les abonnements associés, le nom de l’organisation et l’ID d’objet d’identité utilisés pour l’authentification et l’autorisation. Ces données peuvent être appelées pendant l’exécution du pipeline dans une étape qui utilise une logique et des conditions pour contrôler le locataire Microsoft Entra sur lequel elles sont déployées et avec quelles identités. Les données peuvent être stockées dans des services, comme Azure Cosmos DB ou le stockage Table Azure.
Lorsque vous gérez plusieurs environnements, comme le développement, le test ou la production, vous pouvez les contrôler de la même manière en utilisant des inscriptions d’application et applications d’entreprise identiques ou distinctes avec des pipelines.
Vous pouvez décider d’avoir des pipelines distincts pour chaque locataire Microsoft Entra ou d’en utiliser un seul. Le choix vous appartient, selon vos besoins.
Notes
Azure Lighthouse fonctionne de la même manière que cette approche, mais n’autorise pas l’affectation du propriétaire RBAC, de l’administrateur d’accès utilisateur et des rôles avec des autorisations DataActions. Pour plus d’informations, consultez Prise en charge des rôles pour Azure Lighthouse.
Les rôles d’accès propriétaire et utilisateur sont généralement requis dans tous les scénarios de déploiement de zone d’atterrissage Azure. Cette exigence élimine Azure Lighthouse en tant qu’option pour l’ensemble de l’aspect d’automatisation du déploiement de la plateforme de zones d’atterrissage Azure, mais elle reste utile dans certains scénarios. Pour plus d’informations, consultez Utilisation d’Azure Lighthouse dans des zones d’atterrissage multi-locataires.
Identités pour les administrateurs et développeurs de plateforme - Approche 2
Dans cette approche, les administrateurs de plateforme et les développeurs n’ont généralement besoin que de l’accès au locataire Microsoft Entra de gestion. Cet accès leur accorde l’accès aux outils de développement, comme GitHub ou Azure DevOps, sur lesquels tous les locataires sont déployés et à partir desquels ils sont exploités.
Ils peuvent avoir accès à d’autres locataires Microsoft Entra via Microsoft Entra B2B ou Azure Lighthouse. Ils utilisent leur même compte à partir du locataire gestionnaire, ou ils peuvent avoir des comptes distincts, comme l’exemple de la première approche.