Guide de planification de la sécurité des services et comptes de service

Chapitre 2 - Approche en matière de sécurisation de l'exécution des services

Dernière mise à jour le 31 mai 2005

Le présent chapitre fournit des détails sur les risques inhérents à l'exécution de services et aborde les types de comptes utilisés pour exécuter les services. Il décrit également les principes et stratégies à appliquer lorsque vous planifiez une procédure pour exécuter les services de façon plus sécurisée.

Sur cette page

Vulnérabilités de service
Comptes système
Comptes utilisateur
Modifications apportées aux paramètres de sécurité par défaut dans Windows Server 2003
Principes pour exécuter les services de façon plus sécurisée

Vulnérabilités de service

Les services ont la particularité de s'exécuter automatiquement au démarrage, ce qui les rend idéaux pour les applications de type serveur telles que les services Web. Toutefois, cette caractéristique a ses inconvénients puisqu'un utilisateur peut ignorer qu'un service est en cours d'exécution. Bien qu'ils puissent parfois ouvrir une fenêtre ou une boîte de dialogue visible par l'utilisateur, les services demandent en général peu ou pas d'intervention de la part de l'utilisateur. Aussi, un utilisateur peut exécuter un certain nombre de services par défaut sans jamais être conscient des risques potentiels en termes de sécurité. Certains vers rencontrés récemment sur Internet, comme Nimda, exploitent cette vulnérabilité et utilisent la station de travail d'un utilisateur comme serveur Web totalement à son insu. Les stations de travail infectées répandent alors le ver vers des milliers d'ordinateurs sur Internet.

Certains services, en particulier ceux qu'utilisent les outils de gestion d'entreprise comme Microsoft® Systems Management Server, Microsoft Operations Manager et Tivoli, sont obligés d'ouvrir leurs sessions au moyen d'un compte utilisateur de domaine parce qu'ils ont généralement besoin d'accéder au domaine entier, voire à d'autres domaines approuvés. Dans d'autres cas de figure, l'exécution de services au moyen d'un compte utilisateur de domaine était, jadis, une pratique courante. Récemment, les entreprises ont toutefois reconnu que cette méthode présentait un risque en matière de sécurité.

Le nom d'utilisateur et le mot de passe de chaque service qui utilise un compte de domaine ou un compte utilisateur local sont stockés dans le Registre. Un attaquant peut donc tenter de s'en servir pour obtenir un accès d'administrateur à l'ordinateur. Par conséquent, un risque de sécurité se pose dès que vous configurez un service pour qu'il ouvre une session en tant qu'utilisateur.

Étant donné qu'un risque de sécurité est créé à chaque fois qu'un service est configuré pour ouvrir une session en tant que compte utilisateur de domaine, la possibilité d'exploiter cette vulnérabilité augmente en fonction de divers facteurs.

  • Nombre de serveurs sur lesquels un compte utilisateur de domaine donné est configuré pour exécuter des services. Dans un environnement serveur bien géré, tous les serveurs devraient être aussi sécurisés les uns que les autres. Une entreprise qui ne sécurise pas tous ses serveurs de la même façon court le risque de voir le risque d'exploitation augmenter sur chacun de ses serveurs plus exposés. Plus le nombre de serveurs sur lesquels le service authentifié par le domaine s'exécute est élevé, plus vous risquez que quelqu'un exploite la vulnérabilité de sécurité. Par exemple, un service peut utiliser le même compte de domaine pour s'authentifier auprès de centaines ou de milliers de serveurs d'une entreprise. Par conséquent, si un attaquant parvient à accéder à l'un de ces serveurs et à voler le nom d'utilisateur et le mot de passe utilisés par le service, il peut accéder à tous les autres serveurs qui exécutent le service.

  • Étendue des privilèges réseau pour tout compte utilisateur de domaine configuré pour exécuter un service. Plus l'étendue est vaste, plus le nombre de ressources à risque est important. Les comptes administrateur du domaine sont à haut risque car l'étendue de la vulnérabilité du réseau couvre tous les ordinateurs du domaine, y compris les contrôleurs de domaine. En outre, si ce compte utilisateur de domaine dispose de privilèges administrateur local sur un ou plusieurs autres serveurs, il existe un risque d'exploitation répétée de la vulnérabilité de sécurité.

    Il est particulièrement important de protéger les ressources réseau auxquelles accèdent les comptes de niveau administrateur car les informations d'identification de l'administrateur de domaine créent des vulnérabilités transitives et des possibilités d'escalade dans le domaine. En général, ces informations d'identification sont utilisées pour des ouvertures de session distantes et interactives sur tous les ordinateurs du domaine. Par conséquent, lorsqu'elles sont connues d'autrui, tous les ordinateurs du domaine deviennent vulnérables à une attaque.

