Vigilance sécuritéL'Assistant de configuration de sécurité

John Morello

Cet article comprend des informations relatives à la version bêta de Windows Server « Longhorn ». Ces informations sont susceptibles d'être modifiées.

Pour de nombreuses organisations informatiques, la sécurisation efficace et permanente des serveurs tient du véritable défi, surtout lorsque ces organisations disposent d'un important parc de machines séparées par de nombreuses frontières et autres limites organisationnelles. Si le renforcement d'un serveur unique représente une tâche relativement simple pour tout administrateur qualifié, le renforcement de dizaines, de centaines, voire de milliers de serveurs

s'avère une autre paire de manches. Au fil du temps, de nombreuses organisations ont élaboré leurs propres listes de vérification ou normes internes en matière de sécurité de serveur ou ont suivi les conseils fournis par Microsoft, le National Institute of Standards and Technology ou d'autres sociétés tierces. Bien que potentiellement très utiles, ces conseils sous forme de documentation ne sont pas, à eux seuls, suffisants pour permettre aux organisations d'appliquer concrètement à leurs réseaux ces méthodes recommandées. Par conséquent, de nombreuses organisations ont choisi de se contenter des paramètres d'installation par défaut ou de consacrer beaucoup de temps et d'efforts à l'élaboration de leurs propres scripts et stratégies pour renforcer les systèmes.

Avec l'arrivée de l'Assistant de configuration de sécurité (SCW) dans Windows Server® 2003 Service Pack 1 (SP1), Microsoft propose désormais une méthode simple et prise en charge pour renforcer les serveurs et réduire leur surface d'attaque, en fonction de leurs rôles respectifs. En combinant les avantages du SCW avec le déploiement centralisé et les fonctionnalités de gestion d'une stratégie de groupe, il est possible d'adapter le SCW aux plus grandes entreprises informatiques. Dans la chronique de ce mois, je vais expliquer comment les organisations informatiques peuvent utiliser le SCW et la stratégie de groupe afin de gérer leurs serveurs de manière plus sécurisée et cohérente tout en réduisant les frais de déploiement et d'exploitation.

Qu'est-ce que le SCW ?

Le SCW est un composant facultatif, installé par le biais de l'option Ajouter/Supprimer des composants Windows® du Panneau de configuration, disponible sur tous les membres de la famille Windows Server 2003 SP1, y compris Windows Server 2003 R2. Un administrateur commence par exécuter le SCW sur un serveur cible pour identifier les rôles remplis par le serveur en question. Le SCW aide ensuite l'administrateur à créer une stratégie de sécurité qui renforce l'ordinateur en utilisant un modèle de moindre privilège. En d'autres termes, le SCW veille à ne rendre disponibles que les services, les fonctionnalités d'applications et les ports nécessaires pour que le serveur puisse remplir ses fonctions ; tout élément non expressément requis pour les rôles du serveur sera désactivé. Cette approche permet de réduire la surface d'attaque du serveur cible. Si vous exécutez des services dont le serveur n'a pas besoin pour jouer son rôle, vous exposez le serveur à un plus grand risque net sans pour autant gagner en capacité ou fonctionnalité. La désactivation de ces services diminue le risque et peut également améliorer les performances du serveur.

Bien que Microsoft ait nettement fait progresser la sécurité avec Windows Server 2003, en réduisant considérablement la surface globale d'attaque par rapport aux précédentes versions de Windows Server, l'architecture de Windows Server 2003 ne repose pas sur un cœur aux multiples composants comparable à celui de Windows Vista™ et de la prochaine version de Windows Server, répondant au nom de code « Longhorn ». Par conséquent, une installation par défaut de Windows Server 2003 peut entraîner l'activation et l'exécution de services n'étant pas requis pour toutes les configurations de rôles du serveur. Par exemple, le service Spouleur d'impressions est activé par défaut mais n'est pas requis pour un ordinateur faisant uniquement office de serveur de base de données.

Concrétisation de la sécurité basée sur les rôles

