Partage via

Présentation de l’administration déléguée et des environnements isolés

  • Article

Une architecture monolocataire Microsoft Entra avec administration déléguée est généralement appropriée pour séparer des environnements. Comme expliqué en détail dans d’autres sections de cet article, Microsoft fournit de nombreux outils à cette fin. Toutefois, il peut arriver que votre organisation nécessite un degré d’isolation supérieur à celui qui peut être atteint dans un seul locataire.

Avant d’aborder les architectures spécifiques, il est important de comprendre plusieurs points :

  • Fonctionnement d’un locataire unique classique

  • Fonctionnement des unités administratives dans Microsoft Entra ID

  • Relations entre les ressources Azure et les locataires Microsoft Entra

  • Exigences courantes encadrant l’isolation

Locataire Microsoft Entra comme limite de sécurité

Un locataire Microsoft Entra offre des capacités de gestion des identités et des accès (IAM) aux applications et aux ressources utilisées par l’organisation.

Une identité est un objet annuaire qui peut être authentifié et autorisé à accéder à une ressource. Les objets d’identité existent pour les identités humaines et les identités non humaines. Pour différencier les identités humaines et non humaines, nous désignons les identités humaines comme identités et les identités non humaines comme identités de charge de travail. Les entités non humaines incluent les objets d’application, les principaux de service, les identités managées et les appareils. La terminologie est incohérente dans l’ensemble du secteur, mais en général, une identité de charge de travail est une opération dont vous avez besoin pour que votre entité logicielle s’authentifie auprès d’un système.

Différents termes émergent dans le secteur informatique, permettant de faire la distinction entre identités humaines et non humaines :

  • Identité : identité dont le point de départ est la description de l’objet Active Directory (AD) et Microsoft Entra utilisé par des humains pour l’authentification. Dans cette série d’articles, l’identité fait référence aux objets qui représentent des humains.

  • Identité de charge de travail : dans Microsoft Entra ID, les identités de charge de travail sont des applications, des principaux de service et des identités managées. L’identité de charge de travail est utilisée pour l’authentification et l’accès à d’autres services et ressources.

Pour plus d’informations sur les identités de charge de travail, consultez Que sont les identités de charge de travail ?

Le locataire Microsoft Entra est une limite de sécurité d’identité sous le contrôle des administrateurs. Dans cette limite de sécurité, l’administration des abonnements, des groupes d’administration et des groupes de ressources peut être déléguée pour segmenter le contrôle administratif des ressources Azure. Bien qu’ils n’interagissent pas directement, ces regroupements dépendent des configurations de stratégies et de paramètres à l’échelle du locataire. Par ailleurs, ces paramètres et configurations sont sous le contrôle des administrateurs généraux de Microsoft Entra.

Microsoft Entra ID permet d’accorder aux objets représentant des identités l’accès aux applications et aux ressources Azure. Dans ce sens, les ressources Azure et les applications qui font confiance à Microsoft Entra ID sont des ressources qui peuvent être gérées avec Microsoft Entra ID. Le diagramme suivant, illustrant la limite du locataire Microsoft Entra, montre les objets d’identité Microsoft Entra et les outils de configuration. Sous l’annuaire figurent les ressources qui utilisent les objets d’identité pour la gestion des identités et des accès. Suivant les bonnes pratiques, l’environnement est configuré avec un environnement de test pour tester le bon fonctionnement de l’IAM.

Diagramme illustrant la limite d’un locataire Microsoft Entra.

Accès aux applications qui utilisent Microsoft Entra ID

Les identités peuvent être autorisées à accéder à de nombreux types d’applications. Voici quelques exemples :

  • Services de productivité Microsoft tels qu’Exchange Online, Microsoft Teams et SharePoint Online

  • Services informatiques Microsoft tels qu’Azure Sentinel, Microsoft Intune et Microsoft 365 Defender ATP

  • Outils de développement Microsoft comme Azure DevOps et l’API Microsoft Graph

  • Solutions SaaS telles que Salesforce et ServiceNow

  • Applications locales auxquelles sont intégrées des fonctionnalités d’accès hybrides telles que le Proxy d’application Microsoft Entra

  • Applications personnalisées développées en interne

