5. Sécurisation de l'infrastructure du domaine

 

Le chapitre 4, « Application de la discipline de gestion du risque de sécurité », identifiait les risques de sécurité spécifiques du scénario de la société Contoso SA à l'aide de la discipline de gestion du risque de sécurité (SRMD). Les chapitres suivants de ce guide traitent de l'atténuation des risques ainsi identifiés ou de leur résolution au moyen de mesures de prévention.

Ce chapitre s'attache en particulier aux vulnérabilités au niveau du domaine. Il fournit une description générale de la structure du service Microsoft® Active Directory®, de la structure de l'unité d'organisation (OU, organizational unit) et de la stratégie de domaine. Il explique en outre dans le détail les stratégies de domaine spécifiques implémentées dans la société Contoso.


Structure d'Active Directory

Un ouvrage tout entier pourrait être consacré à l'étude détaillée de la conception d'une structure Active Directory. Cette technologie Microsoft fait partie d'Active Platform. Elle est conçue pour permettre aux applications de rechercher, d'utiliser et de gérer des ressources d'annuaire dans un environnement informatique distribué. Le contenu de cette section est consacré à quelques-uns de ces concepts. L'objectif est d'acquérir ici des connaissances suffisantes pour l'assimilation des autres informations connexes de ce chapitre.

L'un des aspects les plus importants à envisager lors de la création d'une architecture Active Directory concerne les frontières de sécurité qui seront imposées à l'organisation. Si vous prenez le temps de planifier correctement les modalités de la délégation et de l'implémentation des tâches de sécurité dans l'organisation, la structure finale d'Active Directory sera beaucoup plus sécurisée. Cette opération ne devrait pas nécessiter une restructuration de votre environnement à moins que des modifications majeures soient apportées à l'entreprise, comme une acquisition ou une restructuration organisationnelle.

Si une structure Active Directory a déjà été implémentée dans l'organisation, ce chapitre peut vous aider à mieux appréhender certains des avantages ou problèmes potentiels posés par la mise en place d'une structure particulière dans votre environnement du point de vue de la sécurité.

Établissement des frontières d'Active Directory

Il existe dans Active Directory différents types de frontières. Ces « frontières » peuvent correspondre à la forêt, au domaine, à la topologie de site et à la délégation d'autorisations.

Bon nombre de ces frontières sont établies au moment de l'installation d'Active Directory. Lors de la définition de la délégation d'autorisations dans l'environnement, vous devez tenir compte des stratégies et des impératifs organisationnels pour trouver le juste équilibre entre la sécurité et les fonctionnalités administratives. Vous pouvez bénéficier d'une grande souplesse lors de l'établissement de la délégation d'autorisations administratives, en fonction des besoins de votre organisation. Les frontières de délégation peuvent être subdivisées en frontières de sécurité et en frontières administratives.

Frontières de sécurité

Les frontières de sécurité permettent de définir l'autonomie octroyée aux différents groupes de l'organisation. Il est difficile de trouver le compromis idéal pour assurer, d'une part, une sécurité adéquate, fondée sur la définition de ces frontières, et offrir, d'autre part, un niveau adéquat et suffisant de fonctionnalités de base.

Cet équilibre entre les frontières de sécurité et les fonctionnalités existe. Vous devez appréhender correctement les menaces à l'origine de risques pour votre organisation et comparer ensuite cette évaluation avec les implications qu'il y a, au niveau de la sécurité, à déléguer l'administration ou à prendre d'autres décisions essentielles au niveau de l'architecture réseau de votre environnement.

Frontière de sécurité : la forêt

Au moment de la sortie de Microsoft® Windows® 2000 Server, le domaine était défini comme une frontière de sécurité dans une grande partie de la documentation afférente. Plus récemment toutefois, c'est la forêt qui émerge comme véritable frontière de sécurité. En réalité, celle-ci se situe quelque part entre les deux.

Un domaine est une frontière administrative d'Active Directory. Dans une organisation qui occupe uniquement des personnes bien intentionnées, la frontière de domaine permet une gestion autonome des services et des données à l'intérieur de chaque domaine de l'organisation.

Hélas, cet objectif n'est pas simple à réaliser lorsque la sécurité est au centre du débat. Ainsi, un domaine n'est pas parfaitement à l'abri d'une attaque possible par un administrateur de domaine malveillant. Ce niveau de séparation ne peut être obtenu qu'au niveau de la forêt.

Par conséquent, votre organisation devra peut-être envisager de dissocier le contrôle administratif des services et des données de la structure effective. Si vous comprenez parfaitement les besoins de l'organisation en termes d'autonomie et d'isolation des services et des données, votre structure Active Directory n'en sera que plus solide.

Frontières administratives

Dans la mesure où il peut s'avérer nécessaire de segmenter les services et les données, différents niveaux d'administration doivent être définis.

Administrateurs de service

Les administrateurs de service Active Directory sont chargés de configurer et de fournir le service d'annuaire. Par exemple, ils gèrent les serveurs jouant le rôle de contrôleurs de domaines, contrôlent les paramètres de configuration au niveau de l'annuaire et doivent garantir la disponibilité du service.

Souvent, la configuration du service Active Directory est déterminée par des valeurs d'attributs correspondant à des paramètres de leurs objets respectifs, lesquels sont stockés dans l'annuaire. Par conséquent, dans Active Directory, les administrateurs de service sont également des administrateurs de données et peuvent être notamment :

·         des groupes d'administrateurs responsables de la gestion de la forêt ;

·         des groupes d'administrateurs chargés de la gestion du domaine ;

·         des groupes d'administrateurs chargés de la gestion de DNS (Domain Name System) ;

·         des groupes d'administrateurs responsables de la gestion des unités d'organisation ;

·         des groupes d'administrateurs chargés de la gestion de serveur d'infrastructure.

Les groupes qui ont la charge de l'administration de la forêt doivent assurer l'accessibilité du service d'annuaire au réseau. Celui qui assure la gestion de la forêt doit être un groupe présentant un très haut niveau d'approbation. L'équipe chargée de l'administration de la forêt contrôle cette dernière par l'intermédiaire du groupe Administrateur du domaine, du domaine racine de la forêt, du groupe Administrateurs de l'entreprise et du groupe Administrateurs du schéma.

Un groupe assurant l'administration du domaine est principalement responsable des services d'annuaire. C'est l'administrateur de la forêt qui a pour mission de choisir le groupe chargé d'administrer chaque domaine. En raison de l'accès de haut niveau accordé à l'administrateur du domaine, veillez à attribuer ce rôle à une personne digne de confiance. Le groupe chargé de l'administration du domaine contrôle le domaine via le groupe Admins du domaine et d'autres groupes intégrés.

Le groupe des administrateurs DNS est pour sa part responsable du parachèvement de la structure DNS et de la gestion de l'infrastructure DNS, et ce, par l'intermédiaire du groupe des administrateurs DNS.

L'administrateur des unités d'organisation désigne un groupe ou un individu en qualité de gestionnaire de chacune des unités d'organisation. Chaque administrateur d'une unité d'organisation a le devoir de gérer les données stockées dans l'unité d'organisation qui lui est assignée. Ces groupes peuvent contrôler la manière dont l'administration est déléguée et dont la stratégie est appliquée aux objets de leurs unités d'organisation. Les administrateurs des unités d'organisation peuvent également créer de nouvelles sous-arborescences et déléguer l'administration des unités d'organisation dont ils sont responsables.

Le groupe chargé de l'administration du serveur d'infrastructure a pour mission de gérer les services WINS (Windows Internet Name Service), DHCP (Dynamic Host Configuration Protocol) et éventuellement l'infrastructure DNS. Dans certains cas, le groupe responsable de la gestion du domaine gère aussi l'infrastructure DNS puisque Active Directory est intégré à DNS et qu'il est stocké et géré sur les contrôleurs de domaines.

Administrateurs de données

Les administrateurs de données Active Directory sont responsables de la gestion des données stockées dans Active Directory ou sur les ordinateurs faisant partie d'Active Directory. Ils n'ont aucun contrôle sur la configuration ou la mise à disposition du service d'annuaire et peuvent être notamment :

·         des administrateurs qui contrôlent un sous-ensemble d'objets de l'annuaire puisque, via le contrôle d'accès héritable au niveau de l'attribut, ils peuvent se voir accorder le contrôle de sections très spécifiques de l'annuaire mais n'ont aucun contrôle sur la configuration du service lui-même ;

·         des administrateurs qui gèrent les ordinateurs membres faisant partie de l'annuaire et les données stockées sur ces ordinateurs.

Remarque : Très souvent, la configuration du service d'annuaire est déterminée par les valeurs d'attribut des objets stockés dans l'annuaire.

En résumé, les conséquences potentielles de l'intégration d'une organisation à une infrastructure de forêt ou de domaine sur les structures du service Active Directory et les propriétaires de la structure de répertoires contraignent l'organisation à approuver tous les administrateurs de service de la forêt et de tous les domaines. Dans ce contexte, approuver les administrateurs de service signifie :

