Comprendre les cas limites liés aux anciens protocoles dans l’écosystème Microsoft

By Mirko Peters · 2026-04-26

Les protocoles d’authentification hérités (NTLM, SMTP AUTH ou encore le bon vieux FTP) peuvent sembler appartenir à une autre époque, mais ils restent obstinément présents dans l’univers d’entreprise centré sur Microsoft d’aujourd’hui…

Automatically translated with AI from the original post. Read the English original

Cover: Detect Microsoft 365 Attack Chains with Entra and Sentinel

Les protocoles d’authentification hérités (NTLM, SMTP AUTH ou encore le FTP de la vieille école) peuvent sembler appartenir à une autre époque, mais ils persistent obstinément dans l’environnement d’entreprise centré sur Microsoft. Les organisations modernes migrent vers Microsoft 365 et Azure, pourtant les cas limites liés à ces protocoles affaiblissent discrètement les ambitions Zero Trust et les stratégies de sécurité. Vous pouvez verrouiller la porte d’entrée avec l’authentification multifacteur, mais il arrive qu’une vieille fenêtre reste ouverte au sous-sol.

Pourquoi ces cas limites continuent-ils de poser problème\u00A0? La réalité est que la modernisation du SI ne peut pas toujours se faire du jour au lendemain. De nombreux systèmes métier critiques, intégrations tierces et même équipements techniques opérationnels (OT) sont câblés pour utiliser des protocoles plus anciens. Les attaquants le savent\u00A0: ils ciblent ce qui fonctionne encore, contournent les contrôles modernes et exploitent les failles là où les équipes de sécurité s’y attendent le moins.

Cet article examine comment et pourquoi les risques liés aux protocoles hérités persistent à mesure que les entreprises font évoluer leurs environnements Microsoft. Nous définirons les éléments techniques, passerons en revue les dangers critiques pour l’activité et présenterons les actions possibles, de la détection à la gouvernance, pour refermer durablement ces failles persistantes. Plongeons ensemble pour comprendre d’où viennent réellement les risques et comment fermer une bonne fois pour toutes ces portes dérobées.

Vulnérabilités des protocoles hérités et exploitation dans le monde réel

Même avec les défenses natives du cloud et l’authentification multifacteur, les attaquants continuent de tirer profit de maillons faibles hérités de décennies passées. Les protocoles hérités, comme NTLM pour l’authentification, SMTP AUTH pour la messagerie, ou FTP et POP3 de base pour le transfert de données, persistent parce que les systèmes réels doivent continuer de fonctionner pendant la modernisation. Les attaquants en profitent, car cela leur permet souvent de contourner les systèmes les mieux protégés de l’entreprise.

Dans les environnements hybrides actuels, ces anciens protocoles ne se limitent pas à un serveur isolé dans un centre de données\u00A0: ils sont tissés dans les plateformes d’identité cloud, les applications métier et même les équipements OT et IoT, incapables de gérer l’authentification moderne. Il est difficile de les supprimer progressivement, car les bloquer purement et simplement peut interrompre un service critique, et la détection sur l’ensemble de ces périmètres n’est pas toujours homogène.

Le résultat\u00A0? Des incidents comme les violations de données de Vercel et d’Orange España montrent qu’il suffit d’un seul protocole oublié pour ouvrir la porte au vol de données ou à la compromission du réseau. Les attaquants exploitent ces voies héritées pour contourner l’authentification multifacteur, relayer des identifiants ou élever leurs privilèges à travers les charges de travail cloud et sur site. Nous détaillerons précisément le fonctionnement de ces attaques, pourquoi ces protocoles sont intrinsèquement défaillants et où se situent les risques métier les plus tenaces.

Nous évoquerons également les habitudes opérationnelles qui perpétuent ces risques, comme le recours à une hygiène des stratégies trop laxiste ou l’héritage d’années de dette technique issue d’intégrations « qui fonctionnent, c’est l’essentiel ». Les sous-sections suivantes approfondiront la manière dont les vulnérabilités héritées sont exploitées, les failles systémiques des protocoles et les impasses auxquelles se heurtent les défenses modernes. Si vous cherchez à sécuriser réellement votre environnement Microsoft, vous devez savoir précisément où se cachent ces menaces anciennes, et comment elles continuent de s’infiltrer alors que vos journaux affichent « sécurisé ». Pour en savoir plus sur l’enchaînement de ces attaques dans la réalité, consultez cette analyse détaillée des chaînes d’attaque sur Microsoft 365.

Comment les violations de données de Vercel et d’Orange España ont mis en lumière les risques liés aux protocoles hérités