Les applications qui utilisent Microsoft Entra ID nécessitent la configuration et la gestion d’objets annuaire dans le locataire Microsoft Entra approuvé. Les objets annuaire incluent, par exemple, les inscriptions d’applications, les principaux de service, les groupes et les extensions d’attribut de schéma.

Accès aux ressources Azure

Des rôles sont octroyés aux utilisateurs, groupes et objets de principal de service (identités de charge de travail) dans le tenant Microsoft Entra en utilisant le contrôle d’accès en fonction du rôle (RBAC) Azure et du contrôle d’accès en fonction des attributs (ABAC) Azure.

  • Le contrôle d’accès RBAC Azure vous permet de fournir un accès en fonction du rôle comme déterminé par le principal de sécurité, la définition du rôle et l’étendue.

  • Azure ABAC s’appuie sur Azure RBAC en ajoutant des conditions d’attribution de rôle en fonction des attributs dans le contexte d’actions spécifiques. Une condition d’attribution de rôle est une autre vérification que vous pouvez éventuellement ajouter à votre attribution de rôle pour fournir un contrôle d’accès encore plus précis.

Les ressources, groupes de ressources, abonnements et groupes d’administration Azure sont accessibles par le biais de ces rôles RBAC attribués. Par exemple, le diagramme suivant illustre la distribution de la capacité d’administration dans Microsoft Entra ID avec le contrôle d’accès en fonction du rôle.

Diagramme illustrant la hiérarchie des rôles dans Microsoft Entra.

Les ressources Azure qui prennent en charge les identités managées peuvent s’authentifier, accepter des demandes d’accès et se voir attribuer des rôles vis-à-vis d’autres ressources dans la limite du locataire Microsoft Entra.

Les applications utilisant Microsoft Entra ID pour la connexion peuvent également utiliser des ressources Azure (notamment de calcul ou de stockage) dans le cadre de leur implémentation. Par exemple, une application personnalisée qui s’exécute dans Azure et qui fait confiance à Microsoft Entra ID pour l’authentification dispose d’objets annuaire et de ressources Azure.

Enfin, toutes les ressources Azure dans le locataire Microsoft Entra affectent les quotas et limites Azure à l’échelle du locataire.

Accès aux objets annuaire

Comme indiqué dans le diagramme précédent, les identités, les ressources et leurs relations sont représentées dans un locataire Microsoft Entra en tant qu’objets annuaire. Les objets annuaire incluent, par exemple, les utilisateurs, les groupes, les principaux de service et les inscriptions d’applications.

L’existence d’un ensemble d’objets annuaire dans la limite du locataire Microsoft Entra engendre les capacités suivantes :

  • Visibilité. Les identités peuvent découvrir ou énumérer des ressources, des utilisateurs, des groupes, des rapports d’utilisation des accès et des journaux d’audit en fonction de leurs autorisations. Par exemple, un membre de l’annuaire peut découvrir des utilisateurs dans l’annuaire en fonction des autorisations utilisateur par défaut Microsoft Entra ID.

  • Les applications peuvent affecter des objets. Les applications peuvent manipuler des objets annuaire par le biais de Microsoft Graph dans le cadre de leur logique métier. Les exemples classiques incluent la lecture/définition des attributs utilisateur, la mise à jour du calendrier de l’utilisateur, l’envoi d’e-mails pour le compte de l’utilisateur, etc. Le consentement est nécessaire pour permettre aux applications d’affecter le locataire. Les administrateurs peuvent donner leur consentement pour tous les utilisateurs. Pour plus d’informations, consultez Autorisations et consentement dans la Plateforme d’identités Microsoft.

Notes

Utilisez les autorisations d’application avec prudence. Par exemple, avec Exchange Online, vous devez limiter les autorisations d’application à des boîtes aux lettres et autorisations spécifiques.

  • Limitation et limites des services. Le comportement d’une ressource à l’exécution peut déclencher une limitation empêchant la surutilisation ou la dégradation du service. La limitation peut se produire au niveau de l’application, du locataire ou de l’ensemble du service. Elle se produit le plus souvent quand une application a un grand nombre de requêtes dans ou entre des locataires. De même, il existe des limites et restrictions de service Microsoft Entra susceptibles d’affecter le comportement des applications à l’exécution.

Unités administratives pour la gestion des rôles

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. Une unité administrative est une ressource Microsoft Entra qui peut être un conteneur pour d’autres ressources Microsoft Entra. Une unité administrative peut contenir uniquement :

  • Utilisateurs

  • Groupes

  • Appareils