·         croire raisonnablement qu'ils opéreront dans le meilleur intérêt de l'organisation, laquelle ne doit pas rejoindre une forêt ou un domaine si les propriétaires de la forêt ou du domaine peuvent avoir des raisons légitimes de lui nuire ;

·         croire raisonnablement qu'ils suivront les meilleures pratiques et qu'ils imposeront des restrictions en termes d'accès physique aux contrôleurs de domaines ;

·         comprendre et accepter les risques que représentent pour l'organisation des administrateurs malintentionnés ou corrompus.

·         Administrateurs malintentionnés. Il est possible qu'un administrateur digne de confiance décide d'abuser du pouvoir dont il dispose sur le système.

·         Administrateurs corrompus. Un administrateur de confiance peut être corrompu ou forcé à effectuer certaines opérations qui violent la sécurité du système.

Certaines organisations peuvent accepter le risque d'une violation de sécurité par un administrateur de service malintentionné ou corrompu provenant d'une autre partie de l'organisation. Elles jugent peut-être que ce risque est accessoire comparativement aux avantages en termes d'économies financières et de collaboration qu'elles tirent à faire partie d'une infrastructure partagée. D'autres peuvent refuser ce risque dans la mesure où les conséquences potentielles d'une violation de la sécurité sont trop graves.


Conception d'unité d'organisation orienté sécurité

Si ce guide n'est pas consacré à la structure Active Directory, certaines informations relatives à la conception sont toutefois nécessaires afin que le lecteur puisse se faire une idée précise de l'utilisation de la stratégie de groupe en vue d'assurer l'administration sécurisée du domaine, des contrôleurs de domaines et des rôles de serveur spécifiques.

Les unités d'organisation simplifient le regroupement des utilisateurs et d'autres entités de sécurité, mais elles offrent en outre un mécanisme efficace pour définir des frontières administratives.

De plus, le recours à des unités d'organisation pour fournir différents objets Stratégie de groupe (GPO, Group Strategy Object) basés sur un rôle de serveur fait partie intégrante de l'architecture de sécurité globale de l'organisation.

Délégation de l'administration

Une unité d'organisation n'est autre qu'un conteneur dans un domaine. Le contrôle d'une unité d'organisation peut être délégué à un groupe ou à un individu en affectant à ce conteneur des listes de contrôle d'accès (ACL, Access Control List) spécifique.

Une unité d'organisation sert généralement à offrir des fonctionnalités administratives similaires à celles des domaines de ressources Microsoft® Windows NT® 4.0. Elle peut également être créée pour contenir un groupe de serveurs de ressources administrés par d'autres utilisateurs. Si ce groupe d'autres utilisateurs peut contrôler de façon autonome cette unité d'organisation particulière, il n'est pas isolé du reste du domaine.

Les administrateurs qui délèguent le contrôle d'unités d'organisation spécifiques sont, dans la plupart des cas, des administrateurs de service. À un niveau d'autorité inférieur, les utilisateurs qui contrôlent les unités d'organisation sont généralement des administrateurs de données.

Groupes d'administration

La création de groupes d'administration offre aux administrateurs un moyen de segmenter les groupes d'utilisateurs, les groupes ou les serveurs en conteneurs afin de leur accorder des fonctions d'administration autonome.

Prenons l'exemple des serveurs d'infrastructure d'un domaine : ces derniers regroupent tous les ordinateurs qui ne sont pas contrôleurs de domaines et qui exécutent des services réseau de base, comme les serveurs DNS, WINS ou DHCP.

Souvent, ces serveurs sont gérés par un groupe d'opérations ou un groupe d'administration de l'infrastructure. Une unité d'organisation peut être employée pour accorder des fonctionnalités d'administration de ces serveurs.

Pour cela, il faut tout d'abord créer une unité d'organisation appelée Serveurs d'infrastructure, dans laquelle tous les serveurs DNS, WINS ou DHCP peuvent ensuite être placés. Un groupe de sécurité global appelé Administrateurs de l'infrastructure peut être créé et les comptes de domaine appropriés peuvent y être ajoutés. Enfin, l'Assistant Délégation de contrôle peut être exécuté pour donner à ce groupe le contrôle total sur l'unité d'organisation. La figure ci-dessous propose une vue générale de cette unité d'organisation.

Figure 5.1.

Délégation de l'administration à l'unité d'organisation.

Il s'agit là d'une des nombreuses méthodes d'utilisation possibles des unités d'organisation pour établir une segmentation de l'administration. Si votre organisation est plus complexe, reportez-vous aux autres références répertoriées à la fin de ce chapitre.

Au terme de cette procédure, le groupe Administrateurs de l'infrastructure doit disposer du contrôle total sur l'unité d'organisation Serveurs d'infrastructure et sur tous les serveurs et objets qu'elle contient. Ainsi s'achève l'étape préparatoire de la phase  « sécurisation des rôles de serveur à l'aide d'une stratégie de groupe ».


Application de la stratégie de groupe

La stratégie de groupe peut être associée à la délégation de l'administration pour garantir l'application des paramètres, des droits et d'un comportement spécifiques à tous les serveurs d'une unité d'organisation. Le recours à la stratégie de groupe au lieu des procédures manuelles simplifie la mise à jour de nombreux serveurs lors des modifications qui ne manqueront pas d'intervenir.

Les stratégies de groupe sont accumulées et appliquées dans l'ordre indiqué ci-dessous.

Figure 5.2.

Hiérarchie d'application des objets Stratégie de groupe.

Comme vous pouvez le constater, les stratégies sont appliquées en commençant par la stratégie locale de l'ordinateur. Après cela, les objets Stratégie de groupe (GPO) sont appliqués au niveau du site puis au niveau du domaine. Si le serveur est imbriqué dans plusieurs unités d'organisation, tous les GPO existant dans l'unité d'organisation de premier niveau sont appliqués en premier lieu. Le processus d'application des GPO se poursuit en respectant un ordre décroissant dans la hiérarchie d'unités d'organisation. Le dernier objet GPO à être appliqué sera celui de l'unité d'organisation locale où se trouve l'objet serveur.

Ce modèle donne lieu à diverses observations.

·         Si plusieurs GPO sont définis à l'un des niveaux de la stratégie de groupe illustrée ci-dessus, un administrateur établira l'ordre dans lequel ces objets seront appliqués. Si la même option est spécifiée dans plusieurs stratégies, la dernière à être appliquée sera prioritaire.

·         Une stratégie de groupe peut être configurée avec l'option Ne pas passer outre. Si vous sélectionnez cette option, d'autres GPO ne peuvent pas remplacer les paramètres configurés dans le cadre de cette stratégie.

Modèles de sécurité

Les modèles de stratégie de groupe sont des fichiers texte. Il est possible d'y apporter des modifications à l'aide du composant logiciel enfichable Modèles de sécurité de la MMC (Microsoft Management Console) ou au moyen d'un simple éditeur de texte tel que le Bloc-notes. Certaines sections des fichiers de modèle contiennent des listes ACL spécifiques définies par le langage SDDL (Security Descriptor Definition Language). Pour plus d'informations sur l'édition des modèles de sécurité et sur SDDL, reportez-vous au site Microsoft® MSDN®.

Centralisation des modèles

Il est très important de stocker les modèles de sécurité utilisés pour la production dans un emplacement sécurisé de votre environnement, accessible uniquement par les administrateurs chargés de l'implémentation de la stratégie de groupe. Par défaut, les modèles de sécurité se trouvent dans le dossier %SystemRoot%\security\templates de tous les ordinateurs Windows 2000.

Ce dossier n'est pas répliqué entre les contrôleurs de domaines. Il faut donc sélectionner un contrôleur de domaine qui hébergera la copie principale des modèles de sécurité de façon à éviter les conflits liés à des versions de modèles différentes. De cette façon, vous êtes certain de toujours modifier le même exemplaire des modèles.

Configuration de l'heure

Il est essentiel de disposer d'une heure système exacte et d'avoir pour tous les serveurs la même source de temps. Le service W32Time de Windows 2000 assure la synchronisation des heures pour les ordinateurs Microsoft® Windows® 2000 et Microsoft® Windows® XP appartenant à un domaine Active Directory.

Il garantit la synchronisation de toutes les horloges des systèmes clients Windows 2000 avec celles des contrôleurs du domaine, élément indispensable au bon fonctionnement du protocole d'authentification Kerberos version 5. La synchronisation de l'heure facilite également l'analyse des journaux des événements.

Kerberos est un protocole d'authentification réseau développé par le MIT (Massachusetts Institute of Technology). Il authentifie l'identité des utilisateurs qui tentent de se connecter au réseau et crypte leurs communications par une technique basée sur une clé secrète.

Le service W32Time synchronise les horloges à l'aide du protocole SNTP (Simple Network Time Protocol) conformément à la RFC 1769. Dans une forêt Windows 2000 Server, l'heure est synchronisée comme suit :