Les violations de données de Vercel et d’Orange España ont placé sous un jour cru la réalité de ces risques liés aux protocoles hérités, bien loin d’une simple hypothèse. Dans les deux incidents, des méthodes d’authentification obsolètes ont joué un rôle déterminant, offrant aux attaquants un jeu de clés pour progresser plus profondément dans les réseaux d’entreprise. Dans le cas de Vercel, les attaquants ont réussi à extraire des variables d’environnement et des secrets provenant de centaines de clients de premier plan, simplement parce que des identifiants liés à des processus d’authentification hérités étaient encore utilisés en coulisses.

La violation subie par Orange España présentait un schéma similaire. Ici, les attaquants ont contourné les défenses de première ligne en utilisant des identifiants valides volés, dont beaucoup n’auraient pas fonctionné si des protocoles hérités comme POP3/IMAP ou SMTP AUTH non sécurisé n’avaient pas été activés pour la messagerie. Selon le rapport annuel d’IBM sur les menaces, le vol d’identifiants reste le principal vecteur d’accès initial dans les violations d’entreprises, en particulier lorsque les organisations ne désactivent pas proactivement les méthodes d’authentification obsolètes.

Les experts qui analysent ces cas insistent sur un point essentiel : les vulnérabilités des protocoles hérités ne sont pas de simples vestiges techniques. Elles sont souvent profondément intégrées aux scripts d’automatisation, aux outils de sauvegarde, voire aux appareils embarqués qui utilisent discrètement une authentification obsolète au quotidien. À titre d’exemple, dans la chaîne d’attaque contre Vercel, des protocoles comme l’authentification de base et des jetons d’accès mal imbriqués ont permis aux attaquants de contourner les contrôles de stratégie modernes, puis de se déplacer latéralement une fois à l’intérieur du réseau.

Que peuvent retenir les organisations ? Les violations très médiatisées ne cessent de le rappeler : sécuriser les points d’entrée cloud les plus récents ne suffit pas. Une véritable résilience exige d’éliminer ces chemins hérités cachés. Tant que ce ne sera pas fait, les attaquants continueront de privilégier les voies d’accès les plus simples et les moins protégées, souvent présentes en arrière-plan dans les environnements hybrides et multicloud.

Relais NTLM et problème de l’authentification de base : contourner les contrôles de sécurité modernes

Les protocoles hérités comme NTLM et l’authentification de base posent de nombreux problèmes aux équipes de sécurité, car ils ne respectent pas les règles MFA modernes. Voici comment les acteurs malveillants exploitent ces faiblesses pour contourner les défenses :

Attaques par relais NTLM :
Les attaquants capturent des hachages NTLM sur un appareil compromis et les « relaient » vers d’autres services auxquels la victime a accès. Comme NTLM ne nécessite pas de connaître le mot de passe d’origine, l’attaquant peut usurper l’identité des utilisateurs sans jamais casser un mot de passe. Ces relais vont souvent de l’AD local vers le cloud, en particulier dans des configurations d’identité hybride mal segmentées.
Contournement de la MFA :
Des protocoles comme SMTP AUTH et IMAP ne prennent pas du tout en charge la MFA. Si un attaquant obtient des identifiants valides, il peut se connecter via ces protocoles, même si la MFA est par ailleurs imposée aux comptes utilisateurs. Cela signifie que des mots de passe faibles et réutilisés deviennent un point de défaillance unique dans des environnements pourtant considérés comme sécurisés.
Déplacement latéral et élévation de privilèges :
Une fois à l’intérieur, les attaquants utilisent les protocoles hérités pour pivoter. Par exemple, en exploitant l’authentification de base d’une application oubliée, ils peuvent se déplacer latéralement vers des systèmes disposant de privilèges plus élevés. L’accès à un seul service SMB ou Exchange non protégé conduit souvent à une compromission de l’ensemble du réseau.
Contournement de l’accès conditionnel :
De nombreuses stratégies d’accès conditionnel dans Azure AD ne s’appliquent qu’aux clients utilisant l’authentification moderne. Les protocoles hérités peuvent passer discrètement sous ces règles, laissant subsister des dangereuses « listes d’autorisation » ou des failles de stratégie que les attaquants recherchent activement. Vous souhaitez en savoir plus sur les boucles de sécurité des identités et sur la correction de la prolifération des accès conditionnels ? Découvrez cet épisode de podcast consacré à la réduction évolutive des risques dans les environnements Microsoft.

En bref, vous avez beau déployer et configurer tous les contrôles modernes, si des protocoles hérités traînent encore, les attaquants trouveront presque à coup sûr un moyen de contourner vos nouvelles défenses.

