Accès Direct versus VPN : Ils ne sont pas les mêmes

Introduction

L’une des parties les plus intéressantes de mon travail est la correspondance que je reçois des lecteurs détaillant leurs propres scénarios et questions. J’entends souvent des gens qui veulent remplacer leurs solutions VPN actuelles par DirectAccess. Bien que je sois toujours heureux d’entendre que les gens pensent à déployer DirectAccess (en partie parce que mon mari travaille avec UAG DirectAccess et que cette nouvelle le rend heureux), je dois leur rappeler que même si DirectAccess a de nombreuses caractéristiques qui pourraient vous faire penser à un VPN, DirectAccess n’est pas un VPN. En fait, c’est beaucoup plus. Une façon de comprendre en quoi le client DirectAccess diffère du client VPN est de le mettre en perspective avec d’autres types de clients sur votre réseau et d’examiner les problèmes de connectivité et de sécurité qui sont importants pour chacun de ces types de clients.

Types de clients

Pour commencer cette discussion, supposons qu’il existe trois types généraux de clients qui sont membres du domaine et sont sous votre contrôle administratif. Chacun des types de clients serait considéré comme un » client géré » dans une plus ou moins grande mesure:

Le client corpnet » boulonné »
Le client VPN d’accès distant itinérant
Le client DirectAccess

Le client Corpnet « boulonné »

Le client corpnet « boulonné » est un système qui peut ou non être littéralement boulonné, mais de toute façon, il ne quitte jamais l’intranet de l’entreprise. Ce système est membre du domaine, est un système toujours géré et n’est jamais exposé à d’autres réseaux. Son accès à Internet est toujours contrôlé par un pare-feu d’inspection de la couche applicative, tel qu’un pare-feu TMG. Les emplacements USB et autres supports amovibles sont verrouillés administrativement ou physiquement et l’accès physique au bâtiment où il réside n’est autorisé qu’aux employés et aux invités escortés. Ces systèmes ont un logiciel anti-malware installé, sont configurés via une stratégie de groupe ou un autre système de gestion pour maintenir la configuration de sécurité souhaitée, et la protection d’accès au réseau (NAP) est activée sur le réseau afin d’empêcher les systèmes indésirables de se connecter au réseau et d’accéder aux ressources de l’entreprise. Le pare-feu Windows avec sécurité avancée est activé et configuré pour réduire le risque de menaces introduites par les vers réseau.

Ce concept de client corpnet » boulonné » se rapproche autant que l’on peut l’imaginer de l’idéal de client sécurisé:

Le système n’est jamais exposé à des réseaux non fiables.
Le système est toujours géré.
Le système est toujours sous le contrôle de l’informatique d’entreprise.
L’accès au système est limité aux employés et aux invités accompagnés.
» L’accès hors bande » au système est limité car les ports pour les supports amovibles sont handicapés administrativement ou physiquement.
Un pare-feu Internet d’inspection de la couche d’application tel que TMG empêche les utilisateurs de télécharger des exploits depuis Internet.
NAP réduit les risques de connexion de clients non gérés au réseau et de propagation de logiciels malveillants obtenus à partir d’autres réseaux.
Il est peu probable que le système soit volé en raison des mesures physiques prises pour « connecter » le client à l’infrastructure physique.

Alors que vous pourriez imaginer que c’est le système idéal en termes de sécurité du réseau, dans quelle mesure cette caractérisation est-elle réaliste? Combien de systèmes clients avez-vous maintenant qui ne quittent jamais le corpnet? Et même avec ces contrôles en place, à quel point ces machines sont-elles immunisées contre les attaques? Considérez ce qui suit:

