Isolation de serveurs et de domaines à l'aide d'IPSec et de stratégies de groupe

Chapitre 3 : Détermination de l'état actuel de votre infrastructure informatique

Dernière mise à jour le 16-02-2005

Ce chapitre explique comment obtenir les informations nécessaires à la planification et au déploiement d'une solution d'isolation de serveurs et de domaines. Un déploiement réussi exige une connaissance à jour et précise de votre infrastructure informatique. Après avoir lu le présent chapitre, vous serez parfaitement au fait des informations nécessaires à la mise en place d'une solution d'isolation de serveurs et de domaines.

La dernière partie du chapitre explique comment maîtriser et documenter les ordinateurs identifiés et susceptibles de fonctionner comme ordinateurs « approuvés » au sein de la solution. Ces informations seront utiles à l'équipe chargée de la mise en place de la solution au moment de planifier cette dernière.

Sur cette page

Connaissances préalables requises pour ce chapitre
À qui s'adresse ce chapitre
Analyse de l'état actuel
Considérations relatives à la capacité
Problèmes de prédéploiement
Définition de l'approbation
Identification des coûts de mise à niveau des hôtes actuels
Résumé

Connaissances préalables requises pour ce chapitre

Avant d'exploiter les informations contenues dans ce chapitre, assurez-vous que vous et votre organisation respectez les exigences suivantes. Les instructions fournies dans ce chapitre sont spécifiquement adaptées aux besoins d'une organisation répondant de manière stricte à ces exigences. L'absence de conformité à l'ensemble des conditions requises n'a pas nécessairement un impact négatif sur votre projet mais en respectant ces exigences, vous donnerez d'autant plus de valeur aux instructions qui vous sont fournies.

Connaissances requises

Vous devez être familiarisé avec les concepts liés à IPSec et disposer de connaissances solides dans les domaines suivants :

• Authentification Microsoft® Windows® (plus précisément, le protocole d'authentification Kerberos version 5)

• Concepts relatifs au service d'annuaire Active Directory® (notamment les outils et la structure Active Directory), la manipulation d'utilisateurs, de groupes et d'autres objets Active Directory et enfin l'utilisation de la stratégie de groupe

• Sécurité du système Windows, notamment les concepts de sécurité, tels que les utilisateurs, les groupes, l'audit et les listes de contrôle d'accès

• Conventions système d'attribution de noms de l'organisation

• Emplacements physiques et logiques de l'organisation

• Méthodes de gestion des risques adoptées dans l'organisation

• Concepts réseau clés, notamment le filtrage de port à l'aide de pare-feu  

Avant de poursuivre la lecture de ce chapitre, lisez également les chapitres précédents de ce guide pour bien comprendre les concepts de la solution proposée en termes d'architecture et de conception.

Conditions requises pour l'organisation

En règle générale, la planification de groupes d'isolation dans une organisation implique plusieurs intervenants aux compétences diverses. Les informations nécessaires à une évaluation rigoureuse des exigences proviennent souvent de diverses sources disséminées dans l'organisation. Vous devez consulter les membres de votre organisation susceptibles de participer au processus de planification de ces groupes, notamment les personnes suivantes :

• les cadres exécutifs ;

• les personnes chargées de l'audit et de la sécurité ;

• les ingénieurs, les administrateurs et les équipes opérationnelles Active Directory ;

• les propriétaires d'applications, de serveurs Web et de domaines DNS (Domain Name System) ;

• le personnel des opérations et d'administration réseau ;

• le personnel de formation et d'assistance interne.  

Remarque : selon la structure de votre organisation informatique, ces rôles peuvent être remplis par plusieurs personnes, ou une même personne peut remplir plusieurs rôles.

Outre les informations recueillies auprès des personnes citées ci-avant, un point crucial à retenir est la mise à jour des pratiques opérationnelles actuellement en vigueur avec l'introduction d'IPSec dans l'environnement concerné. Il est possible que des composants logiciels et matériels, notamment le BIOS et les microprogrammes des périphériques réseau, exigent aussi une mise à jour. Enfin, des outils réseau supplémentaires seront peut-être nécessaires afin de faciliter la prise en charge et le dépannage de l'environnement IPSec.

Configuration requise pour l'infrastructure informatique

Ce chapitre part également du principe que l'infrastructure informatique suivante est disponible :

• Un domaine Microsoft Windows Server™ 2003 Active Directory fonctionnant en mode mixte ou natif. Cette solution utilise des groupes universels pour l'application des objets Stratégie de groupe (GPO). Si l'organisation ne fonctionne pas en mode mixte ou natif, il reste possible d'appliquer l'objet Stratégie de groupe à l'aide de configurations de groupes locaux et globaux standards. Cependant, cette option étant plus complexe à gérer, cette solution ne l'utilise pas.

Remarque : Windows Server 2003 a introduit un certain nombre d'améliorations qui affectent les stratégies IPSec. Aucune spécificité de cette solution ne l'empêche de fonctionner avec Windows 2000. Cependant, la solution n'a été testée qu'avec Windows Server 2003 Active Directory. Pour plus d'informations sur les améliorations apportées à IPSec dans Windows Server 2003, reportez-vous à la page New features for IPSec  (Nouvelles fonctionnalités d'IPSec) sur le site Web de Microsoft à l'adresse www.microsoft.com/resources/documentation/
WindowsServ/2003/standard/
proddocs/en-us/ipsec_whatsnew.asp.

• Les outils et les compétences requis pour surveiller le réseau, analyser les données de surveillance et prendre des décisions de planification de capacité sur la base de ces données.

Remarque : l'usage des outils de surveillance réseau est soumis à des restrictions dans de nombreuses organisations. Soyez vigilant et assurez-vous que les procédures opérationnelles suivies lors de l'utilisation de ces outils sont les bonnes.

• Un outil déjà installé et capable de recueillir des données de configuration réseau sur les hôtes du réseau. Par exemple, vous pouvez faire appel à des systèmes de gestion des ressources pour collecter ces informations. Pour plus d'informations, consultez la section « Détection d'hôtes » plus loin dans ce chapitre.

À qui s'adresse ce chapitre

Ce chapitre s'adresse aux professionnels informatiques chargés de créer l'infrastructure informatique que les architectes et les concepteurs de solutions utiliseront. Ces professionnels sont généralement des membres du personnel du support ou des opérations de l'organisation concernée. Pour tirer le meilleur parti des informations figurant dans ce chapitre, vous devez disposer d'un bon de niveau de connaissance technique des outils et des technologies impliqués dans le processus de recueil des informations ainsi que de l'infrastructure actuelle de l'organisation.

Analyse de l'état actuel

Recueillir et tenir à jour des données fiables sur les ordinateurs, les logiciels et les périphériques réseau d'une organisation est un défi informatique classique. La réussite d'un projet dépend des informations relevées au cours de ce processus. Avant d'entamer la planification d'un projet d'isolation de serveurs et de domaines, vous devez recueillir et analyser des données mises à jour sur les ordinateurs, le réseau et les services d'annuaire déjà déployés au sein de l'organisation. Ces données vous permettront de concevoir une solution qui tient compte de tous les éléments possibles de l'infrastructure existante. Si les informations recueillies manquent de précision, des problèmes liés à des périphériques et des ordinateurs non pris en compte au cours de la phase de planification peuvent survenir lors de l'implémentation. Les sections suivantes décrivent les informations requises dans chaque domaine et fournissent des exemples issus des informations recueillies dans le cadre de la solution d'isolation de serveurs et de domaines développée pour la Woodgrove Bank.

Détection réseau

L'aspect le plus primordial de la planification d'une solution d'isolation de serveurs et de domaines est l'architecture réseau, puisque le protocole de sécurité IPSec intervient au niveau du protocole Internet (IP). Une maîtrise partielle ou erronée du réseau se traduira par l'échec de toute solution d'isolation. La compréhension de l'agencement des sous-réseaux, des schémas d'adressage IP et des modèles de trafic est une condition qui participe à cet effort mais les deux composants suivants sont indispensables pour mener à terme la phase de planification du projet :

• Documentation de la segmentation du réseau

• Documentation du modèle de trafic réseau actuel

L'objectif recherché est de disposer de suffisamment d'informations pour identifier une ressource en fonction de son emplacement sur le réseau, en plus de son emplacement physique.

Il est préférable de débuter avec une architecture réseau soigneusement pensée, dotée de plages d'adresses facilement identifiables et du nombre le plus réduit possible de chevauchements ou de plages discontinues. Il est possible que certains impératifs commerciaux ou circonstances (par exemple, dans le cas de fusions et d'acquisitions) ne permettent pas la mise en place d'un réseau « rationalisé » mais en prenant soin de documenter et de comprendre l'état actuel, vous faciliterez votre travail d'identification du réseau et des ressources qu'il gère. N'utilisez pas un réseau complexe et mal documenté comme point structurel de départ ; il risque de laisser un trop grand nombre de domaines non identifiés susceptibles de causer des problèmes lors de l'implémentation.

Ces instructions sont un moyen d'obtenir les informations les plus pertinentes pour la planification d'une solution d'isolation de serveurs et de domaines mais n'ont pas pour vocation de chercher à résoudre d'autres problèmes, notamment les questions de masque de sous-réseau de longueur variable et d'adressage TCP/IP, de segmentation de réseau local virtuel (VLAN) ou d'autres méthodes et techniques d'optimisation des réseaux. Les informations obtenues servent à formuler les composants opérationnels et d'implémentation de la solution d'isolation de serveurs et de domaines.

Documentation de la segmentation du réseau

Si l'architecture actuelle de votre organisation n'est pas documentée et disponible en guise de référence, vous devez vous procurer les documents nécessaires dès que possible avant de poursuivre la mise en œuvre de la solution. Si les informations documentées ne sont pas à jour ou n'ont pas été récemment validées, deux options simples vous sont proposées :

• Accepter le fait que les informations exposent le projet à des risques.

• Engager un processus de détection et de découverte, soit manuellement, soit par le biais d'un outil d'analyse réseau capable de fournir les informations nécessaires à la documentation de la topologie réseau actuelle.