Failles systémiques : des vulnérabilités de MCP aux risques LLMNR et NetBIOS

Les protocoles hérités de Microsoft sont hantés par des failles qui ne sont pas de simples bogues : elles sont intégrées à leur conception même. Voici pourquoi ces faiblesses représentent un risque tenace :

Failles de MCP (Microsoft Connector Platform) :
Certaines plateformes et certains connecteurs utilisés par des agents tiers et des scripts d’automatisation reposent encore sur un transfert d’identifiants hérité, sans liaison appropriée des jetons ni contrôle d’accès granulaire. Les attaquants les exploitent pour élever leurs privilèges, en particulier lorsque les stratégies des agents ne sont pas strictement gouvernées.
Faiblesses de LLMNR (Link-Local Multicast Name Resolution) :
LLMNR a été conçu pour faciliter la résolution de noms sur le réseau, mais il est facilement détourné pour voler des identifiants. Les attaquants diffusent de fausses réponses, incitant les systèmes voisins à transmettre des hachages NetNTLM, qui peuvent ensuite être cassés ou relayés.
Risques liés à la dénomination NetBIOS :
Les anciens réseaux Windows utilisent encore NetBIOS pour la résolution de noms, un autre protocole qui n’a jamais été conçu en pensant à la sécurité. Des attaquants peuvent intercepter et manipuler le trafic pour se faire passer pour des services ou collecter des informations sensibles sur le réseau, ce qui prépare d’autres attaques.
Lacunes de la signature SMB :
La signature SMB a été ajoutée pour sécuriser les partages de fichiers, mais son application reste inégale, en particulier dans les réseaux hybrides et les environnements OT. Les attaquants en profitent en relayant des identifiants ou en falsifiant les réponses entre systèmes, franchissant souvent la frontière entre l’OT historique et l’infrastructure IT moderne.

La désactivation de protocoles comme LLMNR et l’application de la signature SMB sont indispensables à toute véritable démarche Zero Trust. Pour découvrir comment un contrôle coordonné et une sécurité adaptative peuvent aider à combler ces lacunes de protocoles, écoutez l’épisode du podcast Zero Trust by Design : c’est une analyse pratique de l’identité unifiée et des contrôles de session.

Authentification moderne et héritée : défis de transition et cas limites

Passer de l’authentification héritée à l’authentification moderne est un cheminement, non un simple basculement. En comblant l’écart, vous rencontrerez toutes sortes de cas limites. Si OAuth 2 et MFA élèvent le niveau de sécurité, le besoin de compatibilité descendante laisse souvent la porte dérobée entrouverte. Les flux d’authentification « semi-modernes », comme les modèles hybrides ou les protocoles qui se font passer pour modernes, apparaissent partout et brouillent les pistes, tant pour la conformité que pour la protection.

Pourquoi les organisations finissent-elles par adopter ces configurations hybrides ? La réponse est simple : les applications critiques, les services et les intégrations tierces ne sont pas toujours prêts à désactiver l’authentification héritée du jour au lendemain. Parfois, un simple processus métier ou un workflow d’automatisation hérité dépend de méthodes d’authentification vieilles de plusieurs décennies. Se précipiter pour les désactiver peut perturber l’activité ou compromettre la conformité ; des exceptions sont donc accordées, et c’est là que les attaquants s’engouffrent.

Un véritable Zero Trust consiste à fermer chaque faille, et non à ajouter de nouvelles couches clinquantes. Le piège, c’est que, lorsque vous tentez de moderniser l’authentification, certaines « mises à niveau » enveloppent simplement d’anciennes vulnérabilités dans un emballage plus récent, comme BAV2ROPC ou d’autres flux de mot de passe du propriétaire de ressource. Les lacunes des stratégies et les exclusions oubliées dans l’accès conditionnel peuvent aussi donner une apparence moderne à votre sécurité sur le papier, tout en laissant grand ouvertes les voies héritées.

Les sections suivantes examinent les subtilités techniques de ces configurations semi-modernes et détaillent les points où même les meilleurs plans d’amélioration se heurtent à des obstacles concrets. Si vous préparez une véritable transformation, ou si vous cherchez simplement à empêcher les attaquants d’entrer, il est utile de comprendre pourquoi la prise en charge des méthodes héritées a la vie dure, et à quel endroit votre stratégie peut encore vous exposer. Pour des conseils sur la mise en place de références fiables pour les stratégies d’accès conditionnel, consultez cet article sur les problèmes de confiance liés aux stratégies.

