Isolation des ressources avec plusieurs locataires

Article
10/27/2023

Dans certains scénarios, la délégation de l’administration dans la limite d’un seul locataire ne répond pas à vos besoins. Dans cette section, il y a des exigences qui peuvent vous conduire à créer une architecture multilocataire. Les organisations multilocataires peuvent englober deux locataires Microsoft Entra ou plus. Ce scénario peut entraîner des exigences uniques en termes de gestion et de collaboration entre locataires. Les architectures multilocataires augmentent la charge et la complexité de gestion et doivent être utilisées avec précaution. Nous vous recommandons d’utiliser un seul locataire si vos besoins peuvent être satisfaits avec cette architecture. Pour plus d’informations, consultez Gestion multilocataire des utilisateurs.

Un locataire distinct crée une nouvelle limite et donc une gestion dissociée des rôles d’annuaire Microsoft Entra, des objets annuaire, des stratégies d’accès conditionnel, des groupes de ressources Azure, des groupes d’administration Azure et des autres contrôles comme décrit dans les sections précédentes.

Un locataire distinct est utile pour le service informatique d’une organisation. Il permet de vérifier les modifications à l’échelle du locataire dans les services Microsoft tels qu’Intune et Microsoft Entra Connect ou une configuration d’authentification hybride, tout en protégeant les utilisateurs et les ressources de l’organisation. Ceci inclut les tests des configurations de service pouvant avoir un impact à l’échelle du locataire et qui ne peuvent pas être limités à un sous-ensemble d’utilisateurs dans le locataire de production.

Le déploiement d’un environnement hors production dans un locataire distinct peut être nécessaire pour le développement d’applications personnalisées pouvant modifier les données des objets utilisateur de production avec MS Graph ou des API similaires (par exemple, des applications ayant l’autorisation Directory.ReadWrite.All ou une étendue large similaire).

Remarque

La synchronisation de Microsoft Entra Connect avec plusieurs locataires peut être utile pour le déploiement d’un environnement hors production dans un locataire distinct. Pour plus d’informations, consultez Microsoft Entra Connect : Topologies prises en charge.

Résultats

Au-delà des résultats obtenus avec une architecture monolocataire comme décrit précédemment, les organisations peuvent dissocier entièrement les interactions entre les ressources et les locataires :

Séparation des ressources

Visibilité : Les ressources dans un locataire distinct ne peuvent pas être découvertes ou énumérées par les utilisateurs et les administrateurs d’autres locataires. De même, les rapports d’utilisation et les journaux d’audit sont contenus dans la nouvelle limite du locataire. Cette séparation de la visibilité permet aux organisations de gérer les ressources nécessaires aux projets confidentiels.
Empreinte d’objet : Les applications qui écrivent dans Microsoft Entra ID et/ou d’autres services Microsoft Online par le biais de Microsoft Graph ou d’autres interfaces de gestion peuvent fonctionner dans un espace objet distinct. Ceci permet aux équipes de développement d’effectuer des tests pendant le cycle de vie de développement sans affecter d’autres locataires.
Quotas : La consommation de quotas et limites Azure à l’échelle du locataire est séparée de celle des autres locataires.

Séparation de configuration

Un nouveau locataire fournit un ensemble distinct de paramètres à l’échelle du locataire, qui peuvent prendre en charge les ressources et les applications d’approbation dont les exigences impliquent différentes configurations au niveau du locataire. En outre, un nouveau locataire fournit un nouvel ensemble de services Microsoft Online tels qu’Office 365.

Séparation administrative

Une nouvelle limite de locataire implique un ensemble distinct de rôles d’annuaire Microsoft Entra, ce qui vous permet de configurer différents ensembles d’administrateurs.

Utilisation courante

Le diagramme suivant illustre une utilisation courante de l’isolation des ressources dans plusieurs locataires : un environnement de préproduction ou de « bac à sable » qui nécessite un degré de séparation supérieur à celui que peut offrir l’administration déléguée dans un seul locataire.

Diagramme montrant un scénario d’utilisation courant.

Contoso est une organisation qui a étendu son architecture de locataire d’entreprise avec un locataire de préproduction appelé ContosoSandbox.com. Le locataire de bac à sable est utilisé pour prendre en charge le développement continu de solutions d’entreprise qui écrivent dans Microsoft Entra ID et Microsoft 365 à l’aide de Microsoft Graph. Ces solutions sont déployées dans le locataire d’entreprise.

Le locataire de bac à sable est mis en ligne pour éviter que les applications en cours de développement impactent directement ou indirectement les systèmes de production en consommant des ressources du locataire et en affectant des quotas ou une limitation.

Les développeurs ont besoin d’accéder au locataire de bac à sable pendant le cycle de vie de développement, idéalement avec un accès en libre-service nécessitant des autorisations supplémentaires limitées dans l’environnement de production. Ces autorisations supplémentaires peuvent inclure, par exemple, la création, la suppression et la mise à jour de comptes d’utilisateur, l’inscription d’applications, le provisionnement et le déprovisionnement de ressources Azure et la modification de stratégies ou de la configuration globale de l’environnement.

