Partager via


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

Une architecture Microsoft Entra à locataire unique avec administration déléguée est souvent suffisante pour séparer les environnements. Votre organisation peut avoir besoin d’un degré d’isolation qui n’est pas possible avec un seul locataire.

Pour cet article, il est important de comprendre :

  • L’opération et la fonction d’un seul locataire
  • Unités administratives (UA) dans Microsoft Entra ID
  • Relations entre les ressources Azure et les locataires Microsoft Entra
  • Conditions requises qui déterminent l’isolation

Locataire Microsoft Entra comme limite de sécurité

Un locataire Microsoft Entra fournit des capacités de gestion des identités et des accès (IAM) aux applications et ressources d’une organisation.

Une identité est un objet annuaire authentifié et autorisé à accéder à une ressource. Il existe des objets d’identité pour les identités humaines et non humaines. Pour dériver, les identités humaines sont appelées identités et les identités non humaines sont appelées 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. En règle générale, une identité de charge de travail est destinée à une entité logicielle pour s’authentifier auprès d’un système.

  • Identité – Objets qui représentent les humains
  • Identité de charge de travail – 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 authentifie et accède à d’autres services et ressources

Pour plus d’informations, découvrez les identités de charge de travail.

Le locataire Microsoft Entra est une délimitation de sécurité d’identité contrôlée par les 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. Ces groupes dépendent de la configuration des stratégies et des paramètres à l’échelle du locataire.

Microsoft Entra ID accorde aux objets l’accès aux applications et aux ressources Azure. Les ressources et applications Azure qui font confiance à Microsoft Entra ID peuvent être managées avec Microsoft Entra ID. En suivant les meilleures pratiques, configurez l’environnement avec un environnement de test.

Accès aux applications qui utilisent Microsoft Entra ID

Octroyez aux identités l’accès aux applications :

  • Services de productivité Microsoft tels qu’Exchange Online, Microsoft Teams et SharePoint Online
  • Services informatiques Microsoft comme Azure Sentinel, Microsoft Intune et Microsoft Defender Advanced Threat Protection (DAV)
  • Outils de développeur 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

Les applications qui utilisent Microsoft Entra ID nécessitent la configuration et la gestion des objets de l’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

Octroyez des rôles aux utilisateurs, aux groupes et aux objets Principal de service (identités de charge de travail) dans le locataire Microsoft Entra. Pour en savoir plus, consultez Contrôle d’accès en fonction du rôle Azure (RBAC) et Contrôle d’accès en fonction des attributs Azure (ABAC).

Utilisez le RBAC Azure pour fournir un accès basé sur le rôle déterminé par le principal de sécurité, la définition du rôle et l’étendue. L’ABAC Azure ajoute des conditions d’attribution de rôle, basées sur des attributs pour les actions. Pour un contrôle d’accès plus précis, ajoutez une condition d’attribution de rôle. Accédez aux ressources Azure, aux groupes de ressources, aux abonnements et aux groupes d’administration avec des rôles RBAC attribués.

Les ressources Azure qui prennent en charge les identités managées permettent aux ressources de s’authentifier, d’obtenir l’accès et se voir attribuer des rôles à d’autres ressources dans la délimitation du locataire Microsoft Entra.

Les applications utilisant Microsoft Entra ID pour la connexion peuvent utiliser les ressources Azure, comme la capacité de calcul ou le stockage. 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. Les ressources Azure du locataire Microsoft Entra affectent les quotas et limites Azure à l’échelle du locataire.

Accès aux objets d’annuaire