L’ingénierie sociale est une méthode courante qui permet aux attaquants d’accéder physiquement à des machines spécifiquement ciblées afin que les logiciels malveillants et les chevaux de Troie puissent être installés sur des clients corpnet « boulonnés ».
Même avec des ports physiques désactivés, il est probable que les utilisateurs auront accès à au moins un lecteur optique – auquel cas les logiciels malveillants obtenus à partir d’un site extérieur peuvent potentiellement se retrouver sur le client corpnet « boulonné ».
Alors qu’un pare-feu d’inspection de la couche d’application peut grandement empêcher les logiciels malveillants et les chevaux de Troie d’entrer dans le corpnet, si le pare-feu n’effectue pas d’inspection SSL sortante (HTTPS), cela ne vaut essentiellement rien, car les chevaux de Troie peuvent utiliser le canal SSL sécurisé (et non inspecté) pour atteindre leurs contrôleurs. De plus, les utilisateurs peuvent profiter de proxy anonymes via une connexion SSL inattendue.
Si un cheval de Troie était installé sur le client corpnet « boulonné », un cheval de Troie bien écrit utiliserait HTTP ou SSL pour se connecter à son contrôleur et très probablement se connecter à un site qui n’a pas encore été classé comme « dangereux ». Même si l’organisation utilisait une approche de sécurité « liste blanche », l’attaquant pourrait détourner un « site sûr » à profil bas (peut-être avec un empoisonnement DNS) et demander au cheval de Troie de se connecter à ce site afin qu’il puisse recevoir des commandes de contrôle.
Les utilisateurs peuvent essayer de contourner vos contrôles s’ils ne peuvent pas visiter les sites ou accéder aux ressources Internet qu’ils souhaitent. Si les utilisateurs utilisent des connexions sans fil, ils peuvent facilement se déconnecter du réseau sans fil d’entreprise et se connecter à un téléphone connecté pour accéder aux ressources bloquées par le pare-feu d’entreprise, puis se reconnecter au corpnet après avoir obtenu ce qu’ils veulent. Les utilisateurs avec une connexion sans fil ou filaire peuvent facilement brancher une « carte air » sans fil pour se connecter à un réseau non filtré et compromettre la machine via la passerelle alternative. Dans ce scénario, le client corpnet « boulonné » prend soudainement certaines des caractéristiques du client d’accès distant itinérant.

Le fait n’est pas que la diligence raisonnable en matière de sécurité est une leçon de futilité. Au lieu de cela, ce qui devrait être clair, c’est que même dans la situation idéale du client corpnet « boulonné », de nombreuses choses peuvent mal tourner et entraîner un incident de sécurité. Vous devez toujours tout faire pour vous assurer que vos machines sont sécurisées, à jour et bien gérées – mais vous devez mettre en perspective la comparaison de ces clients corpnet « isolés » et immobiles avec d’autres types de systèmes clients d’entreprise.

Enfin et peut-être le plus important, il convient de se demander si le concept de client corpnet « boulonné » ne peut présenter qu’un intérêt académique. Combien de ces clients existent aujourd’hui sur les réseaux d’entreprise – en particulier les réseaux où la majorité des employés sont des travailleurs du savoir? Dans un environnement de travail de tâches, vous pouvez considérer VDI comme une solution viable, car les tâches qu’ils effectuent ne nécessitent pas le large éventail de fonctionnalités fournies par un environnement PC complet, mais les travailleurs du savoir ont besoin de la flexibilité et de la puissance fournies par une plate-forme PC entièrement activée. De plus, de plus en plus d’entreprises reconnaissent les avantages du télétravail et de plus en plus d’employés travaillent à domicile ou se connectent au corpnet tout en étant sur la route. Ce qui nous amène à:

Le client VPN d’accès distant itinérant

Dans les années 1990, le client corpnet « boulonné » était la norme. Au cours de la deuxième décennie du 21e siècle, les travailleurs sont beaucoup plus mobiles et le client boulonné a cédé la place au client VPN d’accès distant itinérant. Les travailleurs du savoir ont de puissants ordinateurs portables qu’ils emmènent au travail, chez eux, sur les sites des clients, dans les hôtels, les conférences, les aéroports et partout ailleurs dans le monde où il y a une connexion Internet. Et dans de nombreux cas, après avoir été à un ou plusieurs de ces endroits, ils ramènent ces ordinateurs portables au corpnet.

Le client VPN d’accès distant itinérant présente un profil de menace très différent du client corpnet mythique » boulonné « . Comme le client corpnet « boulonné », ces machines sont membres du domaine, ont installé un logiciel anti-malware, ont activé le pare-feu Windows avec sécurité avancée et sont initialement configurées pour être entièrement conformes à la politique de sécurité de l’entreprise. L’ordinateur client VPN itinérant, lorsqu’il est livré pour la première fois à l’utilisateur, est aussi sécurisé que le client corpnet « boulonné « .

Cependant, cet état de configuration et de sécurité ne dure pas longtemps. L’utilisateur peut ne pas se connecter au corpnet via la connexion VPN pendant des jours ou des semaines. Ou l’utilisateur peut se connecter quotidiennement pendant une semaine ou deux, puis ne pas se connecter pendant quelques mois. Pendant l’intervalle, l’ordinateur client VPN itinérant tombe lentement mais sûrement hors de conformité. La stratégie de groupe n’est pas mise à jour, les mises à jour antivirus peuvent se terminer de manière irrégulière, d’autres logiciels anti-malware peuvent tomber à jour. Les contrôles de sécurité et de conformité qui sont imposés aux clients situés sur le corpnet peuvent ne jamais trouver leur chemin vers les clients VPN d’accès distant itinérants car ils ne parviennent pas à se connecter sur le VPN en temps opportun.

