Sécuriser correctement Microsoft 365 : Conditional Access, exceptions MFA et comptes break-glass au quotidien

Quiconque souhaite sécuriser correctement Microsoft 365 ne peut se passer de Conditional Access (politiques d’accès conditionnel dans Entra ID, anciennement Azure AD) et de l’authentification multifacteur (MFA, c.-à-d. une authentification avec au moins deux facteurs). Dans de nombreuses entreprises, la MFA et les premières règles Conditional Access sont activées rapidement — et c’est alors que le travail commence réellement : les exceptions doivent être justifiées, les accès d’urgence organisés proprement et les processus d’exploitation conçus de manière à ce que la sécurité ne devienne pas une avalanche de tickets de support.

Dans la pratique, la sécurisation de « M365 » échoue rarement à cause de la technique de base, mais à cause de problèmes du quotidien : comptes de service pour des interfaces, protocoles hérités, personnel sur le terrain sans réseau mobile fiable, administrateurs avec des droits trop étendus, ou un incident où précisément la mesure de protection empêche l’accès de l’équipe IT. Cet article remet en perspective la façon dont Conditional Access, les exceptions MFA et les comptes Break-Glass interagissent — et comment exploiter l’ensemble de manière à ce qu’il RESTe fiable après le go-live.

Pourquoi Conditional Access est le levier — et pourquoi la MFA seule ne suffit pas

La MFA réduit sensiblement le risque lié aux mots de passe volés, mais elle ne constitue pas un concept d’accès complet. Conditional Access (CA) décide de manière contextuelle sous quelles conditions un accès est autorisé : par exemple seulement depuis des appareils gérés, seulement depuis certains pays, seulement après une évaluation fondée sur le risque ou uniquement avec des applications clientes spécifiques. C’est l’étape décisive vers le modèle Zero Trust (modèle de sécurité dans lequel aucun accès n’est de confiance par défaut, mais est continuellement réévalué).

Raisons typiques pour lesquelles la MFA seule n’est pas suffisante dans Microsoft 365 :

• Jetons plutôt que mots de passe : L’authentification moderne fonctionne avec des jetons (tickets d’accès à durée limitée). Un jeton volé peut contourner la MFA si la CA n’exige pas de conditions additionnelles (par ex. l’état de l’appareil ou un contrôle de session).
• Risque lié aux administrateurs : Les comptes administratifs sont particulièrement prisés. Sans règles CA pour les accès administratifs (par ex. uniquement depuis des postes d’administration ou uniquement avec une MFA résistante au phishing), la surface d’attaque la plus importante demeure ouverte.
• « Autorisé » est trop large : Si la CA ne distingue pas entre applications, classes de données et types d’accès, la sécurité devient rapidement soit trop laxiste soit trop RESTrictive — les deux posent problème.

Le cœur opérationnel est donc : la CA comme couche de politiques, la MFA comme composant de cette couche, en plus d’une gestion rigoureuse des exceptions et de chemins d’urgence robustes.

Vue d’ensemble d’architecture : ce que Conditional Access contrôle réellement dans Entra ID

Pour la direction IT et l’exploitation, il est important de ne pas considérer la CA comme « une politique », mais comme une chaîne de décisions. Entra ID évalue des signaux à chaque authentification et applique des politiques. Les signaux importants sont :

• Identité : utilisateurs, groupes, rôles (par ex. rôles privilégiés comme Global Administrator).
• Ressource cible : application cloud (Exchange Online, SharePoint/OneDrive, Teams, mais aussi des solutions tierces via Enterprise App).
• Type de client : navigateur, clients modernes, applications mobiles, ainsi que « Legacy Authentication » (protocoles anciens sans jetons modernes, p. ex. variantes IMAP/POP/SMTP d’authentification plus anciennes).
• État de l’appareil : « Compliant » ou « hybrid joined » (appareil géré, typiquement via Intune ou jonction de domaine avec statut de l’appareil).
• Réseau/Emplacement : Named Locations (plages d’IP définies), pays/régions, indicateurs de risque.
• Conditions de session : Session Lifetime, App-Enforced RESTrictions, Continuous Access Evaluation (réévaluation continue en cas d’événements de risque).