Les identités, les ressources et leurs relations sont représentées comme des objets d’annuaire dans un locataire Microsoft Entra. Les utilisateurs, les groupes, les principaux de service et les inscriptions d’applications sont des exemples. Disposer d’un ensemble d’objets d’annuaire dans la délimitation du locataire de Microsoft Entra pour 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’activité d’audit en fonction de leurs autorisations. Par exemple, un membre de l’annuaire peut découvrir des utilisateurs dans l’annuaire avec les autorisations d’utilisateur par défaut de Microsoft Entra ID.

  • Effets sur les applications : dans le cadre de leur logique commerciale, les applications peuvent manipuler des objets de l’annuaire par l’intermédiaire de Microsoft Graph. Parmi les exemples typiques, citons la lecture ou la définition des attributs de l’utilisateur, la mise à jour du calendrier de l’utilisateur, l’envoi de courriers électroniques au nom de l’utilisateur, etc. Le consentement est nécessaire pour autoriser aux applications d’affecter le locataire. Les administrateurs peuvent donner leur consentement pour tous les utilisateurs. Pour en savoir plus, consultez Autorisations et consentement dans la Plateforme d’identités Microsoft.

  • Limitation de requêtes et limites de service : le comportement runtime d’une ressource peut déclencher une limitation de requêtes afin d’éviter une surutilisation ou une dégradation du service. La limitation peut se produire au niveau de l’application, du locataire ou de l’ensemble du service. En général, cette limitation se produit lorsqu’une application a un grand nombre de demandes dans ou entre les locataires. De même, il existe des limites et des restrictions de service Microsoft Entra qui peuvent affecter le comportement runtime de l’application.

    Remarque

    Soyez prudent en ce qui concerne les autorisations d’utilisation des applications. Par exemple, avec Exchange Online, les autorisations d’application d’étendue pour les boîtes aux lettres et les autorisations.

Unités administratives pour la gestion des rôles

Les unités administratives restreignent les autorisations d’un rôle à une partie de votre organisation. Vous pouvez utiliser les unités administratives pour déléguer le rôle Administrateur de mot de passe aux spécialistes du service clientèle régional, afin qu’ils puissent gérer les utilisateurs dans la région qu’ils prennent en 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 :

  • Utilisateurs
  • Groupes
  • Appareils

Dans le diagramme suivant, les unités administratives (UA) segmentent le locataire Microsoft Entra en fonction de la structure organisationnelle. Cette approche est utile lorsque les unités professionnelles ou les groupes allouent du personnel de support informatique dédié. Utilisez les UA pour fournir des autorisations privilégiées limitées à une unité administrative.

Diagramme des unités administratives de Microsoft Entra.

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

Motifs courants d’isolation des ressources

Parfois, vous isolez un groupe de ressources d’autres ressources pour des raisons de sécurité, comme les ressources avec des exigences d’accès uniques. Cette action est un bon cas d’usage pour les UA. Déterminez les utilisateurs et l’accès aux ressources du principal de sécurité et dans quels rôles. Raisons d’isoler les ressources :

  • Les équipes de développeurs doivent itérer en toute sécurité. Toutefois, le développement et les tests d’applications qui écrivent sur Microsoft Entra ID peuvent affecter le locataire Microsoft Entra par le biais d’opérations d’écriture :
    • Nouvelles applications pouvant modifier le contenu d’Office 365, comme les sites SharePoint, OneDrive, Microsoft Teams, etc.
    • Applications personnalisées pouvant modifier les données des utilisateurs à l’aide de MS Graph ou d’API similaires à grande échelle. Par exemple, les applications bénéficiant de l’autorisation Directory.ReadWrite.All.
    • Scripts DevOps qui mettent à jour de grands jeux d’objets
    • Les développeurs d’applications intégrées Microsoft Entra doivent créer des objets utilisateur pour les tester. Les objets utilisateurs n’ont pas accès aux ressources de production.
  • Ressources et applications Azure hors production qui peuvent affecter d’autres ressources. Par exemple, une nouvelle application SaaS doit être isolée de l’instance de production et des objets utilisateurs
  • Les ressources secrètes doivent être protégées contre la découverte, l’énumération ou la prise de contrôle par les administrateurs

Configuration dans un locataire