Scénarios de vulnérabilité des services

Il existe plusieurs scénarios de vulnérabilité des services ayant chacun leurs niveaux de risque de sécurité. Ces scénarios sont présentés dans la figure et le tableau suivants. Dans la figure suivante, tous les comptes sont des comptes de domaine. Chaque compte exécute au moins un service sur l'un des serveurs.

Descriptions des comptes de domaine dans le diagramme :

  • Le compte A dispose de privilèges équivalents à ceux d'un Administrateur sur plus d'un contrôleur de domaine.

  • Les comptes A, B, C et D ont des privilèges équivalents à ceux d'un Administrateur sur plus d'un serveur membre.

  • Le compte E possède des privilèges équivalents à ceux d'un Administrateur uniquement sur un seul serveur membre.

    Figure 2.1 Privilèges de comptes administrateur sur des contrôleurs de domaine et des serveurs

    Figure 2.1 Privilèges de comptes administrateur sur des contrôleurs de domaine et des serveurs

Priorités des vulnérabilités de sécurité

Les niveaux de sécurité utilisés dans le tableau ci-dessous sont les suivants :

  • Niveau de risque critique. Le scénario compromet immédiatement la sécurité d'entreprise.

  • Niveau de risque élevé. Le scénario compromet la sécurité d'entreprise mais pas de façon immédiate.

  • Niveau de risque moyen. Le scénario est important, mais le risque de sécurité ne concerne pas un serveur haute sécurité.

  • Niveau de risque faible. L'élimination du scénario a peu d'effets sur les objectifs de sécurité.

Le tableau suivant décrit chaque scénario de vulnérabilité des services de façon détaillée et définit son niveau de priorité de sécurité.

Tableau 2.1 : scénarios des vulnérabilités de sécurité

Scénario

Description

Niveau de risque

1

Le compte A exécute un service sur le serveur 1. Une fois que le mot de passe du compte A est révélé sur le serveur 1, l'utilisateur a accès au contrôleur de domaine 1, qui devient alors vulnérable. Il s'agit d'un cas de priorité critique ; vous ne devriez pas utiliser de comptes de domaine avec des privilèges équivalents à ceux d'un Administrateur sur un contrôleur de domaine pour exécuter des services sur un serveur membre.

Critique

2

Le compte B exécute un service sur le serveur 2. Le compte B a également accès au serveur 1, où le compte A exécute un service. Une fois que le mot de passe du compte B est découvert sur le serveur 2, l'utilisateur se trouve dans la même position que lors du scénario 1 et le contrôleur de domaine 1 devient alors vulnérable. Cette logique peut être étendue au compte C qui exécute un service sur le serveur 3, lequel pourrait à son tour faciliter l'accès au serveur 2 sur lequel le compte B exécute un service et ainsi de suite. Il s'agit d'un cas de priorité élevée, et pas d'un cas de priorité critique, car lorsque le problème du scénario 1 a été résolu, le problème du scénario 2 se limite aux serveurs membres uniquement.

Élevée

3

Le compte D exécute un service sur le serveur 4 ou le serveur 5. Une fois que le mot de passe du compte D est découvert sur le serveur, l'utilisateur a accès à tous les autres serveurs membres sur lesquels le compte D a des privilèges. Il s'agit d'un cas de priorité moyenne (la nature transitive du scénario 2 n'existe pas).

Moyenne

4

Le compte E exécute un service sur le serveur 5 et n'a accès qu'à ce serveur 5.

Faible

Résumé des vulnérabilités des services

Les services sont des points de vulnérabilités de premier plan pour les attaquants qui tentent d'accéder au serveur local ou à d'autres serveurs sur le réseau. Si vous n’avez pas besoin d’utiliser un service en particulier, désactivez-le. En désactivant les services inutiles, vous réduisez rapidement et facilement la surface d'attaque, et vous bénéficiez également d'autres avantages en termes de performances.

Pour protéger un service avec succès, vous devez être conscient de ses vulnérabilités et minimiser son exposition.

Comptes système