Dans le diagramme suivant, les unités administratives sont utilisées pour segmenter davantage le locataire Microsoft Entra en fonction de la structure métier ou organisationnelle. Ceci s’avère utile quand différents groupes ou divisions d’entreprise disposent d’équipes de support informatique dédiées. Les unités administratives peuvent être utilisées pour fournir des autorisations privilégiées limitées à une unité administrative donnée.

Diagramme montrant des unités administratives Microsoft Entra.

Pour plus d’informations sur les unités administratives, consultez Unités administratives dans Microsoft Entra ID.

Motifs courants d’isolation des ressources

Parfois, un groupe de ressources doit être isolé d’autres ressources à des fins de sécurité ou pour d’autres raisons, par exemple quand les ressources ont des exigences d’accès uniques. Il s’agit d’un bon cas d’usage des unités administratives. Vous devez déterminer quels utilisateurs et principaux de sécurité doivent avoir accès aux ressources et dans quels rôles. Différentes raisons peuvent motiver l’isolation des ressources, par exemple :

  • Des équipes de développeurs ont besoin de flexibilité pour effectuer des itérations de manière sûre pendant le cycle de vie de développement des applications. Toutefois, le développement et le test des applications qui écrivent dans Microsoft Entra ID peuvent affecter le locataire Microsoft Entra par le biais d’opérations d’écriture. En voici quelques exemples :

    • Nouvelles applications susceptibles de modifier du contenu Office 365, par exemple des sites SharePoint, OneDrive, MS Teams, etc.

    • Applications personnalisées qui peuvent modifier les données des utilisateurs avec MS Graph ou des API similaires à grande échelle (par exemple, des applications auxquelles est attribuée l’autorisation Directory.ReadWrite.All)

    • Scripts DevOps qui mettent à jour de grands ensembles d’objets dans le cadre d’un cycle de vie de déploiement.

    • Développeurs d’applications intégrées Microsoft Entra qui doivent pouvoir créer des objets utilisateur à des fins de test, alors que ces objets utilisateur ne doivent pas avoir accès aux ressources de production.

  • Ressources et applications Azure hors production susceptibles d’affecter d’autres ressources. Par exemple, une nouvelle version bêta d’une application SaaS peut avoir besoin d’être isolée de l’instance de production de l’application et des objets utilisateur de production.

  • Ressources secrètes qui doivent être protégées contre la découverte, l’énumération ou la prise de contrôle par des administrateurs existants pour des raisons réglementaires ou vitales pour l’entreprise.

Configuration dans un locataire

Les paramètres de configuration de Microsoft Entra ID peuvent affecter n’importe quelle ressource du locataire Microsoft Entra par le biais d’actions de gestion ciblées ou à l’échelle du locataire. Voici quelques exemples de paramètres à l’échelle du locataire :

  • Identités externes : les administrateurs identifient et contrôlent les identités externes qui peuvent être approvisionnées dans le tenant.

    • S’il faut ou non autoriser les identités externes dans le locataire

    • À partir de quel(s) domaine(s) des identités externes peuvent être ajoutées

    • Si les utilisateurs peuvent ou non inviter des utilisateurs issus d’autres locataires

  • Emplacements nommés : les administrateurs peuvent créer des emplacements nommés, qui peuvent être utilisés pour :

    • Bloquer les connexions provenant de lieux spécifiques

    • Déclenchez des stratégies d’accès conditionnel, par exemple l’authentification multifacteur.

    • Contourner des exigences de sécurité

  • Options en libre-service : Les administrateurs définissent des options en libre-service, comme la réinitialisation de mot de passe en libre-service, et créent des groupes Microsoft 365 au niveau du tenant.

L’implémentation de certaines configurations à l’échelle du locataire peut être limitée, à condition qu’elles ne soient pas remplacées par des stratégies générales. Par exemple :

  • Même si le locataire est configuré pour autoriser les identités externes, un administrateur de ressources peut exclure ces identités de l’accès à une ressource.

  • Même si le locataire est configuré pour autoriser l’inscription d’appareils personnels, un administrateur de ressources peut exclure ces appareils de l’accès à des ressources spécifiques.

  • Si des emplacements nommés sont configurés, un administrateur de ressources peut configurer des stratégies autorisant ou excluant l’accès à partir de ces emplacements.