Le mystère de BAV2ROPC et les pièges de l’authentification semi-moderne

BAV2ROPC signifie « Basic Authentication Version 2 Resource Owner Password Credential ». Ce nom sonne moderne, mais il ne s’agit en réalité que d’un nouvel habillage d’un vieux problème. Ce protocole, souvent rencontré dans les environnements cloud Microsoft, fait le lien entre authentification héritée et moderne en permettant à des applications de transmettre par programme un nom d’utilisateur et un mot de passe pour obtenir un jeton de ressource, sans navigateur ni flux de consentement moderne.

Cette approche « semi-moderne » trompe bien des organisations. En surface, BAV2ROPC utilise des points de terminaison modernes et des flux OAuth 2. Mais, en profondeur, il repose sur le même échange basique nom d’utilisateur/mot de passe que les protocoles historiques comme POP3, IMAP ou SMTP AUTH, et prend rarement en charge le MFA ou l’accès conditionnel. Cela laisse la porte ouverte aux attaquants pour mener des attaques par bourrage d’identifiants, rejeu d’identifiants ou relais, de l’environnement local vers le cloud.

La détection est difficile. Dans les journaux, le trafic BAV2ROPC est difficile à distinguer de la véritable authentification moderne. Les attaquants le savent et ciblent délibérément les applications ou les comptes de service qui utilisent ces flux, car les tentatives d’intrusion ne déclenchent pas les mêmes alertes que l’ancienne authentification de base. Dans la réalité, les organisations peinent à abandonner BAV2ROPC, en particulier pour les tâches d’automatisation sans interface et les scripts d’intégration encore utilisés au quotidien.

Pour les équipes de sécurité, le piège le plus fréquent consiste à supposer qu'un élément étiqueté « OAuth 2 » ou « resource owner » est sûr par défaut. BAV2ROPC et d'autres protocoles similaires montrent la réalité dérangeante : même des API modernes et élégantes peuvent vous exposer aux mêmes faiblesses que les protocoles qu'elles étaient censées remplacer. Tant que vous n'avez pas entièrement audité et migré chaque cas particulier, ces failles semi-modernes restent des cibles ouvertes.

Quand les améliorations de l'authentification ne suffisent pas : la stratégie de sécurité minée par la prise en charge des anciens protocoles

Passer à OAuth 2 et déployer l'authentification multifacteur sur l'ensemble du parc semble être la solution idéale, jusqu'à ce que la prise en charge des anciens protocoles introduise une faille fatale. Des recherches montrent que plus de 60 % des prises de contrôle de comptes cloud survenues l'année dernière ont impliqué des identifiants valides utilisés via des protocoles hérités. Même les stratégies d'accès conditionnel les plus avancées s'effondrent dès qu'une exclusion a été oubliée ou qu'une ancienne application utilise encore l'authentification de base en arrière-plan.

Les experts le répètent : moderniser votre pile d'authentification ne se résume pas à cocher des cases dans une liste de fonctionnalités. La prise en charge persistante des anciens protocoles, les stratégies mal configurées ou les comptes de service non gérés permettent aux attaquants de contourner des défenses par ailleurs solides. Seul un plan de transition complet, qui supprime activement les anciennes voies d'accès, audite les exclusions de stratégies et encadre chaque point de terminaison, permet de tenir la distance. Pour un aperçu concret de la façon dont les attaquants exploitent le consentement OAuth et les voies héritées, lisez cette analyse approfondie sur les attaques par consentement dans Entra ID, et pour comprendre pourquoi une bonne gouvernance n'est pas automatique, écoutez ce podcast sur l'illusion de la gouvernance dans Microsoft 365.

Détecter et surveiller l'utilisation des anciens protocoles dans les environnements d'entreprise

Repérer et surveiller l'utilisation de l'ancienne authentification revient à traquer des fuites cachées dans un vaste réseau de canalisations. Il est facile de passer à côté de protocoles encore actifs, car ces connexions n'apparaissent pas toujours en bonne place dans les tableaux de bord modernes. Pourtant, chaque occurrence manquée, qu'il s'agisse d'un ancien script de sauvegarde, d'une imprimante ou d'un capteur IoT, offre à un attaquant une chance supplémentaire de s'introduire.

Pour y remédier, les environnements Microsoft 365 et Azure proposent une série de journaux et d'outils d'analyse conçus pour offrir une visibilité approfondie. Encore faut-il savoir où chercher et interpréter des résultats qui ne signalent pas toujours clairement « authentification héritée détectée ». En combinant les journaux de connexion, les pistes d'audit et la télémétrie personnalisée issue d'outils comme PowerShell et Python, vous obtenez une vue plus complète des endroits où les anciens protocoles passent encore. Il est essentiel de croiser les données des ressources cloud et sur site, car les architectures hybrides présentent souvent des rapports incohérents.

