Un tenant Microsoft 365 n'arrive pas mal configuré : il arrive configuré pour que tout fonctionne tout de suite. Ce n'est pas la même chose, et c'est un choix défendable de la part de Microsoft. Le problème est que les réglages d'ouverture initiale ne sont presque jamais refermés une fois la migration terminée.
Nous scannons plus de 300 points de contrôle sur un tenant. Six reviennent avec une régularité qui n'a plus rien d'anecdotique.
1. Les comptes à privilèges sans authentification forte
Le classique absolu. Pas parce que la MFA n'est pas déployée — elle l'est presque toujours pour les utilisateurs — mais parce que les comptes d'administration ont été exclus pendant la migration, « le temps de finir », et que l'exclusion est restée.
S'y ajoutent les comptes de service, les comptes de secours (breakglass) créés puis oubliés, et les administrateurs de prestataires externes.
Ce que nous regardons : le nombre de rôles à privilèges effectivement attribués, la couverture réelle de l'authentification forte sur ces comptes, et l'existence d'un accès de secours documenté et surveillé — parce que verrouiller un tenant en fermant mal cette porte est un incident en soi.
2. L'authentification héritée encore acceptée
Les protocoles anciens — IMAP, POP, SMTP AUTH de base, les vieux clients Exchange — ne savent pas présenter un second facteur. Tant qu'ils sont acceptés, la MFA se contourne : il suffit à l'attaquant de se connecter par un chemin qui ne la demande pas.
Microsoft a fermé beaucoup de ces portes par défaut sur les nouveaux tenants. Les tenants créés il y a cinq ans, eux, ont conservé leurs autorisations, et les exceptions ajoutées pour une imprimante multifonction ou un ERP n'ont jamais été revues.
3. Le partage externe sans expiration
SharePoint et OneDrive permettent de créer des liens « toute personne disposant du lien ». Par défaut, dans beaucoup de configurations, ces liens n'expirent jamais.
Un lien créé pour un appel d'offres en 2022 fonctionne encore aujourd'hui, il est peut-être dans un fil de discussion transféré trois fois, et le fichier qu'il expose a peut-être été mis à jour depuis.
Le correctif ne coûte presque rien : une durée de vie maximale sur les liens anonymes, et une revue des partages existants. Il ne casse aucun usage légitime — il oblige simplement à recréer un lien quand on en a besoin plus tard.
4. La création d'applications par les utilisateurs
Par défaut, un utilisateur standard peut consentir à ce qu'une application tierce accède à ses données, et souvent enregistrer lui-même une application dans l'annuaire.
C'est le vecteur du consent phishing : l'utilisateur ne donne pas son mot de passe, il autorise une application à lire son courrier. La MFA ne l'arrête pas, le changement de mot de passe non plus, et l'autorisation survit à tout — jusqu'à ce que quelqu'un la révoque.
Ce que nous regardons : le nombre d'applications ayant obtenu des permissions étendues sur la messagerie ou les fichiers, la date de leur autorisation, et la présence d'un circuit de validation.
5. Les règles de transport oubliées
Les règles de flux de messagerie s'accumulent : une exception pour un partenaire, un contournement du filtrage pour un test, une redirection mise en place pendant une absence.
Deux catégories nous inquiètent systématiquement :
- les exclusions de filtrage par expéditeur ou par domaine, qui créent un chemin de confiance qu'un attaquant peut emprunter en usurpant précisément ce domaine ;
- les redirections automatiques vers l'extérieur, qui sont l'un des marqueurs les plus fiables d'une compromission de boîte aux lettres.
6. La journalisation incomplète
Ce n'est pas une faille : c'est ce qui vous empêchera de répondre le jour où il faudra. Sans journal d'audit unifié activé et sans rétention suffisante, une question aussi simple que « depuis quand cette règle de redirection existe-t-elle ? » devient sans réponse.
Or c'est exactement la question qu'un assureur, un client qui vous audite, ou une autorité vous poseront. La journalisation est le seul de ces six points qui ne protège de rien sur le moment, et sans lequel les cinq autres ne se démontrent pas.
Ce que ça coûte de refermer
L'essentiel de cette liste se traite en quelques jours, et une bonne partie sans interruption pour les utilisateurs. Ce qui prend du temps n'est pas la modification : c'est la vérification qu'aucun usage légitime n'en dépend. Couper l'authentification héritée sans avoir inventorié les applications qui l'utilisent, c'est arrêter une chaîne de production.
C'est d'ailleurs la raison pour laquelle nous appliquons la remédiation par lots, en vérifiant à chaque étape, plutôt qu'en une bascule unique.