Les informations requises peuvent être présentées de différentes façons, mais une série de représentations schématiques s'avère souvent la méthode la plus efficace pour illustrer et expliquer la configuration actuelle du réseau. Lorsque vous créez le schéma d'un réseau, évitez d'y insérer trop d'informations. Si nécessaire, utilisez plusieurs schémas illustrant différents niveaux de détail.

Prenons pour exemple le scénario imaginé pour la Woodgrove Bank. Le schéma créé et illustré ci-dessous offre une vision détaillée de son réseau étendu et de l'environnement du site :

Figure 3.1 Réseau étendu et architecture du site de la Woodgrove Bank

Après avoir développé ce schéma, l'équipe de la Woodgrove Bank a entrepris de créer des schémas détaillés de chaque site, puis de chaque sous-réseau à l'intérieur de chaque site.

Tout en documentant votre réseau, vous rencontrerez peut-être des applications et des services réseau incompatibles avec IPSec. Parmi les risques d'incompatibilité actuels figurent les points suivants :

• Sur les routeurs, la technologie Cisco NetFlow ne peut pas analyser les paquets entre des membres IPSec à partir du protocole ou du port.

• La qualité de service (QoS) mise en place sur le routeur ne peut pas utiliser les ports ou les protocoles pour définir la priorité du trafic. L'utilisation d'adresses IP spécifiques reste néanmoins possible pour la hiérarchisation du trafic. Par exemple, tandis qu'une règle attribuant la priorité de « quiconque à quiconque utilisant le port 80 » ne fonctionnerait pas, une règle définissant une priorité de « quiconque à 10.0.1.10 » ne serait nullement affectée.

• Certains équipements ne prennent pas en charge ou n'autorisent pas le protocole IP 50, le port adopté par le protocole ESP (Encapsulating Security Payload).

• La technique WFQ (Weighted Fair Queuing) et d'autres méthodes de définition de la priorité du trafic sur routeur fondées sur le flux peuvent échouer.

• Les moniteurs réseau peuvent être incapables d'analyser les paquets ESP non chiffrés (ESP-Null).

  Remarque : le Moniteur réseau Microsoft a ajouté un analyseur ESP à la version 2.1 destiné à faciliter la résolution des problèmes liés aux paquets IPSec non chiffrés. L'outil Moniteur réseau est fourni avec Microsoft Systems Management Server (SMS). Pour plus d'informations, consultez la page Microsoft Systems Management Server  sur le site www.microsoft.com/smserver/.

• Si le système ne peut pas procéder à une analyse ESP, aucune liste de contrôle d'accès (ACL) spécifiant des règles de port ou de protocole n'est traitée dans les paquets ESP.

• Si le système dispose d'un analyseur ESP et utilise le chiffrement, les listes de contrôle d'accès qui spécifient des règles de port ou de protocole ne sont pas traitées dans les paquets ESP.

IPSec annule la définition des priorités fondées sur le réseau et la gestion du trafic fondée sur les ports et les protocoles lorsque des ports et des protocoles sont utilisés. Il n'existe malheureusement aucune solution alternative pour les paquets chiffrés. Si la gestion du trafic ou la définition des priorités doit être fondée sur les ports ou le protocole, l'hôte lui-même doit être en mesure d'assumer ces fonctions de gestion du trafic et de hiérarchisation.

Enfin, il est primordial d'enregistrer avec exactitude les informations nécessaires pour les divers périphériques du réseau.

Périphériques de l'infrastructure réseau

Les périphériques qui composent l'infrastructure réseau (routeurs, commutateurs, équilibreurs de charge et pare-feu) communiquent avec IPSec après l'implémentation de la solution. C'est pourquoi il est primordial d'examiner les caractéristiques suivantes des périphériques du réseau pour s'assurer de leur capacité à gérer les exigences techniques et matérielles de la conception :

• Marque/modèle. Vous pouvez utiliser ces informations pour déterminer les fonctionnalités prises en charge par le périphérique. De plus, vérifiez le BIOS ou le logiciel exécuté sur le périphérique pour être certain qu'IPSec est pris en charge.

• Quantité de mémoire vive (RAM). Cette information peut être précieuse lorsque vous souhaitez évaluer la capacité ou l'impact d'IPSec sur le périphérique.

• Analyse du trafic. Ces informations (heure d'utilisation maximale et tendances quotidiennes et hebdomadaires indiquant le taux d'utilisation journalier du périphérique) peuvent toujours s'avérer utiles. En rapport avec IPSec, les informations fournies offrent un aperçu du périphérique et de son utilisation sur une période donnée. Si des problèmes surgissent après l'implémentation d'IPSec, ces mêmes informations peuvent permettre de déterminer si les causes sont liées à une utilisation intensive du périphérique.

• Listes de contrôle d'accès (ACL) affectant directement IPSec. Les listes de contrôle d'accès ont un impact direct sur la capacité de fonctionnement de certains protocoles. Par exemple, si vous n'autorisez pas le protocole Kerberos (protocole UDP (User Datagram Protocol) et port TCP 88) ou le protocole IP (le protocole, pas le port) 50 ou 51, IPSec ne fonctionnera pas. Les périphériques doivent également être configurés pour permettre la circulation du trafic IKE (UDP 500 et 4500) lorsque vous utilisez la traduction d'adresses réseau NAT-Traversal (NAT-T).

• Réseaux/sous-réseaux connectés à des interfaces de périphériques. Ces informations vous permettent d'effectuer la meilleure analyse possible de la structure du réseau interne. La définition des limites du réseau à partir d'une plage d'adresses est une opération simple et permet d'identifier si d'autres adresses sont non gérées ou étrangères au réseau interne (par exemple, les adresses Internet). Ces informations sont nécessaires pour les décisions de stratégies IPSec prises au cours des chapitres suivants du présent guide.

• Le périphérique autorise ou non la traduction d'adresses réseau (NAT). La traduction d'adresses réseau est fréquemment utilisée pour soumettre une plage d'adresses tout entière en tant qu'adresse IP unique à un réseau connecté ou à Internet. Le planificateur de solutions doit savoir où ce processus intervient sur le réseau.

  Remarque : l'article 818043 de la Base de connaissances Microsoft, « Mise à jour NAT-T pour le protocole L2TP et la sécurité IP dans Windows XP et Windows 2000  » (https://support.microsoft.com/kb/818043) propose la fonctionnalité NAT-T en tant que correctif téléchargeable pour Windows XP Service Pack (SP) 1 et Windows 2000 SP4. En revanche, aucun répondeur IPSec ne fonctionnera correctement si vous n'avez pas installé Windows XP SP2 ou Windows Server 2003 SP1.

• Segmentation des réseaux locaux virtuels (VLAN). En déterminant le mode d'implémentation actuel des réseaux locaux virtuels (VLAN) sur le réseau, vous comprendrez mieux les modèles de trafic ou les exigences de sécurité existantes et pourrez déterminer comment IPSec augmentera ces exigences ou sera potentiellement amené à interférer avec elles.

• Liens de connexion du périphérique. Ces informations vous permettront de détecter les connexions que le périphérique entretient entre des réseaux spécifiques. Elles peuvent également être utilisées pour identifier le réseau logique et les connexions à divers emplacements d'une interface donnée.

• Taille de l'unité de transmission maximale (MTU) sur les interfaces des périphériques. L'unité de transmission maximale (MTU) désigne le plus grand datagramme qu'il est possible de transmettre sur une interface donnée sans le diviser en plus petites unités de transmission (processus également appelé « fragmentation »). Dans les communications IPSec, le MTU a pour but de déterminer les zones dans lesquelles la fragmentation aura lieu. Le routeur doit suivre la fragmentation des paquets afin de détecter le protocole ISAKMP (Internet Security Association and Key Management Protocol). IPSec configure la taille MTU de la session selon le MTU minimal détecté dans le chemin de communication utilisé, puis définit le bit DF (Do not Fragment) à 1.

  Remarque : si la découverte du PMTU (Path MTU) est activée et fonctionne comme il se doit, vous n'avez pas besoin de recueillir la taille MTU sur les interfaces des périphériques. Certaines sources, notamment le Windows Server 2003 Hardening Guide (Guide de renforcement de la sécurité de Windows Server 2003), recommandent de désactiver la fonction de découverte PMTU. En revanche, cette fonction doit être activée pour permettre à IPSec de fonctionner correctement.

Notez également qu'IPSec peut affecter un système IDS (système de détection d'intrusion) puisqu'un analyseur spécifique est nécessaire à l'interprétation des données à l'intérieur des paquets. Si le système IDS n'est pourvu d'aucun analyseur, il ne peut pas examiner les données de ces paquets pour déterminer si une session particulière est une menace potentielle. Dans ce cas, la décision d'utiliser IPSec indique que votre organisation a davantage besoin d'IPSec que du système IDS.

Les informations identifiées dans cette section sont essentielles à la réussite du projet puisqu'elles vous permettent de comprendre la configuration actuelle et la santé de l'infrastructure du réseau avant même de configurer l'utilisation d'IPSec sur les périphériques concernés (ou d'y placer une charge supplémentaire s'ils sont déjà configurés pour la circulation du trafic IPSec). Par l'étude des informations relatives aux pics de charge, vous pouvez déterminer si le périphérique est en mesure d'utiliser IPSec dans son état actuel ou s'il exige une mise à niveau de la mémoire ou du microprogramme afin de supporter la charge attendue. Les informations sur la marque et le modèle s'avéreront utiles au moment de vous procurer le matériel de mise à niveau des périphériques (si nécessaire). Les informations sur les paramètres de configuration ou les fonctionnalités propres à cette marque et ce modèle peuvent également vous être utiles. Le nombre de listes de contrôle d'accès configurées sur les périphériques vous aidera à estimer l'effort requis pour configurer les périphériques afin de prendre en charge IPSec. Si aucun périphérique du réseau n'est configuré pour autoriser le trafic IPSec et que le réseau dispose d'un grand nombre de routeurs, la configuration des périphériques risque de représenter une importante charge de travail.

Une fois ces informations à votre disposition, vous pouvez rapidement déterminer s'il est nécessaire ou non de mettre à niveau les périphériques afin qu'ils répondent aux exigences du projet, de modifier les listes de contrôle d'accès ou de prendre d'autres mesures pour vous assurer que les périphériques seront capables de gérer les charges qui leur seront confiées.

