Sécuriser Entra ID : configuration avancée et pratiques

Sécurisation des Applications et Permissions dans Entra ID

L'une des surfaces d'attaque les plus critiques et les moins bien protégées dans les environnements Entra ID concerne les applications enregistrées et leurs permissions. Chaque application enregistrée dans Entra ID (anciennement Azure Active Directory) peut se voir accorder des permissions Microsoft Graph qui lui permettent d'agir sur les ressources de l'annuaire avec des droits potentiellement très étendus. La compromission d'une application avec des permissions Graph excessives peut donner à un attaquant un accès persistant à l'ensemble de l'annuaire sans nécessiter de credentials utilisateur, rendant ce vecteur particulièrement insidieux.

Les permissions Microsoft Graph les plus dangereuses à auditer prioritairement dans Entra ID :

• Directory.ReadWrite.All : permission d'application permettant de lire et modifier tous les objets de l'annuaire, y compris la création d'utilisateurs, la modification des membres des groupes et l'ajout de credentials aux applications existantes
• RoleManagement.ReadWrite.Directory : permet d'attribuer et de retirer des rôles Azure AD à n'importe quel principal, équivalent d'un Global Administrator sans apparaître dans la liste des administrateurs
• Mail.ReadWrite et Mail.Send pour toutes les boîtes mail : permet à l'application de lire et d'envoyer des emails depuis n'importe quelle boîte mail de l'organisation sans interaction utilisateur, vecteur d'espionnage et d'usurpation d'identité massif
• User.ReadWrite.All : modification de tous les attributs utilisateur y compris les méthodes d'authentification MFA, permettant de désactiver le MFA pour des comptes cibles avant une tentative d'accès

L'audit des permissions applicatives Entra ID s'effectue via PowerShell avec le module Microsoft.Graph :

Connect-MgGraph -Scopes "Application.Read.All", "Directory.Read.All"
Get-MgServicePrincipal -All | ForEach-Object {
  $sp = $_
  Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id |
  Where-Object {$_.PrincipalType -eq "ServicePrincipal"} |
  Select-Object @{n="App";e={$sp.DisplayName}}, PrincipalDisplayName, @{n="Permission";e={$_.AppRoleId}}
}

Gouvernance des Identités Entra ID : Cycle de Vie et Access Reviews

La gouvernance des identités dans Entra ID couvre l'ensemble du cycle de vie des comptes utilisateurs, de leur création automatisée lors de l'onboarding jusqu'à leur désactivation et suppression lors de l'offboarding. Entra ID Governance (anciennement Azure AD Identity Governance) fournit des fonctionnalités natives de gestion du cycle de vie des identités, d'Access Reviews automatisées et de gestion des accès à droit élevé (Privileged Identity Management).

Les Access Reviews Entra ID permettent d'automatiser les campagnes de recertification des accès : les propriétaires de groupes ou d'applications reçoivent périodiquement des demandes de validation des membres de leurs ressources, avec révocation automatique des accès non validés dans le délai imparti. Cette fonctionnalité est directement requise par les référentiels ISO 27001 (A.9.2.6 Removal of Access Rights) et SOC 2 (CC6.3 Access Revocation).

• Privileged Identity Management (PIM) : les rôles administrateurs (Global Admin, Exchange Admin, etc.) sont attribués en mode eligible plutôt que permanent ; l'activation nécessite une demande justifiée, une approbation par un manager et une durée limitée configurée (8 heures maximum recommandé)
• Conditional Access avec conditions de risque : les politiques d'Accès Conditionnel qui intègrent le score de risque utilisateur et de risque de connexion calculés par Entra ID Protection bloquent automatiquement les connexions depuis des localisations ou comportements atypiques sans intervention humaine
• Entitlement Management : les Access Packages permettent de regrouper les ressources nécessaires à un rôle métier (groupes, applications, sites SharePoint) et de les attribuer via un processus d'approbation avec durée de validité configurable et révision périodique automatique
• Cross-tenant synchronization : dans les environnements multi-tenant, la synchronisation des identités entre tenants doit être auditée pour prévenir les accès non autorisés par des identités d'un tenant partenaire mal gouvernées

La surveillance continue de la sécurité Entra ID s'effectue via Microsoft Defender for Identity (anciennement Azure ATP) qui analyse les comportements d'authentification et détecte les attaques comme le Pass-the-Hash, le Golden Ticket Kerberos et les énumérations d'annuaire. Les alertes Defender for Identity sont centralisées dans Microsoft Sentinel pour corrélation avec d'autres sources de télémétrie et traitement par les analystes SOC dans un workflow unifié de gestion des incidents de sécurité lié aux identités cloud.

Politiques d'Accès Conditionnel Entra ID : Conception et Bonnes Pratiques