Les paramètres de configuration de Microsoft Entra ID peuvent affecter les ressources du locataire Microsoft Entra par le biais d’actions de gestion ciblées ou à l’échelle du locataire :

  • Identités externes : les administrateurs identifient et contrôlent les identités externes qui peuvent être approvisionnées dans le locataire
    • L’autorisation d’utiliser des identités externes dans le locataire
    • Domaines à partir desquels les identités externes sont ajoutées
    • Si les utilisateurs peuvent inviter des utilisateurs d’autres locataires
  • Emplacements nommés : les administrateurs créent des emplacements nommés pour :
    • Bloquer la connexion à partir de plusieurs emplacements
    • Déclencher des politiques d’accès conditionnel comme l’authentification multifacteur
    • Contourner des exigences de sécurité
  • Options en libre-service : les administrateurs définissent la réinitialisation de mots de passe en libre-service et créent des groupes Microsoft 365 au niveau du locataire.

Si elles ne sont pas remplacées par des stratégies globales, vous pouvez définir l’étendue de certaines configurations à l’échelle du locataire :

  • La configuration du locataire autorise les identités externes. Un administrateur de ressources peut exclure ces identités de l’accès.
  • La configuration du locataire autorise l’inscription d’appareils personnels. Un administrateur de ressources peut exclure les appareils de l’accès.
  • Les emplacements nommés sont configurés. Un administrateur de ressources peut configurer des stratégies pour autoriser ou exclure l’accès.

Motifs courants d’isolation de configuration

Les configurations, contrôlées par les administrateurs affectent les ressources. Si certaines configurations à l’échelle du locataire peuvent être encadrées par des politiques qui ne s’appliquent pas ou s’appliquent partiellement à une ressource, d’autres ne peuvent pas l’être. Si une ressource a une configuration unique, isolez-la dans un locataire distinct. Voici quelques exemples :

  • Ressources dont les exigences sont en conflit avec les mesures de sécurité ou de collaboration mises en place à l’échelle du locataire.
    • Par exemple, les types d’authentification autorisés, les stratégies de gestion des périphériques, le libre-service, la preuve d’identité pour les identités externes, etc.
  • Exigences de conformité qui définissent l’étendue de la certification à l’ensemble de l’environnement
    • Cette action concerne toutes les ressources et le locataire Microsoft Entra, en particulier lorsque les exigences entrent en conflit avec d’autres ressources organisationnelles ou les excluent
  • Exigences d’accès des utilisateurs externes en conflit avec des stratégies de ressources de production ou sensibles
  • Les organisations qui s’étendent sur plusieurs pays ou régions, et les entreprises hébergées dans un locataire Microsoft Entra.
    • Par exemple, les paramètres et licences utilisés dans les pays, les régions ou les filiales commerciales.

Administration de locataire

Les identités ayant des rôles privilégiés dans un 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 comprend la propriété des objets d’identité comme les utilisateurs, les groupes et les appareils. Elle inclut également l’implémentation étendue de configurations à l’échelle du locataire pour l’authentification, l’autorisation, etc.

Administration des objets d’annuaire

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

  • Les identités organisationnelles comme les suivantes, 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 représentent les utilisateurs externes à l’organisation :
    • Partenaires, fournisseurs ou fournisseurs provisionnés avec des comptes dans l’environnement organisationnelle
    • Partenaires, fournisseurs ou fournisseurs approvisionnés avec Azure B2B Collaboration
  • Les groupes sont représentés par des objets :
  • Les appareils sont représentés par des objets :
    • Appareils avec jonction hybride à Microsoft Entra. Ordinateurs locaux synchronisés localement.
    • Appareils joints à Microsoft Entra
    • Microsoft Entra a enregistré les appareils mobiles utilisés par les employés pour accéder aux applications de l’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 local à l’aide de Microsoft Entra Connect.

Administration des services d’identité