Le client VPN itinérant tombe de plus en plus hors de votre configuration de conformité de sécurité définie et le problème devient amplifié car la machine est connectée à un certain nombre de réseaux de confiance faible et inconnue. Ces réseaux non gérés ou mal gérés peuvent être remplis de vers de réseau et l’ordinateur peut être exposé à des utilisateurs qui ont un accès physique ou logique à l’ordinateur et qui n’auraient autrement pas accès à l’ordinateur s’il ne quittait jamais le corpnet.

Que se passe-t-il lorsque l’utilisateur ramène cet ordinateur qui n’est pas conforme au réseau de l’entreprise ? Et si l’ordinateur était compromis par des vers, des virus, des chevaux de Troie et d’autres formes de logiciels malveillants? Les dommages peuvent être limités si la protection d’accès au réseau est activée sur le réseau, mais combien de réseaux ont réellement activé NAP, même s’il est disponible depuis des années dans le cadre de la plate-forme Windows Server 2008 et supérieure?

Bien sûr, l’utilisateur n’aurait même pas besoin de ramener l’ordinateur compromis sur le réseau. Supposons que l’utilisateur ait connecté l’ordinateur à un certain nombre de réseaux différents, exposé l’ordinateur à un certain nombre d’utilisateurs de confiance inconnue et s’est retrouvé avec un ordinateur compromis. Ensuite, l’utilisateur doit changer son mot de passe après trois mois afin qu’il se connecte via VPN pour effectuer le changement de mot de passe. Les résultats de sécurité potentiellement désastreux seraient les mêmes que si l’ordinateur était effectivement retourné au réseau physique de l’entreprise.

Comme vous pouvez le voir, le client VPN itinérant souffre d’un certain nombre de problèmes de sécurité par rapport au client historique « boulonné »:

Le client VPN itinérant est connecté au corpnet de manière intermittente – ou parfois jamais – et tombe donc hors de portée de la stratégie de groupe et d’autres systèmes de gestion.
Le client VPN itinérant est exposé à des réseaux non gérés et mal gérés, ce qui augmente la « surface d’attaque » potentielle à laquelle le client VPN d’accès distant itinérant est exposé, par rapport à la machine qui ne quitte jamais le corpnet.
Les clients VPN itinérants peuvent accéder à Internet et les utilisateurs peuvent faire ce qu’ils veulent lorsqu’ils sont connectés à des sites Internet car il n’y a généralement pas de filtrage des connexions Internet lorsque le client VPN n’est pas connecté au corpnet.
Si le client VPN est configuré pour désactiver le split tunneling, il peut être forcé d’utiliser des passerelles d’accès Internet d’entreprise pendant la connexion du client. Cependant, une fois la connexion VPN supprimée, l’utilisateur peut à nouveau faire ce qu’il veut – et peut partager tous les logiciels malveillants ou chevaux de Troie que l’ordinateur a acquis lorsqu’il est déconnecté du VPN lorsqu’il se connecte à nouveau.
Les utilisateurs peuvent éviter de se connecter au VPN car les temps de connexion sont lents, la connectivité est incohérente et l’expérience VPN dans son ensemble n’est pas optimale, ce qui augmente encore le risque de non-conformité à la sécurité et augmente le risque de compromis.

Le client VPN itinérant est donc très différent du point de vue de la sécurité, par rapport au client corpnet « boulonné « :

La politique de groupe peut ou non être mise à jour en temps opportun.
Les logiciels antivirus peuvent ou non être mis à jour en temps opportun.
Les logiciels anti-malware peuvent ou non être mis à jour en temps opportun.
D’autres méthodes de gestion et de contrôle peuvent ou non être en mesure de reconfigurer le client en temps opportun.
Le nombre de personnes qui ont accès à l’ordinateur client VPN physique est potentiellement supérieur à ceux qui ont accès à un client corpnet « boulonné », y compris non seulement les membres de la famille et les amis de l’utilisateur, mais aussi les personnes qui pourraient réellement voler l’ordinateur.

La principale différence entre le client VPN itinérant et le client corpnet « boulonné » est que le client VPN n’est pas toujours géré et qu’il est exposé à un plus grand nombre de menaces programmatiques et physiques. Cependant, il existe des moyens d’atténuer certaines de ces menaces et de nombreuses entreprises ont déjà introduit des méthodes pour le faire, telles que les suivantes:

Déploiement d’un chiffrement de disque (tel que BitLocker) de sorte qu’en cas de vol d’une machine, le disque ne puisse pas être lu à l’aide d’une » attaque hors ligne ». Le chiffrement de disque peut également utiliser une méthode d’accès basée sur une « clé » au disque, de sorte que si la machine est éteinte, la machine ne démarrera pas sans la clé.
Nécessitant une authentification à deux facteurs pour se connecter à la machine, le deuxième facteur étant également nécessaire pour déverrouiller la machine ou la mettre en veille.
Déploiement de technologies NAP ou similaires pour tester la sécurité des points de terminaison avant d’autoriser l’accès corpnet à la machine. Si la machine ne peut pas corriger, l’accès corpnet ne lui est pas autorisé.
S’assurer que les comptes d’utilisateurs utilisés pour se connecter au réseau ne sont pas les mêmes que les comptes administratifs utilisés pour gérer les serveurs et les services du réseau, afin d’éviter les attaques d’élévation.
Repousser le centre de données de tous les clients, à la fois des clients situés VPN et corpnet, de sorte que le centre de données est physiquement et logiquement séparé de l’ensemble de la population de clients.

