L’authentification multifacteur (MFA) est depuis longtemps devenue une pratique de s\u00e9curit\u00e9 standard. Avec un large consensus sur sa capacit\u00e9 \u00e0 repousser plus de 99 % des attaques de prise de contr\u00f4le de compte, il n’est pas \u00e9tonnant que les architectes de s\u00e9curit\u00e9 le consid\u00e8rent comme un incontournable dans leurs environnements. Cependant, ce qui semble moins connu, ce sont les limites de couverture inh\u00e9rentes aux solutions MFA traditionnelles. Bien que compatible avec la connexion RDP et les connexions de bureau locales, ils n’offrent aucune protection aux outils d’acc\u00e8s \u00e0 distance en ligne de commande tels que PsExec, Remote PowerShell et autres.<\/strong><\/p>\n En pratique, cela signifie que les postes de travail et les serveurs restent aussi vuln\u00e9rables aux mouvements lat\u00e9raux, \u00e0 la propagation des ransomwares et aux autres menaces d’identit\u00e9 malgr\u00e9 la pr\u00e9sence d’une solution MFA enti\u00e8rement fonctionnelle. Pour l’adversaire, il suffit de prendre le chemin de la ligne de commande au lieu du RDP pour se connecter comme s’il n’y avait aucune protection install\u00e9e. Dans cet article, nous allons explorer cet angle mort, comprendre sa cause profonde et ses implications, et voir les diff\u00e9rentes options que les \u00e9quipes de s\u00e9curit\u00e9 peuvent surmonter pour maintenir la protection de leurs environnements. <\/p>\n MFA la mesure de s\u00e9curit\u00e9 la plus efficace \u00e0 nouveau la prise de contr\u00f4le de compte. La raison pour laquelle nous avons MFA en premier lieu pour emp\u00eacher les adversaires d’acc\u00e9der \u00e0 nos ressources avec des informations d’identification compromises. Ainsi, m\u00eame si un attaquant pouvait s’emparer de notre nom d’utilisateur et de notre mot de passe – ce qui est un sc\u00e9nario plus que plausible – il ne pourra toujours pas les exploiter pour un acc\u00e8s malveillant en notre nom. C’est donc la derni\u00e8re ligne de d\u00e9fense ultime contre la compromission des informations d’identification, qui vise \u00e0 annuler ce compromis de tout gain. <\/p>\n Bien que MFA puisse couvrir enti\u00e8rement l’acc\u00e8s aux applications SaaS et Web, il est beaucoup plus limit\u00e9 en ce qui concerne l’environnement g\u00e9r\u00e9 par Active Directory. En effet, les principaux protocoles d’authentification utilis\u00e9s dans cet environnement, NTLM et Kerberos, ont \u00e9t\u00e9 \u00e9crits bien avant l’existence de MFA et ne le prennent pas en charge de mani\u00e8re native. Cela signifie que chaque m\u00e9thode d’authentification qui impl\u00e9mente ces protocoles ne peut pas \u00eatre prot\u00e9g\u00e9e par MFA. Cela inclut tous les outils d’acc\u00e8s \u00e0 distance bas\u00e9s sur CMD et PowerShell, dont les plus importants sont PsExec et Remote PowerShell. Ce sont les outils par d\u00e9faut que l’administrateur utilise pour se connecter \u00e0 distance aux machines des utilisateurs \u00e0 des fins de d\u00e9pannage et de maintenance, et se trouvent donc dans pratiquement tous les environnements AD. <\/p>\n Ce chemin de connexion \u00e0 distance grand public n’est, par d\u00e9finition, pas prot\u00e9g\u00e9 contre un sc\u00e9nario d’informations d’identification compromises et, par cons\u00e9quent, il est utilis\u00e9 dans la plupart des attaques de mouvement lat\u00e9ral et de propagation de ransomware. Peu importe qu’il existe une solution MFA qui prot\u00e8ge la connexion RDP et les emp\u00eache d’\u00eatre abus\u00e9s. Pour un attaquant, passer de la machine patient z\u00e9ro \u00e0 d’autres postes de travail dans l’environnement avec PsExec ou Remote PowerShell est aussi simple qu’avec RDP. C’est juste une question d’utiliser une porte au lieu de l’autre. <\/p>\n \u00cates-vous aussi prot\u00e9g\u00e9 que vous devriez l’\u00eatre ? Il est peut-\u00eatre temps pour vous de r\u00e9\u00e9valuer votre MFA. En guise de suivi, explorez cet eBook pour apprendre<\/b><\/a> en savoir plus sur l’approche de protection unifi\u00e9e de l’identit\u00e9 de Silverfort en mati\u00e8re de MFA et d\u00e9couvrez comment \u00e9valuer vos protections existantes et l’exposition relative aux risques.<\/p>\n<\/div>\n Ainsi, si vous avez eu la peine d’installer des agents MFA sur tous vos serveurs et postes de travail critiques, il y a de fortes chances que vous n’ayez pas r\u00e9ussi \u00e0 les prot\u00e9ger des menaces d’identit\u00e9. C’est l’un des cas o\u00f9 vous ne pouvez pas faire la moiti\u00e9 du chemin. C’est soit vous \u00eates prot\u00e9g\u00e9, soit vous ne l’\u00eates pas. Quand il y a un trou dans le fond du bateau, peu importe que tout le reste soit en bois massif. Et de la m\u00eame mani\u00e8re, si les attaquants peuvent se d\u00e9placer lat\u00e9ralement dans votre environnement en fournissant des informations d’identification compromises aux outils d’acc\u00e8s \u00e0 la ligne de commande, il n’est plus important que vous disposiez d’une protection MFA pour RDP et la connexion au bureau. <\/p>\n Malgr\u00e9 le passage au cloud, plus de 90\u00a0% des organisations maintiennent une infrastructure d’identit\u00e9 hybride avec \u00e0 la fois des stations de travail et des serveurs g\u00e9r\u00e9s par AD, ainsi que des applications SaaS et des charges de travail cloud. Ainsi, non seulement les principales ressources sur site telles que les applications h\u00e9rit\u00e9es et les partages de fichiers sont expos\u00e9es \u00e0 l’utilisation d’informations d’identification compromises en raison de l’absence de protection MFA, mais \u00e9galement les applications SaaS. <\/p>\n La pratique courante aujourd’hui consiste \u00e0 synchroniser les mots de passe entre toutes ces ressources, de sorte que le m\u00eame nom d’utilisateur et le m\u00eame mot de passe sont utilis\u00e9s pour acc\u00e9der \u00e0 la fois \u00e0 un serveur de fichiers sur site et \u00e0 une application SaaS organisationnelle. Cela signifie que toute attaque sur site qui inclut la compromission et l’utilisation des informations d’identification des utilisateurs peut facilement pivoter pour acc\u00e9der aux ressources SaaS directement \u00e0 partir des machines attaqu\u00e9es.<\/p>\n L’\u00e9cart que nous avons d\u00e9crit d\u00e9coule de la fa\u00e7on dont l’authentification MFA traditionnelle est con\u00e7ue et mise en \u0153uvre. La principale limitation est que les solutions MFA d’aujourd’hui se connectent au processus d’authentification de chaque ressource individuelle, donc si le logiciel qui effectue cette authentification ne prend pas en charge la MFA – comme dans les outils d’acc\u00e8s \u00e0 la ligne de commande AD – il ne peut y avoir de protection \u00e0 blanc.<\/p>\n Cependant, il existe aujourd’hui une nouvelle approche qui d\u00e9place l’attention de placer MFA sur chaque ressource individuelle vers le r\u00e9pertoire, surmontant ainsi compl\u00e8tement la barri\u00e8re.<\/p>\n Silverfort est le pionnier de la premi\u00e8re plate-forme de protection unifi\u00e9e de l’identit\u00e9 qui peut \u00e9tendre la MFA \u00e0 n’importe quelle ressource, qu’elle prenne en charge nativement la MFA ou non. Utilisant une technologie sans agent et sans proxy, Silverfort s’int\u00e8gre directement \u00e0 AD. Avec cette int\u00e9gration, chaque fois qu’AD re\u00e7oit une demande d’acc\u00e8s, il attend son verdict et le transmet \u00e0 Silverfort. Silverfort analyse ensuite la demande d’acc\u00e8s et, si n\u00e9cessaire, d\u00e9fie l’utilisateur avec MFA. Sur la base de la r\u00e9ponse de l’utilisateur, Silverfort d\u00e9termine s’il faut ou non faire confiance \u00e0 l’utilisateur et transmet le verdict \u00e0 AD qui accorde ou refuse l’acc\u00e8s, respectivement. <\/p>\n L’innovation dans cette approche est qu’il n’a plus d’importance si cette demande d’acc\u00e8s a \u00e9t\u00e9 faite via RDP ou en ligne de commande et si elle prend en charge MFA ou non. Tant qu’il a \u00e9t\u00e9 fait \u00e0 AD, AD peut le passer \u00e0 Silverfort. Ainsi, en passant de la protection MFA au niveau des ressources \u00e0 la protection MFA au niveau du r\u00e9pertoire, l’angle mort dont les adversaires abusent depuis des ann\u00e9es est enfin r\u00e9solu et s\u00e9curis\u00e9. <\/p>\n Vous souhaitez en savoir plus sur la mani\u00e8re d’appliquer la MFA \u00e0 toutes vos ressources\u00a0? Rendez-nous visite au https:\/\/www.silverfort.com\/<\/a> <\/p>\n <\/p>\nL’objectif principal de MFA\u00a0: emp\u00eacher les adversaires d’acc\u00e9der \u00e0 vos ressources avec des informations d’identification compromises <\/h2>\n
L’angle mort\u00a0: MFA n’est pas pris en charge par les outils d’acc\u00e8s \u00e0 la ligne de commande dans l’environnement Active Directory<\/h2>\n
Les implications en mati\u00e8re de cybers\u00e9curit\u00e9\u00a0: les mouvements lat\u00e9raux et les attaques de ransomware ne rencontrent aucune r\u00e9sistance. <\/h2>\n
La dure v\u00e9rit\u00e9\u00a0: une protection MFA partielle n’est pas une protection du tout<\/h2>\n
Les limitations MFA dans l’environnement sur site mettent \u00e9galement vos ressources cloud en danger<\/h2>\n
Le changement de paradigme\u00a0: de la MFA traditionnelle \u00e0 la protection unifi\u00e9e de l’identit\u00e9 <\/h2>\n