Zones d’atterrissage Azure et plusieurs locataires Microsoft Entra

Les zones d’atterrissage Azure sont basées sur des groupes d’administration. Des stratégies Azure sont affectées, et les abonnements sont placés dans des groupes d’administration pour fournir les contrôles de gouvernance requis dont une organisation a besoin pour répondre à ses besoins en matière de sécurité et de conformité.

Ces ressources sont déployées dans un seul locataire Microsoft Entra. Les groupes d’administration et la plupart des autres ressources Azure, comme Azure Policy, prennent en charge seulement le fonctionnement au sein d’un seul locataire Microsoft Entra. Un abonnement Azure s’appuie sur un locataire Microsoft Entra pour authentifier les utilisateurs, les services et les appareils auprès d’Azure Resource Manager (ARM) afin de contrôler les opérations de plan et certains services Azure, comme Stockage Azure, pour les opérations de plan de données.

Plusieurs abonnements peuvent s’appuyer sur le même locataire Microsoft Entra. Chaque abonnement peut s’appuyer seulement sur un locataire Microsoft Entra. Pour plus d’informations, consultez Ajouter un abonnement Azure existant à votre locataire .

Dans le diagramme précédent, les groupes d’administration, les stratégies Azure et les abonnements Azure sont déployés en suivant l’architecture conceptuelle des zones d’atterrissage Azure au sein d’un même locataire Microsoft Entra.

Cette approche est recommandée pour la plupart des organisations, sur la base de leurs besoins. Cette approche offre aux organisations la meilleure expérience de collaboration possible et leur permet de contrôler, de gouverner et d’isoler les utilisateurs et les ressources au sein d’un même locataire Microsoft Entra.

Votre organisation peut être tenue d’utiliser plusieurs locataires Microsoft Entra pour de nombreux scénarios. Découvrez comment déployer et gérer le déploiement d’une zone d’atterrissage Azure dans chacun de ces locataires ainsi que des considérations et recommandations relatives à la gestion de plusieurs locataires Microsoft Entra.

Pourquoi un seul locataire Microsoft Entra est suffisant

Pour certaines raisons, vous pouvez avoir besoin de plusieurs locataires Microsoft Entra, mais il est important de comprendre pourquoi un seul locataire Microsoft Entra est généralement suffisant. Il doit s’agir du point de départ par défaut pour toutes les organisations.

Utilisez votre locataire Microsoft Entra d’entreprise existant pour les abonnements Azure afin de bénéficier d’une expérience de productivité et de collaboration optimale sur la plateforme.

Au sein d’un seul locataire, les équipes de développement et les propriétaires d’applications peuvent avoir les rôles les moins privilégiés pour créer des instances hors production de ressources Azure et d’applications approuvées, tester des applications, tester des utilisateurs et des groupes, et tester des stratégies pour ces objets. Pour plus d’informations sur la façon de déléguer l’administration à un seul locataire, consultez Isolation des ressources dans un seul locataire.

Créez plus de locataires Microsoft Entra seulement quand des exigences ne peuvent pas être satisfaites en utilisant le locataire Microsoft Entra d’entreprise.

Avec Microsoft 365, le locataire Microsoft Entra d’entreprise est généralement le premier locataire provisionné dans l’organisation. Ce locataire est utilisé pour l’accès aux applications d’entreprise et les services Microsoft 365. Il prend en charge la collaboration au sein d’une organisation. La raison de commencer avec ce locataire existant est qu’il a déjà été provisionné, géré et sécurisé. Le cycle de vie défini des identités est probablement déjà établi. Ce cours facilite l’intégration de nouvelles applications et ressources, et de nouveaux abonnements. Il s’agit d’un environnement mature et compris avec des processus, des procédures et des contrôles établis.

Complexités liées à des locataires Microsoft Entra multiples

Quand vous créez un locataire Microsoft Entra, il nécessite un travail supplémentaire pour provisionner, gérer, sécuriser et gouverner les identités. Vous devez également établir les stratégies et procédures requises. La collaboration est optimale dans un seul locataire Microsoft Entra. Le passage à un modèle multilocataire crée une limite, ce qui peut entraîner des frictions utilisateur, une surcharge de gestion et une augmentation de la surface d’attaque, ce qui peut entraîner un risque de sécurité et complique les scénarios de produit et les limitations. Voici quelques exemples :

• Plusieurs identités pour les utilisateurs et les administrateurs pour chaque locataire : si Microsoft Entra B2B n’est pas utilisé, l’utilisateur a plusieurs ensembles d’informations d’identification à gérer. Pour plus d’informations, consultez Considérations et recommandations pour les scénarios de zone d’atterrissage Azure mutualisées.
• Limitations des services Azure dans la prise en charge de plusieurs locataires Microsoft Entra : les charges de travail Azure qui prennent en charge les identités hébergées dans le locataire auquel elles sont liées. Pour plus d’informations, consultez Intégration des produits et services Azure Microsoft Entra.
• Pas de configuration ou de gestion centralisée pour les locataires Microsoft Entra : plusieurs stratégies de sécurité, stratégies de gestion, configurations, portails, API et processus JML (Joiners, Movers et Leavers).
• Complexités de facturation et de licences et exigences potentielles en matière de duplication de licences pour les licences Microsoft Entra ID P1 ou P2 - Pour plus d’informations, consultez Considérations et recommandations relatives aux scénarios de zone d’atterrissage Azure mutualisées.

Les organisations doivent connaître précisément la raison pour laquelle elles s’écartent du modèle de locataire Microsoft Entra d’entreprise pour être sûres que la charge et la complexité supplémentaires sont justifiées pour répondre aux exigences. Il existe des exemples de ces instances dans l’article de scénarios.

La propriété des rôles privilégiés au sein des équipes et des départements internes peut constituer un défi, car l'équipe Identity et l'équipe Azure font souvent partie d'équipes, de départements et de structures organisationnelles différents.

Les équipes qui exploitent Azure sont responsables des services Azure et souhaitent garantir la sécurité des services qu’elles gèrent. Lorsque des personnes extérieures à cette équipe ont des rôles avec le pouvoir d’accéder potentiellement à leurs environnements, la sécurité est plus faible. Pour plus d’informations, consultez Comprendre les fonctions cloud requises.

Microsoft Entra ID fournit des contrôles qui permettent d’atténuer ce problème au niveau technique, mais il s’agit également d’une question de personnes et de processus. Pour plus d’informations, consultez Recommandations.

Étapes suivantes