Partager via


Isolation des ressources dans un seul locataire

De nombreux scénarios de séparation sont réalisables au sein d’un seul locataire. Si possible, nous vous recommandons de déléguer l’administration à des environnements distincts au sein d’un seul locataire afin de fournir la meilleure expérience de productivité et de collaboration pour votre organisation.

Résultats

Séparation des ressources – avec les rôles d'annuaire Microsoft Entra, les groupes de sécurité, les stratégies d'accès conditionnel, les groupes de ressources Azure, les groupes de gestion Azure, les unités administratives (AU) et d'autres contrôles, vous pouvez restreindre l'accès aux ressources à des utilisateurs, groupes et principaux de service spécifiques. Les ressources peuvent être gérées par des administrateurs distincts et avoir des utilisateurs, des autorisations et des exigences d’accès distincts.

Si un ensemble de ressources nécessite des paramètres uniques à l’échelle du locataire, s’il existe une tolérance de risque minimale pour l’accès non autorisé par les membres du locataire, ou si un impact critique peut être causé par des modifications de configuration, vous devez réaliser l’isolation dans plusieurs locataires.

Séparation de la configuration Dans certains cas, des ressources telles que les applications ont des dépendances sur les configurations à l’échelle du tenant, comme les méthodes d’authentification ou les emplacements nommés. Vous devez prendre en compte ces dépendances lors de l’isolation des ressources. Les administrateurs généraux peuvent configurer les paramètres des ressources et les paramètres à l’échelle du locataire qui affectent les ressources.

Si un ensemble de ressources nécessite des paramètres uniques à l’échelle du locataire, ou si les paramètres du locataire doivent être administrés par une autre entité, vous devez réaliser l’isolation avec plusieurs locataires.

Séparation administrative – Avec l'administration déléguée de Microsoft Entra ID, vous pouvez séparer l'administration des ressources telles que les applications et les API, les utilisateurs et les groupes, les groupes de ressources et les stratégies d'accès conditionnel.

Les administrateurs généraux peuvent découvrir et obtenir un accès total à toutes les ressources de confiance. Vous pouvez configurer l’audit et les alertes pour savoir quand un administrateur modifie une ressource s’il est authentifié.

Vous pouvez également utiliser des unités administratives (AU) dans Microsoft Entra ID pour fournir un certain niveau de séparation administrative. Les unités administratives limitent les autorisations d’un rôle en fonction du service auquel il appartient au sein de l’organisation. Par exemple, vous pouvez utiliser des unités administratives pour déléguer le rôle Administrateur du support technique aux spécialistes du support régional, pour qu’ils ne puissent s’occuper que des utilisateurs situés dans la région dont ils ont la charge.

Diagramme montrant des unités administratives

Les unités administratives peuvent être utilisées pour séparer les objets utilisateur, groupe et appareil. Les affectations de ces unités peuvent être gérées par des règles d’appartenance dynamique.

En utilisant Privileged Identity Management (PIM), vous pouvez définir qui dans votre organisation est la meilleure personne pour approuver la demande de rôles hautement privilégiés. Par exemple, les administrateurs nécessitant un accès administrateur général pour apporter des modifications à l’échelle du locataire.

Remarque

L'utilisation de PIM nécessite une licence Microsoft Entra ID P2 par humain.

Si vous devez vous assurer que les administrateurs généraux ne peuvent pas gérer une ressource spécifique, vous devez isoler cette ressource dans un locataire distinct avec des administrateurs généraux distincts. Cela peut être particulièrement important pour les sauvegardes ; consultez les conseils d’autorisation multi-utilisateur pour obtenir des exemples.

Utilisation courante

L’une des utilisations les plus courantes pour plusieurs environnements dans un seul locataire consiste à séparer la production des ressources hors production. Au sein d’un seul locataire, les équipes de développement et les propriétaires d’applications peuvent créer et gérer un environnement distinct avec des applications de test, des utilisateurs et des groupes de test et des stratégies de test pour ces objets ; de même, ils peuvent créer des instances hors production d’applications approuvées et de ressources Azure.