Du point de vue de l’exploitation, la qualité de votre configuration CA dépend fortement de la fiabilité de ces signaux. Un Named Location n’est utile que si votre hygiène des adresses IP est bonne. «Compliant» n’a de valeur que si votre gestion des appareils et la définition de la conformité sont correctes. Et l’évaluation des risques n’est utile que si vous traitez effectivement les événements qui en résultent.

Sécuriser correctement Microsoft 365 avec l’accès conditionnel : un ensemble de politiques opérationnel

Plutôt qu’une «grande» règle globale, un ensemble de quelques politiques clairement délimitées fonctionne mieux au quotidien. Cela réduit les effets secondaires et facilite la recherche d’erreur en cas d’incident. Un schéma de base éprouvé se compose de :

1) Baseline pour tous les utilisateurs : imposer la MFA, bloquer l’authentification héritée

Pour les comptes utilisateurs normaux, la baseline est : MFA requise et blocage de l’authentification héritée. «Héritée» ici n’est pas “démodée”, mais techniquement problématique : ces protocoles ne supportent souvent pas une challenge MFA moderne et constituent donc un point d’entrée typique pour le password spraying.

Important : ne bloquez pas l’héritage «à un moment donné», mais planifiez une phase de transition avec mesure. Vérifiez via les journaux de connexion quels clients utilisent encore l’héritage. Dans les entreprises, on y retrouve souvent des imprimantes multifonctions, des workflows Scan-to-Mail ou des clients mail anciens dans des environnements spécialisés.

2) Politique admin : sensiblement plus stricte que la baseline

Les rôles privilégiés doivent avoir leur propre politique : accès uniquement depuis des postes administrateurs définis (p. ex. «conforme» et éventuellement une stratégie distincte de postes admin), MFA avec un niveau de sécurité élevé (résistant au phishing, p. ex. FIDO2/Passkey ou basé sur certificat), et si possible des restrictions pour les pays/lieux à risque. Même si toutes les entreprises n’adoptent pas immédiatement une architecture Privileged Access complète (PAM, c’est‑à‑dire gestion des accès privilégiés), cette différenciation vaut immédiatement la peine : un compte admin compromis constitue un périmètre de dommages différent d’un compte utilisateur compromis.

3) Politique pour la collaboration externe et les invités

Les accès invités (B2B Collaboration) génèrent souvent des chemins de données inattendus : les invités téléchargent des fichiers depuis SharePoint, travaillent dans Teams ou accèdent à des portails de projet. Définissez clairement si les invités doivent obligatoirement passer par la MFA, si certaines applications sont exclues et quelle est la durée de validité des sessions. Pour le travail de projet, une durée de session plus courte est souvent pertinente pour réduire le risque de «connexions oubliées».

4) Politique pour les flux de données sensibles : sécuriser l’appareil ou la session

Le quotidien impose différents besoins de protection : un commercial peut peut‑être lire ses e‑mails depuis n’importe quel appareil, mais ne devrait pas télécharger de gros ensembles de données depuis SharePoint sans appareil géré. Ces différences ne se modèlent pas par un simple «autoriser/interdire», mais par des combinaisons CA : «accès autorisé si l’appareil est conforme» ou «accès uniquement via navigateur avec session restreinte». C’est moins radical que de bloquer complètement — et néanmoins efficace.

Exceptions à la MFA : où elles sont réalistes — et comment les contrôler

Les exceptions MFA ne sont pas un signe de faiblesse, tant qu’elles sont conçues consciemment et contrôlées opérationnellement. Sans exceptions contrôlées, des solutions parallèles apparaissent : les utilisateurs contournent les processus, les admins désactivent des règles à la hâte, et la collection de politiques devient incompréhensible.

La distinction importante : une exception MFA signifie rarement «MFA désactivée», mais souvent «MFA autrement» ou «accès uniquement sous d’autres conditions». Catégories d’exceptions typiques :

Cas d’exception 1 : accès non‑interactifs et interfaces

De nombreuses solutions logicielles proches des processus intègrent des services M365 : envoi d’e-mails, accès aux calendriers, stockage de fichiers SharePoint, notifications Teams ou accès à l’API Graph. De telles intégrations ne devraient pas s’effectuer via des comptes utilisateur avec MFA désactivé. Il est préférable d’utiliser un accès technique via des enregistrements d’application (application dans Entra ID) avec des autorisations claires et un cycle de vie des secrets / certificats. Ce n’est pas une « exception MFA », mais un autre mode d’authentification, plus auditable.

