NIS 2 : pourquoi la connexion à Windows reste l’angle mort de vos accès

La directive NIS 2 impose des exigences strictes en matière de sécurité des réseaux, mais la majorité des organisations sous-estiment la surface d'attaque représentée par l'authentification locale Windows. Contrairement aux applications SaaS modernes, le domaine Active Directory (AD) ne n'offre pas nativement de mécanisme d'authentification multifacteur (MFA) robuste pour les connexions interactives, créant un vide de sécurité critique.

En bref

• Le problème : L'authentification Windows classique repose sur des mots de passe statiques, vulnérables aux attaques par pass-the-hash et au vol de tickets Kerberos, sans option MFA native intégrée au protocole NTLM/Kerberos.
• L'exigence NIS 2 : Bien que la directive ne nomme pas explicitement "MFA Windows", elle exige des mesures proportionnées pour protéger les systèmes d'information contre les menaces cyber, incluant la gestion des identités et des accès. Le MFA est désormais considéré comme une mesure de sécurité de base pour les acteurs essentiels et importants.
• La contrainte technique : Forcer le MFA directement dans l'AD via des GPO est techniquement complexe, peu flexible et souvent non compatible avec les applications héritées ou les agents de gestion d'entreprise.
• La solution agile : L'approche recommandée est l'interception de l'authentification via un proxy d'accès (comme Specops Secure Access), permettant d'ajouter du MFA sans modifier l'AD ni déployer d'agents lourds.
• L'enjeu opérationnel : Sécuriser les accès Windows sans impacter la productivité des utilisateurs ni casser les intégrations existantes est le défi principal des consultants IT face à NIS 2.

La faiblesse structurelle de l'authentification Windows

Pour comprendre pourquoi le MFA est indispensable, il faut d'abord analyser la mécanique de l'authentification Windows. Que ce soit via le protocole NTLM (plus ancien, basé sur le challenge-response) ou Kerberos (plus moderne, basé sur les tickets), le fondement reste le même : la connaissance d'un secret partagé, c'est-à-dire le mot de passe.

Dans un environnement d'entreprise, ce modèle présente trois vulnérabilités majeures :

1. La réversibilité partielle et le stockage local : Les hachés de mots de passe sont stockés dans la base SAM (Local) ou dans la base AD (NTDS.dit). Un attaquant disposant d'un privilège élevé peut extraire ces hachés et les utiliser pour des attaques pass-the-hash ou pass-the-ticket.
2. L'absence de preuve d'identité forte : Le fait de connaître le mot de passe ne prouve pas que la personne qui le saisit est bien l'utilisateur légitime, surtout si le mot de passe a été compromis via un phishing ou un keylogger.
3. La rigidité des politiques : Les stratégies de groupe (GPO) permettent de forcer des changements de mot de passe, mais elles ne peuvent pas imposer une seconde étape d'authentification de manière granulaire et contextuelle (par exemple, uniquement pour les accès distants ou les sessions RDP).

L'approche traditionnelle consistant à ajouter du MFA via des solutions d'entreprise (comme Microsoft Entra ID Protection pour les accès web) ne couvre pas les connexions directes au bureau, les sessions RDP, ou les accès via des applications héritées qui s'appuient sur l'authentification intégrée Windows (IWA). C'est ici que réside l'angle mort : si un attaquant obtient un accès initial (par exemple via un phishing), il peut se déplacer latéralement dans le réseau en utilisant les tickets Kerberos volés, sans jamais être confronté à une demande de MFA.

NIS 2 : ce que la directive impose réellement sur la gestion des identités

La directive NIS 2 (Network and Information Systems) est une évolution majeure de la précédente NIS 1. Elle élargit le périmètre d'application à de nouveaux secteurs (logistique, production chimique, banques, etc.) et renforce les obligations de sécurité.

Les exigences clés pour les consultants IT

Bien que NIS 2 soit une directive européenne et non une norme technique de détail, elle s'appuie sur des lignes directrices (comme celles de l'ENISA et du CSIRT) qui convergent vers des exigences concrètes :

