Protection d'un réseau contre les clients non gérés

Paru le 29 août 2006

Sur cette page

Introduction
Définition
Enjeux
Solutions
Résumé
Annexe A : Protection de l’accès réseau

Introduction

Bienvenue dans ce document de la collection Guides de sécurité pour les entreprises de taille moyenne. Microsoft espère que les informations suivantes vous aideront à mettre en place un environnement informatique plus sûr et plus productif.

Synthèse

Dans l'environnement sécuritaire d'aujourd'hui, effectuer une approche approfondie de la protection d'un réseau d'entreprise de taille moyenne et des données qui y résident est une question des plus complexes. Il ne suffit plus de se fier uniquement aux défenses périphériques et aux logiciels antivirus pour protéger les ressources réseau et les informations confidentielles. Les entreprises et les professionnels de la sécurité sont à présent conscients du fait que les risques internes au réseau, intentionnels ou accidentels, peuvent s'avérer bien plus dangereux que les menaces externes.

En matière de gestion des correctifs, de solutions de protection contre les logiciels malveillants et d'initiatives de gestion des identités, d'importants investissements en temps et ressources ont été engagés afin de faire face aux innombrables vulnérabilités qui constituent un risque pour les entreprises de taille moyenne. Pour garantir une utilisation universelle de ces investissements dans l'ensemble de l'entreprise et une rentabilité maximale, l'entreprise doit trouver des méthodes pour appliquer efficacement les stratégies de sécurité.

Les ordinateurs non autorisés sont des systèmes qui ne sont pas considérés comme des risques élevés du fait qu'il n'existe aucun moyen de déterminer s'ils sont conformes aux stratégies de sécurité établies. Ces ordinateurs peuvent poser problème aux administrateurs système et aux professionnels de la sécurité. Les systèmes non conformes présentent un certain nombre de risques, en raison notamment de leur vulnérabilité aux infections par des logiciels malveillants et du fait qu'ils constituent des plates-formes potentielles pour les attaques. Généralement, ces systèmes sont difficiles à gérer et à rendre conformes.

Ce document présente un certain nombre de méthodes efficaces permettant d'assurer la conformité aux stratégies de sécurité. Cette approche optimise les avantages liés aux initiatives de gestion des risques et ajoute une couche de sécurité supplémentaire aux réseaux des entreprises de taille moyenne afin de réduire les risques liés aux ordinateurs non gérés et non approuvés.

Présentation

Ce document est divisé en quatre sections principales présentant des informations détaillées qui permettent au lecteur de mieux comprendre les concepts et principes associés à la protection d'un réseau d'entreprise de taille moyenne contre les ordinateurs non gérés. Ces quatre sections principales se présentent comme suit :

Introduction

Cette section propose une synthèse du document, ainsi qu'une présentation de sa structure et un certain nombre d'informations relatives au public visé.

Définition

Cette section fournit des informations détaillées et des définitions permettant de comprendre les solutions traitées dans le document.

Enjeux

Cette section décrit certains des problèmes communs auxquels une entreprise de taille moyenne peut être confrontée lorsqu'elle essaie d'établir une méthode de protection contre les ordinateurs non gérés et non approuvés. Elle fait office de contexte général relatif aux problèmes traités par ce document.

Solutions

Cette section traite des solutions permettant de répondre aux problèmes posés par les ordinateurs non gérés en évaluant les approches possibles et en abordant les questions relatives au développement de stratégies associées. Elle fournit également des informations relatives aux méthodes de déploiement et de gestion.

Personnes concernées par ce guide

Ce document technique est destiné à aider les informaticiens et les responsables techniques à comprendre les menaces provenant des périphériques non gérés afin de pouvoir prendre des décisions informées et protéger ainsi un réseau d'entreprise de taille moyenne. Même si les lecteurs non techniques peuvent utiliser ce document afin de mieux cerner ce problème de sécurité spécifique, une connaissance de base des éléments suivants est un plus pour parfaitement comprendre et mettre en application les questions qui y sont traitées.

Les technologies spécifiques traitées dans ce document sont les suivantes :

• Authentification IEEE 802.1X

• Stratégies IPsec

• Sécurité réseau

• Microsoft® Systems Management Server 2003

• Microsoft Windows Server™ 2003

• Service d'annuaire Active Directory®

• Microsoft Operations Management Server

• Microsoft Internet Authentication Service

• Authentification RADIUS

Haut de page

Définition

Ce guide est conçu pour utiliser le modèle de processus MOF (Microsoft Operations Framework) en plus des fonctions de gestion du service d'administration (SMF) de la sécurité MOF.

Plus précisément, les solutions présentées dans ce document recommandent l'utilisation d'une approche de processus en continu plutôt qu'une approche de déploiement linéaire pour améliorer la sécurité réseau contre les menaces générées par les ordinateurs non gérés.

La mise en application de ces solutions doit précisément impliquer les étapes illustrées dans la figure suivante :

Figure 1. Mise en application de MOF

Comme illustré dans cette figure, toutes les réponses aux problèmes de sécurité posés par les systèmes non gérés doivent être des processus continus de test et de mesures correctives, non pas des simples questions de planification et de déploiement. Les menaces susceptibles d'atteindre un réseau d'entreprise de taille moyenne sont en constante évolution ; de ce fait, le système qui protège un réseau d'entreprise doit s'y adapter en permanence.

L'application des solutions abordées dans ce document répond aux directives de Gestion de la sécurité de la documentation SMF (Service Management Functions), laquelle est détaillée comme suit :

• Évaluer l'exposition de l'entreprise et identifier les ressources à sécuriser.

• Identifier les méthodes permettant de réduire à des niveaux acceptables les risques générés par les périphériques non sécurisés.

• Concevoir un plan permettant d'atténuer les risques liés à la sécurité.

• Contrôler l'efficacité des mécanismes de sécurité.

• Réévaluer régulièrement l'efficacité et les besoins en termes de sécurité.

Pour en savoir plus sur MOF, reportez-vous au site Web Microsoft Operations Framework de Microsoft TechNet à l'adresses suivante : www.microsoft.com/technet/itsolutions/cits/mo/mof/default.mspx.

Pour plus d'informations sur la SMF Gestion de sécurité, consultez la page relative aux fonctions de gestion de la sécurité (cette page peut être en anglais) à l'adresse suivante : http://go.Microsoft.com/fwlink/?LinkId=37696.

La gestion des risques est un processus consistant à déterminer le niveau de risque acceptable d'une organisation, à évaluer les risques actuels, à trouver des méthodes permettant d'atteindre ce niveau de risque acceptable et à gérer les risques. Même si ce document aborde certains concepts de la gestion des risques, ce sujet en soi mérite d'être traité en profondeur. Pour plus d'informations sur l'analyse et l'évaluation des risques, reportez-vous au Guide de gestion des risques de sécurité à l'adresse suivante : http://go.Microsoft.com/fwlink/?LinkId=30794.

Haut de page

Enjeux

Les enjeux liés à la protection contre les ordinateurs non gérés sont notamment les suivants :

• Comment empêcher des ordinateurs non gérés d'accéder aux ressources réseau.

• Comment assurer la conformité permanente des ordinateurs itinérants avec les mises à jour et les stratégies.

• Comment appliquer les stratégies de sécurité établies aux ordinateurs qui se connectent au réseau à distance.

• Comment protéger un réseau contre les périphériques sans fil non autorisés.

• Comment détecter les systèmes non gérés, tels que des ordinateurs portables de fournisseurs ou des périphériques personnels, lorsqu'ils se connectent au réseau.

• Comment se protéger contre d'autres périphériques mobiles tels que des ordinateurs portatifs et de poche.

Haut de page

Solutions

La section « Enjeux » établie une liste de plusieurs facteurs devant être pris en compte dans le cadre de la protection du réseau contre les ordinateurs non autorisés et non gérés. Outre la défense du réseau câblé interne traditionnel, des initiatives doivent également être entreprises pour sécuriser le réseau sans fil, ainsi que tous les chemins d'accès à distance. Pour qu'elle couvre l'ensemble des possibilités permettant à un périphérique non autorisé de se connecter, la solution doit avoir une portée globale et complète.

La section suivante traite des enjeux répertoriés en abordant les approches suivantes :

• Utilisation de l'isolation IPsec de serveurs et de domaines afin d'empêcher les ordinateurs non gérés d'accéder aux ressources réseau.

• Utilisation de la quarantaine VPN pour appliquer les stratégies de sécurité établies aux ordinateurs qui se connectent au réseau à distance.

• Utilisation de l'authentification 802.1X pour se protéger contre les périphériques sans fil non approuvés.

• Utilisation de SMS pour détecter les ordinateurs non gérés lorsqu'ils se connectent au réseau.

Remarque   Ce document suppose que le lecteur a déjà mis en œuvre des processus pour garantir la conformité des ordinateurs membres résidant dans les structures de domaine de l'entreprise de taille moyenne avec toutes les mesures de sécurité et correctives établies, et qu'il recherche des méthodes permettant d'appliquer cette conformité, ainsi que les mesures de protection relatives aux périphériques non conformes. Ce document ne traite ni des méthodes de mise en conformité des ordinateurs, ni de l'utilisation de mécanismes de mise à jour de sécurité automatique tels que WSUS ou les fonctionnalités de gestion des correctifs de SMS.

Évaluation

Cette section vous présente certaines des réponses possibles permettant de résoudre le problème posé par les ordinateurs non gérés aux entreprises de taille moyenne. Elle aborde également certaines des décisions devant être prises avant de choisir l'une de ces réponses. Chacune de ces réponses peut permettre, individuellement, de renforcer le niveau de sécurité réseau dans une entreprise de taille moyenne. Néanmoins, lorsqu'elles sont combinées et mises en œuvre dans le cadre d'une approche globale de défense renforcée, elles constituent une solution plus sophistiquée aux problèmes abordés dans la section « Enjeux ».

Utilisation d'IPsec pour l'isolation de domaines et de serveurs

L'isolation physique d'ordinateurs et de réseaux n'a rien d'une nouveauté. Elle a été mise en pratique sous de nombreuses formes au fil des ans, le plus souvent dans le cadre du développement et de réseaux de test. Toutefois, les précédentes approches d'isolation physique ne se prêtent pas bien à la protection de systèmes gérés contre des périphériques non gérés potentiellement compromis. Cela se vérifie particulièrement dans les environnements de réseau d'entreprise modernes, caractérisés par une présence de plus en plus forte de l'informatique mobile et une demande croissante en solutions automatisées et flexibles. Le tableau suivant présente les méthodes d'isolation physique courantes qui ont été utilisées par le passé, ainsi que les difficultés associées à leur utilisation.

Tableau 1. Approches d'isolation de réseau

Couche OSI	Approche	Problèmes
Couche 1	Utiliser un câblage séparé pour les segments devant être isolés du réseau approuvé.	Coûts associés à l'utilisation de nouveaux câbles pour chaque nouvelle connexion. Surcharge administrative accrue due à la gestion de nouveaux câbles pour les déplacements des utilisateurs. Manque de souplesse et difficulté de gestion au fur et à mesure que l'entreprise se développe. Risques plus élevés de négligences et d'erreurs en raison des besoins importants en termes de gestion.
Couche 2	Utiliser des réseaux locaux virtuels (VLAN) pour créer des sous-réseaux logiques isolés du réseau approuvé.	Accroissement des coûts liés à la mise à jour de la matrice de commutation pour prendre en charge les réseaux locaux virtuels (VLAN). Augmentation de la surcharge administrative pour le suivi des modifications du réseau, des déplacements des utilisateurs et pour les réponses aux demandes de connexion de type « invité ». Risques de négligences et d'erreurs lorsque plusieurs utilisateurs sont en déplacement ou lorsque des périphériques mobiles sont utilisés.

Comme l'indique ce tableau, le réseau d'entreprise moderne nécessite une solution plus flexible lui permettant d'être conforme aux normes de sécurité qui aident à se protéger contre les systèmes non gérés. Il existe des solutions tierces pour faire face à ce problème, mais ces dernières impliquent des installations côté client sur toutes les stations de travail gérées et augmentent la complexité du réseau. Heureusement, les versions actuelles de Microsoft Windows comportent des fonctionnalités intégrées permettant de résoudre ce problème sans pour autant nécessiter l'installation de logiciels supplémentaires ou impliquer des courbes d'apprentissage relatives à l'administration.

L'isolation de serveurs et de domaines Microsoft permet aux administrateurs informatiques de limiter les communications TCP/IP en s'appuyant sur la stratégie de groupe Active Directory et sur la technologie IPsec, ce qui présente les avantages suivants :

• Utilisation de la couche réseau du modèle OSI, ce qui permet de dépasser les frontières posées par les commutateurs et les routeurs.

• Indépendant des limites posées par la matrice de commutation et les réseaux physiques.

• Réduction des coûts grâce à l'exploitation des fonctionnalités d'authentification intégrées des ordinateurs Windows.

• Automatisation, ne nécessitant pas de maintenance en continu liée aux modifications du réseau et aux déplacements des utilisateurs.

• Possibilité d'authentifier les ordinateurs approuvés, mais aussi de chiffrer les communications entre systèmes approuvés.

• Mise en oeuvre des stratégies de sécurité via le refus des demandes de connexion provenant des périphériques non gérés.

• Amélioration des audits et de la gestion des ressources.

• Possibilité d'isoler rapidement des ressources spécifiques en cas d'attaque.

