Partager via


Concevoir une architecture multilocataire pour les grandes institutions

Une architecture monolocataire est recommandée pour les établissements de petite taille. Toutefois, pour les organisations qui ont plus d’un million d’utilisateurs, nous recommandons une architecture multilocataire pour atténuer les problèmes de performances et les limitations des locataires, telles que l’abonnement et les quotas Azure et les limites et restrictions de service Microsoft Entra.

Principes de conception

Lors de la conception de votre architecture mutualisée, tenez compte des principes de conception suivants pour réduire les coûts et augmenter l’efficacité et la sécurité :

  • Réduire les coûts

  • Augmenter l’efficacité

    • Normalisez l’architecture, les configurations et les processus entre les locataires pour réduire les problèmes administratifs.

    • Réduire la nécessité pour les utilisateurs de passer d’un locataire à un autre

  • Renforcer la sécurité

    • Concentrez-vous sur la sécurisation des données des étudiants.

    • Suivez le principe du privilège minimum : accordez uniquement les privilèges nécessaires pour effectuer les tâches nécessaires et implémentez l’accès juste-à-temps (JIT).

    • Autoriser l’accès des utilisateurs externes uniquement via la gestion des droits d’utilisation ou Microsoft Entra collaboration B2B.

    • Déléguer l’administration de tâches spécifiques à des utilisateurs spécifiques disposant d’un accès suffisant (JEA) pour effectuer le travail.

Raisons courantes pour plusieurs locataires

Nous recommandons vivement aux organisations comptant moins d’un million d’utilisateurs de créer un seul locataire, sauf si d’autres critères indiquent la nécessité de plusieurs locataires. Pour les organisations avec 1 million d’objets utilisateur ou plus, nous recommandons plusieurs locataires à l’aide d’une approche régionale.

La création de locataires distincts a les effets suivants sur votre environnement EDU.

  • Séparation administrative

    • Peut limiter l’impact d’une erreur de sécurité administrative ou opérationnelle sur les ressources critiques.

    • Peut limiter l’impact des comptes d’administrateur ou d’utilisateur compromis.

    • Les rapports d’utilisation et les journaux d’audit sont contenus dans un locataire.

  • Séparation des ressources

    • Confidentialité des étudiants. Les objets utilisateur d’étudiant ne peuvent être découverts que dans le locataire dans lequel l’objet réside.

    • Isolation des ressources. Les ressources d’un locataire distinct ne peuvent pas être découvertes ou énumérées par les utilisateurs et les administrateurs d’autres locataires.

    • Empreinte de l’objet. Les applications qui écrivent dans Microsoft Entra ID et d’autres services Microsoft Online via Microsoft Graph ou d’autres interfaces de gestion peuvent affecter uniquement les ressources du locataire local.

    • Quotas. La consommation des quotas et limites Azure à l’échelle du locataire est séparée de celle des autres locataires.

  • Séparation de la configuration

    • Fournit un ensemble distinct de paramètres à l’échelle du locataire qui peuvent prendre en charge les ressources et les applications d’approbation qui ont des exigences de configuration différentes.

    • Active un nouvel ensemble de services Microsoft Online tels que Office 365.

En plus d’avoir plus d’un million d’utilisateurs, les considérations suivantes peuvent conduire à plusieurs locataires.

  • Considérations administratives

    • Vous travaillez en vertu de réglementations qui limitent qui peut administrer l’environnement en fonction de critères tels que le pays de citoyenneté, le pays de résidence ou le niveau d’autorisation.

    • Vous avez des exigences de conformité, telles que la confidentialité des données des étudiants, qui vous obligent à créer des identités dans des régions locales spécifiques.

  • Considérations relatives aux ressources

    • Vous disposez de ressources, peut-être pour la recherche et le développement, que vous devez protéger contre la découverte, l’énumération ou la prise de contrôle par les administrateurs existants pour des raisons réglementaires ou critiques pour l’entreprise.

    • Cycle de développement d’applications personnalisées qui peuvent modifier les données des utilisateurs avec MS Graph ou des API similaires à grande échelle (par exemple, les applications qui reçoivent Directory.ReadWrite.All)

  • Considérations relatives à la configuration

    • Ressources dont les exigences sont en conflit avec les postures de collaboration ou de sécurité existantes à l’échelle du locataire, telles que les types d’authentification autorisés, les stratégies de gestion des appareils, la possibilité de libre-service ou la vérification des identités pour les identités externes.

Déterminer l’approche multilocataire

