Configuration de Confiance Zéro pour les organisations de défense multilocataires
Cet article décrit comment les organisations multilocataires peuvent appliquer des configurations dans Microsoft Entra ID et répondre aux exigences courantes de Confiance Zéro en matière de défense. Suivez ces recommandations pour établir l’architecture d’identité multilocataire appropriée et mettre en œuvre la Confiance Zéro dans votre environnement.
Figure 1 : Exemple d’architecture de défense multilocataire dotée de configurations de Confiance Zéro.
Déterminer l’architecture d’identité
Les locataires Microsoft Entra sont la base de votre architecture d’identités. Dans Microsoft Entra ID, un locataire constitue une limite d’identité. Une organisation avec un locataire Microsoft Entra présente une architecture monolocataire. Des organisations avec plusieurs locataires Microsoft Entra présentent une architecture multilocataire.
Avantages de l’architecture monolocataire. Grâce à son efficacité opérationnelle, l’architecture monolocataire est plus facile à gérer et offre des coûts réduits. Elle vous permet de configurer plus facilement un environnement de Confiance Zéro. L’architecture monolocataire évite de fragmenter l’expérience utilisateur avec plusieurs informations d’identification de connexion. Elle permet également d’éviter les solutions en silos à intégrer ultérieurement. Vous devez vous efforcer de placer vos données, Microsoft 365 et les services cloud Azure dans un même locataire. Si vous utilisez déjà plusieurs locataires Microsoft Entra, vous devriez consolider votre environnement en utilisant une architecture monolocataire. Vous pouvez consolider les locataires en transférant les abonnements Azure de vos locataires secondaires vers le locataire principal. Pour plus d’informations, consultez Transférer un abonnement Azure vers un autre répertoire Microsoft Entra.
Cas d’utilisation des architectures multi-locataires. Une organisation de défense peut utiliser une architecture multilocataire pour plusieurs raisons. Les organisations de défense volumineuses et complexes peuvent avoir besoin de plusieurs locataires Microsoft Entra à des fins de sécurité, de conformité et de collaboration (consultez le tableau 1).
Tableau 1. Raisons pour lesquelles utiliser ou créer plusieurs locataires
| Motif | Exemple |
|---|---|
| Séparation approfondie des données à des fins de confidentialité ou de sécurité | Le Bureau de l’Inspecteur général d’une organisation doit être indépendant. |
| Délégation et segmentation de l’administration | Une organisation n’a pas la possibilité de gérer une autre organisation. |
| Souveraineté et/ou propriété des données | Une organisation n’a pas l’autorité légale pour gérer les données d’une autre organisation. |
| Réseau et organisation informatique | Il n’est pas possible ni recommandé de réduire les différentes architectures informatiques d’une grande entreprise dans une seule et même architecture d’entreprise. |
| Analyse et réponse aux incidents du SOC | Le centre des opérations de sécurité (SOC) a besoin d’un locataire distinct pour gérer ses rôles et ses responsabilités. |
Si vous avez besoin de plusieurs locataires Microsoft Entra, vous devez utiliser Microsoft Entra External ID (B2B) et Azure Lighthouse. Ces fonctionnalités permettent de prendre en charge les environnements de défense multilocataires. Pour plus d’informations, consultez l’article Modèles de location pour une solution multilocataire.
Identifier les types de locataires
Les organisations de défense multilocataires peuvent classer les instances Microsoft Entra qu’elles utilisent comme principales ou secondaires. Chaque organisation doit identifier et désigner un locataire comme locataire principal. Tous les autres locataires sont secondaires. La Figure 1 représente une organisation de défense avec un locataire principal et n locataires secondaires (deux locataires secondaires représentés).
Identifier le locataire principal. La plupart des organisations de défense créent le locataire principal lorsqu’elles s’inscrivent à Microsoft 365. Le locataire principal contient (1) toutes les identités d’utilisateur et les licences Microsoft 365 ; (2) les appareils ; et (3) les applications (voir Figure 1). Les organisations de défense utilisent souvent Microsoft Entra Connect pour synchroniser les identités d’Active Directory localement avec le locataire Microsoft Entra principal.
Certaines organisations de défense utilisent Microsoft 365 dans un locataire partagé, qui est détenu et géré par une agence externe. Cette agence agit en tant que fournisseur de services partagés pour Microsoft 365. Même si votre organisation peut ne pas gérer ni contrôler le locataire partagé, elle contient les identités Microsoft Entra sous licence que vos utilisateurs utilisent probablement avec Office 365 et d’autres applications. Dans ce scénario, le locataire du fournisseur de services partagés est le locataire principal.
Identifier tous les locataires secondaires (architecture multi-locataire). Tous les autres locataires gérés par l’organisation sont des locataires secondaires. Vous pouvez avoir des locataires secondaires si vous avez migré des applications sur le cloud avant de mettre en place une zone d’atterrissage Azure à l’échelle de l’entreprise. En général, vous pouvez utiliser les locataires secondaires pour gérer (4) des charges de travail Azure avec des utilisateurs externes (invités B2B) ; ou (5) des comptes cloud uniquement (voir Figure 1).
Utiliser l’arbre de décision. Pour trouver le locataire principal, le moyen le plus simple consiste à examiner les licences d’identité dont vous disposez dans Microsoft Entra ID.
Le locataire avec les licences Microsoft 365 est le locataire principal (voir Figure 2). Le locataire principal peut ne pas être le premier locataire créé par votre organisation, mais il doit être le locataire principal avec tous vos utilisateurs et toutes vos licences Microsoft 365.
Si votre organisation n’utilise pas Microsoft 365, le locataire Microsoft Entra avec les licences EMS (Enterprise Mobility and Security) est le locataire principal. C’est dans ce locataire que vous avez ajouté et vérifié le nom de domaine de votre organisation. Bien souvent, le locataire utilise une identité hybride ou s’intègre à un système de ressources humaines (RH) (voir Figure 2).
Figure 2 : Arbre de décision permettant de déterminer si le locataire Microsoft Entra est principal ou secondaire.
Pour définir Microsoft Entra ID comme plateforme de Confiance Zéro, vous devez utiliser un locataire renseigné avec vos identités utilisateur et doté des licences pour les stratégies d’accès basées sur l’utilisateur ou l’appareil. Les licences Microsoft 365 proposent ces fonctionnalités de Confiance Zéro avec Office 365. Si vous n’utilisez pas Microsoft 365, songez à adopter Enterprise Mobility + Security E5 pour établir un fournisseur d’identité basé sur le cloud pour la Confiance Zéro. Pour plus d’informations, consultez la rubrique Choisir votre autorité d’identité (uniquement disponible en anglais pour le moment).
Configurer la Confiance Zéro
Lorsque vous gérez les identités dans Microsoft Entra ID, vous devez appliquer les recommandations suivantes pour chaque type de locataire. Vous devez d’abord adopter certaines recommandations générales applicables à tous les types de locataires. Une fois ces recommandations générales implémentées, recherchez les recommandations spécifiques au type de locataire (principal ou secondaire), puis appliquez-les.
Pour en savoir plus sur la sécurisation des locataires Microsoft Entra avec confiance zéro, consultez Plan de modernisation rapide Confiance Zéro et Plan de modernisation rapide de la sécurité.
Tous les locataires
Vous devez implémenter les recommandations suivantes avec tous les locataires Microsoft Entra.
Définir des procédures et des comptes d’accès d’urgence. Créez au moins deux comptes d’accès d’urgence pour éviter le verrouillage de votre locataire Microsoft Entra. Vous devez attribuer le rôle d’administrateur général à ces comptes. Il doit s’agit de comptes cloud uniquement. Les comptes cloud uniquement utilisent le domaine *.onmicrosoft.com. Pour plus d’informations, consultez l’article Gérer des comptes d’accès d’urgence dans Azure AD.
Important
Microsoft vous recommande d’utiliser des rôles avec le moins d’autorisations. Cela permet d’améliorer la sécurité de votre organisation. Administrateur général est un rôle hautement privilégié à ne limiter qu’aux scénarios d’urgence lorsque vous ne pouvez pas utiliser un rôle existant.
Protégez Microsoft Entra ID contre les attaques locales. Respectez les meilleures pratiques décrites dans la rubrique Sécurisation de l’accès privilégié. Attribuez les autorisations Microsoft Entra seulement aux comptes d’utilisateur Cloud uniquement avec des informations d’identification résistantes au hameçonnage (comme la clé d’accès matérielle ou l’authentification par certificat). N’utilisez pas d’identités fédérées à des fins administratives. Pour plus d’informations, consultez Protéger Microsoft 365 des attaques locales.
Utilisez Privileged Identity Management. Utilisez Microsoft Entra Privileged Identity Management (PIM) pour gérer les attributions de rôles pour les rôles Microsoft Entra ID et Azure. Vous devez également utiliser PIM en vue de gérer l’appartenance à un groupe éligible pour les groupes de sécurité privilégiés. Définissez des révisions d’accès périodiques pour les administrateurs éligibles et les utilisateurs externes (invités B2B).
Activer l’authentification basée sur le cloud pour tous les utilisateurs. Les méthodes d’authentification basée sur le cloud sont plus sécurisées que celles d’authentification fédérée. Lorsqu’ils sont associés à des appareils à jointure Microsoft Entra, ils offrent une meilleure expérience d’authentification unique. L’authentification fédérée expose Microsoft Entra ID à des compromissions Active Directory locales.
Avec l’authentification basée sur les certificats Microsoft Entra (CBA, certificate-based authentication), il n’est plus utile de fédérer des domaines Microsoft Entra. L’authentification Microsoft Entra prend en charge les méthodes d’authentification sans mot de passe suivantes :
- Clés d’accès (clés de sécurité FIDO2)
- Authentification basée sur un certificat
- Microsoft Authenticator
- Windows Hello Entreprise
Établir des stratégies d’accès conditionnel de référence. La référence en matière d’accès conditionnel varie selon les organisations et les exigences. Établissez un ensemble principal de stratégies d’accès conditionnel pour tous les locataires Microsoft Entra. Utilisez des conditions d’identité, d’appareil, d’application et de risque au sein de votre ensemble de stratégies. Excluez les comptes d’accès d’urgence de vos stratégies d’accès conditionnel.
La Protection des ID Microsoft Entra permet aux organisations de détecter, d’examiner et de corriger les risques basés sur l’identité. Pour protéger les connexions et les utilisateurs risqués, créez des stratégies d’accès conditionnel avec des conditions de risque. Utilisez des stratégies distinctes pour les utilisateurs à risque et les connexions risquées. Renforcez les contrôles appliqués avec un niveau de risque pour chaque type de risque. Pour équilibrer la productivité des utilisateurs avec la sécurité, évitez d’utiliser le contrôle Bloquer dans les stratégies basées sur les risques.
Remarque
Les utilisateurs peuvent corriger eux-mêmes les risques de connexion avec l’authentification MFA. Pour permettre aux utilisateurs de corriger eux-mêmes les risques de connexion, configurez la MFA ou le contrôle d’octroi de force d’authentification dans une stratégie d’accès conditionnel basée sur les risques de connexion.
Les utilisateurs peuvent corriger eux-mêmes les risques utilisateurs en modifiant leurs mots de passe. Pour permettre aux utilisateurs de corriger eux-mêmes les risques utilisateurs, configurez une stratégie d’accès conditionnel basée sur les risques utilisateurs avec le contrôle d’octroi Exiger la modification du mot de passe.
Attention
Les utilisateurs sans mot de passe qui se connectent uniquement avec des méthodes sans mot de passe telles que l’authentification par certificat Entra, la clé d’accès ou Windows Hello Entreprise, peuvent être bloqués par le contrôle d’octroi Exiger une modification du mot de passe s’ils ne peuvent pas réinitialiser leur mot de passe dans Microsoft Entra ID.
Concevez des stratégies d’accès conditionnel pour votre organisation, à l’aide de la liste de contrôle de stratégie d’accès conditionnel d’exemple (voir le tableau 2). Utilisez le mode Rapport uniquement pour tester les stratégies d’accès conditionnel avant le déploiement en production.
Tableau 2 : Liste de contrôle pour stratégie d’accès conditionnel d’exemple.
| Nom de stratégie | Utilisateurs | Applications | Conditions | Contrôle octroyé |
|---|---|---|---|---|
| MFA pour tous les utilisateurs | Tous les utilisateurs | Toutes les applications | Aucune | - MFA résistante au hameçonnage |
| Exiger un appareil géré | Tous les utilisateurs | Toutes les applications | Aucun | - Exige un appareil à jointure hybride Microsoft Entra ou compatible |
| Protection des connexions à risque moyen | Tous les utilisateurs | Toutes les applications | Risque de connexion moyen | - MFA résistante au hameçonnage - Exiger un appareil conforme - Fréquence de connexion : 1 heure (ajuster en fonction de la tolérance au risque de votre organisation) |
| Protéger les connexions à haut risque | Tous les utilisateurs | Toutes les applications | Risque de connexion élevé | - MFA résistante au hameçonnage - Exiger un appareil conforme - Fréquence de connexion : à chaque fois |
| Protéger les utilisateurs à haut risque | Tous les utilisateurs | Toutes les applications | Risque utilisateur élevé | - MFA résistante au hameçonnage - Exiger un appareil conforme - Fréquence de connexion : à chaque fois |
| Sécuriser l’administration Microsoft Entra | Rôles Microsoft Entra | Toutes les applications | Aucune | - MFA résistante au hameçonnage - Exige une station de travail à accès privilégié (PAW) conforme avec des filtres pour appareil mobile |
| Gestion cloud sécurisée | Tous les utilisateurs | Gestion d’Azure Google Cloud Platform Amazon Web Services |
Aucune | - MFA résistante au hameçonnage - Exige une station de travail à accès privilégié (PAW) conforme avec des filtres pour appareil mobile |
L’exemple de stratégie défini dans le tableau 2 concerne les organisations sans mot de passe où tous les utilisateurs utilisent uniquement la MFA résistante au hameçonnage à partir d’appareils gérés. Les utilisateurs privilégiés utilisent des stations de travail à accès privilégié (PAW) gérées par Intune. Au lieu d’exiger une modification du mot de passe pour les utilisateurs à haut risque, la stratégie utilisateur à risque applique la force d’authentification et les contrôles de fréquence de connexion. Ces contrôles offrent certaines protections, mais ne corrigent pas le niveau de risque de l’utilisateur dans la Protection des ID Microsoft Entra. Votre équipe des opérations de sécurité doit examiner et corriger les utilisateurs à haut risque.
Pour en savoir plus sur le déploiement de l’accès conditionnel, consultez Planifier un déploiement d’accès conditionnel.
Utiliser des identités de locataire principal pour accéder à toutes les applications. Les utilisateurs doivent pouvoir utiliser leur identité dans le locataire principal pour accéder aux applications. Vous devez inscrire des applications dans le locataire principal. Définissez une stratégie pour inscrire des applications auprès du locataire principal, quel que soit l’emplacement d’hébergement de l’infrastructure d’application.
Pour les applications héritées qui ne prennent pas en charge les protocoles d’authentification modernes, utilisez le service Proxy d’application Microsoft Entra dans le locataire principal. Le proxy d’application Microsoft Entra offre des fonctionnalités de Confiance Microsoft Entra aux applications héritées sans modifier le code.
Lorsqu’un fournisseur de services partagés ou une agence externe contrôle le locataire principal, il doit déléguer les autorisations d’inscription d’application. Si le fournisseur de services n’offre pas cette délégation, vous devez inscrire les applications auprès du locataire secondaire que votre organisation contrôle à la place. Toutefois, les utilisateurs doivent toujours pouvoir accéder à ces applications sans créer d’identité dans le locataire secondaire. Avec cette configuration, attribuez l’accès utilisateur à l’aide des identités externes (invités B2B) pour les utilisateurs dans le locataire principal. Pour plus d’informations, consultez l’article Sécuriser les applications avec la Confiance Zéro.
Utilisez Microsoft Entra ID pour gérer d’autres environnements cloud. Microsoft Entra ID n’est pas seulement une plateforme d’identité pour Azure et Microsoft 365. Utilisez Microsoft Entra ID pour accéder à d’autres environnements cloud. Ces environnements incluent les produits SaaS (software as a service) populaires et les plateformes cloud comme Amazon Web Services (AWS) et Google Cloud Platform (GCP). Pour plus d’informations, consultez Galerie d’applications Microsoft Entra.
Utiliser une architecture de cloud computing sécurisée (SCCA). Chaque organisation de défense doit déployer une architecture de zone d’atterrissage conforme SCCA. La zone d’atterrissage doit se trouver dans les abonnements Azure attachés au locataire principal.
Segmenter la gestion des ressources Azure dans un seul locataire. Vous devez utiliser le contrôle d’accès en fonction des rôles Azure pour isoler les ressources et la gestion des abonnements au sein d’une zone d’atterrissage Azure à l’échelle de l’entreprise. Songez à transférer les abonnements des locataires secondaires vers le locataire principal.
Utilisez Gestion des autorisations Microsoft Entra. Gestion des autorisations Microsoft Entra est la solution de gestion des droits d’utilisation d’une infrastructure cloud (CIEM) de Microsoft. Vous pouvez utiliser Gestion des autorisations Microsoft Entra pour bénéficier d’une visibilité sur les autorisations attribuées à toutes les identités. Vous pouvez également l’utiliser pour suivre les autorisations suspectes dans l’environnement multicloud de l’organisation.
Utilisez Microsoft Entra ID Governance. Utilisez Microsoft Entra ID Governance pour automatiser le cycle de vie de l’attribution d’accès des utilisateurs et des invités. Effectuez les révisions d’accès afin de supprimer l’accès à l’environnement cloud pour les utilisateurs qui n’en ont plus besoin.
Sécuriser des identités de charge de travail. Utilisez les fonctionnalités Microsoft Entra Workload ID pour gérer et appliquer des stratégies de Confiance Zéro adaptatives pour les identités d’application (principaux de service) dans Microsoft Entra ID.
Activer Defender pour le cloud pour votre entreprise. Utilisez Defender pour le cloud pour votre environnement multicloud. Veillez à activer les fonctionnalités de sécurité renforcée pour surveiller les ressources Azure et corriger les risques de configuration. La protection Defender pour le cloud s’étend au-delà d’Azure pour vous aider à sécuriser les environnements hybrides et multiclouds.
Déployer Sentinel et connectez toutes les sources de données disponibles. Agrégez les signaux de sécurité dans un système de gestion des informations et des événements de sécurité (SIEM) comme Microsoft Sentinel. Déployez Sentinel et connectez toutes les sources de données des signaux de sécurité en configurant les connecteurs de données.
Locataires principaux
Vous devez implémenter les recommandations suivantes avec les locataires principaux uniquement.
Les utilisateurs finaux n’ont qu’une seule identité dans Entra AD. Synchronisez Active Directory Domain Services sur site avec le locataire Microsoft Entra principal. La synchronisation renseigne les utilisateurs, les groupes et les appareils de l’organisation auprès de Microsoft Entra ID. Même si les locataires secondaires peuvent comporter des invités B2B externes, les utilisateurs ne doivent mémoriser qu’un seul nom d’utilisateur pour toutes les applications et services. L’expérience utilisateur et les résultats de Confiance Zéro sont meilleurs lorsque vous utilisez les identités dans le locataire principal pour la connexion Windows et l’accès aux applications.
Joindre et gérer des appareils avec le locataire principal. Le locataire Microsoft Entra principal contient tous les utilisateurs et appareils de l’organisation. Jointure Microsoft Entra (ou jointure hybride Microsoft Entra) d’appareils Windows au locataire principal et gestion avec Microsoft Intune. Utilisez la stratégie Intune pour déployer Microsoft Defender for Endpoint qui propose une fonctionnalité de détection et de réponse étendue (XDR).
Déléguer les autorisations d’inscription des applications. Les applications d'entreprise, y compris le code d'application s'exécutant dans n'importe quel abonnement Azure, utilisent le locataire principal Microsoft Entra ID pour l'identité de l'utilisateur. Utilisez Privileged Identity Management pour rendre les développeurs éligibles au rôle de développeur d’applications Microsoft Entra ou au rôle d’inscription d’applications personnalisée. Cette configuration permet aux développeurs qui créent des applications dans des locataires secondaires de les inscrire auprès du locataire principal à des fins d’identité.
Joindre les services PaaS (platform as a service) qui ont besoin d’une identité d’utilisateur final. Certains services PaaS (comme Azure Files et Azure Virtual Desktop) dépendent d’une configuration d’identité hybride ou de droits de licence. Vous devez déployer ces services sur des abonnements Azure dans le locataire principal.
Locataires secondaires
Vous devez implémenter les recommandations suivantes avec les locataires secondaires uniquement.
Procurez-vous les licences requises pour la gestion Microsoft Entra. Pour activer les fonctionnalités de sécurité avancées dans les locataires secondaires, vous avez besoin de licences. Déterminez des licences dont vous avez besoin en fonction des utilisateurs, des charges de travail et des appareils.
Identités d’utilisateur. Vous devez disposer de licences Microsoft Entra ID Premium P2 pour les administrateurs clients et les comptes d’accès d’urgence. Si vous utilisez un modèle de gestion des identités externes (invité B2B), vous devez attribuer au moins une licence Microsoft Entra ID Premium P2 à un utilisateur local du locataire. Cette configuration permet d’activer les fonctionnalités Premium (comme l’accès conditionnel et la protection des identités). Pour plus d’informations, consultez Considérations courantes sur la gestion multilocataire des utilisateurs.
Identités de charge de travail. Vous devez utiliser les identités de charge de travail premium pour sécuriser les identités de charge de travail avec accès aux ressources dans le locataire principal (comme l’API MS Graph).
Gestion des appareils. Vous devrez peut-être gérer des appareils avec Microsoft Intune dans le locataire secondaire. Le cas échéant, vous devez vous procurer des licences Enterprise Mobility and Security (EMS).
Configurer des stratégies d’accès interlocataires (XTAP). Les paramètres d’accès interlocataire des identités externes Microsoft Entra (Microsoft Entra B2B collaboration) permettent à un locataire secondaire d’approuver certaines revendications du locataire principal. Ajoutez le locataire Microsoft Entra principal en tant qu’organisation et mettez à jour les paramètres d’approbation entrant de sorte à inclure les options suivantes :
- Faire confiance à l’authentification multifacteur (MFA) sur les locataires Microsoft Entra
- Faire confiance aux appareils conformes
- Faire confiance aux appareils à jointure hybride Microsoft Entra
- Facultatif : accepter automatiquement les invitations du locataire
Gérer le locataire secondaire avec les identités du locataire principal. Réduisez la surcharge administrative et les coûts en utilisant des utilisateurs externes (invités B2B) du locataire principal pour gérer le locataire secondaire et les ressources Azure. Attribuez des rôles Microsoft Entra d’après rôle Microsoft Entra de privilège minimum par tâche à l’aide de Microsoft Entra Privileged Identity Management. Utilisez l’accès initié par l’utilisateur final ou la synchronisation interlocataire pour réduire la surcharge de gestion lors de l’intégration des identités externes dans le locataire secondaire.
Utilisez Azure Lighthouse pour faciliter l’accès Sentinel à partir du locataire principal. Azure Lighthouse vous offre un autre moyen de gérer Azure entre les locataires. Azure Lighthouse utilise des modèles Azure Resource Manager (ARM) pour attribuer des rôles Azure à des identités dans un locataire externe. Cette approche n’utilise pas d’objets utilisateur invité B2B. Lorsqu’un administrateur se connecte au portail pour gérer Azure, il voit toutes les ressources parmi tous les locataires. Cette vue consolidée inclut des abonnements dotés d’autorisations attribuées par Azure Lighthouse. Étant donné qu’il n’existe aucun objet invité B2B, l’administrateur n’a pas besoin de changer de répertoire. Utilisez Azure Lighthouse pour faciliter la gestion de Microsoft Sentinel parmi les locataires.