Analyse du modèle de trafic réseau actuel

Après avoir recueilli les informations d'adressage et d'infrastructure réseau, l'étape suivante consiste logiquement à examiner avec soin le flux des communications. Par exemple, si un service comme celui des ressources humaines s'étend sur plusieurs bâtiments et si vous souhaitez utiliser IPSec pour chiffrer les informations de ce service, vous devez savoir comment les bâtiments concernés sont connectés pour déterminer le niveau de « confiance » envers la connexion. Un bâtiment hautement sécurisé relié par un câble en cuivre à un autre bâtiment sans protection peut être la proie d'une écoute clandestine ou d'une attaque par relecture de données. Si une attaque de ce type représente une menace, IPSec peut fournir une authentification mutuelle renforcée et le chiffrement du trafic des hôtes approuvés. Néanmoins, la solution ne résout pas le fait qu'un manque de sécurité physique sur les hôtes approuvés constitue toujours une menace.

Au moment d'examiner le flux de trafic, regardez de près comment tous les périphériques gérés et non gérés interagissent, y compris les périphériques non-Windows, tels que Linux, UNIX et Mac, ainsi que les versions Windows antérieures à Windows 2000 SP4. Posez-vous certaines questions, notamment : certaines communications ont-elles lieu au niveau du port ou du protocole ou bien existe-t-il un grand nombre de sessions intervenant entre les mêmes hôtes sur un large éventail de protocoles ? Comment les serveurs et les clients communiquent-ils ensemble ? Existe-t-il des systèmes de sécurité ou des projets actuellement mis en œuvre ou planifiés susceptibles d'avoir un impact sur le projet d'isolation ? Par exemple, l'utilisation de Windows XP SP2 et du Pare-feu Windows pour "verrouiller" certains ports, tels que le port UDP 500, risque de provoquer l'échec de la négociation IKE.