Conséquences opérationnelles : les secrets doivent être renouvelés, les certificats expirent et les autorisations doivent être recertifiées. Si vous planifiez des intégrations, définissez la responsabilité (qui renouvelle certificats/secrets) et le monitoring (p. ex. alertes avant expiration). Sinon, une authentification applicative « sûre » peut se transformer en panne imprévue.

Ausnahmefall 2: Geräte ohne modernen Login (z. B. Scanner, Drucker, Raum-Systeme)

Ici se posent les discussions classiques autour de SMTP-Relay, Scan-to-Mail ou des boîtes aux lettres de salle. La mauvaise solution est presque toujours « un compte utilisateur sans MFA ». Mieux valent des voies techniques qui ne dépendent pas d’une authentification interactive : relais mail central avec RESTriction IP, approches par certificats ou connecteur, ou boîtes système séparées avec des droits RESTreints. L’essentiel : l’appareil lui‑même ne peut pas gérer le MFA, donc le design doit sécuriser le transport et le chemin réseau.

Ausnahmefall 3: Notbetrieb und eingeschränkte Erreichbarkeit

Le personnel itinérant, la production ou le travail en équipes connaissent des situations sans couverture mobile ou sans appareils mobiles personnels. Il vaut la peine de réfléchir tôt à des méthodes MFA alternatives : tokens matériels, clés de sécurité FIDO2, ou Windows Hello for Business (authentification liée à l’appareil). « Désactiver temporairement le MFA » est séduisant opérationnellement, mais difficile à industrialiser et peu compatible avec l’auditabilité.

Ausnahmefall 4: Automatisierte Jobs mit Benutzerkontext

Certains systèmes hérités lancent des tâches « en tant qu’utilisateur », par exemple pour des uploads vers SharePoint ou des rapports. Aujourd’hui, cela représente un risque car cela mélange les rôles et les droits d’accès. Si une refonte n’est pas immédiatement possible, travaillez par étapes intermédiaires : comptes de service limités, Named Locations claires, politiques strictes de mots de passe/secrets et journalisation systématique. Et : planifiez la migration vers des identités d’application comme un lot de travail à part, pas comme « pour plus tard ».

Wie man Ausnahmen dokumentiert, genehmigt und wieder loswird

Les exceptions ne sont acceptables en exploitation que si elles ont un cycle de vie. Une approche légère, sans lourde bureaucratie mais néanmoins auditable, s’est révélée efficace :

1. Motif en une phrase : Quelle fonction métier ou opérationnelle en dépend (p. ex. « Scan-to-Mail sur le site X ») ?
2. Classement technique : Quelle application/protocoles, quels comptes, quels flux de données ?
3. Contrôles compensatoires : Qu’est‑ce qui limite le risque (RESTriction IP, droits minimaux nécessaires, monitoring) ?
4. Date d’expiration : Chaque exception reçoit une date de réexamen. Sans réexamen, elle est supprimée ou réapprouvée.
5. Propriétaire : Qui est responsable en cas de problème ou à l’expiration de l’exception ?

Cela ne rend pas les exceptions « bonnes », mais elles deviennent maîtrisables. Et c’est précisément dans le quotidien la différence entre une base de sécurité M365 robuste et une prolifération anarchique des politiques.

Break-Glass-Accounts: accès d’urgence sans faille de sécurité

Les comptes Break-Glass sont des comptes d’urgence pour accéder au Tenant lorsque les accès administrateurs classiques ne fonctionnent pas – par exemple en cas de mauvaise configuration du Conditional Access, de panne d’un fournisseur MFA ou d’un incident d’identité. L’objectif est clair, mais la mise en œuvre comporte des écueils typiques : un compte Break-Glass jamais testé n’aidera pas en situation réelle. Un compte Break-Glass trop facilement accessible constitue une cible attractive pour un attaquant.

Ce que n’est pas le Break-Glass