·         Le maître des opérations émulateur du contrôleur principal (PDC) du domaine racine de la forêt est la source de temps qui fait autorité pour l'organisation.

·         Tous les maîtres des opérations PDC des autres domaines de la forêt respectent la hiérarchie de domaines lors de la sélection d'un émulateur PDC avec lequel synchroniser l'heure.

·         Tous les contrôleurs d'un domaine synchronisent leur heure avec le maître des opérations de l'émulateur PDC dans leur domaine en tant que partenaires de service de temps entrant.

·         Tous les serveurs membres et les ordinateurs clients utilisent le contrôleur de domaine d'authentification comme leur partenaire pour la synchronisation du temps.

Pour s'assurer que l'heure est exacte, l'émulateur PDC du domaine racine de la forêt peut être synchronisé avec un serveur de temps SNTP externe. Toutefois, cette opération peut exiger l'ouverture de ports du pare-feu, c'est pourquoi il est indispensable de mettre en balance au préalable les avantages offerts par l'opération et le risque de sécurité potentiel qu'elle présente.

Souvent, il n'est pas nécessaire que tous les serveurs soient synchronisés avec une source de temps externe, à condition qu'ils le soient avec la même source de temps à l'intérieur du réseau de l'organisation.

Si votre réseau comprend des ordinateurs Microsoft® Windows® 95 ou Microsoft® Windows® 98, les horloges de ces ordinateurs doivent être synchronisées en insérant la commande suivante dans un script d'ouverture de session où <ordinateur_temps> est un contrôleur de domaine du réseau :

net time \\<ordinateur_temps> /set /yes

L'exécution de cette commande permet d'empêcher que les horloges de ces ordinateurs présentent une différence de temps par rapport à d'autres ordinateurs du domaine.

Remarque : Les ordinateurs du réseau exécutant des systèmes d'exploitation non-Windows doivent également synchroniser leurs horloges avec l'émulateur PDC du domaine Windows 2000 pour permettre une analyse des événements du journal basée sur la même heure.

Unités d'organisation par rôle de serveur

L'exemple précédent illustrant la gestion des serveurs d'infrastructure de l'organisation peut être également étendu au scénario Contoso. L'objectif est de créer une stratégie de groupe générale qui englobe tous les serveurs, tout en s'assurant que les serveurs résidant dans Active Directory respectent les normes de sécurité requises par votre environnement.

Stratégie de domaine

La première étape de ce processus consiste à créer une nouvelle stratégie au niveau du domaine. En effet, la stratégie de domaine par défaut de Windows 2000 doit être mieux sécurisée. L'administrateur doit créer une nouvelle stratégie et la lier à l'objet GPO du domaine. Pour être certain que cette nouvelle stratégie a la priorité sur la stratégie par défaut, déplacez-la pour qu'elle présente le niveau de priorité le plus élevé dans les liaisons de l'objet Stratégie de groupe.

Il est évidemment toujours possible de modifier directement la stratégie par défaut pour créer une nouvelle configuration de sécurité, mais la création d'une toute nouvelle stratégie permet en cas de problème une désactivation facile et le remplacement de la nouvelle stratégie par la stratégie de domaine par défaut.

Stratégie de base

La deuxième étape consiste à créer une stratégie de base. Pour cela, il faut créer un modèle de sécurité de base et l'importer dans la stratégie. Le modèle MSS Baseline.inf, inclus dans cette solution, fournit cette fonctionnalité. Ce modèle de sécurité GPO doit être lié à l'unité d'organisation Serveurs membres. Le modèle MSS Baseline.inf applique les paramètres de la stratégie de base à tous les serveurs de l'unité d'organisation Serveurs membres ainsi qu'à ceux des unités d'organisation enfants.

La stratégie de base doit définir les paramètres voulus pour tous les serveurs de l'organisation. Elle doit en outre être aussi restrictive que possible, et tous les serveurs auxquels elle ne doit pas être appliquée doivent être placés dans des unités d'organisation de serveurs spécifiques, comme l'unité d'organisation Serveurs d'infrastructure.

Unités d'organisation par rôle de serveur

Pour reprendre l'exemple ci-dessus, une stratégie distincte, contenant les modifications incrémentielles, doit être créée pour les serveurs d'infrastructure. Un modèle de sécurité appelé MSS Infrastructure Role.inf peut contenir tous les paramètres nécessaires pour assurer le bon fonctionnement des services d'infrastructure et leur disponibilité sur l'ensemble du réseau.

Ce GPO doit être lié à l'unité d'organisation Infrastructure. Enfin, le paramètre Groupes restreints doit être utilisé pour ajouter les trois groupes suivants au groupe Administrateurs locaux de l'objet GPO Stratégie d'infrastructure : Administrateurs du domaine, Administrateurs de l'entreprise et Administrateurs de l'infrastructure.

Ce processus est illustré par la figure ci-dessous.

Figure 5.3.

Configuration de stratégies de groupe incrémentielles.

Pour rappel, il s'agit là d'une des nombreuses approches possibles pour créer une structure d'unités d'organisation en vue du déploiement d'objets GPO.

Pour plus d'informations sur la création d'unités d'organisation en vue de l'implémentation de la stratégie de groupe, reportez-vous à l'article Microsoft® TechNet intitulé « Best Practice Active Directory Design for Managing Windows Networks » (en anglais), disponible à l'adresse suivante : http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/ad/windows2000/deploy/depovg/bpaddply.asp.

 

Dans ce guide, plusieurs rôles de serveur sont définis. Les modèles de sécurité indiqués dans le tableau suivant ont été créés conformément au processus décrit plus haut, afin de renforcer la sécurité pour ces rôles.

Tableau 5.1. Rôles de serveur Windows 2000

Rôle de serveur

Description

Modèle de sécurité

Contrôleur de domaine Windows 2000

Groupe contenant les contrôleurs de domaine Active Directory.

MSS DCBaseline.inf

Serveurs membres Windows 2000 

Tous les serveurs membres du domaine résidant dans l'unité d'organisation des serveurs membres ou sous son arborescence

MSS Baseline.inf

Serveur de fichiers et d'impression Windows 2000

Groupe contenant les serveurs de fichiers et d'impression.

MSS FilePrint Role.inf

Serveur d'infrastructure Windows 2000

Groupe contenant les serveurs DNS, WINS et DHCP.

MSS Infrastructure Role.inf

Serveur IIS Windows 2000

Groupe contenant les serveurs IIS.

MSS IIS Role.inf

Tous les fichiers de modèle incrémentiel sont censés être appliqués aux unités d'organisation situées sous l'unité d'organisation des serveurs membres. Dès lors, chacune de ces unités d'organisation de niveau inférieur doit se voir appliquer à la fois le modèle MSS Baseline.inf et le fichier incrémentiel spécifique, afin de définir le rôle que chacune va jouer dans l'organisation.

Chacun de ces rôles répond à des impératifs différents sur le plan de la sécurité. Les paramètres de sécurité requis pour chacun d'eux sont décrits dans le détail au chapitre 7, « Renforcement de la sécurité pour des rôles de serveur spécifiques ».

Important : Ce guide suppose que les serveurs Windows 2000 remplissent des rôles spécifiques définis. Si les serveurs de votre entreprise ne correspondent pas à ces rôles ou s'ils doivent remplir plusieurs fonctions, créez vos propres modèles de sécurité en vous inspirant des paramètres indiqués ici. Il est toutefois important de garder à l'esprit que le degré de vulnérabilité d'un serveur aux attaques croît proportionnellement au nombre de fonctions qu'il doit assumer.

La structure d'unités d'organisation finale nécessaire à la prise en charge de ces rôles de serveur est illustrée dans la figure ci-dessous.

Figure 5.4.

Exemple de structure d'unités d'organisation.


Conception d'OU, de GPO et de groupes administratifs de Contoso

Les recommandations ci-dessus sont appliquées à la société Contoso afin de réorganiser sa structure d'unités d'organisation existante pour les serveurs Windows 2000. De plus, les administrateurs de Contoso utilisent leurs frontières d'administration prédéfinies pour créer leurs groupes administratifs. La corrélation existant entre ces groupes et les unités d'organisation qu'ils gèrent est décrite dans le tableau suivant.

Tableau 5.2. Unités d'organisation et groupes administratifs de Contoso

Nom de l'unité d'organisation

Groupe administratif

Contrôleurs de domaines

Ingénierie du domaine

Serveurs membres

Ingénierie du domaine

Infrastructure

Opérations

Fichiers et impression

Opérations

Web

Services Web

Au sein de Contoso, chaque groupe administratif a été créé en tant que groupe global dans le domaine enfant  NorthAmerica

Contoso a ajouté chacun de ces groupes au groupe restreint approprié au moyen de la GPO correspondante. Les groupes administratifs créés précédemment seront uniquement membres du groupe Administrateurs locaux pour les ordinateurs se trouvant dans les unités d'organisation regroupant les ordinateurs en fonction de leur rôle.

Enfin, Contoso a défini des autorisations sur chaque objet GPO de sorte qu'ils puissent être modifiés uniquement par les administrateurs du groupe ingénierie du domaine.