Lorsque vous appliquez le processus de modélisation des menaces décrit dans le chapitre  2 (« Présentation de l'isolation de serveurs et de domaines ») afin d'examiner les différents types de trafic réseau, vous pouvez aisément rechercher les protocoles et les applications qui génèrent un trafic devant être protégé contre les périphériques non approuvés ou non gérés. Certains des protocoles et des applications les plus fréquemment rencontrés sont les suivants :

• NetBIOS sur TCP/IP (NetBT) et SMB (Server Message Block). Dans un réseau local, on trouve souvent les ports 137, 138 et 139 activés pour NetBT et le port 445 activé pour SMB. En plus d'autres fonctionnalités, ces ports offrent des services de résolution des noms NetBIOS. Malheureusement, ils entraînent aussi la création de sessions NULL. Une session NULL est une session établie sur un hôte qui n'utilise pas le contexte de sécurité d'une entité ou d'un utilisateur connu. Ces sessions sont souvent anonymes.

• Appel de procédure distante (RPC). En règle générale, l'appel de procédure distante opère en présentant un port d'écoute à une application (également appelé « mappeur de point de terminaison », port TCP 135) qui suggère alors à « l'appelant » (souvent une autre application) d'engager la communication sur un autre port de la plage éphémère. Dans un réseau segmenté par des pare-feu, cette communication RPC soulève un véritable défi en termes de configuration puisqu'elle implique d'ouvrir le port d'écoute RPC et tous les ports au-dessus du port 1024. L'ouverture de tous ces ports augmente la surface exposée aux attaques sur la totalité du réseau et réduit l'efficacité des pare-feu. En revanche, l'avantage de l'appel de procédure distante (RPC) est qu'il fournit les fonctionnalités des couches 1 à 4 du modèle OSI (Open Systems Interconnection) pour les applications qui l'utilisent, ce qui évite aux développeurs d'effectuer des appels de bas niveau sur le réseau pour leurs applications distribuées. Du fait que de nombreuses applications dépendent de l'appel de procédure distante (RPC) pour leurs fonctionnalités de base, la stratégie IPSec devra tenir compte du service RPC. Pour plus d'informations sur la création d'une stratégie IPSec, consultez le chapitre 5, « Création de stratégies IPSec pour les groupes d'isolation ».

• Autre trafic. IPSec peut sécuriser les transmissions entre hôtes en authentifiant les paquets en plus de chiffrer les données qu'ils contiennent. L'important est d'identifier ce qui doit être protégé et les risques à minimiser. Tout autre trafic ou type de trafic à sécuriser doit être examiné et modélisé comme il se doit. Il peut, par exemple, s'agir d'une base de données visant un objectif précis et à laquelle seuls quelques clients sont autorisés à accéder, ou bien d'une application spécialisée destinée aux ressources humaines et exclusivement réservée aux cadres de ce service.

Après avoir documenté le réseau logique et physique, la prochaine étape consiste à examiner les modèles de trafic actuels et à répondre aux questions suivantes :

• Disposez-vous à l'heure actuelle de sous-réseaux dédiés à des types spécifiques de trafic (par exemple, des stations de travail Mac et UNIX ou des connexions entre ordinateur central et terminal) ?

• Avez-vous besoin de séparer les différents types de trafic ou le trafic d'un emplacement à un autre ?

Active Directory

Après le réseau, Active Directory est le deuxième élément clé à partir duquel il vous faudra rassembler des données. Vous devrez comprendre la structure des forêts, notamment l'agencement des domaines, l'architecture des unités d'organisation et la topologie du site. Ces informations permettent de connaître la position actuelle des ordinateurs, leur configuration et l'impact des modifications apportées à Active Directory suite à l'implémentation d'IPSec. La liste ci-dessous décrit les informations nécessaires à la réalisation de cette étape du processus de découverte.

• Nombre de forêts. Étant donné que la forêt est la limite de sécurité dans une implémentation Active Directory, il est nécessaire de comprendre l'architecture Active Directory actuelle pour déterminer les hôtes à isoler et les modalités de l'isolation.

• Noms et nombre de domaines. L'authentification IPSec intervient suite au processus de négociation IKE. Dans cette solution, la méthode d'authentification est le protocole Kerberos. Ce protocole suppose que les ordinateurs sont associés à des domaines et qu'ils répondent aux exigences de version requises en matière de système d'exploitation (Windows 2000, Windows XP ou Windows Server 2003).

• Nombre et types d'approbations. Connaître le nombre et les types d'approbations est crucial puisque les approbations affectent les limites logiques de l'isolation et permettent de définir la manière dont peut (ou doit) survenir l'authentification IKE dans la solution.

• Noms et nombre de sites. L'architecture du site s'aligne généralement sur la topologie du réseau. En maîtrisant le mode de définition des sites dans Active Directory, vous comprendrez mieux la réplication et d'autres processus. Dans cette solution, l'architecture du site offre une description plus approfondie de l'implémentation Active Directory tel qu'elle existe à l'heure actuelle.

• Structure d'unités d'organisation. Lorsque vous créez une structure d'unités d'organisation, un minimum de planification permet d'augmenter considérablement l'efficacité opérationnelle. Les unités d'organisation sont des constructions logiques. Elles peuvent donc être modelées pour répondre à divers objectifs et exigences. La structure d'unités d'organisation est le laboratoire idéal à partir duquel vous pouvez examiner l'utilisation de la stratégie de groupe et l'agencement des unités d'organisation. Les chapitres 4 et 5 de cette solution décrivent l'architecture des unités d'organisation et expliquent en détail comment en faire usage pour appliquer la stratégie IPSec.

• Utilisation actuelle de la stratégie IPSec. L'objectif ultime de ce projet étant l'implémentation de la stratégie IPSec, il est primordial que vous sachiez comment votre réseau exploite actuellement IPSec (si tel est le cas). Que vous utilisiez de simples filtres IPSec (comme ceux prescrits dans un guide de renforcement de la sécurité) ou implémentiez des stratégies complètes, la connaissance de votre utilisation actuelle et des conditions mêmes de cette utilisation permettront une intégration plus efficace dans la solution.

Le scénario de la Woodgrove Bank présente une seule et unique forêt (corp.woodgrovebank.com) composée de quatre domaines répartis sur cinq sites. Chaque site peut comporter un contrôleur de domaine (DC), un contrôleur principal de domaine (PDC) ou un serveur de catalogue global (GC) comme le montre le tableau ci-dessous.

Tableau 3.1 : Informations Active Directory de la Woodgrove Bank

Site physique	Domaine	Utilisateurs	Type de contrôleur de domaine
New York, NY	corp.woodgrovebank.com americas.corp.woodgrovebank.com	5 000	Catalogue global racine de la forêt PDC GC régional, Amériques DC régional, Europe DC régional, Asie
Chicago, IL	americas.corp.woodgrovebank.com	750	GC régional, Amériques
Atlanta, GA	americas.corp.woodgrovebank.com	1 450	GC régional, Amériques
Boston, MA	americas.corp.woodgrovebank.com	480	GC régional, Amériques
San Francisco, CA	americas.corp.woodgrovebank.com	250	GC régional, Amériques
Pittsburgh, PA	americas.corp.woodgrovebank.com	50	GC régional, Amériques
Phoenix, AZ	americas.corp.woodgrovebank.com	50	GC régional, Amériques
Miami, FL	americas.corp.woodgrovebank.com	50	GC régional, Amériques
Washington, DC	americas.corp.woodgrovebank.com	75	GC régional, Amériques
Cambridge, MA	americas.corp.woodgrovebank.com	36	GC régional, Amériques
Toronto, Canada	americas.corp.woodgrovebank.com	25	GC régional, Amériques
Londres, R.U.	europe.corp.woodgrovebank.com corp.woodgrovebank.com	5 200	GC racine de la forêt Émulateur PDC GC régional, Europe DC régional, Amériques DC régional, Asie
Genève, Suisse	europe.corp.woodgrovebank.com	350	GC régional, Europe
Amsterdam, Pays-Bas	europe.corp.woodgrovebank.com	295	GC régional, Europe
Munich, Allemagne	europe.corp.woodgrovebank.com	149	GC régional, Europe
Rome, Italie	europe.corp.woodgrovebank.com	80	GC régional, Europe
Dublin, Irlande	europe.corp.woodgrovebank.com	79	GC régional, Europe
Édimbourg, Écosse	europe.corp.woodgrovebank.com	40	GC régional, Europe
Johannesburg, Afrique du Sud	europe.corp.woodgrovebank.com	37	GC régional, Europe
Tokyo, Japon	asia.corp.woodgrovebank.com corp.woodgrovebank.com	500	GC racine de la forêt Émulateur PDC GC régional, Asie DC régional, Europe DC régional, Amériques
Hong-Kong, Chine	asia.corp.woodgrovebank.com	100	GC régional, Asie
Bangkok, Thaïlande	asia.corp.woodgrovebank.com	150	GC régional, Asie
Singapour	asia.corp.woodgrovebank.com	210	GC régional, Asie
Sydney, Australie	asia.corp.woodgrovebank.com	45	GC régional, Asie
Bangalore, Inde	asia.corp.woodgrovebank.com	35	GC régional, Asie
Taipei, Taïwan	asia.corp.woodgrovebank.com	65	GC régional, Asie

La structure Active Directory de la Woodgrove Bank utilisait les relations d'approbation bidirectionnelle automatiquement créées par la forêt. Aucune approbation supplémentaire entre forêts ou externe n'était disponible.

La figure suivante donne un exemple de la structure d'unités d'organisation de haut niveau adoptée à la Woodgrove Bank. Cette structure a fait l'objet d'une utilisation cohérente sur les trois domaines régionaux principaux (Amériques, Europe et Asie).

Figure 3.2 Exemple de structure d'unités d'organisation Woodgrove Bank

Le projet d'isolation de serveurs et de domaines étant la première implémentation IPSec réalisée par la Woodgrove Bank, aucune stratégie IPSec active et existante n'était en place.

Détection d'hôtes

L'avantage le plus précieux d'un projet de découverte des ressources est la quantité considérable de données recueillies sur les hôtes (stations de travail et serveurs) du réseau. Les décisions prises et décrites au chapitre 4, « Conception et planification de groupes d'isolation », exigeront des informations précises sur l'état de l'ensemble des hôtes afin de garantir leur aptitude à participer aux communications IPSec de la solution.

Données requises concernant les hôtes

Cette section décrit les informations nécessaires sur les hôtes et explique comment les représenter de manière physique et logique.

• Nom de l'ordinateur. Il s'agit du nom NetBIOS ou DNS de l'ordinateur permettant d'identifier ce dernier sur le réseau. Du fait qu'un ordinateur peut disposer de plusieurs adresses MAC (Media Access Control) et/ou IP, le nom d'ordinateur constitue l'un des critères en fonction desquels vous pouvez déterminer l'unicité sur le réseau. Les noms des ordinateurs peuvent être dupliqués dans certaines circonstances de sorte que l'unicité ne soit pas jugée comme absolue.

• Adresse(s) IP de chaque carte d'interface réseau. L'adresse IP désigne l'adresse utilisée avec le masque de sous-réseau pour identifier un hôte sur le réseau. Une adresse IP n'est pas une méthode efficace d'identification d'une ressource parce qu'elle est change fréquemment.

• Adresse MAC de chaque carte d'interface réseau. L'adresse MAC est une adresse 48 bits unique utilisée pour identifier une interface réseau. Elle peut servir à différencier plusieurs interfaces réseau sur le même périphérique.

• Système d'exploitation, service pack et versions de correctifs. La version du système d'exploitation est un facteur clé permettant de déterminer l'aptitude d'un hôte à communiquer avec IPSec. Il est également primordial de contrôler l'état actuel des service packs et des correctifs susceptibles d'être installés car ces éléments sont souvent utilisés pour déterminer si les normes de sécurité minimales sont respectées.

• Appartenance au domaine. Ces informations sont utilisées pour déterminer si un ordinateur peut se procurer la stratégie IPSec à partir d'Active Directory ou s'il doit utiliser une stratégie IPSec locale.

• Emplacement physique. Cette information représente simplement l'emplacement du périphérique de votre organisation. Vous pouvez l'utiliser pour déterminer si un périphérique doit participer à un groupe d'isolation particulier en fonction de son emplacement ou de l'emplacement des périphériques avec lesquels il communique régulièrement.

• Type/rôle du matériel. Ces informations ne sont parfois pas accessibles via un processus automatisé. Certains outils de détection d'hôtes peuvent permettre de les obtenir en sondant les informations liées au matériel, puis en exécutant des applications pour déterminer le type (serveur, station de travail ou Tablet PC). Vous pouvez également exploiter ces données afin d'évaluer le droit d'un ordinateur spécifique à participer au processus d'isolation et de définir le groupe d'isolation dans lequel le placer.

  Remarque : les informations ayant trait au type de matériel sont obtenues par interpolation des données ou par le biais d'un logiciel soumettant des requêtes en vue de se procurer ces informations. Par exemple, il est évident qu'un HP Evo n800 est un ordinateur portable. Si vous avez la possibilité de soumettre une requête au niveau du matériel (ou de le munir d'une étiquette d'inventaire l'identifiant en tant que tel), vous pouvez plus facilement déterminer la stratégie IPSec appropriée à attribuer au périphérique.

Après avoir collecté toutes ces informations et les avoir regroupées dans une base de données, procédez à intervalles réguliers à des opérations de détection afin de les tenir à jour. Vous aurez besoin d'un état complet et à jour des hôtes gérés sur les réseaux pour concevoir une solution conforme aux exigences de votre organisation.

Vous pouvez employer diverses méthodes pour recueillir des données sur les hôtes du réseau. Il peut s'agir de systèmes haut de gamme entièrement automatisés ou bien d'un processus d'extraction des données entièrement manuel. En règle générale, le recours aux méthodes automatisées de recueil des données est préférable aux méthodes manuelles pour des raisons de vitesse et de sécurité. Néanmoins, quelle que soit la méthode adoptée, les informations requises restent les mêmes. La seule différence concerne le temps nécessaire à l'obtention de ces données. Les processus manuels soulèvent généralement plusieurs difficultés : risque d'informations en double, portée de l'effort engagé (tous les réseaux ont-ils été analysés ? Les informations recueillies concernent-elles tous les hôtes ou simplement les sous-réseaux de clients ?) et recueil des données en temps utile. L'étude de tous les éléments d'un audit complet du système informatique dépasse le cadre de ce projet. Cependant, il est important de comprendre que ces informations d'audit jouent un rôle crucial pour l'organisation, un rôle qui dépasse largement les seuls besoins de cette solution. Le suivi des ressources et la gestion des risques de sécurité sont deux exemples de processus clés qui justifient la nécessité d'un inventaire système actualisé et minutieux.

Détection automatisée

L'emploi d'un système de gestion réseau avec audit automatisé, tel que SMS, permet d'obtenir des informations précieuses sur l'état actuel de l'infrastructure informatique. Les systèmes automatisés posent cependant un problème lié au fait que les hôtes hors connexion, débranchés ou en état d'incapacité physique (ou logique) de répondre à des demandes d'information n'apparaissent pas dans la base de données finale. Même les systèmes les plus automatisés exigent un degré de gestion manuelle pour s'assurer que les hôtes sont accessibles et pris en compte comme il se doit.

Nombre de produits et d'outils sont, dans ce domaine, proposés par divers fournisseurs. Certaines méthodes font appel à un mécanisme d'analyse centralisé, d'autres utilisent des agents installés sur les ordinateurs clients. L'objectif du présent guide n'est pas de comparer et de conseiller des produits à acheter mais la solution exige que les données de découverte et de détection détaillées dans ce chapitre soient disponibles pour les considérations de conception émises dans les chapitres 4 et 5.

Pour plus d'informations sur la manière dont SMS 2003 peut contribuer à la gestion des ressources (ou aider à recueillir les informations nécessaires à ce projet), accédez à la démonstration et à la fiche technique consacrée à la gestion des ressources à partir de la page SMS 2003 Asset Management  (Gestion du parc informatique avec Systems Management Server 2003) à l'adressewww.microsoft.com/smserver/evaluation/capabilities/
asset.asp.

Détection manuelle

La différence majeure entre les méthodes de détection manuelles et les méthodes automatisées est le temps. L'obtention manuelle des données requises pour ce projet peut mobiliser une bonne dizaine de personnes et exiger des jours ou des semaines, voire peut-être plus dans une entreprise de plus grande échelle. Si vous envisagez de recourir à une méthode manuelle pour procéder à un audit de l'état actuel de votre infrastructure, il est primordial que les informations recueillies soient disponibles dans un format électronique (par exemple, dans une feuille de calcul ou une base de données). Le volume de données susceptible d'être généré peut rendre le processus de filtrage et d'analyse très fastidieux si vous ne parvenez pas à soumettre avec rapidité et précision des requêtes spécifiques capables de renvoyer les informations requises. Qui plus est, vous pouvez faire appel aux administrateurs informatiques pour vous procurer les informations ou valider toutes les informations recueillies précédemment.

Même si votre organisation ne bénéficie pas d'un outil d'audit automatisé, il existe toujours une part d'automatisation possible via les interfaces de script et de gestion à distance standards disponibles sur la plate-forme Windows. La principale difficulté liée à l'utilisation de ces outils est de veiller à n'oublier aucun client simplement parce qu'il n'est pas compatible avec le script ou l'outil de gestion.

Vous pouvez utiliser l'environnement d'exécution de scripts Windows, Microsoft Visual Basic® Scripting Edition (VBScript) et Windows Management Instrumentation (WMI) pour créer un fichier de script capable de collecter des informations de configuration système. Le tableau ci-dessous décrit la disponibilité de VBScript et WMI par plate-forme.

Tableau 3.2 : Disponibilité de VBScript et WMI par plate-forme

Plate-forme	VBScript	WMI
Windows 95	Installer WSH 5.6	Installer WMI CORE 1.5
Windows 98	Intégré	Installer WMI CORE 1.5
Windows Millennium	Intégré	Intégré
Microsoft Windows NT® version 4.0	Installer WSH 5.6	Installer WMI CORE 1.5
Windows 2000	Intégré	Intégré
Windows XP	Intégré	Intégré
Windows Server 2003	Intégré	Intégré

Remarque : vous pouvez télécharger la mise à jour de Microsoft Windows Script 5.6 depuis la page Microsoft Windows Script Downloads  (téléchargements de Microsoft Windows Script) à l'adresse https://msdn.microsoft.com/library/default.asp?url=/
downloads/list/webdev.asp.
Vous pouvez télécharger également le fichier d'installation de Windows Management Instrumentation (WMI) CORE 1.5  depuis le Centre de téléchargement Microsoft à l'adresse www.microsoft.com/downloads/details.aspx?FamilyID=afe41f46-e213-4cbf-9c5b-fbf236e0e875\&DisplayLang=en.

Un exemple VBScript intitulé Discovery.vbs est fourni dans le dossier Tools and Templates de cette solution. Ce script utilise le service WMI pour extraire l'ensemble des données répertoriées dans la section « Données requises concernant les hôtes » de ce chapitre, à l'exception du rôle et de l'emplacement physique. Les informations sont rassemblées dans le fichier texte C:\Discovery\<systemname>_info.txt sur l'ordinateur local. Vous pouvez modifier le script pour collecter d'autres informations ou placer les informations collectées sur un partage de fichiers distant.

Si WMI ou VBScript n'est pas disponible sur l'ordinateur hôte, vous pouvez recueillir certaines informations à l'aide d'un script de commandes et d'outils externes. La difficulté vient du fait que le langage de commandes est extrêmement limité en termes de fonctionnalités et que les informations de configuration ne sont pas faciles à extraire de la ligne de commande dans les versions antérieures de Windows.

Pour procéder à une détection d'hôtes, il est nécessaire d'interroger les hôtes et de fournir un emplacement pour stocker les résultats obtenus.

Que vous optiez pour une méthode de collecte des données manuelle, automatique ou hybride, l'une des plus grandes difficultés pour garantir la validité de la conception consiste à connaître les modifications survenues entre l'analyse d'inventaire d'origine et le début de l'implémentation. Une fois la première analyse terminée, vous devez informer votre personnel de support que toutes les modifications futures doivent être enregistrées et les mises à jour consignées dans l'inventaire.

Cet inventaire est indispensable à la planification et l'implémentation des stratégies IPSec (sujets abordés dans les chapitres suivants).

Considérations relatives à la capacité

Une fois le processus de collecte des informations achevé, vous devez vous intéresser à l'impact d'IPSec, notamment en termes de planification de la capacité. Cette section décrit certains des éléments essentiels d'une planification en bonne et due forme d'IPSec dans votre environnement.

Impact d'IPSec

Du fait des diverses techniques cryptographiques auxquelles il fait appel, IPSec peut entraîner une consommation importante des ressources de l'ordinateur. Les scénarios qui exigeront une analyse plus profonde sont ceux qui préconiseront un chiffrement. Par exemple, un scénario peut envisager l'utilisation des algorithmes 3DES (Triple Data Encryption Standard) et SHA-1 (Secure Hash Algorithm) pour vérifier l'intégrité dans des situations qui exigent la plus forte protection disponible en termes d'échange de clés et de chiffrement. Un autre scénario impliquera la négociation de l'association de sécurité. Vous pouvez opter pour une durée plus courte pour l'association de sécurité en mode principal (par exemple, trois heures) mais comme dans toutes considérations ayant trait à la sécurité, soyez prêt à faire des compromis. Chaque association de sécurité en mode principal consomme environ 5 Ko de mémoire vive (RAM). Une situation dans laquelle un serveur est contraint de négocier des dizaines de milliers de connexions simultanées peut entraîner une consommation abusive. D'autres facteurs concernent l'utilisation du processeur sur les serveurs de l'infrastructure réseau, la consommation accrue des ressources sur les serveurs et les stations de travail exécutant IPSec (surtout les serveurs puisque, dans la plupart des cas, ils comportent un plus grand nombre d'associations de sécurité en mode principal que les clients) et le temps de réponse du réseau plus long résultant de la négociation IPSec.

Remarque : dans le cadre de son propre scénario de déploiement de cette solution, Microsoft a constaté qu'une augmentation possible (de l'ordre de un à trois pour cent) de la charge réseau est tout à fait normale. Cette augmentation est une conséquence directe de l'utilisation d'IPSec.