Au cours de ces dernières années, Microsoft a publié d'innombrables documentations centrées sur la sécurité pour aider les administrateurs à comprendre quels services étaient requis dans divers rôles de serveur et pour fournir des modèles pré-construits pour des rôles bien connus comme les serveurs Web. Toutefois, des conseils comme ceux dispensés par le Guide sur la sécurité de Windows Server 2003 peuvent s'avérer difficiles à appliquer dans des environnements de grande taille, particulièrement lorsque les applications utilisées dans ce type d'environnements sont plus complexes que les installations serveur IIS ou SQL Server de base. La multitude d'applications tierces utilisées par les entreprises complique encore plus la question ; nombreuses sont celles qui présentent des dépendances envers plusieurs rôles de serveur et dont l'application ainsi que la configuration de service requise ne sont pas toujours clairement définies.

Le SCW aborde ces problèmes en encapsulant dans un assistant piloté par l'administrateur toutes les connaissances et méthodes recommandées qui ont trait aux dépendances et sont contenues dans les guides. Par exemple, si un administrateur déploie une nouvelle application métier qui requiert à la fois SQL Server™ et IIS, il n'a plus besoin de consacrer beaucoup de temps à l'exploration du Guide sur la sécurité ni au développement de sa propre liste de dépendances personnalisées. À la place, il peut installer l'application sur le serveur et lancer le SCW. Le SCW détecte les services en cours d'exécution et propose à l'administrateur une liste de rôles à choisir pour le serveur. En fonction du choix de l'administrateur, le SCW génère une stratégie qui désactivera tous les services non requis par la matrice de dépendances pour les rôles. Le SCW fournit également des options pour renforcer le registre, bloquer toute communication réseau superflue et appliquer une stratégie d'audit efficace. Après l'exécution du SCW, l'administrateur peut enregistrer la stratégie du SCW sous forme de fichier XML et l'appliquer à tout autre serveur exécutant la même application métier.

Par conséquent, l'exécution du SCW comporte trois avantages majeurs par rapport aux méthodes classiques, moins automatisées, de sécurisation de Windows Server. Premièrement, l'administrateur a nettement moins besoin (pour ne pas dire plus besoin) de consulter en permanence la documentation du produit afin de déterminer les services et paramètres requis pour une charge de travail donnée. Cette connaissance est intégrée au SCW et l'administrateur peut facilement se procurer les détails nécessaires grâce à une interface à base de questions. Deuxièmement, le SCW regroupe des conseils abordant plusieurs domaines tels que le renforcement des services, la réduction de la surface d'attaque des réseaux, le renforcement des services LDAP et SMB ainsi que le verrouillage du IIS. Auparavant, l'exécution de ces tâches de configuration nécessitait des utilitaires distincts disposant chacun de leurs propres interface et approche. Pour finir, le SCW redirige ses paramètres dans un fichier de stratégie XML et peut, par conséquent, être utilisé dans des scénarios du type « créez une fois, appliquez plusieurs fois ». Que vous déployiez 1 ou 100 serveurs pour prendre en charge une application métier spécifique, la même stratégie SCW peut facilement être appliquée à chacun d'entre eux. Ceci rend les paramètres de sécurité plus cohérents et permet de diminuer les frais d'exploitation. Ceci simplifie également l'annulation de stratégies SCW.

Composants du SCW

Malgré toutes ses fonctionnalités et tous ses avantages, le SCW reste en fait un outil assez simple qui se compose de trois éléments principaux : l'interface de l'Assistant, l'interface de ligne de commande et la base de données de configuration de la sécurité (SCD). Les administrateurs des petites ou moyennes entreprises auront probablement uniquement besoin d'interagir avec l'interface de l'Assistant. Dans des environnements plus grands ou plus complexes, les administrateurs peuvent en revanche utiliser l'interface de ligne de commande pour faciliter l'automatisation des tâches du SCW, comme la transformation d'une stratégie SCW en objet de stratégie de groupe (GPO). En règle générale, seuls les administrateurs avancés souhaitant créer leurs propres rôles SCW personnalisés modifient la SCD.

L'interface de l'Assistant, illustrée à la figure 1, permet aux administrateurs de créer, de modifier, d'appliquer et d'annuler des paramètres de sécurité sur un serveur cible. Elle propose aux administrateurs des choix dans un flux de travail cohérent qui examine les services et paramètres avant d'examiner la connectivité réseau, les stratégies d'audit de sécurité et, en dernier lieu, les paramètres IIS.