Dans cette section, nous considérons une université fictive nommée School of Fine Arts avec 2 millions d’étudiants dans 100 écoles à travers le États-Unis. Dans ces écoles, il y a au total 130 000 enseignants et 30 000 employés et employés à temps plein.

Nous recommandons une approche régionale lors du déploiement de plusieurs locataires comme suit :

  1. Commencez par diviser votre communauté d’étudiants et d’enseignants par des régions géographiques où chaque région contient moins d’un million d’utilisateurs.

  2. Créez un locataire Microsoft Entra pour chaque région.

    approche multilocataire.

  3. Provisionnez le personnel, les enseignants et les étudiants dans leur région correspondante pour optimiser les expériences de collaboration.

    provisionnement dans les locataires.

Pourquoi utiliser des régions ?

Une approche régionale est recommandée pour réduire le nombre d’utilisateurs qui se déplacent d’un locataire à l’autre. Si vous avez créé un locataire pour chaque niveau scolaire (par exemple, les écoles primaires, les collèges et les écoles secondaires), vous devrez migrer les utilisateurs à la fin de chaque année scolaire. Si au lieu de cela, les utilisateurs restent dans la même région, vous n’avez pas besoin de les déplacer entre les locataires à mesure que leurs attributs changent.

D’autres avantages d’une approche régionale sont les suivants :

  • Collaboration optimale dans chaque région

  • Nombre minimal d’objets invités provenant d’autres locataires sont nécessaires

Lorsqu’un locataire compte plus d’un million d’utilisateurs, les expériences et les outils de gestion ont tendance à se dégrader au fil du temps. De même, certaines expériences de l’utilisateur final, telles que l’utilisation du sélecteur de personnes, deviendront fastidieuses et peu fiables.

Les petites organisations qui choisissent de déployer plusieurs locataires sans raison convaincante augmentent inutilement leur charge de gestion et le nombre de migrations d’utilisateurs. Cela nécessite également des étapes pour garantir des expériences de collaboration entre les locataires.

Collaborer entre locataires à l’aide de Microsoft Entra collaboration B2B

Microsoft Entra B2B Collaboration permet aux utilisateurs d’utiliser un ensemble d’informations d’identification pour se connecter à plusieurs locataires. Pour les établissements d’enseignement, les avantages de la collaboration B2B sont les suivants :

  • Équipe d’administration centralisée gérant plusieurs locataires

  • Collaboration des enseignants entre les régions

  • Intégration des parents et tuteurs avec leurs propres informations d’identification

  • Partenariats externes comme les entrepreneurs ou les chercheurs

Avec B2B Collaboration, un compte d’utilisateur créé dans un locataire (son locataire d’origine) est invité en tant qu’utilisateur invité à un autre locataire (locataire de ressource) et l’utilisateur peut se connecter à l’aide des informations d’identification de son locataire d’origine. Les administrateurs peuvent également utiliser B2B Collaboration pour permettre aux utilisateurs externes de se connecter avec leurs comptes sociaux ou d’entreprise existants en configurant la fédération avec des fournisseurs d’identité tels que Facebook, des comptes Microsoft, Google ou un fournisseur d’identité d’entreprise.

Membres et invités

Les utilisateurs d’un locataire Microsoft Entra sont des membres ou des invités en fonction de leur propriété UserType. Par défaut, les utilisateurs membres sont ceux qui sont natifs du locataire. Un utilisateur Microsoft Entra B2B Collaboration est ajouté en tant qu’utilisateur avec UserType = Guest par défaut. Les invités disposent d’autorisations limitées dans le répertoire et les applications. Par exemple, les utilisateurs invités ne peuvent pas parcourir les informations du locataire au-delà de leurs propres informations de profil. Toutefois, un utilisateur invité peut récupérer des informations sur un autre utilisateur en fournissant le nom d’utilisateur principal (UPN) ou objectId. Un utilisateur invité peut également lire les propriétés des groupes auxquels il appartient, y compris l’appartenance au groupe, indépendamment du paramètre Des autorisations des utilisateurs invités sont limitées .

Dans certains cas, un locataire de ressource peut souhaiter traiter les utilisateurs du locataire d’origine comme des membres plutôt que des invités. Si c’est le cas, vous pouvez utiliser les API du gestionnaire d’invitations Microsoft Entra B2B pour ajouter ou inviter un utilisateur du locataire d’origine au locataire de ressource en tant que membre. Pour plus d’informations, consultez Propriétés d’un utilisateur Microsoft Entra B2B Collaboration.