Les problèmes habituels concernant l'utilisation de IPsec pour sécuriser les communications ont été résolus par les récents développements effectués en réponse à ces questions. Plus précisément, la traduction d’adresses réseau (NAT) ne pose plus problème grâce aux fonctionnalités de parcours NAT disponibles dans les versions actuelles de Microsoft Windows, telles que Windows Server 2003 et Microsoft Windows XP avec Service Pack 2 (SP2). En outre, la prise en charge de plates-formes non IPsec est rendue possible via des listes d'exceptions paramétrables et/ou une exception de basculement permettant une communication en texte clair avec ces systèmes.

Comme le montre ce document, les solutions d'isolation de domaines et de serveurs sont utilisées au sein même du réseau interne de Microsoft. Non seulement Microsoft recommande ces solutions aux clients, mais sa propre sécurité dépend également du niveau de protection supérieur qu'elles offrent. Dans ce contexte, et pour une plus grande confiance dans l'informatique, Microsoft s'engage sur le long terme à tout mettre en œuvre pour faire évoluer cette méthode de sécurisation afin que les réseaux soient de plus en plus fiables et faciles à gérer.

Présentation de l'isolation de domaines et de serveurs

En bref, la création d'un réseau isolé implique la séparation des divers types d'ordinateurs dans un réseau d'entreprise en fonction du type d'accès qui leur correspond. Dans ce contexte, ces divers types sont divisés en deux ensembles : les ordinateurs gérés et les ordinateurs non gérés. Pour pouvoir atteindre un niveau fonctionnel d'isolation du réseau, deux conditions de base doivent être remplies, à savoir :

• Les ordinateurs résidant à l'intérieur de la partie isolée du réseau peuvent établir des communications avec tous les ordinateurs du réseau dans son ensemble, notamment ceux qui résident hors de la partie approuvée du réseau.

• Les ordinateurs résidant hors de la partie isolée du réseau peuvent établir des communications uniquement avec d'autres ordinateurs situés hors du réseau approuvé, et non pas avec ceux situés à l'intérieur.

L'isolation IPsec de domaines et de serveurs permet de renforcer les structures existantes à l'aide des paramètres de stratégie de groupe. Tous les éléments nécessaires à la création d'un réseau existent déjà dans les ordinateurs exécutant Windows XP, Windows 2000 Server et Windows Server 2003. Lorsque les paramètres de stratégie de groupe requis ont été configurés, les processus d'insertion d'un nouvel ordinateur dans le réseau isolé consiste, grosso modo, à ajouter cet ordinateur au domaine.

Figure 2. Isolation d'un réseau à l'aide de domaines Active Directory

Comme illustré dans la figure précédente, tout ordinateur ne faisant pas partie du domaine n'est pas considéré comme étant approuvé et, de ce fait, réside hors du réseau isolé. Tout système résidant en dehors du réseau isolé ne peut initier de communications IPsec, et donc d'établir une connexion avec un système situé au sein du domaine isolé. En revanche, les membres du domaine isolé ont, quant à eux, la possibilité d'établir des communications en texte clair avec les périphériques situés en dehors du réseau isolé.

Bien entendu, de nombreuses organisations possèdent des ordinateurs et des serveurs qui, bien qu'étant gérés et approuvés, ne se trouvent pas dans un domaine Active Directory ou ne peuvent pas utiliser IPsec pour diverses raisons. Or, ces derniers ont pourtant besoin de communiquer avec des systèmes situés à l'intérieur du réseau isolé. Pour résoudre ce dilemme, un autre groupe isolé (ou groupe frontalier) peut être créé à l'aide de listes d'exceptions, comme illustré dans la figure suivante.

Figure 3. Isolation du réseau et groupes frontaliers

Un tel modèle d'isolation permet de réduire l'empreinte de sécurité d'un réseau d'entreprise. Toutefois, cette solution ne peut garantir à elle seule que les systèmes approuvés demeureront conformes aux normes qui font qu'ils sont approuvés. En soi, elle ne constitue pas une solution de sécurité réseau complète, mais elle contribue à un processus de sécurité général et plus complet qui, conjointement avec d'autres solutions, permet de réduire les risques auxquels sont exposés les réseaux modernes des entreprises de taille moyenne. Plus précisément, lorsqu'elle est utilisée avec d'autres solutions de sécurité telles que WSUS, SMS et MOM, cette méthode d'isolation peut permettre de renforcer la conformité aux stratégies de sécurité au sein du réseau isolé.

D'autres solutions de sécurité Active Directory permettent d'automatiser les tâches de mise en conformité permanente aux stratégies de sécurité au sein du réseau approuvé isolé. Toutefois, un groupe frontalier doit s'appuyer sur plusieurs méthodes différentes afin de s'assurer que les ordinateurs qu'il comprend ne deviennent pas les points faibles de la solution de réseau isolé. Avant d'être ajoutés au groupe frontalier, ces ordinateurs doivent être validés comme étant conformes et doivent comporter des méthodes et stratégies spécifiques garantissant leur conformité permanente avec les stratégies de sécurité des systèmes approuvés.

Présentation d'IPsec

IPsec est une norme de sécurité du Protocole Internet qui fournit un mécanisme de sécurité de couche IP basé sur des stratégies, idéale pour l'authentification d'hôte à hôte. Les stratégies IPsec sont définies comme étant un dispositif de règles et paramètres de sécurité qui permettent de contrôler le flux du trafic entrant et sortant sur un système hôte. Elles sont gérées de manière centralisée dans Active Directory à l'aide d'objets de stratégie de groupe pour les attributions de stratégies aux membres du domaine. Elles permettent d'établir des communications sécurisées entre les membres du domaine, ce qui constitue le fondement de cette solution.

IPsec utilise le protocole de négociation IKE (Internet Key Exchange) pour négocier les options entre deux hôtes afin de déterminer la manière de communiquer en toute sécurité à l'aide d'IPsec. Les accords conclus entre les deux hôtes et les divers paramètres qui définissent cette méthode de négociation sont appelés des associations de sécurité (SA, Security Associations). Microsoft Windows est capable d'utiliser l'une des trois méthodes IKE suivantes :

• Protocole d'authentification Kerberos version 5

• Certificats numériques X.509 et les paires de clés RSA correspondantes

• Clés prépartagées utilisant des phrases de passe

Remarque   Même si l'infrastructure à clé publique (Public Key Infrastructure, PKI) peut être utilisée en tant que méthode d'authentification, il n'est pas recommandé d'utiliser l'intégration de l'authentification de domaine Windows 2000 (Kerberos) dans le protocole de négociation IKE.

La négociation IKE de Windows peut être configurée afin d'autoriser les communications avec des ordinateurs qui ne répondent pas à la demande de négociation IKE. Cette fonctionnalité, appelée « basculement en clair », est non seulement essentielle lors des déploiements, mais elle s'avère également très utile dans ce contexte du fait qu'elle permet aux systèmes du groupe frontalier de communiquer avec des membres du réseau isolé. Toute communication qu'IPsec ne peut pas protéger est appelée « association de sécurité logicielle » et est enregistrée en tant qu'événement d'audit réussi du journal de sécurité.

