Exporter (0) Imprimer
Développer tout

Gestion des identités et des accès

Paru le 13 septembre 2006

Par David Conrad

En un coup d'oeil :

  • Vulnérabilité des réseaux VPN

  • Déploiement d'une PKI

  • Options d'authentification

  • Connexions en quarantaire

Qui a décrété que les réseaux privés virtuels, ou VPN, étaient une bonne idée ? Les VPN permettent à une multitudes de travailleurs mobiles présentant des besoins professionnels "légitimes" de se connecter à nos sympathiques

réseaux d'entreprise, à l'aide des mêmes ordinateurs que leurs enfants utilisent entre autre pour jouer. Les responsables informatiques ont rapidement compris la valeur des VPN et ont immédiatement créé des projets, avec, pour conséquence, une productivité légitime désormais ralentie dès lors que les utilisateurs comprirent qu'ils pouvaient consulter leur messagerie et jouer au poker en ligne en même temps.

L'évolution fut rapide mais sans réelle modernisation. De nombreuses entreprises utilisent encore le scénario VPN de base qu'elles ont déployé il y a des années, qui repose sur le protocole Point-To-Point Tunneling (PPTP) et qui permet à tous les types d'ordinateurs, qu'iols soient infectés, non modifiés et mal configurés de se connecter à leur réseau. Dans l'environnement actuel qui doit faire face à des menaces Internet de plus en plus complexes, ce type de configuration est totalement inadapté. Si votre solution VPN n'a pas évolué pour devancer ces menaces, il ne serait pas superflu d'offrir à votre entreprise une modernisation de votre réseau VPN.

Une modernisation du réseau VPN basée sur les technologies Microsoft vous permettront d'améliorer la sécurité de votre VPN dans deux principaux domaines. Premièrement, cela vous garantit une protection de vos données basée sur le puissant protocole IPsec (IP Security ), et deuxièmement, vous disposez d'un service de quarantaine VPN Microsoft® pour inspecter les ordinateurs client lors de leur connexion, assurant que les correctifs de sécurité et les anti-virus requis sont installés avant que les clients n'accèdent au reste du réseau d'entreprise.

Dans ce document, j'aborderai une solution VPN sécurisée fondée sur deux produits clés, Windows Server 2003 et Internet Security and Acceleration (ISA) Server 2004. Je décrirai des moyens d'attribuer des certificats numériques X.509 aux utilisateurs de VPN et de consulter le service de quarantaine du VPN. Si vous avez besoin d'un guide pas-à-pas pour installer et configurer une solution VPN sécurisée, consultez le site Web ISA.

Définition de nos objectifs