• Pas un compte admin quotidien : Il ne doit pas être utilisé dans l’exploitation courante.
• Pas un fourre-tout pour exceptions : Il ne remplace pas une conception propre du CA.
• Pas « on en a un, ça ira » : Sans processus, test et alerting, ce n’est qu’un plan théorique.

Principes de base pour le Break-Glass en production

Une configuration praticable s’articule autour de trois objectifs : accessible en urgence, difficile à attaquer en fonctionnement normal, et parfaitement traçable.

• Au moins deux comptes : Redondance contre le verrouillage, les erreurs d’utilisation ou des identifiants compromis.
• Fortement protégés : Mots de passe longs et aléatoires ; pas de redirections d’e‑mail ; pas d’utilisation pour des applications/intégrations.
• Exclus ciblées du CA – mais strictes : Il est courant d’exclure certains utilisateurs ou groupes de politiques CA pour éviter de se verrouiller soi‑même en urgence. En parallèle, d’autres mécanismes de sécurité doivent RESTer actifs : alertes lors de l’utilisation, attribution de rôles RESTrictive, conservation séparée des identifiants.
• Journalisation et alerting : Chaque connexion doit déclencher un signal immédiat (SIEM/SOC ou au minimum alerte par e‑mail/Teams vers une boîte incident). L’utilisation du Break-Glass est par définition un événement de sécurité.

Un point central : décidez délibérément si le Break-Glass fonctionne avec ou sans MFA. Beaucoup d’organisations le laissent sans MFA pour RESTer opérationnelles en cas de panne MFA. Dans ce cas, les contrôles compensatoires doivent être particulièrement soignés (conservation, accès au mot de passe, alerting, rotation régulière). En alternative, on peut équiper le Break-Glass d’un MFA matériel (p. ex. FIDO2) indépendant du réseau mobile. L’important n’est pas une idéologie « correcte », mais un chemin d’urgence qui fonctionne effectivement dans votre contexte.

Réalité du déploiement : comment éviter les verrouillages et les pics de support

Beaucoup de déploiements CA/MFA échouent non pas techniquement, mais organisationnellement : trop rapides, trop larges, sans télémétrie et sans processus de support clair. Un déploiement stable se fait par vagues et points de mesure.

Étape 1 : Créer de la visibilité (avant de bloquer)

Utilisez les journaux de connexion et des analyses pour déterminer : quelles applications sont utilisées ? Quels clients sont « Legacy » ? Quelles localisations/ plages d’IP sont réelles ? Quels utilisateurs ont particulièrement des problèmes d’authentification ? Sans ces données, toute politique est un vol à l’aveugle.

Étape 2 : Groupes pilotes avec de vrais cas limites

Les pilotes ne doivent pas se limiter à « l’informatique et quelques volontaires ». Intégrez volontairement des cas limites : les équipes terrain, les sites de production, des collaborateurs de projet avec accès invité, et au moins un service utilisant des outils tiers typiques. L’objectif n’est pas l’harmonie, mais la détection précoce des vrais points de blocage.

Étape 3 : Définir des playbooks pour le helpdesk

Lorsque le MFA est imposé, le nombre de tickets augmente : changement d’appareil, téléphones perdus, nouvel·les employé·es, compte bloqué après trop d’essais. Définissez ce que le First-Level peut résoudre (p. ex. réinitialisation MFA après vérification d’identité) et quand il faut escalader. Sans Playbooks, tout s’escalade — et les admins deviennent le goulot d’étranglement.

Étape 4 : Regrouper les travaux techniques dans un backlog distinct

CA met en lumière des dettes techniques cachées : clients mail obsolètes, scanners non documentés, scripts avec mot de passe dans le Task Scheduler, ou intégrations qui utilisent encore Basic Auth. Planifiez ces travaux comme des paquets de travail visibles. Sinon, ils RESTent en « exception permanente ».

Scénarios d’erreur typiques en exploitation — et comment les classer plus rapidement

Au quotidien, les hypothèses rapides comptent. Certains schémas reviennent régulièrement :

« Soudain Outlook ne fonctionne plus »

Causes fréquentes : legacy client, profil ancien, ou un blocage CA dû à l’état non conforme de l’appareil. Vérifiez : type de client dans le sign-in log, CA-Policy appliquée, et si l’appareil est considéré comme conforme. Le correctif opérationnel est rarement « désactiver la policy », mais plutôt « moderniser le client » ou « remettre en ordre la gestion des appareils ».