• Mesures de sécurité proportionnées : Les organisations doivent mettre en œuvre des mesures techniques et organisationnelles proportionnées au risque. Pour les systèmes critiques, le MFA est de plus en plus cité comme une mesure "de base" ou "attendue".
• Gestion des identités et des accès : Il est exigé d'assurer la séparation des rôles, la revue périodique des accès, et la sécurisation des accès à distance.
• Réponse aux incidents : La capacité à détecter et répondre aux compromissions d'identités est un point central.

Le MFA est-il explicitement obligatoire ?

La nuance est importante. NIS 2 n'utilise pas le terme "MFA" de manière absolue dans tous les cas, mais elle exige que les mesures de sécurité soient efficaces et adaptées aux menaces actuelles. Dans le contexte des audits de conformité (ISO 27001, Cybersecurity Act 1.0), l'absence de MFA sur les accès à des systèmes d'information critiques est généralement considérée comme une non-conformité majeure.

Pour un consultant IT, la question n'est plus si le MFA doit être déployé, mais comment le déployer de manière effective sur l'infrastructure Windows sans casser l'expérience utilisateur.

Pourquoi les approches natives (GPO/AD) sont insuffisantes

De nombreuses organisations tentent de résoudre ce problème en s'appuyant uniquement sur les fonctionnalités natives d'Active Directory. Voici pourquoi cette approche est souvent insuffisante pour répondre aux exigences de sécurité moderne et de NIS 2 :

1. L'absence de MFA natif dans l'AD

Active Directory ne possède pas de protocole d'authentification multifacteur intégré. Les mécanismes disponibles (comme SmartCards ou les certificats) sont des facteurs "possession" ou "héritage", mais ils ne constituent pas un MFA au sens moderne (combinaison de connaissance + possession + biométrie, ou connaissance + possession). De plus, la gestion des certificats est complexe et coûteuse à maintenir à grande échelle.

2. La rigidité des stratégies de groupe (GPO)

Les GPO permettent de définir des politiques de mot de passe (longueur, complexité, expiration), mais elles ne permettent pas d'intercepter la session d'authentification pour demander un code à usage unique (OTP) ou une notification push. Pour contourner cela, il faudrait déployer des agents sur chaque poste client, ce qui augmente la surface d'attaque et la complexité de maintenance.

3. L'incompatibilité avec les applications héritées

De nombreuses applications d'entreprise (ERP, CRM, outils internes) s'appuient sur l'authentification intégrée Windows (NTLM/Kerberos). Si vous imposez un MFA via un agent client, vous risquez de casser ces intégrations. Si vous utilisez un SSO (Single Sign-On) basé sur des certificats, la configuration est lourde et peu flexible.

L'approche non invasive : le proxy d'accès MFA

La solution la plus robuste et la plus alignée avec les bonnes pratiques de sécurité moderne est l'utilisation d'un proxy d'accès qui s'interpose entre l'utilisateur et le serveur Windows. Cette approche permet d'ajouter du MFA sans modifier l'infrastructure AD ni déployer d'agents sur les postes clients.

Principe de fonctionnement