Par défaut, la nouvelle structure d'unités d'organisation hérite de nombreux paramètres de sécurité de son conteneur parent. La case à cocher Permettre aux autorisations pouvant être héritées du parent d'être propagées à cet objet doit être désactivée pour chaque unité d'organisation. Tous les groupes précédemment créés par les administrateurs qui ne présentent pas réellement d'utilité doivent être supprimés, et le groupe de domaine correspondant à chaque unité d'organisation de rôle de serveur doit être ajouté. Le groupe Administrateurs du domaine doit conserver le contrôle total.

Les tâches requises pour établir ces unités d'organisation ne doivent pas être effectuées dans un ordre particulier, mais il est clair que certaines sont tributaires d'autres tâches. Ainsi, il faut avoir créé les groupes du domaine avant de pouvoir leur déléguer le contrôle des différentes unités d'organisation. Voici l'ordre dans lequel nous vous suggérons d'accomplir ces tâches :

  1. Création de la structure d'unités d'organisation
  2. Déplacement des ordinateurs vers les unités d'organisation adéquates
  3. Création des groupes administratifs
  4. Ajout des comptes de domaine adéquats aux groupes administratifs
  5. Délégation de l'administration de chacune des unités d'organisation aux groupes de domaine appropriés
  6. Création des stratégies de groupe dans l'unité d'organisation où elles seront appliquées
  7. Liaison de chaque stratégie de groupe à d'autres unités d'organisation en fonction des besoins
  8. Importation du modèle de sécurité voulu pour chaque objet GPO
  9. Définition des autorisations de chaque objet GPO pour qu'ils soient contrôlés par les groupes de domaine voulus
  10. Ajout des groupes de domaine requis aux groupes restreints pour chaque objet GPO
  11. Test et amélioration des stratégies de groupe

Stratégie de domaine

Les paramètres de sécurité de la stratégie de groupe peuvent être appliqués à différents niveaux de l'organisation. Contoso a décidé d'utiliser la stratégie de groupe pour appliquer ces paramètres aux trois niveaux suivants :

·         Stratégie de domaine. Pour répondre aux impératifs de sécurité communs, comme les stratégies de comptes à appliquer pour tous les serveurs.

·         Stratégie de base. Pour répondre aux conditions de sécurité requises pour tous les serveurs du réseau.

·         Stratégie de rôle. Pour satisfaire aux exigences de sécurité propres aux différents rôles de serveur. Par exemple, les serveurs d'infrastructure n'ont pas les mêmes impératifs en termes de sécurité que les serveurs Microsoft® Internet Information Services (IIS).

En matière d'audit de sécurité, IIS crée des fichiers journaux assurant le suivi des tentatives de connexion aux services Web, FTP (File Transfer Protocol), NNTP (Network News Time Protocol) et SMTP (Simple Mail Transfer Protocol).

Présentation de la stratégie de domaine

La stratégie de groupe est un outil extrêmement puissant puisqu'elle permet d'appliquer une configuration standard à tous les ordinateurs du réseau. Les GPO constituent un élément essentiel d'une solution de gestion de la configuration pour toute entreprise puisqu'ils offrent aux administrateurs la possibilité d'apporter des modifications de sécurité sur tous les ordinateurs (ou des sous-ensembles d'ordinateurs) du domaine à la fois.

Parmi les types de modifications de sécurité qu'il est possible d'appliquer simultanément à l'aide de la stratégie de groupe, il faut citer celles qui concernent :

·         les autorisations sur le système de fichiers ;

·         les autorisations sur les objets du Registre ;

·         les paramètres du Registre ;

·         les affectations de droits d'utilisateur ;

·         la configuration des services système ;

·         la configuration des journaux d'audit et des événements ;

·         la définition des stratégies de comptes et de mot de passe.

Les paramètres de la stratégie de groupe qui concernent ces modifications de sécurité sont répartis dans plusieurs sections de la stratégie des ordinateurs Windows 2000 Server.

Tableau 5.3. Sections de la stratégie des ordinateurs Windows 2000 Server

Nom de la section de stratégie dans l'interface

Description

Stratégie de comptes\Stratégie de mot de passe

Configure la durée de vie, la longueur et la complexité des mots de passe.

Stratégie de comptes\Stratégie de verrouillage des comptes

Configure la durée et le seuil de verrouillage, ainsi que la réinitialisation du compteur.

Stratégie de comptes\Stratégie Kerberos

Configure la durée de vie des tickets.

Stratégies locales\Stratégie d'audit

Active ou désactive l'enregistrement d'événements spécifiques.

Stratégies locales\Attribution des droits utilisateur

Définit des droits tels que l'ouverture de session en local et l'accès au réseau.

Stratégies locales\Options de sécurité

Modifie des valeurs de Registre spécifiques liées à la sécurité.

Journal des événements

Active la surveillance des réussites et des échecs.

Groupes restreints

Les administrateurs contrôlent les membres de groupes spécifiques.

Services système

Contrôle le mode de démarrage de chaque service.

Registre

Configure les autorisations et l'audit de clés de Registre.

Système de fichiers

Configure les autorisations et l'audit de dossiers, sous-dossiers et fichiers.

Tous les ordinateurs possèdent une stratégie locale prédéfinie. Lors de la création initiale d'un domaine Active Directory, des stratégies de domaine et de contrôleur de domaine par défaut sont également générées. Au lieu de modifier les stratégies par défaut, il est conseillé de créer une nouvelle stratégie et de la lier au domaine, ce qui permettra, le cas échéant, d'annuler tous les paramètres susceptibles de provoquer des problèmes non identifiés dans l'environnement. Si les stratégies par défaut sont modifiées, il est important de documenter les paramètres qu'elles contiennent, de sorte qu'il soit possible de rétablir rapidement les stratégies antérieures en cas de problème.

Figure 5.5.

Application de stratégies de domaine.

La section suivante traite des paramètres au niveau du domaine qu'il convient d'étudier et de documenter.

Stratégies de comptes

Les stratégies de comptes sont implémentées au niveau du domaine. Un domaine Windows 2000 Server doit disposer d'une stratégie de mot de passe unique, d'une stratégie de verrouillage des comptes et d'une stratégie Kerberos version 5 pour le domaine. Si vous définissez ces stratégies à un autre niveau d'Active Directory, elles sont appliquées uniquement aux comptes locaux des serveurs membres. Si certains groupes requièrent des stratégies de mot de passe distinctes, ils doivent être placés dans un autre domaine ou dans une autre forêt, en fonction des exigences supplémentaires qu'ils présentent.

Stratégie de mot de passe

Dans Windows 2000 Server, la méthode la plus courante pour authentifier l'identité d'un utilisateur consiste à recourir à un mot de passe secret. Une fois l'utilisateur identifié et authentifié, il peut accomplir toutes les tâches et accéder à toutes les ressources pour lesquelles il dispose des autorisations appropriées.

La sécurisation d'Active Directory dans votre environnement nécessite l'utilisation de mots de passe forts par tous les utilisateurs. En effet, il existe une menace bien réelle de voir un utilisateur non autorisé deviner un mot de passe trop simple soit manuellement, soit à l'aide d'outils capables d'obtenir les informations d'identification d'un compte utilisateur compromis. Le recours aux mots de passe forts permet de pallier à ce risque. Il est surtout essentiel dans le cas des comptes d'administration.

Un mot de passe complexe qui est modifié régulièrement réduit les chances de réussite d'une attaque des mots de passe. Les paramètres de la stratégie de mot de passe contrôlent la complexité et la durée de vie des mots de passe. Chaque paramètre de compte spécifique de cette stratégie est étudié dans cette section.

Les valeurs suivantes peuvent être configurées dans les paramètres de la stratégie de groupe du domaine, à l'emplacement suivant : Configuration ordinateur\Paramètres Windows\Paramètres de sécurité\Stratégies de comptes\Stratégie de mot de passe

Conserver l'historique des mots de passe

Vulnérabilité

La réutilisation des mots de passe constitue un problème majeur dans toute organisation. Au moins trois modes de réutilisation des mots de passe sont à l'origine de cette vulnérabilité :