« Le service XY ne peut plus envoyer d’e-mails »

Souvent il s’agit d’un changement d’authentification SMTP, d’une Relay-Policy modifiée ou d’une nouvelle règle CA qui impacte involontairement des comptes techniques. Une décision d’architecture claire aide : envoi via Relay/Connector plutôt que via login utilisateur, avec RESTriction IP et logging (traçabilité dans l’incident).

« L’admin n’arrive plus dans le tenant »

C’est le cas d’usage prévu pour le Break-Glass. Si l’accès Break-Glass ne fonctionne pas non plus, il manque généralement un chemin d’urgence testé ou l’exception a été mal construite. Donc : exercer l’utilisation régulièrement (avec documentation indiquant qui teste quand et à quoi ressemble l’alerte).

« Trop d’exceptions — personne n’y voit clair »

C’est un problème de gouvernance. Consolidez les Policies, définissez un rituel de revue (p. ex. 30 minutes par mois), et supprimez les exceptions qui n’ont plus d’Owner ou d’objectif. Techniquement, ce n’est pas glamour, mais c’est la différence entre une sécurité maîtrisable et des droits particuliers hérités.

Monitoring et traçabilité : ce dont vous avez réellement besoin

CA et MFA génèrent de nombreux événements. Si vous collectez tout, vous vous noyez ; si vous n’analysez rien, vous détectez les problèmes trop tard. Trois niveaux sont pragmatiquement utiles :

• Alerting sur événements critiques : Break-Glass-Login, Admin-Login depuis des pays inhabituels, événements de blocage sur des applications critiques.
• Revue régulière : principaux motifs de blocage, principaux utilisateurs avec problèmes MFA, tentatives d’authentification legacy, nouvelles apps/Enterprise Apps.
• Trace d’audit pour les exceptions : qui a approuvé quelle exception, avec quelle date d’expiration, et quand elle a été revue ?

Si vous avez déjà des processus centraux de logging et d’incident (SIEM, Ticketing, Change-Management), ancrez-y les changements CA. Conditional Access n’est pas un « petit réglage », mais une couche d’accès critique en production.

Effort et responsabilités : qui doit livrer quoi ?

Les projets CA/MFA sont sous-estimés parce qu’ils semblent être de la simple configuration. En réalité, ce sont des projets d’interface entre identité, terminaux, réseau et processus métiers. Un modèle de responsabilités clair réduit les frictions :

• Identity-Team / Entra Admins : Policy-Design, Rollenmodell, Break-Glass, App-Registrierungen.
• Gestion des clients (p. ex. Intune) : définition de la conformité, état des appareils, déploiement d’Authenticator/Passkeys, cycle de vie des appareils.
• Réseau : plages d’adresses IP pour Named Locations, exceptions proxy/inspection TLS, changement de site.
• Propriétaire de service des applications métier : chemins d’intégration (Graph/SMTP/SharePoint), transition depuis l’authentification legacy, rotation des secrets.
• Helpdesk : processus standard pour réinitialisation MFA, changement d’appareil, onboarding/offboarding.

La décision de management la plus importante n’est souvent pas « MFA oui/non », mais : avons-nous le temps et les ressources pour les travaux de suivi (élimination du legacy, modernisation des intégrations, stabilisation de la gestion des appareils) ? Sans ce travail, le gain de sécurité restera en deçà des attentes — ou l’exploitation deviendra inutilement lourde.

Conclusion : la sécurité progresse lorsque l’urgence et les exceptions font partie du système

Sécuriser correctement Microsoft 365 signifie exploiter Conditional Access comme une couche de contrôle centrale — pas comme une configuration ponctuelle. MFA est obligatoire, mais la qualité opérationnelle réelle se construit par des exceptions propres (avec date d’expiration, responsable et contrôles compensatoires) et par des comptes Break-Glass, testés, surveillés et intégrés organisationnellement. Qui articule ces trois éléments réduit les risques liés aux comptes, obtient la capacité d’audit sans surcharge et évite que les règles de sécurité deviennent, en cas d’incident, un handicap.

Discuter d’un projet ou d’une modernisation avec Net-Base.