Motifs courants d’isolation de configuration

Les configurations, contrôlées par les administrateurs, affectent les ressources. Certaines configurations à l’échelle du locataire peuvent être limitées à l’aide de stratégies pour ne pas s’appliquer (ou s’appliquer partiellement) à une ressource spécifique, mais d’autres ne le peuvent pas. Si une ressource a des besoins de configuration uniques, isolez-la dans un locataire distinct. Voici quelques exemples de scénarios d’isolation de configuration :

  • Ressources présentant des exigences en conflit avec les postures existantes en termes de sécurité ou de collaboration à l’échelle du locataire (par exemple, des types d’authentification autorisés, des stratégies de gestion des appareils, la capacité de libre-service, la vérification d’identité pour les identités externes, etc.).

  • Exigences de conformité qui étendent la certification à l’ensemble de l’environnement, y compris toutes les ressources et le locataire Microsoft Entra lui-même, en particulier quand ces exigences sont en conflit avec d’autres ressources organisationnelles ou doivent exclure d’autres ressources organisationnelles.

  • Exigences d’accès des utilisateurs externes en conflit avec des stratégies de ressources de production ou sensibles.

  • Organisations qui s’étendent sur plusieurs pays/régions et entreprises hébergées dans un seul locataire Microsoft Entra. Par exemple, quels paramètres et licences sont utilisés dans les différents pays/régions ou filiales.

Administration dans un locataire

Les identités avec des rôles privilégiés dans le locataire Microsoft Entra ont la visibilité et les autorisations nécessaires pour exécuter les tâches de configuration décrites dans les sections précédentes. L’administration inclut à la fois l’administration des objets d’identité tels que les utilisateurs, les groupes et les appareils et l’implémentation délimitée de configurations à l’échelle du locataire pour l’authentification, l’autorisation, etc.

Administration des objets annuaire

Les administrateurs gèrent la façon dont les objets d’identité peuvent accéder aux ressources et dans quelles circonstances. Ils peuvent également désactiver, supprimer ou modifier des objets annuaire en fonction de leurs privilèges. Les objets d’identité incluent :

  • Les identités organisationnelles telles que les suivantes, qui sont représentées par des objets utilisateur :

    • Administrateurs

    • Utilisateurs d’organisation

    • Développeurs organisationnels

    • Comptes de service

    • Utilisateurs de test

  • Les identités externes, qui représentent les utilisateurs externes à l’organisation, par exemple :

    • Partenaires, fournisseurs ou prestataires provisionnés avec des comptes locaux de l’environnement de l’organisation

    • Partenaires, fournisseurs ou prestataires provisionnés avec Azure B2B Collaboration

  • Les groupes, qui sont représentés par des objets, par exemple :

  • Les appareils, qui sont représentés par des objets, par exemple :

    • Appareils avec une jointure hybride Microsoft Entra (ordinateurs locaux synchronisés à partir d’Active Directory local)

    • Appareils joints à Microsoft Entra

    • Appareils mobiles inscrits auprès de Microsoft Entra utilisés par les employés pour accéder aux applications de leur espace de travail

    • Appareils de bas niveau inscrits auprès de Microsoft Entra (hérités), par exemple, Windows 2012 R2

  • Identités de charge de travail

    • Identités managées

    • Principaux de service

    • Applications

Dans un environnement hybride, les identités sont généralement synchronisées à partir de l’environnement Active Directory local avec Microsoft Entra Connect.

Administration des services d’identité

Les administrateurs disposant des autorisations appropriées peuvent également gérer la façon dont les stratégies à l’échelle du locataire sont implémentées au niveau des groupes de ressources, des groupes de sécurité ou des applications. Quand vous réfléchissez à l’administration des ressources, gardez à l’esprit les points suivants. Ils peuvent tous représenter une raison de conserver les ressources ensemble ou de les isoler.

  • Un administrateur général peut prendre le contrôle de n’importe quel abonnement Azure lié au locataire.

  • Une identité à laquelle est attribué un rôle d’administrateur d’authentification peut exiger des non-administrateurs qu’ils se réinscrivent pour l’authentification multifacteur ou FIDO.

  • Les administrateurs d’accès conditionnel peuvent créer des stratégies d’accès conditionnel obligeant les utilisateurs à se connecter à partir d’appareils appartenant à l’organisation pour accéder à certaines applications. Ils peuvent également délimiter les configurations. Par exemple, même si les identités externes sont autorisées dans le locataire, ils peuvent les empêcher d’accéder à une ressource.

  • Un administrateur d’application cloud peut donner son consentement pour les autorisations d’application pour le compte de tous les utilisateurs.

