M365 / Identité
M365 : accès conditionnel, MFA et comptes sensibles sans angle mort
La MFA seule ne suffit pas si les comptes sensibles, les appareils non conformes, les accès prestataires et les exceptions ne sont pas gouvernés. L'accès conditionnel devient utile quand il traduit une décision de risque : qui accède à quoi, depuis quel contexte, avec quelle preuve et quelle exception temporaire.
Partir des comptes qui peuvent faire mal
Le bon point de départ n'est pas le nombre total d'utilisateurs, mais les comptes dont la compromission changerait la crise : administrateurs, direction, finance, RH, support, prestataires, comptes invités et comptes qui touchent plusieurs applications.
Pour chacun, il faut relier rôle métier, accès réels, appareil, méthode MFA, délégation et application critique. Cette cartographie courte suffit souvent à révéler les premières exceptions dangereuses.
- administrateurs
- direction
- finance
- prestataires
- invités
- applications critiques
Traiter l'exception comme un risque
Une exception peut être légitime : migration, appareil industriel, support éditeur, urgence métier. Le problème commence quand elle devient invisible. Chaque exclusion doit avoir un propriétaire, une justification, une durée, une mesure compensatoire et une revue.
Cette discipline transforme l'accès conditionnel en preuve de gouvernance. On ne dit plus seulement 'la MFA est activée', on sait expliquer pourquoi telle exception existe et quand elle disparaît.
- propriétaire
- justification
- date de fin
- compensation
- revue
Tester avant de généraliser
Les politiques M365 peuvent bloquer un usage critique si elles sont appliquées sans test. Le mode report-only et les groupes pilotes sont utiles, mais seulement s'ils débouchent sur une décision : corriger, appliquer, exclure temporairement ou abandonner.
Le test doit couvrir les profils sensibles et les scénarios réels : accès depuis mobile, accès prestataire, application legacy, administrateur, appareil non conforme et réseau inhabituel.
Rendre la preuve lisible
En audit ou après incident, la capture d'une politique ne suffit pas toujours. La preuve utile montre l'intention, le périmètre, le résultat de test, les exceptions et les journaux qui confirment l'application.
Un registre minimal des politiques et exceptions rend la posture M365 défendable sans produire une documentation lourde.
- intention
- périmètre
- test
- exception
- journal
Terrain
Décisions, signaux et preuves à ne pas perdre
Décision
À décider
- Quels comptes doivent être protégés avant tous les autres ?
- Quelle exception est réellement nécessaire et jusqu'à quelle date ?
- Une politique bloque-t-elle un métier critique ou révèle-t-elle un usage non maîtrisé ?
- Qui valide l'accès d'un prestataire à un service M365 sensible ?
- Quel niveau de preuve sera acceptable en audit ou après incident ?
Technique
À vérifier techniquement
- Comptes exclus des politiques MFA ou accès conditionnel sans justification récente
- Connexion à application critique depuis appareil non conforme ou localisation inhabituelle
- Politiques en mode report-only jamais basculées ou jamais revues
- Groupes dynamiques, rôles Entra ID ou comptes invités sans propriétaire clair
- Méthodes MFA faibles, réenregistrement MFA récent ou ajout d'application OAuth sensible
Preuves
Preuves à conserver
- Export des politiques Conditional Access avec état, cible, exclusions et contrôles imposés
- Liste des comptes privilégiés, dirigeants, prestataires et comptes invités à risque
- Journal des exceptions : demandeur, justification, date de fin, compensations et validation
- Sign-in logs sur comptes sensibles et traces des tests de politiques
- Captures ou exports montrant les politiques en production et les alertes associées
Pièges
Erreurs fréquentes
- Activer la MFA globalement puis laisser des exclusions permanentes non revues.
- Tester les politiques uniquement sur les utilisateurs standards et oublier les administrateurs.
- Ne pas relier accès conditionnel, appareils, applications OAuth et journaux de connexion.
- Confondre report-only avec une mesure réellement protectrice.
Questions fréquentes
Faut-il bloquer toutes les connexions hors France ?
Pas automatiquement. Le blocage géographique peut être utile, mais il doit être relié aux usages réels, aux prestataires, aux voyages et aux risques de contournement.
Une politique en report-only protège-t-elle réellement ?
Non. Elle sert à observer l'impact avant application. Elle devient utile si une décision de bascule ou de correction est planifiée.
Sources publiques
Références utilisées sans copie de contenu
Les liens ci-dessous servent de repères publics. Le contenu de cette page est reformulé, contextualisé et adapté à l'approche terrain d'Adrien Murillo.