Le diagramme suivant illustre les environnements hors production et l’environnement de production.

Diagramme illustrant les limites du client Microsoft Entra.

Dans ce diagramme, il existe des ressources Azure de non-production et des instances de non-production d'applications intégrées Microsoft Entra avec des objets d'annuaire de non-production équivalents. Dans cet exemple, les ressources hors production de l’annuaire sont utilisées à des fins de test.

Remarque

Vous ne pouvez pas avoir plusieurs environnements Microsoft 365 dans un seul client Microsoft Entra. Cependant, vous pouvez avoir plusieurs environnements Dynamics 365 dans un seul locataire Microsoft Entra.

Un autre scénario d’isolation au sein d’un seul locataire peut être la séparation entre les emplacements, les filiales ou l’implémentation d’une administration hiérarchisée (selon le « modèle d’accès aux entreprises »).

Les attributions de rôles RBAC Azure autorisent l’administration étendue des ressources Azure. De même, Microsoft Entra ID permet une gestion granulaire des applications de confiance Microsoft Entra ID grâce à de multiples fonctionnalités telles que l'accès conditionnel, le filtrage des utilisateurs et des groupes, les affectations d'unités administratives et les affectations d'applications.

Si vous devez garantir l’isolation complète (y compris la préproduction de la configuration au niveau de l’organisation) des services Microsoft 365, vous devez choisir une isolation à plusieurs locataires.

Gestion délimitée dans un seul locataire

Gestion délimitée pour les ressources Azure

La fonctionnalité RBAC Azure vous permet de concevoir un modèle d’administration avec des étendues granulaires et une surface d’exposition. Considérez la hiérarchie d’administration dans l’exemple suivant :

Notes

Il existe plusieurs façons de définir la hiérarchie d’administration en fonction des exigences, des contraintes et des objectifs individuels d’une organisation. Pour plus d’informations, consultez le Guide du Cloud Adoption Framework sur la façon d’organiser les ressources Azure.

Diagramme montrant l’isolation des ressources dans un seul locataire

  • Groupe d’administration – Vous pouvez attribuer des rôles à des groupes d’administration spécifiques afin qu’ils n’affectent aucun autre groupe d’administration. Dans le scénario ci-dessus, l’équipe RH peut définir une stratégie Azure Policy pour auditer les régions où les ressources sont déployées sur tous les abonnements RH.

  • Abonnement – Vous pouvez attribuer des rôles à un abonnement spécifique pour l’empêcher d’affecter d’autres groupes de ressources. Dans l’exemple ci-dessus, l’équipe RH peut attribuer le rôle Lecteur pour l’abonnement Avantages, sans lire un autre abonnement RH ni un abonnement d’une autre équipe.

  • Groupe de ressources – Vous pouvez attribuer des rôles à des groupes de ressources spécifiques afin qu’ils n’affectent aucun autre groupe de ressources. Dans l’exemple ci-dessus, l’équipe d’ingénierie Avantages peut attribuer le rôle Contributeur au prospect de test afin qu’elle puisse gérer la base de données de test et l’application web de test, ou pour ajouter d’autres ressources.

  • Ressources individuelles – Vous pouvez attribuer des rôles à des ressources spécifiques afin qu’elles n’affectent aucune autre ressource. Dans l’exemple ci-dessus, l’équipe d’ingénierie Avantages peut affecter un analyste de données au rôle Lecteur de compte Cosmos DB uniquement pour l’instance de test de la base de données Azure Cosmos DB, sans interférer avec l’application web de test ni aucune ressource de production.

Pour plus d’informations, consultez Rôles intégrés Azure et Qu’est-ce que le contrôle d’accès en fonction du rôle Azure (RBAC Azure) ?.