Un service doit ouvrir une session comme un compte pour accéder aux ressources et aux objets dans le système d’exploitation. Si vous affectez un compte à un service ne disposant pas d’autorisations adéquates d'ouverture de session, le composant logiciel enfichable Services de la console MMC (Microsoft Management Console) lui accorde automatiquement le droit d'utilisateur requis, à savoir Ouvrir une session en tant que service, sur l'ordinateur que vous gérez. Microsoft Windows Server™ 2003 inclut les trois comptes intégrés suivants utilisés comme comptes d'ouverture de session pour plusieurs services système :

  • Compte Système local

    Le compte système local est un compte local prédéfini qui peut démarrer un service et fournir un contexte de sécurité à ce service. C'est un compte puissant qui a un accès total à l'ordinateur, y compris au service d'annuaire lorsque celui-ci est utilisé pour des services qui s'exécutent sur des contrôleurs de domaine. Le compte agit comme le compte d'ordinateur hôte sur le réseau et, à ce titre, a accès aux ressources réseau exactement comme tout autre compte de domaine. Sur le réseau, ce compte apparaît en tant que DOMAIN\<nom de l'ordinateur>$. Si un service ouvre une session à l'aide du compte Système local sur un contrôleur de domaine, il a un accès Système local sur le contrôleur de domaine même, ce qui, dans le cas où il serait compromis, pourrait permettre à des utilisateurs malveillants d'apporter des modifications à leur guise dans le domaine. Windows Server 2003 configure certains services pour ouvrir une session en tant que compte Système local par défaut. Le nom réel du compte est NT AUTHORITY\System, et il n'a pas de mot de passe géré par un administrateur.

  • Compte Service local

    il s'agit d'un compte spécial et prédéfini qui dispose de privilèges limités semblables à ceux d'un compte utilisateur local authentifié. Cet accès limité aide à protéger votre ordinateur dans le cas où un attaquant compromettrait les services ou processus individuels. Un service qui s'exécute en tant que compte Service local accède aux ressources réseau en tant que session NULL, c'est-à-dire, avec des informations d'identification anonymes. Le nom réel du compte est NT AUTHORITY\LocalService, et il n'a pas de mot de passe géré par un administrateur.

  • Compte Service réseau

    Il s'agit d'un compte spécial et prédéfini qui dispose de privilèges limités semblables à ceux d'un compte utilisateur authentifié. Cet accès limité aide à protéger votre ordinateur dans le cas où un attaquant compromet les services ou processus individuels. Un service qui exécute le compte Service réseau accède aux ressources réseau à l'aide des informations d'identification du compte d'ordinateur de la même façon que le ferait un service Système local. Le nom réel du compte est NT AUTHORITY\NetworkService, et il n'a pas de mot de passe géré par un administrateur.

    Important : en modifiant les paramètres par défaut du service, vous risquez d'empêcher l'exécution normale de services importants. si vous modifiez les paramètres par défaut du service, vous pouvez empêcher des services importants de s’exécuter correctement. La prudence est particulièrement de mise lorsque vous modifiez des paramètres Type de démarrage et Ouvrir une session en tant que de services configurés pour démarrer automatiquement par défaut.

Comptes utilisateur

Plusieurs catégories de comptes utilisateur peuvent ouvrir une session en tant que service. Chaque catégorie dispose de ses propres capacités et privilèges.

  • Comptes d'utilisateur local

    Cette catégorie contient les comptes que vous créez localement sur un ordinateur, par exemple, avec la console de gestion Utilisateurs et groupes locaux. Ces comptes disposent de privilèges très limités sur l'ordinateur local, à moins que vous ne leur accordiez spécifiquement des privilèges plus élevés ou que vous les ajoutiez à des groupes qui possèdent déjà ces privilèges.

  • Comptes d'administrateur local

    Cette catégorie comprend le compte Administrateur intégré que vous créez et utilisez lorsque vous installez Windows Server 2003 ou Microsoft Windows® XP sur l'ordinateur pour la première fois. Elle inclut également tous les autres comptes utilisateur créés ultérieurement et ajoutés au groupe Administrateurs intégré. Les membres de ce groupe disposent d'un accès total à l'ordinateur local.

  • Comptes d'utilisateur de domaine

    Cette catégorie inclut les comptes que vous créez dans le domaine, par exemple, en se servant de la console de gestion des utilisateurs et ordinateurs Active Directory®. Ces comptes disposent de privilèges limités sur le domaine, à moins que vous ne leur accordiez spécifiquement des privilèges plus élevés ou que vous ne les ajoutiez à des groupes qui possèdent déjà ces privilèges.

  • Comptes d'administrateur de domaine

    Cette catégorie comprend le compte administrateur de domaine intégré que vous créez et utilisez lorsque vous installez pour la première fois Active Directory. Elle inclut tous les autres comptes utilisateur créés ultérieurement et ajoutés au groupe Administrateurs locaux intégré, au groupe Administrateurs du domaine ou au groupe Administrateurs de l'entreprise. Les membres de ces groupes disposent d'un accès total au domaine et, dans le cas du groupe Administrateurs d'entreprise, à l'ensemble de la forêt.

