Bonnes pratiques pour toutes les architectures d’isolation
Vous trouverez ci-après des considérations de conception pour toutes les configurations d’isolation. De nombreux liens sont fournis dans ce contenu. Nous fournissons des liens vers des contenus au lieu de les dupliquer ici. Ainsi, vous aurez toujours accès aux informations les plus à jour.
Pour obtenir des conseils généraux sur la configuration de locataires Microsoft Entra (isolés ou non), reportez-vous au guide de déploiement des fonctionnalités de Microsoft Entra.
Remarque
Nous vous suggérons de personnaliser tous les locataires isolés de manière claire et différenciée pour éviter de travailler accidentellement dans le mauvais locataire.
Isolation : principes de sécurité
Quand vous concevez des environnements isolés, il est important de prendre en compte les principes suivants :
Utilisez uniquement une authentification moderne : les applications déployées dans des environnements isolés doivent utiliser une authentification moderne basée sur des revendications (par exemple, SAML, * Auth, OAuth2 et OpenID Connect) pour utiliser des fonctionnalités telles que la fédération, Microsoft Entra B2B Collaboration, la délégation et le framework de consentement. Ainsi, les applications héritées qui dépendent de méthodes d’authentification héritées telles que NTLM (NT LAN Manager) ne seront pas transférées dans les environnements isolés.
Appliquez une authentification forte : une authentification forte doit toujours être utilisée pour l’accès aux services et à l’infrastructure des environnements isolés. Dans la mesure du possible, une authentification sans mot de passe comme Windows Hello Entreprise ou une clé de sécurité FIDO2 doit être utilisée.
Déployez des stations de travail sécurisées : Les stations de travail sécurisées fournissent le mécanisme garantissant que la plateforme et l’identité représentée par la plateforme sont correctement attestées et sécurisées vis-à-vis de l’exploitation. Deux autres approches doivent être prises en compte :
Utilisez des PC Windows 365 cloud (PC cloud) avec l’API Microsoft Graph.
Utilisez l’accès conditionnel et le filtre pour appareils comme condition.
Éliminez les mécanismes de confiance hérités : les annuaires et services isolés ne doivent pas établir de relations d’approbation avec d’autres environnements par le biais de mécanismes hérités (approbations Active Directory, par exemple). Toutes les approbations entre environnements doivent être établies avec des constructions modernes telles que la fédération et l’identité basée sur des revendications.
Isolez les services : minimisez la surface d’exposition aux attaques en protégeant l’infrastructure de service et les identités sous-jacentes. Autorisez l’accès uniquement par le biais d’une authentification moderne pour les services et d’un accès à distance sécurisé (également protégé par une authentification moderne) pour l’infrastructure.
Attributions de rôles au niveau de l’annuaire : évitez ou limitez les attributions de rôles au niveau de l’annuaire (Administrateur d’utilisateur sur l’étendue d’annuaire au lieu de l’application d’une étendue AU) ou les rôles d’annuaire spécifiques aux services avec des actions de plan de contrôle (Administrateur des connaissances avec des autorisations pour gérer les appartenances aux groupes de sécurité).
Outre les conseils fournis dans le guide des opérations générales Microsoft Entra, nous vous recommandons de consulter les considérations suivantes sur les environnements isolés.
Provisionnement d’identités humaines
Comptes privilégiés
Approvisionnez des comptes dans l’environnement isolé pour les équipes administratives et informatiques qui exploitent l’environnement. Cela vous permet d’ajouter des stratégies de sécurité plus fortes comme le contrôle d’accès basé sur les appareils pour les stations de travail sécurisées. Comme indiqué dans les sections précédentes, les environnements hors production peuvent éventuellement utiliser Microsoft Entra B2B Collaboration pour intégrer des comptes privilégiés aux locataires hors production avec la même posture et les mêmes contrôles de sécurité que ceux conçus pour l’accès privilégié dans leur environnement de production.
Les comptes cloud uniquement représentent le moyen le plus simple d’approvisionner des identités humaines dans un locataire Microsoft Entra et se prêtent bien aux environnements entièrement nouveaux. Toutefois, s’il existe une infrastructure locale qui correspond à l’environnement isolé (par exemple, une forêt Active Directory de préproduction ou de gestion), vous pouvez envisager de synchroniser les identités à partir de cette infrastructure. C’est particulièrement vrai si l’infrastructure locale décrite dans ce document est également utilisée pour des solutions IaaS qui nécessitent un accès au serveur pour gérer le plan de données de la solution. Pour plus d’informations sur ce scénario, consultez Protéger Microsoft 365 des attaques locales. La synchronisation à partir d’environnements locaux isolés peut également être nécessaire en présence d’exigences de conformité réglementaire spécifiques (authentification par carte à puce uniquement, par exemple).
Remarque
Il n’existe aucun contrôle technique pour la vérification des identités pour les comptes Microsoft Entra B2B. Les identités externes provisionnées avec Microsoft Entra B2B permettent de démarrer l’intégration avec un seul facteur. Pour l’organisation, les mesures d’atténuation des risques consistent à disposer d’un processus qui vérifie les identités requises avant qu’une invitation B2B soit émise à mettre en œuvre des révisions d’accès régulières des identités externes pour gérer le cycle de vie. Envisagez d’activer une stratégie d’accès conditionnel pour contrôler l’inscription de l’authentification multifacteur.
Externalisation des rôles à haut risque
Pour réduire les menaces internes, il est possible d’externaliser l’accès aux rôles d’administrateur général et d’administrateur de rôle privilégié à un fournisseur de services managés en utilisant Azure B2B Collaboration ou en déléguant l’accès à un partenaire fournisseur de solutions cloud ou à Lighthouse. Cet accès peut être contrôlé par les équipes internes via des flux d’approbation dans Azure Privileged Identity Management (PIM). Cette approche peut réduire les menaces internes de manière considérable. Vous pouvez l’utiliser pour répondre aux exigences de conformité exprimées par certains clients.
Approvisionnement d’identités non humaines
Comptes d’accès d’urgence
Microsoft recommande aux organisations de disposer de deux comptes d’accès d’urgence, en mode cloud uniquement, attribué indéfiniment au rôle Administrateur général. Ces comptes hautement privilégiés ne sont pas attribués à des personnes spécifiques. Les comptes sont limités à des scénarios d’urgence ou « de secours » dans lesquels il est impossible d’utiliser des comptes normaux ou tous les administrateurs sont accidentellement verrouillés. Ces comptes doivent être créés, conformément aux recommandations relatives aux comptes d’accès d’urgence.
Identités managées Azure
Utilisez des identités managées Azure pour les ressources Azure nécessitant une identité de service. Consultez la liste des services qui prennent en charge les identités managées pour la conception de vos solutions Azure.
Si les identités managées ne sont pas prises en charge ou ne sont pas applicables, envisagez de provisionner des objets principal de service.
Comptes de service hybrides
Certaines solutions hybrides peuvent nécessiter l’accès aux ressources locales et cloud. Un exemple de cas d’usage serait une application qui utilise un compte de service dans AD DS pour accéder aux serveurs joints à un domaine local et possède également un compte dans Microsoft Entra ID, car il nécessite l’accès à Microsoft Online Services.
Les comptes de service locaux n’ont généralement pas la possibilité de se connecter de manière interactive. Ainsi, dans les scénarios cloud, ils ne peuvent pas répondre à des exigences d’identification fortes, par exemple dans le cadre de l’authentification multifacteur. Dans ce scénario, n’utilisez pas de compte de service synchronisé à partir d’un environnement local. Utilisez plutôt une identité managée/un principal de service. Pour le principal de service, utilisez un certificat comme solution d’identification ou protégez-le avec l’accès conditionnel.
Si des contraintes techniques vous en empêchent et si le même compte doit être utilisé pour les environnements locaux et cloud, implémentez des contrôles compensatoires (accès conditionnel, par exemple) pour limiter la provenance du compte hybride à un emplacement réseau spécifique.
Affectation des ressources
Une solution d’entreprise peut comprendre plusieurs ressources Azure et son accès doit être géré, puis gouverné comme unité logique d’affectation (un groupe de ressources). Dans ce scénario, des groupes de sécurité Microsoft Entra peuvent être créés et associés aux autorisations et attributions de rôles appropriées à l’échelle de l’ensemble des ressources de la solution. Ainsi, l’ajout d’utilisateurs à ces groupes ou leur suppression entraîne l’autorisation ou le refus d’accès à l’ensemble de la solution.
Nous vous recommandons d’utiliser des groupes de licences et des groupes de sécurité pour les services Microsoft qui s’appuient sur un utilisateur disposant d’une attribution de siège de licence comme condition préalable avant de fournir l’accès (par exemple, Dynamics 365, Power BI).
Les groupes natifs cloud Microsoft Entra peuvent être gouvernés à partir du cloud de manière native quand ils sont combinés avec des révisions d’accès Microsoft Entra et la gestion des droits d’utilisation Microsoft Entra.
Microsoft Entra ID prend également en charge l’attribution directe d’utilisateurs aux services SaaS tiers (par exemple, Salesforce et Service Now) et aux applications locales pour l’authentification unique et le provisionnement d’identités. Les affectations directes aux ressources peuvent être gouvernées à partir du cloud de manière native quand elles sont combinées avec des révisions d’accès Microsoft Entra et la gestion des droits d’utilisation Microsoft Entra. L’attribution directe peut être adaptée à l’attribution côté utilisateur final.
Certains scénarios peuvent nécessiter l’octroi d’un accès aux ressources locales par le biais de groupes de sécurité Active Directory locaux. Dans ce cas, envisagez le cycle de synchronisation avec Microsoft Entra ID pour la conception des SLA de processus.
Gestion de l’authentification
Cette section décrit les vérifications et les actions à effectuer pour la gestion des informations d’identification et les stratégies d’accès en fonction de la posture de sécurité de votre organisation.
Gestion des informations d’identification
Informations d’identification fortes
Toutes les identités humaines (comptes locaux et identités externes provisionnées avec B2B Collaboration) dans l’environnement isolé doivent être provisionnées avec des informations d’identification fortes (authentification multifacteur ou clé FIDO, par exemple). Les environnements possédant une infrastructure locale sous-jacente avec une méthode d’authentification forte comme une authentification par carte à puce peuvent continuer à utiliser l’authentification par carte à puce dans le cloud.
Informations d’identification sans mot de passe
Une solution sans mot de passe reste la meilleure solution pour garantir la méthode d’authentification la plus pratique et la plus sûre. Les solutions d’identification sans mot de passe telles que les clés de sécurité FIDO et Windows Hello Entreprise sont recommandées pour les identités humaines avec des rôles privilégiés.
Protection par mot de passe
Si l’environnement est synchronisé à partir d’une forêt Active Directory locale, vous devez déployer la protection par mot de passe Microsoft Entra pour éliminer les mots de passe faibles de votre organisation. Le verrouillage intelligent Microsoft Entra doit également être utilisé dans des environnements hybrides ou cloud uniquement pour bloquer les acteurs malveillants qui tentent de deviner les mots de passe de vos utilisateurs ou utilisent des méthodes d’intrusion agressives.
Gestion des mots de passe en libre-service
Les utilisateurs qui ont besoin de changer ou de réinitialiser leur mot de passe sont une des plus grandes sources de volume et de coût des appels au support technique. En plus du coût, le changement de mot de passe vu comme outil pour réduire le risque utilisateur est une étape fondamentale dans l’amélioration de l’attitude de votre organisation en matière de sécurité. Déployez au minimum la gestion des mots de passe en libre-service pour les comptes humains et de test avec des mots de passe pour limiter les appels au support technique.
Mots de passe pour les identités externes
Avec Microsoft Entra B2B Collaboration, un processus d’invitation et d’échange permet aux utilisateurs externes tels que les partenaires, les développeurs et les sous-traitants d’utiliser leurs propres informations d’identification pour accéder aux ressources de votre entreprise. Ceci réduit la nécessité d’introduire davantage de mots de passe dans les locataires isolés.
Notes
Certains workflows, applications ou infrastructures peuvent nécessiter des informations d’identification locales. Évaluez cet aspect au cas par cas.
Informations d’identification des principaux de service
Pour les scénarios impliquant des principaux de service, utilisez des informations d’identification de certificat pour les principaux de service ou l’accès conditionnel pour les identités de charge de travail. Si nécessaire, utilisez des secrets client comme exception à la stratégie organisationnelle.
Dans les deux cas, Azure Key Vault peut être utilisé avec des identités managées Azure pour que l’environnement d’exécution (par exemple, une fonction Azure) puisse récupérer les informations d’identification du coffre de clés.
Consultez cet exemple pour créer des principaux de service avec un certificat auto-signé pour l’authentification de principaux de service avec des informations d’identification de certificat.
Stratégies d'accès
Les sections suivantes contiennent des recommandations pour les solutions Azure. Pour obtenir des conseils généraux sur les stratégies d’accès conditionnel pour les environnements individuels, consultez les Bonnes pratiques en matière d’accès conditionnel, le guide des opérations Microsoft Entra et l’article Accès conditionnel pour Confiance Zéro :
Définissez des stratégies d’accès conditionnel pour l’application cloud API Gestion des services Windows Azure afin d’appliquer une posture de sécurité des identités pour l’accès à Azure Resource Manager. Ceci doit inclure des contrôles sur l’authentification multifacteur et des contrôles basés sur les appareils pour autoriser l’accès uniquement par le biais de stations de travail sécurisées. (Pour en savoir plus, consultez la section Rôles privilégiés sous Gouvernance des identités). En outre, utilisez l’accès conditionnel pour appliquer un filtre pour appareils.
Pour toutes les applications intégrées à des environnements isolés, des stratégies d’accès conditionnel explicites doivent être appliquées dans le cadre du processus d’intégration.
Définissez des stratégies d’accès conditionnel pour l’inscription des informations de sécurité comme processus racine de confiance sécurisé au niveau local (par exemple, pour les stations de travail à des emplacements physiques, identifiables par des adresses IP, auxquelles les employés doivent accéder en personne pour vérification).
Envisagez d’utiliser l’accès conditionnel pour restreindre les identités de charge de travail. Créez une stratégie pour limiter ou mieux contrôler l’accès en fonction de l’emplacement ou d’autres circonstances pertinentes.
Demandes d’authentification
Les identités externes provisionnées avec Microsoft Entra B2B peuvent impliquer le réapprovisionnent des informations d’identification pour l’authentification multifacteur dans le locataire de ressource. Ceci peut être nécessaire si aucune stratégie d’accès interlocataire n’a été configurée avec le locataire de ressource. Cela signifie que l’intégration au système est démarrée avec un seul facteur. Avec cette approche, l’atténuation des risques consiste, pour l’organisation, à disposer d’un processus de vérification du profil de risque de l’utilisateur et des informations d’identification avant l’émission d’une invitation B2B. En outre, définissez l’accès conditionnel au processus d’inscription comme décrit précédemment.
Utilisez les paramètres d’accès interlocataire External Identities pour gérer leur collaboration avec d’autres organisations Microsoft Entra et d’autres clouds Microsoft Azure via une collaboration B2B et une connexion directe B2B.
Pour une configuration et un contrôle d’appareil spécifiques, vous pouvez utiliser des filtres d’appareil dans les stratégies d’accès conditionnel pour cibler ou exclure des appareils spécifiques. Ceci vous permet de restreindre l’accès aux outils de gestion Azure à partir d’une station de travail d’administration sécurisée donnée. Vous pouvez emprunter d’autres approches et notamment utiliser Azure Virtual Desktop, Azure Bastion ou un PC cloud.
Les applications de gestion de la facturation telles qu’Azure EA Portal ou les comptes de facturation MCA ne sont pas représentées comme applications cloud pour le ciblage de l’accès conditionnel. En guise de contrôle compensatoire, définissez des comptes d’administration distincts et ciblez les stratégies d’accès conditionnel sur ces comptes à l’aide d’une condition « Toutes les applications ».
Gouvernance des identités
Rôles privilégiés
Voici quelques principes de gouvernance des identités à prendre en compte dans toutes les configurations de locataire pour l’isolation.
Aucun accès permanent : aucune identité humaine ne doit disposer d’un accès permanent permettant d’effectuer des opérations privilégiées dans des environnements isolés. Le contrôle d’accès en fonction du rôle (RBAC) Azure s’intègre à Microsoft Entra PIM (Privileged Identity Management). PIM fournit une activation juste-à-temps déterminée par des barrières de sécurité comme l’authentification multifacteur, le workflow d’approbation et la durée limitée.
Nombre d’administrateurs : les organisations doivent définir un nombre minimal et maximal de personnes humaines disposant d’un rôle privilégié afin d’atténuer les risques pour la continuité de l’activité. Si le nombre de rôles privilégiés est trop faible, la couverture de fuseau horaire peut être insuffisante. Réduisez les risques de sécurité en limitant autant que possible le nombre d’administrateurs, en suivant le principe des privilèges minimum.
Limitez l’accès privilégié : créez des groupes cloud uniquement et avec attribution de rôle pour les privilèges élevés ou sensibles. Ceci permet de protéger les utilisateurs attribués et l’objet de groupe.
Droit d’accès minimal : les identités doivent recevoir uniquement les autorisations requises pour effectuer les opérations nécessitant des privilèges conformément à leur rôle dans l’organisation.
Les rôles personnalisés RBAC Azure permettent de concevoir des rôles avec privilèges minimum en fonction des besoins de l’organisation. Nous recommandons de faire créer ou vérifier les définitions de rôles personnalisés par des équipes de sécurité spécialisées et que ces définitions atténuent le risque d’attribution involontaire de privilèges excessifs. La création de rôles personnalisés peut être auditée avec Azure Policy.
Afin d’atténuer le risque d’utilisation accidentelle de rôles qui ne sont pas destinés à une utilisation plus large dans l’organisation, utilisez Azure Policy pour définir explicitement les définitions de rôles pouvant être utilisées pour attribuer l’accès. Apprenez-en davantage avec cet exemple GitHub.
Accès privilégié à partir de stations de travail sécurisées : tous les accès privilégiés doivent provenir d’appareils sécurisés et verrouillés. La séparation de ces tâches et comptes sensibles et des stations de travail et appareils utilisés au quotidien protèges les comptes privilégiés contre les attaques par hameçonnage, les vulnérabilités du système d’exploitation et des applications, différentes attaques par emprunt d’identité et les vols d’informations d’identification, notamment avec des enregistreurs de frappe ou via des attaques de type « Pass the hash » et « Pass the ticket ».
Vous pouvez adopter différentes approches pour utiliser des appareils sécurisés dans le cadre de votre scénario d’accès privilégié, notamment l’utilisation de stratégies d’accès conditionnel pour cibler ou exclure des appareils spécifiques, l’utilisation d’Azure Virtual Desktop, d’Azure Bastion ou d’un PC cloud ou la création de stations de travail managées par Azure ou de stations de travail à accès privilégié.
Processus et garde-fous pour les rôles privilégiés : les organisations doivent définir des processus et des garde-fous techniques pour veiller à ce que les opérations privilégiées puissent être exécutées à tout moment, tout en respectant les exigences réglementaires. Voici quelques exemples de critères relatifs à ces garde-fous :
Qualifier les humains avec des rôles privilégiés (par exemple, employé/fournisseur à temps plein, niveau d’autorisation, citoyenneté).
Définir explicitement l’incompatibilité des rôles (ou séparer les tâches). Par exemple, les équipes avec des rôles d’annuaire Microsoft Entra ne doivent pas être responsables de la gestion des rôles privilégiés Azure Resource Manager, et ainsi de suite.
Déterminer, pour chaque rôle, si des attributions de groupes ou des attributions d’utilisateurs directes sont préférables.
Les stratégies Azure ne permettent pas d’automatiser la surveillance des attributions IAM en dehors de Microsoft Entra PIM. Pour atténuer ce problème, n’accordez pas de rôles Propriétaire de l’abonnement ou Administrateur de l’accès utilisateur aux équipes d’ingénierie. Au lieu de cela, créez des groupes attribués à des rôles avec privilèges minimum tels que le rôle Contributeur et déléguez la gestion de ces groupes aux équipes d’ingénierie.
Accès aux ressources
Attestation : les identités possédant des rôles privilégiés doivent être révisées régulièrement pour que l’appartenance reste à jour et justifiée. Les révisions d’accès Microsoft Entra s’intègrent aux rôles RBAC Azure, aux appartenances aux groupes et aux identités externes Microsoft Entra B2B.
Cycle de vie : les opérations privilégiées peuvent nécessiter un accès à plusieurs ressources telles que des applications métier, des applications SaaS et des groupes de ressources et abonnements Azure. La gestion des droits d’utilisation Microsoft Entra permet de définir des packages d’accès qui représentent une ressource définie attribuée aux utilisateurs comme unité, établissent une période de validité, des workflows d’approbation, et ainsi de suite.
Gestion du cycle de vie du locataire et des abonnements
Cycle de vie des locataires
Nous vous recommandons d’implémenter un processus pour demander un nouveau locataire Microsoft Entra d’entreprise. Ce processus doit tenir compte des points suivants :
Justification métier pour sa création. La création d’un locataire Microsoft Entra accroît considérablement la complexité. Il est donc essentiel d’en démontrer la nécessité.
Le cloud Azure dans lequel il doit être créé (par exemple, Commercial, Government, et ainsi de suite).
S’agit-il d’un locataire de production ou hors production ?
Exigences de résidence des données d’annuaire.
Qui va gérer cela
Formation aux exigences de sécurité courantes et assimilation de ces exigences.
Après approbation, le locataire Microsoft Entra sera créé, configuré avec les contrôles de référence nécessaires, et intégré au plan de facturation, à la surveillance, et ainsi de suite.
Une révision régulière des locataires Microsoft Entra dans le plan de facturation doit être implémentée pour détecter et découvrir la création de locataire en dehors du processus gouverné. Pour plus d’informations, reportez-vous à la section Inventaire et visibilité de ce document.
La création d’un locataire Azure AD B2C peut être contrôlée à l’aide d’Azure Policy. La stratégie s’exécute quand un abonnement Azure est associé au locataire B2C (prérequis pour la facturation). Les clients peuvent limiter la création de locataires Azure AD B2C à des groupes d’administration spécifiques.
Il n’existe aucun contrôle technique pour subordonner la création de locataires à une organisation. Toutefois, l’activité est enregistrée dans le journal d’audit. L’intégration au plan de facturation est un contrôle compensatoire en entrée. Il doit être complété par une surveillance et des alertes.
Cycle de vie des abonnements
Voici quelques considérations à prendre en compte pour la conception d’un processus de cycle de vie des abonnements gouverné :
Définissez une taxonomie des applications et des solutions qui nécessitent des ressources Azure. Toutes les équipes qui demandent des abonnements doivent fournir leur « identificateur de produit » au moment de la demande. Cette taxonomie d’informations détermine les éléments suivants :
Locataire Microsoft Entra pour provisionner l’abonnement
Compte Azure EA à utiliser pour la création de l’abonnement
Conventions d’affectation de noms
Attribution de groupe d’administration
Autres aspects tels que l’étiquetage, la facturation croisée, l’utilisation de la vue des produits, et ainsi de suite.
N’autorisez pas la création d’abonnements ad hoc par le biais des portails ou par d’autres moyens. Envisagez plutôt de gérer les abonnements par programmation à l’aide d’Azure Resource Manager et d’extraire des rapports de consommation et de facturation par programmation. Ceci peut permettre de limiter le provisionnement des abonnements aux utilisateurs autorisés et d’atteindre les objectifs de votre stratégie et de votre taxonomie. L’aide sur les principaux AZOps peut vous aider à créer une solution pratique.
Quand un abonnement est provisionné, créez des groupes cloud Microsoft Entra qui contiendront les rôles Azure Resource Manager standard requis par les équipes d’application tels que les rôles Contributeur et Lecteur et les rôles personnalisés approuvés. Ceci vous permet de gérer les attributions de rôles RBAC Azure avec un accès privilégié gouverné à grande échelle.
Configurez les groupes afin qu’ils soient éligibles pour les rôles RBAC Azure à l’aide de Microsoft Entra PIM avec les contrôles correspondants (stratégie d’activation, révisions d’accès, approbateurs, et ainsi de suite).
Ensuite, déléguez la gestion des groupes aux propriétaires de solutions.
En guise de garde-fou, n’attribuez pas de propriétaires de produits aux rôles Propriétaire ou Administrateur de l’accès utilisateur pour éviter toute attribution directe accidentelle de rôles en dehors de Microsoft Entra PIM ou, éventuellement, le déplacement de l’abonnement vers un autre locataire.
Pour les clients qui choisissent d’activer la gestion d’abonnement interlocataire dans des locataires hors production avec Azure Lighthouse, veillez à ce que les stratégies d’accès du compte de production privilégié (par exemple, un accès privilégié uniquement à partir de stations de travail sécurisées) soient appliquées au moment de l’authentification pour gérer les abonnements.
Si votre organisation dispose d’architectures de référence pré-approuvées, le provisionnement des abonnements peut être intégré à des outils de déploiement de ressources tels qu’Azure Blueprints ou Terraform.
De par l’affinité entre locataires et abonnements Azure, l’approvisionnement des abonnements doit prendre en compte la multitude d’identités pour le même acteur humain (employé, partenaire, fournisseur, et ainsi de suite) sur plusieurs locataires et attribuer l’accès en conséquence.
Rôles EA et MCA
Le portail Contrat Entreprise Azure (Azure EA) ne s’intègre pas au contrôle d’accès en fonction du rôle (RBAC) Azure ni à l’accès conditionnel. Pour atténuer ce problème, utilisez des comptes d’administration dédiés qui peuvent être ciblés avec des stratégies et une surveillance supplémentaire.
Le portail Contrat Entreprise Azure (EA) n’offre pas de journal d’audit. Pour atténuer ce problème, envisagez un processus gouverné automatisé pour provisionner les abonnements en tenant compte des considérations décrites plus haut, utilisez des comptes EA dédiés et auditez les journaux d’authentification.
Les rôles Contrat client Microsoft (MCA, Microsoft Customer Agreement) ne s’intègrent pas à PIM de manière native. Pour atténuer ce problème, utilisez des comptes MCA dédiés et surveillez l’utilisation de ces comptes.
Locataires Azure AD B2C
Dans un locataire Azure AD B2C, les rôles intégrés ne prennent pas en charge PIM. Pour renforcer la sécurité, nous vous recommandons d’utiliser Microsoft Entra B2B Collaboration afin d’intégrer les équipes d’ingénierie chargées de la gestion des identités et des accès client (CIAM, Customer Identity Access Management) à partir de votre locataire Azure, de leur attribuer des rôles privilégiés Azure AD B2C et d’appliquer des stratégies d’accès conditionnel à ces comptes d’administration dédiés.
Les rôles privilégiés de locataire Azure AD B2C ne sont pas intégrés aux révisions d’accès Microsoft Entra. Pour atténuer ce problème, créez des comptes dédiés dans le locataire Microsoft Entra de l’organisation, ajoutez ces comptes à un groupe et effectuez des révisions d’accès régulières sur ce groupe.
En suivant les instructions sur l’accès d’urgence pour Microsoft Entra ID ci-dessus, envisagez de créer des comptes d’accès d’urgence équivalents en plus des administrateurs externes décrits plus haut.
Nous recommandons que la propriété logique de l’abonnement Microsoft Entra sous-jacent du locataire B2C s’aligne aux équipes d’ingénierie CIAM, de la même façon que les autres abonnements Azure sont utilisés pour les solutions B2C.
Opérations
Voici des considérations opérationnelles supplémentaires pour Microsoft Entra ID, spécifiques à l’utilisation de plusieurs environnements isolés. Consultez l’article sur Azure Cloud Adoption Framework, la documentation sur Azure Security point de référence et le guide des opérations Microsoft Entra pour obtenir une aide détaillée sur l’utilisation d’environnements individuels.
Rôles et responsabilités inter-environnements
Architecture SecOps à l’échelle de l’entreprise : les membres des équipes d’exploitation et de sécurité de tous les environnements de l’organisation doivent définir conjointement les éléments suivants :
Principes pour définir quand des environnements doivent être créés, regroupés ou dépréciés
Principes pour définir la hiérarchie des groupes d’administration sur chaque environnement
Posture de sécurité, posture opérationnelle et approche de délégation du plan de facturation (EA Portal/MCA)
Processus de création de locataire
Taxonomie des applications d’entreprise
Processus de provisionnement des abonnements Azure
Limites d’autonomie et évaluation des risques vis-à-vis de l’isolation et de l’administration entre les équipes et les environnements
Configuration et contrôles de sécurité (techniques et compensatoires) de référence courants et références opérationnelles à utiliser dans tous les environnements
Procédures et outils opérationnels standard courants couvrant plusieurs environnements (de surveillance et de provisionnement, par exemple)
Délégation de rôles convenue dans plusieurs environnements
Séparation des tâches entre les environnements
Gestion courante de la chaîne logistique pour les stations de travail privilégiées
Conventions d'attribution de noms.
Mécanismes de corrélation inter-environnement
Création de locataire : une équipe spécifique doit être en charge de la création du locataire, suivant les procédures standardisées définies par l’architecture SecOps à l’échelle de l’entreprise. notamment :
Provisionnement des licences sous-jacentes (par exemple, Microsoft 365)
Intégration au plan de facturation d’entreprise (par exemple, Azure EA ou MCA)
Création de la hiérarchie de groupes d’administration Azure
Configuration des stratégies de gestion pour différents périmètres, notamment l’identité, la protection des données, Azure, et ainsi de suite.
Déploiement de la pile de sécurité selon l’architecture de cybersécurité convenue, ce qui inclut les paramètres de diagnostic, l’intégration SIEM, l’intégration CASB, l’intégration PIM, et ainsi de suite.
Configuration des rôles Microsoft Entra en fonction de la délégation convenue.
Configuration et distribution des stations de travail privilégiées initiales
Provisionnement des comptes d’accès d’urgence
Configuration de la pile de provisionnement des identités
Architecture des outils inter-environnements : il peut être nécessaire que certains outils (tels que les pipelines de provisionnement des identités et de contrôle de code source) fonctionnent dans plusieurs environnements. Ces outils doivent être considérés comme essentiels à l’infrastructure et doivent être structurés, conçus, implémentés et gérés comme tels. Ainsi, les architectes de tous les environnements doivent être impliqués chaque fois que des outils inter-environnements doivent être définis.
Inventaire et visibilité
Découverte d’abonnements Azure : pour chaque locataire découvert, un administrateur général Microsoft Entra peut élever l’accès afin d’obtenir une visibilité sur tous les abonnements de l’environnement. Cette élévation lui attribuera le rôle intégré Administrateur de l’accès utilisateur au niveau du groupe d’administration racine.
Remarque
Cette action confère des privilèges élevés et peut permettre à l’administrateur d’accéder à des abonnements contenant des informations extrêmement sensibles si ces données n’ont pas été correctement isolées.
Activation de l’accès en lecture pour découvrir les ressources : les groupes d’administration activent l’attribution RBAC à grande échelle sur plusieurs abonnements. Les clients peuvent accorder un rôle Lecteur à une équipe informatique centralisée en configurant une attribution de rôle dans le groupe d’administration racine, qui se propage à tous les abonnements de l’environnement.
Découverte des ressources : après l’obtention d’un accès en lecture aux ressources dans l’environnement, Azure Resource Graph peut être utilisé pour interroger les ressources dans l’environnement.
Enregistrement et surveillance
Gestion centralisée des journaux de sécurité : ingérez les journaux de chaque environnement de manière centralisée en suivant systématiquement les meilleures pratiques pour tous les environnements (par exemple, concernant les paramètres de diagnostic, la conservation des journaux, l’ingestion SIEM, et ainsi de suite). Azure Monitor peut être utilisé pour l’ingestion de journaux à partir de différentes sources : appareils de point de terminaison, réseau, journaux de sécurité des systèmes d’exploitation, et ainsi de suite.
Consultez le guide des opérations de sécurité Microsoft Entra pour obtenir des informations détaillées sur l’utilisation de processus et d’outils automatisés ou manuels pour surveiller les journaux dans le cadre de vos opérations de sécurité.
Certains environnements peuvent avoir des exigences réglementaires qui limitent les données (le cas échéant) qui peuvent quitter un environnement donné. Si la surveillance centralisée des différents environnements n’est pas possible, les équipes doivent disposer de procédures opérationnelles pour mettre en corrélation les activités des identités dans les différents environnements (par exemple, les tentatives de mouvement latéral inter-environnement) à des fins d’audit et de forensique. Il est recommandé que les identités humaines des identificateurs uniques d’objet appartenant à la même personne puissent être découvertes, potentiellement dans le cadre des systèmes de provisionnement des identités.
La stratégie de journalisation doit inclure les journaux Microsoft Entra suivants pour chaque locataire utilisé dans l’organisation :
Activité de connexion
Journaux d’audit
Événements à risque
Microsoft Entra ID fournit une intégration Azure Monitor pour le journal des activités de connexion et les journaux d'audit. Les événements à risque peuvent être ingérés via l'API Microsoft Graph.
Le diagramme suivant montre les différentes sources de données qui doivent être incorporées dans le cadre de la stratégie de surveillance :
Les locataires Azure AD B2C peuvent être intégrés à Azure Monitor. Nous recommandons que la surveillance d’Azure AD B2C utilise les mêmes critères que ceux décrits plus haut pour Microsoft Entra ID.
Les abonnements qui ont activé la gestion interlocataire avec Azure Lighthouse peuvent activer la surveillance interlocataire si les journaux sont collectés par Azure Monitor. Les espaces de travail Log Analytics correspondants peuvent résider dans le locataire de ressource et peuvent être analysés de manière centralisée dans le locataire de gestion à l’aide de workbooks Azure Monitor. Pour en savoir plus, consultez Superviser les ressources déléguées à grande échelle - Azure Lighthouse.
Journaux de sécurité du système d’exploitation de l’infrastructure hybride
Tous les journaux du système d’exploitation de l’infrastructure d’identité hybride doivent être archivés et soigneusement surveillés comme système de niveau 0, en raison des implications en termes de surface d’exposition. notamment :
Serveurs AD FS et Proxy d’application web
Microsoft Entra Connect
Agents de proxy d'application
Agents d'écriture différée de mot de passe
Ordinateurs avec passerelle de protection par mot de passe
NPS avec l’extension RADIUS de l’authentification multifacteur Microsoft Entra
Microsoft Entra Connect Health doit être déployé pour la surveillance de la synchronisation et de la fédération des identités (le cas échéant) pour tous les environnements.
Conservation du stockage de journaux : pour tous les environnements, la conservation du stockage de journaux doit faire l’objet d’une stratégie, d’une conception et d’une implémentation homogènes, permettant la mise en œuvre d’un ensemble d’outils cohérent (par exemple, des systèmes SIEM tels qu’Azure Sentinel), de requêtes courantes, d’investigations et des playbooks de forensique. Azure Policy peut être utilisé pour configurer les paramètres de diagnostic.
Surveillance et examen des journaux : les tâches opérationnelles relatives à la surveillance des identités doivent être cohérentes et avoir des propriétaires dans chaque environnement. Comme décrit plus haut, efforcez-vous de regrouper ces responsabilités entre environnements dans la mesure permise par les exigences de conformité réglementaire et d’isolation.
Les scénarios suivants impliquent une surveillance et une investigation explicites :
Activité suspecte : tous les événements Microsoft Entra à risque doivent être surveillés pour détecter toute activité suspecte. Tous les locataires doivent définir les emplacements nommés du réseau pour éviter les détections bruyantes sur les signaux basés sur l’emplacement. Microsoft Entra ID Protection est intégré en mode natif à Azure Security Center. Il est recommandé que toute investigation de détection de risque inclue tous les environnements dans lesquels l’identité est provisionnée (par exemple, si une identité humaine fait l’objet d’une détection de risque active dans le locataire d’entreprise, l’équipe qui exploite le locataire côté client doit également investiguer l’activité du compte correspondant dans cet environnement).
Alertes liées à l’analyse comportementale des utilisateurs et des entités (UEBA, user entity behavioral analytics) : utilisez l’UEBA pour obtenir des informations pertinentes basées sur la détection des anomalies. Microsoft 365 Defender for Cloud Apps fournit l’UEBA dans le cloud. Les clients peuvent intégrer l’UEBA locale à partir de Microsoft 365 Defender pour Identity. MCAS lit les signaux de Microsoft Entra ID Protection.
Activité des comptes d’accès d’urgence : tout accès par le biais de comptes d’accès d’urgence doit être surveillé et des alertes doivent être créées à des fins d’investigation. Cette surveillance doit englober ce qui suit :
Connexions
Gestion des informations d’identification
Toutes les mises à jour relatives aux appartenances à des groupes
Attributions d’applications
Comptes de gestion de la facturation : compte tenu de la sensibilité des comptes avec des rôles de gestion de la facturation dans Azure EA ou MCA et de leurs privilèges significatifs, il est recommandé de surveiller et de signaler les activités suivantes :
Tentatives de connexion de comptes avec des rôles de facturation
Toute tentative d’authentification auprès d’applications autres qu’EA Portal
Toute tentative d’authentification auprès d’applications autres que des applications de gestion des ressources Azure si vous utilisez des comptes dédiés pour les tâches de facturation MCA
Attribution à des ressources Azure à l’aide de comptes dédiés pour les tâches de facturation MCA
Activité des rôles privilégiés : configurez et examinez les alertes de sécurité générées par Microsoft Entra PIM. Si le verrouillage des attributions RBAC directes n’est pas entièrement applicable avec des contrôles techniques (par exemple, le rôle Propriétaire doit être accordé aux équipes produit dans le cadre de leur travail), surveillez l’attribution directe de rôles privilégiés en dehors de PIM en générant des alertes chaque fois qu’un utilisateur se voit attribuer directement l’accès à l’abonnement avec le contrôle d’accès RBAC Azure.
Attributions de rôles classiques : les organisations doivent utiliser l’infrastructure de rôle RBAC Azure moderne au lieu des rôles classiques. Ainsi, les événements suivants devraient être surveillés :
- Attribution à des rôles classiques au niveau de l’abonnement
Configurations à l’échelle du locataire : tout service de configuration à l’échelle du locataire doit générer des alertes dans le système.
Mise à jour des domaines personnalisés
Mise à jour de la personnalisation
Liste d’autorisation/de blocs Microsoft Entra B2B
Fournisseurs d'identité Microsoft Entra B2B autorisés (fournisseurs d'identité SAML par fédération directe ou connexion aux réseaux sociaux)
Modifications apportées aux stratégies d’accès conditionnel
Objets application et principal du service
Nouvelles applications/nouveaux principaux de service susceptibles de nécessiter des stratégies d’accès conditionnel
Activité de consentement d’application
Activité de groupe d’administration : les aspects suivants des groupes d’administration, relatifs aux identités, doivent être surveillés :
Attributions de rôles RBAC au niveau du groupe d’administration
Stratégies Azure appliquées au niveau du groupe d’administration
Abonnements déplacés entre groupes d’administration
Toutes les modifications apportées aux stratégies de sécurité au niveau du groupe d’administration racine
Rôles personnalisés
Mises à jour des définitions des rôles personnalisés
Rôles personnalisés créés
Règles personnalisées de séparation des tâches : si vos organisations ont établi des règles de séparation des tâches, utilisez les packages d’accès incompatibles Gestion des droits d’utilisation Microsoft Entra pour appliquer la séparation des tâches, puis créer des alertes ou configurer des révisions périodiques pour détecter les violations par les administrateurs.
Autres considérations relatives à la surveillance : les abonnements Azure qui contiennent des ressources utilisées pour la gestion des journaux doivent être considérés comme infrastructure critique (niveau 0) et verrouillés pour l’équipe des opérations de sécurité de l’environnement correspondant. Envisagez d’utiliser des outils tels qu’Azure Policy pour appliquer des contrôles supplémentaires à ces abonnements.
Outils opérationnels
Considérations relatives à la conception d’outils inter-environnements :
Dans la mesure du possible, les outils opérationnels qui seront utilisés sur plusieurs locataires doivent être conçus pour s’exécuter comme applications multilocataires Microsoft Entra afin d’éviter le redéploiement de plusieurs instances sur chaque locataire et les inefficacités opérationnelles. L’implémentation doit inclure une logique d’autorisation pour garantir la préservation de l’isolation entre les utilisateurs et les données.
Ajoutez des alertes et des détections pour surveiller toute automatisation inter-environnement (par exemple, relative au provisionnement des identités) et des limites de seuil pour la prévention de défaillance. Par exemple, vous pouvez ajouter une alerte qui se déclenche quand le déprovisionnement de comptes d’utilisateur atteint un niveau spécifique, ce qui peut indiquer un bogue ou une erreur opérationnelle pouvant avoir un impact important.
Toute automatisation qui orchestre les tâches inter-environnements doit être exploitée comme système hautement privilégié. Ce système doit être hébergé dans l’environnement le plus sécurisé et effectuer des extractions de sources externes si des données provenant d’autres environnements sont requises. Une validation des données et des seuils doivent être appliqués pour maintenir l’intégrité du système. La gestion du cycle de vie des identités, visant à supprimer les identités de tous les environnements pour un employé congédié, représente une tâche inter-environnement courante.
Outils de gestion des services informatiques : les organisations qui utilisent des systèmes de gestion des services informatiques (ITSM, IT Service Management) tels que ServiceNow doivent configurer les paramètres d’activation de rôle Microsoft Entra PIM pour demander un numéro de ticket dans le cadre des objectifs d’activation.
De même, Azure Monitor peut être intégré aux systèmes ITSM par le biais du connecteur de gestion des services informatiques.
Pratiques opérationnelles : limitez les activités opérationnelles qui nécessitent un accès direct à l’environnement aux identités humaines. Modélisez-les plutôt comme pipelines Azure exécutant des opérations courantes (par exemple, ajouter de la capacité à une solution PaaS, exécuter des diagnostics, et ainsi de suite) et modélisez un accès direct aux interfaces Azure Resource Manager pour les scénarios d’urgence.
Défis liés aux opérations
L’activité de surveillance du principal de service est limitée pour certains scénarios.
Les alertes Microsoft Entra PIM n’ont pas d’API. Une révision régulière de ces alertes PIM peut atténuer le problème.
Azure EA Portal n’offre pas de capacités de surveillance. Pour atténuer ce problème, vous devez disposer de comptes d’administration dédiés et surveiller l’activité des comptes.
MCA ne fournit pas de journaux d’audit pour les tâches de facturation. Pour atténuer ce problème, vous devez disposer de comptes d’administration dédiés et surveiller l’activité des comptes.
Certains services dans Azure, nécessaires pour exploiter l’environnement, doivent être redéployés et reconfigurés dans les différents environnements, car ils ne peuvent pas être multilocataires ou multiclouds.
Il n’existe aucune couverture d’API complète à l’échelle de Microsoft Online Services pour mettre en œuvre entièrement une infrastructure en tant que code. Pour contourner ce problème, utilisez des API autant que possible et utilisez des portails pour le reste. Cette initiative open source vous permet de déterminer une approche susceptible de fonctionner pour votre environnement.
Aucune fonctionnalité ne permet de découvrir, par programmation, les locataires de ressource qui ont accès aux identités dans un locataire de gestion avec un abonnement délégué. Par exemple, si une adresse e-mail a activé un groupe de sécurité dans le locataire contoso.com pour gérer les abonnements dans le locataire fabrikam.com, les administrateurs de contoso.com n’ont pas d’API pour découvrir que cette délégation a eu lieu.
La surveillance d’activités de compte spécifiques (par exemple, le compte d’urgence ou le compte de gestion de la facturation) n’est pas fournie dès le départ. Pour atténuer ce problème, les clients doivent créer leurs propres règles d’alerte.
La surveillance de la configuration à l’échelle du locataire n’est pas fournie dès le départ. Pour atténuer ce problème, les clients doivent créer leurs propres règles d’alerte.
Étapes suivantes
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour