Guide pratique · Identité et accès
Authentification multifacteur et accès conditionnel : la base non négociable
Le MFA activé sur papier et le MFA réellement appliqué à chaque compte ne protègent pas de la même façon. Ce guide détaille les contrôles précis qu’une cadence mensuelle devrait vérifier, au-delà de la question générale de qui possède un accès.
La décision à prendre
Ce guide aide une équipe à vérifier si ses contrôles d’authentification et d’accès conditionnel sont réellement appliqués, ou seulement activés quelque part dans une console d’administration.
Le MFA doit couvrir tout le monde, y compris les comptes administrateurs
Un projet MFA qui oublie les comptes de service, les administrateurs ou quelques comptes « temporaires » laisse justement la porte que les attaques ciblent en premier. La vérification récurrente compare la liste des comptes actifs à la liste des comptes réellement soumis à une exigence MFA, sans exception non documentée.
Les politiques d’accès conditionnel remplacent les règles uniformes par des règles selon le risque
Une politique de base peut exiger le MFA pour tous, puis ajouter des règles plus précises : bloquer une connexion jugée à risque élevé, exiger un appareil conforme pour atteindre certaines applications, ou refuser un jeton trop ancien. La revue mensuelle vérifie que ces politiques existent, sont actives, et concernent les bonnes applications.
- Politique de base appliquée à tous les utilisateurs
- Règles additionnelles pour les rôles sensibles
- Journal des exclusions et de leur justification
Les emplacements de confiance doivent rester exacts
Une politique qui fait confiance à « l’adresse IP du bureau » perd sa valeur si cette adresse a changé depuis un déménagement ou un changement de fournisseur Internet, ou si le Wi-Fi invité partage la même sortie que le réseau corporatif. La cadence mensuelle confirme que la liste des emplacements de confiance correspond encore à la réalité du bureau.
L’authentification héritée reste une porte dérobée oubliée
Les anciens protocoles de courrier (POP, IMAP, SMTP authentifié) ne savent souvent pas présenter une demande MFA, ce qui en fait une cible privilégiée si un mot de passe fuite ailleurs. Le blocage de l’authentification héritée devrait être confirmé activement, pas seulement supposé parce qu’une politique existe quelque part.
Le SSO pour les applications métier évite les mots de passe orphelins
Une application comptable, un portail fournisseur ou un outil sectoriel connecté par mot de passe séparé échappe complètement au MFA du locataire Microsoft 365. Relier ces applications à l’authentification unique du locataire, quand c’est possible, ramène cette porte d’entrée sous la même surveillance que le reste.
Une matrice simple pour attribuer le travail.
| Situation | Propriétaire | Moment | Trace utile |
|---|---|---|---|
| MFA sur tous les comptes actifs | Responsable M365 | Revue à chaque cycle | Liste des exceptions justifiées |
| Politiques d’accès conditionnel | Responsable M365 + direction | Revue convenue | Politiques actives et testées |
| Authentification héritée | Responsable M365 | Vérification continue | Blocage confirmé |
Checklist de décision
Ce qui devrait être vrai avant de considérer le sujet sous contrôle.
- Le MFA s’applique à tous les comptes, y compris les administrateurs
- Les politiques d’accès conditionnel reflètent les rôles sensibles
- La liste des emplacements de confiance est à jour
- L’authentification héritée est bloquée et vérifiée
- Les applications métier critiques passent par l’authentification unique du locataire
Prochaine étape
Reliez ces contrôles à la revue plus large des accès.
L’hygiène des accès couvre les comptes, invités et rôles au sens large; ce guide en précise la couche identité. Utilisez ensuite l’évaluation pour voir si ces contrôles ont un propriétaire clair chez vous.