·        Réutilisation d'un même mot de passe pour plusieurs comptes de l'organisation. Il arrive fréquemment que des utilisateurs ou des administrateurs possédant plusieurs comptes dans différents domaines (ou associés à différentes fonctions au sein d'un même domaine) choisissent le même mot de passe pour tous leurs comptes.

·        Utilisation ou réutilisation du même mot de passe pour un compte quelconque pendant une période prolongée. Si les utilisateurs sont tenus de changer leur mot de passe, rien ne les empêche de spécifier à nouveau leur ancien mot de passe ou de réutiliser continuellement un nombre réduit de mots de passe. Dès lors, la stratégie de mot de passe est beaucoup moins efficace.

·        Réutilisation du même mot de passe pour plusieurs comptes de service. Si une organisation doit utiliser des comptes de ce type, chacun doit disposer d'un mot de passe unique qui respecte au minimum les normes de base définies en matière de définition de mot de passe afin de s'assurer qu'il soit extrêmement difficile à décoder.

La valeur indiquée pour l'option Conserver l'historique des mots de passe détermine le nombre de nouveaux mots de passe uniques devant être associés à un compte utilisateur avant qu'un ancien mot de passe puisse être réutilisé.

Si vous spécifiez une valeur faible, les utilisateurs peuvent affecter continuellement le même nombre réduit de mots de passe à plusieurs reprises. Si, en outre, vous ne spécifiez pas de valeur pour l'option Durée minimale du mot de passe, les utilisateurs peuvent changer plusieurs fois leur mot de passe mais au final réutiliser leur mot de passe initial.

Pour que l'option Conserver l'historique des mots de passe soit efficace dans votre organisation, la configuration du paramètre Durée minimale du mot de passe doit empêcher que les mots de passe puissent être modifiés immédiatement.

Contre-mesure

Attribuez à l'option Conserver l'historique des mots de passe la valeur 24. Il s'agit de la valeur maximale puisque la plage de valeurs acceptées est de 0 à 24 mots de passe. Ce paramètre est défini avec la valeur 1 dans l'objet GPO Domaine par défaut et dans la stratégie de sécurité locale des stations de travail et des serveurs. Si vous lui affectez la valeur maximale, vous limitez les vulnérabilités liées à la réutilisation des mots de passe.

Impact potentiel

La principale conséquence de ce paramètre est, pour les utilisateurs, de devoir indiquer un tout nouveau mot de passe chaque fois qu'ils doivent modifier l’existant. En obligeant de la sorte les utilisateurs à spécifier systématiquement un nouveau mot de passe encore jamais choisi, vous vous exposez à un autre danger : que certains d'entre eux inscrivent leurs mots de passe quelque part afin de ne pas l'oublier.

Le mieux est de trouver une valeur qui soit un compromis raisonnable pour tous les utilisateurs de l'organisation, tant pour la durée de vie maximale des mots de passe que pour l'intervalle de modification requis.

Scénario Contoso

Dans le scénario Contoso, la valeur 24 a été définie pour le paramètre Conserver l'historique des mots de passe.

Durée maximale du mot de passe

Vulnérabilité

Tout mot de passe peut être décodé. Avec les puissances de traitement atteintes de nos jours, la découverte des mots de passe les plus complexes n'est jamais qu'une question de temps et d'efforts. Certains des paramètres suivants peuvent rendre l'opération plus longue et plus difficile. Toutefois, une modification fréquente des mots de passe dans un environnement contribue à atténuer les risques de décodage et d'utilisation d'un mot de passe obtenu de façon illicite.

Le paramètre Durée maximale du mot de passe détermine le nombre de jours pendant lequel un mot de passe peut être utilisé avant que le système oblige l'utilisateur à le modifier. Sa valeur peut être définie de sorte que les utilisateurs ne soient jamais forcés de changer leurs mots de passe, mais cela représente un risque considérable en termes de sécurité.

Contre-mesure

Attribuez à l'option Durée maximale du mot de passe une valeur située entre 30 et 60 jours. La plage de valeurs possibles va de 1 à 999 jours, mais il est possible de spécifier que le mot de passe ne doit jamais expirer, en spécifiant la valeur 0. Ce paramètre possède la valeur 42 dans l'objet GPO Domaine par défaut et dans la stratégie de sécurité locale des stations de travail et des serveurs.

Impact potentiel

Si vous spécifiez pour ce paramètre un trop petit nombre de jours, les utilisateurs devront modifier leurs mots de passe très souvent. Au bout du compte, une telle mesure peut être dangereuse pour la sécurité de l'organisation car elle peut augmenter les risques qu'un utilisateur inscrive son mot de passe sur un post-il pour éviter de l'oublier. Il en va de même lorsqu'une valeur excessive est spécifiée puisque, potentiellement, les pirates disposent de plus de temps pour décoder les mots de passe.

Scénario Contoso

Dans le scénario Contoso, la valeur 42 jours a été définie pour le paramètre Durée maximale du mot de passe.

Cette valeur renforce la sécurité de l'environnement de Contoso puisque les utilisateurs sont tenus de changer de mot de passe régulièrement mais pas trop souvent, ce qui limite les désagréments causés aux utilisateurs.

Durée minimale du mot de passe

Vulnérabilité

Les utilisateurs qui souhaitent réutiliser un mot de passe peuvent être obligés de le modifier régulièrement. Si une stratégie est mise en place pour qu'ils ne puissent pas réutiliser leurs 12 derniers mots de passe, il leur suffit de changer consécutivement leur mot de passe 13 fois pour revenir au mot de passe initial.

Le paramètre Durée minimale du mot de passe détermine le nombre de jours pendant lesquels un mot de passe peut être utilisé avant qu'un utilisateur ne soit autorisé à le changer. La valeur spécifiée doit être inférieure à la valeur choisie comme durée maximale du mot de passe.

Pour rappel, une valeur supérieure à 0 doit être attribuée au paramètre Durée minimale du mot de passe pour que le paramètre Conserver l'historique des mots de passe soit efficace. En l'absence d'une durée minimale des mots de passe, l'utilisateur peut modifier son mot de passe plusieurs fois de suite, pour revenir à son ancien mot de passe favori.

Contre-mesure

Attribuez à l'option Durée minimale du mot de passe la valeur 2 jours. Cette valeur peut se situer entre 1 et 998 jours. Il est même possible de spécifier la valeur 0, qui permet de modifier plusieurs fois de suite un mot de passe, mais cela n'est pas recommandé. Ce paramètre n'est pas défini dans l'objet GPO Domaine par défaut et dans la stratégie de sécurité locale des stations de travail et des serveurs, si bien que le mot de passe peut être modifié plusieurs fois à la suite.

Impact potentiel

L'attribution d'une valeur supérieure à 0 au paramètre Durée minimale du mot de passe pose un problème mineur. Si un administrateur définit temporairement un mot de passe pour un utilisateur et souhaite que celui-ci change ce mot de passe, il doit activer la case à cocher L'utilisateur doit changer de mot de passe à la prochaine ouverture de session. Sans cela, l'utilisateur ne pourra effectuer de modification avant le lendemain.

Scénario Contoso

Dans le scénario Contoso, le paramètre Durée de vie minimale du mot de passe a été établi à 2 jours, de façon à éviter la tentation d’enregistrer successivement des mots de passe pour revenir au final à un mot de passe familier.

Longueur minimale du mot de passe

Vulnérabilité

Plusieurs types d'attaques permettent d'obtenir le mot de passe d'un compte utilisateur particulier. Citons notamment les attaques par dictionnaire, qui consistent à essayer une multitude de mots et expressions courantes, et les attaques par force brute, qui tentent toutes les combinaisons possibles de chiffres et de lettres. Une attaque peut également s'appuyer sur la découverte du hachage de mot de passe LM et sur l'emploi d'utilitaires pour décoder les hachages et identifier les mots de passe.

La longueur minimale du mot de passe détermine le nombre minimal de caractères composant le mot de passe d'un compte utilisateur. Plusieurs théories ont été avancées pour déterminer la longueur de mot de passe idéale pour une organisation.

Contre-mesure

Attribuez au paramètre Longueur minimale du mot de passe la valeur 8 au moins. Les valeurs acceptables sont comprises entre 1 et 14 caractères. Aucun mot de passe n'est requis si vous spécifiez une longueur de 0. Ce paramètre possède la valeur 0 dans l'objet GPO Domaine par défaut et dans la stratégie de sécurité locale des stations de travail et des serveurs.

Dans la majorité des environnements, une longueur de mot de passe de 8 caractères est recommandée, puisque ce nombre suffit à fournir un niveau de sécurité correct tout en garantissant des mots de passe faciles à mémoriser. Cette valeur assure une mesure de défense adéquate contre les attaques par force brute. Si, parmi les conditions requises, figure en outre la complexité des mots de passe, les risques de voir une attaque par dictionnaire aboutir sont réduits. Nous aborderons les conventions de complexité à la section suivante.

L'attaque visant à découvrir le hachage de mot de passe est décrite dans le détail au chapitre 6, « Renforcement de la sécurité du serveur Windows 2000 de base ».

Impact potentiel

Si la longueur minimale du mot de passe définie est trop faible, la sécurité est réduite puisque les mots de passe courts peuvent être facilement décodés à l'aide d'outils spécialisés d'attaques par dictionnaire ou par force brute. En revanche, une longueur excessive augmente les risques de d’erreurs lors de la saisie des mots de passe, donc éventuellement des verrouillages de compte et, par suite, une hausse du volume d'appels au service d'assistance technique.

A fortiori, si des mots de passe extrêmement longs sont requis, cela peut finir par nuire à la sécurité d'une organisation car les utilisateurs noteront vraisemblablement leur mot de passe par crainte de l'oublier.

Scénario Contoso

Le scénario Contoso prévoit 8 caractères comme valeur de Longueur minimale du mot de passe.

Les mots de passe doivent respecter certaines exigences

Vulnérabilité

Les mots de passe contenant uniquement des caractères alphanumériques sont extrêmement faciles à décoder à l'aide de plusieurs utilitaires accessibles au grand public. Pour éviter cela, les mots de passe doivent contenir des caractères spéciaux et être soumis à certaines exigences de complexité.

Le paramètre Les mots de passe doivent respecter des exigences de complexité détermine si les mots de passe doivent respecter une série de conventions considérées comme importantes pour obtenir des mots de passe forts.

Si ce paramètre de stratégie est activé, les mots de passe doivent être conformes aux exigences suivantes :

·         Le mot de passe ne doit pas contenir la totalité ou une partie du nom du compte utilisateur.

·         Le mot de passe doit comporter au minimum six caractères.

·         Le mot de passe doit contenir des caractères appartenant à trois des quatre catégories suivantes :

·         caractères majuscules (de A à Z) ;

·         caractères minuscules (de a à z) ;

·         chiffres de 0 à 9 ;

·         caractères non alphanumériques (comme !, $, # ou %).

Ces exigences de complexité sont appliquées lors de la modification ou de la création de nouveaux mots de passe.

Les règles incluses dans la stratégie Windows 2000 Server ne peuvent pas être modifiées directement. Toutefois, une nouvelle version du fichier passfilt.dll peut être créée, afin d'appliquer un autre jeu de règles. Vous trouverez le code source de passfilt.dll dans l'article 151082 de la Base de connaissances Microsoft, intitulé « HOW TO: Password Change Filtering & Notification in Windows NT » (en anglais).

Contre-mesure

Attribuez à l'option Les mots de passe doivent respecter des exigences de complexité la valeur Activé. Ce paramètre est désactivé dans l'objet GPO Domaine par défaut et dans la stratégie de sécurité locale des stations de travail et des serveurs.

Son activation, associée à une longueur minimale du mot de passe de 8 caractères, garantit qu'il existe au minimum 218 340 105 584 896 possibilités différentes de mots de passe, ce qui rend une attaque par force brute très difficile, voire impossible.

Impact potentiel

Si vous activez le fichier passfilt.dll par défaut, il se peut que vous constatiez une augmentation du volume d'appels au service d'assistance technique pour cause de comptes d'utilisateur verrouillés. En effet, les utilisateurs ne sont peut-être pas familiers avec les mots de passe contenant des caractères différents de ceux que l'on trouve dans l'alphabet. Toutefois, ce paramètre offre suffisamment de liberté pour que tous les utilisateurs puissent se faire aux exigences de complexité en un temps réduit.

D'autres exigences peuvent être stipulées dans un fichier passfilt.dll personnalisé, par exemple l'emploi de caractères non associés à la ligne de touches supérieure du clavier, c'est-à-dire ceux saisis en maintenant la touche maj enfoncée et en appuyant sur l'une des touches correspondant aux chiffres de 1 à 0 (sur un clavier US).

De plus, l'utilisation des combinaisons de caractères avec la touche alt peut augmenter considérablement la complexité d'un mot de passe. Toutefois, un tel niveau d'exigences de complexité dans l'ensemble de l'organisation peut provoquer le mécontentement des utilisateurs et se traduire par un service d'assistance technique débordé. Vous pouvez envisager de mettre en vigueur une convention qui requiert l'utilisation de caractères accessibles au moyen de la combinaison de touches alt + 0128 à 0159 pour tous les mots de passe d'administrateur. En dehors de cette plage, les caractères obtenus représentent souvent des caractères alphanumériques standards n'apportant rien à la complexité des mots de passe.

Scénario Contoso

Dans le scénario Contoso, la valeur Activé a été définie pour le paramètre Les mots de passe doivent respecter des exigences de complexité.

Stocker le mot de passe en utilisant le cryptage réversible pour tous les utilisateurs du domaine

Vulnérabilité

Certaines applications peuvent nécessiter l'accès via des mots de passe utilisateur pour proposer des fonctionnalités supplémentaires. Souvent, il faut pour cela que le stockage du mot de passe dans un format à « cryptage réversible », et donc non sécurisé, soit autorisé.

Le paramètre Stocker le mot de passe en utilisant le cryptage réversible pour tous les utilisateurs du domaine détermine si Windows 2000 Server stocke les mots de passe dans un format nettement moins sécurisé, comparable à du texte en clair, donc non crypté (on parle aussi parfois de message en texte brut). Son activation affaiblit les mots de passe de votre environnement.

Impact potentiel

Ce paramètre de stratégie est requis lorsque le protocole d'authentification CHAP est utilisé via les services d'accès distant ou d'authentification Internet (IAS, Internet Authentication Service), mais également lors de l'utilisation de l'authentification Digest dans IIS. Il est extrêmement dangereux d'appliquer ce paramètre à l'aide de la stratégie de groupe au cas par cas en fonction de l'utilisateur, car cela nécessite l'ouverture de l'objet de compte utilisateur approprié dans la console MMC Utilisateurs et ordinateurs Active Directory.

Avertissement : Ce paramètre de stratégie ne doit jamais être activé à moins que les fonctionnalités de l'application priment sur la nécessité de protéger les mots de passe.

 

Contre-mesure

Attribuez la valeur Désactivé au paramètre Stocker le mot de passe en utilisant le cryptage réversible pour tous les utilisateurs du domaine.

Ce paramètre est désactivé dans l'objet GPO Domaine par défaut et dans la stratégie de sécurité locale des stations de travail et des serveurs.

Scénario Contoso

Dans le scénario Contoso, la valeur Désactivé a été conservée pour le paramètre Stocker le mot de passe en utilisant le cryptage réversible pour tous les utilisateurs du domaine.

Résumé de la stratégie de mot de passe

Quelles que soient les stratégies de domaine définies, les paramètres L'utilisateur doit changer de mot de passe à la prochaine ouverture de session, L'utilisateur ne peut pas changer de mot de passe, Le mot de passe n'expire jamais et Stocker le mot de passe en utilisant le cryptage réversible pour tous les utilisateurs du domaine peuvent être configurés pour n'importe quel utilisateur individuel. Pour cela, il faut afficher l'onglet Compte de la boîte de dialogue des propriétés de l'utilisateur. Ces paramètres de stratégie de mot de passe d'utilisateur individuel priment les stratégies de domaine. Le tableau ci-dessous propose un récapitulatif des paramètres de stratégie de mot de passe dans l'environnement Contoso.

Tableau 5.4. Stratégies de mot de passe de Contoso

Nom du paramètre de stratégie de mot de passe dans l'interface

Valeur

Conserver l'historique des mots de passe 

24 mots de passe mémorisés

Durée maximale du mot de passe

42 jours

Durée minimale du mot de passe

2 jours

Longueur minimale du mot de passe

8 caractères

Les mots de passe doivent respecter des exigences de complexité

Activé

Stocker le mot de passe en utilisant le cryptage réversible pour tous les utilisateurs du domaine

Désactivé

Stratégie de verrouillage des comptes

Si le nombre d'échecs lors de tentatives de saisie de mots de passe dépasse un certain seuil lors de l'ouverture de session dans le système, il s'agit peut-être d'une attaque visant à déterminer le mot de passe d'un compte par tâtonnements successifs. Windows 2000 Server assure le suivi des tentatives d'ouverture de session et peut être configuré de façon à réagir face à ce type d'attaque potentielle en désactivant le compte pendant une période prédéfinie.

Les paramètres de stratégie de verrouillage des comptes contrôlent le seuil de tentatives à l'issue desquelles le système d'exploitation réagit en appliquant certaines mesures.

Durée de verrouillage des comptes

Vulnérabilité

Un pirate peut lancer une attaque par refus de service (DoS) en multipliant les tentatives d'ouverture de session jusqu'à dépasser le seuil de verrouillage des comptes. Si le seuil de verrouillage des comptes est défini, le compte sera verrouillé à l'issue du nombre spécifié de tentatives infructueuses.

Le paramètre Durée de verrouillage des comptes détermine le nombre de minutes pendant lesquelles un compte verrouillé demeure indisponible.

Contre-mesure

Attribuez au paramètre Durée de verrouillage des comptes la valeur 30 minutes. Cette durée peut être comprise entre 1 et 99 999 minutes. Vous pouvez également spécifier la valeur 0 pour désactiver le verrouillage des comptes. Ce paramètre n'est pas défini dans l'objet GPO Domaine par défaut ni dans la stratégie de sécurité locale des stations de travail et des serveurs.

Impact potentiel

S'il peut paraître judicieux d'empêcher le déverrouillage automatique des comptes, une telle mesure risque d'accroître le volume d'appels effectués au service d'assistance technique de l'organisation pour débloquer des comptes verrouillés par erreur.

Scénario Contoso

Dans le scénario Contoso, la valeur spécifiée pour Durée de verrouillage des comptes est de 30 minutes, ce qui limite le nombre d'appels liés au verrouillage des comptes.

Seuil de verrouillage du compte

Vulnérabilité

Les attaques des mots de passe peuvent faire appel à des procédés automatisés pour lancer des milliers de tentatives de combinaisons pour retrouver le mot de passe d'un ou plusieurs comptes d'utilisateur. Les chances de réussite de telles attaques peuvent être réduites par l'application d'une limite au nombre de tentatives d'ouverture de session infructueuses.

Cependant, il est important de souligner qu'une attaque de refus de service peut être menée contre un domaine où le seuil de verrouillage de compte est configuré. En effet, l'auteur d'une attaque hostile peut envoyer par programme une série d'attaques de mots de passe contre tous les utilisateurs de l'organisation et obtenir le verrouillage de tous les comptes si le nombre de tentatives excède le seuil de verrouillage du compte.

Ce dernier détermine le nombre d'échecs autorisés lors de tentatives d'ouverture de session avant que le compte utilisateur soit verrouillé. Si vous spécifiez une valeur pour le paramètre Seuil de verrouillage du compte, alors la valeur de Durée de verrouillage des comptes doit être supérieure ou égale au délai de réinitialisation du compteur.

Contre-mesure

Par défaut, ce paramètre de stratégie a pour valeur 0 dans l'objet GPO Domaine par défaut et dans la stratégie de sécurité locale des stations de travail et des serveurs. Sa valeur maximale est de 999.

Dans la mesure où la configuration comme la non-configuration de ce paramètre peuvent donner lieu à des vulnérabilités, deux contre-mesures distinctes sont proposées. Toute organisation doit faire un choix entre les deux propositions en fonction des menaces identifiées dans son environnement et des risques qu'elle tente d'atténuer. Deux options doivent être prises en compte pour ce paramètre.

·                     Attribuez la valeur 0 au paramètre Seuil de verrouillage du compte, de sorte que les comptes ne soient pas verrouillés. Cette valeur empêche les attaques de refus de service destinées à verrouiller intentionnellement tous les comptes ou des comptes spécifiques. De plus, elle contribue à réduire le volume d'appels au service d'assistance technique car elle permet d'éviter les verrouillages accidentels de compte par leur utilisateur véritable. En revanche, elle n'empêche pas une attaque par force brute, c'est pourquoi elle ne doit être spécifiée que si les deux critères suivants sont réunis :

o        La stratégie de mot de passe force tous les utilisateurs à disposer de mots de passe complexes constitués de 8 caractères au moins.

o        Un mécanisme d'audit efficace est mis en place pour alerter les administrateurs si une série de tentatives d’ouverture de sessions infructueuses se produisent .

·                     Si ces conditions ne sont pas réunies, attribuez au paramètre Seuil de verrouillage du compte une valeur suffisamment élevée pour qu'elle autorise quelques erreurs de la part des utilisateurs lors de la saisie de leur mot de passe sans provoquer le verrouillage de leur compte mais pour qu'une attaque par force brute entraîne malgré tout un verrouillage des comptes visés. Dans ce cas, il recommandé de choisir la valeur 50 (tentatives d'ouvertures de session infructueuses). En spécifiant une valeur élevée telle que celle-là, vous évitez les verrouillages accidentels et, partant, un nombre excessif d'appels au service d'assistance technique mais vous avez peu de chances d'empêcher une éventuelle attaque de refus de service semblable à celle décrite précédemment.

Impact potentiel

Si le seuil de verrouillage du compte est défini, un compte verrouillé peut être utilisé uniquement après sa réinitialisation par un administrateur ou à l'expiration de la durée de verrouillage. Ce paramètre tend à accroître la charge de travail du service d'assistance technique liée à un plus grand nombre d'appels.

Si, en revanche, vous spécifiez la valeur 0 pour le seuil de verrouillage, il est possible qu'une attaque par force brute destinée à décoder des mots de passe ne soit pas détectée.

Scénario Contoso

Dans le scénario Contoso, le seuil de verrouillage du compte a été fixé à 50 (tentatives d'ouvertures de session infructueuses). Cette valeur garantit que les comptes d'utilisateur ne peuvent pas être verrouillés accidentellement ou au moyen d'outils d'analyse des vulnérabilités automatisés, tout en empêchant une attaque des mots de passe par force brute.

Réinitialiser le compteur de verrouillages du compte après

Vulnérabilité

Les utilisateurs peuvent accidentellement verrouiller leur compte s'ils se trompent plusieurs fois en tapant leur mot de passe. Pour réduire les risques d'une telle situation, le paramètre Réinitialiser le compteur de verrouillages du compte après détermine le nombre de minutes devant s'écouler après une tentative d'ouverture de session infructueuse et avant que le compteur de verrouillage soit ramené à 0.

Si vous spécifiez une valeur pour le paramètre Seuil de verrouillage du compte, alors le délai de réinitialisation du compteur doit être supérieur ou égal à la valeur de Durée de verrouillage des comptes.

Contre-mesure

Attribuez à l'option Réinitialiser le compteur de verrouillages du compte après la valeur 30 minutes. La plage de valeurs autorisées est comprise entre 1 et 99 999 minutes. Ce paramètre de stratégie n'est pas défini dans l'objet GPO Domaine par défaut et dans la stratégie de sécurité locale des stations de travail et des serveurs.

Impact potentiel

Si vous ne spécifiez aucune valeur ou que vous définissez une valeur d'intervalle trop longue, une attaque de refus de service pourra aboutir. Un pirate peut décider d'effectuer volontairement un grand nombre de tentatives d'ouvertures de session infructueuses pour tous les comptes d'utilisateur de l'organisation afin de provoquer le verrouillage de ceux-ci. En l'absence d'une stratégie de réinitialisation de comptes verrouillés, les administrateurs devraient déverrouiller manuellement tous les comptes. Si une valeur raisonnable est définie, les comptes d'utilisateur sont verrouillés pendant un certain temps et, à l'issue de cette période, ils sont déverrouillés automatiquement.

Scénario Contoso

Dans le scénario de Contoso, le délai de Réinitialiser le compteur de verrouillages du compte après a été établi à 30 minutes afin de renforcer la sécurité contre les attaques de mots de passe par force brute.

Résumé de la stratégie de verrouillage des comptes

En général, pour accroître la sécurité au sein d'une organisation, il faut augmenter la valeur du paramètre Durée de verrouillage des comptes tout en diminuant celle du Seuil de verrouillage du compte.

Le tableau ci-dessous propose un récapitulatif des paramètres de stratégie de verrouillage de compte dans l'environnement de Contoso.

Tableau 5.5. Résumé de la stratégie de verrouillage des comptes de Contoso

Nom du paramètre de stratégie de verrouillage des comptes dans l'interface

Valeur

Durée de verrouillage des comptes 

30 minutes

Seuil de verrouillage du compte 

50 tentatives d'ouvertures de session infructueuses

Réinitialiser le compteur de verrouillages du compte après

30 minutes

Avec les paramètres définis dans la société Contoso, un utilisateur effectuant 50 tentatives d'ouvertures de session infructueuses en l'espace de 30 minutes voit son compte verrouillé. Le compte est débloqué automatiquement après 30 minutes. Si le compte doit être réinitialisé au cours de cette période de 30 minutes, c'est à l'administrateur du compte de le faire manuellement.

Stratégie Kerberos

Dans Windows 2000 Server, le protocole d'authentification Kerberos version 5 assure le mécanisme par défaut des services d'authentification et fournit les données d'autorisation nécessaires pour qu'un utilisateur puisse accéder à une ressource et y effectuer une tâche. En réduisant la durée de vie des tickets Kerberos, vous diminuez aussi les risques de voir les informations d'identification d'un utilisateur légitime être volées et exploitées à mauvais escient par un intrus. Toutefois, cela accroît les ressources de traitement nécessaires au processus d'autorisation.

Dans la plupart des environnements, ces paramètres ne doivent pas être modifiés.

Résumé de la stratégie Kerberos

Contoso a décidé de conserver les paramètres par défaut de sa stratégie Kerberos version 5. Ces paramètres sont indiqués dans le tableau ci-dessous.

Tableau 5.6. Paramètres de la stratégie Kerberos

Nom du paramètre de stratégie Kerberos dans l'interface

Valeur

Appliquer les restrictions pour l'ouverture de session

Activé

Durée de vie maximale du ticket de service

600 minutes

Durée de vie maximale du ticket utilisateur

10 heures

Durée de vie maximale pour le renouvellement du ticket utilisateur

7 jours

Tolérance maximale pour la synchronisation de l'horloge de l'ordinateur

5 minutes

Les valeurs par défaut des paramètres de stratégie Kerberos sont conservées. Par conséquent, elles ne sont pas définies spécifiquement dans l'environnement Contoso ou le fichier MSS Domain. inf inclus dans la documentation de travail accompagnant cette solution.

Autres stratégies

Il existe un certain nombre de stratégies supplémentaires qui seront configurées dans le cadre d'une stratégie de base pour tous les serveurs membres de Contoso, ainsi que d'autres paramètres réservés à de nombreux rôles de serveur spécifiques. Ceux-ci sont étudiés au chapitre 6, « Renforcement de la sécurité du serveur Windows 2000 de base » et au chapitre 7, « Renforcement de la sécurité pour des rôles de serveur spécifiques ».

Stratégie de gestion

Importation des modèles de sécurité

La procédure suivante permet d'importer, dans la structure d'unités d'organisation suggérée dans ce chapitre, les modèles de sécurité inclus dans ce guide. Avant d'implémenter la procédure suivante sur un contrôleur de domaine, les fichiers de stratégie spécifiques (.inf) doivent être placés sur un serveur Windows 2000 Server de votre environnement.

Avertissement : Les modèles de sécurité de ce guide sont conçus pour renforcer la sécurité de votre environnement. Lors de leur installation, il peut arriver que certaines fonctionnalités soient désactivées, voire que des applications essentielles ne puissent plus être exécutées.
Il est par conséquent essentiel de tester soigneusement ces modèles avant de les déployer dans un environnement de production. Procédez à une sauvegarde de tous les serveurs et contrôleurs de domaines de votre environnement avant d'appliquer de nouveaux paramètres de sécurité. Veillez à inclure l'état système dans la sauvegarde afin que les paramètres du Registre ou les objets Active Directory puissent être restaurés.

 

Avant de poursuivre la procédure d'importation des modèles de sécurité, si les serveurs de votre environnement n'exécutent pas Windows 2000 avec le SP3 au minimum (comme le recommande ce guide), appliquez le correctif logiciel décrit dans l'article Q295444 de la Base de connaissances, intitulé « SCE Cannot Alter a Service's SACL Entry in the Registry ».

Si vous n'appliquez pas ce correctif, les modèles de stratégie de groupe ne pourront désactiver aucun service. Un correctif logiciel est un package cumulatif composé d'un ou de plusieurs fichiers permettant de résoudre un défaut présent dans un produit. Il pallie une situation problématique spécifique d'un client et ne peut pas être distribué à l'extérieur de l'organisation de celui-ci sans le consentement écrit de Microsoft. L'acronyme QFE (Quick-Fix Engineering), ainsi que les expressions « correctifs de sécurité » et « mises à jour » sont également utilisées pour désigner un correctif logiciel.

Importation de la stratégie de domaine
  1. Dans Utilisateurs et ordinateurs Active Directory, cliquez avec le bouton droit sur Domaine, puis sélectionnez Propriétés.
  2. Dans l'onglet Stratégie de groupe, cliquez sur Nouveau pour ajouter un nouvel objet GPO.
  3. Tapez Stratégie de sécurité du domaine et appuyez sur entrée.
  4. Cliquez avec le bouton droit sur Stratégie de sécurité du domaine et sélectionnez Ne pas passer outre.
  5. Sélectionnez Stratégie de sécurité du domaine et cliquez sur Modifier.
  6. Dans la fenêtre Stratégie de groupe, cliquez sur Configuration Ordinateur\Paramètres Windows. Cliquez avec le bouton droit sur Paramètres de sécurité et sélectionnez Importer une stratégie.
  7. Dans la boîte de dialogue Importer la stratégie à partir de, accédez à \SCI\Modèles de sécurité, et double-cliquez sur MSS Domain.inf.
  8. Fermez la Stratégie de groupe modifiée.
  9. Fermez la fenêtre Propriétés de Domaine.
  10. Forcez la réplication entre les contrôleurs de domaines pour que tous disposent de la nouvelle stratégie en procédant comme suit :
    1. Ouvrez une invite de commandes et, à l'aide de l'outil Secedit.exe, forcez le contrôleur de domaine à actualiser la stratégie de domaine en tapant :
      secedit /refreshpolicy stratégie_ordinateur /enforce.
  1. Vérifiez le journal des événements pour vous assurer que la stratégie a été téléchargée correctement et que le serveur peut communiquer avec les autres contrôleurs du domaine.

Secedit.exe est un utilitaire de ligne de commande qui, lorsqu'il est appelé à partir d'un fichier de commandes ou d'un planificateur de tâches automatique, peut servir à créer et à appliquer automatiquement des modèles ainsi qu'à analyser la sécurité du système. Il peut également être exécuté dynamiquement à partir d'une ligne de commande.

Il est important de souligner que cette stratégie doit être importée dans tous les autres domaines de l'organisation. Toutefois, il n'est pas rare de rencontrer des environnements où la stratégie de mot de passe du domaine racine est beaucoup plus stricte que celle des autres domaines. Par ailleurs, il faut s'assurer que tous les autres domaines utilisant cette stratégie ont les mêmes impératifs de gestion. Dans la mesure où la stratégie de mot de passe peut uniquement être définie au niveau du domaine, certaines exigences légales ou commerciales peuvent obliger certains utilisateurs à appartenir à un domaine distinct, simplement afin de pouvoir appliquer une stratégie de mot de passe plus stricte pour ce groupe.

Contoso a choisi d'utiliser la même stratégie pour ses domaines racine et enfants, et elle a implémenté celle-ci au moyen du même fichier MSS Domain.inf.

Des procédures similaires à celles évoquées ci-dessus doivent être utilisées pour appliquer un des modèles suivants pour la stratégie de base et les stratégies incrémentielles.

Événements indiquant la réussite de l'application d'objets GPO

Si vous devez contrôler manuellement tous les paramètres afin de vous assurer qu'ils ont été correctement appliqués sur le serveur de l'organisation, vous devez en outre vérifier qu'un événement figure effectivement dans le journal des événements : cet événement doit informer l'administrateur que la stratégie de domaine a été téléchargée avec succès. Les informations d'événement suivantes doivent apparaître dans le journal d'applications, avec son numéro d'ID d'événement unique :

Type : Information

ID source : SceCli

ID d'événement : 1704

Description : La stratégie de sécurité dans les objets Stratégie de groupe est appliquée correctement.

Si ce message n'apparaît pas dans les minutes qui suivent l'application de la stratégie, exécutez à nouveau l'utilitaire de ligne de commande Secedit.exe pour appliquer la stratégie de domaine, puis redémarrez le serveur pour forcer le téléchargement de la stratégie de domaine.

Par défaut, les paramètres de sécurité sont actualisés toutes les 90 minutes sur une station de travail ou un serveur, et toutes les 5 minutes sur un contrôleur de domaine. L'événement susmentionné apparaît si des changements sont intervenus au cours de cette période. De plus, les paramètres sont actualisés toutes les 16 heures, qu'il y ait eu ou non modification.


Résumé

Plusieurs points doivent être pris en considération lors de l'analyse sécuritaire de la structure de forêt, de domaine et d'unités d'organisation (OU).

Recherchez et documentez tous les impératifs d'isolement et d'autonomie au sein de l'organisation. L'autonomie de stratégie ou encore l'isolement opérationnel, juridique ou réglementaire sont des raisons valables pour envisager la création de structures de forêt complexes.

La possibilité de contrôler les administrateurs de service doit également être étudiée. En effet, des administrateurs de service malveillants peuvent représenter un risque considérable pour l'organisation, de même qu'à un niveau inférieur, des administrateurs de domaine malintentionnés peuvent utiliser à mauvais escient les données de tout domaine de la forêt.

S'il n'est pas toujours simple de modifier la structure de forêt ou de domaine de votre organisation, une telle opération peut être nécessaire pour remédier à certains risques de sécurité encourus par l'entreprise.

Planifiez le déploiement des unités d'organisation au sein de l'organisation en fonction des besoins des administrateurs de service et des administrateurs de données.

Créez un modèle d'unité d'organisation prenant en charge l'utilisation d'objets Stratégie de groupe (GPO) pour la gestion continue des différents rôles de serveur de l'entreprise.

Enfin, examinez tous les paramètres au niveau du domaine. Un seul jeu de stratégies de mot de passe, de verrouillage des comptes et Kerberos version 5 (protocole d'authentification) peut être configuré pour le domaine. D'autres paramètres relatifs aux mots de passe et au verrouillage des comptes n'ont d'incidence que sur les comptes locaux des serveurs membres. Envisagez la configuration de paramètres s'appliquant à tous les serveurs membres du domaine, et assurez-vous qu'ils garantissent un niveau de sécurité adéquat dans l'ensemble de l'organisation.

Autres références

Informations sur la sécurité et la confidentialité propres à Microsoft : http://www.microsoft.com/france/securite

Informations sur les dix lois immuables en matière de sécurité : http://www.microsoft.com/technet/treeview/default.asp?url=/technet/columns/security/ essays/10imlaws.asp (en anglais)

Informations sur la conception en vue de la délégation de l'administration dans Active Directory : http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/ad/windows2000/plan/addeladm.asp (en anglais)

Informations sur la configuration d'un serveur de temps : article 216734 de la Base de connaissances Microsoft, « Procédures pour configurer un serveur de temps faisant autorité dans Windows 2000 »