Par exemple, nous devons prendre en charge une communauté mobile et nos utilisateurs nécessitent un accès à notre réseau depuis leur ordinateur géré (membre du domaine de l'entreprise), ainsi que depuis leur ordinateur personnel et d'autres réseaux. Nous devons également nous protéger contre l'introduction de virus, de logiciel malveillant ou d'autres menaces dans notre réseau d'entreprise par la connexion via des ordinateurs non protégés ou sur lesquels les correctifs n'ont pas été passés. Comment atteindre nos objectifs ?

Premièrement, nous imposons à tous les clilents VPN rejoignant notre réseau d'utiliser le puissant protocole de cryptage IPsec pour la protection des données, ce qui nécessite un certificat numérique X.509 pour chaque client. Il est facile d'émettre des certificats pour des postes de travail gérés, mais qu'en est-il des ordinateurs personnels et des ordinateurs des sous-traitants ? Nous pouvons attribuer des certificats pour ces ordinateurs à l'aide de l'outil cmgetcer.dll du kit de ressources Windows Server 2003. La stratégie consiste à permettre aux clients de se connecter à l'aide du protocole PPTP le plus faible sur une période suffisamment longue pour obtenir un certificat numérique, puis à forcer leur déconnexion et à les reconnecter à l'aide du cryptage IPsec basé sur les certificats. Nous utiliserons plusieurs stratégies d'accès à distance définies sur un contrôleur de domaine pour gérer ce comportement.

Ensuite, nous devrons nous assurer que personne n'infecte le réseau avec le dernier virus, ver ou autre attaque du système. Pour ce faire, nous utiliserons le service de quarantaine VPN qui permet aux clients VPN d'être mis en quarantaine jusqu'à ce qu'ils aient passé avec succès une vérification. Les administrateurs peuvent écrire d'autres scripts de vérification, mais chaque client doit au moins faire l'objet d'un contrôle relatif à la définition actuelle des anti-virus, au passage des derniers correctifs de sécurité et à quelques autres fonctions diverses, telles que l'activation du pare-feu Windows. Lorsqu'un client est considéré en bonne santé, le service de quarantaine VPN le libère, lui donnant ainsi accès aux ressources du réseau. Les clients qui ne satisfont pas au contrôle sont maintenus en quarantaine et corrigés par un serveur sur le réseau de quarantaine, puis recontrôlés. Pour une description générale de la procédure de quarantaine, consultez la barre latérale "Processus de quarantaire"

Pour finir, nous présumons que les utilisateurs disposent de comptes Active Directory et que nous utiliserons leur nom d'utilisateur et mot de passe (MSCHAPv2) dans notre schéma d'authentification. À mesure que vous avancez dans le scénario de solution, vous devriez partir du principe que les utilisateurs saisissent un nom d'utilisateur et un mot de passe Active Directory valides dans le cadre de leur authentification.

Pour comprendre le fonctionnement de cette solution, abordons ses composants plus en profondeur.

Le processus de quarantaine par Steve Riley

1. Pré-connexion : Un script pré-tunnel s'exécute avant que le client à distance n'initie la connexion VPN. Ce script vérifie la plupart des éléments de stratégie et enregistre les résultats. Si le script échoue, il interrompt la tentative de connexion et en informe l'utilisateur.

2. Connexion : Si le script réussit le client à distance établit une connexion au serveur RAS.



3. Authenfication de l'utilisateur : Le serveur RAS contacte un serveur RADIUS pour authentifier l'utilisateur. Si l'authentification échoue, le script interrompt la connexion et en informe l'utilisateur.

4. En quarantaine : Si l'authentification réussit, le serveur RAS place le client à distance en quarantaine. Dans ce cas, un script post-tunnel effectue une vérification supplémentaire non obligatoire et limite le client à distance de deux manières : Les filtres IP restreignent les capacités de communication de l'ordinateur au sous-réseau de quarantaire uniquement, et un délai d'expiration assure que l'ordinateur ne reste pas indéfiniment en quarantaine.

5. Notification : Le script post-tunnel renvoie les résultats du script pré-tunnel vers le serveur RAS. Si le client à distance ne respecte pas la stratégie ou si le délai d'expiration arrive à terme avant que le client à distance ait répondu par des résultats acceptables, le script annule la connexion.

6. Accès autorisé : Si le script post-tunnel réussit, le serveur RAS supprime les restrictions de filtre IP et octroie au client à distance un accès total et normal au réseau (tel que spécifié dans la stratégie d'accès à distance).

Protocoles VPN

Les administrateurs réseaux ont déployé pendant des années des solutions VPN basées sur le protocole PPTP en raison de sa simplicité. Les clients PPTP étaient créés dans Windows, disponibles sur la plupart des autres plates-formes, et ne nécessitaient aucun service d'infrastructure supplémentaire. Le protocole PPTP garantit une sécurité satisfaisante, il manque cependant de fonctionnalités avancées de protection des données, telles que l'établissement d'une connexion sécurisée avant l'authentification, autorisant l'authentification des données et la protection contre les répétitions d'attaques. Il y a de fortes chances que votre solution VPN actuelle utilise le protocole PPTP et qu'une grande partie de cette modernisation extrême du VPN soit une mise à niveau vers le protocole plus puissant Layer Two Tunneling (L2TP).

L'implémentation par Microsoft du protocole L2TP résoud les insuffisances en matière de sécurité du protocole PPTP par le biais de l'utilisation du protocole IPsec pour fournir des fonctionnalités de protection renforcée des données ; et il est donc plus correct de l'appeler L2TP sur IPsec ou L2TP/IPsec. L'un des avantages majeurs de IPsec sur PPTP est que la totalité du processus d'authentification de l'utilisateur a lieu après l'établissement d'une connexion cryptée entre le client et le serveur VPN. IPsec requiert les certificats numériques X.509 sur chaque ordinateur client, qui à son tour nécessite une infrastructure à clé publique (PKI) pour déployer les certificats.

Attribution automatique de certificat PKI

La première étape de notre modernisation VPN consiste à faire basculer les clients Windows sur le protocole L2TP/IPsec basé sur des certificats pour améliorer la protection des données. Si vous disposez d'une PKI existante, vos clients peuvent déjà disposer de certificats valides (ils doivent avoir l'identifiant d'objet (OID) d'utilisation avancée de la clé "1.3.6.1.5.5.7.3.2" utilisé pour l'authentification du client). Si n'en n'avez pas ou si vous devez étendre votre solution aux ordinateurs personnels ou aux sous-traitants, vous pouvez tirer parti des services de certificat intégrés dans Windows Server 2003.

Gardez à l'esprit que le déploiement de tout type de PKI est une opération importante qui doit être planifiée. Toute implémentation doit inclure deux documents juridiques décrivant les stratégies globales de sécurité. Une stratégie de certificat (CP) doit décrire l'authentification des utilisateurs avant leur réception des certificats, l'utilisation prévue des certificats et d'autres informations du même type. Une déclaration CPS (Certificate Practice Statement) doit décrire comment les autorités de certification de votre PKI sont maintenues à jour et décrire les précautions de sécurité environnementale mises en place pour la protéger. Si vous configurez une nouvelle PKI simplement pour disposer d'un réseau VPN sécurisé, prenez quelques instants pour consulter les exemples de stratégie de certificat et de déclaration CPS disponibles sur le site Web de Microsoft, et peut-être pour les modifier pour qu'ils reflètent les stratégies de votre entreprise. Les responsables de la sécurité d'entreprise commencent souvent avec ces documents.

Maintenant, retournons à la technologie. Supposons que nous n'avons pas de PKI existante et que nos seules exigences consistent à déployer des certificats aux clients VPN. Nous avons alors besoin d'un serveur Windows Server 2003 Edition Entreprise pour notre autorité de certificat, car c'est la seule édition de Windows qui prend en charge les modèles de sécurité version 2. Ce serveur doit appartenir à notre domaine car nous souhaitons tirer parti des fonctionnalités d'inscription automatique au certificat disponibles pour les membres de domaine. Nous devons inclure IIS et les pages Web d'inscription au certificat. Lorsque nous activons les services de certificat sur notre serveur, nous devons le configurer en tant qu'autorité de certification racine de l'entreprise. Ainsi les informations sur l'autorité de certification sont publiées dans Active Directory et nous permet de tirer parti des fonctionnalités d'inscription automatique prises en charge par les autorités de certification du membre du domaine. Une fois l'autorité de certification activée, nous la configurons pour que les certificats d'ordinateur client soient automatiquement publiés vers les utilisateurs authentifiés, activant ainsi notre scénario d'attribution de privilèges d'accès. Enfin, nous déploierons un certificat vers le serveur VPN qui est exécutera ISA Server 2004.

Lorsque l'autorité de certificat est configurée pour publier des certificats client, nous pouvons laisser nos clients VPN demander des certificats à l'aide de l'outil cmgetcer.dll. Le client se connecte au serveur VPN avec le protocole PPTP, puis demande le certificat en exécutant un script. Le script et ses paramètres sont spécifiés dans le logiciel Connection Manager Client VPN, que nous allons étudier dans un instant. L'outil cmgetcer.dll résout deux des principaux problèmes liés aux déploiements de PKI. Lorsqu'un client authentifié demande un certificat, cmgetcer.dll prend non seulement en charge l'inscription à un certificat, mais il enregistre également la publication des autorités de certification et toute chaîne de certificat associée dans le magasin d'autorité de certification de confiance du client .

Terminaison VPN

ISA Server 2004 représente la terminaison VPN de notre solution. Même si Windows Server inclut à l'origine un serveur VPN dans les services de routage et d'accès à distance, les clients d'entreprise ont besoin du service VPN ISA Server 2004 qui fournit davantage de sécurité, de capacité de gestion et de règles. ISA Server 2004 est un pare-feu au niveau application (ALF) qui assure la vérification des paquets avec état au niveau 7, ainsi que des services VPN sécurisés basés sur le protocole PPTP ou L2TP. Les services VPN d'ISA Server peuvent faire l'objet d'un équilibrage de la charge sur différents ordinateurs et, essentiellement, peuvent s'exécuter sur des serveurs qui n'appartiennent pas au domaine. Le déploiement d'ISA Server sur les serveurs des membres du groupe de travail dans la zone démilitarisée représente une partie importante d'une stratégie de défense en profondeur, car aucun service ne s'exécute avec des informations d'identification de domaine sur les serveurs VPN.

La configuration d'ISA en tant que membre du groupe de travail dans la zone démilitarisée est très simple Vous devez spécifier les protocoles VPN autorisés, dans notre cas, il s'agit de PPTP et L2TP. Rappellez-vous que le protocole L2TP est en réalité le protocole L2TP/IPsec, ainsi nous demanderons manuellement un certificat à notre autorité de certification via les pages Web de certificat intégrées. Si le certificat est correctement configuré sur notre serveur ISA, nous pouvons sélectionner la méthode d'authentification.

Authentification RADIUS

Le serveur VPN ISA n'étant pas membre de notre domaine, il ne peut pas en authentifier directement les utilisateurs. Par conséquent, nous devrons configurer le serveur VPN ISA à l'utilisation du service RADIUS (Remote Access Dial-In User Service) à des fins d'authentification.

Le serveur RADIUS utilisé est un service d'authentification Internet (IAS), un autre service intégré dans Windows Server (voir la Figure 1). En activant ce service sur un ou plusieurs contrôleurs de domaine du réseau interne, nos contrôleurs de domaine peuvent être utilisés comme serveurs RADIUS pour les clients RADIUS, qui est le serveur VPN ISA dans notre cas.

Configuration d'IAS


figure 1 : Configuration d'IAS

Le trafic de données entre le client et le serveur RADIUS est crypté par un mot de passe confidentiel partagé, vous devez donc utiliser un mot de passe complexe et identique sur chaque ordinateur. Une information intéressante concernant cette configuration est que votre serveur VPN ISA situé dans la zone démilitarisée utilise un port unique (habituellement UDP 1812) pour envoyer des demandes d'authentification dans le réseau interne. Il n'est pas nécessaire d'ouvrir une multitude de ports pour permettre une authentification classique de style Kerberos via le pare-feu interne de la zone démilitarisée.

À présent, comme le service IAS est activé sur un ou plusieurs contrôleurs de domaine, nous devons créer quelques stratégies d'accès à distance. IAS utilise ces stratégies pour déterminer l'octroi d'accès VPN à un utilisateur. Une stratégie commune consiste à créer un groupe de sécurité Windows appelé « Utilisateurs VPN » et à intégrer les utilisateurs d'Active Directory appropriés dans ce groupe. Ensuite, vous pouvez créer une stratégie d'accès à distance qui permet aux membres de ce groupe d'accéder au serveur VPN du réseau.

Les entreprises peuvent posséder un certain nombre de stratégies d'accès à distance définies pour plusieurs scénarios différents. Lorsque les clients tentent de s'authentifier via RADIUS, les stratégies sont évaluées dans l'ordre établi de la liste du serveur IAS. La première stratégie correspondante est celle utilisée pour ce client, et si aucune stratégie ne correspond, le client n'est pas autorisé à se connecter.

Définissons, à présent, nos stratégies d'accès à distance. La première stratégie indique que l'utilisateur doit utiliser le type de tunnel L2TP et elle spécifie certains paramètres spécifiques au service de quarantaine VPN. La seconde stratégie autorise les types de tunnel PPTP, mais n'autorise que les utilisateurs authentifiés à rester connectés pendant une minute, afin d'autoriser l'activation du mécanisme défini d'attribution automatique des certificats. Une fois la minute écoulée, IAS déconnecte le client du serveur VPN ISA en appliquant la stratégie.

Connexions VPN

Ces deux stratégies mises en place permettent de définir le niveau de comportement souhaité. Regardons brièvement comment configurer le logiciel VPN client, mais voici essentiellement ce qui se passe. D'abord, les clients essayant de se connecter via le VPN à notre réseau devront utiliser le kit de numéroteur de Connection Manager, que nous créerons plus tard. Ce numéroteur personnalisé exécute les scripts de quarantaire VPN en local sur le client et indique ensuite dans un rapport son état au service de quarantaine VPN. Sans le numéroteur personnalisé, les clients resteraient indéfiniment en quarantaine.

Les clients tentant de se connecter à notre serveur VPN essaieront d'abord d'établir une connexion L2TP, puis se rabattront sur le protocole PPTP si nécessaire (voir Figure 2). Il s'agit d'un autre choix de configuration effectué dans le numéroteur de Connection Manager. La première fois qu'un nouveau client tente de se connecter au serveur VPN, il ne dispose d'aucun certificat, ce qui fait échouer le protocole L2TP. Le client tente alors de manière transparente d'effectuer une connexion PPTP. Au niveau du serveur VPN, nous avons choisi d'autoriser le trafic PPTP, ainsi le serveur ISA accepte la tentative de connexion PPTP et utilise RADIUS pour demander une authentification pour l'utilisateur. Le serveur RADIUS IAS commence à vérifier ses stratégies d'accès à distance. Comme la première stratégie autorise les connexions uniquement avec L2TP, le type de connexion ne correspond pas et la stratégie suivante est évaluée. Puisque la stratégie suivante autorise le protocole PPTP et que l'utilisateur possède les informations d'identification Active Directory correctes, la connexion est autorisée, mais seulement pendant une minute, grâce à la stratégie PPTP.

Processus de connexion


figure 2 : Processus de connexion

Pendant cette minute de connexion critique, l'attribution automatique de notre certificat doit être réalisée. Le gestionnaire de connexions offre la possibilité d'exécuter les scripts ou d'autres commandes sur le client après une connexion réussie. Nous utiliserons cette fonctionnalité pour exécuter un fichier de commandes qui nécessite un certificat X.509 de notre serveur de certificat, il s'agit du seul élément indispensable pour retenter une connexion PPTP. Gardez à l'esprit que le serveur de certificat doit être accessible depuis le réseau de quarantaire VPN que définit le protocole ISA.

Après la déconnexion PPTP forcée, le gestionnaire de connexions tente une reconnexion. Le gestionnaire de connexions est défini pour tenter d'abord une connexion L2TP, et, comme nous disposons désormais d'un certificat, le client essaiera ce type de connexion. Puisque notre serveur VPN ISA est configuré pour autoriser les connexions L2TP (et qu'il dispose également d'un certificat), il acceptera cette tentative de connexion et utilisera le RADIUS pour authentifier l'utilisateur. Le serveur IAS vérifiera sa liste de stratégies d'accès à distance, en commençant par le haut. Comme la première stratégie répond à nos critères, avec un type de tunnel L2TP, et comme nous avons utilisé les informations d'identification Active Directory valides, nous sommes autorisés à nous connecter.

À présent, notre client est placé dans le réseau de quarantaine VPN, un réseau virtuel spécial ISA est créé lorsque vous le configurez pour utiliser le service de quarantaine VPN. Un client authentifié via les stratégies d'accès à distance est automatiquement placé sur ce réseau VPN de quarantaine jusqu'à ce qu'ISA obtienne le signal indiquant qu'il est possible sécurisé de sortir le client de quarantaine et de le transférer sur le réseau client VPN, cela autorise l'accès à tout ou partie du réseau d'entreprise. Regardons plus en détails le service de quarantaine VPN.

Service de quarantaine VPN

La fonction du service de quarantaine VPN est simple : placer chaque client VPN sur un réseau virtuel restreint, vérifier s'il dispose des correctifs de sécurité requis, des définitions d'anti-virus et de toute autre condition requise définis par votre stratégie de sécurité, puis autoriser l'accès du client au réseau si l'administrateur l'y autorise. Les administrateurs peuvent choisir de placer un ou plusieurs serveurs de mise à jour de logiciel sur le réseau de quarantaine (tel que défini par ISA) pour permettre aux clients qui ne passent pas les vérifications de télécharger les correctifs nécessaires et de réessayer de sortir de quarantaine.

Le service de quarantaine VPN comprend deux composants. Le premier, l'exécutable RQS.exe, est un écouteur qui s'exécute sur le serveur VPN ISA. Il s'agit du service qui permet à ISA de transférer de manière transparente les clients sains depuis la quarantaine sur le réseau. Au cours de l'installation de l'exécutable RQS.exe, un administrateur spécifie une chaîne de texte qui représente un état sain. Le second composant, l'exécutable RQC.exe, est utilisé par les clients pour alerter le service de quarantaine que les vérifications ont été réussies. Les clients exécutent automatiquement le fichier RQC.exe une fois les analyses côté client réussies, passant la chaîne de texte requise à l'écouteur RQS.exe sur le serveur. Lorsque le service RQS.exe reçoit la chaîne de texte appropriée, le client est libéré de quarantaine.

Un certain nombre d'administrateurs réseau sont surpris d'apprendre que les analyses réelles pour rechercher les correctifs de sécurité et les définitions d'anti-virus ne sont pas exécutées par le client en quarantaine Microsoft, RQC.exe. À la place, vous choisissez les moyens d'analyse de vos clients (fichiers de commandes, Windows Scripting Host, applications basées .NET Framework, etc). Cette flexibilité permet aux clients de concevoir leur vérification en fonction de leurs exigences spécifiques et d'exploiter les compétences de développement avec lesquelles ils sont le plus à l'aise. Il existe une seule exigence : votre routine d'analyse client doit appeler l'exécutable côté client RQC.exe à la fin d'une l'analyse réussie, en passant la chaîne de texte appropriée. Ainsi, le fichier RQS.exe sait qu'il est autorisé à sortir le client de quarantaine et l'autorise à accéder au réseau.

Le dernier obstacle à franchir consiste à savoir comment fournir nos scripts d'analyse et le composant côté client RQC.exe du service de quarantaine à nos clients VPN. Pour ce faire, nous utiliserons le Kit d'administration du gestionnaire de connexions (CMAK), une autre fonctionnalité intégrée à Windows Server 2003.

Ressources en ligne

Le site Web de réseau VPN en ligne TechNet propose une multitude d'informations et de ressources associées. Pour plus d'informations sur la solution abordée dans cet article, suivez les guides pas-à-pas répertoriés sur le site : microsoft.com/technet/itsolutions/network/vpn/default.mspx

Consultez également :

Kit d'administration du gestionnaire de connexions

Le CMAK est inclus avec Windows Server depuis des années et permet de créer des packages de connectivité client VPN personnalisés. Dans notre scénario, un numéroteur de Connection personnalisé est essentiel, car il spécifie les paramètres VPN appropriés pour notre environnement et fournit les fichiers côté client importants que nous utilisons : le fichier cmgetcer.dll provenant du kit de ressources, le fichier de commandes pour la demande de certificat, les scripts d'analyse côté client et le non moins important fichier RQC.exe.

Une fois le package du gestionnaire de connexions constitué à l'aide du kit CMAK, il peut être mis à la disposition des clients de plusieurs manières. Pour les ordinateurs gérés, il peut être fourni via différents mécanismes de fourniture de logiciel, tels que Systems Management Server (SMS). Pour les ordinateurs non gérés, les utilisateurs non autorisés peuvent récupérer le package sur un site Web Extranet ou sur un site FTP sécurisé. Les packages de gestionnaire de connexions sont les fichiers Microsoft Installer (MSI) qui utilisent le service Windows Installer pour procéder à l'installation.

Conclusion

Les menaces sur Internet devenant de plus en plus complexes, les points d'entrée VPN peuvent s'avérer être un potentiel de risque important sur un réseau d'entreprise. Les étapes traitées dans ce scénario de modernisation extrême du réseau VPN permettent de réduire ces risques en établissant un cryptage de données puissant et d'assurer que les ordinateurs vulnérables ne soient pas autorisés à se connecter au réseau.


Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.
Afficher:
© 2014 Microsoft