Qu'est-ce qui rend ce défi encore plus délicat ? Certains appareils tiers et OT continuent d'utiliser discrètement des protocoles hérités et sont rarement inclus dans les analyses de sécurité ou les rapports standard. Les équipes de sécurité doivent superposer plusieurs techniques de surveillance, des classeurs de connexion Azure aux extractions du journal d'audit unifié, pour détecter la moindre trace d'utilisation de protocoles. Pour une présentation pratique de l'audit de l'activité sur votre locataire et des raisons pour lesquelles des signaux plus riches sont essentiels à la conformité et à la sécurité, consultez ce guide sur Microsoft Purview Audit.

Les sous-sections suivantes vous expliquent pas à pas comment repérer et analyser les traces d'authentification héritée dans votre environnement, ainsi que des conseils pratiques pour générer une télémétrie exploitable, afin que ces vulnérabilités cachées ne le restent pas longtemps.

Repérer l'authentification héritée dans les journaux de connexion Azure et les classeurs d'analyse

Détecter l'authentification héritée dans les journaux de connexion Azure et les analyses Entra ID demande une approche proactive. Voici une liste de contrôle pratique pour repérer ces protocoles risqués en action :

Filtrer par type d'application cliente :
Commencez par les journaux de connexion Azure AD dans le portail Azure. Filtrez les entrées sur « Application cliente » pour afficher les connexions établies avec des protocoles hérités comme IMAP, POP3, SMTP et « Autres clients ». Ces entrées se distinguent généralement, car elles n'utilisent pas les flux d'authentification modernes ou basés sur un navigateur.
Rechercher les méthodes d'authentification :
Examinez en détail les événements de connexion dont la « Méthode d'authentification » est définie sur « Mot de passe » sans « MFA » ni « Authentification moderne ». Cela indique souvent des protocoles qui contournent l'accès conditionnel, en particulier depuis des appareils anciens ou des scripts d'automatisation.
Configurer des classeurs d'analyse :
Utilisez Azure Monitor ou les classeurs Entra ID Analytics pour visualiser l’évolution des tendances dans le temps. Créez un classeur personnalisé pour représenter graphiquement l’utilisation des protocoles, mettre en évidence les pics d’authentification héritée et signaler les connexions clientes non conformes.
Corréler avec les données d’appareil et de localisation :
Croisez les événements d’authentification héritée avec les informations sur les appareils et la géolocalisation des connexions. Les combinaisons inattendues, comme une connexion par protocole hérité depuis un pays dans lequel votre entreprise n’est pas implantée, méritent une analyse approfondie.
Conseils de dépannage :
Si les résultats semblent peu nombreux, vérifiez l’existence de lacunes dans les stratégies ou la rétention des journaux. Certains événements peuvent être filtrés ou manqués si les paramètres d’audit ne sont pas complets, ou si des exclusions existent dans les stratégies d’accès conditionnel.

En répétant ces étapes, vous obtenez une visibilité fiable. Gardez à l’esprit que quelques entrées de protocoles hérités seulement dans vos journaux peuvent révéler des risques bien plus importants ailleurs. Creusez donc en profondeur et suivez les données là où elles mènent.

Génération de télémétrie avec PowerShell, Python et le journal d’audit unifié : exemples et bonnes pratiques

Pour détecter la moindre trace d’activité de protocole hérité, rien ne vaut une télémétrie personnalisée. Voici comment la mettre en place avec PowerShell, Python et le journal d’audit unifié de Microsoft :