Figure 1** Interface du SCW **(Cliquer sur l'image pour l'agrandir)

L'interface de ligne de commande du SCW fournit trois fonctions fondamentales. Elle permet aux administrateurs d'analyser et de configurer plusieurs serveurs (aussi bien locaux que distants) mais aussi d'annuler des stratégies. Elle peut être utilisée pour convertir automatiquement une stratégie SCW basée sur le XML en un GPO pouvant être utilisé de manière native dans des outils de gestion de GPO standard, comme la Console de gestion des stratégies de groupe. L'outil de ligne de commande du SCW, illustré à la figure 2, est enfin utilisé pour enregistrer toute nouvelle extension de la base de données de configuration de la sécurité.

Figure 2** Outil de ligne de commande du SCW **(Cliquer sur l'image pour l'agrandir)

La SCD est simplement un ensemble de fichiers XML qui décrivent en détail les services et paramètres spécifiques requis pour chaque rôle SCW. Ces fichiers se trouvent dans %win­dir%\security\msscw\kbs. Le SCW est fourni par défaut avec plusieurs rôles Windows Server fondamentaux et 12 rôles d'application prédéfinis, dont : BizTalk®, Commerce Server, Exchange Server, Host Integration Server, Internet Security and Acceleration Server, Microsoft Identity Integration Server, Microsoft Operations Manager, Small Business Server, SharePoint® Portal Server, SharePoint Team Services, SQL Server et Systems Management Server. Chaque rôle a son propre fichier XML (voir figure 3). Chaque fois qu'une nouvelle définition de rôle est créée, le fichier XML correspondant est placé dans ce répertoire. Ces fichiers XML standard peuvent être lus avec toute visionneuse de texte ou autre application prenant en charge le XML (voir figure 4).

Figure 3** Rôles prédéfinis **(Cliquer sur l'image pour l'agrandir)

Figure 4** Fichier de configuration du rôle **(Cliquer sur l'image pour l'agrandir)

Association du SCW et de la stratégie de groupe

Le SCW est en soi un formidable outil, mais ce n'est que lorsqu'on le combine à une stratégie de groupe que sa véritable puissance est intégralement dévoilée. Depuis le lancement de Windows® 2000, les recommandations de Microsoft, en matière de sécurisation des serveurs Windows, se concentrent sur l'utilisation d'une stratégie de groupe afin de fournir une application de stratégie cohérente, permanente et gérée de manière centralisée. En regroupant des serveurs en unités d'organisation (UO) en fonction de leurs rôles, les administrateurs peuvent déployer des configurations de sécurité standard dans toute l'entreprise plutôt que de les déployer au niveau individuel des ordinateurs. En misant sur la logique d'accumulation et d'application d'une stratégie de groupe standard, les organisations peuvent concevoir une hiérarchie de rôles de serveur à plusieurs niveaux au sein de laquelle une poignée de stratégies maîtres peuvent sécuriser des centaines, voire des milliers de serveurs individuels. Lorsque des rôles de serveur uniques exigent des modifications des stratégies maîtres, de petites stratégies delta, ciblées sur les rôles, peuvent être créées plus « étroitement » dans la hiérarchie d'UO, sur les serveurs-mêmes. Ceci permet d'effectuer de petits changements afin d'activer des fonctionnalités spécifiques au rôle, sans avoir à dupliquer intégralement la stratégie maître. Cette approche confère aux grandes entreprises les avantages d'une stratégie à gestion centralisée mais aussi une flexibilité permettant de s'adapter, le cas échéant, à des applications spécifiques.

Le véritable défi de cette approche réside dans sa concrétisation. Pour les grandes organisations avec beaucoup d'applications et de rôles de serveur différents, la création du jeu de stratégies approprié est longue et difficile, ou du moins l'était avant l'avènement du SCW. Utiliser le SCW pour générer des stratégies puis attacher ensuite ces stratégies à l'UO appropriée permet de réduire considérablement le temps nécessaire pour déployer une sécurité basée sur les rôles et hébergée dans des répertoires, aussi bien pour les charges de travail existantes que pour celles risquant d'être adoptées plus tard. Pour mieux illustrer comment une organisation peut mettre ceci en place, examinons l'implémentation du SCW et de GPO basés sur les rôles dans une grande entreprise.

