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’entre elles, une ou plusieurs fois, l’automatisation est essentielle. L’automatisation 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 prenez 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 un fournisseur 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, qu’il soit prévu ou par erreur, réduit.
Les sections suivantes fournissent des diagrammes et des conseils sur les approches que vous pouvez adopter. Choisissez l’approche la mieux adaptée à 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.
Note
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 multilocataires. Cette approche maintient la séparation et l’isolation requises entre les locataires Microsoft Entra, ce qui est la condition la plus courante lors de l’utilisation d’une approche multilocataire.
L’Approche 2 : Inscription d’applications partagées (multilocataire) 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 sous forme d’exemples et d’inspiration. Vous pouvez combiner et mettre en correspondance 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 votre organisation dispose. 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 Plateforme et zones d’atterrissage des applications.
Approche 1 : isolation complète
Dans cette approche, l’objectif principal est de garder chaque client Microsoft Entra isolé des autres dans tous les composants d’automatisation, comme :
- Référentiel Git.
- GitHub Actions ou Azure Pipelines (y compris les exécuteurs autohébergés, s’ils sont utilisés).
- Identités utilisées pour effectuer des tâches dans le cadre de l’automatisation, telles que les identités gérées assignées à des exécuteurs auto-hébergés, des Noms de Principal de Service (SPN), des utilisateurs ou des administrateurs.
Dans cette approche, il y a davantage de composants à gérer, qui sont dupliqués pour chaque locataire Microsoft Entra. Certaines organisations peuvent avoir des contrôles de conformité réglementaires appliqués à eux qui imposent ce type de ségrégation et d’isolement.
Remarque
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 individuellement à chaque locataire. Les identités managées ne prennent pas en charge les scénarios multilocataires mis à la disposition générale aujourd’hui. Pour plus d’informations, consultez cette FAQ.
Toutefois, cette fonctionnalité est désormais disponible en préversion publique pour les identités managées affectées par l’utilisateur en configurant une confiance entre elle-même et une application multilocataire Entra ID. Consultez plus d’informations sur la configuration de ce paramètre dans Configurer une application pour approuver une identité managée (préversion). Cela peut désormais faire de l’Approche 2 : Inscription d’applications partagées (multilocataire) avec plusieurs principaux de service une option viable pour votre déploiement.
Identités pour les administrateurs et les développeurs de la 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 de plateforme ou développeur nécessite un compte d’utilisateur distinct au sein de chaque locataire pour effectuer des opérations au sein de ce locataire. Ces comptes sont également utilisés pour accéder aux outils de développement, tels que GitHub ou Azure DevOps, pour chacun des locataires. Examinez attentivement les effets de la productivité de l’administrateur et du développeur en suivant cette approche.
Microsoft Entra B2B et/ou Azure Lighthouse peuvent être utilisés, mais cette option interroge le raisonnement pour avoir des locataires Microsoft Entra distincts.
Approche 2 : Inscription d’applications partagée (multilocataire) 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’application unique et les applications d’entreprise associées (principaux de service) doivent être surveillés pour toute activité anormale dans vos outils SIEM (Security Information and Event Management), car il s’agit d’un compte hautement privilégié. Il doit envoyer des alertes et éventuellement prendre des mesures, en fonction de la gravité de l’alerte.
Dans l'exemple précédent, un enregistrement d'application unique se trouve dans le locataire contoso.onmicrosoft.com de Microsoft Entra, et une application d'entreprise se trouve dans chacun des locataires Microsoft Entra liés à cet enregistrement 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 et Accorder le consentement administrateur au niveau locataire à une application.
Conseil
Les Identités managées attribuées par l’utilisateur, en préversion publique, peuvent désormais prendre en charge des scénarios multilocataires en configurant une confiance entre elles et une application multilocataire Entra ID. Consultez plus d’informations sur la configuration de ce paramètre dans Configurer une application pour approuver une identité managée (préversion).
Lorsque vous utilisez un pipeline centralisé, vous devrez peut-être créer une petite table de mappage qui contient des données qui correspondent aux locataires Microsoft Entra et à d’autres métadonnées, telles que 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, tels qu’Azure Cosmos DB ou stockage Table Azure.
Lorsque vous gérez plusieurs environnements, tels que le développement, le test ou la production, ils peuvent être contrôlés de la même manière en utilisant les mêmes enregistrements d'applications ou des enregistrements séparés, ainsi que des applications d'entreprise avec des pipelines.
Vous pouvez décider d’avoir des pipelines distincts pour chaque locataire Microsoft Entra ou d’utiliser un seul pipeline. Le choix est le vôtre en fonction de vos besoins.
Note
Azure Lighthouse fonctionne de la même manière que cette approche, mais Azure Lighthouse n’autorise pas l’attribution du propriétaire RBAC, de l’administrateur de l’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 de propriétaire et d’accès utilisateur sont généralement requis dans tous les scénarios de déploiement de zone d’atterrissage Azure. Cette exigence supprime Azure Lighthouse comme option pour l’aspect complet du déploiement d’automatisation de plateforme des zones d’atterrissage Azure, mais il est toujours utile dans certains scénarios. Pour plus d’informations, consultez Utilisation d’Azure Lighthouse dans des zones d’atterrissage multilocataires.
Identités pour les administrateurs et les développeurs de la plateforme - Approche 2
Dans cette approche, les administrateurs de plateforme et les développeurs n’ont généralement besoin d’accéder qu’au locataire Microsoft Entra gérant. Cet accès leur accorde l’accès aux outils de développement, tels que GitHub ou Azure DevOps, à partir duquel tous les locataires sont déployés et gérés.
Ils peuvent avoir accès aux autres locataires Microsoft Entra via Microsoft Entra B2B ou Azure Lighthouse. Ils utilisent le même compte du locataire gestionnaire, ou ils peuvent avoir des comptes distincts, comme l’exemple dans la première approche.