Modifications apportées aux paramètres de sécurité par défaut dans Windows Server 2003

Avec les versions de Windows commercialisées avant Windows XP et Windows Server 2003, presque tous les services fournis avec le système d'exploitation utilisaient le compte Système local par défaut. Les programmes qui s'exécutent dans ce contexte disposent de privilèges illimités sur l'ordinateur local, ce qui présente un risque de sécurité évident. Avec la publication de Windows Server 2003, les développeurs ont modifié les paramètres par défaut afin de rendre l'environnement plus sécurisé. L'une de ces modifications réside dans le fait que le nombre de services qui s'exécutent à présent par défaut sous le compte Système local est moins important. Au lieu d'utiliser le compte Système local, de nombreux services courants utilisent à présent le compte Service local ou Service réseau. Ces comptes ont un niveau de privilèges bien inférieur au compte Système local et, par conséquent, présentent un risque moins important pour la sécurité.

De nombreux services ouvrent toujours une session en tant que Système local, notamment les services Mises à jour automatiques, Explorateur d'ordinateurs, Messenger et Windows Installer. D'autres non. Par exemple, le service Alertes utilisait le compte Système local dans Windows 2000 mais utilise le compte Service local dans Windows Server 2003. Le client DNS utilisait le compte Système local dans Windows 2000 mais utilise le compte Service réseau dans Windows Server 2003. Le tableau suivant répertorie les services qui n'utilisent plus le compte Système local dans Windows Server 2003 et indique quel compte de service ils utilisent à présent.

Attention : Do not attempt to change the accounts that services provided with the Windows Server 2003 operating system use, because doing so can cause serious problems and potentially stop important services from running successfully. Par exemple, le service Client DNS utilise le compte Service réseau parce qu'il doit accéder à des ressources réseau telles que les serveurs DNS. Ce service ne fonctionne pas avec le compte Service local ou tout autre compte qui ne peut pas s'authentifier auprès des ressources réseau.

Tableau 2.2 : nouveaux paramètres de compte de service dans Windows Server 2003

Nom du service

Ouverture de session en tant que

Alertes

Service local

Passerelle de la couche Application

Service local

Accès à distance au Registre

Service local

Carte à puce

Service local

Assistance TCP/IP NetBIOS

Service local

Telnet

Service local

Onduleur

Service local

WebClient

Service local

Acquisition d'image Windows (WIA)

Service local

Horloge Windows

Service local

Service de découverte automatique de Proxy Web pour les services HTTP Windows

Service local

Client DHCP

Service réseau

Coordinateur de transactions distribuées

Service réseau

Client DNS

Service réseau

Service d'enregistrement de licences

Service réseau

Journaux et alertes de performance

Service réseau

Localisateur d'appels de procédure distante (RPC)

Service réseau

Principes pour exécuter les services de façon plus sécurisée

La voie du succès en matière de sécurité des services inclut la compréhension de la nature des services disponibles dans l'environnement en réseau et la mise en place de procédures pour en protéger l'utilisation. Cette section examine trois principes fondamentaux que vous devriez suivre lorsque vous planifiez d'exécuter des services de façon sécurisée :

  • Connaître votre système

  • Utiliser le principe du moindre privilège

  • Utiliser le principe du moindre service

Si vous arrivez à incorporer avec succès ces principes dans vos procédures de sécurité IT, elles vous aideront à atteindre un niveau adéquat de sécurité des services.

Connaître votre système

Bien que cette recommandation semble évidente, de nombreuses entreprises ne sont pas parfaitement au fait des rôles et services qui s'exécutent sur tous leurs ordinateurs.

Pour savoir si vos ordinateurs sont sécurisés ou non, vous devez savoir quels sont les services qui sont exécutés et quelles sont leurs propriétés. Ces informations sont essentielles pour aider à maintenir la sécurité de vos serveurs. Considérez la valeur d'un tableau des services et des paramètres des propriétés des services pour les services qui s'exécutent sur vos ordinateurs, de sorte que vous puissiez évaluer immédiatement les risques. Créer un tableau de ce type peut être long et complexe au début, mais cela peut valoir la peine car il est vital de comprendre les propriétés d'une bonne configuration connue pour les différents rôles de vos serveurs.