1. Interception de la requête : L'utilisateur tente de se connecter à une ressource Windows (RDP, Web, application héritée).
2. Redirection vers le proxy : La requête est redirigée vers le serveur de proxy d'accès.
3. Vérification initiale : Le proxy vérifie les identifiants Windows (via AD/LDAP).
4. Déclenchement du MFA : Si la politique le requiert (basée sur le risque, la localisation, l'appareil), le proxy demande un second facteur (SMS, App, Push, WebAuthn).
5. Création d'une session sécurisée : Une fois le MFA validé, le proxy crée une session chiffrée et authentifiée vers le serveur cible. L'utilisateur accède à la ressource comme si s'était connecté localement, mais avec une couche de sécurité supplémentaire.

Avantages pour les consultants IT

• Transparence pour les applications : Les applications héritées ne voient qu'une authentification Windows standard. Le MFA est géré au niveau du proxy.
• Gestion centralisée : Les politiques de MFA sont gérées dans une console unique, indépendamment de l'AD.
• Auditabilité : Chaque tentative d'accès, y compris les échecs de MFA, est journalisée dans une base de données centralisée, facilitant la réponse aux exigences de NIS 2 en matière de logging.
• Flexibilité : Possibilité d'appliquer le MFA conditionnel (par exemple, obligatoire pour les accès distants, optionnel pour les accès locaux de confiance).

Déploiement de Specops Secure Access : cas d'usage

Specops Secure Access est une solution de ce type qui permet d'ajouter du MFA à l'Active Directory sans modifications invasives. Voici comment un consultant IT peut structurer le déploiement :

1. Analyse du périmètre critique

Identifiez les ressources les plus sensibles :

• Serveurs RDP exposés (internes ou externes).
• Portails web internes (SharePoint, IIS).
• Applications héritées sensibles aux fuites de données.

2. Configuration des politiques de MFA

Dans la console de gestion, définissez des règles basées sur :

• L'utilisateur : Administrateurs, financeurs, RH.
• La ressource : Serveurs critiques, bases de données.
• Le contexte : IP d'accès, type d'appareil, niveau de risque.

Exemple de règle logique :

SI (Utilisateur = "Administrateurs") ET (Ressource = "Serveur DC01")
ALORS Exiger MFA (App Push + Code SMS)

3. Intégration avec l'AD

Le proxy s'authentifie auprès du contrôleur de domaine pour vérifier les identifiants. Il n'est pas nécessaire de modifier les objets utilisateurs dans l'AD. Vous pouvez mapper les groupes AD aux rôles de sécurité dans la console du proxy.

4. Gestion des exceptions et secours

Il est crucial de mettre en place un mécanisme de secours (back-up codes) en cas d'indisponibilité du serveur MFA ou de perte du téléphone par l'utilisateur. Specops Secure Access permet de générer des codes à usage unique de secours pour chaque utilisateur.

Bonnes pratiques pour consultants IT

Pour garantir une conformité NIS 2 effective et une expérience utilisateur fluide, suivez ces recommandations :

1. Commencez par les accès à risque élevé : Ne déployez pas le MFA sur toutes les applications immédiatement. Priorisez les accès RDP, les portails web critiques et les comptes à privilèges.
2. Utilisez le MFA adaptatif : Exploitez les signaux de contexte (localisation, appareil connu, comportement) pour réduire la friction. Évitez de demander du MFA pour chaque connexion locale sur un poste de travail de confiance.
3. Documentez les procédures de secours : Assurez-vous que les équipes support IT savent comment réinitialiser les méthodes MFA et fournir des codes de secours.
4. Surveillez les journaux : Activez l'alerting sur les échecs répétés de MFA ou les tentatives d'accès depuis des IP inconnues. Ces signaux sont essentiels pour la détection des menaces.
5. Testez les scénarios de failover : Vérifiez que l'infrastructure MFA est tolérante aux pannes (réplication des serveurs proxy, redondance des canaux de notification).
6. Sensibilisez les utilisateurs : Communiquez clairement sur les raisons du MFA (sécurité, conformité) et formez-les à l'utilisation de leur application MFA.

Points clés

• NIS 2 élève la barre : Le MFA n'est plus une option, mais une attente de sécurité de base pour les acteurs essentiels et importants. L'absence de MFA sur les accès Windows est une vulnérabilité majeure.
• L'AD seul ne suffit pas : Active Directory ne n'offre pas de MFA natif flexible. Les approches basées sur les GPO sont rigides et souvent insuffisantes pour couvrir tous les scénarios d'attaque.
• Le proxy d'accès est la solution agile : Des outils comme Specops Secure Access permettent d'ajouter du MFA de manière non invasive, en s'interposant entre l'utilisateur et la ressource, sans casser les applications héritées.
• La gestion du contexte est cruciale : Un MFA efficace est un MFA adaptatif. Il doit être déclenché en fonction du risque, de la localisation et de l'importance de la ressource, pour équilibrer sécurité et productivité.
• L'audit et la supervision : Les journaux centralisés du proxy sont un actif précieux pour la conformité NIS 2 et la détection des incidents de sécurité.

En conclusion, la connexion Windows reste un angle mort majeur de la sécurité des entreprises. En adoptant une approche non invasive via un proxy d'accès MFA, les consultants IT peuvent répondre aux exigences de NIS 2 tout en préservant la stabilité et la productivité des opérations IT. C'est une investissement stratégique pour sécuriser l'infrastructure sans réinventer la roue.

Source : IT Connect