Un autre problème majeur concerne les réseaux reliés par un périphérique de traduction d'adresses réseau (NAT). Il vient du fait que la traduction d'adresses réseau (NAT) n'autorise pas les conversations d'authentification de l'en-tête (AH) entre les hôtes parce qu'elle est contraire au principe même du protocole AH : l'authentification d'un paquet inchangé, y compris l'en-tête. Si des périphériques NAT existent sur le réseau interne, préférez le protocole ESP au protocole AH. Le protocole ESP offre la possibilité de chiffrer les données mais n'exige pas le chiffrement. Ce facteur est essentiel en terme d'évaluation de la capacité puisque le chiffrement implique une surcharge dont il faut tenir compte pendant les phases de planification et de conception du projet. Le protocole ESP peut également être implémenté sans chiffrement et, ainsi, offrir la communication homologue à homologue la plus forte sans rompre les communications avec la traduction d'adresses réseau (NAT). Utilisé sans chiffrement, son impact serait donc plus faible qu'une solution ESP avec chiffrement.

Impact de la stratégie

La stratégie IPSec et la stratégie de groupe ont toutes les deux un impact sur les temps de démarrage des ordinateurs et sur le temps nécessaire aux utilisateurs pour se connecter. Lors de la phase de recueil des données, il peut être utile de relever les temps de démarrage des ordinateurs et les temps de connexion des utilisateurs avant d'implémenter la solution. L'enregistrement de ces données fournira un élément de base avec lequel vous pourrez comparer les systèmes testés lors de l'étape pilote afin de déterminer l'impact sur le temps global nécessaire à un utilisateur pour se connecter.

Problèmes de prédéploiement

Les sections précédentes décrivaient les informations à recueillir à partir du réseau, d'Active Directory et des hôtes pour garantir le succès d'un projet d'isolation. Cette section signale les domaines de préoccupation à examiner de près avant de déployer IPSec.

Infrastructure réseau

Le recueil d'informations vous permet de planifier une isolation IPSec sur un réseau. Une fois ces informations collectées, vous pourrez procéder à une analyse minutieuse des données qui révèlera la majorité des problèmes auxquels vous serez confronté lors de la phase pilote et du déploiement. Bien que les éléments suivants ne soient pas exhaustifs, il est important de les prendre en considération au moment d'entamer l'analyse des informations recueillies avant les tests et le déploiement.

Périphériques surexploités

Vous devrez peut-être mettre à niveau ou reconfigurer les commutateurs ou les routeurs exploités actuellement à plus de 75 pour cent pour permettre un trafic accru sur le périphérique et garantir une marge d'utilisation supplémentaire en cas de pointes de trafic. Dans le contexte d'une implémentation IPSec, la planification en bonne et due forme de la capacité est plus une affaire de tests et de charges de trafic anticipées que de calculs précis. Parce qu'il est fort improbable que le scénario, les modèles de trafic, les groupements d'utilisateurs et les applications soient les mêmes pour deux clients, une planification appropriée et la prise en compte de l'impact sur les périphériques du réseau sont indispensables. Par exemple, certains aspects d'IPSec sont totalement prévisibles. Chaque paquet utilisant IPSec avec ESP sera exactement 36 octets plus volumineux que le même paquet n'utilisant pas IPSec. Savoir que la création d'une seule association de sécurité en mode principal exige six messages permet de se représenter plus facilement quel sera l'impact de son utilisation sur un périphérique donné. Vous pouvez utiliser des outils tels que l'application PROVISO de Quallaby  (disponible sur www.quallaby.com), ou d'autres solutions d'analyse réseau pour faciliter votre travail de planification de la capacité IPSec dans votre environnement informatique.

Périphériques incompatibles

Les périphériques qui ne sont pas compatibles avec IPSec ne peuvent pas participer aux communications IPSec. Si ces périphériques ont besoin de communiquer avec un périphérique géré, placez-les dans la liste d'exemptions IPSec. Une autre solution consiste à mettre à niveau le matériel ou les logiciels des périphériques afin qu'ils prennent en charge IPSec. Une autre encore est de permettre à ces périphériques non gérés de communiquer avec des ordinateurs voisins lorsqu'ils communiquent en texte clair pour leurs communications sortantes.

Périphériques mal configurés

Des périphériques mal configurés peuvent augmenter le risque d'échec des communications et de charge accrue sur le périphérique, mais aussi compromettre leur intégrité. Les méthodes de configuration, d'administration et de sécurité conseillées ci-après permettront de réduire les risques.

Adressage IP

Parce que les adresses IP constituent la pierre d'angle d'une solution IPSec, il est primordial que l'adressage soit aussi net que possible. Des espaces d'adresses se chevauchant, des adresses en double, des masques de sous-réseau incorrects et bien d'autres problèmes peuvent compliquer les opérations réseau classiques. L'apport d'IPSec à un réseau de ce type ne fera que compliquer le dépannage et incitera les utilisateurs à penser qu'IPSec est la source de tous ces problèmes. La croissance des entreprises, les fusions et les acquisitions, et bien d'autres facteurs encore, peuvent rapidement contribuer au développement d'une image fausse et obsolète de l'adressage IP sur un réseau. Pour éviter les problèmes majeurs liés à IPSec, assurez-vous que le réseau est divisé en sous-réseaux qui ne se chevauchent pas, que les tables de routage sont récapitulées comme il se doit et que l'agrégation par adresses est facile à déterminer.

Informations Active Directory