Outre l'authentification, IPsec offre d'autres fonctions utiles telles que l'intégrité et le chiffrement du trafic réseau à l'aide de ses protocoles AH (Authentication Headers, en-têtes d'authentification) et ESP (Encapsulating Security Payload). Même si les en-têtes d'authentification (AH) permettent de garantir qu'un paquet n'a pas été modifié au cours de son transfert, leur utilisation à cette fin n'est pas compatible avec la traduction d’adresses réseau (NAT). Le protocole ESP, généralement destiné au chiffrement du trafic, peut être utilisé en mode de chiffrement « null » (ESP/null) en vue d'une vérification compatible NAT de l'intégrité des données.

IPsec est également capable de fonctionner dans deux modes différents : transport ou tunnel. Le mode « transport » d'IPsec est la méthode recommandée pour sécuriser le trafic entre deux hôtes. Il fonctionne simplement en insérant un en-tête à la suite de l'en-tête IP d'origine, puis il chiffre le reste du paquet à l'aide du protocole AH ou du protocole ESP. Le mode « tunnel » est généralement utilisé pour les tunnels VPN de passerelle à passerelle dans lesquels les paquets et les en-têtes IP d'origine sont entièrement encapsulés pour être remplacés par un nouvel en-tête IP IPsec.

Pour plus d'informations, reportez-vous à la page Isolation de serveurs et de domaines de Microsoft (cette page peut être en anglais) à l'adresse suivante : www.microsoft.com/technet/itsolutions/network/sdiso/default.mspx.

Défense renforcée

Figure 4. Modèle de défense renforcée avec isolation logique

La figure précédente illustre la manière dont l'isolation logique s'intègre au modèle de défense renforcée. Même si l'isolation de domaines et de serveurs semble se concentrer sur l'ordinateur hôte comme le ferait un pare-feu basé sur l'hôte, cette solution s'inscrit toujours dans le domaine des communications réseau de par son utilisation d'IPsec. Bien qu'elle comble le vide entre l'hôte et le réseau interne, elle ne se situe complètement sur aucun de ces deux éléments, étant donné qu'il s'agit d'une solution d'« isolation logique ». De ce fait, les fonctionnalités suivantes se trouvent hors de son champ d'action :

• L'isolation logique ne peut pas sécuriser les périphériques réseau, tels que les routeurs.

• L'isolation logique ne peut pas sécuriser les liaisons réseau, contrairement au protocole 802.11i WPA pour le chiffrement sans fil et le protocole 802.1x EAP-TLS pour le contrôle des accès sans fil.

• L'isolation logique ne peut pas sécuriser l'ensemble des hôtes du réseau, étant donné qu'elle gère uniquement les systèmes comportant une identification approuvée et une stratégie IPsec de domaine.

• L'isolation logique est inadaptée à la sécurisation des chemins au niveau des applications et ne comporte aucune méthode configurable à cet effet, contrairement à HTTPS et SSL pour les applications Web.

Il est essentiel de comprendre et de tenir compte du rôle joué par l'isolation logique au sein d'une solution de défense renforcée. En soi, cette solution ne peut pas sécuriser l'ensemble d'une infrastructure d'entreprise de taille moyenne. Toutefois, lorsqu'elle est intégrée à une solution complète, elle peut jouer un rôle précieux.

Utilisation des services de quarantaine VPN pour se protéger contre les ordinateurs distants non gérés

Du point de vue des stratégies de sécurité, les systèmes distants qui utilisent des solutions VPN pour accéder à un réseau d'entreprise posent des problèmes exceptionnels. La plupart des solutions d'accès à distance valident les informations d'identification des utilisateurs distants, mais ne vérifient pas si les ordinateurs distants sont conformes aux stratégies de sécurité. L'approche de validation pose problème du fait qu'elle est susceptible d'ignorer certaines des protections du réseau contre les menaces, telles que les fichiers de signatures de logiciel malveillant non mis à jour, les niveaux de mises à jour de sécurité obsolètes, les paramètres de routage incorrects et l'absence de protection par pare-feu adéquate.

La fonctionnalité de contrôle de quarantaine pour l'accès réseau (Network Access Quarantine Control) de Microsoft Windows Server 2003 permet de résoudre ce problème en retardant l'accès distant à un VPN jusqu'à ce que l'état de configuration de l'ordinateur qui se connecte puisse être garanti comme étant conforme aux normes de stratégie de sécurité actuelles.

Présentation des services de quarantaine VPN

Le contrôle de quarantaine pour l'accès réseau est une fonctionnalité fournie dans la famille Windows Server 2003 permettant de retarder les services d'accès distant normaux jusqu'à ce que les ordinateurs distants qui essaient de se connecter soient étudiés et validés par un script configuré par l'administrateur. Généralement, lorsqu'une session à distance est lancée, l'utilisateur est authentifié et l'ordinateur distant reçoit une adresse IP. À ce stade, la connexion est placée en mode de quarantaine avec un accès réseau limité jusqu'à ce que le script fourni par l'administrateur soit exécuté sur l'ordinateur distant. Une fois le script exécuté, il indique au serveur d'accès distant que l'ordinateur distant est conforme aux stratégies réseau configurées. La quarantaine est alors supprimée et l'ordinateur distant peut accéder au réseau.

Lorsqu'une connexion à distance est en mode de quarantaine, il est possible de lui appliquer les restrictions suivantes :

• Vous pouvez configurer un ensemble de filtres de paquets de quarantaine afin de limiter le type de trafic que le client peut initier ou recevoir.

• Vous pouvez configurer une minuterie de session de quarantaine pour limiter la durée pendant laquelle un client peut resté connecté lorsqu'il est en mode quarantaine.

Le contrôle de quarantaine pour l'accès réseau peut être intégré à une solution de sécurité complète permettant d'appliquer les stratégies de sécurité et d'empêcher que les systèmes non approuvés puissent se connecter au réseau approuvé. Toutefois, il ne s'agit pas d'une solution de sécurité en soi : il ne peut pas empêcher les connexions des utilisateurs malveillants qui ont obtenu un ensemble d'informations d'identification valide.

Remarque   Le contrôle de quarantaine pour l'accès réseau est une technologie différente de la protection de l’accès réseau (NAP, Network Access Protection), la nouvelle plate-forme de mise en application des stratégies qui sera intégrée dans la future famille de systèmes d'exploitation Windows Server. Pour plus d'informations sur NAP, reportez-vous à l'« Annexe A : Protection de l'accès réseau » à la fin de ce document.

Composants du contrôle de quarantaine pour l'accès réseau

Figure 5. Composants du contrôle de quarantaine pour l'accès réseau Windows

La figure précédente dépeint la composition typique d'une solution d'accès distant Windows qui utilise le contrôle de quarantaine pour l'accès réseau. Ces composants sont les suivants :

• Client d'accès distant compatible avec la quarantaine. Ce composant est un ordinateur exécutant une version Windows capable de prendre en charge les profils CM créés à l'aide du kit d'administration du gestionnaire de connexions (CMAK, Connection Manager Administration Kit), fourni avec Windows Server 2003. Les versions Windows offrant cette prise en charge sont les versions Windows 98 Deuxième édition et ultérieures. Ces ordinateurs clients doivent comporter un composant notificateur installé, un script relatif aux exigences de stratégie réseau et doivent être configurés pour exécuter ce script en tant qu'action post-connexion.

• Serveur d'accès distant compatible avec la quarantaine. Ce composant est un ordinateur Windows Server 2003 exécutant le service de routage et d'accès distant (RRAS, Routing and Remote Access), lequel prend en charge l'utilisation d'un composant écouteur en association avec les attributs spécifiques des fournisseurs (VSA) RADIUS suivants : MS-Quarantine-IPFilter et MS-Quarantine-Session-Timeout.

• Serveur RADIUS compatible avec la quarantaine. Ce composant facultatif est utilisé lorsque l'authentification RADIUS est configurée sur le serveur d'accès distant exécutant Windows Server 2003 et IAS pour la prise en charge des VSA RADIUS MS-Quarantine-IPFilter et MS-Quarantine-Session-Timeout.

• Ressources de quarantaine. Ces composants correspondent aux serveurs et aux services auxquels le client distant peut accéder lorsqu'il est en mode quarantaine. Généralement, il s'agit de serveurs fournissant des services DNS, des profils CM ou des fournisseurs de mises à jour de sécurité afin de mettre les clients en conformité.

• Base de données de comptes. Généralement, ce composant correspond au domaine Active Directory où est stocké le compte de l'utilisateur distant et où se situent les propriétés de numérotation.

• Stratégie d'accès distant de quarantaine. Cette stratégie est indispensable pour fournir les conditions requises à l'établissement des connexions distantes et pour préciser les attributs MS-Quarantine-IPFilter ou MS-Quarantine-Session-Timeout.

Défense renforcée

Figure 6. Défense renforcée et contrôle de quarantaine pour l'accès réseau

Comme l'illustre cette adaptation du modèle de défense renforcée Microsoft, la quarantaine VPN s'étend sur trois couches du modèle : l'hôte, le réseau interne et le périmètre. Bien que cette solution ne sécurise pas directement le client, elle permet de sécuriser les serveurs contre les menaces pouvant être introduites par les clients distants qui ne répondent pas aux exigences de sécurité. De manière indirecte, elle sécurise également les clients distants. En effet, en s'assurant qu'ils répondent aux exigences de stratégie afin de fonctionner efficacement, elle les encourage à appliquer les dernières mises à jour.

Par ailleurs, cette solution améliore la protection du réseau en lui-même contre les effets perturbateurs pouvant être causés par les ordinateurs distants lorsqu'ils ne sont pas configurés correctement, tels que la propagation de logiciels malveillants à l'origine de ralentissement des performances réseau. Même si le périmètre ne semble pas concerné par cette solution du fait qu'elle ne protège pas directement le VPN (qui réside dans le périmètre) contre les attaques en force, elle fournit néanmoins une couche de sécurité supplémentaire face aux tentatives d'accès direct aux ressources du réseau interne par les utilisateurs malveillants, et ce même si ces derniers sont parvenus à obtenir des informations d'identification.

Utilisation de l'authentification 802.1X pour se protéger contre les clients sans fil non gérés

La norme 802.1X de l'Institute of Electrical and Electronics Engineers (IEEE) est particulièrement bien adaptée au contexte de la défense des réseaux sans fil contre les actions non autorisées. Plus simplement, si un ordinateur n'est pas configuré pour être autorisé à communiquer sur le réseau, il ne pourra tout simplement pas y parvenir. Bien que cette solution d'authentification fonctionne bien sur les réseaux sans fil, l'utilisation de cette norme sur les réseaux câblés s'avère peu efficace. C'est la raison pour laquelle, dans le cadre de la sécurisation d'un réseau d'entreprise de taille moyenne, ce document recommande une approche combinée. La combinaison des solutions les plus efficaces permet de traiter chacun des aspects d'un réseau d'entreprise type, et de mettre ainsi en place une solution de défense renforcée.

Présentation de l'authentification IEEE 802.1X

L'authentification IEEE 802.1X est un mécanisme de contrôle d'accès basé sur les ports pouvant être configuré pour rendre obligatoire l'authentification entre des clients et un réseau. Lorsqu'elle est mise en œuvre, tout périphérique qui échoue à l'authentification se voit refuser toute communication avec le réseau concerné.

La norme 802.X prend en charge le protocole EAP (Extensible Authentication Protocol), lequel comporte un certain nombre de variantes dont trois sont immédiatement prises en charge par les versions actuelles de Microsoft Windows :

• EAP-MD5 : dans le cas de MD5, un serveur d'authentification envoie un défi à un client (suppliant). Le suppliant doit alors répondre à cette requête de défi à l'aide de son propre identifiant et de sa propre phrase de passe. Cette réponse est convertie en hachage MD5 et renvoyée au serveur d'identification qui la déchiffre et la fait correspondre au défi d'origine. Si la réponse correspond, l'authentification est validée. Dans la plupart des implémentations, cette méthode est peu sûre du fait que le mot de passe en lui-même est envoyé, pouvant ainsi être intercepté et déchiffré par des tiers.

• Protected EAP : le protocole PEAP (Protected EAP) utilise un certificat côté serveur et des informations d'authentification provenant du client (tels que des noms d'utilisateur et des mots de passe) afin d'établir une authentification mutuelle. L'implémentation de cette norme par Microsoft utilise le protocole MS-CHAPv2, lequel s'appuie sur les informations de compte de domaine et mot de passe habituelles et sur un serveur RADIUS pour établir cette authentification. Cette méthode est généralement considérée comme suffisamment sûre pour les environnements de petite taille qui ne peuvent pas se permettre les exigences supplémentaires requises par la méthode EAP-TLS en termes d'administration et d'infrastructure.

• EAP-TLS : dans cette méthode, un serveur d'authentification établit une session TLS (Transport Layer Security) avec le suppliant pour l'envoi d'un certificat numérique au client. Le suppliant valide ce certificat lorsqu'il le reçoit et envoie son propre certificat en réponse, lequel est à son tour validé par le serveur d'authentification. Dès lors que chacune des parties reconnaît le certificat de l'autre, l'authentification est validée. Cette approche convient particulièrement bien aux réseaux capables de prendre en charge une infrastructure PKI et des serveurs d'authentification RADIUS. Il s'agit également de l'option la plus sûre disponible pour les réseaux sans fil, particulièrement lorsqu'elle est combinée avec la norme 802.11i WPA2.