Il s’agit d’une structure hiérarchique. Ainsi, plus la hiérarchie est élevée, plus l’étendue, la visibilité et l’impact sont importants aux niveaux inférieurs. Les étendues de niveau supérieur affectent toutes les ressources Azure dans la limite du locataire Microsoft Entra. Cela signifie également que des autorisations peuvent être appliquées à plusieurs niveaux. Le risque que cela introduit est que l’attribution de rôles plus haut dans la hiérarchie peut fournir plus d’accès plus bas que prévu dans l’étendue. Microsoft Entra (formellement CloudKnox) est un produit Microsoft qui fournit visibilité et correction pour contribuer à réduire le risque. Les détails sont les suivants :

  • Le groupe d’administration racine définit les stratégies Azure Policy et les attributions de rôles RBAC qui seront appliquées à tous les abonnements et ressources.

  • Les administrateurs généraux peuvent élever leur accès à tous les abonnements et groupes d’administration.

Les deux étendues de niveau supérieur doivent être surveillées strictement. Il est important de planifier d’autres dimensions de l’isolation des ressources, telles que la mise en réseau. Pour obtenir des conseils généraux sur la mise en réseau Azure, consultez Meilleures pratiques Azure pour la sécurité réseau. Les charges de travail IaaS (Infrastructure as a Service) ont des scénarios spéciaux dans lesquels l’isolation des identités et des ressources doit faire partie de la conception et de la stratégie globales.

Envisagez d’isoler les ressources sensibles ou de test en fonction de l’architecture conceptuelle de la zone d’atterrissage Azure. Par exemple, l’abonnement d’identité doit être attribué à un groupe d’administration séparé et tous les abonnements à des fins de développement peuvent être séparés dans le groupe d’administration « Bac à sable ». Vous trouverez plus de détails dans la documentation à l’échelle de l’entreprise. La séparation à des fins de test au sein d’un seul locataire est également prise en compte dans la hiérarchie de groupes d’administration de l’architecture de référence.

Gestion étendue pour les applications de confiance Microsoft Entra ID

Le modèle permettant de gérer la portée des applications faisant confiance à Microsoft Entra ID est décrit dans la section suivante.

Microsoft Entra ID prend en charge la configuration de plusieurs instances d'applications personnalisées et SaaS, mais pas de la plupart des services Microsoft, sur le même répertoire avec des attributions d'utilisateurs indépendantes. L’exemple ci-dessus contient à la fois une version de production et une version de test de l’application de voyage. Vous pouvez déployer des versions de préproduction sur le locataire d’entreprise pour obtenir une configuration et une séparation de stratégie spécifiques à l’application qui permettent aux propriétaires de charge de travail d’effectuer des tests avec leurs informations d’identification d’entreprise. Les objets d’annuaire hors production tels que les utilisateurs de test et les groupes de test sont associés à l’application hors production avec une propriété distincte de ces objets.

Il existe des aspects à l’échelle du locataire qui affectent toutes les applications approuvées dans la limite du locataire Microsoft Entra, notamment :

  • Les administrateurs généraux peuvent gérer tous les paramètres à l’échelle du locataire.

  • D’autres rôles d’annuaire tels que les rôles Administrateur d’utilisateurs, Administrateur d’applications et Administrateurs d’accès conditionnel peuvent gérer la configuration à l’échelle du locataire dans l’étendue du rôle.

Les paramètres de configuration tels que les méthodes d’authentification autorisées, les configurations hybrides, la liste verte B2B Collaboration des domaines et les emplacements nommés sont à l’échelle du locataire.

Notes

Les autorisations de consentement et les autorisations de l’API Microsoft Graph ne peuvent pas être délimitées pour un groupe ou des membres d’unités administratives. Ces autorisations seront affectées au niveau de l’annuaire. Seul le consentement spécifique aux ressources autorise l’étendue au niveau des ressources (actuellement limitée aux autorisations de conversation Microsoft Teams)

Important

Le cycle de vie des services Microsoft SaaS tels qu'Office 365, Microsoft Dynamics et Microsoft Exchange est lié au locataire Microsoft Entra. Par conséquent, plusieurs instances de ces services nécessitent nécessairement plusieurs locataires Microsoft Entra. Consultez la documentation relative aux services individuels pour en savoir plus sur les fonctionnalités d’étendue de gestion spécifiques.

Étapes suivantes