Sécuriser un réseau de zone démilitarisée (DMZ) avec l’authentification multifacteur (MFA)

Bien que chaque ressource réseau constitue une cible potentielle pour les hackers, il est de notoriété publique que, dans les réseaux on-premise, certaines présentent un risque de sécurité plus élevé que d’autres. Nous expliquons ici comment mettre en place l’authentification dans une DMZ et pourquoi la sécurisation d’une DMZ avec l’authentification multifacteur (MFA) est autant une question d’art que de science.

Une zone démilitarisée (DMZ) est un sous-réseau qui héberge des services exposés au public et qui est isolé du reste du réseau, ajoutant ainsi une couche de protection contre les attaques externes. Si les serveurs situés dans la DMZ sont compromis, les attaquants ne peuvent pas facilement s’en servir comme point d’appui pour pénétrer plus profondément dans le réseau.

Dans tout réseau, les serveurs les plus exposés sont ceux qui, par nature, doivent être accessibles depuis l’extérieur, comme les serveurs DNS, web et de messagerie.

Cela implique d’autoriser le trafic à atteindre ces serveurs depuis l’extérieur du réseau à travers le pare-feu, par exemple le trafic web HTTPS sur le port 443. Même si les ports publics sont toujours gérés avec soin, tout accès depuis l’extérieur représente un risque potentiel que des attaquants pourraient exploiter.

Une façon de réduire ce risque consiste à déployer une DMZ.

Cependant, les administrateurs doivent toujours gérer les serveurs de la DMZ, ce qui implique d’y accéder via un port interne. Évidemment, comme pour tout accès à privilèges, celui-ci doit être sécurisé à l’aide de mécanismes plus robustes qu’un simple mot de passe.

L’approche recommandée consiste à mettre en œuvre une authentification multifacteur forte. Mais comme les réseaux DMZ sont par nature isolés, la mise en place de la MFA peut s’avérer complexe.

La MFA nécessite une infrastructure dédiée ainsi qu’une intégration avec le contrôleur de domaine Active Directory (AD) sur site, situé en dehors de la DMZ, afin que l’authentification puisse avoir lieu.

Conçue spécifiquement pour résoudre les problématiques de MFA et de contrôle d’accès en environnement sur site, la MFA UserLock pour Active Directory propose une solution simple sur un seul serveur, sans nécessiter d’infrastructure supplémentaire.

Cela signifie que les contrôles MFA de l’organisation pour la DMZ peuvent être gérés depuis la même console que celle utilisée pour définir les politiques d’accès d’autres types de sessions, comme la MFA pour VPN, RDP et IIS.

La DMZ peut ainsi rester isolée tout en permettant une authentification forte, sur site.

L’une des techniques les plus simples pour sécuriser un réseau consiste à le diviser en réseaux ou sous-réseaux plus petits. Ainsi, si un attaquant compromet une ressource dans un sous-réseau, il est empêché de se déplacer latéralement vers d’autres ressources grâce à un ensemble de pare-feu séparant ces sous-réseaux.

Inévitablement, cette approche est plus complexe à administrer — elle nécessite généralement davantage de pare-feu ou des pare-feu plus puissants — mais elle en vaut la peine au regard du gain en sécurité. Le concept de zone démilitarisée (DMZ) en réseau est en réalité une version spécialisée de cette même idée.

La DMZ héberge des serveurs qui doivent être accessibles depuis l’extérieur du réseau, ce qui les rend plus susceptibles d’être attaqués. Mais en les plaçant dans un sous-réseau DMZ, vous isolez ces machines à haut risque du reste du réseau. Ainsi, si une ressource de la DMZ est attaquée, toute compromission reste contenue dans la DMZ et ne peut pas se propager.

À l’image de la célèbre zone démilitarisée qui sépare la Corée du Nord et la Corée du Sud, une DMZ réseau constitue un tampon qui protège le reste du réseau à la fois de ce qui se trouve à l’intérieur de la DMZ et du monde extérieur.

Comme le suggère la description ci-dessus, une DMZ de base nécessite au minimum deux pare-feu : l’un pour protéger la DMZ contre les attaques externes, et un second pour protéger le réseau principal contre la DMZ. Mais le concept de DMZ peut être appliqué de manière plus complexe, notamment dans les réseaux de technologies opérationnelles (OT).