Plusieurs outils peuvent vous aider à créer une liste des propriétés des services et des services en cours d'exécution. Il s'agit entre autres des outils suivants :

  • Outil de contrôle des services (sc.exe). Cet outil de ligne de commande est inclus avec Windows Server 2003 et Windows XP. Il fournit une méthode de communication avec le composant Gestionnaire de contrôle des services à partir de la ligne de commande pour interroger et définir les propriétés des services.

  • Windows Management Instrumentation (WMI). Il s'agit d'un composant pré-installé des systèmes d'exploitation Windows Server 2003 et Windows XP qui fournit des informations de gestion et un contrôle dans un environnement d'entreprise. À l'aide des normes de l'industrie, les administrateurs de gestion des systèmes peuvent utiliser WMI pour demander et définir des informations sur les ordinateurs de bureau, applications, réseaux et autres composants d'entreprise. Plusieurs outils de gestion fonctionnent avec WMI, dont les Informations système et le composant Dépendances de la console Services. Les dépendances des services identifient les services dont dépend le service en cours et les services qui, à leur tour, dépendent de lui. Les administrateurs système peuvent également utiliser des scripts WMI pour automatiser les tâches d'administration.

  • Ligne de commande WMIC (Windows Management Instrumentation command line). WMI inclut un outil de ligne de commande, WMIC, qui fournit une interface de ligne de commande simple vers WMI pour interroger et gérer à distance les ordinateurs qui fonctionnent sous des systèmes d'exploitation Windows. Pour invoquer WMIC, tapez wmic à l'invite de commande. Par exemple, pour récupérer des informations de services pour un serveur nommé Server1, tapez ceci à l'invite de commande :

    wmic /output:c:\services.htm /node:server1 service list full / format:htable

    Utilisez Microsoft Internet Explorer pour examiner le fichier c:\services.htm qui en résulte présenté sous forme d'un tableau HTML (Hypertext Markup Language). Si le nom de votre serveur contient des espaces ou des caractères spéciaux, mettez des guillemets autour du nom lorsque vous exécutez la commande wmic.

    Remarque : il existe un autre outil de ligne de commande disponible nommé sclist.exe, qui est inclus dans le kit de ressources Windows 2000 Server. Cet outil peut afficher les services en cours d'exécution, les services interrompus ou tous les services à la fois sur les ordinateurs locaux et distants. Sclist.exe peut identifier des services qui s'exécutent sur un ordinateur physiquement distant ou un ordinateur qui n'a pas de moniteur, par exemple dans un rack de serveurs.

Utiliser le principe du moindre privilège

La plupart des cours de formation et documents liés à la sécurité abordent la mise en œuvre du principe de moindre privilège. Ce principe est simple, mais l'impact de la mise en œuvre accroît considérablement la sécurité et réduit les risques. Le principe de moindre privilège établit que vous donnez à une entité l'accès le plus réduit possible dont elle a besoin pour effectuer sa tâche et rien de plus. Sous Windows Server 2003, ce principe s'applique à la fois aux comptes utilisateur et aux comptes d'ordinateur car dans Active Directory, les comptes utilisateur et les comptes d'ordinateur sont des entités de sécurité, ce qui signifie qu'ils disposent les uns et les autres d'autorisations et de privilèges.

Une des raisons pour lesquelles ce principe fonctionne si bien est qu'il vous oblige à évaluer les ressources réseau et les risques potentiels de sécurité. Vous devez apprendre les privilèges d'accès nécessaires pour un ordinateur ou un utilisateur donné puis vérifier que seuls les privilèges requis sont appliqués.

Pour exécuter des services de façon plus sécurisée, les entreprises doivent les déployer à l'aide d'une approche du moindre privilège. Dans la mesure du possible, exécutez les services en tant que compte Service local, de sorte que le compte ne puisse accéder qu'à un seul ordinateur et non pas au domaine entier. Les services qui requièrent un accès authentifié au réseau peuvent devoir utiliser le compte Service réseau et vous devriez déployer les services qui requièrent une implémentation plus large en tant que compte Système local. Si vous déterminez qu'un compte administrateur au niveau du domaine est nécessaire pour déployer un service, vous devriez traiter le serveur sur lequel vous déployez comme un serveur haute sécurité et le protéger par les mêmes mesures que celles que vous utilisez pour d'autres ressources réseau extrêmement sensibles telles que les contrôleurs de domaine. Pour plus d'informations à ce sujet, reportez-vous à la section Créer un groupe de serveurs haute sécurité pour les exceptions des administrateurs de domaine du Chapitre 3, « Procédure à suivre pour exécuter les services de façon plus sécurisée ».