Motifs courants d’isolation administrative

Qui doit avoir la possibilité d’administrer l’environnement et ses ressources ? Dans certains cas, les administrateurs d’un environnement ne doivent pas avoir accès à un autre environnement. Voici quelques exemples :

  • Séparation des responsabilités administratives à l’échelle du locataire pour réduire davantage le risque d’erreurs de sécurité et opérationnelles affectant les ressources critiques.

  • Réglementations qui limitent les personnes autorisées à administrer l’environnement en fonction de conditions telles que la citoyenneté, le pays de résidence, le niveau d’autorisation, etc., auxquelles ne peuvent satisfaire les équipes.

Considérations opérationnelles et relatives à la sécurité

Compte tenu de l’interdépendance entre un locataire Microsoft Entra et ses ressources, il est essentiel de comprendre les risques opérationnels et de sécurité pouvant découler d’une erreur ou d’une compromission. Si vous travaillez dans un environnement fédéré avec des comptes synchronisés, une compromission au niveau local peut entraîner une compromission au niveau de Microsoft Entra ID.

  • Compromission d’identité : dans la limite d’un locataire, n’importe quel rôle peut être attribué à n’importe quelle identité si la personne qui fournit l’accès dispose de privilèges suffisants. Si la compromission d’identités non privilégiées a un impact très maîtrisable, la compromission d’administrateurs peut avoir, quant à elle, un impact majeur. Par exemple, si un compte Administrateur général Microsoft Entra est compromis, les ressources Azure peuvent également être compromises. Pour atténuer le risque de compromission d’identité ou d’intervention d’acteurs malveillants, implémentez une administration hiérarchisée et veillez à respecter les principes des privilèges minimum pour les rôles Administrateur Microsoft Entra. De même, veillez à créer des stratégies d’accès conditionnel qui empêchent spécifiquement les comptes de test et les principaux de service de test d’accéder aux ressources en dehors des applications de test. Pour plus d’informations sur la stratégie d’accès privilégié, consultez Accès privilégié : stratégie.

  • Compromission de l’environnement fédéré

  • Compromission de ressources d’approbation : les considérations de sécurité ne se limitent pas aux identités humaines. La compromission de tout composant du locataire Microsoft Entra peut affecter les ressources d’approbation en fonction de son niveau d’autorisations au niveau du locataire et des ressources. L’effet de la compromission d’un composant d’une ressource d’approbation Microsoft Entra dépend des privilèges de la ressource. Les ressources étroitement intégrées à l’annuaire pour effectuer des opérations d’écriture peuvent avoir un impact majeur sur l’ensemble du locataire. Les conseils relatifs à la Confiance Zéro peuvent vous permettre de limiter l’impact d’une compromission.

  • Développement d’applications : les premières étapes du cycle de vie de développement d’applications avec des privilèges d’écriture dans Microsoft Entra ID (où des bogues peuvent entraîner l’écriture accidentelle de modifications dans les objets Microsoft Entra) présentent un risque. Suivez les bonnes pratiques relatives à la plateforme d’identité Microsoft pendant le développement pour atténuer ces risques.

  • Erreur opérationnelle : un incident de sécurité peut se produire non seulement sous l’action d’acteurs malveillants, mais également à la suite d’une erreur opérationnelle commise par les administrateurs du locataire ou les propriétaires des ressources. Ces risques sont inhérents à toutes les architectures. Réduisez ces risques en vous appuyant sur la séparation des tâches, l’administration hiérarchisée, les principes des privilèges minimum et les bonnes pratiques avant d’essayer d’utiliser un locataire distinct.

L’incorporation des principes de Confiance Zéro à votre stratégie de conception Microsoft Entra ID peut vous orienter dans votre processus d’atténuation des risques. Pour plus d’informations, consultez Gérez la sécurité de manière proactive avec la Confiance Zéro.

Étapes suivantes