Dans cet exemple, Contoso utilise Microsoft Entra B2B Collaboration afin de provisionner des utilisateurs à partir du locataire d’entreprise pour permettre aux utilisateurs d’accéder aux ressources dans les applications du locataire de bac à sable et de les gérer sans qu’il soit nécessaire de gérer plusieurs informations d’identification. Cette capacité est principalement destinée aux scénarios de collaboration inter-organisations. Toutefois, les entreprises ayant plusieurs locataires (comme Contoso) peuvent l’utiliser pour éviter les complexités supplémentaires liées à l’administration du cycle de vie des informations d’identification et à l’expérience utilisateur.

Utilisez les paramètres d’accès entre locataires des identités externes pour gérer la manière dont vous collaborez avec d’autres organisations Microsoft Entra via la collaboration B2B. Ces paramètres déterminent à la fois le niveau d’accès entrant dont disposent les utilisateurs des organisations Microsoft Entra externes à vos ressources et le niveau d’accès sortant dont disposent vos utilisateurs aux organisations externes. Ils vous permettent également de faire confiance à l'authentification multifacteur (MFA) et aux revendications d'appareil (revendications conformes et revendications jointes hybrides Microsoft Entra) provenant d'autres organisations Microsoft Entra. Pour plus de détails et de considérations de planification, consultez Accès entre locataires dans Microsoft Entra External ID.

Une autre approche consisterait à utiliser les capacités de Microsoft Entra Connect pour synchroniser les mêmes informations d’identification Microsoft Entra locales avec plusieurs locataires en conservant le même mot de passe, mais en différenciant le domaine UPN des utilisateurs.

Isolation des ressources dans une architecture multilocataire

Avec un nouveau locataire, vous disposez d’un ensemble distinct d’administrateurs. Les organisations peuvent choisir d’utiliser des identités d’entreprise par le biais deMicrosoft Entra B2B Collaboration. De même, les organisations peuvent implémenter Azure Lighthouse pour la gestion interlocataire des ressources Azure afin que les abonnements Azure hors production puissent être gérés par des identités dans l’équivalent de production. Azure Lighthouse ne peut pas être utilisé pour gérer des services externes à Azure comme Microsoft Intune. Pour les fournisseurs de services managés, Microsoft 365 Lighthouse est un portail d’administration qui permet de sécuriser et de gérer des appareils, des données et des utilisateurs à grande échelle pour les clients de petite et moyenne entreprise qui utilisent Microsoft 365 Business Premium, Microsoft 365 E3 ou Windows 365 Business.

Ceci permettra aux utilisateurs de continuer à utiliser leurs informations d’identification d’entreprise tout en profitant des avantages de la séparation.

Microsoft Entra B2B Collaboration dans les locataires de bac à sable doit être configuré pour autoriser l’intégration d’identités de l’environnement d’entreprise uniquement à l’aide de listes vertes/d’exclusion Azure B2B. Pour les locataires que vous souhaitez autoriser pour la collaboration B2B, envisagez d’utiliser les paramètres d’accès interlocataire External Identities pour l’approbation interlocataire de l’authentification multifacteur/d’appareils.

Important

Les architectures multilocataires pour lesquelles l’accès avec identité externe est activé permettent uniquement l’isolation des ressources, mais pas l’isolation des identités. L’isolation des ressources à l’aide de Microsoft Entra B2B Collaboration et d’Azure Lighthouse n’atténue pas les risques liés aux identités.

Si l’environnement de bac à sable partage des identités avec l’environnement d’entreprise, les scénarios suivants s’appliquent au locataire de bac à sable :

Un acteur malveillant qui compromet un utilisateur, un appareil ou une infrastructure hybride dans le locataire d’entreprise et qui est invité dans le locataire de bac à sable peut accéder aux applications et ressources du locataire de bac à sable.
Une erreur opérationnelle (par exemple, la suppression d’un compte d’utilisateur ou la révocation d’informations d’identification) dans le locataire d’entreprise peut impacter l’accès d’un utilisateur invité au locataire de bac à sable.

Vous devez effectuer l’analyse des risques et éventuellement envisager l’isolation des identités par le biais de plusieurs locataires pour les ressources vitales pour l’entreprise, nécessitant une approche hautement défensive. Azure Privileged Identity Management peut contribuer à atténuer certains risques en imposant une sécurité supplémentaire pour l’accès aux ressources et locataires vitaux pour l’entreprise.

Objets annuaire

Le locataire que vous utilisez pour isoler les ressources peut contenir les mêmes types d’objets, de ressources Azure et d’applications d’approbation que votre locataire principal. Vous devrez peut-être provisionner les types d’objets suivants :

Utilisateurs et groupes : identités requises par les équipes d’ingénierie de solution, par exemple :

Administrateurs d’environnement de bac à sable
Propriétaires techniques d’applications
Développeurs d’applications métier
Comptes d’utilisateur final de test

Ces identités peuvent être provisionnées pour :