Avant d'être authentifié par le serveur d'authentification, le client doit s'appuyer sur l'authentificateur (un point d'accès sans fil ou un commutateur réseau). De ce fait, lors de la négociation d'authentification initiale, l'authentificateur est chargé de transférer toutes les communications entre le suppliant et le serveur d'authentification. Lorsque l'authentification est validée, le suppliant peut alors accéder directement au réseau.

En quoi la norme 802.1X n'est pas adaptée pour les réseaux câblés

Alors qu'elle permet généralement de sécuriser efficacement les réseaux sans fil, la norme 802.1X pose un certain nombre de problèmes lorsqu'elle est mise en œuvre pour sécuriser les réseaux câblés. Le premier problème est dû au fait que, bien qu'elle comporte plusieurs objets de stratégie de groupe Active Directory qui prennent en charge sa mise en œuvre sur les réseaux sans fil, ces derniers ne prennent pas son authentification en charge sur les réseaux câblés. De ce fait, une telle mise en œuvre de la norme 802.1X nécessiterait une surcharge significative en termes de gestion. Par ailleurs, de nombreux commutateurs, périphériques d'impression réseau et autres périphériques d'infrastructure de réseau câblé ne prenant pas en charge la norme 802.1X, sa mise en œuvre générerait des mises à niveau coûteuses pour la plupart des réseaux d'entreprise de taille moyenne.

Outre les coûts d'administration et d'infrastructure liés à une telle mise en œuvre, l'utilisation de cette norme destinée à l'origine aux réseaux sans fil pose des problèmes de sécurité avec les réseaux câblés. Ainsi, étant donné que la norme 802.1X ignore les concentrateurs (hubs) et que son authentification ne se produit que lorsqu'une connexion est établie, il suffirait à un utilisateur de relier un concentrateur au réseau interne avec un ordinateur authentifié et un ordinateur « virtuel » pour lancer une attaque.

Remarque   Ces inconvénients et vulnérabilités spécifiques ne concernent pas les réseaux sans fil. Ces questions relatives à la sécurité de la norme 802.1X ne se posent que lorsqu'elle est utilisée avec les réseaux câblés.

Toutes ces raisons justifient la recommandation d'IPsec plutôt que 802.1X pour l'isolation de serveurs et de domaines. Toutefois, cela ne signifie pas pour autant que la norme 802.1X est à proscrire pour les réseaux d'entreprise de taille moyenne. Comme indiqué précédemment, cette norme est un outil précieux qui permet de résoudre les questions de sécurité des réseaux sans fil, et dont l'efficacité est renforcée par l'ajout d'une solution d'isolation réseau basée sur IPsec.

Défense renforcée

Figure 7. Sécurité sans fil 802.1X dans le cadre de la défense renforcée

Comme l'illustre la figure précédente, la sécurité sans fil basée sur l'authentification 802.1X occupe la couche réseau du modèle de défense renforcée. Même si la sécurité sans fil semble aussi s'étendre sur le périmètre, les réseaux sans fil correspondent en fait à une partie de réseau local alors que le périmètre concerne davantage les réseaux externes tels qu'Internet. Certaines parties des méthodes de sécurité sans fil comportent des composants hôtes, mais ce type de sécurité n'est pas conçu pour protéger l'hôte directement.

Utilisation de SMS pour détecter les systèmes non gérés et résoudre les problèmes associés

Microsoft Systems Management Server (SMS) 2003 est généralement utilisé pour gérer les ordinateurs sur le réseau, consigner les données d'inventaire relatives aux ressources et fournir des logiciels et des mises à jour afin de maintenir la conformité avec les stratégies de sécurité et d'assurer l'adéquation entre les plates-formes et les installations logicielles. Si ce document traite des fonctionnalités de détection et d'inventaire de SMS 2003, c'est parce qu'elles fournissent une méthode de détection des systèmes non approuvés lorsqu'ils se connectent au réseau. Selon les stratégies mises en œuvre en réponse à l'utilisation d'ordinateurs non gérés, elles peuvent également s'avérer utiles pour la résolution des problèmes.

Ce document suppose que le lecteur a utilisé SMS et d'autres méthodes pour mettre les ordinateurs membres du domaine en conformité avec les stratégies de sécurité, ce qui inclut les mises à jour de sécurité. De ce fait, il ne traite pas de la gestion des correctifs relatifs à SMS 2003 et aux autres outils. Pour plus d'informations sur ces rubriques et sur d'autres questions liées à SMS, reportez-vous à l'accélérateur de solution Patch Management Using SMS 2003 à l'adresse suivante : www.microsoft.com/technet/itsolutions/cits/mo/swdist/pmsms/2003/pmsms031.mspx ou à la page d'accueil Microsoft Systems Management Server à l'adresse suivante : www.microsoft.com/smserver/default.mspx.

Découvrir et documenter les ressources existantes

Dans le cas des entreprises qui ont déjà implémenté SMS, il est probable que la documentation sur les ressources existantes et l'inventaire des systèmes gérés et non gérés ont déjà été effectués. Ce type d'inventaire doit comporter des informations sur les conditions de mises à jour de sécurité et les procédures relatives aux ordinateurs qui ne sont pas gérés par SMS, que ce soit du fait de leur conception ou parce qu'il n'existe aucun agent fonctionnel pour ce type de client. Ces ordinateurs non gérés comprennent notamment les périphériques du périmètre sécurisé (également appelé zone démilitarisée ou DMZ et sous-réseau filtré), des ordinateurs de test ou des périphériques autonomes.

Il est essentiel de disposer d'une liste bien documentée des périphériques non gérés par SMS, non seulement pour les exigences de sécurité, mais aussi parce qu'une telle liste permet d'effectuer une comparaison avec les nouvelles données d'inventaire afin de déterminer si les systèmes récemment détectés sont autorisés ou inconnus. Pour maintenir ce type de liste à jour, il est essentiel de mettre en place un processus relatif à l'ajout de nouveaux systèmes non gérés au réseau d'entreprise ; ce processus doit non seulement comporter des informations d'identification, mais il doit également intégrer la sécurisation de ces systèmes et les définitions de propriété.

Il se peut que SMS ne soit pas en mesure de récupérer d'autres informations qu'une adresse IP et un nom, mais ces dernières suffisent généralement à déterminer si les périphériques réseau sont autorisés ou non.

Développement

La section « Évaluation » a montré que l'approche la plus complète pour la défense d'un réseau d'entreprise de taille moyenne est la combinaison d'un ensemble de solutions différentes dédiées à des fonctions spécifiques de ce réseau. L'isolation de domaines et de serveurs couvre le réseau câblé afin de s'assurer que seuls les ordinateurs connus et gérés peuvent accéder aux ressources approuvées. La quarantaine VPN garantit que les systèmes distants qui ne se connectent qu'occasionnellement au réseau local demeurent conformes aux stratégies de sécurité. L'authentification 802.1X sécurise le réseau sans fil de sorte que seules les machines autorisées peuvent établir des connexions. Enfin, SMS permet de maintenir les ordinateurs approuvés à jour et de détecter les ordinateurs non autorisés et non approuvés lorsqu'ils se connectent au réseau. Toutes ces solutions sont combinées dans le but de protéger les réseaux contre les connexions et les ordinateurs non autorisés.

Outre les conditions requises pour l'implémentation de ces solutions, cette section traite également des éventuels problèmes devant être résolus pour garantir que chacune de ces solutions est l'approche qui convient le mieux à chaque environnement d'entreprise de taille moyenne.

Utilisation d'IPsec pour l'isolation de domaines et de serveurs

Avant de développer un plan pour implémenter une isolation de domaines et de serveurs à l'aide d'IPsec pour un environnement réseau donné, il est nécessaire de déterminer si cette solution est applicable ou non et de récupérer les informations relatives aux conditions requises. Le concept d'isolation réseau IPsec a été présenté dans la section « Évaluation » de ce document. À présent que les avantages de cette approche sont connus, il est possible de la confronter aux éventuels problèmes liés à ce type de mise en œuvre. Cette section traite des conditions requises et de certains problèmes liés à l'implémentation d'une isolation de réseau à l'aide d'IPsec afin de vous assister dans le processus de prise de décision.

Identification de l'architecture réseau

IPsec est situé au niveau de la couche du Protocole Internet lui-même, il est donc essentiel d'avoir une connaissance approfondie de l'infrastructure réseau et du flux de trafic actuels pour déployer cette solution avec succès. Même s'il est important d'identifier les informations relatives aux schémas d’adressage IP, aux configurations des sous-réseaux et aux modèles de trafic réseau, il est absolument indispensable de disposer d'une documentation détaillée sur la segmentation réseau et un modèle de flux de trafic réseau à jour pour pouvoir déployer avec succès un plan d'isolation réseau efficace.

Remarque   Ce document ne traite pas des détails de la phase de documentation de l'environnement réseau. La création de ce type de documentation est essentielle à la réussite de toute initiative de sécurité réseau globale telle que la présente. De ce fait, jusqu'à ce que de telles initiatives documentaires ne soient menées à bien, l'inefficacité de l'implémentation constitue un risque potentiel qui doit être envisagé pour des projets tels que celui-ci.

La documentation de l'architecture réseau doit refléter avec précision les détails actuels par rapport aux points suivants :

• Informations détaillées sur les pare-feu et leurs emplacements

• Informations relatives aux périphériques réseau, notamment la taille de la RAM, la marque/le modèle et les paramètres MTU

• Rapports sur le trafic et l'utilisation du réseau

• Utilisation NAT

• Segmentation VLAN

• Liaisons réseau des périphériques

• Informations du système de détection d'intrusion (IDS)

Identification du flux du trafic réseau

Outre les informations sur les périphériques et les configurations pouvant affecter l'isolation réseau par IPsec, il est important d'étudier les modèles de trafic réseau au sein du réseau. Lors de la collecte de ce type d'informations, il est nécessaire de tenir compte de facteurs tels que la manière dont communiquent les périphériques non-Windows (par exemple des ordinateurs Linux) ou exécutant des versions antérieures à Windows 2000 SP4 avec les autres systèmes Windows. Autres facteurs à prendre en compte :

• Les sous-réseaux sont-ils dédiés à des types de trafic spécifiques, tels que les communications des macroordinateurs ?

• Est-il nécessaire de séparer le trafic entre les divers emplacements ?

• Certains types de trafic, tels que les communications avec les bases de données RH, nécessitent-ils un niveau de chiffrement élevé ?

• Certains périphériques de sécurité ou certains pare-feu peuvent-il avoir un impact sur l'implémentation, tel que le blocage du port 500 ?

• De quelle manière les applications communiquent-elles ? Par exemple, utilisent-elles l'appel de procédure distante (RPC), sachant que cette fonctionnalité nécessite une attention supplémentaire ?

• Comment les hôtes et les serveurs communiquent-ils entre eux ? Utilisent-il des connexions de niveau port/protocole ou établissent-ils des sessions multiples étendues sur une large gamme de protocoles ?

Identification de la structure Active Directory

Pour comprendre l'impact de la mise en œuvre d'IPsec sur une structure Active Directory, en plus des informations réseau identifiées précédemment, il est nécessaire de collecter des informations sur la structure de forêt d'Active Directory, la disposition du domaine, la conception de l'unité d'organisation et la topologie du site. Ces informations doivent intégrer les éléments suivants :

• Nombre de forêts

• Nombre et noms des domaines

• Nombre et types des relations approuvées

• Nombre et noms des sites

• Structure de l'unité d'organisation et de la stratégie de groupe

• Toute information relative aux stratégies IPsec existantes (le cas échéant)

Identification des hôtes

Les informations pertinentes relatives aux hôtes devant être collectées sont les suivantes :

• Noms des ordinateurs

• Adresses IP, et tout particulièrement les adresses statiques

• Adresses MAC

• Version du système d'exploitation, ainsi que les niveaux de service pack et de révision des correctifs

• Appartenance au domaine

• Emplacement physique

• Type et rôle du matériel

Identification des questions relatives à la capacité IPsec

Lors du développement d'un plan d'implémentation d'IPsec, certains facteurs liés à la planification des capacités sont à prendre en compte, en particulier lorsqu'il s'agit du chiffrement IPsec, du fait de son niveau d'exigence élevé en termes d'utilisation de l'hôte et de surcharge du réseau. Les facteurs à prendre en compte sont les suivants :

• Utilisation de la mémoire du serveur. Chaque session peut consommer jusqu'à 5 Ko de RAM.

• Utilisation du processeur du serveur, de la station de travail et du périphérique d'infrastructure. Ces informations sont particulièrement importantes pour les serveurs. Assurez-vous que les périphériques ne sont pas déjà en sur-utilisation.

• Utilisation et latence du réseau. L'utilisation d'IPsec accroît la latence du réseau. Lorsque Microsoft a déployé IPsec, l'utilisation du réseau est passée de 1 % à 3 %.

• Utilisation du type de chiffrement NAT. Les communications AH ne peuvent pas franchir les traductions d’adresses réseau (NAT). De ce fait, c'est le protocole  ESP qui doit être utilisé pour chiffrer les communications. Le protocole ESP présente une surcharge d'utilisation plus élevée que le chiffrement AH, à moins d'utiliser le chiffrement ESP « null ».

• Impact de la stratégie de groupe. Les objets de stratégie de groupe (GPO) IPsec ont un impact sur les temps de démarrage et d'ouverture de session des ordinateurs. Il est recommandé d'effectuer des points de comparaison avant et après les implémentations de test afin de déterminer leur impact réel sur ces temps.

Identification des niveaux de fiabilité

Déterminer quels sont les hôtes qui contribuent à cette solution, et dans quelle mesure. Pour ce faire, il est nécessaire d'établir une définition claire des conditions à remplir pour être approuvé et des éventuels niveaux de fiabilité. Les informations suivantes peuvent s'avérer utiles car elles proposent quelques définitions précises de la fiabilité, des critères nécessaires pour atteindre certains niveaux de fiabilité et la manière dont ces derniers influent sur le processus de planification.

Il existe quatre états de base pouvant être appliqués à un hôte en matière de niveau de fiabilité. Les états relatifs au niveau de fiabilité sont les suivants, du plus élevé au moins élevé :

• Approuvé. Un état « approuvé » implique que les risques liés à la sécurité d'un hôte sont gérés et que d'autres hôtes approuvés peuvent raisonnablement supposer qu'il ne sera à l'origine d'aucune action malveillante. Cet état ne signifie par nécessairement que cet hôte est totalement sécurisé, mais il garantit qu'il est sous la responsabilité d'un département informatique et qu'il est géré par un mécanisme, qu'il s'agisse d'un processus automatique ou documenté.

  Cet hôte étant approuvé, sa communication avec les autres hôtes approuvés ne doit pas être entravée par l'infrastructure réseau. Étant donné qu'il est raisonnable de partir du principe qu'aucune action malveillante ne sera commise par cet hôte, il est inutile de bloquer ou filtrer le trafic qui en provient à l'aide de pare-feu ou de mesures de préventions semblables.

• Fiable. Un état « fiable » indique que, même s'il est en mesure de passer au stade de périphérique approuvé, l'ordinateur concerné nécessite certaines modifications de configuration ou diverses mises à jour pour pouvoir être certifié comme étant approuvé. L'identification de ce type d'ordinateurs est particulièrement importante lors de la phase de conception car ils vous donnent une idée de la somme d'efforts et de dépenses à entreprendre pour l'établissement d'un réseau isolé.

• Connu, non approuvé. Un certain nombre de facteurs peuvent empêcher un ordinateur de devenir une ressource approuvée, qu'il s'agisse de contraintes économiques, des besoins liés à l'activité ou encore des conditions opérationnelles. Ces motifs peuvent par exemple être les suivants : les fonds consacrés au projet sont insuffisants pour assumer la mise à niveau de tous les ordinateurs, certaines entités commerciales sont propriétaires de leurs propres domaines ou des anciennes applications incompatibles avec les systèmes d'exploitation actuels ne peuvent pas être exécutées sur un ordinateur sécurisé.

  Quel que soit le motif, il est nécessaire de s'adresser aux propriétaires de ces ordinateurs connus mais non approuvés afin de déterminer si une action peut être menée pour les mettre en conformité et décider de la manière de traiter ce problème tout en maintenant un profil de risque acceptable.

• Inconnu, non approuvé. L'état « inconnu, non sécurisé » doit être attribué par défaut à tous les hôtes. Les hôtes de ce type n'étant pas gérés et leurs configurations n'étant pas connues, aucun état de fiabilité de peut leur être attribué. Ces hôtes étant susceptibles d'être compromis et utilisés en tant que plates-formes pour des activités malveillantes, ils doivent être considérés comme un risque inacceptable pour l'entreprise. La solution présentée dans ce document est destinée à réduire l'impact potentiel de tels systèmes.

Utilisation des informations collectées

Une fois toutes les informations pertinentes collectées, il est alors possible de développer un plan de mise en œuvre et de déterminer si la solution d'isolation réseau par IPsec convient à l'environnement réseau concerné. Certains facteurs peuvent entrer en ligne de compte dans l'implémentation de cette solution :

• Coûts liés aux mises à niveau nécessaires pour élever les hôtes à l'état « approuvé » afin qu'ils soient conformes aux exigences IPsec.

• Coûts liés aux mises à niveau des infrastructures ou aux remplacements des périphériques réseau ne prenant pas en charge IPsec.

• Estimation du rapport entre l'éventuelle perte de QoS de routeur et les avantages sécuritaires de l'isolation de réseau. En effet, la mise en œuvre d'IPsec ne permet pas d'attribuer des priorités aux ports, mais permet au QoS d'adresse IP de fonctionner.

• La mise en œuvre d'IPsec risque d'entraver le bon fonctionnement des outils de surveillance réseau et des périphériques IDS, plus particulièrement lorsque le chiffrement ESP est utilisé. Si ces dispositifs sont dotés d'un analyseur IPsec, ce problème peut être résolu.

• La mise en œuvre d'IPsec peut nécessiter des mises à niveau matérielles du fait de l'augmentation de la surcharge et de la consommation du processeur et de la mémoire des serveurs et des périphériques réseau.

• La gestion des attentes peut s'avérer problématique du fait de l'accroissement de la latence du réseau.

• Il arrive que, pour des raisons professionnelles, des fournisseurs et autres utilisateurs invités doivent se connecter au réseau isolé pour accéder aux ressources qui s'y trouvent ; leurs périphériques n'étant pas approuvés, la gestion de ce type d'utilisateurs peut également générer une surcharge excessive. Ce type d'exceptions peut devenir difficile à gérer au fur et à mesure que leur nombre et leur fréquence augmentent ; néanmoins, l'utilisation d'une zone frontalière entre les réseaux approuvés et les réseaux non approuvés peut atténuer cette difficulté.

Ces points démontrent l'importance de procéder avec attention à une planification et à des tests complets avant de se lancer dans des modifications pouvant impliquer l'ensemble du réseau, telles que la mise en œuvre d'IPsec et de l'isolation du réseau. Il est également essentiel, avant d'envisager la manière d'effectuer cette mise en œuvre, d'évaluer sa faisabilité, en tenant compte de l'état actuel du réseau et des implications financières et stratégiques de sa mise en conformité. Par ailleurs, des déploiements limités ou incrémentiels peuvent également être envisagés en tant que stratégie d'atténuation pour ces différentes questions.

Encore une fois, l'isolation du réseau par IPsec ne constitue qu'une partie d'une solution globale et complète. Chaque solution présentée dans ce guide contribue à la défense contre les périphériques non approuvés susceptibles de se connecter au réseau, mais chacune des parties de ces solutions peut également, individuellement, augmenter le niveau de sécurité d'un réseau donné. De ce fait, même si l'isolation IPsec de domaines et de serveurs ne constitue pas une solution acceptable pour l'instant, elle peut malgré tout s'avérer utile pour implémenter les autres solutions présentées dans ce document. Par ailleurs, il est toujours possible d'y revenir lorsque le réseau aura évolué pour se conformer aux conditions requises définies dans ce document.

Utilisation des services de quarantaine VPN pour se protéger contre les ordinateurs distants non gérés

Lorsqu'un client d'accès distant lance une session sur un serveur d'accès distant Windows, les actions suivantes se produisent :

1. Le serveur d'accès distant s'assure de la conformité aux stratégies d'accès distant configurées et autorise la connexion.

2. Le serveur vérifie les autorisations d'accès distant de l'utilisateur.

3. Le serveur authentifie ensuite les informations d'identification de l'utilisateur à l'aide d'un service d'authentification, tel que le service Active Directory.

4. Le serveur attribue une adresse IP au client distant.

À ce stade, le client distant bénéficie d'un accès total au réseau alors qu'aucune vérification n'a été effectuée quant aux niveaux des mises à jour, la présence ou l'état de mise à jour des logiciels antivirus et tout autre information liée aux stratégies de sécurité. Cette fonctionnalité est loin d'être optimale du fait que les mises à jour, les modifications de configuration ou les correctifs risquent de ne pas avoir été appliqués aux utilisateurs distants ou aux ordinateurs non sécurisés.

Comme l'illustrent la figure et la liste numérotée suivantes, ce n'est pas le cas d'une connexion par quarantaine VPN :

Figure 8. Processus de quarantaine VPN

1. Le client distant exécute un script de pré-connexion du gestionnaire des connexions qui vérifie les conditions requises de base relatives à la connexion (telles que le niveau des mises à jour de sécurité et la date du fichier de signatures de virus) et enregistre les résultats de cette vérification. Après avoir exécuté ce script, le client établit une session d'accès distant via un tunnel VPN.

2. Le serveur d'accès distant authentifie les informations d'identification de l'utilisateur via RADIUS, lequel s'appuie sur Active Directory pour cette vérification.

3. Dès qu'Active Directory a authentifié l'utilisateur, le serveur d'accès distant place le client en état de quarantaine en appliquant la stratégie d'accès distant. Lors de la quarantaine, l'accès réseau est limité en fonction des précisions de la stratégie de quarantaine. Cet accès limité peut être effectué via un filtre IP (qui limite l'accès à des ressources spécifiques pouvant être utilisées pour mettre un client en conformité) ou en précisant un délai d'expiration (le client est déconnecté après un certain temps).