L’utilisation de l’une de ces mesures d’atténuation contribuera grandement à réduire la menace potentielle exposée par les clients VPN d’accès à distance. Bien que le champ ne soit peut-être pas nivelé avec le client corpnet « boulonné », il peut y avoir des scénarios où le client VPN d’accès distant en itinérance peut présenter un risque moindre. Nous examinerons l’un de ceux-ci plus loin dans cet article.

Le client DirectAccess

Maintenant, nous arrivons au sujet du client DirectAccess. Comme le client VPN, cet ordinateur peut passer du corpnet à une chambre d’hôtel, à un centre de conférence, à un aéroport et à n’importe quel autre endroit où un client VPN d’accès distant itinérant peut se trouver. Le client DirectAccess, au cours de sa durée de vie, sera connecté à des réseaux fiables et non fiables, tout comme le client VPN d’accès distant itinérant, et le risque de compromission physique de l’ordinateur est également similaire à celui observé avec le client VPN d’accès distant itinérant. Ainsi, il semblerait que le résultat d’une comparaison entre le client DirectAccess et le client VPN soit qu’ils sont essentiellement les mêmes du point de vue des menaces.

Cependant, il existe des différences significatives entre le client VPN d’accès distant itinérant et le client DirectAccess:

Le client DirectAccess est toujours géré. Tant que l’ordinateur client DirectAccess est allumé et connecté à Internet, le client DirectAccess dispose d’une connectivité avec des serveurs de gestion qui maintiennent le client DirectAccess en conformité avec la configuration de sécurité.
Le client DirectAccess est toujours utilisable. S’IL doit se connecter au client DirectAccess pour effectuer une configuration logicielle personnalisée ou résoudre un problème sur le client DirectAccess, il n’y a aucun problème à obtenir l’accès car la connexion entre le client DirectAccess et les postes de gestion informatique est bidirectionnelle.
Le client DirectAccess utilise deux tunnels distincts pour se connecter. Le client DirectAccess n’a accès qu’à l’infrastructure de gestion et de configuration via le premier tunnel. L’accès au réseau général n’est pas disponible tant que l’utilisateur ne se connecte pas et ne crée pas le tunnel d’infrastructure.

Lorsque vous comparez le client DirectAccess au client VPN d’accès distant, le client DirectAccess peut présenter un profil de menace beaucoup plus faible que le client VPN, car le client DirectAccess est toujours sous la commande et le contrôle de l’informatique de l’entreprise. Cela contraste fortement avec les clients VPN d’accès distant itinérants qui peuvent ou non se connecter au réseau d’entreprise pendant de longues périodes, ce qui entraîne une entropie de configuration qui peut augmenter considérablement le risque de compromission du système. De plus, les atténuations mentionnées ci-dessus qui s’appliquent au client VPN d’accès distant peuvent également être utilisées avec le client DirectAccess.

Voici où nous arrivons au point de faire une distinction critique: lorsque l’on compare le client VPN d’accès distant itinérant au client DirectAccess, toutes les preuves indiquent que le client DirectAccess présente un profil de menace inférieur. Les comparaisons entre le client DirectAccess et le client corpnet « boulonné » ne présentent probablement qu’un intérêt académique – car peu d’organisations ont désormais ces clients « boulonnés » et la plupart des entreprises permettent aux utilisateurs disposant d’un accès VPN d’atteindre les ressources corpnet, et les clients VPN et les clients DirectAccess entreront et sortiront du réseau d’entreprise, ce qui rend la division entre le « client corpnet » et le « client distant » pratiquement vide de sens du point de vue de la sécurité.

Conclusion

J’ai entendu un certain nombre de personnes s’inquiéter des menaces possibles qu’un client DirectAccess peut présenter au réseau d’entreprise en raison de sa capacité « toujours active « . Cependant, cette préoccupation est exprimée sans tenir compte du contexte du client DirectAccess et de sa comparaison avec le client VPN d’accès distant traditionnel. D’après les analyses fournies dans cet article, il devrait être clair à ce stade que, parce que le client DirectAccess est toujours géré, toujours mis à jour et toujours sous le commandement et le contrôle de l’informatique de l’entreprise, son profil de menace est en effet bien inférieur à celui présenté par le client VPN remote access.