Requêtes PowerShell pour les protocoles hérités :
Appuyez-vous sur les applets de commande Get-Mailbox et Get-CASMailbox d’Exchange Online pour lister les utilisateurs disposant d’IMAP, de POP3 ou de SMTP AUTH activé. Intégrez-les dans des scripts pour générer des rapports quotidiens ou hebdomadaires, et croisez-les avec les informations issues des journaux de connexion.
Automatisation Python pour la corrélation des journaux :
Utilisez des scripts Python pour vous connecter à l’API Microsoft Graph et extraire les enregistrements de connexion et d’audit des boîtes aux lettres. Analysez les types d’applications clientes et les indicateurs de protocole d’authentification, puis générez la liste des anomalies, comme les comptes de service sans interface utilisant l’authentification héritée.
Journal d’audit unifié pour une surveillance centralisée :
Activez Microsoft Purview Audit (anciennement journal d’audit unifié) pour agréger l’activité d’Exchange, SharePoint, Teams et d’autres services. Interrogez les champs Operation liés aux connexions clientes héritées ou aux tentatives d’authentification héritée échouées afin de alimenter un pipeline de détection consolidé.
Mettre en place des visualisations interactives et des alertes :
Exportez ou diffusez la télémétrie vers Microsoft Sentinel ou Power BI. Créez des tableaux de bord assortis de règles d’alerte qui se déclenchent lors de nouvelles utilisations de protocoles hérités ou lorsque des expositions d’identifiants sont détectées.
Attention aux pièges :
Méfiez-vous des données incomplètes liées à une durée de rétention limitée des journaux, à des lacunes de configuration par défaut ou à des événements non journalisés par défaut. Validez toujours votre couverture avec des connexions de test utilisant les protocoles hérités avant de crier victoire.

Pour en savoir plus sur l’intégration de la télémétrie dans la gouvernance et l’automatisation (lorsque le contenu sera de nouveau disponible), suivez les mises à jour de cette page sur l’automatisation PowerShell actuellement indisponible, ou consultez leurs derniers épisodes de podcast sur l’architecture d’entreprise pour découvrir les prochaines évolutions des stratégies de télémétrie.

Stratégies d’atténuation : blocage et désactivation des protocoles hérités

Savoir que vous utilisez des protocoles hérités n’est que la première bataille ; la gagner consiste à couper ces canaux sans paralyser l’activité. La bonne approche repose sur un équilibre entre réduction des risques et continuité opérationnelle. Microsoft 365 et Azure AD vous offrent des outils puissants, comme l’accès conditionnel et les paramètres d’administration, pour bloquer les méthodes d’authentification obsolètes à l’échelle de l’entreprise, mais leur déploiement doit être mené avec discernement.

Les deux tactiques principales consistent à utiliser l’accès conditionnel pour bloquer l’authentification héritée de façon générale, et à désactiver des protocoles comme SMTP AUTH, IMAP et POP3 pour l’accès à la messagerie et aux appareils. Le point délicat est d’identifier toutes les exceptions et tous les flux de travail concernés avant de couper le courant, en particulier pour les comptes de service, les systèmes de messagerie hybrides sur site ou les intégrations tierces qui ne peuvent pas être modernisées facilement. Des déploiements par étapes et des mises à jour ciblées des stratégies permettent de ne pas interrompre les processus critiques tout en réduisant votre exposition au vol d’identifiants et à l’utilisation abusive pour le spam.

Il est également essentiel d’associer les évolutions de stratégie à la sensibilisation des métiers. Communiquez avec les parties prenantes, testez sur de petits groupes et exploitez les données d’analyse pour démontrer que ce changement n’entraînera pas l’arrêt des opérations. Dans les sections ci-dessous, vous trouverez des instructions pas à pas et des points d’attention concernant l’application des accès conditionnels et la désactivation des protocoles dans le Centre d’administration Microsoft 365. Curieux des risques cachés lorsque les habitudes de travail ne sont pas mesurées ? Écoutez ce podcast sur la dérive de conformité et l’application des stratégies pour aller plus loin.

Avec un plan d’action bien pensé, bloquer les protocoles hérités ne se contentera pas de cocher des cases de conformité : vous compliquerez nettement la tâche des attaquants qui cherchent cette porte oubliée restée ouverte.

Comment bloquer l’authentification héritée avec les accès conditionnels

Bloquer l’authentification héritée avec les accès conditionnels d’Azure AD est à la fois puissant et précis, à condition de bien le faire. Voici les points essentiels à connaître :

Les stratégies d’accès conditionnel permettent aux organisations de bloquer explicitement les tentatives d’authentification issues de protocoles anciens comme SMTP AUTH, IMAP, POP3 et les clients utilisant l’authentification de base. Vous pouvez cibler ces stratégies par utilisateurs, groupes ou appareils, tout en surveillant l’impact potentiel sur l’activité en mode « rapport seul » avant leur mise en production. Cette approche progressive vous permet d’identifier les dépendances qui pourraient être rompues par un blocage immédiat.

Microsoft recommande de créer au moins deux stratégies de base : l’une qui bloque l’authentification héritée pour tous les utilisateurs, et une seconde avec des exclusions limitées dans le temps pour les comptes de service ou les exceptions connues. Les tests sont essentiels : commencez en mode surveillance pour observer quels comptes et applications tentent des connexions héritées, puis passez à l’application une fois certain que seuls des flux non essentiels seront perturbés.