Microsoft a minutieusement testé Windows Server 2003 pour s'assurer que les services essentiels du système d'exploitation s'exécutent déjà avec le compte de moindre privilège ; par conséquent, vous ne devriez pas avoir besoin de modifier ces services. Vous devez vous concentrer sur la sécurisation des services qui ne font pas partie du système d'exploitation. Ceux-ci peuvent être fournis comme des composants d'autres offres de produits serveur, par exemple Microsoft SQL Server™, Microsoft Operations Manager et les services fournis par des fournisseurs tiers.

Vous pouvez utiliser la Stratégie de groupe dans Windows Server 2003 pour contrôler certains services précis qui peuvent s'exécuter sur un ou plusieurs ordinateurs. Pour cela, ouvrez l'objet Stratégie de groupe pour l'unité d'organisation contenant l'ordinateur que vous voulez configurer. Allez au nœud Configuration ordinateur\Paramètres Windows\Paramètres de sécurité\ Services système et ouvrez la page Propriétés du service que vous voulez contrôler. Dans la boîte de dialogue Propriétés, définissez le mode de démarrage du service (Automatique, Manuel, ou Désactivé) et définissez les autorisations de sécurité qui contrôlent quels sont les comptes utilisateur qui peuvent effectuer certaines opérations particulières sur ce service, par exemple l'arrêter ou le démarrer.

Pour plus d'informations sur les points à prendre en compte lorsque vous décidez du type de compte à utiliser pour exécuter un service, reportez-vous à la Figure 3.1, « Hiérarchie du moindre privilège pour le déploiement des services », du Chapitre 3, « Procédure à suivre pour exécuter les services de façon plus sécurisée ».

Lorsque vous implémentez le principe du moindre privilège sur vos ordinateurs, il fonctionne en association avec la règle connaître votre système. Comment savez-vous si vos ordinateurs exécutent le nombre minimal de services si vous ne savez pas quels services sont en cours d'exécution ? En associant ces deux principes, votre personnel administratif peut savoir quels sont les services qui sont en cours d'exécution sur un ordinateur, leur statut et les informations d'identification qui sont utilisées pour chaque serveur ; puis modifier méthodiquement chaque service sur le moindre privilège nécessaire. Contrôlez les ordinateurs pour vous assurer que de nouveaux services peuvent être ajoutés sans passer par des procédures de contrôle des changements.

Utiliser le principe du moindre service

Le principe du moindre service établit que le système d'exploitation et les protocoles réseau disponibles sur tout périphérique en réseau devraient exécuter uniquement les services et protocoles exacts requis pour soutenir les objectifs de l'entreprise. Par exemple, si un serveur ne doit pas nécessairement héberger des applications Web, vous devriez supprimer ou désactiver le service World Wide Web. La plupart des systèmes d'exploitation et des programmes installent bien plus de services et protocoles dans leur configuration par défaut que cela est nécessaire en réalité pour les scénarios courants.

La meilleure façon de configurer un nouveau serveur est d'inclure une étape dans laquelle l'administrateur système ferme tout à l'exception de ce qui est strictement nécessaire au système d'exploitation. Par exemple, dans les systèmes d'exploitation Windows antérieurs à Windows Server 2003, il était courant de fermer les services Alertes et Messenger. En outre, vérifiez que le placement des services sur le réseau est correct. Par exemple, il n'est pas conseillé de placer le service de routage et d'accès distant ou Internet Information Services (IIS) sur un contrôleur de domaine car ils exécutent en arrière-plan des services qui augmentent la vulnérabilité sur le contrôleur de domaine. Les pratiques recommandées de Microsoft indiquent qu'aucun service supplémentaire, autre que ceux qui sont requis pour un bon fonctionnement en tant que contrôleur de domaine, ne doit s'exécuter sur un contrôleur de domaine.

Pour plus d'informations sur la sécurisation des services dans Windows Server 2003 et Windows XP, reportez-vous aux guides suivants :

Téléchargez

TéléchargezGuide de planification de la sécurité des services et comptes de service