Si l'implémentation actuelle d'Active Directory fonctionne correctement (résolutions des noms, DHCP (Dynamic Host Configuration Protocol), application de la stratégie de groupe, relations d'approbation, etc.), rien ne saurait affecter IPSec. Surveillez attentivement les modifications effectuées entre le moment où Active Directory a été examiné et le début du projet d'isolation pour vous assurer qu'aucun problème de compatibilité ne surviendra.

Informations concernant les hôtes

Grâce aux sections précédentes, vous avez pu recueillir suffisamment d'informations sur les hôtes de votre réseau. Après avoir déterminé les clients et les serveurs aptes à utiliser IPSec, réfléchissez sur la manière de les isoler et aux applications nécessaires pour évaluer avec soin l'impact que la solution d'isolation peut avoir sur eux.

Évaluation de la participation client/serveur

Une fois les informations concernant les hôtes rassemblées, il est relativement simple de sélectionner les hôtes susceptibles d'être intégrés à la solution d'isolation. Par exemple, seuls des ordinateurs Windows 2000, Windows Server 2003 et Windows XP peuvent communiquer avec IPSec. Toutefois, tous les clients aptes à participer ne doivent pas nécessairement le faire. Une étape clé du processus de conception consiste à déterminer à partir des informations recueillies dans ce chapitre quels ordinateurs et périphériques seront inclus dans la solution et dans quel groupe ils résideront.

Définition des services devant être isolés

Dans le contexte d'un projet d'isolation de serveurs et de domaines, un service désigne une application (par exemple, Microsoft Exchange Server, Microsoft SQL Server™ ou Internet Information Services/IIS) qui offre ses services à des clients du réseau. Vous devez évaluer ces services de manière individuelle afin de déterminer s'ils sont des candidats à l'isolation de serveurs et de domaines. Plusieurs raisons peuvent justifier l'intégration de ces services dans la solution. Cela peut être une question de stratégie d'organisation, d'exigence réglementaire ou d'impératif commercial. Par exemple, une stratégie de l'organisation peut stipuler que toutes les communications entre les serveurs de messagerie doivent être sécurisées avec IPSec, mais pas les communications entre les clients et les serveurs. Le chapitre 4, « Conception et planification de groupes d'isolation », aborde le processus d'isolation plus en détail. Lorsque vous tentez d'isoler des services, examinez avec soin les serveurs qui font intervenir plusieurs services, comme dans le cas d'un serveur de fichiers offrant des services Web et un service FTP (File Transfer Protocol) et faisant également office de serveur de messagerie.

Équilibrage de la charge réseau et clusters

Les organisations qui utilisent l'isolation de serveurs et de domaines peuvent choisir d'exclure les ordinateurs ayant recours à l'équilibrage de la charge réseau et aux clusters. IPSec n'est pas compatible avec l'équilibrage de la charge réseau en mode « sans affinité » puisqu'il empêche différents ordinateurs d'exploiter la même connexion cliente. Du fait de cette incompatibilité, il est préférable d'éviter l'équilibrage de la charge réseau en mode « sans affinité » avec IPSec.

Gestion des exceptions

La gestion des exceptions est une étape essentielle de la planification IPSec. Savoir où utiliser les ordinateurs qui autoriseront l'accès depuis les hôtes non approuvés et comment contrôler l'accès entre les ordinateurs gérés et non gérés est un paramètre essentiel de l'isolation. La meilleure méthode conseillée dans ce domaine est de maintenir le nombre d'exceptions aussi réduit que possible. Les besoins techniques peuvent exiger que certains ordinateurs ou services soient exemptés d'IPSec, notamment les contrôleurs de domaine et les serveurs DHCP, DNS et WINS. Étant donné la nécessité de gérer en permanence ces ordinateurs, le risque encouru est plus faible que d'autoriser les ordinateurs non gérés à communiquer avec des ordinateurs gérés et approuvés.

Périphériques non-Windows

La plupart des réseaux d'entreprise ne sont pas homogènes. Vous devez tenir compte de la diversité des éléments, tels que les systèmes d'exploitation, l'infrastructure réseau et les plates-formes matérielles lorsque vous planifiez le déploiement d'IPSec. Si votre organisation possède des ordinateurs exécutant un système autre que Windows, vous devez comprendre que la consommation de la stratégie IPSec hors du domaine Windows n'est actuellement pas possible. Une organisation peut décider de faire face à cette restriction en traitant certaines plates-formes comme approuvées mais la solution d'isolation de serveurs et de domaines ne les protègera pas puisque ces plates-formes sont dans l'incapacité d'exploiter la stratégie IPSec. La section qui suit explique comment déterminer l'approbation.

Périphériques de gestion et de contrôle

Un aspect d'IPSec souvent ignoré lors de la phase de planification initiale est son impact sur la gestion et le contrôle du trafic du réseau. Parce qu'IPSec exige une authentification et autorise le chiffrement, certains périphériques ne sont plus en mesure de contrôler ou de gérer les ordinateurs activés avec IPSec. Dans certains cas exigeant un chiffrement, une organisation peut supposer que la sécurité est plus importante que le besoin opérationnel de contrôler les données tandis qu'elles transitent sur le réseau. Dans d'autres cas, il sera nécessaire d'évaluer les modifications que vous pouvez apporter à une application ou un périphérique pour activer le contrôle IPSec (par exemple, un analyseur ESP capable d'examiner le trafic ESP). S'il s'avère impossible de mettre à niveau les périphériques de contrôle ou de gestion pour la prise en charge d'IPSec, il est crucial alors que vous enregistriez ces informations. L'architecte de la solution et l'équipe qui l'entoure auront besoin de ces informations au chapitre 4, « Conception et planification de groupes d'isolation ».

Définition de l'approbation

Après avoir rassemblé des informations sur les périphériques hôtes qui composent actuellement votre infrastructure informatique, vous devez déterminer de manière fondamentale ce qui affecte directement la capacité d'un hôte à participer à la solution. L'objectif est de décider jusqu'à quel point un hôte peut être considéré comme approuvé. Le terme « approuvé » peut signifier différentes choses pour différentes personnes ; il est donc important de parvenir à une définition précise afin de la communiquer à toutes les parties prenantes. Ne pas le faire, c'est risquer d'exposer la sécurité de l'environnement approuvé à des problèmes puisque la sécurité globale ne peut aller au-delà du niveau de sécurité défini par le client le moins sécurisé autorisé à adopter l'état approuvé.

Pour comprendre ce concept, tenez compte des quatre états de base applicables aux hôtes d'une infrastructure informatique classique. Ces états sont (par degré de risque, avec le risque le plus faible en premier) les suivants :

1. Approuvé

2. Digne de confiance

3. Connu, non approuvé

4. Inconnu, non approuvé

Le reste de cette section définit ces états et explique comment déterminer dans votre organisation quels hôtes appartiennent à quel état.

État Approuvé

Le classement d'un hôte comme approuvé ne signifie pas que l'hôte en question est parfaitement sécurisé ou invulnérable. Fondamentalement, « approuvé » signifie que les risques de sécurité de l'hôte sont gérés. La responsabilité de cet état géré revient aux administrateurs et aux utilisateurs informatiques responsables de la configuration de l'hôte. Un hôte approuvé mal géré peut devenir une faiblesse et mettre en péril la solution tout entière.

Lorsqu'un hôte est considéré comme approuvé, les autres hôtes approuvés doivent pouvoir légitimement partir du principe que cet hôte ne commettra aucun acte malveillant. Par exemple, des hôtes approuvés ne peuvent s'attendre à une attaque de virus de la part d'autres hôtes puisque tous les hôtes approuvés doivent recourir à des mécanismes (notamment un logiciel antivirus) visant à minimiser les risques de virus.

La communication entre hôtes approuvés ne doit pas être gênée par l'infrastructure du réseau. Par exemple, si un hôte approuvé peut librement partir du principe qu'aucun autre hôte approuvé ne commettra d'acte malveillant à son encontre, le blocage des paquets au niveau IP destiné à limiter l'accès d'autres hôtes approuvés n'est généralement pas nécessaire. Vous devez appliquer toutes les restrictions nécessaires au contrôle des communications des hôtes par port ou protocole en utilisant un pare-feu basé sur l'hôte sur l'ordinateur lui-même, pas en utilisant IPSec.

Dans le scénario imaginé pour la Woodgrove Bank, l'équipe de la sécurité a défini les cinq objectifs clés suivants afin de planifier les technologies nécessaires à l'hôte pour atteindre l'état approuvé :

• L'identité de l'ordinateur ou de l'utilisateur n'a pas été compromise.

• Les ressources requises sont sécurisées et disponibles, quel que soit leur emplacement dans l'environnement géré.

  • Une ressource jugée sécurisée est protégée contre tout risque de falsification, de virus ou de tentative d'accès non autorisé.

  • Une ressource signalée comme étant disponible respecte ou dépasse les niveaux attendus de durée active et est protégée contre toute faille de sécurité.

  • Un environnement considéré comme géré dispose d'ordinateurs dotés de Windows 2000 SP4 (ou une version ultérieure) et de la configuration et des correctifs appropriés.

• Les données et les communications sont privées, ce qui signifie que seuls les destinataires concernés peuvent lire et utiliser ces informations.

• Le propriétaire ou l'opérateur du dispositif comprend et accepte de se conformer aux stratégies et aux procédures afin de maintenir la confiance accordée à l'environnement.

• La réaction face aux risques et aux menaces intervient en temps utile.

Forte de ces objectifs, l'équipe du support de la Woodgrove Bank a pu définir un ensemble d'exigences technologiques permettant de déterminer si un hôte peut être considéré comme approuvé.

Au moment de définir l'état approuvé, assurez-vous que les propriétaires des ressources impliquées sont libres de définir des conditions de sécurité supplémentaires répondant aux besoins commerciaux d'une ressource ou d'un actif donné. Par exemple, votre service des ressources humaines peut exiger un mécanisme d'ouverture de session biométrique pour des serveurs spécifiques. Cette exigence n'aura aucune incidence sur la confiance à accorder aux serveurs dans le contexte de cette solution. Néanmoins, vous devez rester vigilant et veiller à ce que les exigences d'une ressource particulière n'entrent pas en conflit avec celles de l'état approuvé.

Consacrez un peu de temps à la définition des objectifs et des besoins technologiques que votre organisation juge convenables en tant que configuration minimale pour l'octroi de l'état approuvé à un hôte.

Par exemple, l'équipe de conception a dressé ci-dessous la liste des exigences technologiques requises dans le cadre du scénario de la Woodgrove Bank.

• Système d'exploitation. Un hôte approuvé doit exécuter Windows XP SP2 ou Windows Server 2003, ou au minimum Windows 2000 SP4.

• Appartenance au domaine. Un hôte approuvé appartient à un domaine géré, ce qui signifie que le service informatique doit posséder des droits de gestion de la sécurité.