Pensez à revoir et à réduire les listes d’autorisation trop larges ou les exceptions héritées, car elles créent des failles de sécurité invisibles. La surveillance continue et les alertes sur les tentatives d’authentification héritée vous aideront à détecter les nouveaux risques à mesure que votre environnement informatique évolue. Pour d’autres bonnes pratiques et une base solide de stratégies inclusives, consultez l’analyse d’un expert sur le réglage des accès conditionnels pour une gestion des accès prévisible et sécurisée.

En bref : renforcer les accès conditionnels constitue votre première ligne de défense. Veillez simplement à déployer les modifications de manière méthodique, en conciliant en permanence les besoins métiers et les objectifs de sécurité.

Désactiver SMTP AUTH et les protocoles de messagerie hérités dans le Centre d’administration Microsoft 365

Désactiver SMTP AUTH et les autres protocoles de messagerie hérités est l’un des moyens les plus rapides de réduire le vol d’identifiants et d’empêcher les attaquants d’envoyer du spam depuis votre locataire. Voici la marche à suivre, étape par étape :

Auditer l’utilisation actuelle :
Commencez par Exchange Online PowerShell (Get-TransportConfig et Get-Mailbox). Repérez les boîtes aux lettres pour lesquelles SMTP AUTH est activé, ainsi que les protocoles IMAP/POP3 encore actifs pour des utilisateurs ou des comptes de service.
Désactiver au niveau du locataire :
Le Centre d’administration Microsoft 365 permet désormais de désactiver SMTP AUTH pour l’ensemble de votre locataire d’un simple paramètre. Toutes les nouvelles tentatives d’authentification sont ainsi bloquées, sauf exceptions accordées à des boîtes aux lettres spécifiques.
Nettoyage ciblé des stratégies :
Pour les utilisateurs ou les applications qui ont réellement besoin de SMTP AUTH, restreignez explicitement l’accès et surveillez-les de près. Retirez les autorisations IMAP/POP3 à tous les comptes, sauf aux plus essentiels, idéalement à aucun.
Tester et communiquer :
Avant de désactiver à grande échelle, réalisez des cas de test et informez les utilisateurs ou les responsables des systèmes concernés. Surveillez les tickets du support liés à des automatisations défaillantes, puis travaillez avec ces équipes pour adapter leurs processus ou les faire migrer vers l’authentification moderne.
Surveiller après le déploiement :
Consultez les journaux d’audit pour repérer les tentatives échouées sur les protocoles hérités. Des échecs persistants peuvent révéler soit des tentatives d’attaque, soit des dépendances métiers oubliées qu’il faudra traiter.

Cette méthode stoppe la plupart des attaques classiques d’identifiants par messagerie et allège nettement le travail de votre équipe de conformité. Des contrôles solides en amont signifient moins de nettoyage par la suite.

Gouvernance de la sécurité et supervision stratégique du risque lié aux protocoles hérités

Verrouiller les protocoles hérités ne se résume pas à modifier quelques paramètres techniques. La véritable gestion des risques se joue au plus haut niveau, là où la direction générale, les équipes des opérations de sécurité et les architectes IT travaillent ensemble pour piloter le cycle de vie de la technologie comme celui des stratégies. Le problème, c’est que la plupart des grandes organisations s’appuient sur un assemblage hétéroclite de contrôles, de stratégies et de prestataires tiers, ce qui rend difficile l’application d’une supervision cohérente à grande échelle.

Une stratégie de gouvernance efficace répond à de grandes questions : comment gérer les risques lorsque les intégrations tierces, les outils agentiques et le Shadow IT fonctionnent chacun selon leurs propres règles ? Comment appliquer des contrôles uniformes lorsque la moitié de vos partenaires « de confiance » ou de vos appareils IoT ne peuvent même pas dialoguer avec une authentification moderne ? Et comment surveiller en continu la dérive des stratégies à mesure que l’activité, les collaborateurs et le paysage de la sécurité évoluent ?

C’est là qu’interviennent les cadres de gouvernance virtuels, la rigueur dans l’application des stratégies et les technologies d’intelligence avancée. La direction doit non seulement donner le ton au sommet, mais aussi mettre en place des contrôles réels, depuis l’évaluation des fournisseurs de services les plus à risque jusqu’à la conduite d’audits et le déploiement de l’automatisation pour la détection et la remédiation. Alors que l’IA et l’automatisation progressent plus vite que jamais, il s’agit avant tout d’aligner les outils, les stratégies et les personnes.