Administration centralisée de plusieurs locataires

Intégrez des identités externes à l’aide de Microsoft Entra B2B. Les identités externes peuvent ensuite se voir attribuer des rôles privilégiés pour gérer Microsoft Entra locataires en tant que membres d’une équipe informatique centralisée. Vous pouvez également utiliser Microsoft Entra B2B pour créer des comptes invités pour d’autres membres du personnel, tels que des administrateurs au niveau régional ou de district.

Toutefois, les rôles spécifiques au service, tels que l’administrateur Exchange ou l’administrateur SharePoint, nécessitent un compte local natif de leur locataire. ​

Les rôles suivants peuvent être attribués à des comptes B2B

  • Administrateur de l'application

  • Développeur d’applications

  • Administrateur d’authentification

  • Administrateur de jeu de clés IEF B2C

  • Administrateur de stratégie IEF B2C

  • Administrateur de stratégie IEF d’application cloud B2C

  • Administrateur de stratégie IEF Cloud Device B2C

  • Administrateur de l’accès conditionnel

  • Administrateurs d’appareils

  • Jonction d’appareil

  • Utilisateurs de l’appareil

  • Lecteurs d’annuaire

  • Rédacteurs d'annuaires

  • Comptes de synchronisation d’annuaires

  • administrateur de flux utilisateur ID externe

  • administrateur d’attributs de flux utilisateur ID externe

  • Fournisseur d’identité externe

  • administrateur Groupes

  • Inviteur d’invités

  • Administrateur du support technique

  • Administrateur d’identité hybride

  • Administrateur du service Intune

  • Administrateur de licences

  • Administrateur de mot de passe

  • Administrateur d’authentification privilégié

  • Administrateur de rôle privilégié

  • Lecteur de rapports

  • Utilisateur invité restreint

  • Administrateur de sécurité

  • Lecteur de sécurité

  • Administrateur de compte d’utilisateur

  • Jonction d’appareil d’espace de travail

Les rôles d’administrateur personnalisés dans Microsoft Entra ID exposer les autorisations sous-jacentes des rôles intégrés, afin que vous puissiez créer et organiser vos propres rôles personnalisés. Cette approche vous permet d’accorder l’accès de manière plus précise que les rôles intégrés, chaque fois qu’ils sont nécessaires.

Voici un exemple illustrant le fonctionnement de l’administration pour les rôles d’administration qui peuvent être délégués et utilisés sur plusieurs locataires.

Le compte natif de Susie se trouve dans le locataire région 1, et Microsoft Entra B2B est utilisé pour ajouter le compte en tant qu’administrateur d’authentification à l’équipe informatique centrale dans les locataires pour la région 2 et la région 3.

administration centralisée.

Utilisation d’applications sur plusieurs locataires

Pour atténuer les problèmes associés à l’administration des applications dans un environnement multilocataire, vous devez envisager d’écrire des applications multilocataires. Vous devez également vérifier laquelle de vos applications SaaS prend en charge plusieurs connexions IdP. Les applications SaaS qui prennent en charge plusieurs connexions de fournisseur d’identité doivent configurer des connexions individuelles sur chaque locataire. Les applications SaaS qui ne prennent pas en charge plusieurs connexions de fournisseur d’identité peuvent nécessiter des instances indépendantes. Pour plus d’informations, consultez Guide pratique pour connecter n’importe quel utilisateur Microsoft Entra à l’aide du modèle d’application multilocataire.

Remarque : Les modèles de licence peuvent varier d’une application SaaS à l’autre. case activée avec le fournisseur pour déterminer si plusieurs abonnements seront nécessaires dans un environnement multilocataire.

Administration par locataire

L’administration par locataire est requise pour les rôles spécifiques au service. Les rôles spécifiques au service nécessitent d’avoir un compte local natif du locataire. En plus d’avoir une équipe informatique centralisée dans chaque locataire, vous devez également avoir une équipe informatique régionale dans chaque locataire pour gérer les charges de travail telles qu’Exchange, SharePoint et Teams.