Les politiques d'Accès Conditionnel Entra ID constituent le mécanisme central de contrôle d'accès contextuel dans l'écosystème Microsoft 365 et Azure. Elles permettent d'appliquer des décisions d'accès dynamiques basées sur des conditions multiples : identité de l'utilisateur, appartenance à des groupes, niveau de risque calculé par Entra ID Protection, conformité du dispositif (Compliant ou Joined dans Intune), localisation réseau (IP de confiance ou non), application cible et sensibilité des données accédées. La conception d'une architecture de Conditional Access robuste nécessite une approche structurée qui évite les erreurs de configuration pouvant bloquer les accès légitimes ou laisser des vecteurs d'attaque non couverts.

Les politiques d'Accès Conditionnel prioritaires à déployer dans tout tenant Entra ID d'entreprise :

• MFA pour tous les utilisateurs non-administrateurs : politique de base exigeant l'authentification multi-facteurs pour tout accès depuis des réseaux non identifiés comme de confiance, avec des exclusions pour les comptes de service et les applications utilisant des flux d'authentification modernes sans interaction utilisateur
• MFA renforcé pour les administrateurs : politique distincte exigeant une méthode MFA forte (clé FIDO2 ou Microsoft Authenticator avec Passwordless) pour tous les comptes avec des rôles d'administration Entra ID, quelle que soit la localisation réseau
• Blocage des accès depuis des pays non autorisés : liste blanche des pays depuis lesquels les connexions sont autorisées, avec exceptions documentées pour les voyageurs fréquents via des Named Locations dynamiques
• Exigence de conformité du dispositif : accès aux ressources sensibles (SharePoint, Exchange, applications métier critiques) conditionné à la conformité Intune du dispositif, bloquant les accès depuis des appareils personnels non gérés
• Blocage des protocoles d'authentification legacy : les protocoles POP, IMAP, SMTP AUTH, Basic Auth ne supportent pas le MFA modernes et doivent être bloqués globalement, avec des exceptions uniquement pour les systèmes legacy documentés et approuvés

Le mode Report-Only des politiques Conditional Access permet de simuler l'impact d'une nouvelle politique avant son activation en production, affichant les résultats qu'elle aurait produits sans bloquer réellement les accès. Cette fonctionnalité est essentielle pour valider qu'une nouvelle politique ne crée pas de rupture d'accès non anticipée pour des utilisateurs légitimes, notamment les comptes de service et les applications utilisant des flux OAuth2 avec des patterns d'authentification spécifiques. Un run de 7 à 14 jours en mode Report-Only avant activation est la bonne pratique recommandée pour les politiques affectant l'ensemble des utilisateurs.

Monitoring de Sécurité Entra ID et Réponse aux Incidents d'Identité

La surveillance continue de la sécurité Entra ID s'appuie sur les journaux d'audit et de connexion disponibles dans le portail Azure, exportables vers un espace de travail Log Analytics ou directement vers Microsoft Sentinel pour les organisations ayant déployé ce SIEM. Les journaux de connexion Entra ID contiennent des informations précieuses pour la détection des comportements anormaux : adresse IP source, localisation géographique, dispositif utilisé, résultat de l'authentification (succès, échec MFA, risque bloqué) et politique Conditional Access appliquée.

Les requêtes KQL essentielles pour la surveillance Entra ID dans Microsoft Sentinel ou Log Analytics permettent de détecter les patterns d'attaque les plus courants : tentatives de password spray (nombreux échecs d'authentification depuis une même IP sur de nombreux comptes différents), impossible travel (connexions depuis deux pays distants dans un délai impossible à parcourir physiquement), connexions réussies immédiatement suivies d'une modification des méthodes MFA indiquant un attaquant consolidant son accès, et création de nouvelles applications Entra ID avec des permissions étendues par des utilisateurs non autorisés à effectuer ces opérations selon les politiques de gouvernance. La réponse automatisée aux incidents d'identité via des playbooks Microsoft Sentinel (basés sur Azure Logic Apps) permet de révoquer automatiquement les sessions actives, désactiver un compte compromis et notifier le SOC dans les secondes suivant la détection d'un comportement critique.

La sécurisation d'Entra ID est un processus continu qui évolue avec les nouvelles fonctionnalités de la plateforme Microsoft, les nouvelles techniques d'attaque découvertes par les chercheurs en sécurité et les nouvelles exigences de conformité imposées par les régulateurs. La souscription aux bulletins de sécurité Microsoft, la participation aux programmes de preview des nouvelles fonctionnalités de sécurité Entra ID et la formation continue des administrateurs cloud constituent des investissements indispensables pour maintenir une posture de sécurité des identités robuste et adaptée aux menaces actuelles et émergentes dans l'écosystème Microsoft 365.