Dans les sections suivantes, nous examinerons les moyens efficaces dont disposent les RSSI et les décideurs pour bâtir des modèles de gouvernance remote-first, gérer les risques liés aux tiers et aux agents les plus imprévisibles, et exploiter l’intelligence moderne pour combler durablement les failles liées aux protocoles. Pour en savoir plus sur l’équilibre entre innovation et supervision, consultez ces conseils de gouvernance Power Platform, et découvrez comment suivre le rythme des automatisations et des agents, qui avancent plus vite que vos stratégies, dans cet épisode consacré à un cadre de gouvernance pratique.

Comment les responsables de la sécurité se protègent contre les tiers les plus risqués dans un cadre de gouvernance virtuel

Les organisations de référence adoptent une approche proactive et multicouche pour gouverner le risque lié aux protocoles hérités, en particulier celui qui vient des tiers. Voici quatre stratégies concrètes :

Mettre en place une supervision des agents : surveillez et auditez l’ensemble des comptes de service, agents et intégrations tierces qui interagissent avec votre environnement. Attribuez une identité unique aux agents (par exemple des Entra Agent IDs) et appliquez des contrats stricts via des plateformes telles que Microsoft Connector Platform (MCP). Cela permet de prévenir la dérive des identités et la perte de responsabilité, en particulier avec les intégrations basées sur l’IA (en savoir plus sur la gouvernance agentique ici).
Imposer des stratégies d’authentification sécurisée : exigez de tous les fournisseurs et partenaires qu’ils utilisent l’authentification moderne, sans exception pour des raisons de « compatibilité héritée », sauf à mettre en place des contrôles compensatoires approuvés. Passez régulièrement en revue les exclusions de l’accès conditionnel pour les appareils tiers et les flux passant par des connecteurs.
Segmenter et surveiller les appareils OT/IoT et ceux qui ne peuvent pas être corrigés : lorsque des technologies opérationnelles (OT) ou des appareils IoT ne fonctionnent qu’avec des protocoles hérités, isolez-les sur des réseaux distincts. Appliquez des contrôles compensatoires, comme la surveillance réseau et les listes d’autorisation d’accès, afin de réduire l’exposition aux menaces de mouvement latéral.
Mener des revues de gouvernance à distance : adoptez des cadres de gouvernance virtuels pour superviser, corriger et gouverner depuis n’importe où. Ces cadres reposent sur des revues régulières, des audits automatisés et une communication claire entre les parties prenantes, un impératif à mesure que davantage d’activités deviennent hybrides ou à distance.

En privilégiant une supervision à plusieurs niveaux plutôt que les seuls contrôles techniques, les RSSI et les responsables IT peuvent atténuer les risques présents dans les zones les plus difficiles d’accès de leur écosystème.

Exploiter l’intelligence avancée pour renforcer les opérations de sécurité face aux menaces héritées

Les outils d’intelligence basés sur l’IA et les analyses avancées des menaces offrent aux organisations un avantage nouveau pour détecter, analyser et contrer, à grande échelle, les abus de protocoles hérités. Ces plateformes utilisent l’apprentissage automatique pour repérer les comportements d’authentification anormaux, filtrer rapidement les usages suspects des protocoles hérités et remédier automatiquement aux menaces, sans délai de traitement humain.

Les équipes modernes de sécurité des opérations intègrent les données de Microsoft Sentinel, de Purview Audit et des analyses comportementales pilotées par l’IA afin de construire une vue centralisée de l’activité d’authentification, qu’elle soit moderne ou héritée. Les playbooks automatisés peuvent déclencher des réponses en cas d’exception à une stratégie, de comptes de service à haut risque ou d’événements de relais d’identifiants, et combler les failles avant que les attaquants ne puissent les exploiter.

Intégrer l’automatisation et l’analyse n’est pas une option : c’est une nécessité. Les plateformes d’orchestration aident à unifier les données entre les environnements cloud, sur site et hybrides, et garantissent que même les flux d’authentification hérités les moins visibles ne passent pas inaperçus. C’est d’autant plus critique que les agents IA et les automatisations à grande échelle se multiplient, ce qui accroît à la fois les bénéfices et les risques opérationnels.

Enfin, l’application d’un accès selon le principe du moindre privilège, l’étiquetage des contenus sensibles et l’extension de la surveillance des audits permettent de garder le contrôle sur les utilisateurs humains comme sur les comptes machines. Pour un guide pratique d’utilisation de l’analyse avancée et de l’IA afin de contenir les menaces héritées dans les environnements Microsoft, y compris Copilot et les bots tiers, consultez ce guide détaillé sur l’IA gouvernée et la conformité.