Les employés utilisant leur compte d’entreprise par le biais d’Microsoft Entra B2B Collaboration.
Les employés qui ont besoin de comptes locaux pour l’administration, l’accès administratif d’urgence ou d’autres raisons techniques

Les clients possédant ou nécessitant un environnement Active Directory hors production local peuvent également synchroniser leurs identités locales avec le locataire de bac à sable si les ressources et applications sous-jacentes l’exigent.

Appareils : le locataire hors production contient un nombre réduit d’appareils (à hauteur des besoins du cycle d’ingénierie de la solution) :

Stations de travail d’administration
Appareils mobiles et ordinateurs hors production nécessaires au développement, aux tests et à la documentation

Applications

Applications intégrées Microsoft Entra : objets d’application et principaux de service pour :

Instances de test des applications déployées en production (par exemple, les applications qui écrivent dans Microsoft Entra ID et les services en ligne Microsoft).
Services d’infrastructure pour administrer et gérer le locataire hors production, éventuellement un sous-ensemble des solutions disponibles dans le locataire d’entreprise

Microsoft Online Services :

En règle générale, l’équipe propriétaire des services Microsoft Online Services en production doit être celle qui possède l’instance hors production de ces services.
Les administrateurs d’environnements de test hors production ne doivent pas provisionner de services Microsoft Online Services, sauf si ces services sont spécifiquement testés. Ceci évite l’utilisation inappropriée des services Microsoft, par exemple la configuration de sites SharePoint de production dans un environnement de test.
De même, le provisionnement des services Microsoft Online Services qui peuvent être initiés par les utilisateurs finaux (également appelés abonnements ad hoc) doit être verrouillé. Pour plus d’informations, consultez Présentation de l’inscription en libre-service pour Microsoft Entra ID.
En règle générale, toutes les fonctionnalités sous licence non essentielles doivent être désactivées pour le locataire à l’aide de licences par groupe. Cette opération doit être effectuée par l’équipe qui gère les licences dans le locataire de production pour éviter toute configuration incorrecte par les développeurs qui ne connaissent peut-être pas l’impact de l’activation des fonctionnalités sous licence.

Ressources Azure

Toutes les ressources Azure nécessaires aux applications d’approbation peuvent également être déployées, Par exemple, les bases de données, les machines virtuelles, les conteneurs, les fonctions Azure, et ainsi de suite. Pour votre environnement de bac à sable, vous devez peser les économies d’utilisation de références SKU moins coûteuses pour les produits et services avec les fonctionnalités de sécurité moins disponibles.

Le modèle RBAC pour le contrôle d’accès doit toujours être utilisé dans un environnement hors production au cas où les modifications seraient répliquées en production à l’issue des tests. Sinon, les failles de sécurité de l’environnement hors production peuvent se propager à votre locataire de production.

Isolation des ressources et des identités avec plusieurs locataires

Résultats de l’isolation

Dans certaines situations, l’isolation des ressources seule ne répond pas à vos besoins. Vous pouvez isoler les ressources et les identités dans une architecture multilocataire en désactivant toutes les fonctionnalités de collaboration interlocataire et en créant efficacement une limite d’identité distincte. Cette approche offre une défense contre les erreurs opérationnelles et la compromission des identités utilisateur, des appareils ou de l’infrastructure hybride dans les locataires d’entreprise.

Utilisation courante de l’isolation

Une limite d’identité distincte est généralement utilisée pour les applications et ressources vitales pour l’entreprise comme les services côté client. Dans ce scénario, Fabrikam a décidé de créer un locataire distinct pour son produit SaaS côté client afin d’éviter le risque de compromission des identités d’employé affectant ses clients SaaS. Le diagramme suivant illustre cette architecture :

Le locataire FabrikamSaaS contient les environnements utilisés pour les applications proposées aux clients dans le cadre du modèle commercial de Fabrikam.

Isolation des objets annuaire

Les objets annuaire dans FabrikamSaas sont les suivants :

Utilisateurs et groupes : les identités nécessaires aux équipes informatiques en charge de la solution, aux équipes du support technique ou à d’autres équipes requises sont créées dans le locataire SaaS. Pour préserver l’isolation, seuls des comptes locaux sont utilisés et Microsoft Entra B2B Collaboration n’est pas activé.

Objets annuaire Azure AD B2C : si les clients accèdent aux environnements de locataire, ils peuvent contenir un locataire Azure AD B2C et les objets d’identité associés. Les abonnements qui contiennent ces annuaires se prêtent bien à un environnement isolé côté consommateurs.

Appareils : ce locataire contient un nombre réduit d’appareils (uniquement ceux qui sont nécessaires à l’exécution des solutions côté client) :

Stations de travail d’administration sécurisées
Stations de travail des équipes de support (pouvant inclure des ingénieurs « de garde » comme décrit plus haut)

Isolation des applications

Applications intégrées Microsoft Entra : objets d’application et principaux de service pour :

Applications de production (par exemple, définitions d’applications multilocataires).
Services d’infrastructure pour l’administration et la gestion de l’environnement côté client.

Ressources Azure : hébergement des ressources IaaS, PaaS et SaaS des instances de production côté client.

Partage via