Internet Data Center : Infrastructure de sécurité

Sur cette page

Microsoft Internet Data Center : Infrastructure de sécurité
Résumé
Introduction
Programme STPP (Strategic Technology Protection Program)
Sécuriser
Rester sécurisé
À qui s'adresse ce chapitre ?
Questions de conception
Ressources nécessaires
British Standard 7799
Phases BS 7799
Phase 1 : Evaluation
Phase 2 : Conception
Phase 3 : Déploiement
Phase 4 : Gestion
Développement d'une stratégie de sécurité informatique
Définition du rôle de directeur de la sécurité
Besoins en termes de personnel
Stratégie de défense approfondie
Défenses périmétriques
Défenses réseau
Défenses des hôtes
Défense des applications
Données et ressources
Méthodes courantes des pirates et mesures de prévention
Protection de l'architecture contre les techniques de reconnaissance
Limitation des possibilités d'analyse et d'obtention d'informations
Négociation à trois voies
Empreinte TCP
Protection du réseau contre l'analyse
Analyse via le pare-feu
Détection de bannière
Techniques utilisées pour accéder aux informations et accroître les privilèges
Empêcher le détournement de session
Empêcher la corruption DNS
Attaques par chaîne URL
Protection des systèmes contre les attaques par chaîne URL
Empêcher l'usurpation d'adresse IP
Protéger le fichier de mot de passe
Empêcher les débordements de tampon
Limitation des attaques de déni de service
Prévention des attaques déguisées
Comment les pirates tentent d'effacer leurs traces
Sécurisation de IIS
Autorisations, fichiers et répertoires
Autorisations
Exploration des répertoires
Contrôle du répertoire Scripts
Contrôle des fichiers exécutables
Définition de listes de contrôle d'accès appropriées sur les répertoires virtuels
Listes de contrôle d'accès par défaut recommandées par type de fichier
Recommandations relatives au système de fichiers IIS
Définition des ACL appropriées aux fichiers journaux IIS
Sécurité du réseau
Définition de restrictions d'adresse IP/adresse DNS
Mise à jour de certificats racine de l'autorité de certification sur le serveur IIS
Masquage de l'emplacement de contenu
Sécurisation du compte anonyme
Désactivation et suppression d'éléments
Désactivation et suppression des exemples d'applications
Désactivation ou suppression des composants COM inutiles
Suppression du répertoire virtuel IISADMPWD
Suppression des mappages de scripts non utilisés
Désactivation des chemins d'accès relatifs au répertoire parent
Structure Active Directory
Rôles de maître d'opérations
Affectation des rôles pour les opérations
Configuration Active Directory
Mode de domaine
Modèle de sécurité Windows 2000/stratégies Active Directory
Utilisation de stratégies pour appliquer la sécurité
Hiérarchie et héritage des stratégies
Stratégie de domaine
Stratégie de contrôleur de domaine
Application des stratégies de groupe
Topologie des unités d'organisation
Modèles de sécurité
Renforcement des serveurs pour l'architecture Internet Data Center
Se tenir informé des service packs et correctifs
Abonnement au service Microsoft Security Notification
Sécurisation du réseau
Rendre plus difficiles les attaques TCP/IP sur les serveurs de la zone DMZ
Implémentation de filtres IPSec sur des serveurs de la zone DMZ
Désactivation des services NetBIOS sur les serveurs de la zone DMZ
Sécurisation du système de fichiers
Limiter les autorisations NTFS par défaut
Suppression des partages de dossiers Administrateur par défaut sur les serveurs de la zone DMZ
Sécurisation de comptes
Sécurisation du compte Administrateur local sur les serveurs membres
Sécurisation du compte Administrateur du domaine
Audit de l'accès aux comptes
Désactivation de services
Détection des ports à l'écoute
Méthodes recommandées pour la sécurité des applications
Validation des applications Web
Développement d'applications Web
Méthodes recommandées pour la sécurité SQL Server 2000
Mode d'authentification
Compte administrateur système
Considérations relatives au compte de service
Système de fichiers
Considérations relatives au Registre
Considérations relatives à l'audit
Considérations relatives à la sauvegarde et à la restauration
Compte Invité Windows
Considérations relatives à l'accès physique
Utilisation d'alias
Délégation et Kerberos
Cryptage du trafic réseau
Système de fichiers de cryptage
Authentification
Concepts de sécurité
 Authentification
Autorisation
Identificateurs de sécurité (SID, Security Identifier)
Liste de contrôle d'accès (ACL, Access Control List)
Usurpation d'identité
COM+ et Windows 2000
Architecture de sécurité COM+
Authentification COM+
Niveaux d'authentification et de protection
Autorisation COM+
Source de l'authentification
Comparaison entre Active Directory et SQL Server
Authentification IIS 5.0
Accès anonyme
Authentification de base
Authentification Digest
Authentification Windows intégrée
Authentification par certificat client X.509
Contexte de sécurité des processus IIS
Performances relatives
Résumé

Microsoft Internet Data Center : Infrastructure de sécurité

Cet article est tiré du Guide de référence Internet Data Center

Résumé

Ce chapitre examine les tendances actuelles du piratage informatique ainsi que les mesures recommandées pour la protection de Microsoft® Internet Data Center. Ce chapitre étudie également le service d'annuaire Active Directory™ ainsi que la structure DNS (Domain Name System), et il examine le modèle de sécurité ainsi que l'utilisation de stratégies de groupe pour gérer la sécurité dans le système d'exploitation Microsoft Windows® 2000. Les méthodes recommandées pour la conception des applications et l'implémentation de la sécurité Microsoft SQL Server™ 2000 sont également étudiées. La dernière section aborde les technologies d'authentification utilisées dans l'environnement Internet Data Center.

Introduction

La sécurité est une préoccupation majeure pour tous les réseaux, mais elle est essentielle pour les réseaux de commerce électronique, qui acheminent des transactions financières et stockent des informations sensibles, constituant ainsi des cibles potentielles pour les attaques en provenance d'Internet. Les failles en matière de sécurité vont des simples intrusions aux infiltrations plus ennuyeuses, en passant par les événements graves, coûteux et très dommageables. La sécurité est un des aspects les plus importants d'une solution de commerce électronique. Sans une sécurité performante, les informations confidentielles des clients, telles que les numéros de cartes bancaires et les adresses personnelles, peuvent être compromises. Les effets d'une faille dans la sécurité peuvent conduire à une perte de confiance des clients et ainsi qu'à des pertes significatives de clientèle.

Les sections suivantes étudient les approches en matière de sécurité, les techniques de piratage, ainsi que les mesures recommandées pour protéger une implémentation Microsoft® Internet Data Center. Il est très important de comprendre que la technologie associée à la sécurité est en perpétuelle évolution, de nouvelles techniques d'attaque et de défense étant en permanence développées. Pour contribuer à faire face à ces problèmes de sécurité, Microsoft a annoncé la création du programme STPP (Strategic Technology Protection Program).

Programme STPP (Strategic Technology Protection Program)

Microsoft est conscient que la sécurisation des réseaux est d'une importance capitale dans le mode d'exercice actuel des activités professionnelles. Quelle que soit leur motivation, les pirates ont pour objectif d'enfreindre la loi et de perturber le cours habituel de la vie des entreprises et des personnes. Le programme STPP fournit des informations, des outils et des services pour contribuer à faire en sorte que les systèmes puissent être sécurisés de façon simple, et que leur sécurité puisse être maintenue avec un minimum de travail et de temps.

Le programme STPP peut être décomposé en deux phases.

Sécuriser

La première phase, qui consiste à sécuriser les systèmes, offre divers outils, services et support destinés à aider les professionnels de l'informatique à sécuriser leurs réseaux. Ces outils et services sont conçus pour offrir un niveau de sécurité élémentaire à un réseau. Les principaux éléments de cette phase sont les suivants :

• Support gratuit concernant les virus : il s'agit d'une hotline qui offre un support gratuit à tout client Microsoft confronté à un problème de virus.

• Boîte à outils de sécurité Microsoft : cette boîte à outils offre les fonctionnalités suivantes :

  • tous les service packs actuels ;

  • tous les correctifs de sécurité essentiels pour les systèmes d'exploitation Microsoft Windows NT® 4.0 et Windows® 2000, pour Microsoft Internet Information Services (IIS) et pour Microsoft Internet Explorer ;

  • un outil de sécurité qui est relié au site Windows Update afin de s'assurer que tous les correctifs actuels ont été installés.

• Outils de sécurité pour l'entreprise : voici quelques exemples de ces outils de sécurité pour l'entreprise :

  • analyseur de configuration de sécurité (vérifie les configurations et correctifs de sécurité) ;

  • outil de déploiement de correctif de sécurité Systems Management Server ;

  • client de mise à jour automatique Windows Update.

Rester sécurisé

Le maintien de la sécurité est la deuxième phase de l'initiative et comprend des outils et des services destinés à maintenir la sécurité des systèmes une fois le niveau élémentaire atteint. Cette phase inclut notamment les composants suivants :

• Correctifs de déploiement de sécurité Windows 2000 : ce composant réunit tous les correctifs de sécurité dans un même correctif bimensuel. Cela signifie qu'un administrateur doit simplement déployer le correctif cumulé le plus récent pour s'assurer de disposer de tous les correctifs à jour pour son système d'exploitation Windows 2000.

• Windows 2000 Service Pack (SP3) : Ce Service Pack permettra l'installation des correctifs de sécurité les plus récents en même temps que les fichiers du Service Pack.

• Programme Windows Update pour les entreprises : ce programme permettra aux entreprises d'héberger et de sélectionner le contenu Windows Update sur des serveurs intermédiaires.

Pour vous assurer d'être à jour sur les développements les plus récents du programme STPP et sur toutes les questions de sécurité relatives à Microsoft, consultez le site Microsoft Security 

À qui s'adresse ce chapitre ?

Ce chapitre contient des instructions à l'intention des professionnels de l'informatique et de la sécurité qui souhaitent savoir comment appréhender, créer et implémenter un modèle de sécurité pour un réseau délimité et pour une architecture DMZ (Demilitarized Zone, également appelée sous-réseau filtré). La stratégie étudiée dans ce chapitre peut être utilisée comme un exemple à partir duquel vous pouvez développer votre propre plan de sécurité.

Questions de conception

La structure Internet Data Center est basée sur les méthodologies connues, expériences et méthodes recommandées en matière de sécurité.

Ressources nécessaires

Pour implémenter totalement le modèle de sécurité Internet Data Center, une connaissance approfondie de Windows 2000, du service d'annuaire Microsoft Active Directory™, de la configuration du Registre et de la conception de stratégies est nécessaire. En outre, il est essentiel que les professionnels de l'informatique qui implémentent la sécurité comprennent parfaitement les technologies et périphériques réseau (tels que les pare-feu, les routeurs, les commutateurs, les protocoles et les ports).

British Standard 7799

La méthodologie utilisée dans l'architecture Internet Data Center est basée sur la norme BS 7799 (British Standard 7799), un code de méthodologie adopté à l'échelon international pour la sécurité de l'information. La norme constitue une approche en quatre phases de l'implémentation d'une solution de système de gestion de la sécurité des informations.

Phases BS 7799

Les quatre phases définies par la norme BS 7799 sont les suivantes :

Phase 1 : Evaluation

Déterminez la structure et les stratégies de sécurité actuelles et définissez les exigences en termes de sécurité des informations, à partir d'un niveau de risque acceptable pour l'activité. Procédez à une analyse des niveaux de sécurité actuels et souhaités. L'architecture Internet Data Center intègre une structure de sécurité recommandée qui doit être utilisée comme point de départ lors du développement d'un modèle de sécurité propre à l'application.

Phase 2 : Conception

Développez une solution de système de gestion de la sécurité des informations à partir de recommandations spécifiques en termes de sécurité et d'un plan détaillé pour l'implémentation de la solution. L'architecture Internet Data Center répond à cette exigence en offrant un guide (ce chapitre) qui explique la structure de sécurité et détaille les étapes impliquées dans la création de cette structure.

Phase 3 : Déploiement

Testez la structure et développez une configuration de production standard. Définissez et documentez les stratégies, les normes et les procédures d'exploitation nécessaires pour un déploiement et une gestion efficaces de la solution. Une fois la solution de l'architecture Internet Data Center développée, elle doit être testée à l'aide des stratégies décrites dans ce chapitre.

Phase 4 : Gestion

La structure de base de l'architecture Internet Data Center peut être développée afin de constituer une plate-forme de gestion complète. Windows 2000, MOM (Microsoft Operations Manager) et NetIQ AppManager sont quelques-uns des composants essentiels de l'architecture de gestion Internet Data Center.

Ces phases représentent la méthodologie globale utilisée pour créer un processus de sécurité pour l'architecture Internet Data Center. Le composant central de toutes les phases de ce modèle est une stratégie de sécurité complète.

Développement d'une stratégie de sécurité informatique

Pour s'assurer que la sécurité est implémentée et maintenue dans une organisation, une stratégie de sécurité doit être développée et appliquée.
La stratégie de sécurité doit inclure les éléments suivants :

• les objectifs généraux de la sécurité ;

• le détail du niveau général de sécurité requis ;

• les normes de sécurité, notamment les stratégies d'audit et de contrôle ;

• la définition des formations et des processus destinés à garantir la sécurité.

La stratégie de sécurité établit les objectifs de sécurité de l'entreprise, décrit le niveau de sécurité que l'organisation souhaite atteindre et définit les normes internes de sécurité ainsi que la façon dont elles seront auditées et contrôlées. Pour qu'une stratégie soit efficace dans une organisation, la direction doit l'approuver.

Pour développer une stratégie de sécurité informatique, les objectifs particuliers de sécurité informatique de l'entreprise doivent d'abord être analysés. Voici quelques exemples d'objectifs de sécurité qui peuvent être utilisés :

• optimiser la fiabilité, la qualité et la confidentialité des informations ;

• s'assurer que la réputation de l'entreprise ne soit jamais mise en péril ;

• maintenir la confidentialité des ressources technologiques, de la propriété intellectuelle et des informations ;

• éviter et prévenir les dommages aux informations, processus et propriétés, et garantir ainsi le bon fonctionnement de l'activité de l'entreprise.

Ces objectifs généraux de sécurité peuvent être appliqués à la plupart des organisations. Les objets de sécurité spécifiques doivent être créés en fonction de la stratégie de l'organisation. Ces objectifs doivent être détaillés dans un document de stratégie de sécurité informatique. La direction doit communiquer sur l'importance de la sécurité auprès de chaque membre de l'organisation. Le document de stratégie doit définir clairement le niveau de sécurité et la façon dont ce niveau sera maintenu.

Un comité de sécurité informatique développe les objectifs de sécurité et définit la façon dont ils seront réalisés. Ce comité est composé de personnes qui comprennent les problèmes de sécurité actuels et leurs conséquences sur l'activité de l'entreprise. Le comité doit être composé de personnes qui peuvent prendre en charge ces problèmes, formuler des exigences de sécurité essentielles pour l'entreprise et développer des plans permettant d'atteindre ces objectifs.

Voici quelques-unes des tâches du comité de sécurité informatique :

• développement, ajustement et création du document de stratégie de sécurité ;

• collaboration avec le directeur de la sécurité de l'entreprise (dont les responsabilités sont détaillées plus loin dans cette section) ;

• création de processus afin de garantir que les objectifs de sécurité informatique soient atteints ;

• génération d'un processus et d'un plan pour implémenter les normes définies dans le document de stratégie de sécurité ;

• promotion de la prise de conscience des problèmes de sécurité ;

• conseils au personnel interne et à la direction de l'entreprise sur tous les problèmes de sécurité ;

• détermination du budget et des ressources nécessaires.

Les membres du comité de sécurité informatique sont des personnes qui ont une expérience des questions de sécurité, une connaissance technique des systèmes informatiques actuels, ainsi qu'une expérience dans les domaines de l'organisation et de la gestion de projet. Pour réussir, le comité doit avoir le soutien sans réserve de la direction. De nombreuses organisations répondent à cette nécessité en créant un poste de directeur de la sécurité de l'entreprise. Le directeur de la sécurité représente le groupe de sécurité informatique, la communauté des utilisateurs et l'entreprise lors de toutes les réunions de la direction. Il s'agit du meilleur moyen de s'assurer que le personnel à tous les niveaux de l'entreprise comprend l'importance de la sécurité informatique.

Définition du rôle de directeur de la sécurité

La responsabilité globale de la sécurité informatique, ainsi que tous les problèmes qui y sont liés, incombent au directeur de la sécurité de l'entreprise. Le directeur de la sécurité doit s'assurer que la sécurité bénéficie du niveau de soutien approprié de la direction et que la stratégie est clairement articulée et comprise à tous les niveaux de l'organisation.

Besoins en termes de personnel

Tous les membres du personnel doivent être conscients qu'on attend d'eux une certaine implication concernant la sécurité. Il est important que le comité de sécurité adopte une approche proactive afin de contribuer à cet effort. De nombreuses attaques sont la conséquence directe d'un manque de formation ou de procédures. Pour aider les utilisateurs dans ces procédures, un programme complet de formation à la sécurité doit être créé et remis à tous les utilisateurs de l'organisation. Pour contribuer à cet effort, le document de stratégie doit contenir des informations sur les points suivants :

• des détails sur les procédures et programmes de formation des utilisateurs ;

• les conséquences et l'impact des procédures de sécurité de l'entreprise ;

• l'importance de la sécurité ;

• le niveau global de sécurité de l'entreprise ;

• les rôles et responsabilités du comité de sécurité informatique ;

• les objectifs et fonctions du directeur de la sécurité de l'entreprise ;

• les procédures de verrouillage des composants individuels de l'architecture, de contrôle et d'alerte, ainsi que de construction de serveurs, de périphériques ou d'applications sécurisés.

Cette section constitue une bonne introduction au processus de création d'une stratégie de sécurité ; cependant, il est nécessaire d'étudier et de comprendre bien d'autres choses. Les références suivantes offrent les détails complémentaires nécessaires pour mener à bien ce processus :

• Center for Security Policy  

• Internet Security Policy : A Technical Guide  