Les réseaux OT sont déjà des réseaux au sein des réseaux, qui doivent être isolés à la fois du monde extérieur et du réseau informatique interne. Ils sont souvent considérés comme totalement isolés afin de les protéger des cyberattaques. En réalité, les besoins de gestion à distance font que les réseaux OT sont fréquemment configurés de manière similaire aux réseaux IT. Certaines de leurs ressources doivent être accessibles publiquement, comme les systèmes SCADA, les automates programmables (PLC) et d’autres capteurs d’équipements.

Mais, comme pour un réseau IT, cela augmente les risques d’attaque et de compromission, ce qui explique pourquoi ces systèmes sont souvent placés dans une DMZ OT. Il est même possible qu’un grand réseau OT comporte plusieurs DMZ réparties sur différents sites.

Si le concept de DMZ comporte un inconvénient, il réside probablement dans la gestion et la sécurité. Les administrateurs doivent évidemment pouvoir gérer les serveurs situés dans la DMZ, ce qui implique un accès via un port du pare-feu.

Ouvrir une connexion peut sembler contredire l’objectif même d’une DMZ, qui est de protéger le réseau interne contre les mouvements latéraux. En pratique, tout dépend généralement du sens de la connexion : le réseau interne doit pouvoir se connecter à la DMZ, mais les connexions dans l’autre sens doivent être strictement contrôlées.

Une connexion administrateur vers les serveurs de la DMZ est extrêmement sensible, ce qui explique pourquoi la MFA est aujourd’hui un contrôle de sécurité recommandé. Toutefois, sa mise en œuvre confronte les administrateurs à un choix.

• L’approche recommandée consiste à conserver le serveur d’authentification MFA en dehors de la DMZ. Si l’organisation dispose déjà d’une plateforme MFA on-premise ou utilise un fournisseur MFA externe, cette solution est pratique mais peut entraîner une latence supplémentaire, problématique pour certaines applications.

• Une option moins conventionnelle consiste à placer le serveur d’authentification à l’intérieur de la DMZ. Cela permet une MFA transparente, mais le serveur MFA lui-même est évidemment plus exposé aux risques. Cette approche nécessite également une connexion à une forêt Active Directory dédiée, reliée par une relation d’approbation unidirectionnelle au contrôleur de domaine AD principal.

Dans tous les cas, le déploiement de la MFA requiert toujours une infrastructure supplémentaire, ce qui ajoute de la complexité à la gestion du réseau.

Ces scénarios mettent en évidence une autre subtilité des DMZ : toutes les DMZ ne se valent pas.

Certaines sont très strictement contrôlées et peuvent tolérer l’installation de la MFA à l’intérieur de la DMZ. D’autres, au contraire, privilégieront l’approche classique consistant à placer le serveur MFA à l’extérieur de la DMZ.

UserLock simplifie la mise en œuvre de la sécurité MFA et du contrôle d’accès pour les administrateurs gérant des réseaux on-premise, la DMZ en étant un exemple particulier. Il n’en reste pas moins que la sécurité des DMZ impose souvent des compromis difficiles, pouvant entraîner un niveau de sécurité inférieur et une complexité accrue.

UserLock, en tant que solution sur un seul serveur, réduit la complexité et offre une plus grande flexibilité en matière de gestion sécurisée. Par exemple, lorsqu’il est installé en dehors de la DMZ, UserLock peut sécuriser les ressources situées dans la DMZ avec la MFA via UserLock Anywhere. Cela fonctionne en déployant un service web IIS dans la DMZ, qui communique de manière sécurisée avec UserLock via Internet, en utilisant le port SMB 445 de partage de fichiers et d’imprimantes Microsoft (des connexions distinctes sont ouvertes dans le pare-feu pour l’authentification Windows vers le contrôleur de domaine sur les ports 389 et 3268).

Grâce à cette approche, UserLock évite de devoir placer le processus d’authentification à l’intérieur de la DMZ, où il présenterait un risque accru.

Une entreprise du secteur de l’énergie a mis en place une DMZ afin d’isoler ses serveurs publics de son réseau OT, dans le but de répondre à des exigences réglementaires et de conformité, notamment la mise en œuvre de la MFA pour les accès d’administration depuis le réseau IT principal vers la DMZ.

La plupart des solutions étudiées par l’équipe IT ajoutaient de la complexité et des coûts à une infrastructure réseau déjà complexe. Avec UserLock, l’équipe a pu éviter cela et déployer la MFA pour les accès à la DMZ en quelques heures.

UserLock propose plusieurs méthodes de MFA, telles que les notifications push et les jetons, mais l’entreprise a opté pour des codes TOTP via une application d’authentification intégrée à l'authentification unique (SSO), comme solution la plus simple.