• Client de gestion. Tous les hôtes approuvés doivent exécuter un client de gestion réseau spécifique pour permettre une gestion centralisée et un contrôle des stratégies de sécurité, des configurations et des logiciels.

• Logiciel antivirus. Tous les clients approuvés doivent être dotés d'un logiciel antivirus configuré en vue de mettre à jour automatiquement et quotidiennement les derniers fichiers de signatures de virus.

• Système de fichiers. Tous les hôtes approuvés seront configurés avec le système de fichiers NTFS.

• Paramètres du BIOS. Tous les ordinateurs portables approuvés seront configurés avec un mot de passe au niveau du BIOS contrôlé par l'équipe du support informatique.

• Conditions requises pour les mots de passe. Les clients approuvés doivent utiliser des mots de passe forts.  

Un élément essentiel à comprendre est le fait que l'état approuvé n'est pas constant. C'est un état de transition soumis à des normes de sécurité qui évoluent et au besoin de se conformer à ces normes. De nouvelles menaces et de nouveaux principes de défense apparaissent constamment. C'est pourquoi il est impératif que les systèmes de gestion de l'organisation vérifient en permanence les hôtes approuvés pour garantir une conformité continue. Qui plus est, ces systèmes doivent être capables d'émettre des mises à jour ou des changements de configuration s'ils sont chargés de maintenir l'état approuvé.

Un hôte apte à répondre en permanence à l'ensemble des exigences de sécurité peut être considéré comme approuvé. Néanmoins, il est fort probable que la plupart des ordinateurs hôtes identifiés au cours du processus de détection et de découverte abordé plus haut dans ce chapitre ne répondent pas à ces exigences. Il est donc primordial de distinguer les hôtes qui peuvent être approuvés de ceux qui ne le peuvent pas (considérés alors comme non approuvés). Pour faciliter ce processus, vous pouvez définir un état Digne de confiance intermédiaire. Le reste de cette section aborde les différents états et leurs implications.

État Digne de confiance

Si nécessaire, il peut être utile d'identifier au plus vite dans votre infrastructure actuelle les hôtes aptes à devenir approuvés. Un état Digne de confiance peut être attribué à l'hôte actuel pour confirmer son aptitude physique à devenir approuvé en effectuant les modifications requises au niveau des logiciels et de la configuration.

Pour chaque ordinateur auquel vous attribuez un état Digne de confiance, pensez à ajouter une note de configuration consignant les conditions permettant à l'hôte d'atteindre l'état approuvé. Ces informations revêtent une importance toute particulière pour l'équipe de conception du projet (afin d'estimer les coûts résultant de l'ajout de l'hôte à la solution) et le personnel du support (pour pouvoir appliquer la configuration requise). En règle générale, les hôtes dignes de confiance tombent dans l'un des deux groupes suivants :

• Configuration requise. Le matériel utilisé, le système d'exploitation et le logiciel actuels permettent à l'hôte d'atteindre un état Digne de confiance. En revanche, des changements de configuration supplémentaires sont nécessaires avant de parvenir aux niveaux de sécurité requis. Par exemple, si l'organisation exige un système de fichiers sécurisé avant de pouvoir considérer un hôte comme approuvé, un hôte avec un disque dur de format FAT32 ne pourra pas satisfaire cette exigence.

• Mise à niveau requise. Ce groupe d'ordinateurs exige des mises à niveau système avant d'être considéré comme approuvé. La liste suivante fournit quelques exemples sur le type de mise à niveau que les ordinateurs de ce groupe peuvent exiger :

  • Mise à niveau du système d'exploitation requise. Si le système d'exploitation actuel de l'hôte n'est pas capable de prendre en charge les exigences de sécurité de l'organisation, une mise à niveau sera nécessaire pour que l'hôte puisse accéder à l'état approuvé.

  • Logiciel requis. Un hôte non doté de l'application de sécurité requise (par exemple, un outil d'analyse antivirus ou un client de gestion) ne peut être considéré comme approuvé tant que les applications nécessaires n'ont pas été installées et activées.

  • Mise à niveau matérielle requise. Dans certains cas, un hôte peut exiger une mise à niveau matérielle spécifique avant d'être déclaré comme approuvé. Il s'agit généralement d'une mise à niveau du système d'exploitation ou d'un logiciel supplémentaire forçant la mise à niveau matérielle requise. Par exemple, un logiciel de sécurité nécessitant un espace de stockage supplémentaire exigera davantage d'espace sur le disque dur.

  • Changement d'ordinateur requis. Cette catégorie est réservée aux hôtes inaptes à satisfaire les exigences de sécurité de la solution du fait de leur incapacité matérielle à prendre en charge la configuration minimale acceptable. Il peut s'agir d'un ordinateur incapable d'exécuter un système d'exploitation sécurisé parce qu'il est doté d'un processeur trop ancien (par exemple, un ordinateur x86 de 100 mégahertz).

Utilisez ces groupes pour répartir les coûts d'implémentation de la solution sur des ordinateurs exigeant des mises à niveau.

État Connu, non approuvé

Lors du processus de catégorisation des hôtes d'une organisation, vous identifierez certains hôtes incapables de parvenir à un état approuvé pour des raisons bien connues et clairement définies. Ces raisons peuvent être de type suivant :

• Financier. Les fonds nécessaires à la mise à niveau du matériel ou des logiciels de cet hôte ne sont pas disponibles.

• Politique. L'hôte doit demeurer dans un état non approuvé en raison d'une situation politique ou commerciale qui ne lui permet pas de satisfaire les exigences de sécurité minimales dictées par l'organisation. Nous vous conseillons alors fortement de contacter le responsable de l'entreprise ou le fournisseur de logiciels indépendant de l'hôte pour débattre de la valeur ajoutée de l'isolation de serveurs et de domaines.

• Fonctionnel. L'hôte a besoin d'exécuter un système d'exploitation non sécurisé ou d'opérer de manière non sécurisée pour accomplir son rôle. Par exemple, l'hôte doit peut-être être utilisé avec un système d'exploitation plus ancien en raison d'une série d'applications commerciales spécifiques ne fonctionnant que sur ce système.

Beaucoup de raisons fonctionnelles peuvent justifier le maintien d'un hôte en état connu non approuvé. La liste suivante présente quelques exemples de motifs fonctionnels susceptibles de justifier un classement dans cet état :

• Ordinateurs dotés de Windows 9 x ou Windows Millennium Edition. Les ordinateurs munis de ces versions particulières du système d'exploitation Windows ne peuvent pas être classées comme dignes de confiance car ces systèmes d'exploitation ne prennent en charge aucune infrastructure de sécurité de base. En fait, de par leur conception, ces systèmes ne disposent d'aucune infrastructure de sécurité. Qui plus est, les fonctions de gestion centrale rudimentaires dont ils sont pourvus ne concernent que des configurations informatiques pour utilisateurs (via la stratégie système et les scripts d'ouverture de session). Pour finir, ces systèmes d'exploitation n'offrent aucune des fonctionnalités requises pour la gestion de la sécurité.

• Ordinateurs dotés de Windows NT. Les ordinateurs dotés de Windows NT ne peuvent pas être classés comme dignes de confiance dans le contexte de l'isolation de serveurs et de domaines puisque ce système ne prend pas intégralement en charge une infrastructure de sécurité élémentaire. Par exemple, Windows NT ne prend pas en charge les listes de contrôle d'accès de refus dans les ressources locales, toute méthode visant à garantir la confidentialité et l'intégrité des communications réseau, les cartes à puce pour une authentification renforcée ou une gestion centralisée des configurations d'ordinateurs (bien qu'une gestion centralisée limitée des configurations d'utilisateurs soit possible). Windows NT n'offre aucun moyen de protéger la confidentialité des données et de maintenir leur intégrité, tel que le système EFS (Encrypting File System) de Windows 2000.

  En outre, il ne prend pas en charge l'ensemble des fonctionnalités de sécurité requises. Par exemple, il ne prend pas en charge la stratégie de groupe ou les stratégies IPSec et ne fournit aucun mécanisme garantissant un accès au niveau Administrateur local si cela est nécessaire. Enfin, ses configurations de sécurité n'étant pas réappliquées régulièrement, il n'existe aucune garantie qu'elles demeurent effectives.

  Remarque : la description de Windows NT comme système n'étant pas digne de confiance se limite strictement au contexte de l'isolation de serveurs et de domaines et ne concerne d'aucune manière son utilisation en tant que système d'exploitation dans le sens large du terme. Pour les serveurs de ce projet, la mise à niveau vers la plate-forme Windows Server 2003 représente la solution la plus sûre et la plus facile à gérer.

• Ordinateurs autonomes. Les ordinateurs dotés d'une version quelconque de Windows et configurés comme ordinateurs autonomes ou en qualité de membres d'un groupe de travail sont, en règle générale, incapables de parvenir à un état digne de confiance. Même si ces systèmes d'exploitation prennent intégralement en charge l'infrastructure de sécurité de base minimale requise, il est peu probable que les fonctionnalités requises pour la gestion de la sécurité soient garanties lorsque l'ordinateur n'est pas membre d'un domaine approuvé.

• Ordinateurs dans un domaine non approuvé. Un ordinateur membre d'un domaine qui n'est pas approuvé par le service informatique d'une organisation ne peut pas être classé comme approuvé. Un domaine non approuvé est un domaine qui n'offre pas les fonctionnalités de sécurité requises à ses membres. Même si les systèmes d'exploitation des ordinateurs membres de ce domaine non approuvé prennent intégralement en charge l'infrastructure de sécurité de base minimale requise, les fonctionnalités requises pour la gestion de la sécurité ne peuvent pas être garanties à 100 % lorsque les ordinateurs ne résident pas dans un domaine approuvé. Par exemple, dans un domaine non approuvé, il n'existe aucun mécanisme garantissant l'octroi d'un accès de niveau Administrateur local pour un utilisateur approuvé. De même, les configurations de sécurité (y compris celles qui peuvent être gérées de manière centrale) peuvent facilement être remplacées par les administrateurs du domaine non approuvé. Enfin, le respect de la configuration de sécurité, des logiciels, des stratégies et des normes ne peut être garanti et les mesures chargées de contrôler de manière efficace toutes les règles de conformité ne sont pas disponibles.