4. Un script de post-connexion indique au serveur d'accès distant si le client est en conformité ou non avec les conditions requises spécifiées. Si la connexion ne remplit pas les conditions requises avant un certain délai, elle est abandonnée et l'utilisateur reçoit des informations détaillées sur cet échec.

5. Si le script de post-connexion indique que le client remplit les conditions requises précisées, le serveur d'accès distant retire le client du mode quarantaine en supprimant les limitations du filtre IP, lui autorisant ainsi l'accès aux ressources réseau spécifiées dans la stratégie d'accès distant.

Un client d'accès distant peut accéder uniquement aux ressources qui résident sur le réseau de quarantaine spécifié, qu'il s'agisse d'un sous-réseau ou d'un ensemble défini de serveurs Internet. Un réseau de quarantaine doit fournir des ressources permettant à un client distant de mener les actions nécessaires pour mettre un ordinateur en conformité avec les normes de sécurité. Généralement, ces ressources comprennent un serveur DNS pour la résolution des noms, un serveur de fichiers pour l'obtention des mises à jour et éventuellement un serveur Web pour les instructions ou les mises à jour Web.

L'utilisation d'un sous-réseau de quarantaine dans ce processus nécessiterait des paramètres d'expiration de session plus longs pour garantir que l'ordinateur client distant dispose d'un délai suffisant pour le téléchargement et l'installation des mises à jour. Pour éviter ce problème, l'ordinateur client pourrait être redirigé afin d'utiliser d'autres sources ou des serveurs de mises à jour Internet en dehors de la session VPN, mais cette approche nécessiterait un script plus complexe et présenterait d'autres problèmes de sécurité. Dans les deux cas, c'est le script qui détermine le comportement de la quarantaine, et non pas le réseau de quarantaine lui-même.

Remarque   Les stratégies IPsec peuvent s'appuyer sur un script si la solution de quarantaine doit s'adapter à des systèmes non associés à un domaine. En pareil cas, il est possible d'utiliser la commande netsh ou l'exécutable lpseccmd.exe pour appliquer des stratégies simples comportant des certificats et assurer ainsi la prise en charge de l'authentification IPsec. Par ailleurs, IPsec peut non seulement s'appliquer à des systèmes associés à un domaine dans des configurations de quarantaine VPN, mais aussi agir en tant que solution de couches.

Composants du client de quarantaine VPN

Comme indiqué dans la section précédente, la première étape du processus de quarantaine VPN commence par le client, et tout particulièrement par le script de pré-connexion du gestionnaire de connexions. Le gestionnaire de connexions est un élément du kit d'administration du gestionnaire de connexions (CMAK, Connection Manager Administration Kit), lequel centralise et automatise l'établissement et la gestion des connexions réseau et prend en charge plusieurs domaines clés de la configuration de quarantaine VPN, notamment :

• Contrôles de sécurité de pré-connexion pour la gestion automatique des configurations des ordinateurs clients.

• Contrôles de sécurité de post-connexion et validations des ouvertures de session.

Le gestionnaire des connexions permet aux administrateurs de définir des actions personnalisées via des profils pouvant être distribués à plusieurs ordinateurs. Cette fonctionnalité simplifie le processus de connexion des utilisateurs distants en limitant le nombre de paramètres qu'ils sont autorisés à modifier. Les paramètres pouvant être modifiés sont, entre autres, les suivants :

• Établissement de listes de numéros de téléphone pouvant être utilisés pour les connexions distantes.

• Personnalisation des images, des icônes, des messages et du texte de l'Aide.

• Exécution d'actions personnalisées de pré-connexion et de post-connexion, par exemple la réinitialisation du profil de numérotation ou la configuration des règles de filtre des paquets du pare-feu Windows.

Parmi les composants CMAK se trouve également l'agent client (RQC.exe), lequel communique avec le service de quarantaine pour les clients distants (RQS.exe) sur le serveur d'accès distant à l'aide du port TCP 7250. Lorsqu'une connexion de quarantaine est établie, le RQS envoie au RQC une clé partagée secrète. Si le client remplit les conditions requises, le RQC envoie cette clé partagée afin de le libérer de la quarantaine.

Les profils du gestionnaire de connexions sont des paquets de numérotation de client du gestionnaire de connexions auto-extractibles et personnalisés ; il peuvent être créés et configurés à l'aide de CMAK. L'Assistant du CMAK guide les administrateurs tout au long du processus de configuration du profil, lequel peut ensuite être distribué à l'aide d'un certain nombre de mécanismes allant de la stratégie de groupe à la distribution de logiciels de SMS 2003 (Systems Management Server) de Microsoft. Lorsque l'exécutable créé est exécuté sur l'ordinateur client, il installe le profil sur l'ordinateur local, ainsi que les paramètres nécessaires à l'établissement de communications avec les serveurs d'accès distant. Lorsque l'installation est terminée, pour établir une connexion, l'utilisateur doit juste initialiser le nom du profil dans le menu Connexion de Windows XP.

Pour plus d'informations sur CMAK, reportez-vous à la page du kit d'administration de Connection Manager (cette page peut être en anglais) sur Microsoft TechNet à l'adresse suivante : technet2.microsoft.com/WindowsServer/fr/library/be5c1c37-109e-49bc-943e-6595832d57611036.mspx.

Composants du serveur de quarantaine VPN

Le serveur d'accès distant VPN est le composant central de cette solution. Il remplit les fonctions suivantes :

• Exécution du service de quarantaine pour les clients distants (RQS.exe).

• Mise en application des stratégies d'accès distant pour les paramètres d'accès de quarantaine.

• Négociation des communications avec l'agent client.

• Réception des informations de conformité aux stratégies en provenance de l'agent client.

• Mise en application des stratégies d'accès distant pour déterminer les autorisations d'accès aux ressources réseau.

Le service de quarantaine pour les clients distants (RQS) est un composant optionnel de Windows Server 2003 Service Pack 1 qui prend en charge les API nécessaires à la mise en quarantaine des ordinateurs clients distants et à leur libération lorsque l'agent client envoie une notification de conformité aux stratégies. Ce service (RQS.exe) écoute le port TCP 7250 pour détecter la notification provenant du composant côté client (RQC.exe) et indiquant que l'ordinateur client remplit les conditions requises par les stratégies. Pour que cette fonctionnalité puisse fonctionner, tous les pare-feu, y compris les pare-feu basés sur les hôtes, doivent autoriser le trafic sur le port TCP 7250.

Composants du réseau de quarantaine VPN

Les composants réseau suivants comprennent des éléments obligatoires et facultatifs pouvant s'intégrer à la solution de réseau de quarantaine VPN.

• Serveur RADIUS IAS (Internet Authentication Service) (recommandé). Bien que les serveurs IAS ne soient nécessaires que si RADIUS est utilisé comme fournisseur d'authentification, ils présentent de nets avantages sur les autres solutions d'authentification, notamment la prise en charge du protocole EAS pour l'authentification bi-facteurs par certificat et carte à puce. Si RADIUS est utilisé, il est recommandé d'utiliser le service IAS fourni avec Windows Server 2003 en tant que fournisseur RADIUS du fait que, contrairement à certains autres serveurs RADIUS, il prend en charge les attributs spécifiques des fournisseurs MS-Quarantine Session Timeout et MS-Quarantine-IPFilter.

• Active Directory (recommandé). Active Directory fait office de base de données d'authentification de compte utilisateur pour RADIUS et s'intègre avec IAS et d'autres services. Lorsqu'il est utilisé conjointement avec IAS, il peut prendre en charge l'authentification bi-facteurs par certificat ou via d'autres méthodes.

• Serveur DHCP (recommandé). Les serveurs DHCP permettent de fournir des adresses IP aux clients distants.

• Serveur DNS (recommandé). Les serveurs DNS fournissent des services de résolution de nom pour que les clients qui se trouvent dans le réseau de quarantaine puissent se connecter à d'autres serveurs (le cas échéant) afin de mettre les ordinateurs clients distants en conformité.

• Serveur WSUS (Windows Software Update Service) (facultatif). Les serveurs WSUS peuvent fournir les mises à jour et les correctifs dont les ordinateurs distants peuvent avoir besoin afin de remplir les conditions requises pour ne plus être placés en état de quarantaine. Si les ordinateurs doivent être redirigés vers des ressources externes pour obtenir les mises à jour, d'autres méthodes peuvent également être utilisées, notamment SMS 2003 ou même les services Windows Update standard.

• Serveur de fichiers (facultatif). Des serveurs de fichiers peuvent être utilisés pour fournir des partages dans lesquels les ordinateurs mis en quarantaine peuvent accéder à des mises à jour logicielles et à des fichiers de signatures antivirus afin de remplir les conditions requises par les stratégies.

• Serveur Web (facultatif). Des serveurs Web peuvent être utilisés en quarantaine afin de fournir aux utilisateurs des instructions pour libérer leurs ordinateurs de la quarantaine. Certains packages de mise à jour utilisent également des composants Web pour la distribution, tels que certains produits antivirus.

Utilisation de l'authentification 802.1X pour se protéger contre les clients sans fil non gérés