Le SCW dans l'entreprise

Pour cet exemple, j'utiliserai le réseau fictif de Contoso. Contoso possède une grande entreprise informatique, complexe et géographiquement dispersée. Espérant réduire ses frais d'exploitation tout en renforçant la sécurité de ses serveurs, Contoso suit les conseils de Microsoft préconisant la création d'une hiérarchie d'UO basée sur les rôles qui sépare et organise les serveurs, sur la base de la charge de travail. Pour créer les stratégies à attacher à ces UO, Contoso utilise le SCW.

Comme le SCW n'est pas installé par défaut, Contoso doit expressément activer le composant du SCW dans son image d'installation autonome. Pour ce faire, l'entreprise ajoute la nouvelle ligne SCW=On à la section [Components] de Unattend.txt. Par la suite, tous les nouveaux systèmes créés avec cette image installeront le composant du SCW lors de l'installation. Notez que le fait de simplement configurer le SCW devant être installé n'applique aucune stratégie sur les ordinateurs puisque les stratégies sont en cours d'élaboration.

Pour appliquer une stratégie par défaut lors du processus d'installation, Contoso modifie dans l'image la section [Commands] du fichier cmdlines.txt afin d'appeler scwcmd avec les options suivantes :

scwcmd configure /p:ContosoBaselinePolicy.xml 

Le fichier texte et le fichier XML doivent tous les deux se trouver dans le répertoire $OEM$ de l'image. Pourquoi Contoso appliquerait-elle une stratégie de référence au moment de la création au lieu de simplement utiliser la stratégie associée à l'UO du niveau supérieur dans le répertoire ? En appliquant une stratégie au moment de la création, Contoso peut garantir la cohérence de la base, que les ordinateurs aient été ajoutés à Active Directory® ou non. Si un serveur est par exemple conçu à des fins de test, l'application de la stratégie de référence au cours du processus de génération garantit au moins la conformité du serveur à la stratégie de sécurité standard de l'organisation, même s'il n'est jamais ajouté à Active Directory de production. Si le serveur est ajouté à Active Directory ultérieurement, l'algorithme de priorité et d'application de la stratégie de groupe remplacera les paramètres locaux par ceux du domaine ou du niveau de l'UO (N'oubliez pas l'ordre de priorité pour l'application des stratégies : local, site, domaine et UO).

Une fois le SCW installé, Contoso peut commencer à créer sa stratégie de référence. La stratégie de référence doit être celle qui est déployée au niveau supérieur de la hiérarchie d'UO de la sécurité basée sur les rôles. Elle est généralement la stratégie la plus restrictive de la hiérarchie. L'idée consiste à avoir une situation par défaut aussi sécurisée que possible, puis d'ouvrir uniquement les services et ports pour les charges de travail individuelles comme l'exigent les rôles de serveur correspondants. Pour ce faire, la stratégie de référence doit être générée en prenant un quelconque serveur nouvellement créé, en y ajoutant l'ensemble standard d'outils et d'utilitaires de gestion de Contoso puis en y exécutant le SCW. Une fois l'installation de base de Windows terminée, Contoso installe par exemple sur le serveur (manuellement ou via le fichier cmdlines.txt) ses outils standard : antivirus, outil de sauvegarde, outil de gestion et outil de surveillance. Puisque chacun de ces outils crée vraisemblablement ses propres services Windows, leur présence sur le serveur avant la création de la stratégie de référence permet au SCW de les prendre en compte au cours de la phase de verrouillage des services.

Une fois le serveur créé, Contoso y exécute le SCW. Le SCW peut être exécuté localement ou à distance et toute personne l'exécutant doit être membre du groupe Administrateurs locaux de l'ordinateur. Si le SCW est exécuté à distance, il fournit une option afin de spécifier le compte utilisateur sous lequel l'exécuter sur l'hôte distant ; si le SCW est exécuté localement, vous pouvez utiliser runas.exe pour accomplir la même chose. La première tâche qu'entreprend le SCW consiste à évaluer les services s'exécutant sur l'ordinateur local et à afficher les rôles actuellement installés (voir figure 5).