• Information Security Policies Made Easy (Les stratégies de sécurité de l'information), par Charles Wood (Baseline Software; ISBN : 1881585069)

Stratégie de défense approfondie

Cette section décrit la stratégie de défense approfondie utilisée dans l'architecture Internet Data Center pour améliorer la sécurité.

Une des recommandations pour la réduction des menaces et des vulnérabilités, et donc du risque, consiste à s'assurer que le centre Internet Data Center utilise une stratégie de défense approfondie pour la protection des ressources contre les menaces internes et externes. Cela implique le déploiement de solutions de sécurité avancées, telles que les pare-feu, la détection d'intrusion et le cryptage ; cela nécessite également de s'assurer que les contrôles et configurations de l'hôte et des applications sont appropriés.

La figure 1 résume cette stratégie.

Figure 1. Stratégie de défense approfondie

À chaque niveau de l'architecture Internet Data Center, il existe un certain type de contrôle de sécurité. Parmi ces contrôles, citons les pare-feu, les routeurs, la consultation des journaux d'audit, les serveurs multirésidents, les contrôles d'accès appropriés et le cryptage. Chaque niveau créé pour la sécurité agit comme un obstacle pour empêcher l'accès non autorisé. Plus le nombre de niveaux de défense est élevé, plus il est difficile d'accéder sans autorisation aux ressources du réseau. Cette stratégie contribue à garantir la sécurité en offrant des couches de défense redondantes qui protègent les ressources en cas de défaillance d'une couche unique (voire même de plusieurs couches, dans certains cas).

Défenses périmétriques

Tous les aspects de l'architecture Internet Data Center sont définis par des défenses périmétriques, avec un certain type de périphériques sécurisés qui protègent chaque point d'accès du réseau. Grâce à la stratégie de défense approfondie, chaque périphérique a été évalué, les types de trafic autorisés ont été définis et un modèle de sécurité a été développé afin de bloquer tout autre type de trafic. Les principaux points d'accès au système se font via les fournisseurs de services Internet, de sorte que certaines stratégies n'autorisent le trafic que sur les ports 80 et 443. Tout autre trafic est totalement bloqué.
Si des utilisateurs tentent de pénétrer dans le réseau via Internet, seuls ces ports peuvent être utilisés. Les périphériques périmétriques empêchent toute tentative d'analyse des ports intérieurs ou extérieurs, d'utilisation du protocole ICMP (Internet Control Message Protocol) ou le trafic TTL (Time to Live) pour observer l'intérieur du réseau, de lancer une attaque de déni de service (DoS, Denial of Service), d'attaquer le serveur DNS (Domain Name System), de se connecter au serveur à l'aide de commandes NetBIOS, etc.
Si quelqu'un tente de modifier la configuration de sécurité à partir de l'intérieur ou de l'extérieur du système, ce dernier détecte la tentative et alerte l'administrateur.

Défenses réseau

La stratégie de défense approfondie insiste sur le fait qu'un bon modèle de sécurité est basé sur une série de barrières de sécurité. La ligne de défense suivante, après les périphériques périmétriques, est le réseau lui-même. La figure 2 illustre ces périphériques ainsi que la configuration réseau dans le centre Internet Data Center.

Figure 2 : Vue d'ensemble de l'architecture Internet Data Center

Remarque : Dans l'architecture Internet Data Center, toutes les connexions réseau sont totalement redondantes ; cependant, ce schéma ne montre pas ce niveau de détail dans la mesure où il s'agit d'une vue d'ensemble.

Pour cette architecture, chaque réseau a été évalué de façon individuelle et une stratégie a été créée qui détaille le type de trafic qui est absolument nécessaire sur ce réseau. Tout autre trafic est bloqué par un pare-feu, contrôlé par un commutateur ou désactivé.

Le tableau suivant illustre le trafic autorisé sur chaque segment.

Réseau VLAN

Trafic autorisé

Exceptions

21

Seuls les ports prenant en charge le trafic DNS sont autorisés via le pare-feu ; tous les autres ports sont désactivés.

Aucun

22 et 23

Seul le port 80. Tout autre trafic est désactivé sur la carte exposée à Internet (y compris NetBIOS sur TCP/IP). La procédure pour cela est détaillée dans la section "Sécurisation du réseau", plus loin dans ce chapitre.

Aucun

11

Carte réseau dorsale sur les serveurs Web multirésidents et les serveurs DNS externes. Le trafic NetBIOS est autorisé entre les ordinateurs de ce réseau en raison d'une exigence du système de gestion. Le trafic d'ouverture de session Kerberos est également autorisé à passer par le pare-feu. L'inspection complète et les listes de contrôle d'accès sont activées sur le pare-feu afin de garantir que seuls les serveurs autorisés communiquent entre eux.

Le trafic NetBIOS n'est pas autorisé à passer jusqu'aux réseaux d'infrastructure ou de données. Le pare-feu interne bloque ces ports.

15

Carte réseau dorsale du pare-feu vers les réseaux VLAN intérieurs. Le trafic Kerberos ainsi que le trafic valide des applications et des composants est autorisé à passer entre les réseaux d'infrastructure et de données, via le pare-feu.

Aucun

13

Le réseau de l'infrastructure qui contient tous les serveurs Active Directory et les serveurs DNS internes. Tout le trafic NetBIOS est autorisé dans ce segment, afin de garantir la prise en charge des applications de gestion.

Aucun

12

Le réseau de données, de gestion et VPN. Le trafic NetBIOS passe du réseau VLAN 12 à 13 via le commutateur. À titre de mesure de sécurité supplémentaire, les listes de contrôle d'accès VLAN peuvent être utilisées pour contrôler le trafic entre ces deux segments. Comme dans le cas du trafic vers le réseau VLAN de l'infrastructure, le trafic à destination du réseau VLAN DMZ est traité à l'aide de stratégies de pare-feu.

La solution de gestion utilise les services Terminal Server pour l'accès à distance aux serveurs Web. Cela nécessite que le protocole RDP (Remote Desktop Protocol) utilise le port 3389 pour communiquer avec les serveurs de la zone DMZ pour l'accès des services Terminal Server.

14

Utilisé uniquement pour la connexion des cartes de gestion des serveurs. Certains fabricants de serveurs proposent des cartes de gestion à distance pour la gestion hors bande des serveurs. Ce réseau VLAN permet l'accès à ces cartes.

Ce réseau VLAN n'est accessible que via le serveur Tools, qui possède une carte réseau dédiée pour la gestion des serveurs sur VLAN14.

Défenses des hôtes

Grâce à la stratégie de défense approfondie, chaque hôte de l'environnement Internet Data Center a été évalué et des stratégies individuelles ont été créées afin de limiter chaque serveur aux seules tâches nécessaires. Cela permet de créer une barrière de sécurité supplémentaire qu'un éventuel pirate devra franchir avant de pouvoir causer des dommages. Les stratégies individuelles ont été créées en fonction de la classification et du type de données contenues sur chaque serveur. La stratégie de l'entreprise stipule que tous les serveurs Web sont destinés à une utilisation publique et qu'ils ne peuvent donc contenir que des informations publiques. Les serveurs de base de données sont désignés comme confidentiels dans l'entreprise, ce qui signifie que ces informations doivent être protégées coûte que coûte. Tous les serveurs sont exposés à un niveau TCP/IP, de sorte qu'il existe une normalisation dans le verrouillage du protocole. À l'aide de Active Directory et d'unités d'organisation, des stratégies individuelles ont été créées pour chaque type de serveur et ont été appliquées aux unités d'organisation appropriées. Les détails complets de ce processus sont étudiés plus loin dans ce chapitre. Les serveurs sont classés de la façon suivante :

Valeur

Définition

Utilisation publique

La distribution de ces informations n'est pas limitée. Il s'agit notamment des informations marketing, des documents commerciaux et des informations destinées au public. Les données des serveurs Internet publics ne doivent être destinées qu'à une utilisation publique.

Usage interne uniquement

La divulgation de ces informations est autorisée en interne, mais peut occasionner des dommages à l'organisation si elles sont publiées.
Au moins un pare-feu doit être placé entre ces informations et Internet.

Confidentiel

La divulgation de ce type d'information causerait des dommages sérieux à l'ensemble de l'organisation. Ces informations sont très sensibles et ne doivent être consultées qu'en cas de besoin. Au moins deux pare-feu doivent être placés entre ces informations et Internet.

Défense des applications

Le renforcement des applications est un élément essentiel de n'importe quel modèle de sécurité et qui constitue un niveau de défense supplémentaire. La sécurisation du système d'exploitation offre le premier niveau de protection. Il est de la responsabilité du développeur d'incorporer la sécurité dans l'application afin d'offrir un niveau supplémentaire de protection aux zones de l'architecture auxquelles cette application a accès. Une application existe dans le contexte du système. Il est donc impossible d'envisager la sécurité des applications sans étudier celle de l'ensemble du système. L'architecture Internet Data Center a été conçue pour prendre en charge un large éventail de types d'applications. Chaque application nécessite son propre modèle de sécurité, mais il est nécessaire de suivre quelques règles standard lors du cycle de développement. Pour en savoir plus sur l'intégration d'une structure de sécurité dans l'architecture d'une application, consultez la section "Méthodes recommandées pour la sécurité des applications", plus loin dans ce chapitre.

Données et ressources

Toutes les applications et tous les services de chaque serveur sont évalués afin de déterminer leur importance ; ceux qui ne sont pas indispensables sont retirés. Les autres types de ressources, notamment les données, sont sécurisés à l'aide de stratégies et sont audités à l'aide d'une console de gestion centralisée. Les recommandations de sécurité pour le contrôle de l'accès aux bases de données, aux fichiers et au Registre SQL Server™, ainsi que pour le maintien de droits d'accès appropriés à la base de données, sont détaillées dans les sections "Modèle de sécurité Windows 2000 et stratégies Active Directory" et "Méthodes recommandées pour la sécurité SQL Server 2000", plus loin dans ce chapitre.

Méthodes courantes des pirates et mesures de prévention

Une composante essentielle de la stratégie de défense approfondie de Internet Data Center est de comprendre les méthodes utilisées par les pirates et d'inclure dans la stratégie de sécurité les défenses permettant d'éviter les attaques les plus courantes. Cette section détaille les tendances générales du piratage informatique ainsi que les mesures recommandées pour la protection de l'environnement Internet Data Center. Les sujets abordés sont les suivants :

• la protection de l'architecture contre les techniques de reconnaissance standard ;

• la limitation des possibilités d'analyse et d'obtention d'informations ;

• les techniques utilisées pour accéder aux informations et accroître les privilèges ;

• la limitation des attaques de déni de service (DoS, Denial of Service) ;

• la prévention des attaques déguisées ;

• la compréhension de la façon dont les pirates effacent leurs traces.

Protection de l'architecture contre les techniques de reconnaissance

Lors de la construction du réseau périmétrique, tous les moyens simples de pénétrer sans autorisation dans le réseau doivent être supprimés. Voici quelques-unes des techniques permettant d'y parvenir :

• S'assurer que seuls des périphériques spécifiques et identifiés du réseau permettent la connexion par accès à distance. Un utilitaire de balayage de modem examine tous les préfixes de l'entreprise, afin de rechercher les périphériques non autorisés. Les périphériques d'accès distant peuvent également être détectés via l'activation de la détection d'analyse dans le PBX, lorsque cela est possible.

• Désactiver NetBIOS sur TCP/IP, y compris le port 445, sur les ordinateurs qui se connectent directement à Internet par l'intermédiaire du pare-feu extérieur. Cela rend impossible l'utilisation depuis l'extérieur des fonctionnalités réseau Microsoft standard pour se connecter aux serveurs.

• Activer uniquement les ports 80 et 443 à la fois sur les cartes réseau exposées à Internet et sur le pare-feu pour le trafic destiné à un groupe de serveurs Web. Cela permet d'interdire la plupart des techniques de reconnaissance basées sur les ports.

• Vérifier les informations du site Web public, afin de s'assurer que :

  • les adresses de messagerie utilisées sur le site ne sont pas des comptes administratifs ;

  • la technologie du réseau n'est pas spécifiée ;

  • les informations générales publiées sur l'entreprise sont appropriées et ne peuvent pas être utilisées pour découvrir ou déduire les caractéristiques du système de sécurité. Ce type d'information inclut les événements actuels et ceux qui ont eu lieu récemment. Par exemple, si le site Web annonce que votre entreprise vient juste d'acquérir une autre entreprise, les pirates peuvent tenter de s'attaquer à cette dernière, dans l'espoir que son réseau a été relié à la hâte au réseau de votre entreprise et qu'il n'est pas encore suffisamment sécurisé.

  • Consulter les informations publiées par les employés sur les groupes Usenet afin d'évaluer le type d'informations qu'ils envoient.

  • Gérer le type d'informations insérées dans le code source du site Web afin d'éviter qu'un pirate ne consulte ce code pour obtenir des informations intéressantes (technique parfois appelée "passage au crible du code source"). Parmi les éléments du code source qui doivent être analysés par l'équipe de sécurité, citons les commentaires inappropriés, les mots de passe intégrés et les balises cachées.

  • Consulter le registre ARIN (American Registry for Internet Numbers  ) afin de déterminer le type d'informations à disposition du public.

  • S'assurer qu'un pirate ne peut pas interroger le serveur DNS du réseau de référence ou effectuer un transfert complet de zone. En extrayant tous les enregistrements du serveur DNS, un pirate peut se faire une bonne idée des ordinateurs qui constituent les meilleures cibles. Pour empêcher l'interrogation DNS, vous pouvez attribuer des droits au serveur DNS Windows 2000 à l'aide de l'option Notify et autoriser les transferts de zone uniquement vers les serveurs autorisés. Une autre approche consiste à implémenter un serveur DNS en lecture seule et à mettre en place des stratégies et des procédures pour sa mise à jour.

  • Consulter le manuel de sécurité du site (Site Security Handbook, RFC 2196) afin de prendre connaissance des points importants à prendre en considération lors du développement d'une stratégie. Une entreprise qui traite avec le public doit rendre publiques certaines informations, notamment sur son architecture réseau. Il est essentiel de ne fournir que les informations indispensables, et non des informations qui peuvent être utilisées à des fins malhonnêtes.

  • Gérer le type d'informations fournies aux individus qui tentent d'analyser le réseau à l'aide d'utilitaires tels que traceroute et tracert. Ces utilitaires, qui utilisent le paramètre TTL, sont utilisés pour suivre le chemin emprunté par un paquet IP d'un hôte à l'autre ; les résultats peuvent ensuite être utilisés pour dessiner une image du réseau. L'architecture Internet Data Center est conçue pour empêcher ces types d'analyses grâce à la détection d'intrusion et au filtrage de protocole et de paquet.

Limitation des possibilités d'analyse et d'obtention d'informations

La boîte à outils d'un pirate comporte toujours un analyseur de ports. À la fois les protocoles TCP (Transmission Control Protocol) et UDP (User Datagram Protocol) utilisent des ports pour communiquer (65 535 ports pour TCP et UDP, détaillés dans le document RFC 1700). En analysant un port, un pirate peut découvrir les parties de l'architecture Internet Data Center qui écoutent, puis utiliser ces informations pour élaborer des méthodes d'accès au réseau.

Négociation à trois voies

Les attaques utilisant des analyseurs de port sont devenues de plus en plus sophistiquées afin d'éviter d'être découvertes par les systèmes de détection d'intrusion. Elles exploitent la négociation TCP/IP à trois voies, comme illustré figure 3, afin de contourner le système de détection d'intrusion et de découvrir les ports disponibles, ainsi que le type de technologie utilisée, dans le réseau périmétrique.

Figure 3 : Négociation à trois voies

Les analyses qui utilisent la négociation à trois voies sont facilement détectées, car l'ensemble de la négociation est effectué pour chaque port lors de l'analyse. Cependant, il existe certaines analyses furtives conçues spécialement pour neutraliser un système de détection d'intrusion. Exemple :

• Les analyses SYN (également appelées analyses demi-ouvertes) utilisent uniquement le SYN initial pour récupérer les informations sur le port. Celles-ci peuvent être difficiles à détecter.

• Les analyses ACK peuvent être utilisées pour envoyer des paquets dans le réseau afin de contourner les simples pare-feu à base de routeur, qui n'utilisent pas l'inspection complète.

• Les analyses UDP peuvent être utilisées pour localiser les services UDP vulnérables.

Empreinte TCP

L'empreinte TCP est une méthode par laquelle un pirate utilise un outil d'analyse pour envoyer différentes sondes ou différents types de paquets aux ports, afin de déterminer leur réponse. En fonction de la réponse, l'outil d'analyse tente d'identifier la plate-forme visée.

Supposez qu'un pirate utilise un outil d'analyse pour envoyer des paquets inappropriés vers un port ouvert. Parmi les méthodes utilisées pour cela, citons la définition d'indicateurs TCP non identifiés dans l'en-tête ou l'envoi de paquets fragmentés. En fonction de la réponse, l'outil d'analyse peut généralement identifier le type de technologie qui se trouve derrière le routeur. Ainsi, si par exemple la cible est identifiée comme étant un serveur Microsoft Windows NT®, le pirate peut commencer à rechercher les vulnérabilités connues de Windows NT.

Protection du réseau contre l'analyse

L'approche suivante a été utilisée pour protéger l'architecture Internet Data Center contre l'analyse :

• Seuls les ports 80 et 443 sont ouverts. Toute autre exigence concernant les ports est strictement contrôlée par une stratégie ; tous les membres du comité de sécurité doivent être d'accord avant d'ouvrir tout autre port.

• Un système de détection d'intrusion réseau est implémenté.

• Tous les services qui ne sont pas indispensables sont arrêtés. Les détails des services arrêtés sont répertoriés dans des modèles de sécurité appropriés.

• Tous les correctifs système actuels sont appliqués.

Remarque : La vérification et l'installation régulières des derniers correctifs de sécurité sont essentielles dans la prévention des menaces contre la sécurité. Le programme STPP (Strategic Technology Protection Program) décrit précédemment dans ce chapitre contribuera à cet effort. Pour plus d'informations, consultez le site suivant : www.microsoft.com/security

Analyse via le pare-feu

Les pirates tentent de déterminer quels ports sont ouverts via le pare-feu. Les outils classiques d'analyse des ports identifient les ports qui écoutent sur l'ordinateur cible. Cependant, une analyse de pare-feu tente de déterminer les ports qui sont activés par des règles internes de filtrage de paquets dans le réseau périmétrique, plutôt que ceux qui sont actuellement ouverts. Si un port, comme par exemple un port Telnet, est identifié, le pirate peut attendre qu'il soit activé, puis tenter d'en prendre le contrôle. Les outils qui effectuent ce type d'analyse utilisent le paramètre TTL pour procéder à une analyse des ports. Le paramètre TTL est défini sur un nombre qui est supérieur de un au nombre de segments du périphérique de filtrage de paquets. Si un message est renvoyé indiquant un dépassement TTL, cela signifie que ce port est ouvert via le pare-feu. Si aucun message n'est renvoyé, cela signifie que le pare-feu filtre le port.

Dans l'architecture Internet Data Center, les défenses qui ont été envisagées contre ce type d'attaque sont les suivantes :

• La désactivation des messages de dépassement TTL ICMP ; cependant, cette méthode peut provoquer des problèmes avec certains outils réseau et peut affecter les clients légitimes.

• L'utilisation de serveurs proxy au niveau du pare-feu, plutôt que des filtres de paquets. Contrairement aux filtres de paquets, les serveurs proxy ne transfèrent pas les paquets lorsque le filtrage IP est activé. Cela permet de contrer efficacement les attaques, car les paquets TTL ICMP ne sont pas transmis avec les autres paquets.

Détection de bannière

La détection de bannière est une technique d'analyse dans laquelle un port ouvert est utilisé pour contacter et identifier un système d'exploitation. La méthode la plus courante consiste à se connecter à un port, à appuyer plusieurs fois sur ENTRÉE et à voir quel type d'informations est renvoyé.

Une autre méthode consiste à extraire le contenu du Registre afin de voir quelles applications s'exécutent sur le réseau. Pour l'architecture Internet Data Center, les modifications suivantes ont été apportées afin d'assurer la protection contre la détection de bannière :

• Tous les ports ont été vérifiés, à l'aide de Telnet et d'autres outils de piratage, afin de déterminer le type et la quantité des informations fournies. Une stratégie d'audit a été mise en place afin de vérifier en permanence cette sécurisation.

• Seuls les administrateurs ont accès à distance au Registre. Des outils tiers, tels que Dumpreg de Systemtools, sont utilisés pour vérifier et contrôler la compatibilité.

Techniques utilisées pour accéder aux informations et accroître les privilèges

Les pirates tentent d'utiliser de nombreuses méthodes pour accéder à un système et accroître leurs privilèges. L'architecture Internet Data Center inclut un modèle de sécurité élémentaire conçu pour empêcher la réussite de ces attaques. Les points essentiels à prendre en considération sont les suivants :

• empêcher le détournement de session ;

• empêcher la corruption DNS ;

• empêcher l'usurpation d'adresse IP ;

• protéger le fichier de mot de passe ;

• empêcher les débordements de tampon.

Empêcher le détournement de session

Les outils de détournement de session permettent aux pirates d'interrompre, de terminer ou de subtiliser une session en cours. Ces types d'attaques tendent à se concentrer sur les applications à base de session. De nombreux outils de détournement de session peuvent afficher plusieurs sessions simultanément. La meilleure solution pour protéger l'architecture contre le détournement de session consiste à utiliser le cryptage. Voici quelques-unes des méthodes utilisées dans l'architecture Internet Data Center :

• utilisation de IPSec, de stratégies de sécurité et du protocole SSL (Secure Sockets Layer) pour crypter le trafic chaque fois que cela est possible ;

• implémentation d'un protocole sécurisé pour gérer l'infrastructure. Par exemple, un shell sécurisé est utilisé pour se connecter au pare-feu plutôt que Telnet pour la configuration.

Empêcher la corruption DNS

Les éléments les plus importants à protéger dans l'architecture sont les serveurs DNS. Tous les clients réseau interrogent les serveurs DNS pour localiser les serveurs avec lesquels ils doivent communiquer. Lors de l'attaque du serveur DNS, un pirate peut utiliser la méthode de corruption DNS. Il peut par exemple utiliser différentes techniques de pénétration pour remplir le fichier de cache du serveur DNS avec des informations malveillantes. Ainsi, lorsqu'un utilisateur interroge le serveur DNS de production, il est redirigé vers un serveur DNS fantôme que le pirate contrôle et qu'il peut utiliser pour endommager le système. Les approches suivantes peuvent être utilisées pour empêcher les attaques sur le serveur DNS :

• Utiliser différents serveurs DNS pour résoudre les requêtes du réseau interne et s'assurer que ces serveurs DNS ne répondent pas aux requêtes des ordinateurs externes. Ce mécanisme est appelé DNS partagé.

• Utiliser un serveur DNS en lecture seule qui empêche toute mise à jour.

• Sécuriser la base de données DNS. L'architecture Internet Data Center utilise la sécurité Active Directory et seules les mises à jour DNS sécurisées sont autorisées.

• Lors de l'utilisation de Microsoft DNS, activer la protection contre la corruption DNS dans les paramètres avancés de configuration de Microsoft DNS.

Attaques par chaîne URL

Les pirates commencent maintenant à concentrer leurs efforts sur les attaques qui traversent le port 80. Un exemple de ce type d'attaque consiste à créer une chaîne URL qui utilise une version codée UTF-8 des barres obliques ou des barres obliques inverses (\ ou /) ; par exemple, la chaîne %c0%af. Ce type d'attaque permet à un pirate de traverser la structure des répertoires des systèmes distants, d'obtenir des informations intéressantes sur le serveur ou sur le réseau, voire même d'exécuter un programme à distance.

Par exemple, le virus Nimda utilise une chaîne URL codée UTF pour lancer une session TFTP sur le serveur distant et télécharger son code malveillant sur l'ordinateur infecté. Le ver installe ensuite son propre serveur TFTP, télécharge le reste du code, puis commence à se répliquer de différentes façons, comme par exemple par l'envoi de courrier électronique en nombre, l'incorporation d'un fichier .eml dans un site Web ou l'attaque de partages réseau ouverts.

Protection des systèmes contre les attaques par chaîne URL

La première mesure d'une stratégie de défense approfondie contre une attaque par chaîne URL consiste à en apprendre le plus possible sur le virus et à vous assurer que vous êtes à jour des différents correctifs de sécurité. Une attaque de virus Nimda échouera si les correctifs appropriés ont été installés sur les ordinateurs attaqués. Ces correctifs prennent deux formes différentes : le correctif Outlook sur les ordinateurs des utilisateurs et les correctifs contre les attaques de codage URL sur les serveurs IIS.

La page Information sur le ver "Nimda" fournit des informations sur la façon de mettre à jour votre système et inclut également des liens vers des sites tiers contenant des détails techniques complets sur le virus Nimda.

La structure de l'architecture Internet Data Center détaillée aurait également empêché la réussite d'une attaque du ver Nimda, et ce pour les raisons suivantes :

• Le pare-feu ISA périmétrique ne permet pas aux serveurs IIS d'initier une demande TFTP sortante vers Internet. C'est de cette façon que le ver Nimda peut installer des logiciels sur les serveurs IIS.

• La stratégie de filtrage IPSec sur IIS Server ne permet pas aux serveurs IIS d'initier une requête TFTP sur leurs interfaces exposées à Internet ; seul le trafic HTTP est autorisé et les autres ports sont désactivés.

• Le pirate ne peut pas exécuter la commande TFTP, car ce fichier exécutable comporte une liste de contrôle d'accès qui ne permet son exécution que par
  les administrateurs.

• Les correctifs appropriés auraient été appliqués au groupe de serveurs IIS et le pirate n'aurait pas pu exécuter l'attaque de codage URL contre les serveurs IIS.

Maintenir les correctifs à jour sur les serveurs Web n'est pas forcément évident ; c'est pourquoi Microsoft facilite le processus. L'équipe produit IIS a créé plusieurs outils qui facilitent l'installation des correctifs par les clients et qui les informent dès que de nouveaux correctifs sont disponibles :

• QChain.exe permet aux clients d'installer plusieurs correctifs avec un seul redémarrage. Cet outil se trouve à la page No-Reboot Patches for Windows 2000 

• Tous les bulletins de sécurité IIS publiés après MS01-026 sont cumulatifs, ce qui veut dire que l'installation du dernier correctif permet aux clients de bénéficier de tous les correctifs IIS 5 en une seule installation. Cette fonctionnalité est également disponible pour les correctifs IIS 4. Les bulletins de sécurité sont publiés sur la page Sécurité de TechNet.

• L'outil de vérification des correctifs peut vous aider à rester à jour. Il examine le serveur IIS par rapport à la liste des correctifs publiés par Microsoft et génère un rapport dans le journal des événements de l'application, avec la liste des correctifs qui doivent être appliqués.

• Les clients peuvent recevoir automatiquement les futurs bulletins de sécurité en s'abonnant au service de notification de sécurité Microsoft. Pour vous abonner, rendez-vous sur la page Product Security Notification 

• L'outil de verrouillage IIS facilite le processus visant à sécuriser IIS. L'outil verrouille les serveurs Web aussi étroitement que possible, sans désactiver les fonctionnalités essentielles de IIS. Vous pouvez télécharger l'outil de verrouillage IIS depuis la page IIS Lockdown Tool 

Pour prendre connaissance des informations les plus récentes sur la sécurité, consultez le site Microsoft Security  ou la rubrique Sécuritéde TechNet.

Remarque : Il est essentiel de tester de façon approfondie ces outils avant d'apporter toute modification aux systèmes de production.

Empêcher l'usurpation d'adresse IP

Un autre type d'attaque à éviter est l'attaque de l'intermédiaire. Ces attaques permettent à un pirate de prendre le contrôle d'une session TCP/IP existante. L'usurpation d'adresse IP est une technique courante pour prendre le contrôle d'une session. Par exemple, comme le montre la figure 4, supposez que Julien soit un pirate et que Pierre et Paul soient des utilisateurs valides. Pour usurper une identité, Julien procède de la façon suivante :

1. Julien se connecte à l'ordinateur de Pierre via un port ouvert afin de visualiser les numéros ISN (Initial Sequence Numbers) de cet ordinateur et d'analyser la façon dont ils sont modifiés.

2. Grâce aux informations ISN, Julien effectue une attaque DoS contre Pierre afin de fermer la session de Pierre.

3. Julien envoie ensuite un message à Paul à l'aide de l'adresse de Pierre.

4. Paul répond à Pierre avec la deuxième partie de la négociation à trois voies.

5. Julien simule Pierre en envoyant la dernière partie de la négociation à trois voies, c'est-à-dire l'accusé de réception (ACK, Acknowledgement) et les ISN incrémentés découverts précédemment.

Figure 4 : Usurpation d'adresse IP

Une fois cette procédure terminée, Julien dispose d'une connexion ouverte avec l'ordinateur de Paul et peut commencer à envoyer des commandes. Julien peut désormais tenter de reconfigurer l'ordinateur de Paul afin que toutes les réponses soient envoyées à lui et non à Pierre.

Méthodes de prévention

Tous les types d'attaques d'usurpation constituent une menace grave et peuvent être évités par les méthodes suivantes :

• utiliser une authentification et un cryptage puissants chaque fois que cela
  est possible ;

• s'assurer que les numéros ISN sont réellement aléatoires et donc très difficiles à prévoir ;

• ne pas étendre les relations d'approbation au-delà du pare-feu ;

• désactiver le routage de source IP et utiliser des filtres anti-usurpation au niveau des routeurs et des pare-feu ;

• ne pas autoriser le routage des paquets source via les passerelles réseau.

Protéger le fichier de mot de passe

La gestion du fichier de mot de passe est également une étape importante dans la prévention des attaques. Voici quelques-unes des méthodes de protection du fichier de mot de passe contre les attaques de pirates :

• Placer les contrôleurs de domaine en mode natif. Cela permet d'éviter que des pirates ne tentent de se connecter au répertoire de réparation et de télécharger le fichier SAM (Security Accounts Manager).

• Pour les serveurs membres, protéger le fichier de mot de passe en imposant des droits pour les fichiers, les répertoires et les sauvegardes.

• Désactiver l'authentification LAN Manager par l'intermédiaire d'une stratégie et utiliser d'autres formes d'authentification (comme par exemple les certificats et la biométrie).

• Établir et imposer une stratégie de mot de passe qui :

  • nécessite le changement des mots de passe tous les 42 jours ;

  • impose des mots de passe comportant au moins huit caractères, avec au moins une lettre, un chiffre et un caractère spécial ;

  • verrouille les utilisateurs après cinq tentatives infructueuses d'ouverture de session.

Empêcher les débordements de tampon

Les débordements de tampon sont une technique très dangereuse utilisée par les pirates pour accéder à un système. Les pirates tentent de placer trop d'informations dans un conteneur afin de voir s'ils peuvent tirer parti du débordement. Par exemple, si le programme attaqué ne procède pas aux vérifications de limite appropriées, il déborde et permet au pirate d'exécuter les fonctions de son choix. Souvent, ces débordements sont provoqués sur des comptes système locaux disposant de droits complets.

Attaques de débordement de tampon basées sur la pile

De nombreuses attaques de débordement sont très bien documentées et peuvent être téléchargées facilement via le Web. Les types d'attaques les plus courants sont les attaques de débordement de tampon basées sur la pile. Le débordement écrase toute la pile, y compris les pointeurs. Le pirate en tire parti en optimisant la quantité de données placées dans le débordement. Il envoie ensuite du code propre à l'ordinateur afin d'exécuter une commande, ainsi qu'une nouvelle adresse pour le pointeur de retour. Enfin, le pirate utilise l'adresse, qui pointe de nouveau vers la pile, afin d'exécuter les instructions de son programme lorsque le système revient à la pile.

Éviter les débordements de tampon

Pour éviter les attaques de débordement de tampon, il est nécessaire de prendre les mesures suivantes :

• Les systèmes doivent être tenus à jour avec les derniers service packs et correctifs.

• De bonnes méthodes de codage doivent être implémentées et des règles standard de vérification de limite doivent être observées. Il existe de nombreuses ressources sur le sujet ; par exemple, Designing Secure Web-Based Applications for Microsoft Windows 2000 (Conception d'applications Web sécurisées pour Microsoft Windows 2000) parMichael Howard (Microsoft Press ; ISBN : 0735609950).

Limitation des attaques de déni de service

Les attaques de déni de service (DoS, Denial of service) et de déni de service distribué (DDoS, Distributed Denial of Service) sont le type d'attaque le plus courant sur Internet aujourd'hui. Chaque semaine, de nouvelles attaques DoS sont documentées et ajoutées aux bases de données de suivi des bogues.

Parmi les attaques DoS et DDoS les plus récentes, citons les actions suivantes :

• Utiliser la commande ping standard pour envoyer un paquet volumineux vers l'ordinateur d'une victime. Cette action peut provoquer le blocage ou le plantage de l'ordinateur.

• Ouvrir un grand nombre de connexions TCP/IP semi-ouvertes. Le serveur répond à ces requêtes SYN en stockant un petit élément d'état dans la file d'attente de connexion. Après une très courte période, la file d'attente de connexion est pleine et la bande passante du serveur est totalement utilisée, ce qui fait que le serveur ne répond plus.

• Distribuer l'attaque DDoS sur un ensemble d'ordinateurs (appelés zombis) précédemment compromis et qui saturent le réseau lorsque cela leur est demandé. Ces zombis submergent alors rapidement le serveur cible avec des paquets réseau inutiles.

Le danger réel d'une attaque DDoS est que le pirate utilise de nombreux ordinateurs victimes comme ordinateurs hôtes pour contrôler d'autres zombis qui engagent l'attaque. Lorsque le système submergé tente de pister l'origine de l'attaque, il reçoit un ensemble d'adresses usurpées générées par des zombis.

Nous pourrions évoquer de nombreux autres types d'attaques, mais il est plus important d'étudier les types de défenses qui peuvent être mis en place pour éviter ces types d'attaques. Voici quelques mesures de protection que vous pouvez prendre pour empêcher ces attaques :

• Maintenir les systèmes à jour avec les derniers correctifs de sécurité.

• Bloquer les paquets ping volumineux au niveau du routeur et du pare-feu, en les empêchant ainsi d'atteindre le réseau périmétrique.

• Appliquer des filtres anti-usurpation sur le routeur, ce qui revient à bloquer les paquets entrants dont l'adresse source est identique à une adresse du réseau interne.

• Filtrer les messages ICMP sur le pare-feu et le routeur (bien que cela puisse affecter certains outils de gestion).

• Développer un plan de défense avec votre fournisseur de services Internet, afin de répondre rapidement à une attaque visant la bande passante entre votre fournisseur et votre réseau périmétrique.

• Désactiver la réponse aux diffusions directes.

• Appliquer un filtrage approprié au niveau du routeur et du pare-feu.

• Utiliser le système IDS pour détecter le trafic inhabituel et générer une alerte en cas de détection. Configurer IDS pour générer une alerte s'il détecte ICMP_ECHOREPLY sans les paquets ICMP_ECHO associés.

Prévention des attaques déguisées

Le développement d'un plan de sécurité efficace nécessite de comprendre comment les pirates accèdent aux systèmes, puis de modifier leurs privilèges d'accès ou de sécurité. Pour empêcher les pirates de télécharger des informations sur le système, vous devez vous protéger contre l'utilisation d'un cheval de Troie pour installer un mécanisme déguisé sur le système. Cela pose généralement plus de problèmes sur le client que sur un serveur totalement sécurisé. Cependant, un pirate peut utiliser un tel mécanisme pour attaquer un utilisateur ou le poste de travail d'un administrateur, puis utiliser ce système pour lancer des attaques sur un réseau périmétrique de production.

Par exemple, Back Orifice 2000 est un programme déguisé qui permet aux pirates de prendre à distance le contrôle d'un ordinateur sur le réseau, de capturer les saisies au clavier et d'utiliser ces informations pour devenir un utilisateur d'un poste de travail du réseau. De nombreux logiciels antivirus détectent Back Orifice ; cependant, de nouvelles versions de Back Orifice créent des mutations différentes qui ne sont pas détectées. Ce programme s'exécute également en mode furtif et ne s'affiche pas dans la liste des tâches, dans la mesure où la taille de son empreinte est inférieure à 100 kilo-octets (ko). Il prend en charge les plug-ins afin d'accroître ses fonctionnalités. Back Orifice n'est qu'un des très nombreux programmes déguisés. Voici quelques-uns des moyens d'empêcher ces types d'attaques :

• Exécuter une analyse antivirus complète et maintenir l'outil antivirus à jour avec les signatures les plus récentes.

• Être prudent avec toute information envoyée par courrier électronique et limiter l'exécution des pièces jointes inconnues.

• Exécuter des outils, tels que l'analyseur ISS (Internet Security Systems), pour analyser l'ensemble du réseau afin de détecter la présence d'outils de piratage, tels que Back Orifice, en s'assurant auparavant que la base de données de l'analyseur est à jour.

• Accepter uniquement les contrôles Microsoft ActiveX® signés.

• Informer les utilisateurs des dangers liés à l'installation de programmes inconnus, au lancement de pièces jointes douteuses ou au téléchargement d'informations non signées ou inconnues via Internet.

Comment les pirates tentent d'effacer leurs traces

Windows 2000 conserve ses fichiers journaux dans un répertoire appelé %SYSTEMROOT%\System32\Config. Les journaux ne sont pas lisibles directement, mais ils peuvent être manipulés. En général, les pirates visent le fichier Secevent.evt, mais ils tentent parfois de supprimer tous les fichiers afin d'effacer leurs traces.

Un pirate plus expérimenté tentera soit d'effacer le journal, soit d'interrompre totalement le processus d'audit. L'audit est activé par la stratégie de sécurité locale ou par l'outil stratégie de groupe. Un des moyens de désactiver l'audit consiste à obtenir les privilèges appropriés, à lancer la configuration d'audit dans la stratégie système à l'aide de la console MMC (Microsoft Management Console), puis à désactiver l'audit. Une autre approche consiste à exécuter l'utilitaire auditpol, inclus dans le Kit de ressources de Microsoft Windows NT. Les défenses visant à empêcher ce type d'activité consistent notamment à s'assurer que seuls les administrateurs puissent configurer l'audit, à appliquer les autorisations appropriées au répertoire config, et à utiliser la solution de gestion pour centraliser, crypter et envoyer des alertes si les journaux sont trafiqués.

Sécurisation de IIS

Cette section étudie les problèmes de sécurité propres au service de serveur Web Microsoft Internet Information Services (IIS) 5.0, tel qu'il est utilisé dans l'architecture Internet Data Center.Les principaux aspects à prendre en considération sont la gestion des fichiers et des répertoires, la définition des autorisations, les options de configuration relatives à l'accès réseau à l'ordinateur IIS, la désactivation et la suppression des composants et répertoires non indispensables, ainsi que l'application des correctifs.

Remarque : Nombre des étapes manuelles détaillées dans cette section sont désormais automatisées grâce à l'outil de verrouillage IIS.

Autorisations, fichiers et répertoires

Cette section explique comment la sécurité du système de fichiers et de la structure des répertoires des serveurs Web doit être configurée afin de réduire les risques pour le système global.

Autorisations

Il est important de déterminer les droits minimum qui sont nécessaires pour permettre le bon fonctionnement du site Web. S'agissant de IIS, il est important de comprendre les dangers de l'application des privilèges de lecture et d'exécution à un répertoire. Un dossier disposant de ces droits permet à un pirate de télécharger et de lancer n'importe quel fichier exécutable ou script sur le serveur IIS. Si un administrateur doit attribuer ces droits, le dossier doit être protégé à l'aide d'une fonctionnalité de contrôle d'accès (comme par exemple SSL, l'authentification ou le filtrage IP).

Exploration des répertoires

Si l'exploration des répertoires est activée, elle expose la structure des noms de fichiers et de dossiers du site aux pirates. Elle peut également leur permettre d'explorer les fichiers et d'obtenir des informations sur la configuration d'un serveur. L'exploration des répertoires doit être désactivée.

Contrôle du répertoire Scripts

De nombreux sites placent tous les scripts dans un dossier distinct. Ce dossier est généralement appelé Scripts ou CGI et exécute divers scripts CGI (Common Gateway Interface) ou autres. Selon le principe du privilège minimum, ce dossier doit recevoir l'autorisation d'exécution "scripts uniquement". Les autres autorisations, telles que la lecture, l'écriture et l'exploration des répertoires, doivent être étudiées avec soin.

Contrôle des fichiers exécutables

De nombreux sites Web utilisent des fichiers exécutables, tels que des fichiers .dll ou .exe, qui nécessitent qu'ils soient accessibles directement. Dans ce cas, un répertoire Bin doit être créé, avec pour seule autorisation "scripts et exécutables" (aucune autre autorisation) dans la boîte de dialogue Propriétés du répertoire virtuel. Cette séparation des scripts et des fichiers exécutables permet à l'administrateur d'affecter des autorisations séparées et de contrôler de près la sécurité des fichiers exécutables.

Définition de listes de contrôle d'accès appropriées sur les répertoires virtuels

Bien que le processus d'application des autorisations aux répertoires virtuels dépende quelque peu des applications, certaines règles générales s'appliquent.
Le tableau suivant répertorie des exemples de types de fichiers courants, ainsi que les autorisations qui sont généralement appliquées.

Type de fichier

Listes de contrôle d'accès

CGI

(.exe, .dll, .cmd, .pl)

Tout le monde (X)

Administrateurs (Contrôle total)
Système (Contrôle total)

Fichiers script

(.asp)

Tout le monde (X)

Administrateurs (Contrôle total)
Système (Contrôle total)

Fichiers d'inclusion

(.inc, .shtm, .shtml)

Tout le monde (X)

Administrateurs (Contrôle total)
Système (Contrôle total)

Contenu statique

(.txt, .gif, .jpg, .mspx)

Tout le monde (R)

Administrateurs (Contrôle total)
Système (Contrôle total)

Listes de contrôle d'accès par défaut recommandées par type de fichier

Plutôt que de définir des listes de contrôle d'accès ACL (Access Control Lists) pour chaque fichier, il est préférable de créer de nouveaux répertoires pour chaque type de fichier, de définir des ACL pour ce répertoire, puis de permettre aux ACL d'hériter les fichiers. Voici un exemple de structure de répertoire :

C:\Inetpub\Wwwroot\Myserver\Static (.mspx)

C:\Inetpub\Wwwroot\Myserver\Include (.inc)

C:\Inetpub\Wwwroot\Myserver\Script (.asp)

C:\Inetpub\Wwwroot\Myserver\Executable (.dll)

C:\Inetpub\Wwwroot\Myserver\Images (.gif, .jpeg)

Remarquez que les deux répertoires suivants nécessitent une attention toute particulière :

C:\Inetpub\Ftproot (serveur FTP)

C:\Inetpub\Mailroot (serveur SMTP)

Les ACL par défaut de ces deux répertoires sont Tout le monde (Contrôle total) et doivent être remplacées par quelque chose de plus strict, en fonction du niveau de fonctionnalité requis. Il vous faudra placer le répertoire dans un volume différent de celui du serveur IIS s'il est important de prendre en charge Tout le monde (Écriture), ou faire appel aux quotas de disque de Windows 2000 pour limiter la quantité de données qu'il est possible d'écrire dans ces répertoires.

Recommandations relatives au système de fichiers IIS

Voici les recommandations relatives au système de fichiers IIS :

• Examinez les autorisations des répertoires. Par défaut, Windows crée de nouveaux dossiers et affecte des autorisations Contrôle total au groupe Tout le monde.

• Définissez le contrôle d'accès pour le compte IUSR_nom_ordinateur.
  Ce compte est affecté au groupe Utilisateurs sur le serveur IIS et permet aux utilisateurs anonymes d'ouvrir une session localement. Cela contribue à limiter l'accès des utilisateurs anonymes à l'ordinateur.

• Synchronisez les autorisations Web et NTFS. Si ces autorisations ne sont pas synchronisées, le jeu le plus restrictif des deux est utilisé. La synchronisation peut être effectuée manuellement ou à l'aide de l'Assistant Autorisations. L'organigramme suivant (figure 5) montre que les autorisations NTFS sont l'élément de décision final pour permettre aux utilisateurs d'accéder à un fichier. Le fait de désactiver les autorisations du serveur Web, comme par exemple la lecture, empêche tous les utilisateurs de consulter un fichier, indépendamment des autorisations NTFS appliquées aux comptes de ces utilisateurs. L'activation des autorisations peut permettre à tous les utilisateurs d'afficher ce fichier, excepté lorsque des autorisations NTFS qui limitent l'accès ont également été appliquées. Si à la fois les autorisations NTFS et du serveur Web ont été définies, les autorisations qui refusent explicitement l'accès sont prioritaires par rapport à celles qui octroient l'accès.

Remarque : Pour les sites Web qui hébergent uniquement des informations statiques, seul l'accès en lecture doit être accordé.

Figure 5 : Organigramme des autorisations IIS

Définition des ACL appropriées aux fichiers journaux IIS

Les ACL des fichiers journaux générés par IIS (%Systemroot%\System32\LogFiles) doivent être les suivantes :

• Administrateurs (Contrôle total)

• Système (Contrôle total)

• Tout le monde (RWC (lecture, écriture, modification))

Ces ACL contribuent à empêcher d'éventuels utilisateurs malveillants de supprimer les fichiers pour faire disparaître les traces de leur passage. L'activation de la journalisation est essentielle pour déterminer si un serveur est attaqué. Vous devez utiliser le format de journalisation étendu W3C. Les propriétés suivantes doivent être définies sous l'onglet Propriétés étendues :

• Adresse IP du client

• Nom d'utilisateur

• Méthode

• Ressource URI

• État du protocole

• État Win32

• Agent utilisateur

• Adresse IP du serveur

• Port du serveur

Les deux dernières propriétés ne sont utiles que si vous hébergez plusieurs serveurs Web sur un seul ordinateur. La propriété État Win32 est utile en cas de débogage. Lors de l'examen du journal, tout événement intitulé "erreur 5" doit être noté, car il fait référence à des événements "accès refusé". Pour connaître la signification d'autres erreurs Win32, tapez "net helpmsg err" (sans les guillemets) à l'invite de commande, où err est l'ID de l'événement.

Sécurité du réseau

La section suivante contient des informations sur les problèmes de sécurité liés spécifiquement au réseau.

Définition de restrictions d'adresse IP/adresse DNS

La définition de restrictions d'adresse IP et d'adresse DNS n'est pas courante, mais il s'agit d'une option permettant d'empêcher l'accès aux sites Web à certains utilisateurs. Cependant, il est important de comprendre que si des noms DNS sont utilisés dans les restrictions, plutôt que des adresses IP, IIS doit procéder à une recherche DNS, laquelle peut prendre du temps.

Mise à jour de certificats racine de l'autorité de certification sur le serveur IIS

La configuration des certificats racine de l'autorité de certification s'effectue en deux étapes. La première étape consiste à ajouter tout nouveau certificat racine approuvé de l'autorité de certification, en particulier les nouveaux certificats créés à l'aide de Microsoft Certificate Services 2.0. La deuxième étape consiste à supprimer tous les certificats racine de l'autorité de certification qui ne sont pas approuvés.

Attention : Si le nom de l'entreprise qui a émis le certificat racine n'est pas connu de l'organisation, ce certificat ne doit pas être considéré comme approuvé.

Tous les certificats racine de l'autorité de certification utilisés par IIS sont stockés dans le magasin de certificats de l'ordinateur. Ce magasin est accessible et peut être supprimé via le composant logiciel enfichable Certificats de la console MMC (Microsoft Management Console).

Attention : Ne supprimez pas les racines Microsoft ou VeriSign. Elles sont très utilisées par le système d'exploitation.

Masquage de l'emplacement de contenu

Lorsque des pages statiques non ASP sont extraites, l'URL de la page est envoyée avec l'adresse IP. En d'autres termes, lorsqu'une page statique non ASP est extraite, un en-tête d'emplacement de contenu est ajouté à la réponse. Par défaut, cet en-tête de contenu fait référence à l'adresse IP et non au nom de domaine pleinement qualifié (FQDN, Fully Qualified Domain Name).

Voici un exemple d'en-tête :

HTTP/1.1 200 OK
Server: Microsoft-IIS/4.0
Content-Location: http://10.1.1.1/Default.htm
Date: Thu, 18 Feb 1999 14:03:52 GMT
Content-Type: text/html
Accept-Ranges: bytes
Last-Modified: Wed, 06 Jan 1999 18:56:06 GMT
ETag: "067d136a639be1:15b6"
Content-Length: 4325

Dans cet exemple, la ligne Content-Location spécifie l'adresse interne privée de l'ordinateur IIS (10.1.1.1). Celle-ci ne change pas lorsque le paquet passe par un pare-feu, ce qui risque de compromettre la sécurité en exposant les adresses internes.

Vous pouvez corriger ce problème en modifiant une valeur dans la métabase IIS afin de changer le comportement par défaut et de faire en sorte que les adresses IP ne soient plus exposées, mais que le nom FQDN soit envoyé à la place. Pour en savoir plus, consultez l'article Q218180, "Internet Information Server Returns IP Address in HTTP Header (Content-Location) (IIS renvoie l'adresse IP dans l'en-tête HTTP", dans la Base de connaissances Microsoft

Sécurisation du compte anonyme

Pour plus de sécurité, envisagez l'utilisation d'un compte anonyme distinct.
Le compte IUSR_nom_ordinateur peut être désactivé et servir d'appât. Un nouveau compte doit alors être créé et utilisé comme compte anonyme. Le mot de passe de ce compte doit répondre à des règles strictes, afin qu'il soit très difficile à découvrir. Le compte doit être un compte local qui, s'il est compromis, permettra au pirate d'accéder uniquement au serveur IIS (il est important de tester cela, car certaines applications Web nécessitent un compte de domaine et non un compte local).

Désactivation et suppression d'éléments

Il est important de comprendre les éléments requis par les services utilisés dans l'architecture Internet Data Center. La suppression de tout autre élément contribue à réduire le risque pour le système global.

Désactivation et suppression des exemples d'applications

Les exemples d'applications ne sont pas installés par défaut et ne doivent jamais être installés sur un serveur de production. Tous les exemples d'applications doivent être supprimés, y compris ceux qui ne sont accessibles que via https://localhost ou 127.0.0.1.

Le tableau suivant répertorie les emplacements par défaut de quelques exemples d'applications et fonctionnalités système.

Exemple/fonctionnalité

Répertoire virtuel

Emplacement

Exemples IIS

\IISSamples

C:\ Inetpub\iissamples

Documentation IIS

\IISHelp

C:\Winnt\Help\iishelp

Accès aux données

\MSADC

C:\Program files\Common files\System\Msadc

Désactivation ou suppression des composants COM inutiles

Certains composants COM ne sont pas nécessaires pour la plupart des applications et doivent être supprimés ; par exemple, le composant Objet système de fichiers (cependant, notez que la suppression de ce composant entraîne également la suppression de l'objet Dictionnaire). Certains programmes nécessitent des composants particuliers ; par exemple, Microsoft Site Server 3.0 utilise l'objet système de fichiers.

Suppression du répertoire virtuel IISADMPWD

Le répertoire virtuel IISADMPWD permet de réinitialiser les mots de passe Windows NT et Windows 2000. Il est principalement destiné aux scénarios intranet et ne fait pas partie de l'installation de IIS 5.0. Cependant, il n'est pas supprimé lors de la mise à niveau d'un serveur IIS 4.0 vers IIS 5.0. Il doit être supprimé si le serveur est connecté au Web.

Suppression des mappages de scripts non utilisés

IIS est préconfiguré pour prendre en charge les extensions de nom de fichier courantes telles que .asp et .shtm. Lorsque IIS reçoit une demande pour un fichier de ce type, l'appel est traité par la DLL appropriée, laquelle est contrôlée par le mappage d'application stocké dans le cadre de la configuration du répertoire de base. Le tableau suivant répertorie les principaux mappages d'applications qui peuvent être supprimés.

Si vous n'utilisez pas

Supprimez l'entrée suivante

La redéfinition du mot de passe pour le Web

.htr

Internet Database Connector

.idc

Inclusions côté serveur

.stm, .shtm et .shtml

Impression Internet

.printer

Index Server

.htw, .ida et .idq

Désactivation des chemins d'accès relatifs au répertoire parent

L'option Chemins d'accès relatifs au répertoire parent permet d'utiliser des guillemets doubles ".." dans les appels aux fonctions telles que MapPath. Cette option est activée par défaut et il faut la désactiver.

Structure Active Directory

La structure Active Directory de l'architecture Internet Data Center est basée sur un modèle de domaine unique. Cette structure, basée sur les exigences spécifiques de l'application utilisée dans le laboratoire Internet Data Center, n'est sans doute pas adaptée à toutes les implémentations, mais c'est le point de départ recommandé pour la plupart des structures Active Directory. Cette structure est détaillée dans le chapitre 9 du Kit de ressources de Microsoft Windows 2000. Le schéma suivant illustre la structure Active Directory ainsi que les rôles des ordinateurs dans l'architecture Internet Data Center.

Figure 6 : Structure Active Directory dans l'architecture Internet Data Center

L'exigence initiale lors de la conception de l'architecture Internet Data Center était qu'elle soit simple. Chaque structure Active Directory doit impliquer à la fois le réseau périmétrique et l'environnement d'entreprise. L'architecture Internet Data Center ne peut pas tenir compte de toutes les structures et exigences différentes propres à chaque organisation. L'ajout d'un réseau d'entreprise nécessite une planification importante de la relation entre la sécurité, la réplication et l'annuaire. La structure du réseau périmétrique fait partie d'une architecture plus importante qui est mise en place lorsqu'une connexion d'entreprise est implémentée entre les deux architectures. Voici deux modèles couramment utilisés aujourd'hui :

• deux forêts distinctes (une pour le réseau de l'entreprise et l'autre pour le réseau périmétrique) ;

• une forêt avec une arborescence pour le réseau périmétrique et des arborescences distinctes pour les ressources internes de l'entreprise.

La structure que vous devez utiliser dépend de vos exigences techniques et professionnelles.

Les serveurs DNS internes qui constituent l'espace de noms Internet Data Center sont implémentés sur les deux contrôleurs de domaine. Les deux serveurs sont intégrés à Active Directory. Cette intégration offre une topologie de réplication configurée automatiquement, laquelle permet aux deux serveurs de jouer le rôle de serveur principal pour les ajouts et les suppressions, créant ainsi une architecture redondante. Les deux serveurs font autorité pour les zones de recherche directe et inverse créées pour les réseaux VLAN suivants (reportez-vous à la figure 2, plus haut dans ce chapitre).

Nom du réseau VLAN

Réseau IP

Numéro VLAN

Réseau VLAN dorsal DMZ

192.168.11.0

VLAN 11

Réseau VLAN de données/gestion

192.168.12.0

VLAN 12

Réseau VLAN de l'infrastructure

192.168.13.0

VLAN 13

Pour en savoir plus sur l'architecture DNS, consultez le chapitre 2, "Conception de l'infrastructure réseau".

Rôles de maître d'opérations

Un autre élément de conception important pour l'annuaire est l'implémentation correcte des rôles de maître d'opérations. Dans Active Directory, la possibilité d'apporter des modifications à l'échelle du système n'est pas associée à un seul contrôleur de domaine ; cette possibilité est donc désignée sous le rôle de maître d'opérations. Au moment de la rédaction de ce document, Windows 2000 prend en charge les cinq rôles de maître d'opérations suivants :

• Contrôleur de schéma. Il s'agit du seul contrôleur de domaine autorisé à traiter les mises à jour du schéma de l'annuaire. Il réplique le schéma mis à jour sur tous les autres contrôleurs de domaine de l'annuaire. Il n'existe qu'un seul contrôleur de schéma par annuaire.

• Maître de nommage de domaine. Il s'agit du seul contrôleur de domaine autorisé à apporter des modifications à l'espace de noms de domaine de la forêt de l'annuaire. Il s'agit également du seul contrôleur de domaine autorisé à ajouter ou à supprimer un domaine de l'annuaire, ou à ajouter ou supprimer des références croisées vers des domaines d'annuaires externes.

• Maître RID. Il s'agit du seul contrôleur de domaine autorisé à traiter les demandes de RID (Relative Identifier) provenant des contrôleurs de domaine de son propre domaine, ainsi que du seul à pouvoir supprimer un objet de son domaine et à le placer dans un autre domaine lors d'un déplacement d'objet.

• Émulateur PDC. Celui-ci s'annonce lui-même comme contrôleur principal de domaine (CPD) auprès des postes de travail, serveurs membres et contrôleurs de domaine qu'il contrôle.

• Maître d'infrastructure. Lorsqu'un objet est référencé par un autre objet d'un autre domaine, la référence est représentée par l'identifiant absolument unique (GUID, Globally Unique Identifier), l'identificateur de sécurité (SID, Security Identifier) pour les références aux entités de sécurité, ainsi que le nom de domaine de l'objet référencé. Le contrôleur de domaine du maître d'infrastructure met à jour les SID des objets ainsi que les noms uniques dans les références entre domaines.

Affectation des rôles pour les opérations

Plus haut dans ce chapitre, la figure 6 illustre la façon dont les rôles de maître d'opérations sont affectés dans l'architecture Internet Data Center. Les rôles de contrôleur de schéma et de maître de nommage de domaine sont attribués forêt par forêt. Les trois autres (maître RID, émulateur PDC et maître d'infrastructure) sont attribués domaine par domaine. Dans la mesure où la structure Active Directory de l'architecture Internet Data Center est un domaine unique, il n'y a que les cinq rôles initiaux. Lorsque le premier contrôleur de domaine Windows 2000 est créé dans l'architecture Internet Data Center, les cinq rôles lui sont attribués. En raison des problèmes de charge, les rôles de maître RID et de maître d'infrastructure sont placés sur un serveur distinct. Dans une structure Active Directory à plusieurs domaines, chaque domaine ajoute trois rôles supplémentaires de maître d'opérations. Pour ces structures multidomaines, il est recommandé de placer le maître d'infrastructure sur un contrôleur de domaine qui ne soit pas un serveur de catalogue global. Cependant, dans la mesure où la structure Active Directory de l'architecture Internet Data Center est un domaine unique, le maître d'infrastructure peut se trouver sur le même contrôleur de domaine que le serveur de catalogue global. Les rôles de contrôleur de schéma, d'émulateur PDC et de maître de nommage de domaine se trouvent sur le même contrôleur de domaine, car ils sont rarement utilisés et sont étroitement contrôlés.

Configuration Active Directory

Le tableau suivant illustre la configuration des deux contrôleurs de domaine du domaine racine.

Attributs

Contrôleur de domaine 1

Contrôleur de domaine 2

Nom

AD01

AD02

Configuration IP

Adresse IP : 192.168.13.20

Sous-réseau : 255.255.255.0

DNS : principal pour lui-même/secondaire pour AD02

Adresse IP : 192.168.13.21

Sous-réseau : 255.255.255.0

DNS : principal pour lui-même/secondaire pour AD01

Rôles de maître d'opérations

Contrôleur de schéma

Maître de nommage de domaine

Émulateur PDC

Maître d'infrastructure

Maître RID

Catalogue global

Oui

Oui

DNS

Oui. Dynamique/intégré à Active Directory

Oui. Dynamique/intégré à Active Directory

WINS

Non implémenté

Non implémenté

Configuration matérielle

Boîtier de bas niveau

256 mégaoctets (Mo) de RAM minimum.

9,1 gigaoctets (Go) de disque dur (RAID 1)

Boîtier de bas niveau

256 Mo de RAM minimum

9,1 Go de disque dur (RAID 1)

Mode de domaine

Pour l'architecture Internet Data Center, Active Directory est passé du mode de domaine mixte au mode natif, car il n'existe pas d'exigence de prise en charge de contrôleurs de domaine Windows NT 4.0 dans le même domaine.

Modèle de sécurité Windows 2000/stratégies Active Directory

Intégré à Windows 2000 Server, Active Directory simplifie la tâche de sécurisation des serveurs du réseau périmétrique. Un groupe de serveurs présentant les mêmes fonctionnalités peut être créé (par exemple, un groupe de serveurs Microsoft IIS peut être créé à l'aide d'unités d'organisation, comme cela est décrit plus loin dans cette section), et des objets stratégie de groupe peuvent ensuite être utilisés pour appliquer au groupe des paramètres de sécurité communs. Si davantage de serveurs sont ajoutés à ce groupe ultérieurement, nombre des paramètres de sécurité communs sont automatiquement appliqués, ce qui réduit le travail de déploiement et d'administration.

Cette section décrit comment sécuriser les ordinateurs qui exécutent Windows 2000 Server à l'aide d'une combinaison de stratégies de groupe, de modifications du Registre et de configurations réseau dans l'architecture Internet Data Center. Ce processus s'applique uniquement aux ordinateurs qui exécutent Windows 2000 Server ; il ne peut pas être utilisé sur des serveurs Windows NT 4.0 du réseau périmétrique.

Les serveurs sont regroupés en fonction de leurs rôles et leurs connexions réseau sont séparées les unes des autres à l'aide de la technologie VLAN. Chaque réseau VLAN de l'architecture crée une zone de sécurité qui impose des exigences de sécurité particulières aux serveurs et à l'équipement réseau de la zone. Les serveurs qui appartiennent à la même zone peuvent établir des communications entre eux à l'aide d'une simple diffusion locale. Lorsque des serveurs doivent communiquer entre zones, une barrière de sécurité doit être franchie et le trafic qui est autorisé à passer est étroitement contrôlé, comme cela a été décrit précédemment dans la section "Défenses réseau".

Pour en savoir plus sur les configurations VLAN, consultez le Chapitre 2, "Conception de l'infrastructure réseau".

Utilisation de stratégies pour appliquer la sécurité

Lorsque des stratégies de sécurité sont créées et appliquées, l'objectif est de simplifier et de centraliser la gestion et la configuration de la sécurité pour les ordinateurs Windows 2000 Server du réseau périmétrique. Les stratégies réduisent la charge de travail de l'administrateur en automatisant certains processus pour l'application de la sécurité aux serveurs, bien que certaines actions manuelles soient toujours nécessaires pour renforcer les serveurs.

Il existe deux types de conteneurs pour les stratégies Windows 2000 : les stratégies utilisateur et les stratégies d'ordinateur. La structure des stratégies de l'architecture Internet Data Center est basée sur la stratégie d'ordinateur pour le renforcement des serveurs.

Les ordinateurs qui exécutent Windows 2000 Server et qui sont membres d'un domaine accèdent périodiquement à Active Directory ; s'ils détectent la présence d'une nouvelle stratégie ou la modification d'une stratégie existante, ils téléchargent automatiquement cette stratégie et l'appliquent localement. Lors de la création du domaine, seules les stratégies de domaine et de contrôleur de domaine sont appliquées, et ces stratégies appliquent des paramètres par défaut aux serveurs qui joignent le domaine. Des stratégies personnalisées sont créées pour chaque type de serveur. Pour les paramètres courants, des stratégies sont appliquées à l'échelle du domaine, et pour les paramètres spécifiques, des stratégies sont affectées aux unités d'organisation. L'utilisation des stratégies par défaut n'offre pas une sécurité suffisante pour le déploiement de serveurs dans l'architecture Internet Data Center.

Hiérarchie et héritage des stratégies

Une stratégie de groupe est administrée via l'utilisation d'objets stratégie de groupe (GPO, Group Policy Objects), qui sont des structures de données liées dans une hiérarchie spécifique à des objets Active Directory sélectionnés, comme par exemple des sites, des domaines ou des unités d'organisation. Une fois ces GPO créés, ils sont appliqués dans un ordre standard, représenté par l'acronyme "LSDUO", qui signifie :

1. Local. La stratégie d'ordinateur qui est créée en premier lors de l'installation de l'ordinateur.

2. Site. Si le domaine est réparti sur plusieurs sites, une stratégie de site peut être implémentée. Pour l'architecture Internet Data Center, aucune stratégie de site n'est déployée, car cette structure est contenue dans un seul emplacement.

3. Domaine. Une stratégie qui applique des paramètres communs à tous les serveurs du domaine.

4. Unité d'organisation. Conteneurs Active Directory dans lesquels des utilisateurs, des groupes, des ordinateurs et d'autres unités d'organisation peuvent être placés. Les stratégies peuvent être isolées et appliquées uniquement aux objets qui se trouvent dans cette unité d'organisation.

Les dernières stratégies sont prioritaires par rapport à celles appliquées précédemment. Par exemple, les paramètres de la stratégie de l'unité d'organisation remplacent ceux de la stratégie de domaine si la même option est définie dans les deux stratégies, dès lors que l'unité d'organisation n'a pas configuré l'héritage des blocs.

Stratégie de domaine

Pour l'architecture Internet Data Center, une stratégie de domaine commune à tous les serveurs du domaine est appliquée pour les paramètres de sécurité des ordinateurs. Les sections suivantes décrivent les paramètres de sécurité communs imposés par la stratégie de domaine.

Stratégie de mot de passe

Une stratégie de mot de passe standard est appliquée à tous les serveurs du domaine. Pour garantir la sécurité des comptes administrateur, il est recommandé d'utiliser un mot de passe complexe comportant au moins 15 caractères. Le tableau suivant répertorie les paramètres d'une stratégie de mot de passe standard.

Stratégie

Paramètre de l'ordinateur

Appliquer l'historique des mots de passe.

24 mots de passe mémorisés

Âge maximal des mots de passe

42 jours

Âge minimal des mots de passe

2 jours

Longueur minimale des mots de passe

8 caractères

Les mots de passe doivent répondre à des exigences de complexité

Activé

Stocker les mots de passe à l'aide du cryptage réversible pour tous les utilisateurs du domaine

Désactivé

Stratégie de verrouillage de compte

La stratégie de verrouillage de compte est importante pour sécuriser les comptes au cas où ils seraient victimes d'une attaque d'un pirate qui tenterait de deviner le mot de passe d'un compte. Un compte qui subit cinq tentatives d'ouverture de session infructueuses en 30 minutes est bloqué pendant 30 minutes, après quoi il est réinitialisé à 0 tentatives infructueuses et peut de nouveau être utilisé). Le compte ne peut être réactivé avant la fin des 30 minutes que si un administrateur réinitialise le verrouillage. Le tableau suivant répertorie les paramètres de la stratégie de verrouillage de compte.

Stratégie

Paramètre de l'ordinateur

Durée de verrouillage des comptes

30 minutes

Seuil de verrouillage des comptes

5 tentatives d'ouverture de session infructueuses

Réinitialiser le verrouillage des comptes après

30 minutes

Stratégie d'audit

Les paramètres de tous les journaux IIS, ainsi que des journaux des applications, de sécurité et du système, sont configurés dans la stratégie et sont appliqués à tous les serveurs du domaine. La taille de chacun des journaux est configurée à 10 Mo et chaque journal est configuré pour être tronqué lorsqu'il contient 10 Mo de données. Dans la mesure où le système de gestion détecte les événements spécifiques dans les journaux afin d'extraire et d'envoyer les détails à la base de données de gestion, il n'est pas nécessaire de conserver les informations des journaux. Le tableau suivant répertorie les réussites et/ou échecs à enregistrer dans le journal, tels qu'ils sont configurés dans la stratégie d'audit :

Stratégie

Paramètre de l'ordinateur

Audit des événements de connexion de compte

Réussite, échec

Audit de gestion des comptes

Réussite, échec

Auditer l'accès au service d'annuaire

Échec

Audit des événements de connexion

Réussite, échec

Audit d'accès aux objets

Échec

Audit des changements de procédure

Réussite, échec

Audit des utilisations de privilèges

Échec

Audit du suivi de processus

Pas d'audit

Audit des événements système

Échec

Remarque : La stratégie de mot de passe et de compte ne peut être définie qu'au niveau du domaine. Si ces stratégies sont définies au niveau de l'unité d'organisation ou ailleurs dans Active Directory, elles sont ignorées par la stratégie de domaine.

Lors de la construction du domaine, Windows 2000 crée une stratégie de domaine par défaut ; des exigences spécifiques peuvent être modifiées ultérieurement dans la stratégie par défaut. La stratégie par défaut peut être remplacée par une nouvelle stratégie associée à la stratégie de domaine, laquelle spécifie les paramètres anciens, modifiés et nouveaux. Seuls les paramètres définis dans la stratégie associée remplacent la stratégie de domaine par défaut, et les nouveaux paramètres sont envoyés à tous les serveurs et postes de travail du domaine. L'avantage de l'utilisation d'une stratégie de domaine de remplacement plutôt que de modifier la stratégie par défaut est que, en cas de problème, la stratégie de remplacement peut être désactivée afin de permettre à la stratégie de domaine par défaut de reprendre le contrôle.

Stratégie de contrôleur de domaine

Par défaut, Active Directory place tous les contrôleurs de domaine dans leur propre unité d'organisation appelée Contrôleurs de domaine. Une stratégie par défaut distincte est créée pour les contrôleurs de domaine lors de la construction initiale du domaine. Comme pour la stratégie de domaine, certains paramètres de sécurité doivent être appliqués pour remplacer les stratégies de contrôleur de domaine par défaut. Par exemple, la section d'audit de la stratégie par défaut ne modifie pas les contrôleurs de domaine. Ces paramètres doivent être configurés dans la stratégie de contrôleur de domaine. Comme pour la stratégie de domaine, une nouvelle stratégie de contrôleur de domaine est construite à partir d'une copie de la stratégie de contrôleur de domaine par défaut. Les modifications sont apportées à la nouvelle stratégie et celle-ci est ensuite associée à la stratégie de contrôleur de domaine par défaut. Une fois les modifications vérifiées, la stratégie de contrôleur de domaine originale peut être supprimée.

Application des stratégies de groupe

Voici quelques méthodes d'application de stratégies de groupe aux serveurs
du domaine :

• Par défaut, les stratégies de groupe sont actualisées toutes les 90 minutes sur les ordinateurs Windows 2000 Server. Cependant, les contrôleurs de domaine sont configurés pour détecter les mises à jour toutes les 5 minutes. Ces deux paramètres peuvent être modifiés à l'aide de stratégies de groupe.

• Chaque fois qu'un serveur est redémarré, il examine la stratégie Active Directory afin de détecter les éventuelles modifications, puis il réapplique la stratégie localement.

• Les stratégies de groupe peuvent être appliquées immédiatement à un serveur à l'aide de l'utilitaire de ligne de commande secedit.

Topologie des unités d'organisation

Dans l'architecture Internet Data Center, une unité d'organisation est utilisée pour partitionner et automatiser l'application de la sécurité pour des groupes de serveurs, comme par exemple les contrôleurs de domaine et les serveurs Microsoft IIS.

La figure 7 illustre la structure des unités d'organisation et des stratégies implémentée dans l'architecture Internet Data Center.Une fois un serveur construit et prêt à être déployé en production, l'administrateur doit déplacer l'ordinateur de l'unité d'organisation par défaut, appelée "Ordinateurs", vers l'unité d'organisation de destination, en fonction de son rôle.

Figure 7 : Structure des unités d'organisation et des stratégies

Il est important de planifier l'architecture des stratégies en distinguant les exigences de sécurité spécifiques des serveurs à l'aide d'unités d'organisation, car une fois l'infrastructure en production, il peut s'avérer nécessaire d'annuler ou de modifier une stratégie. Lorsqu'une stratégie est annulée ou modifiée, cela affecte uniquement les serveurs qui appartiennent à cette unité d'organisation particulière ; les autres serveurs du domaine ne sont pas affectés. Par exemple, les modifications apportées à la stratégie des serveurs Microsoft IIS n'affectent pas les serveurs qui exécutent SQL Server, car ceux-ci appartiennent à une autre unité d'organisation.

Modèles de sécurité

Windows 2000 inclut plusieurs types de modèles de sécurité. Ces modèles sont enregistrés sous forme de fichiers .inf dans le dossier %SystemRoot%\Security\Templates. Les modèles de sécurité qui commencent par "basic" dans la liste suivante sont utilisés pour les paramètres de sécurité par défaut de Windows 2000. Ces paramètres sont appliqués lors de la construction initiale du système Windows 2000. Les modèles de sécurité élémentaires sont les suivants :

• Basicwk.inf. Pour Windows 2000 Professionnel.

• Basicsv.inf. Pour Windows 2000 Server.

• Basicdc.inf. Pour les contrôleurs de domaine Windows 2000.

Pour offrir davantage de sécurité à Windows 2000, les modèles de sécurité Securedc.inf, Securews.inf, Hisecdc.inf et Hisecws.inf peuvent être appliqués après les modèles élémentaires. Ces modèles sont considérés comme des modèles incrémentaux, car ils ne peuvent être appliqués qu'une fois les modèles élémentaires appliqués. Les paramètres élémentaires sont appliqués lors de la construction initiale du serveur Windows 2000. Les modèles qui commencent par "secure" appliquent des paramètres de sécurité supplémentaires par rapport aux modèles élémentaires. Les modèles qui commencent par "hisec" incluent tous les paramètres des modèles "secure" et modifient les valeurs du Registre pour les paramètres "basic" et "secure".

Le tableau suivant répertorie les valeurs initiales des clés de Registre lorsque le modèle "basic" est appliqué, ainsi que les modifications incrémentales des valeurs du Registre lorsque les modèles de serveur "secure" ou "hisec" sont appliqués. Ces valeurs de Registre font partie de la section des options de sécurité de la stratégie de groupe réelle qui serait affectée à un serveur via une unité d'organisation.

Clé de registre

Basic

Secure

Hisec

HKLM\System\CurrentControlSet\Control\Lsa\AuditBaseObjects

0

HKLM\System\CurrentControlSet\Control\Lsa\CrashOnAuditFail

0

HKLM\System\CurrentControlSet\Control\Lsa\FullPrivilegeAuditing

0

HKLM\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel

0

2

5

HKLM\System\CurrentControlSet\Control\Lsa\RestrictAnonymous

0

1

2

HKLM\System\CurrentControlSet\Control\Print\Providers\LanMan Print Services\Servers\AddPrinterDrivers

1

HKLM\System\CurrentControlSet\Control\Session Manager\
Memory Management\ClearPageFileAtShutdown

0

1

HKLM\System\CurrentControlSet\Control\
Session Manager\ProtectionMode

0

HKLM\System\CurrentControlSet\Services\LanManServer\
Parameters\EnableSecuritySignature

0

1

HKLM\System\CurrentControlSet\Services\LanManServer\
Parameters\RequireSecuritySignature

0

1

HKLM\System\CurrentControlSet\Services\LanManServer\
Parameters\EnableForcedLogOff

1

HKLM\System\CurrentControlSet\Services\LanManServer\
Parameters\AutoDisconnect

15

HKLM\System\CurrentControlSet\Services\LanmanWorkstation\
Parameters\EnableSecuritySignature

1

HKLM\System\CurrentControlSet\Services\LanmanWorkstation\
Parameters\RequireSecuritySignature

0

1

HKLM\System\CurrentControlSet\Services\LanmanWorkstation\
Parameters\EnablePlainTextPassword

0

HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\
DisablePasswordChange

0

HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\
SignSecureChannel

1

HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\
SealSecureChannel

1

HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\
RequireSignOrSeal

0

1

HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\
RequireStrongKey

0

1

HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\DisableCAD

0

HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\DontDisplayLastUserName

0

1

HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\LegalNoticeCaption

“”

HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\LegalNoticeText

“”

HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\ShutdownWithoutLogon *

0

1

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Setup\
RecoveryConsole\SecurityLevel

0

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Setup\
RecoveryConsole\SetCommand

0

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\
AllocateCDRoms

0

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\
AllocateDASD

0

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\
AllocateFloppies

0

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\
CachedLogonsCount

10

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\
PasswordExpiryWarning

14

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\
ScRemoveOption

0

1

HKLM\Software\Microsoft\Driver Signing\Policy******

1

2

HKLM\Software\Microsoft\Non-Driver Signing\Policy******

1

** Stratégies complémentaires ajoutées lorsque des modèles "secure" ou "hisec" sont appliqués
* La modification de la clé ShutdownWithoutLogon est recommandée uniquement pour les serveurs dont l'interrupteur de mise sous tension est physiquement sécurisé.

Remarque : Pour en savoir plus sur les clés et valeurs de Registre du tableau précédent, consultez le fichier gp.chm dans le Kit de ressources de Windows 2000 Server.

Il existe plus de différences entre les modèles "secure" et "hisec" que les seules valeurs du Registre. Le tableau suivant résume les différences entre les deux modèles Windows 2000 Server. Le modèle hisecws.inf est un modèle sécurisé conçu comme un bon point de départ pour le développement d'une configuration de stratégie.

Stratégie

Modèle "Secure"

Modèle "Hisec"

Compte – Mot de passe

Configuration de l'âge, de la longueur et de la complexité des mots de passe

Identique à la stratégie "secure"

Compte – Verrouillage

Configuration de la durée, du seuil et du compteur de réinitialisation de verrouillage

Identique à la stratégie "secure", excepté la durée de verrouillage, définie sur 0

Local – Audit

Configuration du contrôle des réussites et des échecs

Configuration d'un niveau plus élevé de contrôle des réussites et des échecs

Local – Droits utilisateur

Aucun défini

Aucun défini

Local – Options de sécurité

Valeurs modifiées (voir le tableau de la section "Modèles de sécurité", plus haut dans ce chapitre)

Davantage de valeurs modifiées (voir le tableau de la section "Modèles de sécurité", plus haut dans ce chapitre, pour comparer)

Journal des événements

Définition de la taille du journal système ; accès invité limité aux 3 journaux

Définition de la taille des 3 journaux ; accès invité limité aux 3 journaux

Services système

Aucun défini

Davantage de services désactivés

Registre

Aucun défini

Davantage de listes de contrôle d'accès appliquées

Système de fichiers

Aucun défini

Davantage de listes de contrôle d'accès appliquées

Pour l'architecture Internet Data Center, une variante du modèle "Hisec" a été déployée comme base de sécurité.

Renforcement des serveurs pour l'architecture Internet Data Center

La sécurisation de serveurs Windows 2000 basés sur des domaines est un processus complexe qui nécessite une configuration et des tests approfondis avant de procéder à la mise en place du serveur dans le réseau de production. Un pare-feu seul n'est pas suffisant pour sécuriser les serveurs. La sécurité doit être appliquée à chaque serveur, en supposant que le serveur n'est pas protégé par le réseau périmétrique ou par un pare-feu. Les réseaux d'infrastructure et de données/gestion doivent également être traités comme s'ils se trouvaient dans la même zone de sécurité que les serveurs Microsoft IIS.

Cette section étudie les principales modifications apportées à la configuration de la sécurité de chaque serveur déployé dans l'architecture Internet Data Center.

Bien que la plupart des modifications de sécurité de Windows 2000 puissent être traitées par l'intermédiaire de stratégies et de la topologie des unités d'organisation, certaines modifications doivent être apportées manuellement, les autres pouvant également être effectuées manuellement si l'administrateur le souhaite. Cette section détaille toutes les modifications qui doivent être apportées à chaque serveur. Voici un résumé des modifications recommandées :

• Appliquez les derniers service packs et tenez-vous informé des derniers correctifs et alertes de sécurité.

• Appliquez la stratégie de sécurité à l'aide d'une variante du modèle haute sécurité, via des unités d'organisation.

• Renforcez les paramètres TCP/IP des serveurs IIS.

• Implémentez le filtrage des paquets sur les cartes réseau externes des serveurs IIS.

• Désactivez NetBIOS sur les cartes réseau externes des serveurs IIS.

• Supprimez les partages administratifs par défaut des serveurs IIS.

• Sécurisez les ACL du système de fichiers.

• Sécurisez les comptes Administrateur locaux et du domaine.

• Désactivez les services qui ne sont pas indispensables.

Se tenir informé des service packs et correctifs

Il est très important d'appliquer les derniers service packs et correctifs à l'ordinateur qui exécute Windows 2000 Server, ainsi que les nouveaux correctifs de sécurité, les correctifs IIS, ainsi que les correctifs pour les autres applications qui s'exécutent sur le système. Il est nécessaire de procéder à une planification et à des tests minutieux dans un environnement de test qui simule avec précision l'environnement de production, afin de vérifier les modifications qui seront appliquées au système de production. Une sauvegarde complète du serveur doit également être effectuée avant toute opération de maintenance.

Abonnement au service Microsoft Security Notification

L'abonnement au service Microsoft Security Notification est utile pour se tenir informé des problèmes et correctifs de sécurité associés aux produits Microsoft. Une fois abonné, vous êtes automatiquement informé par courrier électronique des problèmes de sécurité. Vous trouverez davantage de détails sur le service Microsoft Security Notification  sur Microsoft TechNet.

Il est également utile de créer un raccourci vers le programme Microsoft Security Advisor sur le Bureau.

Pour créer un raccourci :

1. Lancez Microsoft Internet Explorer.

2. Accédez à la page Microsoft Security Notification Service sur TechNet.

3. Dans le menu Favoris, cliquez sur Ajouter aux Favoris.

4. Activez la case à cocher Rendre disponible hors connexion, cliquez sur Personnaliser, puis cliquez sur Suivant dans l'Assistant Favoris hors connexion.

5. Cliquez sur Oui et précisez que vous souhaitez télécharger des pages dont les liens remontent à deux pages à partir de la présente.

6. Cliquez sur Suivant.

7. Cliquez sur Créer une nouvelle planification, puis cliquez sur Suivant.

8. Acceptez les paramètres par défaut, puis cliquez sur Suivant.

9. Cliquez sur Terminer, puis sur OK.

10. Dans le menu Favoris, cliquez sur Organiser les Favoris.

11. Dans la boîte de dialogue Organiser les Favoris, cliquez sur Microsoft TechNet Security.

12. Cliquez sur Propriétés.

13. Sous l'onglet Téléchargement, désactivez la case à cocher Suivre les liens à l'extérieur du site Web de cette page.

14. Cliquez sur OK, puis sur Fermer.

Faites glisser le raccourci Microsoft TechNet Security du menu Favoris vers le Bureau. Une petite marque rouge apparaît sur l'icône lorsque des nouvelles en matière de sécurité surviendront.

Important : Il est essentiel de se tenir informé des nouveaux problèmes de sécurité lorsqu'ils surviennent. Nous n'insisterons jamais assez sur cela.

Sécurisation du réseau

Outre la protection de l'infrastructure physique du réseau, il est également important de sécuriser la mise en réseau Windows 2000. Cette section décrit quelques-unes des méthodes essentielles utilisées pour cela dans l'architecture Internet Data Center.

Rendre plus difficiles les attaques TCP/IP sur les serveurs de la zone DMZ

Par défaut, la pile TCP/IP est configurée pour traiter le trafic normal dans des conditions de travail normales. Pour les ordinateurs Windows 2000 Server exposés à Internet, comme par exemple les serveurs Microsoft IIS, la pile TCP/IP est reconfigurée afin de décourager les attaques TCP/IP. Cela nécessite la configuration de paramètres TCP/IP supplémentaires dans le Registre, mais ces modifications sont incluses dans le modèle de sécurité des serveurs Microsoft IIS, de sorte qu'elles peuvent être appliquées automatiquement.

Pour en savoir plus sur le renforcement de la pile TCP/IP, consultez l'article Q142641, "Internet Server Unavailable Because of Malicious SYN Attacks (Serveur Internet indisponible en raison d'attaques SYN malveillantes)" dans la Base de connaissances Microsoft.

Implémentation de filtres IPSec sur des serveurs de la zone DMZ

Le moteur de stratégie IPSec fourni avec Windows 2000 est un outil puissant pour améliorer la sécurité générale de l'architecture Internet Data Center, en particulier la sécurité des serveurs Web. En tant que méthode de filtrage des paquets, l'utilisation de la stratégie IPSec pour sécuriser les systèmes Web est une technologie plus puissante et plus souple que l'utilisation du filtrage TCP/IP, disponible dans les paramètres de configuration avancés des propriétés des cartes réseau pour les ordinateurs Windows 2000.

La stratégie IPSec revient généralement à créer un chemin de communication sécurisé entre deux sites hôtes ou deux sites distants. Cependant, l'architecture Internet Data Center utilise la stratégie IPSec pour ses fonctionnalités de filtrage de protocole/de port.

Pour créer des stratégies IPSec :

1. Créez une liste de filtrage, constituée de ports, de protocoles et de directions.

2. Créez une action de filtrage, qui définit une mesure à prendre lorsque le trafic correspond à un filtre. Les actions les plus courantes sont l'autorisation et le blocage.

3. Créez une nouvelle stratégie IPSec personnalisée, affectez des listes de filtrage IP et définissez une action pour cette liste.

4. Appliquez la stratégie aux serveurs souhaités.

Pour l'architecture Internet Data Center, deux listes de filtrage personnalisées ont été créées. Le premier filtre autorise les communications d'Internet vers le port 80. Le deuxième filtre bloque toute autre communication.

Le tableau suivant répertorie la configuration du sous-réseau 192.168.22.0. La même configuration est appliquée au sous-réseau 192.168.23.0 pour les deuxièmes serveurs IIS du cluster.

Liste de filtrage

Direction

De/vers

Sous-réseau IP de l'interface

Protocole

Port TCP/UDP

WebIn

Entrant

Tout

192.168.22.0/24

TCP

80

AllTrafficIn

Entrant

Tout

192.168.22.0/24

Tout

Tout

Outre l'implémentation de l'action de filtrage Autoriser, nous avons créé l'action de filtrage Bloquer. Nous avons utilisé cette action par rapport à la liste de filtrage AllTrafficIn.

Dans la mesure où les serveurs Web font partie du domaine Windows 2000 et où ils sont tous membres de la même unité d'organisation, les serveurs Web et les unités d'organisation constituent l'emplacement le plus logique pour créer la stratégie de filtrage IPSec.

Les communications avec les serveurs DNS sont également sécurisées dans la zone DMZ à l'aide de la même technique. L'une des listes de filtrage est constituée du protocole DNS qui est autorisé à passer par les cartes réseau frontales de ces serveurs. Un autre filtre est créé pour tout le trafic. Ce filtre, nommé AllTrafficIn, bloque tout autre trafic à destination des serveurs au niveau des cartes réseau frontales. Le tableau suivant répertorie les stratégies IPSec appliquées à ces serveurs.

Liste de filtrage

Direction

De/vers

Sous-réseau IP de l'interface

Protocole

Port TCP/UDP

InternetIn

Entrant

Tout

192.168.21.0/24

UDP

53

AllTrafficIn

Entrant

Tout

192.168.22.0/24

Tout

Tout

Désactivation des services NetBIOS sur les serveurs de la zone DMZ

NetBIOS sur TCP/IP doit être désactivé sur la carte réseau externe de tous les serveurs IIS afin d'éviter que des utilisateurs mal intentionnés ne puissent accéder au serveur via un autre mécanisme que TCP/IP. Cela permet de désactiver l'utilisation de toutes les commandes NetBIOS, comme par exemple nbtstat, que les pirates utilisent pour exposer des informations sur le serveur.

NetBIOS est simplement une norme de recherche de ressources, qui est prise en charge pour la compatibilité descendante avec Windows NT Server 4.0. NetBIOS utilise les ports suivants :

• UDP/137 (service de nom NetBIOS)

• UDP/138 (service de datagramme NetBIOS)

• TCP/139 (service de session NetBIOS)

La désactivation de NetBIOS n'est pas, et ne doit pas être, une décision simple. Certaines applications qui s'exécutent dans l'environnement Windows 2000 ont besoin de NetBIOS pour fonctionner correctement. Cependant, s'il est désactivé, Windows 2000 continue de prendre en charge le trafic SMB sans utiliser les ports NetBIOS standard, en utilisant à la place le port TCP 445 (appelé hôte direct). Sur les cartes réseau des serveurs Web exposées à Internet, le port TCP 445 doit être désactivé en supprimant le partage de fichiers et d'imprimantes pour les réseaux Microsoft ainsi que les clients pour les réseaux Microsoft dans les propriétés TCP/IP.

Microsoft Application Center 2000 est un exemple d'application qui nécessite l'API NetBIOS. Lorsque Application Center est configuré pour l'équilibrage de charge d'un groupe de clusters Web à l'aide de la fonctionnalité d'équilibrage de charge réseau, les serveurs doivent être multirésidents, avec NetBIOS activé sur la carte réseau interne des serveurs multirésidents utilisés pour la gestion de Application Center. Pour en savoir plus, reportez-vous à l'article Q289723, "INFO: Event ID: 4135 ClusterNameResolution NetBIOSIsDisabled", dans la Base de connaissances Microsoft.

Sécurisation du système de fichiers

Pour sécuriser de façon efficace le système de fichiers Windows 2000, la partition doit être formatée en NTFS. Avec les partitions NTFS, des autorisations locales peuvent être définies sur des fichiers et des dossiers afin de spécifier quels groupes de sécurité ou utilisateurs peuvent y accéder. En outre, des autorisations peuvent être définies sur des partages de dossiers afin de limiter l'accès à partir du réseau.

Limiter les autorisations NTFS par défaut

Pour renforcer encore davantage le système de fichiers du serveur, des listes de contrôle d'accès plus strictes sont appliquées aux répertoires et fichiers communs à tous les serveurs de l'architecture Internet Data Center. Par exemple, les répertoires tels que SystemDrive incluent le groupe de sécurité Tout le monde avec des autorisations Contrôle total. Cette autorisation est supprimée à titre de précaution supplémentaire. L'application de listes de contrôle d'accès aux répertoires de tous les serveurs est un processus ennuyeux, sauf si le serveur peut être modifié à l'aide d'un script. Pour l'architecture Internet Data Center, l'utilitaire XcAcls inclus dans le Kit de ressources de Windows 2000 automatise la configuration des listes de contrôle d'accès sur chaque serveur. Les listes de contrôle d'accès de fichiers peuvent également être appliquées par l'intermédiaire de stratégies de groupe, mais l'héritage doit être pris en considération lors de la conception de la stratégie. Le modèle hautement sécurisé (hisec.inf) constitue un bon exemple de définition des autorisations de fichiers.

Voici quelques règles pour l'attribution d'autorisations NTFS :

• Utilisez des autorisations NTFS pour contrôler l'accès aux fichiers et aux dossiers.

• Affectez des autorisations aux groupes plutôt qu'aux utilisateurs individuels.

• Les autorisations de fichiers NTFS sont prioritaires par rapport aux autorisations de fichiers NTFS.

• Les administrateurs et le propriétaire d'un fichier ou d'un dossier contrôlent les autorisations qui peuvent être configurées.

• Lors de la modification des autorisations des dossiers, tenez compte des applications installées sur les serveurs. Les applications créent leurs propres dossiers pour lesquels l'autorisation Permettre aux autorisations pouvant être héritées du parent d'être propagées à cet objet est activée. Si des autorisations sont modifiées dans le dossier parent, ces modifications peuvent provoquer des problèmes dans l'application.

Suppression des partages de dossiers Administrateur par défaut sur les serveurs de la zone DMZ

Lors de la construction d'un nouveau serveur, des partages Administrateur masqués sont automatiquement créés par défaut pour chaque répertoire racine de chaque volume (nommés C$, D$, E$, etc.) et pour le dossier racine du système (C:\Winnt, nommé Admin$). Ces partages disposent par défaut d'autorisations Contrôle total et sont affectés au groupe Administrateurs.

Bien que ces dossiers soient sécurisés via le groupe Administrateur, les partages des serveurs Microsoft IIS et des autres serveurs présentant des connexions exposées à Internet sont supprimés à titre de mesure de sécurité supplémentaire, afin d'éviter toute utilisation abusive du compte Administrateur.

Sécurisation de comptes

Windows 2000 prend en charge trois types de comptes : les comptes de domaine d'entreprise, les comptes de domaine et les comptes de serveur locaux.
Les comptes de domaine d'entreprise et les comptes de domaine permettent à l'utilisateur d'accéder aux ressources réseau sur n'importe quel serveur de tout le domaine. Les comptes locaux permettent à l'utilisateur d'accéder aux ressources qui sont uniquement disponibles sur ce serveur.

En outre, Windows 2000 offre des comptes utilisateur intégrés. Les comptes intégrés ne peuvent pas être supprimés, mais ils peuvent être renommés. Les deux comptes intégrés les plus connus de Windows 2000 sont les comptes Administrateur et Invité. Par défaut, le compte Invité est désactivé à la fois sur les contrôleurs de domaine et sur les serveurs membres.

Voici quelques méthodes recommandées pour le traitement des comptes du domaine :

• Créez des groupes globaux pour chaque type de fonction requise dans le domaine. Par exemple, affectez des administrateurs de gestion au groupe global Gestion. Pour chacun des groupes globaux, créez les groupes locaux correspondants, puis ajoutez les groupes globaux à ces groupes locaux. Accordez ensuite les autorisations appropriées aux groupes locaux
  du domaine.

• Créez des comptes utilisateur distincts pour chaque utilisateur. Ne partagez pas les comptes entre utilisateurs. Assurez-vous que les comptes sont affectés à un groupe global. Activez l'audit de sorte que les comptes utilisateur puissent faire l'objet d'un suivi dans l'ensemble du domaine.

• Utilisez des mots de passe renforcés pour chaque compte utilisateur ; afin de rendre encore plus difficiles les attaques de mot de passe, utilisez des mots de passe de 15 caractères.

• N'utilisez pas le même mot de passe pour le compte administrateur local sur tous les serveurs membres du domaine. Le mot de passe du compte administrateur du serveur IIS doit être différent du mot de passe de l'administrateur local de l'ordinateur SQL Server. Le mot de passe de l'administrateur du domaine doit être différent de tous les mots de passe des administrateurs des serveurs membres.

Sécurisation du compte Administrateur local sur les serveurs membres

Chaque serveur membre Windows 2000 comporte sa propre base de données SAM locale. Les deux comptes utilisateur, Administrateur et Invité, sont créés sous forme de comptes intégrés sur chaque serveur. Windows 2000 désactive le compte Invité par défaut, ce qui réduit le risque associé à l'accès invité tant que ce compte reste désactivé. Cependant, le compte Administrateur constitue une cible potentielle pour les intrus.

Dans l'architecture Internet Data Center, les modifications suivantes sont apportées au compte Administrateur local afin de le protéger contre les attaques à distance :

• Le compte Administrateur est renommé et la description du nouveau compte est modifiée afin de rendre son accès plus difficile pour les pirates. Même lorsque le compte est renommé, certains outils de piratage parviennent quand même à identifier le nouveau compte administrateur en déterminant l'identificateur de sécurité (SID, Security Identifier). Le SID du compte Administrateur intégré se termine toujours par 500, qu'il ait été renommé ou non. Ainsi, afin de protéger le serveur contre la localisation du SID, le paramètre de stratégie de sécurité Restrictions supplémentaires pour les connexions anonymes est défini sur Aucun accès sans autorisation explicite.

• Un nouveau compte Administrateur factice, que personne n'utilisera, est créé. Ce compte est doté d'un minimum d'autorisations et de droits sur le serveur.

• Le compte Administrateur factice se voit refuser le droit utilisateur Accéder à cet ordinateur depuis le réseau. Par conséquent, les pirates ne peuvent pas ouvrir une session sur le serveur, même s'ils découvrent le mot de passe administrateur.

Sécurisation du compte Administrateur du domaine

Sur les serveurs membres, le compte Administrateur peut être renommé. Dans Active Directory, le compte Administrateur du domaine (qui se trouve sur les contrôleurs de domaine) peut être copié tout en conservant les autorisations par défaut qui ont été appliquées au compte intégré lors de la création du domaine.

Pour protéger l'architecture Internet Data Center des attaques distantes, les modifications suivantes sont apportées au compte Administrateur du domaine :

• À l'aide de Utilisateurs et ordinateurs Active Directory, le compte Administrateur est copié sur un nouveau compte sous un nouveau nom qui sera utilisé en production.

• Les autorisations du compte Administrateur existant du domaine sont supprimées.

Audit de l'accès aux comptes

Un bon moyen de contrôler l'activité des comptes consiste à détecter les événements d'ouverture de session infructueuse pouvant être provoqués par un mot de passe erroné ou les événements qui signalent que le compte a été verrouillé. Par exemple, si l'ID d'événement 529 apparaît dans le journal de sécurité lorsqu'un compte ne parvient pas à ouvrir une session, cela peut indiquer une attaque initiale par un intrus qui essaie de trafiquer le compte. Si l'ID d'événement 539 apparaît après l'ID 529, cela signifie que le compte trafiqué est verrouillé pendant 30 minutes parce que l'intrus a fait cinq tentatives infructueuses. Toute ouverture de session réussie pour le compte Administrateur affiche l'ID d'événement 528, ce qui peut signifier qu'une intrusion a réussi ou qu'un administrateur viole la stratégie en n'utilisant pas le compte qui lui a été attribué.

Le tableau suivant répertorie certains ID d'événement essentiels qui doivent être contrôlés sur tous les serveurs. Pour plus d'informations sur les ID d'événement qui doivent être contrôlés, consultez l'article Q174073, "Auditing User Authentication (Audit de l'authentification des utilisateurs)", dans la Base de connaissance Microsoft.

ID
d'événement

Description

514

Un package d'authentification a été chargé par le LSA

515

Un processus d'ouverture de session approuvée s'est inscrit auprès du LSA

518

Un package d'authentification a été chargé par le Gestionnaire de compte de sécurité

528

Ouverture de session réussie

529

Échec d'ouverture de session : nom d'utilisateur inconnu ou mot de passe incorrect

530

Échec d'ouverture de session : violation de la restriction de durée d'ouverture de session d'un compte

531

Échec d'ouverture de session : compte actuellement désactivé

532

Échec d'ouverture de session : le compte utilisateur spécifié a expiré

533

Échec d'ouverture de session : l'utilisateur n'est pas autorisé à ouvrir une session sur cet ordinateur

534

Échec d'ouverture de session : l'utilisateur n'a pas reçu l'autorisation pour ce type d'ouverture de session sur cet ordinateur

535

Échec d'ouverture de session : le mot de passe du compte spécifié a expiré

536

Échec d'ouverture de session : le composant NetLogon n'est pas actif

537

Échec d'ouverture de session : une erreur inattendue s'est produite lors de l'ouverture de session

538

Déconnexion de l'utilisateur

539

Échec d'ouverture de session : compte verrouillé

644

Compte utilisateur verrouillé

Désactivation de services

Lors de la construction initiale de Windows 2000 Server, des services par défaut sont créés et configurés pour s'exécuter au démarrage du système. Certains de ces services présentent des risques de piratage et ne sont pas indispensables dans l'architecture Internet Data Center. Des services tels que le service d'exploration annoncent les autres serveurs du réseau et n'ont pas besoin de s'exécuter dans le domaine. Nombre de ces services sont toujours utilisés pour la compatibilité descendante avec les ordinateurs Windows NT Server 4.0.

Par exemple, voici quelques-uns des services qui doivent être évalués et éventuellement désactivés :

• Alertes

• Album

• Explorateur d'ordinateur (utilisez plutôt Active Directory Share Publishing)

• Service client DHCP (Dynamic Host Configuration Protocol)

• Fax

• Partage de connexion Internet (ICS, Internet Connection Sharing)

• Service Messenger

• Logiciel de conférence Microsoft NetMeeting®

• Spouleur d'impression

• Registre à distance (vous pouvez activer temporairement ce service pour installer des applications à distance, comme par exemple Backup Exec)

• Planificateur de tâches

• Telnet

Cette liste détaille les services dont l'exécution n'est généralement pas indispensable sur un serveur IIS sécurisé. La configuration particulière de votre réseau ou de votre système peut contenir des services ou exigences supplémentaires, qui devront être évaluées de façon individuelle.

Détection des ports à l'écoute

Il est important de comprendre quels ports d'application TCP et UDP les serveurs écoutent à un instant donné. Il s'agit des ports auxquels un pirate tentera de se connecter et qui sont ouverts sur l'interface du serveur. Une fois les services désactivés sur le serveur, la commande netstat peut être exécutée pour déterminer sur quels ports le serveur est toujours à l'écoute ; netstat fournit les informations pour chaque carte réseau. Les deux tableaux suivants donnent un exemple du résultat de deux commandes netstat, une pour les ports TCP, l'autre pour les ports UDP.
Le serveur de ces tableaux écoute sur plusieurs ports ainsi que sur les différentes cartes réseau répertoriées dans la colonne Adresse locale. Les adresses qui s'affichent sous la forme 0.0.0.0 signifient que le serveur répond au port sur toutes les interfaces. Par exemple, 0.0.0.0:135 signifie que le serveur Windows 2000 répond aux demandes de mappage de port RPC sur toutes les interfaces.

Le tableau suivant illustre un exemple de sortie de la commande netstat -an -p TCP, pour les ports TCP actifs.

Protocole

Adresse locale         

Adresse externe       

État

TCP

0.0.0.0:135           

0.0.0.0:0             

LISTENING

TCP

0.0.0.0:445           

0.0.0.0:0             

LISTENING

TCP

0.0.0.0:1025          

0.0.0.0:0             

LISTENING

TCP

0.0.0.0:1720          

0.0.0.0:0             

LISTENING

TCP

0.0.0.0:3001          

0.0.0.0:0             

LISTENING

TCP

0.0.0.0:3002          

0.0.0.0:0             

LISTENING

TCP

127.0.0.1:80          

0.0.0.0:0             

LISTENING

TCP

127.0.0.1:11223       

0.0.0.0:0             

LISTENING

TCP

192.168.1.10:25       

0.0.0.0:0             

LISTENING

TCP

192.168.1.10:80       

0.0.0.0:0             

LISTENING

TCP

192.168.100.10:1080   

0.0.0.0:0             

LISTENING

TCP

192.168.100.10:3500   

0.0.0.0:0             

LISTENING

TCP

192.168.100.10:3504   

0.0.0.0:0             

LISTENING

Le tableau suivant illustre un exemple de sortie de la commande netstat -an -p UDP, pour les ports UDP actifs.

Protocole 

Adresse locale          

Adresse externe       

UDP

0.0.0.0:445           

*:*

UDP

192.168.1.10:53       

*:*

UDP

192.168.1.10:500      

*:*

UDP

192.168.1.50:500      

*:*

UDP

192.168.1.51:500      

*:*

UDP

192.168.100.10:500    

*:*

UDP

192.168.100.10:1745    

*:*

UDP

192.168.100.10:3007   

*:*

Méthodes recommandées pour la sécurité des applications

Lors de la planification de la sécurité IIS, il est essentiel de s'assurer que les applications n'introduisent pas des risques en termes de sécurité. La section suivante met en évidence certains exemples de méthodes recommandées par MCS (Microsoft Consulting Services) en termes de sécurité des applications.

Validation des applications Web

MCS conseille de sécuriser la validation des applications Web à partir des recommandations suivantes :

• Utilisez un cryptage approprié, tel que SSL.

• Vérifiez que le code source HTML ne comporte pas d'informations confidentielles sous forme de champs masqués dans des formulaires.

• Vérifiez que les cookies ne contiennent aucune information sensible.

• Procédez aux vérifications d'erreur et de validation appropriées.

• Vérifiez que les informations ne sont pas envoyées à l'aide d'une méthode GET.

• Vérifiez que des arguments inhabituels ou arbitraires ne puissent pas être utilisés pour endommager les données, ralentir ou arrêter le système, lancer des applications non autorisées ou procéder à d'autres activités non autorisées.

• Vérifiez que les packages de vérification d'erreur n'exposent pas les vulnérabilités des applications.

• Évaluez la sécurité basée sur les rôles pour les composants COM+.

Développement d'applications Web

MCS dispose également d'un ensemble de méthodes recommandées pour le développement d'applications Web. Il s'agit notamment de déterminer si l'application Web :

• Utilise les fonctionnalités de sécurité intégrées au système d'exploitation. Cela signifie qu'il est préférable de laisser le système d'exploitation traiter les procédures, comme par exemple la vérification des noms d'utilisateur et des mots de passe, le cryptage et le contrôle d'accès. Il serait difficile pour une quelconque application d'atteindre les performances ou la sécurité du système d'exploitation en termes de traitement des noms d'utilisateur et des mots de passe.

• Effectue des contrôles de validation à chaque niveau. L'application ne doit pas supposer que l'authentification réussie au niveau du serveur Web signifie que l'authentification n'est plus nécessaire au niveau intermédiaire et au niveau des données. L'application doit effectuer une validation à chaque niveau.

• Effectue des contrôles de validation lors de chaque accès. L'application ne doit pas considérer qu'une fois la validation réussie, tous les accès sont autorisés.

• Dispose d'une méthode d'identification et de différenciation entre les sessions utilisateur spécifiques. Un utilisateur ou toute autre personne ne doit pas pouvoir réexécuter une session et accéder au système.

• Permet le transfert sur le réseau de mots de passe non cryptés. L'application ne doit pas autoriser la circulation des mots de passe non cryptés sur le réseau.

• Manipule un mot de passe. L'application ne doit pas stocker le mot de passe décrypté.

• Traite les changements de mot de passe. L'application doit imposer certaines restrictions de mot de passe en termes de longueur, de période de réutilisation et de difficulté (comme par exemple un mot de passe différent du nom d'utilisateur). En outre, le compte doit être verrouillé après un nombre défini de tentatives de connexion infructueuses. Cela permet d'empêcher quelqu'un d'utiliser un outil de détection de mot de passe pour tenter d'accéder de façon répétée au compte d'un utilisateur, jusqu'à y parvenir.

• Répète les informations qui sont saisies ; l'application doit offrir une protection contre les attaques de script par site croisé. Pour plus d'informations sur les scripts par site croisé, consultez le site TechNet Security 

• Limite l'accès aux objets de base de données aux seuls utilisateurs ou rôles qui nécessitent un accès au système. N'accordez pas d'accès public à une quelconque table ou procédure stockée. Cela peut prendre du temps et nécessiter des tests, mais cette étape est essentielle.

• Définit les autorisations des fichiers et des dossiers sur le minimum requis pour accéder à l'application. N'accordez pas d'accès de type Tout le monde, Utilisateurs ou Utilisateurs du domaine aux fichiers et aux dossiers.

• Dispose d'une logique codée dans des objets intermédiaires et non dans le code ASP. Des failles dans la sécurité ont autorisé l'accès au code source des pages ASP. Il est nécessaire d'envisager de rendre public tout ce qui est écrit dans les scripts ASP.

• Autorise les requêtes SQL écrites par les utilisateurs ; aucune ne doit être autorisée. Certaines exploitations de code SQL spécifique ont permis à des utilisateurs mal intentionnés d'exécuter des opérations nécessitant des privilèges.

• Stocke des informations utiles dans des champs masqués. Aucune information utile ne doit être stockée dans des balises masquées. Si des informations utiles sont stockées dans une balise masquée, un utilisateur malveillant peut modifier la valeur de la balise avant de renvoyer la page vers le serveur.

• Stocke des informations utiles dans des cookies. Si des informations utiles sont stockées dans un cookie, un utilisateur malveillant peut modifier les valeurs du cookie avant de renvoyer la page vers le serveur.

• Force les pages à ne pas être mises en cache et impose l'expiration des pages du cache. 

• Vérifie la saisie <FORM> et Querystring dans le code ASP. Nombre de sites font appel à la saisie utilisateur pour appeler d'autre code ou créer des instructions SQL directement. En d'autres termes, ils traitent l'entrée comme étant valable, au bon format et non malveillante. Cela est une erreur, car il existe de nombreuses attaques au cours desquelles la saisie utilisateur est considérée à tort comme étant valable et l'utilisateur peut en conséquence accéder en toute impunité au serveur ou provoquer des dégâts. Vous devez donc vérifier toutes les saisies <FORM> et les chaînes de requête avant de les transmettre à d'autres processus ou appels de méthodes qui pourraient recourir à des ressources extérieures telles que le système de fichiers ou une base de données.

Vous pouvez procéder à la vérification du texte à l'aide des fonctionnalités d'expression valide du logiciel de développement Microsoft JScript® 5 et du système de développement Microsoft Visual Basic® Scripting Edition (VBScript) 5. L'exemple de code suivant est destiné à éliminer tous les caractères non valables d'une chaîne (à savoir, les caractères autres que 0-9,
a-z, A-Z ou _) :

Set reg = New RegExp
reg.Pattern = "\W+" ' One or more characters which
' are NOT 0-9a-zA-Z or '_'
strUnTainted = reg.Replace(strTainted, "")

L'exemple de code suivant est destiné à éliminer tout le texte situé après un opérateur binaire OU (|) :

Set reg = New RegExp
reg.Pattern = "^(.+)\|(.+)" ' Any character from the start of
' the string to a | character.
strUnTainted = reg.Replace(strTainted, "$1")

Soyez prudent lorsque vous ouvrez ou créez des fichiers à l'aide du composant Scripting File System Object. Si le nom de fichier s'appuie sur la saisie utilisateur, ce dernier peut tenter d'ouvrir un port série ou une imprimante. Le code JScript suivant supprime les noms de fichiers non valides :

var strOut = strIn.replace(/(AUX|PRN|NUL|COM\d|LPT\d)+\s*$/i,"");

La syntaxe du modèle des moteurs de script de la version 5 est la même que celle de Perl 5.0. Vous trouverez davantage d'informations sur les technologies Windows Script  sur MSDN.

Vous trouverez en outre des exemples 

Méthodes recommandées pour la sécurité SQL Server 2000

La sécurisation des données d'un serveur de base de données est essentielle, car la base de données stocke des données sensibles, telles que les numéros de carte bancaire ou les mots de passe des utilisateurs. Cette section n'a pas pour vocation d'être un nouveau guide de la sécurité de SQL Server 2000 ; elle se base sur les méthodes recommandées (avec des explications) pour l'implémentation de la sécurité des bases de données SQL Server dans un environnement de domaine Microsoft Windows 2000. Pour en savoir plus sur les opérations de sécurité de SQL Server, consultez SQL Server Books Online.

Les sections suivantes détaillent certaines techniques utilisées pour renforcer la sécurité de SQL Server 2000 dans l'architecture Internet Data Center.

Mode d'authentification

Microsoft SQL Server peut opérer dans un des deux modes de sécurité (d'authentification) suivants :

• Mode d'authentification Windows (Windows Authentication)

• Mode mixte (Windows Authentication et SQL Server Authentication)

Le mode mixte permet aux utilisateurs de se connecter via Windows Authentication ou SQL Server Authentication.

Le mode Windows Authentication est plus sûr que le mode SQL Server Authentication (mode mixte). SQL Server Authentication est fourni pour assurer la compatibilité descendante lorsque SQL Server 2000 est installé sur les systèmes d'exploitation Windows 98 ou Windows Millennium Edition. Microsoft recommande la configuration de SQL Server 2000 avec le mode Windows Authentication afin d'offrir le niveau de sécurité le plus élevé (configuration par défaut).

Le mode Windows Authentication est étroitement intégré à Windows 2000 et tire parti des puissantes méthodes d'authentification fournies par le système d'exploitation. Il est extrêmement sûr, et les noms d'utilisateur et mots de passe ne sont pas transmis sur le réseau ; il peut même utiliser l'authentification Kerberos pour déléguer l'authentification SQL Server.

Compte administrateur système

Microsoft recommande que tous les administrateurs de SQL Server aient accès à SQL Server grâce à leur appartenance à un groupe Windows, et que ce même groupe soit membre du rôle de serveur sysadmin. Cependant, gardez à l'esprit que les administrateurs Windows peuvent accorder à n'importe qui des autorisations sysadmin sur SQL Server 2000, car ils peuvent ajouter n'importe quel utilisateur au groupe Windows approprié.

Si un site n'est pas conçu pour permettre aux administrateurs Windows d'attribuer un accès sysadmin à SQL Server, seuls des comptes Windows individuels peuvent se voir attribuer le rôle sysadmin.

Quoi qu'il en soit, il est vivement recommandé de ne pas utiliser le compte sysadmin pour l'administration quotidienne. Vous devez affecter un mot de passe au compte ; ce mot de passe doit être difficile à deviner et doit être mis en sécurité afin qu'il ne soit accessible qu'en cas d'urgence.

Si SQL Server 2000 s'exécute avec le mode Windows Authentication (ce qui est recommandé), le compte sysadmin ne peut pas être utilisé pour l'ouverture de session, car seules les connexions approuvées (telles que celles authentifiées par Windows 2000) sont autorisées.

Remarque : Bien que le compte sysadmin ne puisse pas être utilisé pour ouvrir une session sur SQL Server 2000 en mode Windows Authentication, il est néanmoins important de spécifier un mot de passe pour ce compte. En effet, une simple modification du Registre peut faire passer le mode de sécurité Windows Authentication au mode mixte. Si le mot de passe sysadmin est vide (ce qui est le cas d'une installation par défaut), un intrus (ou l'administrateur Windows) peut accéder au serveur. Pour en savoir plus sur la méthode utilisée pour réduire les chances de succès d'une telle attaque, consultez la section "Considérations relatives au Registre", plus loin dans ce chapitre.

Considérations relatives au compte de service

SQL Server 2000 s'exécute comme trois services Windows : MSSQLServer,SQLServerAgent et Microsoft Search.

Les services SQL Server (MSSQLServer) et SQL Server Agent peuvent être configurés pour utiliser un compte système local, un compte utilisateur local ou un compte utilisateur de domaine. Les deux services peuvent être configurés pour utiliser le même compte si nécessaire. Le service Microsoft Search offre des capacités de recherche sur le texte intégral et doit toujours être configuré pour utiliser le compte système local. Le service que vous sélectionnez dépend de la fonctionnalité requise pour SQL Server 2000.

Le compte système local peut être utilisé si l'ordinateur qui exécute SQL Server n'est pas configuré pour la réplication et ne nécessite pas d'accès aux ressources du réseau.

Pour que SQL Server 2000 exécute ses tâches correctement, les autorisations suivantes doivent être accordées au compte système local (elles sont attribuées automatiquement par le programme d'installation) :

• Contrôle total sur le répertoire SQL Server (par défaut, \Program Files\Microsoft SQL Server\MSSQL)

• Contrôle total sur tous les fichiers de base de données all .mdf, .ndf et .ldf

• Contrôle total sur les clés (et sous-clés) de Registre suivantes :

  HKLM\Software\Microsoft\MSSQLServer

  HKLM\System\CurrentControlset\Services\MSSQLServer

• Contrôle total pour une instance nommée :

  HKLM\Software\Microsoft\Microsoft SQL Server\InstanceName

  HKLM\System\CurrentControlset\Services\MSSQL$InstanceName

• Le compte utilisateur local présente les mêmes exigences que le compte système local, à ceci près qu'il doit également être doté de l'autorisation Ouvrir une session en tant que service (cette autorisation est attribuée par défaut par le programme d'installation).

• L'option Compte utilisateur de domaine offre le niveau de flexibilité le plus élevé et réduit la surcharge administrative dans un environnement multiserveur. Voici quelques exemples des fonctionnalités disponibles lorsque seul un compte utilisateur de domaine est utilisé :

  • Réplication

  • Sauvegarde et restauration au moyen de lecteurs réseau

  • Jointures hétérogènes impliquant des sources de données distantes

  • Fonctionnalités de messagerie de SQL Server Agent et de SQL Mail

Système de fichiers

Windows fournit un excellent cadre de sécurité pour les objets du système d'exploitation, tels que les fichiers. Microsoft recommande l'application d'autorisations de fichiers NTFS aux données et aux fichiers journaux de toutes les bases de données. Le compte utilisateur que SQL Server 2000 doit utiliser doit disposer d'autorisations Contrôle total sur les fichiers de bases de données.

Tous les fichiers SQL Server 2000, y compris les fichiers exécutables et les bibliothèques de liaison dynamique (DDL, Dynamic-Link Libraries) doivent être configurés de sorte que les utilisateurs ne puissent pas les manipuler. Les autorisations sur ces fichiers doivent être configurées de façon à accorder au compte utilisateur utilisé par SQL Server, au groupe Administrateurs et aux comptes système locaux des autorisations Contrôle total. Aucune autre autorisation ne doit être accordée.

Remarque : Le programme d'installation de SQL Server 2000 accorde automatiquement aux comptes de service des autorisations Contrôle total sur les fichiers associés à SQL Server, ainsi que le contrôle total du groupe Administrateurs local.

Considérations relatives au Registre

Pour protéger l'installation SQL Server 2000 contre les attaques d'utilisateurs disposant de droits d'accès sur le serveur physique, il est conseillé de définir les autorisations Windows dans les clés de Registre qui sont utilisées pour configurer SQL Server 2000.

En particulier, toutes les clés sous HKLM\SOFTWARE\MICROSOFT\MSSQLSERVER (pour une instance par défaut) ou HKLM\SOFTWARE\MICROSOFT\MICROSOFT SQL SERVER\INSTANCENAME (pour une instance nommée) doivent être sécurisées. Les autorisations du groupe Tout le monde sur cette clé doivent être supprimées et des autorisations Contrôle total doivent être ajoutées au groupe Administrateurs, au compte système local et au compte de service SQL Server. Le programme d'installation fait cela automatiquement pour les comptes de service sélectionnés au cours du processus d'installation.

La configuration d'autorisations sur les clés de Registre est particulièrement importante si les administrateurs SQL Server souhaitent empêcher les administrateurs Windows d'accéder à l'ordinateur qui exécute SQL Server. Dans ce cas, les administrateurs SQL Server doivent également prendre possession de la clé de Registre et supprimer les autorisations accordées au groupe Administrateurs. Il est alors impératif que le compte de service SQL Server dispose des autorisations Contrôle total. Bien que cela n'empêche pas les administrateurs d'accéder au système, cela permet aux administrateurs SQL Server de savoir quand les administrateurs Windows ont pris des risques avec la sécurité. Les administrateurs peuvent toujours prendre possession, mais ils ne peuvent pas l'attribuer. Pour en savoir plus sur les administrateurs Windows qui accèdent à SQL Server, consultez la section "Compte administrateur système" plus haut dans ce chapitre.

Considérations relatives à l'audit

SQL Server 2000 permet d'auditer les ouvertures de session sur le serveur dans le journal des événements de Windows. Le niveau d'audit peut être configuré à l'aide de SQL Server Enterprise Manager ou de la procédure stockée étendue xp_loginconfig.

Les paramètres d'audit possibles sont les suivants :

• Aucun. Ce paramètre n'enregistre aucune information d'audit.

• Réussite. Ce paramètre n'enregistre que les ouvertures de session ayant abouti.

• Échec. Ce paramètre n'enregistre que les ouvertures de session ayant échoué.

• Tout. Ce paramètre enregistre à la fois les ouvertures de session ayant réussi et ayant échoué.

Microsoft recommande d'auditer au moins les échecs. Si les exigences en termes de sécurité sont très élevées, toutes les ouvertures de session doivent être auditées. Les informations d'audit sont enregistrées dans le journal des erreurs de SQL Server 2000.

Considérations relatives à la sauvegarde et à la restauration

Voici quelques-unes des considérations relatives à la sécurité pour les opérations de sauvegarde et de restauration (pour plus d'informations sur la stratégie de telles opérations, consultez SQL Server Books Online).

• Microsoft SQL Server sauvegarde les bases de données, les journaux de transactions et les fichiers sur des périphériques tels que des disques, des bandes ou des périphériques de canaux nommés. La sauvegarde doit être sécurisée par le contrôle de l'accès aux médias physiques ainsi que par l'utilisation de listes de contrôle d'accès Windows sur les partitions NTFS.

• Microsoft SQL Server 2000 prend en charge la protection par mot de passe pour les médias de sauvegarde et les jeux de sauvegarde. Les mots de passe ne sont pas indispensables pour procéder aux opérations de sauvegarde, mais ils offrent un niveau de sécurité supplémentaire. Ils peuvent être utilisés en plus des rôles de sécurité SQL Server. L'utilisation de la protection par mot de passe contribue à éviter la restauration non autorisée de bases de données, les ajouts sur les médias ou encore l'effacement accidentel des médias.

• La sécurité par mot de passe n'empêche pas l'écrasement du média par formatage ou son utilisation comme volume de continuation. En outre, le fait de spécifier un mot de passe ne crypte aucunement les données.

• Des mots de passe peuvent être utilisés pour les jeux de médias ou les jeux
  de sauvegarde.

• Les mots de passe de jeux de médias protègent toutes les données enregistrées sur ce média. Le mot de passe du jeu de médias est défini lors de l'écriture de l'en-tête du média et ne peut plus être modifié. Si un mot de passe est défini pour le jeu de médias, il doit être fourni pour toute opération d'ajout ou de restauration.

• Le média ne doit être utilisé que pour les opérations de sauvegarde et de restauration SQL Server. Le fait de spécifier un mot de passe pour le jeu de médias empêche toute sauvegarde Microsoft Windows NT 4.0 ou Windows 2000 de partager le média.

• Les mots de passe de jeux de sauvegarde ne protègent qu'un jeu particulier.
  Des mots de passe de jeux de sauvegarde différents peuvent être utilisés pour chaque jeu de sauvegarde du média. Un mot de passe de jeu de sauvegarde est défini lors de l'écriture du jeu sur le média. Si un mot de passe est défini pour le jeu de sauvegarde, il doit être fourni pour toute opération de restauration.

Compte Invité Windows

Lors de l'exécution de SQL Server 2000 en mode Windows Authentication, le serveur s'appuie sur Windows pour procéder à toute authentification des clients. L'utilisation du compte Invité Windows constitue une menace pour la sécurité. Il est vivement recommandé de désactiver le compte Invité.

Le compte Invité peut s'avérer nécessaire si une application ne prend pas en charge Windows Authentication et doit transmettre des noms d'utilisateur et des mots de passe via le réseau. Cette solution n'est toutefois pas aussi sûre que la désactivation ; elle doit donc être évitée dans la mesure du possible.

Considérations relatives à l'accès physique

Il est recommandé de limiter l'accès physique au système dès lors que cela est possible. L'un des risques de l'accès physique non autorisé est la possibilité pour un intrus de démarrer le serveur à partir d'une disquette et d'accéder au système de fichiers Windows NT. Vos serveurs de bases de données essentiels ainsi que les médias de sauvegarde doivent être physiquement sécurisés.

Utilisation d'alias

Dans les versions de SQL Server antérieures à la version 7.0, un alias permet à un utilisateur d'usurper de façon temporaire l'identité d'un autre utilisateur dans une base de données, afin d'effectuer des actions au nom de cet autre utilisateur. Par exemple, le propriétaire d'une base de données peut se faire passer pour un autre utilisateur lorsque celui-ci est absent, par exemple lorsqu'il est en congé.

Les rôles ont remplacé les alias dans SQL Server version 7.0 et SQL Server 2000. Dans la mesure où un utilisateur peut appartenir à plusieurs rôles en même temps, il n'est plus nécessaire d'usurper l'identité d'un autre utilisateur. Les utilisateurs appartenant aux mêmes rôles se voient automatiquement attribuer les mêmes autorisations, en supposant que les autorisations ne sont appliquées qu'au niveau du rôle et non au niveau de l'utilisateur.

SQL Server 2000 prend en charge l'utilisation d'alias pour des comptes utilisateur dans une base de données, à des fins de compatibilité descendante. Cela n'est toutefois pas recommandé. Microsoft recommande l'utilisation des rôles. Ils sont plus puissants et apportent des fonctionnalités identiques à celles des alias.

Délégation et Kerberos

Kerberos est le principal mécanisme d'authentification des réseaux Windows 2000. La délégation fait référence à la possibilité de transférer des informations d'identification de sécurité entre plusieurs ordinateurs et applications. Lors de chaque saut entre ordinateurs, les informations d'identification de l'utilisateur sont conservées. SQL Server 2000 prend totalement en charge le protocole Kerberos, y compris la possibilité d'accepter des tickets Kerberos délégués et de déléguer ensuite ces tickets (sous le système d'exploitation Microsoft Windows 2000) à des contrôleurs de domaine Windows 2000 et Active Directory. Cette fonctionnalité offre davantage de sécurité est n'est pas disponible avec les systèmes d'exploitation Windows NT version 4.0 ou antérieurs.

Pour que la délégation fonctionne, les options suivantes doivent être configurées dans Active Directory :

• Le compte est sensible et ne peut pas être délégué. Cette option ne doit pas être sélectionnée pour l'utilisateur qui demande la délégation.

• Le compte est approuvé pour la délégation. Cette option doit être sélectionnée pour le compte de service de SQL Server.

• L'ordinateur est approuvé pour la délégation. Cette option doit être sélectionnée pour le serveur qui exécute une instance de Microsoft SQL Server.

Pour utiliser la délégation d'un compte de sécurité, SQL Server doit posséder un nom principal de service (SPN, Service Principal Name), lequel est attribué par l'administrateur de domaine du compte Windows 2000.

Le SPN doit être affecté au compte de service du service SQL Server sur cet ordinateur particulier. La délégation impose l'authentification mutuelle. Le SPN est nécessaire pour prouver que SQL Server a été vérifié sur ce serveur particulier, à l'adresse de socket particulière, par l'administrateur de domaine du compte Windows 2000. Vous pouvez demander à votre administrateur de domaine d'établir un SPN pour SQL Server avec l'utilitaire Setspn, lequel est inclus dans le Kit de ressources de Windows 2000.

Utilisez la commande suivante pour créer un SPN pour SQL Server :

setspn -A MSSQLSvc/Host:port serviceaccount

Pour activer la délégation, vous devez utiliser TCP/IP. Vous ne pouvez pas utiliser des canaux nommés, car le SPN cible un socket TCP/IP particulier. Si vous utilisez plusieurs ports, vous devez disposer d'un SPN pour chaque port.

La délégation peut être activée via l'exécution sous le compte LocalSystem. SQL Server s'inscrit automatiquement au démarrage du service et inscrit automatiquement le SPN. Cette option est plus simple que d'activer la délégation à l'aide d'un compte utilisateur de domaine. Cependant, lorsque SQL Server est arrêté, les SPN sont désinscrits pour le compte LocalSystem.

Utilisez la commande suivante pour activer la délégation sous le compte LocalSystem :

setspn -A MSSQLSvc/Host:port serviceaccount

Cryptage du trafic réseau

SQL Server 2000 prend en charge le cryptage des données et tout autre trafic réseau acheminé entre les systèmes client et serveur d'un réseau. La puissance de cryptage dépend des possibilités de cryptage autorisées par le certificat installé pour SQL Server ainsi que par les fonctionnalités de cryptage du client et du serveur.

Le certificat sélectionné pour SQL Server doit se voir attribuer le nom du serveur sous la forme du nom DNS pleinement qualifié du serveur ; par exemple, SQLServer1.Redmond.Microsoft.com. Le certificat doit être valide pour l'authentification par le serveur. Le processus implique l'ouverture de session sur SQL Server sous le compte de service SQL Server, l'obtention du certificat (d'une autorité de certification interne ou d'un fournisseur tiers approuvé), puis son installation sur le serveur dans l'emplacement suggéré lors de l'importation du certificat.

Système de fichiers de cryptage

SQL Server 2000 fonctionne correctement sous Windows 2000 lors de la protection des fichiers de données avec le système de fichiers de cryptage (EFS, Encrypting File System) intégré au système d'exploitation. La documentation Windows 2000 inclut des informations détaillées sur les opérations EFS. Les fichiers doivent être cryptés à l'aide du compte de service de SQL Server.

Pour changer le compte de service, décryptez les fichiers, changez le compte de service des services SQL Server, puis recryptez les fichiers avec le nouveau compte de service. Si cette opération n'est pas effectuée, SQL Server risque de ne pas pouvoir démarrer, car il ne pourra pas décrypter les fichiers qui ont été cryptés avec les informations d'identification du précédent compte de service.

L'utilisation du système EFS offre davantage de sécurité, tout en ajoutant cependant une surcharge pour le processus de cryptage et de décryptage. Pour réduire la surcharge, le système EFS ne doit être utilisé que pour les fichiers de données essentiels.

Authentification

La popularité d'Internet a modifié pour toujours la façon dont les personnes accèdent aux informations et effectuent leurs transactions professionnelles. La principale fonction d'un site Web est de déterminer qui peut accéder à quelles informations ; cette section étudie les choix disponibles lors de la conception d'un site Web à l'aide de produits et de technologies Microsoft. Une question essentielle est de déterminer si les informations d'identification des utilisateurs, telles que les noms d'utilisateur et les mots de passe, seront stockées dans Active Directory ou SQL Server. La détermination de l'emplacement de stockage des informations d'identification est importante, car elle dicte les choix disponibles lors de l'accès aux informations d'identification et a des conséquences sur les performances et l'évolutivité.

L'authentification est le processus de vérification des informations d'identification de l'utilisateur, comme par exemple le nom d'utilisateur et le mot de passe ; ces informations sont souvent recueillies lors de l'ouverture de session. Le site Web examine ensuite l'ID utilisateur par rapport à toute information à laquelle l'utilisateur tente d'accéder, afin de déterminer si l'accès doit être accordé ou refusé. Ce processus est appelé autorisation ou contrôle d'accès.

Cette section décrit les méthodes d'authentification et de contrôle d'accès qui peuvent être utilisées lors de la conception d'un site Web. Chaque méthode est étudiée quant à son fonctionnement et à son impact sur les performances, l'évolutivité et la sécurité. Nous proposons également des recommandations sur l'opportunité d'utiliser chaque méthode.

Concepts de sécurité

Avant d'étudier les méthodes recommandées pour l'authentification, il est important de jeter un œil aux principaux concepts de sécurité. En particulier, il est important de comprendre l'authentification, l'autorisation, les identificateurs de sécurité, ainsi que l'utilisation des listes de contrôle d'accès et de l'usurpation d'identité.

 Authentification

L'authentification est le processus qui consiste à vérifier qu'un utilisateur est bien celui qu'il prétend être. L'authentification nécessite des preuves sous la forme d'informations d'identification. La preuve peut être apportée par un ou plusieurs des moyens suivants :

• paire nom d'utilisateur/mot de passe ;

• carte à puce ou certificat ;

• biométrie.

L'authentification est un processus de type vrai ou faux ; si un visiteur du site Web fournit les informations d'identification correctes, son identité est approuvée, que le visiteur soit ou non la personne qu'il prétend être. Sur un site Web qui ne vérifie que les noms d'utilisateur et les mots de passe, toute personne qui fournit la paire nom d'utilisateur/mot de passe correcte se voit accorder l'accès, même s'il n'est pas l'utilisateur qu'il prétend être.

L'authentification peut être effectuée au niveau du serveur IIS dans la zone DMZ, au niveau du serveur d'application COM+ dans le réseau VLAN de l'infrastructure, ou encore au niveau des bases de données SQL Server 2000 du réseau VLAN de données et de gestion. En général, le serveur IIS authentifie les utilisateurs Web, les serveurs COM+ authentifient le processus d'appel et les serveurs de base de données authentifient les processus qui s'y connectent. Il est important de se rappeler que l'authentification est coûteuse et que trop d'authentification ralentit le temps de réponse du serveur Web.

Microsoft prend en charge les technologies d'authentification suivantes sur IIS 5.0 :

• Kerberos. La prise en charge du schéma d'authentification Kerberos est intégrée au système d'exploitation Microsoft Windows 2000.

• Windows NTLM. Il s'agit du protocole par défaut de Microsoft Windows NT, inclus dans Windows 2000 pour la compatibilité descendante. Il est également appelé authentification Stimulation/Réponse de Windows NT.

• De base. L'authentification de base fait partie de la spécification HTTP 1.0 prise en charge par la plupart des serveurs Web et navigateurs Web. Elle n'est pas sécurisée, car les mots de passe ne sont pas cryptés. Toutes les versions de Microsoft IIS prennent en charge l'authentification de base.

• Digest. L'authentification Digest fait partie de la spécification HTTP 1.1 et résout nombre des failles de sécurité de l'authentification de base. IIS 5.0 prend en charge l'authentification Digest.

L'authentification est expliquée en détail plus loin dans ce chapitre.

Autorisation

Une fois son identité authentifiée, l'utilisateur Web souhaite accéder aux ressources, telles que les fichiers et les enregistrements de base de données. L'accès est déterminé en vérifiant que l'utilisateur Web a accès à la ressource demandée.

Pour cela, les informations relatives à l'utilisateur (ou parfois au compte utilisateur proxy) sont comparées aux informations de contrôle d'accès associées à la ressource. Les mécanismes d'autorisation sont les suivants :

• Listes de contrôle d'accès Windows 2000. Une liste de contrôle d'accès décrit les possibilités (comme par exemple la lecture, l'écriture ou l'exécution) dont un compte utilisateur dispose sur un fichier.

• Vérification des rôles dans un composant COM+. Lorsqu'une application exécute des tâches suite à une demande de l'utilisateur, ces tâches sont exécutées sous l'entité de sécurité de l'utilisateur (compte utilisateur Windows 2000) ou sous un compte utilisateur préconfiguré. L'application COM+ utilise ensuite la vérification des rôles afin de déterminer si l'accès est autorisé. Il arrive que l'accès utilisateur soit représenté par un composant qui s'exécute sous un compte utilisateur proxy. Un groupe d'utilisateurs peut être mappé sur un compte utilisateur unique afin d'accéder aux informations.
  Ce modèle permet un meilleur partage de connexion et peut améliorer les performances.

Par exemple, lors de l'utilisation de Commerce Server 2000, les utilisateurs peuvent être authentifiés par rapport à une base de données SQL Server, puis accéder aux ressources à l'aide d'un compte utilisateur proxy. Commerce Server 2000 peut également être configuré pour utiliser un compte utilisateur dans Active Directory, de sorte que chaque accès soit vérifié par rapport à ce compte utilisateur spécifique. Commerce Server 2000 inclut un groupe de composants COM+ aux performances élevées pour les activités telles que la sélection de contenu et la gestion des profils utilisateur.

Identificateurs de sécurité (SID, Security Identifier)

Tous les noms d'utilisateur et noms de groupes sont des étiquettes affectées aux objets Active Directory afin d'offrir aux utilisateurs et aux administrateurs une méthode d'authentification simple. En interne, le système d'exploitation fait référence à chaque objet Active Directory par l'intermédiaire d'un numéro qui identifie cet objet de façon unique. Chaque objet se voit attribuer un SID unique lors de sa création. Si un compte utilisateur est supprimé, puis qu'un autre compte est créé avec le même nom, le nouveau compte ne comportera pas le même SID que le compte d'origine ; ainsi, les droits ou autorisations accordés à l'ancien compte ne s'appliqueront pas.

Liste de contrôle d'accès (ACL, Access Control List)

Windows 2000 protège les ressources sécurisables contre les accès non autorisés en utilisant le contrôle d'accès discrétionnaire, lequel est implémenté par l'intermédiaire de listes de contrôle d'accès discrétionnaire (DACL, Discretionary Access Control Lists). Les DACL, généralement abrégées en ACL, sont une suite d'entrées de contrôle d'accès (ACE, Access Control Entries). Chaque ACE fait référence à une entité et contient des informations sur l'entité et les opérations que cette entité peut exécuter sur la ressource. Certaines personnes peuvent se voir attribuer un accès en lecture, tandis que d'autres bénéficient d'un contrôle total. Le type d'ACE dépend du type d'objet sécurisable.

Un objet sécurisable est un objet qui comporte un descripteur de sécurité contenant des informations sur la sécurité de l'objet, comme par exemple les données SID et ACL du propriétaire. Voici quelques exemples d'objets sécurisables :

• les fichiers et répertoires NTFS ;

• les canaux nommés et anonymes ;

• les processus et les threads ;

• les services ;

• les partages réseau.

Une ACL est une structure de données simple. Elle contient une série d'informations sur le propriétaire ainsi que d'éventuelles ACE. Chaque ACE contient un SID et des informations d'accès relatives à ce SID, comme par exemple la lecture, l'écriture, l'ouverture, la création, etc. Les ACL sont appliquées aux ressources qui nécessitent une protection ; elles sont appelées discrétionnaires parce que la décision d'accorder tel degré d'accès à tel utilisateur pour un objet est à la discrétion du propriétaire de l'objet.

Windows 2000 inclut également la prise en charge du refus explicite de l'accès à un objet par l'intermédiaire d'autorisations de refus. Par exemple, si tous les utilisateurs (Tout le monde) à l'exception de Richard doivent pouvoir accéder à un fichier, les autorisations suivantes seront définies : Tout le monde (Lecture) et Richard (Refus de contrôle total).

Dans la mesure où les autorisations refus sont toujours examinées avant les autorisations permission, Richard se verra toujours refuser l'accès à cet objet. Pour cette raison, le compte Tout le monde ne doit jamais se voir refuser l'accès à un objet ; dans pareil cas, Windows génère un avertissement.

Les types d'autorisations sont différents d'un objet à l'autre ; par exemple :

• Il est possible de définir, d'écrire, de lire et de créer des autorisations de fichiers.

• Les objets Active Directory peuvent comporter des paramètres spécifiques sur les propriétés des objets, comme par exemple la possibilité de lire les certificats d'un utilisateur ou de définir l'adresse de messagerie de l'utilisateur.

Lorsqu'une entité tente d'accéder à une ressource, Windows 2000 procède à une simple vérification DACL. Pour cela, il vérifie les SID dans le jeton de l'utilisateur afin de comparer le type d'accès demandé aux SID de chaque ACE de l'ACL de la ressource. Windows 2000 refuse l'accès à l'objet si aucune des ACE n'autorise l'accès de l'utilisateur, ou si une ACE refuse l'accès de l'utilisateur ; dans le cas contraire, l'accès est accordé. En outre, lorsqu'un processus ou une thread limité(e) tente d'accéder à un objet sécurisable, le système effectue deux vérifications d'accès : l'une utilise les SID activés du jeton, l'autre utilise la liste des SID limités. L'accès est accordé uniquement si les deux vérifications d'accès permettent l'accès demandé (les jetons limités sont étudiés plus loin).

Il est important de noter qu'une application qui agit au nom d'un utilisateur (c'est-à-dire qui usurpe l'identité de l'utilisateur) doit uniquement demander les droits d'accès dont elle a besoin pour exécuter ses tâches. Si l'application demande un accès de lecture, d'écriture et de suppression mais que la ressource accorde uniquement l'accès en lecture, l'application se verra refuser l'accès, y compris l'accès en lecture.

Usurpation d'identité

L'usurpation d'identité désigne la possibilité pour une thread de s'exécuter dans un contexte de sécurité différent de celui du processus auquel la thread appartient.
En général, une thread dans une application serveur usurpe l'identité d'un client avant d'exécuter les tâches au nom du client, permettant ainsi à la thread du serveur d'agir au nom de ce client pour accéder aux objets ou valider l'accès à ses propres objets.

Un serveur peut usurper l'identité d'un client lorsqu'il se connecte à une base de données, de sorte que la base de données puisse authentifier et autoriser le client. De même, une application peut usurper l'identité du client avant d'accéder aux fichiers qui sont protégés par une ACL, afin de s'assurer que le client ne peut obtenir que l'accès autorisé aux informations de ces fichiers.

COM+ et Windows 2000

Les services de composants inclus dans Microsoft Windows 2000 représentent une combinaison de COM et de MTS (Microsoft Transaction Server). Il est important de comprendre le fonctionnement de l'authentification dans Windows 2000. L'architecture COM+ 1.0 est basée sur le modèle de fourniture de services aux composants d'applications qui implémentent un certain nombre d'interfaces.
Les services COM+ 1.0 incluent les transactions automatiques, la mise en pool de ressources, la gestion des threads et la sécurité. Cette section se concentre sur la sécurité et l'authentification.

Les interfaces sont des collections de déclarations de méthodes et de types de données associés qui représentent des unités de fonctionnalités offertes par un composant. Les notions de composant et d'interface de COM+ 1.0 correspondent aux notions de classe et d'interface dans les langages modernes orientés objet.
Les composants COM+ 1.0 sont accessibles via les protocoles COM standard, à la fois en mémoire et hors processus.

Architecture de sécurité COM+

La sécurité COM+ 1.0 s'articule autour de l'interaction entre un client et une application COM+ 1.0 ; ainsi, une application client exécute un appel de méthode sur un des composants de l'application. Dans l'architecture Internet Data Center, un client est généralement un processus IIS qui s'exécute dans le contexte de sécurité d'un utilisateur et qui exécute un appel de méthode vers un composant COM+.

L'application doit authentifier le client et peut également nécessiter l'authentification de l'identité du serveur. L'appel proprement dit de la méthode nécessite une protection contre la divulgation des informations et le trafic des données. L'objectif de la sécurité COM+ 1.0 est d'offrir cette fonctionnalité et de simplifier la tâche du programmeur. Pour cela, la sécurité COM+ 1.0 utilise un modèle déclaratif pour traiter la majorité des cas dans lesquels à la fois l'autorisation et l'authentification sont configurées.

Pour répondre à des scénarios plus élaborés, comme par exemple le scénario de délégation dans lequel l'application COM+ doit exécuter des tâches sous l'autorité du client, des contrôles de programmation peuvent être utilisés.

Vue d'ensemble des autorisations

Pour l'autorisation, les applications contrôlent l'accès par l'intermédiaire de rôles, lesquels représentent des catégories d'entités propres aux applications. Dans COM+ 1.0, ces entités sont authentifiées par Windows 2000. La protection est configurée afin de limiter l'accès aux appels de méthodes ou est programmée pour limiter l'accès aux ressources d'applications privées. En outre, COM+ 1.0 prend en charge le contrôle d'accès de type usurpation d'identité de Windows 2000 lorsque l'application accède aux ressources au nom du client.

Vue d'ensemble de l'authentification

Pour l'authentification, COM+ 1.0 se base totalement sur Windows 2000. Cela signifie que les entités COM+ 1.0 sont des entités Windows 2000. En outre, COM+ 1.0 utilise les services d'authentification fournis par Windows 2000. Cela s'effectue par l'intermédiaire de divers mécanismes, tels que la superposition de DCOM sur un appel de procédure à distance (RPC, Remote Procedure Call), lequel se base à son tour sur les différents fournisseurs de sécurité de Windows 2000, tels que Kerberos et NTLM, pour offrir les services d'authentification, de confidentialité et d'intégrité.

COM+ 1.0 offre une mince couche de configuration qui contrôle divers paramètres d'authentification. Ce contrôle d'authentification peut être appliqué de façon administrative à différents niveaux de granularité de la configuration et, dans les rares cas où cela s'avère nécessaire, par la programmation.

Authentification COM+

La relation entre l'authentification COM+ 1.0 et l'authentification Windows 2000 est décrite en détail ci-après, ainsi que les mécanismes offerts par COM+ 1.0 pour le contrôle de l'authentification.

Approbation client-application

COM+ 1.0 utilise des mécanismes d'authentification de Windows 2000 via l'intégration à Microsoft RPC et aux différents fournisseurs de sécurité de Windows 2000. Le niveau de fonctionnalité varie en fonction de chaque fournisseur de sécurité. Par exemple, Kerberos prend en charge l'authentification mutuelle, tandis que NTLM authentifie uniquement le client et non le serveur. Cela fait que la prise en charge des fournisseurs de sécurité au niveau COM+ 1.0 (via DCOM) n'est pas totalement transparente. Ainsi, bien qu'une couverture plus étendue sera sans doute offerte très prochainement, COM+ 1.0 dans Windows 2000 ne prend en charge que les protocoles Kerberos, NTLM et Négociation.

Cela signifie que pour qu'un client et l'application COM+ 1.0 engagent une communication d'authentification, un chemin d'approbation doit exister entre les domaines du client et de l'application. Soit le client et l'application sont membres du même domaine, soit il doit exister une relation d'approbation inter-domaine entre les domaines du client et de l'application. Dans l'architecture Internet Data Center, un modèle de domaine unique est utilisé, de sorte que le client et l'application sont membres du même domaine.

Dans de nombreux cas, l'identité du client n'est pas une identité de domaine, ou du moins elle ne peut pas directement être authentifiée comme telle. Dans ces cas, la relation entre le client et l'application fait généralement l'objet d'une médiation par un serveur Web ; ainsi, le client est un navigateur Web qui interagit via HTTP avec le programme hébergé par le serveur Web, lequel répartit à son tour les tâches aux composants COM+. Par conséquent, il est possible de transférer au serveur Web la responsabilité de l'authentification et l'établissement d'une identité de domaine pour le client. Une fois cette tâche accomplie, le serveur Web peut usurper l'identité du client dans son interaction avec l'application COM+ 1.0.

La configuration de l'authentification permet de contrôler le niveau de protection appliqué aux appels de méthodes, y compris la décision de procéder ou non à l'authentification. À la fois le client et l'application peuvent définir des exigences pour ce contrôle. Au début d'une conversation, le client et l'application engagent une négociation afin de déterminer l'authentification et la protection qui seront appliquées à leurs échanges. Le paramètre appliqué aux appels de méthodes entre le client et l'application est le plus strict des deux.

Pour le client, la configuration de l'authentification s'applique à l'échelle de l'ordinateur. Celle-ci est définie dans la zone de liste Niveau d'authentification par défaut, qui se trouve sous l'onglet Propriétés par défaut du Poste de travail. Ce paramètre peut être modifié par programmation par le code client.

Outre la définition du niveau d'authentification par défaut pour les clients, la configuration par défaut inclut également les paramètres suivants :

• Activer Distributed COM sur cet ordinateur. Ce paramètre détermine si les appels entre ordinateurs à l'aide de DCOM sont autorisés depuis ou vers l'ordinateur. Par défaut, ce paramètre est sélectionné, ou activé.

• Activer les services Internet COM sur cet ordinateur. Ce paramètre détermine si les appels qui utilisent CIS (COM Internet Services) sont autorisés vers l'ordinateur. Par défaut, ce paramètre est désactivé.

Chaque application COM+ 1.0 peut configurer de façon indépendante ses contrôles d'authentification. Pour l'application, ce paramètre s'applique à la fois à l'application lorsqu'elle agit en tant que serveur (c'est-à-dire lorsqu'elle reçoit des appels client) et lorsqu'elle agit en tant que client (lorsqu'elle émet des appels à destination d'autres applications). Dans ce dernier cas, le niveau d'authentification et de protection peut également être modifié par programmation. L'authentification est configurée via la zone de liste Niveau d'authentification pour les appels sous l'onglet Sécurité de la boîte de dialogue Propriétés de l'application.

Outre les exigences d'authentification de l'application COM+, l'onglet Sécurité propose deux contrôles de base sur l'autorisation :

• Appliquer les vérifications d'accès pour cette application. Il s'agit du commutateur le plus élevé qui contrôle si le service de sécurité COM+ procédera aux vérifications d'autorisation pour l'application. Par défaut, ce paramètre est désactivé.

  Remarque : Même lorsque la vérification de l'autorisation est désactivée, le client peut toujours nécessiter de subir toute vérification d'authentification déterminée par le niveau d'authentification.

• Niveau de sécurité. Cette propriété détermine si l'application utilise une autorisation fine basée sur les rôles ou uniquement un contrôle d'accès élémentaire au niveau de l'application. Par défaut, ce paramètre est configuré pour procéder à des vérifications d'accès au niveau des processus et des composants.

Niveaux d'authentification et de protection

COM+ 1.0 prend en charge les niveaux d'authentification et de protection détaillés dans le tableau ci-après. Remarquez que ces niveaux de protection sont cumulatifs, c'est-à-dire que chaque niveau offre sa propre protection en plus de celle offerte par les niveaux inférieurs.

Paramètres

Commentaires

Aucun

Aucune authentification n'est requise.

Connexion

Authentification uniquement lors de la connexion initiale entre le client et l'application.

Appel

Ce niveau est toujours promu à la protection de niveau Paquet.

Paquet

Vérification que les données reçues au cours d'un appel proviennent bien du client approprié.

Intégrité du paquet

Vérification que les données d'appel de la méthode n'ont pas été modifiées au cours de la transmission.

Confidentialité du paquet

Cryptage des données de l'appel afin de les protéger contre toute interception au cours de leur transmission.

Une application COM+ 1.0 peut être hébergée soit dans son propre processus (ce type d'application est connu sous le nom d'application serveur), soit sous forme de bibliothèque de liaison dynamique (DLL, Dynamic-Link Library) hébergée dans un processus appelant ; dans ce cas, on parle d'une application de bibliothèque.

Une application de bibliothèque COM+ 1.0 est hébergée par un autre processus ; le processus d'hébergement contrôle donc ses paramètres d'authentification et d'autorisation. Les paramètres de sécurité du processus d'hébergement sont configurés soit en tant que client, soit en tant qu'application.

Dans les situations qui nécessitent des rappels (par exemple pour la notification), cette configuration peut provoquer des difficultés, en particulier lorsque le processus d'hébergement est un processus client sujet aux paramètres de sécurité étendus en vigueur pour l'ensemble de l'ordinateur. Dans un tel cas, les rappels échouent souvent lors la vérification de la sécurité, échouant ainsi totalement. Pour traiter ce scénario, COM+ 1.0 offre aux applications de bibliothèque un moyen de désactiver toute vérification automatique de sécurité pour leurs composants. Il suffit pour cela de désactiver la case à cocher Activer l'authentification sous l'onglet Sécurité de l'application de bibliothèque (remarquez que cette case à cocher ne s'affiche que pour les applications de bibliothèque). À l'évidence, cette possibilité doit être utilisée avec précaution.

Pour une application serveur, il est nécessaire de configurer une entité sous l'identité de laquelle l'application pourra opérer. Cette identité est celle que le client authentifie lors de l'utilisation d'un service d'authentification prenant en charge l'authentification mutuelle (comme par exemple Kerberos). Il s'agit également de l'identité par défaut utilisée lorsque l'application agit comme un client au cours de son travail. Une application peut utiliser l'usurpation d'identité pour usurper temporairement l'identité d'un de ses clients lorsqu'elle exécute des tâches en son nom ; cette procédure est décrite plus loin dans ce chapitre.

L'identité de l'application peut être configurée comme étant celle de l'utilisateur actuellement connecté (également appelé l'utilisateur interactif), ou celle d'un autre utilisateur désigné.

Le paramètre d'utilisateur interactif n'est pas adapté dans un environnement de production, car l'application nécessiterait la connexion d'un utilisateur pour fonctionner. En outre, une application configurée de la sorte expose l'identité de l'utilisateur interactif à une utilisation malveillante. Ce paramètre n'est donc utile que dans un nombre limité de cas, comme par exemple pendant le développement d'une application COM+.

COM+ 1.0 ne prend pas encore en charge l'exécution d'une application en tant que service ou sous un compte système local. L'application système COM+ 1.0, qui s'exécute sous le compte système local, constitue une exception à cette règle. En réalité, cette limitation peut présenter des avantages, car elle empêche l'exécution du code d'une application avec des privilèges de niveau système.

Autorisation COM+

L'autorisation COM+ 1.0 implique la protection de l'accès aux éléments suivants :

• les appels de méthodes d'une application ;

• les ressources privées d'une application ;

• les ressources externes que l'application peut utiliser au nom du client.

Les premier et deuxième points sont pris en charge par les rôles COM+ 1.0 et les autorisations pilotées par des ACL. Avec la prise en charge essentielle fournie par Windows 2000, COM+ 1.0 répond au troisième point grâce à deux modèles :

• Le modèle d'application approuvée, dans lequel l'application prend la décision d'accès et accède aux ressources externes uniquement sous sa propre identité.

• Le modèle d'usurpation d'identité, ou délégation, dans lequel l'application usurpe l'identité du client afin d'exécuter les tâches sous son nom.

Des rôles COM+ sont utilisés pour établir une stratégie d'autorisation : il s'agit de déterminer qui laisser entrer et avec quelle autorité. Lors du développement d'une stratégie, une décision est prise quant aux utilisateurs qui doivent pouvoir effectuer certaines actions et accéder à certaines ressources. Les rôles facilitent ce processus en servant de mécanisme de contrôle d'accès, appelé chaque fois qu'un utilisateur tente d'accéder à une ressource d'application. Un rôle est principalement un groupe d'utilisateurs qui partagent les mêmes privilèges de sécurité. Lorsqu'un rôle est affecté à une ressource d'application, une autorisation d'accès est accordée pour cette ressource à toute personne membre de ce rôle.

Ainsi, il est possible de définir un privilège de sécurité particulier en le déclarant en tant que rôle, puis en affectant ce rôle à des ressources spécifiques. Cette structure est créée lors du déploiement de l'application et les administrateurs système affectent des utilisateurs et des groupes d'utilisateurs à ce rôle. Lorsque l'application s'exécute, COM+ 1.0 applique la stratégie en examinant les rôles.

Le code est l'élément fondamental protégé par les rôles : en particulier, les méthodes qui peuvent être appelées par les clients d'une application COM+. Avec la sécurité basée sur les rôles, l'application protège les ressources en protégeant le code qui accède à ces ressources. L'appartenance à un rôle est vérifiée chaque fois qu'un client tente d'appeler une méthode exposée par un composant d'une application. L'appel ne réussit que si l'appelant est dans un rôle affecté à la méthode appelée.

Il est souvent utile de configurer l'appartenance à des rôles à l'aide des groupes Microsoft Windows NT ou Windows 2000, plutôt que pour des utilisateurs individuels. Cette approche est justifiée par les raisons suivantes :

• S'il existe un grand nombre d'applications COM+ et de rôles, il peut être possible de définir un ensemble beaucoup plus restreint de groupes qui peuvent être mappés vers les rôles de l'application Cela permet de simplifier considérablement l'administration pour certaines organisations.

• Pour les rôles contenant un grand nombre d'utilisateurs, les performances sont améliorées par l'utilisation d'un groupe pour décrire cette appartenance. L'appartenance à un groupe est déterminée lors de l'ouverture de session et est ajoutée au jeton de l'utilisateur, lequel peut être comparé plus rapidement au petit descripteur de sécurité qui représente le rôle.

• Si des applications sont déployées sur plusieurs ordinateurs, l'autorisation des utilisateurs sur le réseau peut être administrée plus facilement par l'intermédiaire de groupes.

Source de l'authentification

Les méthodes pouvant être utilisées pour authentifier un utilisateur sont la paire nom d'utilisateur/mot de passe, la carte à puce, les certificats et la biométrie. La plupart des sites Web utilisent une paire nom d'utilisateur/mot de passe, l'utilisateur étant invité à saisir un nom d'utilisateur et un mot de passe lorsqu'il tente d'accéder aux informations contrôlées. La conservation de ces informations (c'est-à-dire le nom d'utilisateur et le mot de passe) dans un endroit sécurisé est essentielle, car le site Web accepte n'importe quelle ouverture de session dès lors que le nom d'utilisateur et le mot de passe sont corrects ; il n'y a rien d'autre à vérifier. Les noms d'utilisateur et les mots de passe peuvent être stockés dans le système d'exploitation (dans Active Directory ou SAM, par exemple), ou dans une base de données telle que SQL Server. 

Comparaison entre Active Directory et SQL Server

Le tableau suivant répertorie les principales différences entre le stockage dans Active Directory et dans SQL Server.

Exigence

Active Directory

SQL Server

Lecture/
écriture

Lent en écriture. La lecture est quasiment aussi rapide que pour SQL Server.

Rapide à la fois en lecture et en écriture, sous réserve d'une implémentation correcte.

Sécurité

Très sûr.

Peu ou pas de développement requis, intégré à IIS 5.0.

Contrôle d'accès souple et précis aux objets.

Prise en charge de la norme LDAP.

Nécessite le développement d'un composant ou d'un script pour l'accès à SQL Server.

Le coût peut être élevé.

Les performances peuvent être ralenties.

Le contrôle précis peut être difficile à implémenter.

Évolutivité

Active Directory est évolutif par conception et permet également la réplication.

Possibilité d'utiliser des données partitionnées et des clusters pour l'évolutivité.

La principale différence est que Active Directory est considéré comme lent en écriture et qu'il ne doit donc pas servir au stockage d'informations dynamiques régulièrement mises à jour. Les informations qualifiées de dynamiques sont l'enregistrement de chaque déplacement d'un visiteur sur le site Web. Les actions normales de l'utilisateur, telles que la modification d'un mot de passe ou de préférences personnelles, sont considérées comme des informations statiques et peuvent largement être traitées par Active Directory. SQL Server est considéré comme rapide en écriture, mais il nécessite généralement une phase de développement supplémentaire afin d'implémenter correctement les règles définies.  

Active Directory est considéré comme le moyen le plus sûr de stocker les noms d'utilisateur et les mots de passe. Le mot de passe est crypté, et même un serveur Web approuvé, tel que IIS, ne peut pas accéder au mot de passe ; il peut uniquement vérifier que la paire nom d'utilisateur/mot de passe est valide. L'authentification Kerberos permet également une ouverture de session unique sur plusieurs serveurs. L'évolutivité de Active Directory a été considérablement améliorée par rapport au SAM Windows NT 4.0, qui ne pouvait stocker que 50 000 comptes utilisateur : Active Directory peut stocker des millions de comptes.

Active Directory est également mieux intégré à IIS. Plusieurs méthodes intégrées facilitent le processus d'authentification, comme par exemple l'authentification de base, l'intégration à Active Directory et l'authentification Digest. Si la paire nom d'utilisateur/mot de passe est stockée dans SQL Server, une méthode d'accès doit être développée afin d'accéder à cette paire ; cela peut être effectué par l'intermédiaire d'un script ASP, d'objets ADO (ActiveX Data Objects), de composants Visual Basic personnalisés ou d'une combinaison de ces éléments.
La plupart des solutions personnalisées sont lentes, ne sont pas très évolutives et exposent à davantage de risques en termes de sécurité. Les solutions maison ont tendance à coûter plus cher et font reposer la sécurité de l'organisation sur les personnes qui ont conçu le système. Il n'est donc pas recommandé de développer des solutions personnalisées, sauf nécessité absolue.

En cas d'utilisation de Microsoft Commerce Server 2000, les noms d'utilisateur et mots de passe peuvent être stockés dans Active Directory ou dans SQL Server. Dans le cas de Active Directory, toutes les méthodes d'authentification IIS standard sont prises en charge. Dans le cas de SQL Server, Commerce Server 2000 utilise ses propres composants COM+ pour accéder aux noms d'utilisateur et mots de passe SQL Server. Ces composants sont conçus et testés afin d'offrir des sites Web hautement évolutifs et aux performances élevées.

Authentification IIS 5.0

En général, le point d'entrée de l'utilisateur Web est le serveur Web IIS frontal. IIS traite l'authentification des utilisateurs par rapport à Active Directory ou SQL Server. On distingue trois catégories d'accès Web :

• l'accès anonyme ;

• l'accès identifié mais non authentifié ;

• l'accès authentifié.

Dans un scénario d'accès anonyme, il n'est pas important de savoir qui est l'utilisateur, car tous les utilisateurs ont accès à toutes les ressources. La plupart des sites Web utilisent l'accès anonyme pour leur page d'accueil et leurs documents commerciaux ou marketing. Le contenu est le même pour chaque utilisateur et il n'y a aucune information personnalisée. Par exemple, Microsoft.com utilise un fichier HTML nommé Ms.htm comme page d'accueil, afin d'optimiser au maximum les performances.

L'accès identifié concerne les zones du site Web qui offrent des services personnalisés. Par exemple, une entreprise peut souhaiter que son site Web permette aux personnes de saisir les symboles de leurs valeurs boursières préférées, un code postal pour connaître la météo, ou des événements, mais elle ne souhaite pas effrayer les utilisateurs en leur demandant de s'inscrire et d'ouvrir une session. Cette fonctionnalité est généralement implémentée à l'aide d'un programme sur le serveur Web, permettant d'écrire et de lire un fichier de cookie sur le client.

Dans le scénario de l'accès authentifié, l'utilisateur doit ouvrir une session. Cela permet d'offrir des informations personnalisées et de vérifier si l'utilisateur a accès à des données privées, sensibles ou personnelles.

Le passage de l'accès anonyme à l'accès authentifié nécessite davantage de travail de vérification. Pour l'accès anonyme, il n'est pas nécessaire de savoir qui est l'utilisateur. Pour l'accès identifié, il est nécessaire de savoir qui est l'utilisateur, mais uniquement dans le but d'offrir un service ou des informations personnalisées, en fonction de cette identité. Avec l'accès authentifié, l'accès est refusé si l'utilisateur qui tente d'ouvrir une session n'est pas en mesure de fournir les informations d'identification correctes. L'accès anonyme est le plus rapide, dans la mesure où aucune vérification n'est requise. L'accès authentifié est le plus coûteux et donc le plus lent, car l'utilisateur doit impérativement ouvrir une session et le site doit vérifier chaque élément du contenu contrôlé par rapport à l'identité de l'utilisateur, afin de déterminer si l'accès doit être accordé ou refusé.

IIS 5.0 prend en charge les protocoles d'authentification suivants, qui se classent dans les catégories anonyme et authentifié (l'accès identifié nécessite l'écriture de code pour fonctionner sous IIS 5.0) :

• l'accès anonyme ;

• l'authentification de base ;

• l'authentification Digest ;

• l'authentification Windows intégrée ;

• les certificats client X.509.

Accès anonyme

Techniquement, l'accès anonyme ne constitue pas un schéma d'authentification, dans la mesure où l'utilisateur appelant n'est jamais invité à saisir des informations d'identification telles qu'un mot de passe. Cependant, Windows 2000 nécessite que tous les utilisateurs s'authentifient avant de pouvoir accéder à une quelconque ressource. Pour cela, IIS offre un compte utilisateur par défaut appelé IUSR_nom_ordinateur comme compte pour l'accès anonyme. Tout accès anonyme s'effectue dans le contexte de ce compte. Il est également appelé compte proxy.

Ce compte est défini lors de l'installation avec un mot de passe renforcé, composé de lettres majuscules et minuscules, de chiffres et de caractères non alphabétiques ; il peut être modifié ultérieurement par l'administrateur. Ce compte n'a pas besoin d'être utilisé pour l'accès anonyme ; différents comptes utilisateur peuvent être configurés pour être utilisés dans des parties différentes de l'espace Web, comme par exemple le serveur Web, les répertoires virtuels, les répertoires et les fichiers. Dans un environnement d'hébergement dans lequel de nombreux sites Web d'entreprises sont hébergés sur le même serveur IIS, différents comptes utilisateur anonymes peuvent être créés pour chaque site Web virtuel ; les administrateurs de chaque site Web virtuel peuvent ainsi définir des mots de passe différents et disposer d'un contrôle d'accès précis pour leur propre contenu.

Le compte Utilisateur anonyme doit comporter peu de privilèges, une adhésion minimale aux groupes et un accès minimal aux ressources. À défaut de configurer le compte de cette façon, la sécurité du site Web s'en trouve compromise, car tout accès anonyme a lieu dans le contexte du compte utilisateur anonyme.

Authentification de base

L'authentification de base est un protocole d'authentification simple défini dans le cadre du protocole HTTP 1.0. Quasiment tous les serveurs et navigateurs Web prennent en charge ce protocole, mais il n'est pas sécurisé, car le mot de passe est en texte clair, avec un simple codage Base64. Toute personne utilisant un outil de détection réseau ou de capture de trafic peut accéder au mot de passe. L'authentification de base fonctionne bien par l'intermédiaire de serveurs proxy et de pare-feu.

L'authentification de base dans IIS 5.0 nécessite des comptes Windows 2000, soit dans le SAM, soit dans Active Directory. Cela permet au site Web d'utiliser des ACL pour déterminer l'accès aux ressources. Lorsqu'un utilisateur se connecte à un site Web via l'authentification de base, IIS récupère le nom d'utilisateur et le mot de passe dans l'en-tête d'autorisation HTTP, appelle l'API LogonUser, puis usurpe l'identité de l'utilisateur.

Par défaut, les utilisateurs qui accèdent à un serveur Web avec authentification de base doivent disposer du droit d'ouvrir une session localement, bien que cet aspect puisse être modifié dans la métabase IIS via l'interface ADSI. Mais pourquoi changer le type d'ouverture de session ? L'API LogonUser détermine le mode d'ouverture de session du compte. Par exemple, le compte peut ouvrir une session à l'aide de privilèges d'ouverture de session locale, réseau ou par fichier de commande. L'ouverture de session interactive (locale) est activée par défaut, car il s'agit du paramètre le plus souple pour la plupart des environnements ; il n'est cependant pas nécessairement le plus sûr. Le fait d'attribuer ce privilège aux utilisateurs leur permet d'ouvrir une session sur le serveur Web comme s'ils disposaient d'un accès physique au serveur ; et en effet, si un tel utilisateur pouvait accéder physiquement au serveur, il pourrait ouvrir une session sur le serveur lui-même.

La possibilité d'ouvrir une session localement est héritée de Windows NT 4.0 et de IIS 4.0. Si un compte est authentifié via NTLM ou ouvre une session avec des privilèges réseau, il ne peut pas accéder aux ressources sécurisées d'un autre ordinateur distant. Bien que le problème de la délégation client soit résolu dans Windows 2000 grâce à Kerberos, le seul moyen de contourner ce problème dans Windows NT avec IIS 4.0
(et Windows 2000 avec IIS 5.0 dans un environnement non Active Directory) consiste à utiliser le compte avec des privilèges d'ouverture de session locale.

Avec des privilèges d'ouverture de session locale, les informations sur le client, telles que l'adhésion aux groupes et les privilèges, sont stockées de façon à ce que le compte puisse procéder à une ouverture de session hors connexion si le serveur qui procède à l'ouverture de session ne peut pas accéder à un contrôleur de domaine. L'inconvénient du stockage de ces informations est la lenteur ; un certain temps est en effet nécessaire pour charger et stocker les données.

Néanmoins, le meilleur des deux mondes (rapidité et possibilité de passer à un serveur distant de façon sécurisée) peut être obtenu à l'aide du privilège d'ouverture de session par fichier de commande ; ce privilège doit être accordé aux comptes utilisateur, car il ne s'agit pas d'un paramètre par défaut.

Le paramètre d'ouverture de session réseau avec mot de passe en texte clair

Une nouvelle implémentation de l'ouverture de session réseau de Windows 2000 permet l'utilisation du privilège réseau lors de l'appel de LogonUser. L'utilisateur peut passer du serveur IIS à un serveur distant à l'aide d'un indicateur dans l'appel de LogonUser (le paramètre Ouverture de session réseau avec mot de passe en texte clair). Cette possibilité ne peut être définie qu'à l'aide de l'interface ADSI.

Le tableau suivant répertorie les avantages et les inconvénients de chaque privilège d'ouverture de session lorsqu'il est appliqué à l'authentification de base.

Privilège

Avantages

Inconvénients

Local

L'utilisateur peut passer à un serveur distant sécurisé fonctionnant sous Windows NT ou Windows 2000.

Non sécurisé ; le fait d'attribuer ce privilège aux utilisateurs leur permet d'ouvrir une session sur le serveur Web comme s'ils disposaient d'un accès physique au serveur.
Plus lent que les autres types d'ouverture de session, car les informations du client sont mises en cache.

Réseau

Sécurisé ; l'utilisateur ne peut pas ouvrir une session sur le serveur, même s'il a accès physiquement au serveur.
Rapide, car aucune donnée client n'est mise en cache.

L'utilisateur ne peut pas passer à un serveur distant.

Fichier de commande

L'utilisateur peut passer à un serveur distant.
Sécurisé ; l'utilisateur ne peut pas ouvrir une session sur le serveur, même s'il a accès physiquement au serveur.
Rapide, car aucune donnée client n'est mise en cache.
Les futures versions de Windows devraient prendre en charge la mise en cache des données client pour ce type d'ouverture
de session.

Très peu de comptes possèdent ce privilège
par défaut.

Réseau avec ouverture de session en texte clair

Sécurisé ; l'utilisateur ne peut pas ouvrir une session sur le serveur, même s'il a accès physiquement au serveur.
Rapide, car aucune donnée client n'est mise en cache.
L'utilisateur peut passer à un serveur distant.

Le texte en clair peut être intercepté par un outil de détection réseau.

Nouvelles fonctionnalités avec Active Directory

Lorsque l'authentification de base est utilisée sur un système avec Active Directory, elle offre deux autres fonctionnalités :

• la possibilité de déléguer une identité ;

• l'utilisation de noms d'utilisateur principaux (UPN, User Principal Names).

La possibilité de déléguer une identité permet à un compte utilisé pour ouvrir une session sur le serveur Web d'être utilisé pour demander des ressources sécurisées sur des ordinateurs distants ; elle permet également à ces ordinateurs distants de demander à leur tour des informations sur d'autres ordinateurs, au nom du compte

utilisateur d'origine.

Active Directory permet cela grâce à l'utilisation du protocole Kerberos (celui-ci est activé lors de l'installation de Active Directory) pour procéder à la délégation. L'identité de l'utilisateur peut être transférée et vérifiée sur n'importe quel serveur du domaine Kerberos Active Directory.

Les noms d'utilisateur principaux (UPN, User Principal Names) sont une autre fonctionnalité intéressante. Ces noms sont au format utilisateur@domaine.com.
Les conditions suivantes doivent être satisfaites pour permettre l'utilisation de noms UPN avec l'authentification de base :

• Le serveur sur lequel s'exécute IIS 5.0 doit avoir accès à Active Directory.

• Le compte doit posséder un nom UPN. Par défaut, tous les comptes Active Directory disposent d'un nom UPN.

• Le nom de domaine de base doit être défini sur "\". Il s'agit d'un indicateur permettant de signifier à IIS qu'il doit utiliser le nom UPN plutôt que la dénomination domaine/compte classique de Windows NT.

Comme nous l'avons vu précédemment, les utilisateurs doivent disposer de comptes dans le SAM ou dans Windows 2000 Active Directory pour accéder aux ressources de IIS 5.0. Si un utilisateur ouvre une session sans entrer de nom de domaine, le serveur suppose que le domaine à utiliser pour le compte est le même que celui dans lequel se trouve le serveur Web. Par exemple, si le serveur Web se trouve sur un serveur du domaine Ventes et que Antoine ouvre une session à l'aide de l'authentification de base, il se connecte avec le compte VENTES\Antoine, sauf s'il ouvre explicitement une session avec un autre compte tel que DEVELOPPEMENT\Antoine. Le fait de configurer l'authentification de base pour utiliser le domaine par défaut "\" indique à IIS 5.0 qu'il doit ignorer tout nom de domaine et utiliser un nom UPN à la place. Cela est possible parce des informations de domaine sont intégrées au nom UPN.

Bien que l'authentification de base ne soit pas sécurisée, elle reste utile lorsqu'elle est utilisée conjointement avec le protocole SSL/TLS (Secure Sockets Layer/Transport Layer Security). Si un répertoire virtuel est configuré pour utiliser SSL/TLS et l'authentification de base, la négociation SSL/TLS a lieu en premier et le canal sécurisé est établi, après quoi l'authentification démarre et toutes les données transmises, y compris le nom d'utilisateur et le mot de passe, sont cryptées à l'aide du protocole SSL/TLS. Cela rend très difficile, sinon impossible, de déterminer les informations d'identification d'un utilisateur. SSL nécessite toutefois que la session client se cantonne au même serveur Web, ce qui peut poser problème dans un environnement de groupes de serveurs Web. Un groupe de serveurs Web est utilisé pour équilibrer la charge entre les serveurs IIS, ainsi que pour permettre le basculement. Si le protocole SSL est utilisé et que le serveur Web qui procède à l'authentification connaît une défaillance, l'utilisateur remarque l'erreur et doit de nouveau ouvrir une session. Cependant, si ces informations d'état sont stockées dans SQL Server, l'utilisateur ne perd pas les données de la session, comme par exemple les articles de son caddie.

Bien que l'authentification de base soit un ancien protocole qui présente de sérieux problèmes de sécurité, il est courant sur le Web aujourd'hui et est pris en charge par absolument tous les serveurs et navigateurs Web. En raison de ces problèmes de sécurité, il ne doit être utilisé que pour l'accès à des données peu importantes et le protocole SSL/TLS doit d'abord être utilisé pour sécuriser la connexion.

Authentification Digest

L'authentification Digest est un nouveau schéma d'authentification qui fait partie du protocole HTTP 1.1 ; à l'instar de l'authentification de base, l'authentification Digest peut fonctionner via des serveurs proxy et des pare-feu.

L'authentification Digest ne transmet pas le mot de passe de l'utilisateur au serveur en texte clair ; elle hache les informations (comme par exemple la ressource à laquelle l'utilisateur accède, le mot de passe et le domaine), puis transmet la demande au serveur. Le processus de hachage est souvent appelé création d'un résumé (digest).
La fonction de hachage par défaut pour l'authentification Digest est MD5, développée par RSA Data Security.

L'authentification Digest offre des avantages par rapport à l'authentification de base, principalement parce que le mot de passe ne transite pas en texte clair du navigateur au serveur. Le principal inconvénient de l'authentification Digest est la prise en charge par les navigateurs et les serveurs. Au moment de la rédaction de ce document, Internet Explorer 5 (et versions ultérieures) est le seul navigateur, et IIS 5.0 est un des très rares serveurs Web à prendre en charge l'authentification Digest. L'authentification Digest est envisagée pour une utilisation par des protocoles Internet autres que HTTP, comme par exemple LDAP (Lightweight Directory Access Protocol) et les protocoles de messagerie électronique IMAP, POP3 et SMTP (Simple Mail Transfer Protocol).

Authentification Windows intégrée

Dans IIS 4.0, l'authentification Windows intégrée était appelée authentification Stimulation/Réponse de Windows NT, également appelée authentification NTLM (NT LAN Manager). Il s'agit du protocole d'authentification natif de toutes les plates-formes Windows antérieures à Windows 2000.

Dans Windows 2000 et IIS 5.0, l'authentification intégrée inclut l'authentification NTLM et Kerberos, et elle représente un sous-ensemble de l'authentification NTLM.

L'authentification NTLM fonctionne particulièrement bien dans un environnement intranet dans lequel les utilisateurs disposent de comptes Windows, car le navigateur tente d'utiliser les informations d'identification de l'utilisateur actuel à partir d'une ouverture de session sur un domaine. Si ces informations d'identification sont rejetées, le serveur Web renvoie une erreur HTTP 401 au navigateur afin d'inviter l'utilisateur à saisir un nom d'utilisateur et un mot de passe, de sorte que la demande puisse être reformulée.

L'utilisateur n'est pas invité à saisir ces informations pour chaque demande HTTP ; cela ne se produit que lorsque les informations d'identification mises en cache ne disposent pas des autorisations suffisantes pour accéder à une page ou à un fichier spécifique.

Avec l'authentification NTLM, le mot de passe de l'utilisateur n'est pas envoyé du navigateur au serveur Web. Si un utilisateur ouvre une session en tant qu'utilisateur du domaine, il n'a pas besoin d'être de nouveau identifié lors de l'accès à un serveur Web configuré pour utiliser l'authentification NTLM dans ce domaine. Avant Windows 2000, Windows NT utilisait uniquement le protocole d'authentification Stimulation/Réponse de Windows NT. En revanche, Windows 2000 Server prend en charge à la fois les protocoles d'authentification NTLM et Kerberos version 5, ce qui explique que IIS 5.0 ne propose plus le protocole d'authentification Stimulation/Réponse de Windows NT dans la boîte de dialogue Méthodes d'authentification : le schéma d'authentification peut être Kerberos ou NTLM.

Windows 2000, Internet Explorer 5 et IIS 5.0 utilisent tous le protocole Négociation pour déterminer si l'authentification NTLM ou Kerberos doit être utilisée. Le processus est le suivant :

1. Le client, via Internet Explorer 5 sous Windows 2000, demande une ressource du serveur IIS 5.0 qui exécute Windows 2000.

2. IIS renvoie au navigateur une erreur HTTP 401 qui inclut deux en-têtes
   WWW-Authenticate, l'une pour Négociation et l'autre pour NTLM.

3. Internet Explorer voit qu'une erreur HTTP 401 s'est produite et examine la réponse afin de voir quels en-têtes WWW-Authenticate il comprend. Il choisit le premier protocole qu'il comprend, à savoir Négociation. Le navigateur comprend également NTLM, mais Négociation est répertorié en premier. Internet Explorer effectue ensuite un appel au fournisseur de sécurité Négociation du client. L'interface de programmation vers le fournisseur de sécurité est appelée SSPI (Security Support Provider Interface), un moyen standard de faire référence aux multiples schémas d'authentification de Windows.

4. Le fournisseur de sécurité Négociation obtient les données appropriées des fournisseurs de sécurité NTLM et Kerberos, puis il construit une réponse. La réponse comporte suffisamment d'informations pour authentifier le client auprès du serveur et pour déterminer si NTLM ou Kerberos seront utilisés comme protocole d'authentification (les situations dans lesquelles l'utilisation de Kerberos est préférable à NTLM sont étudiées plus loin).

5. Le fournisseur de sécurité Négociation du client passe l'objet BLOB (Binary Large Object) de réponse à Internet Explorer.

6. Internet Explorer génère une nouvelle demande, en incluant cette fois l'en-tête HTTP Authorization et les informations de négociation, puis il la transmet à IIS.

7. Le serveur Web prend la nouvelle demande et transmet l'objet BLOB Négociation au fournisseur de sécurité Négociation du serveur.

8. Le fournisseur de sécurité Négociation détermine si Kerberos ou NTLM est utilisé.

9. Si NTLM est choisi durant la phase Négociation, les étapes 6, 7 et 8 peuvent être répétées plusieurs fois, en raison du processus Stimulation/Réponse.

10. Si tout se passe bien, le fournisseur de sécurité renvoie un jeton à IIS et le serveur Web usurpe l'identité de l'utilisateur représenté par le jeton, afin d'accéder à la ressource.

11. IIS renvoie au client les données demandées, avec un message "HTTP code d'état 200 – aucune erreur".

Mécanisme Stimulation/Réponse

La plupart des systèmes de type Stimulation/Réponse fonctionnent de la façon détaillée ci-après. Remarquez que le mot de passe de l'utilisateur ne transite pas sur le réseau.

1. Le client demande l'accès à une ressource du serveur.

2. Le serveur impose au client de s'authentifier.

3. Le serveur envoie une valeur aléatoire, la stimulation, au client.

4. Le client hache la valeur aléatoire et son mot de passe afin de créer une réponse.

5. Le client envoie la réponse et son nom au serveur.

6. Le serveur reçoit la réponse du client.

7. Le serveur effectue les mêmes opérations de hachage que le client.

8. Si le hachage envoyé par le client est le même que celui obtenu par le serveur, il y a de fortes chances que le client soit bien celui qu'il prétend être.

Ce système est plus sûr que l'envoi d'un mot de passe en texte clair sur le réseau, dans la mesure où ce sont des hachages, et non des mots de passe, qui transitent sur le réseau.

Le renvoi au client d'en-têtes NTLM et Négociation est nécessaire à des fins de compatibilité descendante. Les versions de Internet Explorer antérieures à Internet Explorer 5 et les versions de Windows antérieures à Windows 2000 ne reconnaissent pas l'en-tête Négociation, mais ils reconnaissent NTLM.

Comparaison de Kerberos et de NTLM

Le package Négociation utilise Kerberos si les conditions ci-après sont réunies. Si l'une ou l'autre des conditions n'est pas vraie, NTLM est utilisé :

• Le client est Windows 2000 et utilise Internet Explorer 5 (ou version ultérieure).

• Le serveur exécute Windows 2000 et IIS 5.0 (ou version ultérieure).

• IIS 5.0 est configuré pour utiliser l'authentification Windows intégrée.

• Le client et le serveur se trouvent dans le même domaine Windows 2000 ou dans des domaines approuvés.

• Si l'en-tête de l'hôte (nom du site Web) demandé diffère du nom NetBIOS du serveur qui exécute IIS 5.0, un nouveau nom SPN doit avoir été enregistré à l'aide de l'outil Setspn du Kit de ressources de Windows 2000 Server.

Kerberos offre plusieurs avantages significatifs par rapport à NTLM :

• L'identité du client peut être transmise d'un ordinateur à un autre. En d'autres termes, Kerberos résout le problème de la délégation.

• Kerberos est plus sûr que NTLM.

• Kerberos authentifie le serveur et le client ; NTLM authentifie uniquement le client. Lorsque NTLM est utilisé, le client ne sait pas si le serveur est valide.

• Kerberos peut être plus rapide que NTLM.

Authentification par certificat client X.509

À la fois IIS 4.0 et IIS 5.0 prennent en charge l'utilisation de certificats client X.509 pour l'authentification. Cette approche utilise HTTPS au lieu de HTTP pour ordonner au navigateur d'utiliser le protocole SSL/TLS (port TCP 443 par défaut, plutôt que le port 80). Les certificats prennent toujours en charge l'authentification du serveur Web et les certificats client peuvent également être configurés pour prendre en charge l'authentification du client.

Authentification du serveur

Lorsqu'un navigateur client accède à un serveur Web à l'aide du protocole SSL/TLS, il utilise toujours les certificats du serveur pour authentifier le serveur Web. Les vérifications suivantes sont effectuées :

• Vérifier que le site Web possède la clé privée associée à la clé publique du certificat.

• Vérifier que le nom dans le certificat est le même que le nom du site Web.

• Vérifier que l'émetteur du certificat du site Web est approuvé.

• Vérifier que le certificat n'a pas expiré.

• Vérifier que le certificat n'a pas été révoqué. Par défaut, cette vérification n'est pas effectuée par Internet Explorer, car cela générerait une grande quantité de trafic Internet supplémentaire ; cela signifie que Internet Explorer approuvera un certificat qui a été révoqué. Cependant, IIS procède à la vérification par rapport à la liste de révocation.

• Vérifier que le certificat n'a pas été trafiqué.

En cas d'échec de l'une ou l'autre de ces vérifications, un avertissement s'affiche pour l'utilisateur et la connexion risque d'être perdue. Si le navigateur informe l'utilisateur d'un problème au niveau du certificat, celui-ci ne doit pas poursuivre la connexion.

Authentification du client

De façon facultative, le protocole SSL/TLS peut authentifier le client. Lorsqu'une connexion SSL/TLS est établie, le client authentifie le serveur en inspectant le certificat du serveur Web, après quoi le serveur Web peut éventuellement demander à l'utilisateur de s'authentifier. Après une telle demande, le serveur envoie au navigateur une liste d'autorités de certification qu'il approuve. Le navigateur invite l'utilisateur à choisir parmi une liste de certificats client pris en charge.

IIS peut utiliser des certificats client X.509 de quatre façons différentes :

• Il n'en a pas besoin.

• Il propose à l'utilisateur de fournir un certificat, mais n'en a pas besoin.

• Il impose à l'utilisateur de fournir un certificat client.

• Il impose à l'utilisateur de fournir un certificat client et utilise ce certificat pour procéder au mappage vers un compte utilisateur Windows 2000.

La première option est simple : le client n'a pas la possibilité de présenter un certificat. Les deux options suivantes sont semblables ; la différence est que la première n'impose pas au client de fournir un certificat, comme c'est le cas de la deuxième. Dans les deux cas, si le certificat client est fourni, ses informations sont utilisées pour remplir la collection ASP Request.ClientCertificate. Ces données sont utilisées dans ASP pour prendre des décisions d'authentification et d'autorisation.

IIS 5.0 permet au développeur d'un site Web d'utiliser des certificats d'authentification client comme de puissantes informations d'identification pour l'authentification.
Ce processus est appelé mappage de certificat, car les informations des certificats sont utilisées pour le mappage vers un compte Windows 2000 ; l'utilisateur du site Web accède ainsi aux ressources dans le contexte du compte mappé.

IIS 4.0 offre une méthode simple pour le mappage des certificats client, méthode qui est également prise en charge par IIS 5.0 à des fins de compatibilité descendante. Cependant, cette méthode risque d'être écartée au profit du mappage Active Directory offert par IIS 5.0, plus simple à utiliser.

Le mappage IIS 4.0 fonctionne selon deux modes différents : le mappage un à un et le mappage plusieurs à un. Lors de l'utilisation du mappage un à un, IIS examine le certificat client et, en fonction de l'ensemble de son contenu, utilise ce certificat pour ouvrir une session sur le système avec ce compte utilisateur. L'inconvénient de ce modèle est l'évolutivité : IIS doit stocker une copie de chaque certificat utilisé pour le mappage, ce qui limite le nombre de certificats à environ 2 à 3 000.

Le mappage de certificat plusieurs à un est basé sur des règles. L'administrateur définit une série de règles de contenu de certificat et utilise ces règles pour le mappage vers un compte Windows 2000. Par exemple, l'administrateur peut définir une règle afin que tous les certificats d'authentification client créés par la même autorité de certification de la même unité d'organisation de la même organisation soit mappés vers un même compte utilisateur.

L'inconvénient de ces deux méthodes de mappage de certificat issues de IIS 4.0 est la charge administrative importante : l'administrateur doit saisir le compte utilisateur et le mot de passe de chaque compte utilisé dans le processus de mappage. Une charge supplémentaire est également introduite parce que les administrateurs saisissent souvent de façon incorrecte les mots de passe et les noms d'utilisateur.

Le mappage de certificat client Active Directory, également appelé mappage du service d'annuaire Windows, a été introduit dans IIS 5.0. Le mappage de certificat client Active Directory utilise les informations des certificats client contenus dans Active Directory pour procéder au mappage vers un compte utilisateur ; par exemple, pour comparer des informations spécifiques contenues dans le certificat client (et présentées au cours de la phase de négociation SSL/TLS) avec les informations des certificats client stockés dans Active Directory. Si Active Directory trouve un compte avec les informations de certificat appropriées, il ouvre automatiquement une session pour ce compte. Contrairement aux méthodes de mappage de certificat client de IIS, il n'est pas nécessaire de saisir un mot de passe pour le compte utilisateur associé au mappage.

Le mappage de certificat client Active Directory fonctionne de deux façons :

• Une recherche Active Directory du Nom de l'objet dans le certificat trouve l'utilisateur Active Directory dans l'annuaire à partir de ce nom. Ce mode est très rapide.

• Une recherche Active Directory de l'Autre nom de l'objet dans le certificat trouve une correspondance pour l'utilisateur dans Active Directory.

Après que le sous-système d'autorité de sécurité locale (Local Security Authority Subsystem, Lsass.exe) a trouvé une correspondance à l'aide de l'une ou l'autre de ces méthodes, il mappe automatiquement le certificat client vers le compte Windows 2000 approprié ; aucune autre intervention administrative n'est nécessaire.

Le mappage de certificat client Active Directory est beaucoup plus simple à configurer que le mappage de certificat client IIS, car la charge administrative est peu importante. Les exigences sont les suivantes :

• Windows 2000 Active Directory est rempli avec les utilisateurs et les certificats d'authentification client associés.

• IIS est configuré pour utiliser le mappage de certificat client Active Directory plutôt que IIS.

Contexte de sécurité des processus IIS

Lorsqu'un processus démarre dans Windows 2000, il démarre toujours dans un contexte de sécurité spécifique, soit à l'aide d'un compte préconfiguré, soit à l'aide du compte de l'utilisateur actuellement connecté. Le processus IIS fondamental est InetInfo.exe, lequel s'exécute sous le compte LocalSystem. Un autre processus, à savoir DllHost.exe, s'exécute sous IWAM_nom_ordinateur.

Un processus peut contenir plusieurs threads qui s'exécutent dans un contexte de sécurité particulier. Lorsqu'une demande client est traitée, IIS usurpe l'identité du client avant d'effectuer le travail ; cela implique le remplacement du contexte de la thread (IWAM_nom_ordinateur ou LocalSystem) par le contexte utilisateur. Une fois le travail terminé, la thread revient au contexte du processus, autrement dit IWAM_nom_ordinateur ou LocalSystem. Ce processus est appelé "revert to self".

Certains développeurs Web procèdent à un appel de fonction au cours de ce processus ; ceci est fortement déconseillé. Lorsque l'application Web traite une demande client, elle appelle la fonction RevertToSelf. À ce stade, la thread qui traite la demande client n'usurpe plus l'identité de l'utilisateur. Elle s'exécute sous l'identité du processus, et si l'application Web s'exécute avec une faible protection, elle revient à l'identité InetInfo.exe, à savoir LocalSystem. Dans la mesure où ce compte est hautement privilégié, toute erreur de sécurité commise lors de l'exécution dans le contexte LocalSystem peut s'avérer très grave. Microsoft résoudra ce problème dans une version ultérieure du serveur Web.

L'appel de la fonction RevertToSelf à partir d'une application Web avec une protection intermédiaire ou élevée provoque le retour de la thread sous le compte IWAM_nom_ordinateur.

Niveaux de protection

IIS peut être configuré pour exécuter des portions du site Web dans un processus distinct, de sorte que si ce processus se bloque, le processus InetInfo.exe ne soit pas bloqué.
Les processus sont appelés DllHost.exe et sont contrôlés par COM+ (dans IIS 4.0, les processus sont appelés Mtx.exe et sont contrôlés par Microsoft Transaction Server).

Lorsque le serveur Web reçoit une demande, il examine le magasin de configuration afin de rechercher le paramètre Protection d'application de cette partie de l'espace d'adressage du site Web. On distingue trois niveaux de protection :

• Basse (Processus IIS). Il s'agit du mode de fonctionnement de IIS avant IIS 4.0 ; toutes les demandes sont traitées dans le processus InetInfo.exe. Il s'agit de l'option la plus rapide, mais également la moins sûre, car une application défaillante peut provoquer le blocage du processus InetInfo.exe.

• Moyenne (En file d'attente). Il s'agit d'une nouvelle option dans IIS 5.0 et c'est le paramètre par défaut pour toutes les nouvelles applications Web. Dans ce modèle, toutes les portions de l'espace Web marquées avec la protection Moyenne (En file d'attente) s'exécutent dans le même processus, externe à InetInfo.exe, appelé DllHost.exe. Ce processus ne s'exécute pas sous LocalSystem, comme c'est le cas de InetInfo.exe. En revanche, DllHost.exe s'exécute sous l'identité d'un compte contrôlé par IIS. Par défaut, l'identité est IWAM_nom_ordinateur. Lorsque la requête est reçue, IIS (avec COM+) détermine si un processus s'exécute pour traiter les applications Web de protection moyenne. Si tel n'est pas le cas, COM+ démarre le processus et IIS décharge le travail sur le nouveau processus. Si le processus s'exécute déjà, IIS passe simplement le travail au processus. Cette méthode offre le meilleur compromis entre performances et sécurité, car en cas de défaillance d'une application Web, il est probable que seule l'instance de DllHost.exe se bloque, et non le processus InetInfo.exe. Cependant, toutes les autres applications Web qui s'exécutent dans le processus DllHost.exe cesseront également de fonctionner. Lorsque IIS reçoit une nouvelle demande client, le serveur Web démarre automatiquement une nouvelle instance de DllHost.exe.

• Élevée (Isolé). Cette option, introduite dans IIS 4.0, exécute chaque application Web dans sa propre instance de DllHost.exe, laquelle s'exécute dans le contexte du compte IWAM_nom_ordinateur. Le niveau de sécurité est alors le plus élevé, mais la rapidité s'en trouve affectée.

Performances relatives

Le tableau suivant, qui présente les performances relatives de l'authentification IIS, est issu d'un test sur un serveur Xeon Pentium III 450 MHz avec 128 Mo de mémoire. Le serveur Web exécute également Active Directory. Ce scénario comporte 10 000 comptes utilisateur contenus dans Active Directory et 1 000 comptes utilisés de façon aléatoire, aucune connexion n'étant réutilisée. Dans les tests suivants, aucune dégradation notable des performances n'a été détectée lors de l'augmentation du nombre de comptes utilisateur, pas plus que lors de l'ajout de sites Web virtuels à IIS. En revanche, une dégradation significative des performances a été notée entre l'authentification de base et d'autres méthodes d'authentification plus sûres. Les méthodes d'authentification sécurisée ne transmettent pas les mots de passe en texte clair et nécessitent des calculs poussés et des algorithmes complexes ; elles sont donc beaucoup plus lentes.

Protocole d'authentification

Performances

Anonyme

860 requêtes par seconde

Authentification de base

780 requêtes par seconde

NTLM

99 requêtes par seconde

Authentification Digest

96 requêtes par seconde

Négociation (avec Kerberos)

55 requêtes par seconde

Le tableau suivant répertorie les performances pour les protocoles d'authentification à base de certificats. Dans chaque cas, le protocole SSL/TLS (Secure Sockets Layer/Transport Layer Security) était TLS utilisant RC4 56 bits, un hachage SHA-1 et l'échange de clés RSA 512 bits. Aucun autre protocole d'authentification n'a été utilisé. Il est nécessaire d'allouer environ 1 ko de mémoire par compte utilisateur connecté authentifié par IIS.

Protocole d'authentification

Performances

Accès anonyme nécessitant un certificat client (c'est-à-dire, pas de mappage)

35 requêtes par seconde

Certificat client requis et utilisation du mappage de certificat Active Directory

23 requêtes par seconde

Certificat client requis et utilisation du mappage de certificat IIS

2 requêtes par seconde

Résumé

L'architecture Internet Data Center offre un modèle hautement sécurisé à utiliser pour l'implémentation d'une solution complète de commerce électronique. Ce chapitre fournit des détails sur la conception et l'utilisation des diverses techniques et technologies de sécurité qui peuvent être utilisées pour garantir la sécurité de la solution.

Il est essentiel de comprendre que la sécurité n'est pas un aspect que vous pouvez configurer une bonne fois pour toutes, puis ignorer. Les techniques de piratage évoluent en permanence, de sorte que vos stratégies de sécurité doivent être continuellement adaptées afin de garantir que votre réseau bénéficie de la protection appropriée.

Le programme STPP (Strategic Technology Protection Program) est conçu pour s'intégrer aux composants qui constituent l'architecture Internet Data Center et garantir leur mise à jour avec les dernières configurations de sécurité. Consultez le site Web de Microsoft consacré à la sécurité afin de vous assurer que vous disposez des informations les plus récentes.

<< 1 2 3 4 5 6 7 8 9 >>

Dernière mise à jour le vendredi 1 mars 2002

Pour en savoir plus

• Lire la version US de cet article

• La rubrique sécurité de TechNet