• Ordinateurs dans un domaine Windows NT. Les ordinateurs membres d'un domaine fondé sur Windows NT ne peuvent pas être classés comme étant approuvés. Même si leurs systèmes d'exploitation prennent intégralement en charge l'infrastructure de sécurité de base minimale requise, les fonctionnalités requises pour la gestion de la sécurité ne sont pas entièrement prises en charge lorsque les ordinateurs appartiennent à un domaine Windows NT.

  Néanmoins, si l'hôte doit être pris en compte lors de la conception parce qu'il joue un rôle indispensable pour l'organisation, il est préférable que vous lui affectiez un état connu, non approuvé. Cela signifie alors que la solution a identifié un risque qu'elle ne peut minimiser. Vous devez faire appel à d'autres techniques pour répondre à cette menace connue. En raison de la nature variée des hôtes appartenant à cette catégorie, aucune instruction spécifique concernant ces techniques ne peut être fournie. Néanmoins, l'objectif de ces techniques doit être de minimiser les risques posés par cet hôte.  

État Inconnu, non approuvé

L'état Inconnu, non approuvé doit être utilisé comme état par défaut pour tous les hôtes. Du fait de la configuration inconnue des hôtes affichant cet état, aucune confiance ne peut leur être accordée. Le processus tout entier de planification des hôtes dans cet état doit partir du principe que l'hôte risquait ou risque d'être compromis et constitue, par conséquent, un risque inacceptable pour l'organisation. Les personnes chargées de concevoir la solution doivent s'efforcer de minimiser l'impact potentiel des ordinateurs dotés de cet état sur leurs organisations.

Identification des coûts de mise à niveau des hôtes actuels

L'ultime étape de ce chapitre concerne le processus d'enregistrement du coût approximatif de la mise à niveau des ordinateurs en vue de rendre ces derniers aptes à contribuer à la solution. Plusieurs décisions seront à prendre lors de la phase de conception du projet et exigeront que vous répondiez aux questions suivantes :

• L'ordinateur répond-il aux exigences de configuration matérielle requises pour l'isolation ?

• L'ordinateur répond-il aux exigences de configuration logicielle requises pour l'isolation ?

• Quelles modifications devez-vous apporter à la configuration pour intégrer cet ordinateur à la solution d'isolation ?

• Quel coût prévisionnel ou impact suite aux modifications proposées peut permettre de parvenir à un état approuvé ?

En répondant à ces questions, vous pouvez rapidement déterminer le niveau d'effort et le coût approximatif requis pour intégrer un hôte ou un groupe d'hôtes particulier à l'échelle du projet. Il est fort probable qu'aucune personne, voire plusieurs personnes dans un seul rôle, ne rassemble toutes ces données. Certaines de ces données peuvent être recueillies par des techniciens du support technique ou d'un service de terrain ; d'autres exigeront le point de vue d'un architecte ou d'un membre de la direction. Gardez toujours à l'esprit que l'état d'un ordinateur est transitif et qu'en entreprenant les actions correctives présentées, vous pouvez changer l'état d'un ordinateur et le faire passer de non approuvé à approuvé. Après avoir décidé si un ordinateur doit être approuvé ou non, vous êtes p rêt à entamer le proce ssus de planification et de conception, thèmes que le chapitre 4 (« Conception et planification de groupes d'isolation ») aborde plus loin dans ce guide.

Le tableau ci-dessous est un exemple de fiche à l'aide de laquelle vous pouvez identifier l'état actuel d'un hôte et les conditions de son passage à un état approuvé.

Tableau 3.3 : Exemple de données collectées sur l'hôte

Nom de l'hôte	Config. matérielle conforme	Config. logicielle conforme	Configuration. requise	Détails	Coût prévisionnel
HOST-NYC-001	Non	Non	Mise à niveau matérielle et logicielle	Le système d'exploitation actuel est Windows NT 4.0. L'ancien matériel n'est pas compatible avec Windows XP SP2.	$XXX.
SERVER-LON-001	Oui	Non	Intégrer domaine approuvé, mettre à niveau de NT 4 vers Windows 2000 ou ultérieur.	Aucun logiciel antivirus présent.	$XXX.

La liste suivante explique chaque colonne du tableau 3.3 :

Nom de l'hôte. Nom du dispositif hôte sur le réseau.

• Configuration matérielle conforme. Indique si un ordinateur répond aux exigences de configuration matérielle requises pour participer à la solution.

• Configuration logicielle conforme. Indique si un ordinateur répond aux exigences de configuration logicielle requises pour participer à la solution. Le minimum requis pour la Woodgrove Bank est Windows 2000 SP4, Windows XP SP2 ou Windows Server 2003, ainsi que tous les correctifs de sécurité requis pour chaque système d'exploitation. De plus, tous les ordinateurs doivent appartenir à un domaine approuvé (soit un domaine géré centralement par le personnel informatique de la Woodgrove Bank) et fournir de manière spécifique aux administrateurs informatiques un accès à l'ordinateur.

• Configuration requise. Indique quelle action entreprendre pour permettre à l'ordinateur d'atteindre l'état approuvé.

• Détails. Décrit les raisons pour lesquelles l'ordinateur n'affiche actuellement pas un état approuvé.

• Coût prévisionnel. Indique le coût prévisionnel qui permettra au périphérique d'accéder à un état approuvé. Ce coût doit inclure des estimations portant sur les logiciels, le matériel, la perte de productivité et le support. Ces informations permettront de déterminer s'il est pratique ou valable du point de vue commercial d'ajouter à la solution un ordinateur particulier en tant qu'ordinateur approuvé.

Dans le tableau précédent, l'hôte HOST-NYC-001 est actuellement « connu, non approuvé ». Néanmoins, il peut être considéré comme digne de confiance si les mises à niveau requises sont possibles. Cependant, si un grand nombre d'ordinateurs exigent les mêmes mises à niveau, le coût global de la solution peut considérablement augmenter.

L'hôte SERVER-LON-001 répond aux conditions matérielles requises mais doit être mis à niveau vers un système d'exploitation capable d'exploiter la stratégie IPSec et associé à un domaine. Il requiert également un logiciel antivirus. Le coût prévisionnel correspond à la somme des efforts requis pour mettre à niveau le système d'exploitation et installer des logiciels antivirus, plus le coût des licences du système d'exploitation et des logiciels antivirus.

Après vous être procuré les informations décrites dans le tableau 3.3, enregistrez-les avec les autres informations rassemblées au cours de ce chapitre afin que l'architecte ou l'équipe de conception puisse les exploiter. Ces informations constitueront la base des efforts entrepris au chapitre 4 qui se concentre sur la conception des groupes d'isolation.

Notez que les coûts identifiés dans cette section concernent uniquement le coût prévisionnel des mises à niveau des hôtes. Beaucoup d'autres coûts liés à la conception, au support, aux tests et à la formation viendront se greffer au projet. Ces coûts supplémentaires devront être pris en compte dans le plan global du projet si un coût précis doit être évalué pour le projet.

Résumé

Ce chapitre offre un aperçu des informations requises pour mener un projet d'isolation de serveurs et de domaines, notamment les considérations d'impact. Vous pouvez utiliser les instructions de ce chapitre pour effectuer les opérations suivantes :

• Identifier les ressources sur le réseau.

• Rassembler des informations sur le réseau.

• Rassembler des informations sur les hôtes.

• Définir les données du trafic actuel.

• Examiner l'architecture Active Directory actuelle et recueillir des informations pertinentes la concernant.

• Examiner les éléments à considérer en terme de capacité IPSec.

• Afficher les considérations de prédéploiement pour IPSec.

• Expliquer ce que sont des dispositifs dignes ou non dignes de confiance et comment ils ont été classés dans le scénario imaginé pour la Woodgrove Bank.

La réalisation de ces tâches permettra de réunir toutes les informations dont vous aurez besoin pour lancer la conception de groupes d'isolation au chapitre suivant.

Informations complémentaires

Cette section fournit des liens vers des informations supplémentaires pouvant s'avérer utiles lors de l'implémentation de cette solution :

• Pour plus d'informations sur la configuration des pare-feu pour la prise en charge d'IPSec pour Windows Server 2003, consultez la page Configuring Firewalls  (Configuration des pare-feu) de la documentation Windows Server 2003 à l'adresse www.microsoft.com/resources/documentation/
  WindowsServ/2003/all/deployguide/en-us
  /dnsbj_ips_schx.asp.

• Vous pouvez télécharger le pack d'installation de Windows Management Instrumentation (WMI) CORE 1.5 (Windows 95/98/NT 4.0)  depuis le Centre de téléchargement de Microsoft à l'adresse www.microsoft.com/downloads/details.aspx?
  FamilyID=afe41f46-e213-4cbf-9c5b-fbf236e0e875&DisplayLang=en.

• Pour plus d'informations sur WMI, consultez la documentation Windows Management Instrumentation  sur MSDN® à l'adresse https://msdn.microsoft.com/library/en-us/wmisdk/
  wmi/wmi_start_page.asp.

• Vous pouvez télécharger Microsoft Windows Script 5.6 pour Windows 2000 et XP  depuis le Centre de téléchargement de Microsoft à l'adresse www.microsoft.com/downloads/details.aspx?
  FamilyId=C717D943-7E4B-4622-86EB-95A22B832CAA&displaylang=en.

• Vous pouvez télécharger Microsoft Windows Script 5.6 pour Windows 98, Windows Millennium Edition et Windows NT 4.0  depuis le Centre de téléchargement de Microsoft à l'adresse www.microsoft.com/downloads/details.aspx?
  FamilyId=0A8A18F6-249C-4A72-BFCF-FC6AF26DC390&displaylang=en.

• Vous pouvez télécharger la documentation de Windows Script 5.6  depuis le Centre de téléchargement de Microsoft à l'adresse www.microsoft.com/downloads/details.aspx?
  FamilyId=01592C48-207D-4BE1-8A76-1C4099D7BBB9&displaylang=en.

Télécharger la solution complète

Isolation de serveurs et de domaines à l'aide d'IPSec et de stratégies de groupe