Figure 5** Sélectionner et afficher les rôles de serveur **(Cliquer sur l'image pour l'agrandir)

Aucun rôle ne doit être sélectionné sur le serveur de référence de Contoso car l'ordinateur est conçu pour être dans un état extrêmement restreint. Une fois que les rôles exécutés par le serveur ont été sélectionnés, l'étape suivante consiste à identifier les fonctionnalités client requises pour activer des fonctions telles que les mises à jour automatiques, Active Directory ou le client FTP. Pour la majorité des organisations, l'acceptation des paramètres par défaut du SCW (comme illustré dans la figure 6) fournit des fonctionnalités importantes (comme la possibilité d'ajouter un domaine) mais interdit également des fonctions moins cruciales (comme le client FTP).

Figure 6** Fonctionnalités installées **(Cliquer sur l'image pour l'agrandir)

Le SCW poursuit ensuite en vous laissant choisir les outils d'administration spécifiques et les services, autres que ceux par défaut, à autoriser. Ces options de service expliquent pourquoi vous devez exécuter le SCW après l'installation de l'ensemble standard de gestion de serveur de Contoso. Lorsque l'antivirus, l'application de sauvegarde et les applications associées sont installées, le SCW peut alors avoir connaissance de ces services et, par conséquent, les inclure dans ses paramètres de stratégie résultants.

La dernière question de la section Renforcement des services est la suivante : comment gérer des services non spécifiés ? Il s'agit de services pouvant être rencontrés sur d'autres ordinateurs sur lesquels la stratégie du SCW est appliquée, même s'ils ne sont pas exécutés sur l'ordinateur sur lequel la stratégie a été initialement créée. Par exemple, si la stratégie de référence est appliquée à un nouveau serveur avec une nouvelle application tierce, tout service installé par cette application est géré selon le choix effectué ici par l'administrateur. Le SCW autorise l'administrateur à ne pas modifier le mode de démarrage du service ou à le désactiver. La désactivation constitue le choix le plus sûr mais elle doit être utilisée avec précaution car tout service dont l'exécution n'est pas explicitement autorisée ne pourra pas s'exécuter. Pour cette raison, cette option convient le mieux aux environnements haute sécurité bien gérés. Le choix consistant à ne pas changer le mode de démarrage est recommandé pour les autres parties d'une organisation. C'est ainsi l'option choisie dans le cas de Contoso. Avant de mener à bien la partie « Renforcement des services » de ses tâches, le SCW soumet à l'administrateur un rapport mentionnant les services qui seront modifiés.

Une fois le renforcement des services terminé, le SCW fournit des options pour limiter l'accès réseau entrant. A l'instar de la liste des services requis pour un rôle donné, la liste des ports requis pour une charge de travail donnée est incluse dans la base de données XML du SCW.

En fonction des besoins, les administrateurs peuvent configurer des ports supplémentaires et également établir des règles de port par service, comme le montre la figure 7. Pour le serveur de référence de Contoso, seuls les services les plus simples, tels que le Bureau à distance, doivent être autorisés. Toutes les autres exceptions seront configurées dans les stratégies basées sur les rôles, plus bas dans la hiérarchie d'UO.

Figure 7** Afficher et autoriser des ports **(Cliquer sur l'image pour l'agrandir)

Le SCW permet ensuite à l'administrateur de sélectionner des options de registre, comme la signature du trafic de fichiers et d'impression. Encore une fois, dans la configuration de référence, il est idéalement recommandé de choisir les paramètres par défaut les plus sécurisés.

La prochaine série de choix concerne la stratégie d'audit du système. Sur la majorité des systèmes, il est préférable de sélectionner l'option Auditer les activités exécutées avec succès ; l'audit de toutes les activités exige plus de ressources processeur et génère une importante quantité de données dans le journal d'audit. En cas d'attaque présumée ou lorsqu'une analyse plus détaillée est requise, l'audit des échecs peut être activé sur la machine concernée.

