Dans une identité hybride, l’annuaire local et les services cloud se partagent plusieurs responsabilités. Une faiblesse peut donc se trouver entre deux équipes : synchronisation, compte d’administration, application ou mécanisme de secours. Ces dix contrôles constituent une trame de revue. Ils ne sont pas un classement des attaques les plus fréquentes ni un résultat d’audit client.
En résumé
- La synchronisation des identités et l’authentification sont des fonctions distinctes à cartographier.
- Le serveur de synchronisation doit être traité comme un composant sensible, selon les permissions effectivement accordées.
- Les nouvelles règles d’accès conditionnel se préparent sur un périmètre pilote et avec des comptes de secours.
- Un appareil joint à Entra ID n’est pas automatiquement un appareil conforme.
- Les applications et les identités non humaines doivent avoir un propriétaire, des droits limités et une procédure de révocation.
1. Cartographier le parcours d’identité
Commencez par les forêts AD, les tenants, les domaines, les mécanismes de synchronisation et les dépendances réseau. Distinguez la synchronisation de hachages de mots de passe, l’authentification directe et la fédération. Une compromission n’a pas les mêmes conséquences selon le chemin utilisé et les permissions détenues. Écrire « Entra Connect compromis = administrateur global » serait une généralisation trompeuse.
- Active DirectoryComptes, groupes et délégations
- SynchronisationConnecteurs, filtrage et permissions
- Microsoft Entra IDRôles, authentification et politiques
- ApplicationsConsentements et ressources accessibles
- Supervision et secoursJournaux, alertes et accès indépendants
Prérequis : un périmètre autorisé, des rôles de lecture adaptés, les licences et versions inventoriées, un environnement pilote et un contact capable de restaurer l’accès. Ne commencez pas par modifier une politique qui concerne tous les utilisateurs.
2. Examiner les dix contrôles
| Contrôle | Preuve à recueillir |
|---|---|
| 1. Comptes administrateurs distincts | Séparation des usages quotidiens et privilégiés |
| 2. Serveurs de synchronisation | Administrateurs, mises à jour, agents et flux limités |
| 3. Rôles et délégations | Attributions directes, groupes, éligibilités et justification |
| 4. Accès conditionnel | Périmètre, exclusions et résultats du pilote |
| 5. Comptes de secours | Accès indépendant testé et activité surveillée |
| 6. Authentifications héritées | Usages réellement observés et plan de migration |
| 7. Applications et consentements | Propriétaire, permissions déléguées ou applicatives |
| 8. Appareils | Distinction entre inscription, jonction et conformité |
| 9. Seamless SSO si utilisé | Procédure et historique de rotation de clé |
| 10. Journaux et reprise | Historique disponible, alertes testées et procédure de récupération |
Chaque ligne doit avoir un propriétaire et une conclusion : conforme au besoin, écart à traiter ou information manquante. Une information manquante n’est pas une preuve d’absence de risque. Les fonctions disponibles et leur coût dépendent des licences ; notez ce qui est effectivement activé.
3. Déployer les politiques sans se verrouiller dehors
Microsoft fournit un mode report-only pour examiner l’effet de nombreuses politiques d’accès conditionnel avant application. Il aide à identifier des impacts, mais ne remplace pas un test réel des parcours concernés. Commencez par des comptes pilotes et vérifiez les applications métier, l’administration et les terminaux représentatifs.
Préparez des comptes d’accès d’urgence selon les recommandations Microsoft, avec des dépendances différentes de celles des accès ordinaires, une authentification résistante à l’hameçonnage et une surveillance dédiée. Leur fonctionnement doit être vérifié périodiquement. Un compte de secours inconnu ou inutilisable ne protège pas d’un blocage.
Ne confondez pas protocole et mode d’authentification : certains usages POP ou IMAP peuvent employer OAuth. Identifiez le mode réellement utilisé avant de classer un flux comme authentification basique. De même, une machine jointe à Entra ID ne satisfait pas nécessairement vos critères de conformité.
4. Réduire les accès des applications
Un consentement peut donner à une application un accès durable à des ressources. Les permissions déléguées s’exercent dans un contexte utilisateur ; les permissions applicatives servent notamment aux traitements sans utilisateur. Aucune des deux catégories n’est automatiquement sûre ou dangereuse : la portée, les opérations et les contrôles comptent.
Examinez les propriétaires, les identifiants et certificats, les dernières utilisations et les permissions réellement nécessaires. Une application sans propriétaire ou inutilisée doit être qualifiée avant retrait. Pour un agent IA, ajoutez un contrôle des actions et des destinations : l’autorisation d’un connecteur ne justifie pas tous les usages possibles de ses données.
Le Primary Refresh Token, ou PRT, participe à l’authentification des appareils et utilisateurs. Sa protection dépend du contexte, notamment des mécanismes matériels et logiciels. Évitez de conclure qu’un accès local quelconque permet toujours son rejeu. Concentrez la revue sur les protections et signaux documentés de vos appareils.
5. Traiter Seamless SSO et la conservation des traces
Si Seamless SSO est utilisé, suivez la procédure Microsoft de rotation de sa clé Kerberos. La commande documentée est Update-AzureADSSOForest ; elle nécessite son contexte de module, de session et d’autorisations. Ce guide ne la propose pas comme une commande isolée à exécuter en production. Microsoft recommande une rotation au moins tous les 30 jours.
Pour les journaux, relevez les sources disponibles, les licences, les exports et la durée effective de conservation. Une durée de 365 jours n’est ni automatique ni une obligation universelle. Testez l’arrivée d’une connexion pilote et d’un changement d’administration dans l’outil d’analyse, puis contrôlez les permissions de lecture des traces.
6. Recette, limites et retour arrière
- Consigner versions, licences, modes d’authentification et périmètre du pilote.
- Tester les connexions autorisées et refusées avec plusieurs profils représentatifs.
- Vérifier les comptes d’urgence selon une procédure encadrée et tracer l’exercice.
- Révoquer un accès applicatif de test et vérifier l’effet réel, y compris les délais de session.
- Contrôler la collecte des événements et les périodes absentes.
- Restaurer les politiques et accès de test à partir de l’état initial documenté.
N’enregistrez pas de mots de passe ou de jetons dans le compte rendu. Une modification de politique n’annule pas forcément immédiatement tous les accès déjà ouverts ; la vérification doit couvrir le comportement réel des sessions et applications. Rejouez ces contrôles lors des évolutions de votre environnement.
Sources et références
Références consultées le 10 octobre 2026. Les schémas sont des représentations pédagogiques ; les exemples et recettes proposés doivent être adaptés au périmètre réel.
- Microsoft - Accès d’urgence Entra ID
- Microsoft - Accès conditionnel en report-only
- Microsoft - FAQ Seamless SSO et rotation de clé
Besoin de relier ces contrôles à votre environnement ? Parler de votre projet avec Kenawek.