Les administrateurs disposant de certaines autorisations gèrent la façon dont les stratégies à l’échelle du locataire sont implémentées pour les groupes de ressources, les groupes de sécurité ou les applications. Lorsque vous envisagez l’administration des ressources, gardez à l’esprit les raisons suivantes de regrouper des ressources ou de les isoler.

  • Les administrateurs généraux contrôlent les abonnements Azure liés au locataire
  • Les identités affectées à un rôle Administrateur d’authentification obligent les non-administrateurs à se réenregistrer pour l’authentification multifacteur ou l’authentification Fast IDentity Online (FIDO).
  • Les administrateurs d’accès conditionnel créent des stratégies d’accès conditionnel pour la connexion des utilisateurs aux applications, à partir d’appareils appartenant à l’organisation. Ces configurations d’étendue administrateurs. Par exemple, si les identités externes sont autorisées dans le locataire, elles peuvent exclure l’accès aux ressources.
  • Les administrateurs d’applications clouddonnent leur consentement pour les autorisations d’application au nom des utilisateurs

Motifs courants d’isolation administrative

Qui doit administrer l’environnement et ses ressources ? Parfois, les administrateurs d’un environnement n’ont pas accès à un autre environnement :

  • Séparation des responsabilités administratives à l’échelle du locataire afin de réduire le risque d’erreurs de sécurité et d’exploitation affectant les ressources critiques
  • Les réglementations qui limitent les personnes autorisées à administrer l’environnement, sur la base de conditions comme la citoyenneté, la résidence, le niveau d’habilitation, etc.

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 important de comprendre les risques de sécurité et d’exécution en cas de compromis ou d’erreur. Si vous exécutez 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 de l’identité : dans la délimitation du locataire, les identités se voient attribuer n’importe quel rôle, si l’administrateur qui fournit l’accès dispose de privilèges suffisants. Alors que les effets de la compromission d’identités non privilégiées sont largement contenus, la compromission d’administrateurs peut entraîner de grands problèmes. Par exemple, si un compte hautement privilégié est compromis, les ressources Azure peuvent être compromises. Pour réduire le risque de compromission de l’identité ou de mauvais acteurs, mettez en place une administration par paliers et suivez les principes du moindre privilège pour les rôles d’administrateur de Microsoft Entra. Créez des stratégies d’accès conditionnel qui excluent les comptes de test et testent les principaux de service d’accès aux ressources en dehors des applications de test. Pour en savoir plus sur la stratégie d’accès privilégié, consultez Accès privilégié : stratégie.
  • Compromission de l’environnement fédéré
  • Compromission des ressources fiables : tout composant compromis d’un locataire Microsoft Entra affecte les ressources fiables, en fonction des autorisations au niveau du locataire et de la ressource. Les privilèges d’une ressource déterminent l’effet d’un composant compromis. Les ressources intégrées pour effectuer des opérations d’écriture peuvent affecter l’ensemble du locataire. Le respect des règles de Confiance Zéro peut aider à limiter les effets de la compromission.
  • Développement d’applications : il existe des risques au début du cycle de vie du développement d’applications avec des privilèges d’écriture dans Microsoft Entra ID. Les bogues peuvent écrire des modifications involontairement dans les objets Microsoft Entra. Pour en savoir plus, consultez Meilleures pratiques relatives à la plateforme d’identités Microsoft.
  • Erreur opérationnelle : les mauvais acteurs et les erreurs opérationnelles commises par les administrateurs du locataire ou les propriétaires des ressources peuvent être à l’origine d’incidents de sécurité. Ces risques sont inhérents à toutes les architectures. Utilisez la séparation des tâches, l’administration par paliers, les principes du moindre privilège et observez les meilleures pratiques. Évitez d’utiliser un locataire distinct.

Principes de confiance zéro

Incorporez les principes de Confiance Zéro dans votre stratégie de conception Microsoft Entra ID pour guider la conception sécurisée. Vous pouvez adopter une sécurité proactive avec le principe de Confiance Zéro.

Étapes suivantes