Enfin, le SCW propose à l'administrateur des options pour renforcer le IIS. Ces options sont similaires à celles disponibles dans l'outil de verrouillage IIS et sont désormais directement intégrées dans la stratégie SCW.

Une fois toutes les étapes effectuées, le SCW invite l'administrateur à enregistrer le fichier XML. Le fichier enregistré doit alors être converti en un format compris, en mode natif, par la stratégie de groupe. Scwcmd.exe est utilisé pour transformer le fichier XML enregistré en GPO. Voici la commande à entrer :

scwcmd transform /p:ContosoPolicy.xml /g:ContosoBaselineSecurityPolicy 

Cette stratégie est automatiquement créée dans Active Directory et peut être attachée au sommet de la hiérarchie d'UO de renforcement, basée sur les rôles, de Contoso.

Une fois cette stratégie appliquée au niveau supérieur de la hiérarchie, tout ordinateur ajouté à la hiérarchie d'UO héritera de ses paramètres. Lorsque l'ajout d'un ordinateur implique de modifier cette stratégie (comme un serveur IIS nécessitant l'exécution du service W3SVC), les administrateurs de Contoso exécuteront à nouveau le SCW pour ce nouveau rôle de serveur, transformeront cette nouvelle stratégie en GPO puis lieront ce GPO à une nouvelle sous-UO contenant le ou les serveur(s). Comme le GPO le plus proche du serveur a la préséance, tous les paramètres de base seront par conséquent en place, à l'exception de ceux devant être modifiés afin d'activer la fonctionnalité de rôle désirée pour cette UO (voir figure 8).

Figure 8** Application de la stratégie au niveau de Contoso **(Cliquer sur l'image pour l'agrandir)

La véritable puissance de cette approche apparaît clairement au sein des plus grandes organisations ou lorsque de nombreux serveurs sont déployés. Après que la stratégie SCW initiale a été créée et qu'elle a été attachée à une UO, les futurs serveurs ont juste besoin d'être ajoutés à cette UO : ils hériteront automatiquement de la stratégie de sécurité appropriée. Par conséquent, une fois le jeu de stratégies initial créé puis ajouté à Active Directory, le déploiement de nouveaux serveurs ou le remplacement de serveurs existants devient un processus simple et rapide.

À l’horizon

Dans la prochaine version de Windows Server « Longhorn », Microsoft a considérablement multiplié les composants du système d'exploitation, ce qui se traduit par une surface d'attaque réduite et rationalisée, dès l'installation. Au lieu de se concentrer sur le verrouillage de l'installation minimale par défaut, les administrateurs utiliseront plutôt l'outil Gestionnaire de serveur pour ajouter les charges de travail et rôles requis sur chaque serveur. Le fonctionnement du Gestionnaire de serveur ressemble beaucoup à celui du SCW : le Gestionnaire est doté d'une base de données de dépendances interne qui permet au programme d'installation d'ajouter uniquement les fonctionnalités requises pour fournir le service du rôle désiré. De plus, la sécurité basée sur les rôles, gérée de manière centralisée et utilisant une stratégie de groupe, abordée dans cet article, est encore renforcée par le développement considérable de l'ensemble de fonctionnalités contrôlées par GPO. Pour résumer, Windows Server « Longhorn » fait franchir une étape supplémentaire au concept du SCW en le dotant d'une plus grande flexibilité et d'une méthode de sécurité renforcée et ce, dès l'installation.

Ressources SCW

Les pages Web suivantes vous aideront pour commencer à utiliser le SCW :

• Documentation de l'Assistant de configuration de sécurité
• Assistant de configuration de sécurité pour Windows Server 2003
• Windows Server « Longhorn »

John Morello est diplômé de la Louisiana State University et a occupé plusieurs postes chez Microsoft, qu'il a rejoint il y a six ans. En tant que consultant senior, il a conçu des solutions de sécurité pour des entreprises classées dans Fortune 100 ainsi que des clients civils et militaires du Gouvernement. Il est actuellement responsable senior de programme dans le groupe Windows Server qui se consacre aux technologies de sécurité et d’accès distant.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.