Les rôles suivants nécessitent des comptes natifs pour chaque locataire

  • Administrateur Azure DevOps

  • Administrateur Information Protection Azure

  • Administrateur de facturation

  • Administrateur de service CRM

  • Administrateur de conformité

  • Administrateur de conformité des données

  • Approbateur d’accès Customer Lockbox

  • administrateur Analytique de bureau

  • Administrateur Exchange

  • Administrateur d’informations

  • Responsable de l’entreprise Insights

  • Administrateur Kaizala

  • Administrateur de service Lync

  • Lecteur de confidentialité du Centre de messages

  • Lecteur du Centre de messages

  • Administrateur d’imprimante

  • Technicien d’imprimante

  • Administrateur de recherche

  • Rédacteur de recherche

  • Opérateur de sécurité

  • Administrateur du service de prise en charge

  • Administrateur SharePoint

  • Administrateur des communications Teams

  • Ingénieur de support des communications Teams

  • Spécialiste du support des communications Teams

  • Administrateur du service Teams

Administrateurs uniques dans chaque locataire

Si vous avez une équipe informatique native dans chaque région, vous pouvez faire en sorte que l’un de ces administrateurs locaux gère l’administration de Teams. Dans l’exemple suivant, Charles réside dans le locataire région 1 et a le rôle d’administrateur de service Teams. Alice et Ichiro résident respectivement dans les régions 2 et 3 et ont le même rôle dans leurs régions. Chaque administrateur local a un seul compte natif de sa région.

Image 7.

Administration rôles entre les locataires

Si vous n’avez pas de pool d’administrateurs locaux dans chaque région, vous pouvez attribuer le rôle Administrateur de service Teams à un seul utilisateur. Dans ce scénario, comme illustré ci-dessous, bob de l’équipe informatique centrale peut agir en tant qu’administrateur de service Teams dans les trois locataires en créant un compte local pour Bob dans chaque locataire.

Image 9.

Délégation de rôles d’administrateur au sein d’un locataire

Les unités administratives doivent être utilisées pour regrouper logiquement Microsoft Entra utilisateurs et groupes. La restriction de l’étendue administrative à l’aide d’unités administratives est utile dans les organisations éducatives composées de différentes régions, districts ou écoles.

Par exemple, notre école fictive des beaux-arts est répartie dans trois régions, chacune contenant plusieurs écoles. Chaque région dispose d’une équipe d’administrateurs informatiques qui contrôlent l’accès, gèrent les utilisateurs et définissent des stratégies pour leurs écoles respectives.

Par exemple, un administrateur informatique peut :

  • Créez une unité d’organisation pour les utilisateurs de chacune des écoles de la région 1, afin de gérer tous les utilisateurs de cette école. (non illustré)

  • Créez une unité d’organisation qui contient les enseignants de chaque école pour gérer les comptes d’enseignants.

  • Créez une unité d’organisation distincte qui contient les étudiants de chaque école pour gérer les comptes des étudiants.

  • Attribuez aux enseignants de l’école le rôle Administrateur de mots de passe pour l’AUTHENTIFICATION des étudiants, afin que les enseignants puissent réinitialiser les mots de passe des étudiants, mais pas les mots de passe des autres utilisateurs.

Unités administratives.

Les rôles qui peuvent être étendus aux unités administratives sont les suivants :

  • Administrateur d’authentification

  • administrateur Groupes

  • Administrateur du support technique

  • Administrateur de licences

  • Administrateur de mot de passe

  • Administrateur d’utilisateurs

Pour plus d’informations, consultez Attribuer des rôles délimités à une unité administrative.

Gestion interlocataire

Les paramètres sont configurés individuellement dans chaque locataire. Configurez ensuite dans le cadre de la création du locataire dans la mesure du possible pour éviter d’avoir à revoir ces paramètres. Bien que certaines tâches courantes puissent être automatisées, il n’existe pas de portail de gestion interlocataire intégré.

Gestion des objets à grande échelle

Microsoft Graph (MS Graph) et Microsoft Graph PowerShell vous permettent de gérer des objets d’annuaire à grande échelle. Ils peuvent également être utilisés pour gérer la plupart des stratégies et des paramètres de votre locataire. Toutefois, vous devez comprendre les considérations suivantes en matière de performances :

  • MS Graph limite la création d’utilisateurs, de groupes et de modifications d’appartenance à 72 000 par locataire et par heure.

  • Les performances de MS Graph peuvent être affectées par des actions pilotées par l’utilisateur, telles que des actions de lecture ou d’écriture au sein du locataire

  • Les performances de MS Graph peuvent être affectées par d’autres tâches d’administrateur informatique concurrentes au sein du locataire

  • PowerShell, SDS, Microsoft Entra Connect et les solutions d’approvisionnement personnalisées ajoutent des objets et des appartenances via MS Graph à des tarifs différents

Étapes suivantes

Si vous n’avez pas consulté Présentation des locataires Microsoft Entra, vous pouvez le faire. Consultez les rubriques suivantes :