Dans la section précédente, l'authentification 802.1X a été présentée comme l'option la plus efficace pour la protection des réseaux sans fil contre les ordinateurs non approuvés. Les diverses méthodes 802.1X prises en charge dans les versions actuelles de Microsoft Windows ont été décrites ; il a également été expliqué pourquoi l'authentification 802.1X s'avère peu efficace pour les réseaux câblés (bien qu'elle soit très efficace pour les réseaux sans fil). Avec ces informations, il est possible de traiter des différences entre les méthodes prises en charge et de déterminer laquelle est la plus adaptée aux différents types d'environnements réseau d'entreprise de taille moyenne.

Comparaisons des méthodes 802.1X

Comme indiqué précédemment, il existe trois méthodes 802.1X prises en charge dans les versions actuelles de Microsoft Windows. Ces méthodes sont les suivantes :

• EAP-MD5

• PEAP (Protected EAP)

• EAP-TLS

Parmi ces trois méthodes, la première (EAP-MD5) est considérée comme la moins sûre. En effet, les phrases de passe utilisées dans cette approche étant transmises par voie aérienne, elles sont susceptibles d'être interceptées. Les deux autres méthodes (PEAP et EAP-TLS), quant à elles, méritent d'être étudiées pour un déploiement dans les réseaux d'entreprise de taille moyenne.

La mise en œuvre Microsoft de PEAP utilise le protocole MS-CHAP v2 (Microsoft Challenge Handshake Authentication Protocol version 2). À l'origine, ce protocole était conçu pour l'authentification VPN mais il se prête relativement bien à PEAP du fait qu'il peut prendre en charge des stratégies de mot de passe utilisateur renforcées, disponibles via Active Directory. Du fait qu'elle nécessite moins de serveurs et de services supplémentaires pour sa mise en œuvre, cette approche s'avère plus simple que EAP-TLS et moins coûteuse en termes de ressources et d'investissement initial. Cette solution nécessite des certificats pour les serveurs d'authentification, mais leur nombre requis étant restreint, ils peuvent être générés par des fournisseurs de certificats tiers.

Cependant, la méthode EAP-TLS est considérée comme la mise en œuvre de l'authentification 802.1X la plus sûre. En effet, elle exige des certificats à la fois au niveau du client et du serveur d'authentification pour permettre une authentification mutuelle. Cette mise en œuvre nécessitant un grand nombre de certificats, il est recommandé de mettre en place une infrastructure de clé publique pour la prendre en charge, si une telle infrastructure n'existe pas déjà. C'est la raison pour laquelle EAP-TLS entraîne des coûts supérieurs à ceux générées par la méthode PEAP avec MS-CHAP v2 en termes de support et de mise en œuvre.

Processus décisionnel 802.1X

Pour simplifier le processus décisionnel relatif au choix de la meilleure implémentation de 802.1X dans un environnement réseau donné, Microsoft a conçu l'arborescence décisionnelle suivante relative à l'authentification 802.1X :

Figure 9. Arborescence décisionnelle 802.1X

L'utilisation du terme « grande entreprise » dans cet organigramme peut porter à confusion. Ce terme fait généralement référence à des entreprises de plus de 500 employés comportant un personnel informatique d'au moins 5 spécialistes des technologies. Au vu de cette information, il est évident que chacune de ces solutions pourrait convenir à l'environnement d'une entreprise de taille moyenne. De ce fait, le processus décisionnel dépend davantage des risques et de l'efficacité des investissements.

La principale différence entre PEAP et EAP-TLS réside dans le besoin d'une infrastructure de certificats. C'est pour cette raison que la méthode EAP-TLS est généralement considérée comme étant davantage appropriée aux grandes entreprises et PEAP aux entreprises de taille moyenne (si aucune réglementation ne pose de contraintes de sécurité plus strictes). Au-delà des considérations financières, certaines organisations ont des besoins supplémentaires en termes d'infrastructure de certificats, ce qui justifie l'investissement dans une infrastructure à clé publique (PKI). Après tout, si la sécurisation des contenus Web et les signatures de codes nécessitent de nombreux certificats, il est tout à fait raisonnable d'effectuer cet investissement en infrastructure afin d'implémenter la forme la plus sécurisée de l'authentification 802.1X.

Conditions requises pour PEAP 802.1X

Un PEAP Microsoft avec une implémentation MS-CHAP v2 nécessiterait au moins deux serveurs RADIUS IAS agissant en tant que serveurs d'authentification pour authentifier les clients sans fil en fonction d'une base de données de comptes Active Directory. Il peut s'avérer nécessaire d'ajuster le nombre de serveurs RADIUS en fonction du nombre de sites distants ou pour s'adapter à un plus grand nombre de tentatives d'authentification des utilisateurs.

L'existence de sites distants ne nécessite pas obligatoirement des serveurs RADIUS IAS supplémentaires. Cependant, si les sites distants ne comportent pas de connexions haut débit redondantes ou sont déjà dotés de leurs propres contrôleurs de domaines et d'autres ressources locales, des serveurs d'authentification supplémentaires doivent être ajoutés pour ces sites.

Conditions requises pour EAP-TLS 802.1X

Comme indiqué précédemment, la méthode EAP-TLS nécessite davantage de ressources que les implémentations PEAP en raison des besoins supplémentaires en termes de certificats. Bien entendu, il est possible d'utiliser des fournisseurs tiers pour obtenir les certificats nécessaires pour l'ensemble des clients sans fil et des serveurs d'authentification, mais à moins que le nombre de clients sans fil ne soit très restreint, cette approche est plus coûteuse que la mise en œuvre d'une infrastructure de certificats.

Au total, une simple mise en œuvre EAP-TLS nécessite au moins quatre serveurs, voire davantage pour les entreprises de plus grande taille ou les réseaux distribués géographiquement. Deux de ces quatre serveurs doivent agir en tant que serveurs RADIUS ISA, les autres faisant office d'infrastructure de certificats. Parmi les deux serveurs de certificats, il est recommandé que l'un d'eux (le serveur de certificats racine) se trouve hors du réseau et en reste déconnecté, ce qui signifie que le nombre de serveurs peut être réduit à un dans certains cas.

Utilisation de WEP ou de WPA

S'agissant de la sécurité sans fil, il est également important de déterminer s'il faut utiliser un chiffrement sans fil et, si tel est le cas, lequel. Pour les environnements d'entreprise de taille moyenne, il est rare que l'absence de chiffrement sans fil pose problème. Seules les connexions Internet accessibles au public sont concernées. Si tel est le cas, la sécurisation du réseau sans fil nécessite impérativement la mise en œuvre d'une méthode de chiffrement sans fil, parallèlement à l'authentification 802.1X.

Le chiffrement sans fil se présente sous les deux formes principales suivantes, auxquelles s'ajoute une variante supplémentaire :

• WEP. À l'origine, la norme WEP (Wired Equivalent Privacy) faisait partie de la norme IEEE 802.11 basée sur le chiffrement RC4 64 ou 128 bits pour la sécurisation des communications sans fil. De graves défauts ont été découverts, rendant cette méthode de chiffrement extrêmement vulnérable aux attaques d'écoute passive. Un certain nombre d'outils faciles à obtenir permettent de déchiffrer les transmissions WEP en relativement peu de temps (parfois en quelques minutes). Généralement, l'utilisation de la norme WEP est déconseillée pour les environnements d'entreprise. Néanmoins, il est possible de la sécuriser quelque peu à l'aide de diverses méthodes, notamment l'authentification 802.1X.

• WPA. En réponse aux points faibles inhérents à la norme WEP, un consortium d'acteurs majeurs du secteur industriel, dont Microsoft et le Wi-Fi Institute, a créé la norme WPA (Wi-Fi Protected Access) en tant que mise en œuvre partielle de la norme 802.11i. Cette norme est encore en cours de développement. Elle fournit un chiffrement beaucoup plus élaboré, basé sur le protocole TKIP (Temporal Key Integrity Protocol) pour le chiffrement des données, bien plus efficace que la norme WEP défectueuse. La plupart des points d'accès sans fil actuellement disponibles sur le marché prennent en charge la norme WPA, tout comme l'ensemble des versions actuelles des systèmes d'exploitation Microsoft Windows.

• WPA2. La norme WPA2 ( Wireless Protected Access 2) a été lancée en septembre 2004 par la Wi-Fi Alliance. Cette norme est certifiée en tant que mise en œuvre complète de la spécification IEEE 802.11i, laquelle fut ratifiée en juin 2004. Outre la prise en charge des méthodes d'authentification EAP basées sur 802.1X ou de la technologie PSK (parfois appelée WPA en mode personnel), cette norme présente le mécanisme de chiffrement avancé AES (Advanced Encryption Standard) qui utilise le protocole CCMP (Counter-Mode/CBC-MAC Protocol). Cette implémentation de chiffrement sans fil est extrêmement sûre. La plupart des fabricants prennent en charge l'une ou l'autre forme de la norme WPA2, tout comme l'ensemble des versions actuelles des systèmes d'exploitation Microsoft Windows.

Dans la mesure du possible, il est recommandé d'utiliser la norme WPA2 ou la norme WPA pour sécuriser les données sans fil. Cependant, ces normes étant récentes, leur utilisation peut s'avérer impossible, particulièrement en cas d'investissement majeur effectué précédemment dans une technologie sans fil qui ne les prend pas en charge. Comme indiqué précédemment, il est possible d'accroître le niveau de sécurité de la norme WEP en configurant l'authentification 802.1X et en modifiant régulièrement les paires de clés. Toutefois, même dans ce cas, l'utilisation de la norme WEP doit être réservée aux réseaux sans fil qui sont dans un état transitoire vers la norme WPA ou WPA 2.

Utilisation de SMS pour détecter les systèmes non gérés

Microsoft Systems Management Server (SMS) 2003 est un outil de gestion extrêmement polyvalent dans un réseau Microsoft. SMS permet de centraliser plusieurs fonctions de gestion, notamment la distribution de logiciels, le déploiement de mises à jour de sécurité et l'audit des systèmes. La possibilité de disposer d'un inventaire centralisé et automatisé des systèmes, à partir duquel peuvent être déployés ces outils extrêmement utiles, est au centre de ces fonctions. Et c'est ici qu'intervient la détection des systèmes non gérés.

SMS 2003 fournit diverses méthodes de détection grâce auxquelles les administrateurs peuvent construire la base de données des ordinateurs, laquelle contient des informations sur chacun des ordinateurs du réseau. Ces méthodes vont de la méthode de détection basée sur Active Directory (qui met à jour la base de données à l'aide d'informations détaillées fournies par la liste de comptes d'ordinateur Active Directory) à la méthode de détection réseau (qui contrôle activement le réseau à la recherche de périphériques connectés). Elles peuvent être configurées pour s'exécuter automatiquement à des intervalles prédéfinis et mettre à jour les bases de données une fois qu'elles ont terminé.

Pour répondre au besoin de détection des systèmes non gérés lorsqu'ils sont connectés au réseau, il est possible de configurer la détection réseau pour qu'elle s'exécute plus fréquemment, puis de passer en revue à intervalles réguliers les éléments découverts afin de déterminer à quel moment un nouveau système a été connecté au réseau. Lorsque des connexions système de ce type se produisent, elles peuvent être comparées à une liste établie de nouvelles versions d'ordinateur ou de demandes de connexion réseau afin de confirmer que le nouveau système est autorisé à utiliser le réseau.

Processus de détection réseau

Cette approche de détection des systèmes non gérés comporte certains inconvénients, notamment le fait que SMS peut rencontrer des difficultés à obtenir les informations détaillées sur les ordinateurs qui utilisent des systèmes d'exploitation autres que Microsoft Windows. À vrai dire, même les versions antérieures à Microsoft Windows 98 SE risquent de ne pas être détectées par les méthodes de détection SMS 2003 étant donné qu'elles ne prennent pas en charge les mises en œuvre de WMI (Windows Management Interface). De ce fait, il est nécessaire d'ajouter des scripts au processus de cette solution pour que les nouveaux périphériques soient détectés lorsqu'ils sont reliés au réseau. La figure suivante illustre le mode de fonctionnement d'un tel processus.

Figure 10. Processus de détection SMS des ordinateurs non gérés

Cette figure illustre les méthodes de détection permettant d'ajouter des types d'ordinateur différents dans la base de données SMS. Les trois différents types d'ordinateurs suivants doivent être ajoutés :

• Systèmes gérés accessibles par SMS. Ces ordinateurs peuvent être gérés par SMS et ont déjà été placés sous la gestion de SMS. Ils sont déjà présents dans la base de données SMS et doivent être configurés pour être gérés automatiquement. Ils doivent être considérés comme faisant partie du réseau approuvé et ne nécessitent pas d'attention particulière.

• Systèmes non gérés accessibles par SMS. Ces ordinateurs peuvent être gérés par SMS, mais n'ont pas encore été placés sous la gestion de SMS. Ils peuvent être détectés par SMS ou non, selon leur position dans le réseau (par exemple, derrière un pare-feu ou non), et peuvent inclure des ordinateurs qui sont gérés par d'autres moyens. Ces ordinateurs doivent figurer dans une liste d'exceptions complète comportant des informations de gestion détaillées. Si ce n'est pas le cas, ils doivent être considérés comme non approuvés et nécessitent une étude plus poussée. Ils peuvent être détectés par SMS, sauf si un périphérique réseau bloque une telle activité.

• Systèmes non gérés non accessibles par SMS. Ces ordinateurs ne peuvent pas être gérés par SMS et ne se trouvent pas sous son contrôle. Ils peuvent inclure ou non des systèmes gérés par d’autres moyens. Ces ordinateurs doivent figurer dans une liste d'exceptions comportant des informations de gestion détaillées. Si ce n'est pas le cas, ils doivent être considérés comme inconnus et non approuvés et nécessitent une étude plus poussée. Ces ordinateurs ne peuvent être détectés qu'à l'aide de processus autres que la détection SMS, notamment des scripts de détection personnalisés.

À ce stade, il est évident que le processus de détection des systèmes non gérés sur le réseau dépend de la mise en place de processus qui documentent de façon détaillée chaque connexion de chaque ordinateur autorisé sur le réseau. Ce type de documentation doit comporter des informations détaillées sur l'ordinateur, qu'il soit ou non géré par des méthodes automatisées (telles que SMS) et, si ce n'est pas le cas, sur le processus utilisé pour le maintenir en conformité avec les stratégies de sécurité établies, le cas échéant. Bien entendu, un ordinateur non autorisé peut se trouver sur un réseau sans pour autant devoir répondre aux normes de sécurité, mais de tels ordinateurs doivent obligatoirement rester dans un segment réseau isolé du réseau approuvé.

L'existence d'un processus documenté relatif à l'ajout d'ordinateurs, comportant une liste détaillée de tous les ordinateurs autorisés connus sur le réseau, permet de déterminer ce qui est autorisé et ce qui ne l'est pas. Tous les ordinateurs détectés sur le réseau et qui ne figurent pas dans cette liste doivent être considérés comme suspects et immédiatement étudiés plus attentivement.

Déploiement et gestion

La section « Développement » indique quelles sont les informations détaillées nécessaires à la création de plans de déploiement. La présente section détaille certains problèmes de déploiement courants, ainsi que divers processus dont l'objectif est d'assister les personnes chargées de la mise en œuvre de ces solutions et de permettre aux preneurs de décisions de mieux en comprendre la portée de sorte qu'ils puissent décider de ce qui convient le mieux à un environnement donné.

Utilisation d'IPsec pour l'isolation de domaines et de serveurs

L'isolation réseau par IPsec étant relativement complexe, il est conseillé aux responsables des implémentations d'adopter une approche par phase pour le déploiement de cette solution dans un réseau de production. Il existe deux manières de procéder à un déploiement par phase, selon la façon dont les stratégies IPsec sont déployées : par groupes ou par stratégies.

Indépendamment de la méthode utilisée, il est essentiel d'utiliser des exemples pilotes de chaque groupe au cours des étapes initiales du déploiement, en plus des tests relatifs à l'impact de cette solution dans un environnement de test (si possible). Le déploiement d'IPsec doit suivre un processus de demande de contrôle de modification formel, détaillant des plans de restauration ainsi que des acquisitions informées provenant des propriétaires des technologies et des processus métier concernés.

Déploiement d'IPsec par groupe

La méthode de déploiement de l'isolation réseau IPsec par groupe se base sur des stratégies IPsec entièrement définies, mais contrôle la mise en œuvre à l'aide de listes de contrôle d'accès (ACL) sur les GPO qui fournissent ces stratégies. Avant le déploiement, toutes les exceptions et tous les sous-réseaux sécurisés doivent être complètement définis dans toutes les stratégies IPsec ; toutes les actions de filtre adéquates doivent être déployées.

Lorsque la configuration est terminée, les administrateurs doivent créer des GPO pour chaque stratégie IPsec, ainsi que des groupes d'ordinateurs pour gérer ces GPO. Lorsqu'elles sont créées, les stratégies IPsec appropriées sont attribuées à leur GPO correspondant et les GPO sont reliés aux objets adéquats dans Active Directory. À ce stade du processus, les listes de contrôle d'accès qui gèrent l'attribution des GPO étant vides, aucune des stratégies ne doit être distribuée.

Lorsque les ordinateurs pilotes sont identifiés, les comptes d'ordinateur correspondants peuvent être placés dans les groupes d'ordinateurs appropriés ; la stratégie IPsec sera mise en application une fois que le prochain intervalle d'interrogation des GPO sera passé. Dans les phases suivantes, lorsque des ordinateurs supplémentaires sont ajoutés à la liste de déploiement, leurs comptes correspondants peuvent être placés dans les groupes adéquats pour la distribution des stratégies.

Cette méthode nécessite une planification stricte afin de garantir que les communications ne seront pas interrompues. Par exemple, si un serveur qui héberge une application utilisée par tous les hôtes était placé dans un groupe sécurisé nécessitant une communication chiffrée par IPsec, les ordinateurs qui n'ont pas encore été ajoutés à des groupes et les hôtes qui ne peuvent pas utiliser le chiffrement IPsec seraient perturbés.

Déploiement d'IPsec par stratégie

Cette méthode construit les stratégies IPsec au cours du déploiement, en partant de zéro, plutôt que de le faire préalablement au déploiement de production effectif. Dans cette méthode, les stratégies IPsec d'origine comportent uniquement des listes d'exceptions ; aucune règle de négociation de sécurité n'est définie pour les ordinateurs. Une fois la stratégie d'origine distribuée, les administrateurs peuvent créer une règle de sécurité comportant un filtre applicable à un seul sous-réseau. Au fur et à mesure de la progression du déploiement, des sous-réseaux supplémentaires peuvent être ajoutés à la règle de sécurité jusqu'à ce que la stratégie atteigne l'état de déploiement final.

Les avantages liés à l'utilisation de cette méthode de déploiement par phase tiennent au fait qu'IPsec n'est négocié que pour un pourcentage réduit du trafic TCP/IP plutôt que pour l'ensemble des sous-réseaux, comme c'est le cas dans une approche par groupe. Par ailleurs, cette méthode permet de tester l'ensemble des chemins réseau depuis un même sous-réseau, réduisant ainsi le nombre de clients affectés en cas de problème. Cependant, cette approche présente l'inconvénient d'être appliquée à l'ensemble des ordinateurs dans le domaine ou le groupe d'isolation, et non à des ordinateurs spécifiques comme dans le cas de l'approche par groupe. En outre, tous les ordinateurs devront, à un certain point, supporter un délai de trois secondes pour le basculement en clair lors de l'initialisation de connexions avec des sous-réseaux spécifiés.

Cette approche s'avère efficace dans le cas de réseaux complexes comportant des sous-réseaux multiples, mais relativement peu adaptée aux réseaux de plus petite taille ne comportant que peu de sous-réseaux.

Listes d'exceptions

Même un modèle d'isolation réseau extrêmement bien conçu devra faire face à certaines contraintes lorsqu'il est mis en œuvre dans un environnement de production. En général, les composants clés d'un environnement réseau, tels que les serveurs DNS et les contrôleurs de domaine, présentent certains défis qu'il est nécessaire de relever. Ces composants doivent non seulement être sécurisés, mais ils doivent également être disponibles pour tous les systèmes du réseau. De ce fait, ils doivent être ouverts aux demandes de connexion entrantes. D'autres problèmes peuvent également se manifester lors de la traduction du plan en production, mais il existe une méthode pour les résoudre : les listes d'exceptions.

Une liste d'exceptions est une liste qui contient les ordinateurs qui ne peuvent pas être sécurisés à l'aide d'IPsec et qui doit être implémentée dans chaque stratégie IPsec conçue. IPsec prenant seulement en charge le filtrage statique, tout hôte ajouté à une liste d'exceptions autorise de fait le trafic entrant et sortant provenant de toutes les parties du réseau, approuvées ou non. Ces hôtes étant davantage exposés aux risques liés aux périphériques non gérés, ils nécessitent une protection supplémentaire via un renforcement des serveurs et un filtrage d'état basé sur les hôtes à l'aide d'un pare-feu. C'est la raison pour laquelle cette liste doit être aussi réduite que possible. Il pourrait également être utile de placer les hôtes de la liste d'exceptions sur un même sous-réseau ou un même VLAN pour en simplifier la gestion ou de regrouper les fonctions de serveur afin de réduire le nombre d'hôtes exemptés.

La liste des exceptions peut inclure les hôtes suivants :

• Les contrôleurs de domaine ne prennent pas en charge les communications IPsec avec les membres du domaine, et ce même s'ils leur fournissent les stratégies IPsec et procèdent à l'authentification Kerberos sur laquelle se base l'isolation de réseau.

• Les hôtes pouvant subir un impact inacceptable sur leurs performances (généralement ceux qui doivent gérer simultanément des milliers de clients), ainsi que les hôtes qui subissent un délai de trois secondes pour le basculement en clair (tels que les serveurs DHCP).

• Les hôtes dont l'implémentation IPsec n'est pas compatible ou qui fournissent des services aux ordinateurs approuvés et non approuvés sans utiliser IPsec.

À l'instar du groupe frontalier, un processus d'approbation formel doit être mis en place pour les hôtes devant être ajoutés aux listes d'exceptions.

Remarque   Il existe pour Microsoft Windows XP et Windows Server 2003 une « stratégie simple » permettant de se passer des listes d'exceptions. Pour plus d'informations, reportez-vous aux articles 914841 et 914842 de la Base de connaissances, respectivement aux adresses suivantes : http://support.microsoft.com/kb/914841/fr et http://support.microsoft.com/kb/914842/fr.

Considérations relatives à la gestion d'IPsec

Une fois mises en œuvre, les stratégies IPsec ont un impact sur les communications entre de nombreux hôtes sur le réseau. De ce fait, les changements consécutifs à leur déploiement peuvent avoir des conséquences importantes sur de nombreux utilisateurs. C'est la raison pour laquelle tous les changements apportés à un réseau isolé via IPsec doivent suivre un processus de gestion des changements MOF normalisé comprenant les éléments suivants :

• Demande de changement (RFC)

• Classification des changements

• Autorisation de changement

• Pan de développement des changements

• Pan d'application des changements

• Révision des changements

Microsoft recommande d'utiliser Windows Server 2003 comme plate-forme de gestion IPsec. Pour simplifier les tâches de gestion, les administrateurs peuvent utiliser, au choix, le composant logiciel enfichable MMC Stratégies de sécurité IP ou l'outil de ligne de commande Netsh sur la console Windows Server 2003. Par ailleurs, les stratégies IPsec étant distribuées via une stratégie de groupe, leur gestion est relativement simple. De ce fait, l'ajout de nouveaux ordinateurs au réseau approuvé peut être automatisé via l'utilisation d'un processus établi d'ajout d'ordinateurs.

Néanmoins, certains facteurs doivent être pris en compte lorsqu'il s'agit d'appliquer des changements, notamment :

• Tout changement dans une action de filtre utilisée dans une SA IPsec entraîne la suppression des SA établies sous ces paramètres de stratégie. Cette fonctionnalité crée une nouvelle tentative de mode rapide si du trafic est en route, ce qui peut avoir pour conséquence l'abandon du trafic réseau.

• Le changement de méthode d'authentification ou de méthode de sécurité principale entraîne la suppression des modes existants par IKE. Dans certains cas, cette fonctionnalité entraîne l'échec des négociations du mode principal IKE côté serveur avec les clients.

• La modification de stratégies IPsec dans un GPO entraîne certains délais (notamment le délai de réplication Active Directory et le délai d'interrogation des GPO) qui peuvent aller de quelques minutes à plusieurs heures, selon la taille et la complexité de l'environnement.

Ces considérations relatives à la gestion traite également de la manière d'isoler les ordinateurs suspects en cas d'infection. Il existe plusieurs moyens différents de faire face aux activités malveillantes, notamment :

• Isoler le domaine d'isolation. Lorsqu'un périphérique non approuvé est soupçonné d'être une plate-forme d'activités malveillantes, il est possible de déconnecter complètement le réseau isolé du réseau non approuvé en modifiant le filtre IPsec – Secure Request Mode (mode de requête sécurisée) pour désactiver les communications non sécurisées.

• Bloquer les ports suspects. Il est possible de bloquer le trafic par port en créant des listes comportant deux filtres unidirectionnels. Cette approche doit être utilisée avec précaution, car elle peut bloquer le trafic nécessaire, tel que le DNS, ce qui peut compliquer les changements ou annulations IPsec suivants.

• Isoler vers des domaines enfants. Il est possible d'isoler un domaine d'autres domaines d'une forêt en modifiant les stratégies de sorte que ce domaine utilise une clé prépartagée plutôt que le protocole Kerberos pour l'authentification IPsec.

• Isoler vers des groupes prédéfinis. En utilisant des clés prépartagées ou des certificats plutôt que le protocole Kerberos pour l'authentification IPsec, il est possible de créer des groupes d'isolation utilisant des clés ou des certificats différents pour effectuer le même type d'isolation.

Utilisation des services de quarantaine VPN pour se protéger contre les ordinateurs distants non gérés

Au-delà de tout autre processus de demande de gestion des changements ou de tout autre processus de test de pré-déploiement, le déploiement effectif du contrôle de quarantaine VPN implique six étapes principales. Ces six étapes sont les suivantes :

1. Création de ressources de quarantaine.

2. Création de scripts pour la validation des configurations client.

3. Installation du composant écouteur RQS.exe sur des serveurs d'accès distant.

4. Création de profils CM (Connection Manager) à l'aide du CMAK Windows Server 2003.

5. Distribution des profils CM aux ordinateurs clients d'accès distant.

6. Configuration de la stratégie d'accès distant de quarantaine.

1. Création de ressources de quarantaine

Si les clients mis en quarantaine doivent utiliser des ressources internes pour se placer eux-même dans un état conforme aux stratégies de sécurité établies, un ensemble de ressources accessibles est nécessaire afin de pouvoir installer les mises à jour et autres logiciels requis pour leur sécurisation. Comme indiqué dans la section précédente, ces ressources comprennent généralement un serveur de noms, des serveurs de fichiers et éventuellement un serveur Web. Deux approches peuvent être utilisées lors de la désignation de ces ressources de quarantaine : la désignation des serveurs existants qui résident sur le réseau Internet et le placement des ressources requises dans leur propre sous-réseau séparé.

Du fait qu'elle permet d'utiliser des serveurs existants, la première approche permet de réduire les coûts associés à l'ajout de tels serveurs pour la distribution des mises à jour. Toutefois, cette approche implique l'utilisation de filtres de paquets complexes car chaque ressource nécessite son propre ensemble de filtres dans l'attribut MS-Quarantine-IPFilter de la stratégie d'accès distant de quarantaine.

Placer l'ensemble des ressources de quarantaine dans un même sous-réseau dédié aux services de quarantaine peut impliquer l'ajout de serveurs supplémentaires dans l'environnement réseau, mais il ne nécessite qu'un seul filtre pour les paquets entrants et sortants, applicable à l'ensemble des ressources de quarantaine.

2. Créer des scripts de validation

Les scripts de quarantaine procèdent à un ensemble de tests qui garantissent la conformité des ordinateurs d'accès distant avec les stratégies de sécurité. Une fois ces tests terminés, le script doit exécuter le composant client RQC.exe (en cas de succès) ou rediriger l'ordinateur client vers les ressources appropriées (en cas d'échec) pour le mettre en conformité. Bien entendu, si telle est l'instruction des stratégies réseau, ce script pourrait également simplement appliquer une interruption réseau accompagnée d'un message d'échec. Ces scripts peuvent se résumer à un fichier batch en ligne de commande ou d'exécutables plus complexes.

Des exemples de script sont disponibles en consultation et en téléchargement sur la page des* *exemples de scripts de quarantaine VPN (cette page peut être en anglais) dans le Centre de téléchargement Microsoft, à l'adresse suivante : www.microsoft.com/downloads/details.aspx?FamilyID=a290f2ee-0b55-491e-bc4c-8161671b2462.

3. Installation de RQS.exe sur des serveurs d'accès distant

Le processus d'installation du service Agent de quarantaine pour clients distants (RQS.exe) sur un ordinateur Microsoft Windows Server 2003 diffère de celui des serveurs comportant le Service Pack 1 (SP1). Par souci de concision, cette section décrit uniquement l'installation sur Windows Server 2003 avec SP1, considérant que tous les systèmes disposent de tous les derniers service packs et mises à jour de sécurité.

Installer RQS.exe sur un serveur Windows Server 2003 avec SP1

1. Cliquez sur Démarrer, puis sur Panneau de configuration.

2. Cliquez sur Ajout/Suppression de programmes.

3. Cliquez sur Ajouter ou supprimer des composants Windows.

4. Sélectionnez Composants, puis cliquez sur Services réseau.

5. Cliquez sur Détails.

6. Sélectionnez Sous-composants des services de mise en réseau, cliquez sur Service de quarantaine pour les clients distants, puis sur OK.

Ce processus installe le service de quarantaine, mais ne le démarre pas ; un administrateur doit le lancer manuellement une fois que la solution est complètement configurée et que l'environnement est prêt pour l'implémentation.

Ce processus d'installation comporte une étape supplémentaire consistant à modifier les chaînes de version de script pour qu'elles correspondent à celle configurée pour RQC.exe dans le script de quarantaine. RQS.exe peut être configuré pour accepter des chaînes de version de script multiples, lesquelles sont, à leur tour, écrites dans le registre du serveur d'accès distant sous HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\rqs\AllowedSet, ce qui correspond à l'emplacement où ces paramètres doivent être appliqués via une valeur de type REG_MULTI_SZ. Généralement, la valeur Ensemble autorisé est définie sur RASQuarantineConfigPassed, mais il est possible d'ajouter des valeurs de chaîne supplémentaires.

4. Création de profils CM de quarantaine

Un profil CM de quarantaine se résume en fait à un profil CM d'accès distant typique auquel sont ajoutés les éléments suivants :

• Une action de post-connexion qui exécute le script créé pour le tester et pour vérifier la conformité aux stratégies réseau. Cette action est effectuée via l'écran Actions personnalisées de l'assistant CMAK.

• Un composant de notification doit également être ajouté au profil via l'écran Fichiers supplémentaires de l'assistant CMAK

5. Distribution des profils CM

Les profils CM de quarantaine ainsi créés doivent être distribués et installés sur tous les ordinateurs clients d'accès distant. Un profil se présente sous la forme d'un fichier exécutable devant être exécuté sur chaque ordinateur client d'accès distant pour y installer le profil en question et configurer la connexion réseau de quarantaine.

La distribution de ces profils peut se faire manuellement, par exemple en les envoyant aux utilisateurs sous forme de pièces jointes accompagnées d'instructions. Elle peut également être automatisée avec des outils tels que la distribution de logiciels de SMS 2003. Plusieurs méthodes différentes peuvent être utilisées, selon la meilleure approche pour un réseau donné.

6. Configuration d'une stratégie d'accès distant de quarantaine

La procédure de configuration d'une stratégie d'accès distant de quarantaine varie selon qu'elle est configurée ou non sur un serveur  IAS ou un autre fournisseur d'authentification, comme indiqué ci-après :

• Si elle est configurée sur une serveur RADIUS IAS, vous devez utiliser le composant logiciel enfichable Service d'authentification Internet.

• Si elle est configurée sur un fournisseur d'authentification Windows, utilisez le composant logiciel enfichable Routage et accès distant.

Avant de créer une stratégie de quarantaine, vous devez d'abord créer une stratégie d'accès distant en mode normal. Vous devez ensuite ajouter les attributs MS-Quarantine-Session-Timeout et MS-Quarantine-IPFilter à l'aide de l'onglet Avancé dans les propriétés du profil de stratégie d'accès distant.

Si vous utilisez RADIUS, la stratégie d'accès distant de quarantaine doit être répliquée sur les autres serveurs RADIUS en copiant sa configuration ou en la créant manuellement sur chaque serveur.

Utilisation de l'authentification 802.1X pour se protéger contre les clients sans fil non gérés

Comme décrit dans les précédentes sections, les options recommandées par Microsoft pour sécuriser un réseau d'entreprise de taille moyenne sont les suivantes, de la plus sûre à la moins sûre :

• WPA2/AES et EAP-TLS

• WPA2/AES et PEAP-MS-CHAP v2

• WPA/TKIP et EAP-TLS

• WPA/TKIP et PEAP-MS-CHAP v2

Même si les méthodes EAP-TLS ou PEAP-MS-CHAP v2 peuvent renforcer la sécurité du protocole WEP, son utilisation n'est recommandée qu'en tant que transition vers une norme plus sécurisée telle que WPA ou WPA2.

Les processus de mise en œuvre des méthodes EAP-TLS et PEAP-MS-CHAP v2 comportent des similitudes. Tous deux nécessitent l'utilisation de serveurs RADIUS IAS Microsoft dans la solution et tous deux nécessitent des certificats. Toutefois les certificats requis par EAP-TLS concernent à la fois l'ordinateur client et le serveur, alors que ceux requis par PEAP-MS-CHAP v2 concernent uniquement les serveurs d'authentification. C'est la raison pour laquelle il est fortement recommandé d'utiliser une infrastructure de certificats lors de l'implémentation de la méthode EAP-TLS. En effet, les coûts d'acquisition de certificats auprès de fournisseurs tiers pour l'ensemble des clients peuvent s'avérer prohibitifs.

Authentification sans fil à l'aide des méthodes EAP-TLS et PEAP-MS-CHAP v2

Les processus d'implémentation des méthodes EAP-TLS et PEAP-MS-CHAP v2 impliquent un certain nombre d'actions qui n'entrent pas dans le cadre de ce document. Cependant, il existe déjà d'excellentes ressources permettant de concevoir et d'implémenter des solutions de sécurisation des réseaux sans fil :

• La page Déploiement de réseaux 802.11 sécurisés avec Microsoft Windows sur Microsoft TechNet fournit des informations concernant l'implémentation des deux approches d'authentification IEEE 802.1X. Elle est accessible à l'adresse suivante : www.microsoft.com/technet/prodtechnol/winxppro/deploy/ed80211.mspx.

• Le document Sécuriser les réseaux locaux à l'aide de services de certificat (cette page peut être en anglais) fournit des ressources et des informations détaillées sur l'implémentation de la méthode EAP-TLS sur les réseaux Microsoft. Il est disponible en téléchargement à l'adresse suivante : http://go.Microsoft.com/fwlink/?LinkId=14844.

• Le document Sécuriser les réseaux locaux avec PEAP et des mots de passe fournit des ressources et des informations détaillées sur l'implémentation de la méthode PEAP-MS-CHAP v2 sur les réseaux Microsoft. Il est disponible en téléchargement à l'adresse suivante : http://go.Microsoft.com/fwlink/?LinkId=23481.

• La mise à jour WPA2/WPS IE pour Windows XP Service Pack 2 (cette page peut être en anglais) est requise par Microsoft Windows XP avec SP2 pour la prise en charge de la norme WPA2. Elle est disponible à l'adresse suivante : http://support.microsoft.com/kb/893357/fr.

Utilisation de SMS pour détecter les systèmes non gérés et résoudre les problèmes associés

Comme indiqué dans la section « Développement », le processus de détection SMS s'avère très utile dans la recherche d'ordinateurs récemment connectés au réseau, lorsqu'ils sont gérables par SMS. Il a également été mentionné que SMS rencontre des difficultés à trouver certains systèmes non gérables lors du processus de détection, obligeant ainsi à utiliser un autre mécanisme pour combler cette lacune.

Plusieurs raisons peuvent expliquer que SMS ne soit pas en mesure de détecter les ordinateurs reliés à un réseau. Ces raisons sont les suivantes :

• L'ordinateur est relié mais éteint au moment de la détection et ne comporte pas de compte d'ordinateur sur le domaine.

• L'ordinateur est relié à un sous-réseau où un pare-feu ou tout autre périphérique réseau empêche la communication entre le serveur SMS et ce sous-réseau.

• L'ordinateur est relié à un réseau accessible, mais il utilise un système d'exploitation que SMS ne peut pas détecter.

Pour faire face à de telles éventualités, une solution personnalisée est nécessaire pour combiner les avantages de SMS avec des scripts permettant de palier ses manquements. Des scripts personnalisés peuvent être utilisés pour analyser le réseau à intervalles réguliers à l'aide d'un processus de planification ; de cette manière, ils peuvent détecter des périphériques qui sont sous tension pendant un court laps de temps. De tels scripts peuvent également être exécutés à partir de stations de travail ou de serveurs placés sur des sous-réseaux isolés par d'autres moyens. Ainsi, ils sont en mesure de détecter les systèmes non gérés lorsqu'ils se connectent à ces segments de réseau non surveillés. Ces scripts n'étant pas basés sur des processus de détection WMI, le type de système d'exploitation utilisé par les clients non gérés n'a aucune incidence sur leur efficacité.

Pour plus d'information sur l'utilisation de SMS pour la détection de périphériques sur le réseau, reportez-vous à l'accélérateur de solution Patch Management Using SMS 2003 à l'adresse suivante : www.microsoft.com/technet/itsolutions/cits/mo/swdist/pmsms/2003/pmsms031.mspx. Pour obtenir davantage de liens, notamment vers des ressources relatives aux solutions de script SMS, reportez-vous à la page d'accueil Microsoft Systems Management Server à l'adresse suivante : www.microsoft.com/smserver/default.mspx.

Haut de page

Résumé

Ce document a démontré qu'il était possible d'adopter une approche complète de gestion des problèmes liés aux systèmes non gérés. L'isolation réseau IPsec a été utilisée pour empêcher les systèmes non gérés d'accéder aux ressources du réseau approuvé et pour permettre la mise en application de la conformité aux stratégies par le biais du déni de service aux ordinateurs non conformes. Les services de quarantaine VPN permettent d'appliquer la conformité aux stratégies aux ordinateurs mobiles qui utilisent une solution d'accès distant mais qui se connectent rarement au réseau local. Les normes IEEE 802.1X et WPA/WPA2 permettent de protéger les réseaux locaux virtuels contre les périphériques non autorisés. Enfin, SMS et les scripts de détection permettent de détecter les systèmes non gérés et de maintenir les ordinateurs gérés à jour vis-à-vis de tous les correctifs et de toutes les mises à jour de sécurité.

Même si ces solutions techniques permettent de résoudre de nombreux problèmes liés aux périphériques non autorisés et non gérés, elles ne sont que plus efficaces si elles sont combinées à des stratégies de sécurité et à des processus stricts de gestion des changements. La combinaison de tous ces processus, solutions et stratégies crée une infrastructure d'entreprise de taille moyenne gérable, permettant de diminuer les coûts d'administration et de réduire les risques de sécurité à des niveaux acceptables.

Haut de page

Annexe A : Protection de l’accès réseau

La protection de l’accès réseau (NAP) est une nouvelle fonctionnalité intégrée à la prochaine génération de Windows (Microsoft Windows Server et Windows Vista™) qui permet d'appliquer la conformité avec les stratégies de bon fonctionnement informatique. NAP permet aux administrateurs de définir des seuils de stratégie de validation d'intégrité à l'aide d'une interface de programmation d'applications (API) qui limite l'accès réseau des ordinateurs ne répondant pas aux conditions d'intégrité requises lorsqu'ils se connectent au réseau.

La souplesse de NAP permet aux administrateurs de configurer des solutions personnalisées adaptées aux conditions de leurs environnements, qu'il s'agisse simplement de consigner l'état d'intégrité des ordinateurs qui se connectent au réseau, de déployer automatiquement des mises à jour logicielles ou de limiter la connectivité des systèmes qui ne répondent pas aux exigences d'intégrité. En outre, NAP est suffisamment souple pour s'intégrer avec des applications tierces et des programmes personnalisés afin que la mise en application des stratégies d'intégrité des ordinateurs soit réellement complète. NAP est également une solution complète ; ses composants de mise en application permettent aux administrateurs de forcer la conformité avec les stratégies d'intégrité via les réseaux sans fil DHCP, VPN et 802.1X. Par ailleurs, elle est compatible avec IPsec.

Pour plus d'informations sur NAP, reportez-vous à la page d'accueil de la Network Access Protection (cette page peut être en anglais) à l'adresse suivante : www.microsoft.com/technet/itsolutions/network/nap/default.mspx.

Télécharger

Obtenir l'article Protection d'un réseau contre les clients non gérés

Haut de page