Principes fondamentaux de la sécurité de Microsoft Systems Management Server 2.0

Sur cette page

Avis au lecteur
À propos de ce document
Liste de contrôle de la sécurité SMS
Informations complémentaires
Partie 1 : Environnement de sécurité de SMS
Complexités de la sécurité Windows NT
Authentification Windows NT
Authentification directe
Modèles de domaine
Autres fonctionnalités de sécurité Windows NT
SQL Server 6.5
SQL Server 7.0
Sécurité orientée composant DCOM

... ou comment optimiser la sécurité SMS et réduire les problèmes liés à la sécurité grâce à SMS (Systems Management Server)

de Paul Thomsen, rédacteur technique, Assistance utilisateur en matière de gestion sous Windows - Microsoft Corporation.

Pour les dernières informations, voir le site Web Systems Management Server.

Avis au lecteur

Microsoft Systems Management Server 2.0 (SMS) est un système puissant qui permet de traiter une problèmatique importante : la gestion des ordinateurs. SMS 2.0 peut être déployé dans une grande variété d'environnements exigeant chacun un traitement particulier. Sa mise en œuvre est gérée par un ensemble intégré d'options de sécurité sophistiquées. Pour réussir le déploiement de SMS et l'utiliser efficacement, il convient par conséquent de bien prendre en considération cette combinaison de complexité, de variété et de sophistication.

De nature puissants, les systèmes de gestion informatique peuvent avoir une action sur l'ensemble du parc informatique de votre société. La sécurité de votre système de gestion ne doit en aucun cas faire l'objet d'un compromis. En protégeant correctement vos systèmes de gestion, vous êtes assuré que les personnes non autorisées ne peuvent pas les utiliser pour accéder aux ordinateurs de la société ou pour les désactiver. C'est dans cette optique que nous vous invitons à accorder toute votre attention aux questions soulevées dans le présent document.

Par ailleurs, parce que des risques de sécurité émergent constamment de nouvelles sources et que les avancées technologiques rendent le piratage informatique plus facile, vous devez réexaminer ces questions régulièrement.

À propos de ce document

Ce document technique décrit l'environnement de sécurité dans lequel fonctionne SMS et les fonctionnalités de sécurité incluses dans SMS. Il indique comment déployer et utiliser SMS et les technologies associées afin de tirer le meilleur parti de leur sécurité. En dernière partie, il fournit des instructions pour la résolution des problèmes liés à la sécurité. Ce document comprend les principales parties décrites ci-après, plusieurs annexes et un glossaire.

Partie 1 : Environnement de sécurité de SMS

Partie 2 : Modèle de sécurité de SMS

Partie 3 : Novell NetWare dans le modèle de sécurité de SMS

Partie 4 : Planification, implémentation et utilisation de la sécurité de SMS

Partie 5 : Résolution des problèmes liés à la sécurité de SMS

Ce document s'adresse aux architectes techniques et aux administrateurs qui planifient, configurent et utilisent SMS. Ils sont censés bien connaître l'administration de SMS 2.0 et les principes de base de la sécurité sous Microsoft Windows NT.

Nous y aborderons des questions de sécurité SMS spécifiques à SMS 2.0 avec le Service Pack 2, des ordinateurs exécutant Windows NT Server, version 4.0. Les clients et les configurations NetWare prenant en charge SMS 2.0 sont également décrits dans cette publication.

Il traite un grand nombre de questions identiques à celles du chapitre 4, "Création de votre stratégie de sécurité pour SMS" du Guide d'administration de Systems Management Server Version 2.0. Il développe en outre des thèmes de sécurité SMS ne figurant pas dans ce chapitre et fournit des informations contextuelles complémentaires, qui sont plus détaillées que dans ce chapitre.

Ce document ne traite pas les questions de sécurité relatifs aux éléments suivants :

• Contrôle du logiciel

• Système de statut de site

• Clients 16 bits

• Sécurité relative à Microsoft Windows 2000

• Microsoft Health Monitor : gestion de l'utilisation Health Monitor ou utilisation de Health Monitor pour surveiller la sécurité des ordinateurs clients

• Incidences sur la sécurité de l'extension de l'inventaire matériel

• Création de sites secondaires distants

• Utilisation de SMS avec des solutions de sécurité tierces (comme "Enterprise Administrator" de Mission Critical Software)

• Utilisation de SMS avec des serveurs Samba ou d'autres serveurs SMB

• Sécurité (et connectivité) du gestionnaire de services

• Propagation de la collection aux sites enfants (et choix de propager ou non les droits associés)

• Sécurité de l'expéditeur du courrier, y compris les droits exigés sur les sites récepteurs.

• Questions relatives à la sécurité sous SMS 1.2, soit intégrée à SMS 2.0 soit constituée dans un système autonome. Par ailleurs, les questions de mise à niveau de la sécurité SMS 1.2 ne sont pas traitées. Le Guide d'administration de Systems Management Server Version 2.0 décrit les mises à niveau de SMS. La sécurité SMS 1.2 est traitée dans le Guide d'administration de Systems Management Server Version 1.2.

Liste de contrôle de la sécurité SMS

Consultez la liste suivante afin de vous assurer que vous avez pris en considération tous les points de sécurité associés à SMS. Utilisez-la pour planifier votre déploiement, à l'issue du déploiement, puis de façon régulière par la suite. Par son biais, vous serez toujours assuré d'avoir traité toutes les questions de sécurité SMS. Cependant, comme chaque implémentation présente des problèmes de sécurité différents, vous devez déterminer ceux qui s'appliquent à votre environnement et qui ne figurent pas dans cette liste. Pour l'étudier efficacement, vous devez bien comprendre les aspects et les tsrechniques de la sécurité SMS.

Liste de contrôle de la sécurité SMS

Informations complémentaires

L'objet de ce document est de fournir à ses lecteurs une présentation détaillée de la sécurité SMS en apportant les informations requises concernant les spécificités des technologies de sécurité associées. Il est clair qu'il ne saurait satisfaire les besoins de tous et inévitablement des informations supplémentaires sont apparues au moment de la publication. C'est pourquoi nous vous renvoyons à d'autres sources d'informations sur la sécurité, dont des documents relatifs à la sécurité SMS. La liste suivante peut constituer un bon point de départ.

• Pour toute information sur l'administration générale de SMS 2.0, et notamment une présentation générale de la sécurité SMS 2.0, reportez-vous au Guide d'administration de Systems Management Server Version 2.0.

  Notez que le Service Pack 1 (ou une version ultérieure) du Guide d'administration de Systems Management Server Version 2.0 (proposé uniquement au format électronique avec Service Pack 1, ou une version ultérieure) contient une présentation plus récente de la sécurité que la version imprimée.

• Pour des informations détaillées sur l'utilisation de la console Administrateur SMS, consultez l'aide en ligne de Systems Management Server Version 2.0. L'aide en ligne contient également des consignes de sécurité (par exemple, la rubrique "À propos de la gestion des comptes et des mots de passe SMS").

• Pour plus de précisions sur les questions de sécurité SMS et un complément au Guide d'administration de Systems Management Server Version 2.0, consultez les notes de mise à jour du Service Pack 2.

• Pour des informations plus détaillées sur SMS 2.0, consultez le Guide de ressources de Systems Management Server Version 2.0, une publication distincte (ISBN 0-7356-0928-4) mais également incluse dans le Kit de ressources de Microsoft BackOffice 4.5 (ISBN 0-7365-0583-1).

• Pour toute information sur le produit SMS 2.0, consultez la page Systems Management Server.

• Pour toute autre documentation technique relative à SMS 2,0, consultez la page Systems Management Server.

• Pour toute information sur des questions de sécurité relatives à l'ensemble des produits Microsoft, consultez le site Microsoft Sécurité.

• Pour une documentation spécialisée sur la sécurité Windows NT, consultez le Kit de ressources de Windows NT Server 4.0 et le Guide des ressources de Windows NT Workstation 4.0.

• Pour des informations détaillées sur WMI (Windows Management Instrumentation), y compris la sécurité WMI, consultez la page Management Services .

• Divers documents diffusent des informations détaillées sur le modèle DCOM (Distributed Component Object Model), y compris la sécurité DCOM. Par ailleurs, Microsoft propose diverses ressources sur la page DCOM .

• Pour obtenir des informations complètes sur SQL Server, y compris la sécurité SQL Server, consultez la Documentation en ligne, qui peut être installée sur les consoles SQL Server.

• Un grand nombre d'ouvrages généraux sur la sécurité informatique traitent de questions comme l'évaluation du risque, la sécurité physique, la sécurité du réseau, ainsi que les stratégies et les procédures associées.

Partie 1 : Environnement de sécurité de SMS

Microsoft Systems Management Server 2.0 (SMS) est mis en œuvre avec un ensemble de technologies. Ces technologies contribuent conjointement à créer un environnement de sécurité complet pour SMS. Il convient de bien comprendre les principes de sécurité de chaque technologie pour se représenter clairement leurs relations avec SMS et voir les effets possibles sur les accès à et depuis SMS. Par ailleurs, vous devez utiliser les technologies de sécurité dans un environnement physique protégé et établir les stratégies et procédures appropriées.

Grâce à une bonne vue d'ensemble de l'environnement de sécurité de SMS, vous pouvez voir que la sécurité de SMS est aisément compréhensible et très fiable. Chaque aspect de l'environnement de sécurité de SMS est facile à gérer individuellement, et une fois assimilé, facile à intégrer aux autres éléments. La première partie de ce document présente les technologies de prise en charge de l'environnement de sécurité de SMS, c'est-à-dire :

• la sécurité Microsoft Windows NT ;

• la sécurité Microsoft SQL Server ;

• la sécurité WMI (Windows Management Instrumentation), y compris la sécurité DCOM ;

• la sécurité physique ;

• les stratégies et les procédures de sécurité d'entreprise.

Sécurité Windows NT

Sans surprise, SMS dépend très étroitement de Windows NT et de la sécurité Windows NT. Non seulement SMS s'exécute sous Windows NT, mais de plus il utilise le partage de fichiers Windows NT pour la communication entre les sites, les serveurs de sites, et les clients et les serveurs de sites. Il est indispensable de bien comprendre la sécurité Windows NT pour comprendre la sécurité SMS. Les administrateurs expérimentés de Windows NT connaissent bien les principes fondamentaux de la sécurité Windows NT, y compris les concepts relatifs aux comptes, groupes et domaines. Windows NT comporte néanmoins un certain nombre de complexités qui, si elles ont des incidences sur l'implémentation de SMS, peuvent se révéler décisives pour la réussite de votre projet. L'objet de cette partie est de clarifier ces concepts, qui sont :

• l'impact de la complexité de la sécurité Windows NT sur les comptes, les processus, les privilèges et les droits ;

• l'authentification Windows NT ;

• l'authentification directe ;

• les problèmes liés au modèle du domaine ;

• les mécanismes de sécurité Windows NT ;

• les profils et la représentation.

Pour obtenir des explications sur les principes fondamentaux de la sécurité Windows NT, consultez les ouvrages sur Windows NT comprenant une partie sur la sécurité. Le chapitre "Sécurité du réseau et planification de domaine" du Guide de réseau, intégré au Kit de ressources de Microsoft Windows NT Server 4.0, est une source d'information particulièrement utile.

Complexités de la sécurité Windows NT

SMS 2.0 utilise un grand nombre de comptes pour exécuter ses divers composants, ce qui lui permet d'appliquer une sécurité très spécifique pour chaque composant, et en définitive, de réduire au minimum le risque général de brèche de sécurité SMS. Pour se représenter la conception de SMS et utiliser correctement les comptes SMS, vous devez avoir une idée précise sur la façon dont Windows NT utilise des comptes.

Comptes et processus

Deux conceptions erronées relatives aux comptes Windows NT sont couramment répandues : ils exécutent des programmes et se connectent à des ordinateurs. En réalité, l'ordinateur exécute des programmes en cours et les processus ont chacun un contexte de sécurité. Chaque processus a un jeton de sécurité comprenant des détails relatifs aux privilèges que ce processus peut utiliser. Les processus sont créés lorsqu'ils sont exigés pour exécuter des programmes. Les processus sont toujours créés à partir d'autres processus (à l'exception des processus système initiaux, qui sont créés durant l'amorçage du système) et héritent le plus souvent du contexte de sécurité des processus les ayant créés.

La connexion d'un utilisateur à un ordinateur est un exemple courant de processus créé avec un nouveau contexte de sécurité. L'utilisateur fournit un nom d'utilisateur, un mot de passe et un domaine (ou un nom d'ordinateur), qui constituent collectivement les informations d'identification. Ces informations sont authentifiées par référence à une base de données de comptes. Si une correspondance est trouvée, l'utilisateur est connecté et un processus est créé en exécutant Explorer.exe.

Un programme exécuté en tant que service est un autre exemple de processus créé avec un nouveau contexte de sécurité. Les services sont lancés par le système d'exploitation (parfois sous le contrôle d'un utilisateur privilégié). Les services peuvent être exécutés dans le contexte de sécurité du système d'exploitation, mais dans ce cas le service a des privilèges très spécifiques, qui ne comprennent pas le droit d'utiliser le réseau pour se connecter à d'autres ordinateurs. Pour recevoir des privilèges supplémentaires, les services sont souvent associés à un compte, un nom d'utilisateur et un mot de passe, lesquels sont authentifiés suivant le même processus que celui appliqué lors de la connexion de l'utilisateur. SMS exécute un grand nombre de composants serveur à l'aide de comptes SMS (ainsi qu'un certain nombre de composants clients). Le dernier exemple de situation au cours de laquelle un processus est créé avec un nouveau contexte de sécurité est celle où un processus crée un autre processus qui doit utiliser un compte spécifique. Le processus créant le nouveau processus fournit un compte, un nom d'utilisateur et un mot de passe, qui seront authentifiés. Le moment où vous démarrez un processus détermine la façon dont vous créez un processus. Il détermine également la façon dont SMS exécute un grand nombre de ses composants clients.

Il est important de se rappeler que les comptes Windows NT ont chacun un identifiant unique, appelé ID sécurité ou SID. Le SID est généralement mémorisé dans la plupart des emplacements, comme les listes de contrôle d'accès, où les détails de compte sont stockés. La liste des utilisateurs autorisés à accéder à un répertoire en est un exemple. Les SID, et non les noms d'utilisateur, sont enregistrés dans cette liste. Lorsqu'un compte est supprimé, puis recréé, le nouveau compte (même si son nom et d'autres caractéristiques sont identiques à ceux de l'ancien compte) reçoit un nouveau SID. L'ancien SID n'est pas automatiquement supprimé de tous les emplacements où il est mémorisé ni automatiquement remplacé par le nouveau. C'est pourquoi, si un compte est supprimé par inadvertance, vous ne pouvez pas restaurer l'accès aux mêmes ressources uniquement en recréant le compte avec les mêmes caractéristiques. Au lieu de cela, vous devez ajouter des autorisations pour le nouveau compte à chaque ressource que le compte supprimé était autorisé à utiliser.

Jetons

À l'intérieur de tous les processus, Windows NT a des threads qui suivent les programmes en cours d'exécution. Tous les processus ont au moins un thread et il se peut qu'il y en ait plus pour simplifier la synchronisation des opérations simultanées dont un programme pourrait avoir besoin pour s'exécuter. Plusieurs threads peuvent également autoriser un processus à s'exécuter sur une ou plusieurs unités centrales à la fois.

Un processus est toujours associé à un jeton et un thread peut également avoir un jeton (si l'application exige que le thread ait son propre jeton). Lorsqu'un processus est créé et que ses informations d'identification sont authentifiées, un jeton contenant les détails de sécurité du compte est créé. Windows NT vérifie fréquemment la sécurité, mais authentifier les informations d'identification à chaque fois peut prendre beaucoup de temps. Pour simplifier le processus, des jetons sont utilisés pour les contrôles de sécurité. Les jetons sont toujours fiables car ils ne sont utilisés que dans un ordinateur et ne peuvent être créés que par le système d'exploitation.

Lorsqu'un processus crée un thread, il peut fournir des informations d'identification, les faire authentifier, et ainsi obtenir un jeton unique pour le thread. L'avantage de chaque thread ayant son propre jeton est qu'il dispose de son propre contexte de sécurité unique. Si un thread voit sa sécurité compromise, il ne peut pas affecter les autres threads parce qu'ils ne s'exécutent pas dans le même contexte de sécurité.

Entrées de contrôle d'accès et listes de contrôle d'accès

Les listes de contrôle d'accès (ACL) contiennent les entrées de contrôle d'accès. Chaque entrée spécifie un utilisateur ou un groupe ayant un droit d'accès à l'objet, ainsi que le type d'accès accordé. Windows NT utilise des objets très variés. "Objets" peut avoir plusieurs significations, mais dans le cadre de ce document il fait référence à des éléments de Windows NT (comme les fichiers, les processus et les structures de données internes) pouvant avoir une liste de contrôles d'accès.

Droits, autorisations et privilèges

Les droits Windows NT sont accordés aux comptes et permettent aux processus créés pour ces comptes d'effectuer des fonctions spéciales sur un ordinateur. Les droits courants donnent l'autorisation de fermer un ordinateur ou d'exécuter des programmes en tant que services. La possibilité d'utiliser ces droits, tels qu'ils sont accordés au compte, est stockée dans le jeton lors de la création du processus (et du jeton).

Les autorisations sont détenues par des objets, comme les fichiers, et sont utilisées lorsque le sous-système de sécurité de Windows NT doit déterminer si le type de droit d'accès détenu par l'objet considéré correspond au type d'accès demandé par le processus. Windows NT compare le nom d'utilisateur et le domaine (ou le nom d'ordinateur), ou les groupes auxquels appartient l'utilisateur (tel qu'il est stocké dans le jeton) à la liste de contrôle d'accès de l'objet. S'il trouve une correspondance, Windows NT détermine si le type d'accès demandé est autorisé.

Les privilèges sont une combinaison de droits et d'autorisations accordés aux utilisateurs ou aux groupes. Ce terme fait référence aux droits de sécurité et aux autorisations d'un utilisateur. Ce n'est pas un élément de Windows NT.

Sécurité du réseau

Les ordinateurs exécutant Windows NT n'ont pas confiance dans les jetons provenant d'autres ordinateurs, car il est possible que ceux-ci exécutent une version de Windows NT qui n'est pas valide (par exemple, un système d'exploitation qui ressemble à Windows NT mais qui ne l'est pas, ou qui a été piraté de telle façon que les jetons ont reçu des privilèges auxquels ils n'ont pas droit). Chaque fois qu'un ordinateur tente de se connecter à un autre ordinateur, il doit fournir des informations d'identification qui peuvent être authentifiées par référence à une base de données de sécurité, suivant une procédure identique à celle appliquée pour la création des processus.

Lorsqu'un processus fournit des informations d'identification pour une connexion réseau, il est courant que le processus fournisse les informations d'identification utilisées lors de sa création. Mais des informations d'identification secondaires seront tout autant acceptées. Le fait de fournir des informations d'identification secondaires permet au processus d'exécuter un ensemble de privilèges et de se connecter à un autre ordinateur avec un ensemble différent de privilèges. Un processus peut effectivement utiliser un ensemble d'informations d'identification pour se connecter à un ordinateur, et un autre ensemble pour se connecter à un autre ordinateur. Cependant, un ordinateur peut n'utiliser que le même ensemble pour se connecter à un autre ordinateur, même si différents processus tentent de se connecter à cet ordinateur.

La capacité d'un processus à utiliser un compte pour lui-même et un autre pour les connexions réseau assurent un meilleur contrôle de la sécurité, car le compte spécifiant les privilèges associés à ce processus peuvent être limités à un ordinateur spécifique (ou limité par d'autres façons), mais le compte spécifiant les privilèges de la connexion réseau peut être partagé entre plusieurs ordinateurs. Le compte partagé, que de nombreux ordinateurs pourront utiliser, ne peut pas exécuter de programmes dangereux sur d'autres ordinateurs car il n'a pas les privilèges nécessaires.

SMS exploite fréquemment la capacité d'un processus à utiliser un contexte de sécurité pour lui-même et un deuxième contexte pour ses connexions réseau. C'est la raison pour laquelle SMS affecte plusieurs comptes aux connexions et d'autres à l'exécution des services. Un ordinateur peut utiliser des comptes des deux ensembles en parallèle.

Authentification Windows NT

L'authentification Windows NT est assurée pour la création de processus et de threads, ainsi que lors de la connexion à d'autres ordinateurs. Les problèmes d'authentification apparaissent le plus souvent lorsqu'un ordinateur se connecte à d'autres ordinateurs.

Lorsqu'un utilisateur exécute un processus Windows NT qui tente de se connecter à un partage sur un autre ordinateur exécutant Windows NT, l'ordinateur desservant le partage doit pouvoir établir avec certitude l'identité de l'utilisateur. Une fois cette certitude acquise, l'ordinateur peut ensuite s'assurer que l'utilisateur a reçu le niveau d'accès demandé et peut alors fournir les données demandées.

Le processus d'authentification comporte quatre étapes, également illustrées dans les Figures 1.1 et 1.2.

1. Une fois la connexion au partage établie, l'ordinateur ayant lancé la connexion inclut dans la requête le nom de l'utilisateur, le mot de passe et le nom du domaine que l'utilisateur a fourni lors de la connexion à l'ordinateur. Si l'utilisateur s'est connecté en local à l'ordinateur, en utilisant un compte d'ordinateur local, le nom du domaine est remplacé par le nom de l'ordinateur. L'utilisateur peut substituer ces valeurs s'il spécifie une chaîne "se connecter en tant que" lors de la soumission de la requête de connexion. L'ordinateur recevant la requête de connexion compare le nom du domaine au nom de sa base de données de sécurité. Le nom de la base de données de sécurité sur un contrôleur de domaine est le nom du domaine. Sur un ordinateur autre que Windows NT, ce nom est le nom de l'ordinateur. Si les noms sont identiques, la copie locale de la base de données est utilisée. Sur un contrôleur de domaine, la base de données est la base de données du domaine.

2. Si les noms ne concordent pas et si l'ordinateur n'est pas un contrôleur de domaine, l'ordinateur transmet la requête au contrôleur du domaine.

3. Le contrôleur du domaine compare ensuite le nom de domaine demandé à son nom de domaine. Si les noms sont identiques, le contrôleur de domaine tente d'authentifier la requête. Si les noms ne concordent toujours pas, le contrôleur de domaine parcourt sa liste des domaines approuvés. S'il trouve une correspondance, il transmet la requête au contrôleur de domaine de ce domaine.

Figure 1.1 Étapes de l'authentification Windows NT

1. L'utilisation de privilèges de type invité est une autre extension du processus d'authentification. Si un accès invité est activé et que le nom d'utilisateur spécifié dans la requête est introuvable dans la base de données de sécurité, la connexion est authentifiée en tant qu'accès invité. Cette authentification se produit lorsque l'ordinateur offre le partage ou au niveau du contrôleur de domaine (étapes 1 à 2 dans la Figure 1.1 et 1.2), mais pas avant que la dernière étape possible de votre environnement n'ait été tentée. L'accès invité peut être activé à l'ordinateur offrant le partage, le domaine de l'ordinateur ou un domaine approuvé. Si l'accès invité est activé au domaine de l'ordinateur ou à un domaine approuvé, le compte doit être global, et non local. L'accès invité n'est pas activé par défaut pour Windows NT et est généralement découragé. Les privilèges invités peuvent être limités à des ressources spécifiques, mais il est facile de faire une erreur permettant aux invités d'accéder aux ressources qui ne leur sont pas destinées.

Authentification directe

Il arrive parfois que le domaine spécifié dans la requête de connexion ne soit pas le nom de l'ordinateur connecté, ni le nom du domaine dans lequel il figure, ni le nom d'un domaine approuvé. Dans ce cas, Windows NT tente la dernière méthode d'authentification de la requête. Windows NT tente de trouver le nom d'utilisateur de l'ordinateur offrant le partage, et si le nom d'utilisateur existe, Windows NT compare le mot de passe associé au nom d'utilisateur au mot de passe fourni. Si les deux mots de passe correspondent, la requête est authentifiée. Cette opération correspond à l'étape 4 dans les Figures 1.1 et 1.2.

L'étape 4 de l'authentification de Windows NT est souvent appelée authentification directe, mais en réalité l'authentification directe inclut également des parties de l'authentification où les détails sont vérifiés localement et transmis aux contrôleurs de domaine (étapes 1 à 3). L'étape 4 de l'authentification directe pourrait être appelée authentification sans domaine.

Figure 1.2 Diagramme de la sécurité par authentification directe

Modèles de domaine

Les domaines Windows NT constituent un moyen souple d'organiser la sécurité informatique. Il existe trois modèles de domaine classiques :

• Le modèle de domaine unique est simple, mais sa taille ne peut être augmentée au-delà de la fourchette des 40 000 comptes, ce qui signifie 15 000 utilisateurs finaux.

Le modèle de domaine maître unique peut franchir cette limite, car il répartit les comptes dans des domaines distincts, suivant qu'ils sont destinés à des utilisateurs et à des services ou à des ordinateurs (qui permettent l'inclusion dans le domaine). Les comptes d'utilisateur et de service vont dans un domaine maître, qui est souvent appelé domaine de compte pour cette raison. Les comptes d'ordinateur sont mis dans les domaines de ressources, qui se fient au domaine maître et permettent par conséquent l'accès aux utilisateurs qui ont été authentifiés par le domaine maître. Le modèle de domaine maître unique est limité à environ 30 000 utilisateurs. Il fournit également une certaine modularité au sein de l'administration, de sorte que les administrateurs locaux ou les administrateurs dans les unités d'exploitation peuvent ajouter des ordinateurs aux domaines même s'ils ne peuvent pas avoir le privilège d'ajouter des comptes utilisateur au domaine de compte.

Notez que les utilisateurs d'ordinateurs figurant dans des domaines de ressources peuvent se connecter soit au domaine maître soit au domaine de ressources (ou à l'ordinateur local). L'ordinateur du domaine de ressource est toujours authentifié en tant que membre valide du domaine de ressource, mais l'utilisateur peut être authentifié en tant que membre valide du domaine maître, du domaine de ressource ou de l'ordinateur lui-même. Les comptes détenus par l'utilisateur dans chaque cas diffèrent, mais ils sont tous également valides sur l'ordinateur. Ce point est important pour comprendre que l'appartenance des ordinateurs au domaine maître n'est pas déterminant pour l'utilisation des comptes d'utilisateurs à partir des domaines maîtres ou des domaines de ressources, les comptes d'utilisateurs pouvant être utilisés par les uns ou les autres.

L'évolution du modèle de domaine maître multiple n'est pas limitée et permet également aux unités d'organisation de gérer les comptes utilisateur par eux-mêmes, alors qu'ils ne peuvent pas gérer les comptes d'utilisateur des autres unités. Cependant, le modèle de domaine maître multiple ne génère pas une charge système supplémentaire, car un nombre relativement important d'approbations est impliqué. La Figure 1.3 illustre les principales configurations de domaine Windows NT où SMS peut être utilisé.

Figure 1.3 Les modèles de domaine Windows NT

Autres fonctionnalités de sécurité Windows NT

Outre l'authentification, le contrôle d'accès et les fonctionnalités de gestion de domaine, Windows NT a également des fonctionnalités de sécurité pour l'audit, les profils, les stratégies de sécurité du système et de représentation. Ce sont des fonctionnalités importantes qui garantissent que les stratégies de sécurité de la société sont respectées et qui assurent la sécurité de Windows NT. Si vous comprenez ces fonctionnalités, vous pouvez les utiliser efficacement avec SMS pour renforcer la sécurité.

Audit

Windows NT peut consigner des événements de sécurité spécifiques dans son journal de sécurité. Vous pouvez utiliser cet outil puissant pour surveiller le mode d'utilisation d'un ordinateur, ce qui peut vous aider à résoudre des problèmes à et détecter les attaques. Windows NT peut surveiller des actions comme la connexion à l'ordinateur, l'ouverture de fichiers ou l'utilisation de droits de sécurité. Ces actions peuvent créer des problèmes de sécurité si elles sont effectuées sans respecter les stratégies de sécurité.

La stratégie d'audit de votre ordinateur Windows NT détermine si les événements apparaissent dans le journal de sécurité. Si vous ne sélectionnez pas les éléments à surveiller, vos fichiers journaux vont croître, certaines entrées nouvelles seront perdues et il sera difficile d'identifier des événements autres que les événements d'audit. Vous pouvez activer l'audit des événements système ainsi que de l'accès aux fichiers et aux objets.

Pour activer l'audit des événements système, utilisez le Gestionnaire des utilisateurs ou le Gestionnaire des utilisateurs pour les domaines. Dans le menu Stratégies, sélectionnez Audit, puis sélectionnez Auditer ces événements. Vous pouvez ensuite choisir de contrôler la réussite ou l'échec des événements suivants :

• la connexion et la déconnexion ;

• l'accès aux fichiers et aux objets ;

• l'utilisation des droits utilisateur ;

• la gestion des utilisateurs et des groupes ;

• les modifications de la stratégie de groupe ;

• le redémarrage, l'arrêt et les opérations système ;

• le suivi des processus.

La configuration par défaut est N'auditer aucun événement. Par défaut, les événements de sécurité ne sont pas enregistrés dans le journal de sécurité.

Windows NT vous permet de contrôler l'accès aux fichiers et aux objets. Avant de configurer vos fichiers, répertoires et imprimantes pour l'audit, vérifiez que vous avez activé la fonctionnalité d'audit sur votre système en choisissant de contrôler au moins l'accès aux fichiers et aux objets.

L'audit des fichiers et des répertoires sur vos partitions NTFS vous permet de suivre l'utilisation, d'identifier les auteurs de diverses actions et d'établir leurs responsabilités. Pour activer l'audit de fichiers ou de répertoires particuliers, utilisez le Gestionnaire de fichiers. Dans le menu Sécurité, sélectionnez Audit. Ajoutez les utilisateurs et les groupes que vous souhaitez surveiller. Sélectionnez les types d'accès que vous souhaitez auditer. Vous pouvez notamment vérifier la réussite ou l'échec des opérations Lire, Écrire, Exécuter, Supprimer, Modifier les autorisations et Prendre possession.

Pour contrôler l'accès aux imprimantes, utilisez le Gestionnaire d'impression. Dans le menu Sécurité, choisissez Audit. Ajoutez les utilisateurs et les groupes que vous souhaitez surveiller, puis sélectionnez les types d'accès que vous souhaitez contrôler. Choisissez ensuite de vérifier la réussite ou l'échec des opérations Imprimer, Contrôle intégral, Supprimer, Modifier les autorisations et Prendre possession.

Profils

Un profil d'utilisateur de Windows NT 4.0 décrit la configuration Windows NT pour un utilisateur spécifique, y compris l'environnement de l'utilisateur et le paramétrage des préférences. Ainsi, un profil inclut les paramètres et les options de configuration spécifiques de cet utilisateur, comme les applications installées, les icônes de bureau et les options de couleur. Ce profil est construit en partie à partir des informations de stratégie système (comme les chaînes auxquelles un utilisateur a accès et les données qu'il ne peut pas modifier) et en partie à partir des modifications autorisées, enregistrées qu'un utilisateur effectue pour personnaliser son bureau.

Ces profils génèrent des modifications dans le paramétrage, les répertoires et les fichiers installés sur les ordinateurs clients. Ils sont créés lorsqu'un utilisateur se connecte pour la première fois à un ordinateur. Lorsque des comptes sont supprimés, les profils correspondants doivent également être supprimés, car cette opération ne s'exécute pas automatiquement. Si l'administrateur supprime un compte, il doit supprimer manuellement le profil (dans le panneau de configuration Système). À l'instar des autres comptes, les comptes SMS ont généralement des profils, une fois le premier compte utilisé sur chaque ordinateur.

Stratégies système

Une stratégie système est un ensemble de paramètres de Registre définissant les ressources de l'ordinateur mises à la disposition d'un utilisateur ou d'un groupe d'utilisateurs. Elles définissent les divers aspects de l'environnement de bureau qu'un administrateur système doit contrôler, comme les applications disponibles, les applications affichées sur le bureau de l'utilisateur, les applications et les options proposées dans le menu Démarrer, les utilisateurs habilités à modifier les attributs de leurs bureaux, etc.

Les stratégies système constituent un dispositif de sécurité puissant, car elles permettent de restreindre la capacité des utilisateurs à installer des logiciels non testés et non autorisés qui pourraient compromettre la sécurité de nombreuses façons différentes. Elles sont déterminantes pour SMS car il faut installer des composants clients SMS. Par ailleurs, SMS exécute des programmes supplémentaires dans le cadre de ses opérations habituelles ou lorsqu'ils sont distribués par les administrateurs. Par conséquent, les stratégies système appliquées doivent être restrictives mais en même temps permettre l'exécution des fonctions SMS.

Représentation

Un aspect important des communications entre les serveurs et les clients concerne la capacité d'un serveur à déterminer s'il faut satisfaire la requête d'un client. S'exécutant dans un contexte de sécurité hautement privilégié, de nombreux services ont beaucoup plus de privilèges et de possibilités qu'un client type demandant un service. Un service de fichiers réseau s'exécutant sur le serveur en est un exemple. Ce service a un accès intégral à tous les fichiers sur le serveur, mais les utilisateurs demandant accès aux fichiers sur le serveur ont un accès limité. Le service exécute la requête du client uniquement si ce dernier a des droits d'accès suffisants sur les fichiers demandés.

Il existe deux méthodes pour déterminer si un client a des droits d'accès suffisants pour une opération : le contrôle d'accès par le serveur ou le contrôle d'accès par le service. La méthode exhaustive intègre au service la logique de vérification des autorisations relatives aux accès aux clients. Le service utilise les informations d'autorisation provenant d'un fichier d'autorisation distinct pour déterminer si le client a des droits suffisants pour effectuer l'opération demandée. Windows NT offre aux services un moyen pour déterminer l'autorisation des clients, qui passe par une fonctionnalité appelée représentation. La représentation est fondée sur l'ajustement temporaire du contexte de sécurité du service sur le client avant que le service tente d'accéder à une ressource.

Windows NT implémente automatiquement le contrôle d'accès sur une ressource lorsque le service tente d'ouvrir la ressource système. Le recours à la représentation et aux vérifications des accès au niveau système simplifie le développement de service et assure une utilisation efficace des contrôles d'accès sous Windows NT.

Sécurité NetWare

SMS prend véritablement en charge les environnements Novell NetWare et utilise efficacement la sécurité NetWare. Cet aspect est cependant trop vaste pour être traité correctement en quelques phrases et exige de bien comprendre la sécurité SMS (décrite dans la partie 2, "Modèle de sécurité de SMS" de ce document). C'est pourquoi une partie complète lui a été consacrée (partie 3, "Novell NetWare dans le modèle de sécurité de SMS").

Sécurité SQL Server

SMS 2.0 utilise Microsoft SQL Server pour stocker la base de données d'inventaire et de la configuration SMS. SMS peut utiliser la version 6.5 ou7.0 de SQL Server. La version 7.0 est généralement plus facile à utiliser, mais si votre version provient d'une mise à niveau de SMS 1.2 ou si vous avez largement investi dans la version 6.5 de SQL Server, il est possible que vous ne souhaitiez pas effectuer de mise à niveau maintenant. Généralement, les deux versions de SQL Server ont les mêmes problèmes de sécurité, mais la terminologie est différente et dans ce cas, les différences entre les deux versions sont minimes.

SQL Server 6.5

SQL Server 6.5 offre trois modèles de sécurité pour l'authentification des tentatives de connexion :

Sécurité standard

L'administrateur du système SQL Server définit les ouvertures de session SQL Server avec mots de passe dans SQL Server, puis associe les connexions aux utilisateurs dans des bases de données. Les ouvertures de session SQL Server sont séparées des comptes utilisateur Windows NT.

Sécurité intégrée

L'administrateur du système SQL Server définit les ouvertures de session pour les comptes utilisateur Windows NT autorisés à se connecter à SQL Server. Par défaut, tous les administrateurs de domaine bénéficient d'une sécurité de niveau sa. Les utilisateurs n'ont pas à spécifier une ouverture de session et un mot de passe particuliers lorsqu'ils se connectent à SQL Server une fois connectés au réseau Windows NT. Lors de l'ouverture de session, SQL Server Net-Library tente d'établir une connexion approuvée avec SQL Server. Si le compte Windows NT de l'utilisateur est un compte que l'administrateur système a défini dans SQL Server, la connexion est établie.

Sécurité mixte

L'administrateur système peut définir des ouvertures de session SQL Server et des comptes Windows NT en tant qu'ouvertures de session SQL Server. Les utilisateurs ayant des comptes Windows NT peuvent utiliser des connexions approuvées, alors que les autres utilisent la sécurité standard et des ouvertures de session SQL Server.

Seuls les canaux nommés ou les Net-Libraries multiprotocoles prennent en charge la sécurité intégrée et les connexions approuvées, mais le multiprotocole n'est pas géré par SMS. La sécurité intégrée offre plusieurs avantages :

• Il est inutile de stocker les mots de passe SQL Server dans l'application (comme SMS).

• Les mots de passe ne figurent jamais dans les paquets SQL Server TDS (Tabular Data Stream), (TDS étant le protocole SQL Server au niveau application).

• La sécurité intégrée est facile à administrer car l'administrateur système peut utiliser l'utilitaire Gestionnaire de sécurité SQL pour créer les ouvertures de session SQL Server à partir de comptes Windows NT existants.

SQL Server 7.0

Dans SQL Server 7.0, l'Assistant de sécurité remplace le Gestionnaire de sécurité SQL. Le terme sécurité intégrée est remplacé par l'authentification Windows NT et est disponible sur toutes les bibliothèques réseau. L'authentification SQL Server, précédemment appelée sécurité standard, est assurée pour la compatibilité à rebours et pour les environnements Windows 95 et Windows 98. Son utilisation n'est pas recommandée pour les serveurs dans l'environnement d'entreprise.

La sécurité mixte n'est pas une option explicite de SQL Server 7.0. L'authentification Windows NT est toujours disponible. L'authentification SQL Server peut être activée et désactivée. L'action d'une sécurité mixte est obtenue en activant l'authentification SQL Server.

Les rôles remplacent le concept SQL Server 6*.x* de groupes. Les rôles s'apparentent à la sécurité Windows NT 4.0 et sont des comptes de groupe ayant des membres. Les autorisations sont affectées à des rôles à l'aide d'instructions GRANT, REVOKE et DENY. DENY est une nouvelle autorisation explicite, qui est similaire aux autorisations Windows NT. Elle refuse explicitement l'autorisation sur un objet et a priorité sur toutes les autres autorisations.

Sécurité WMI

SMS utilise WMI (Windows Management Instrumentation) comme une interface de gestion normalisée. SMS utilise WMI sur les clients pour le rassemblement de l'inventaire matériel et pour l'analyse de l'état du système, sur les serveurs en tant qu'interface avec la base de données SMS, et sur les consoles en tant qu'interface avec la base de données SMS. WMI sert également à stocker des données de configuration, comme celles utilisées par Network Trace.

WMI assure une sécurité intégrale pour le système d'exploitation Microsoft Windows NT/Microsoft Windows 2000, et une sécurité limitée pour Windows 95/98. La sécurité WMI authentifie les informations de connexion d'un utilisateur pour l'ordinateur local et pour l'accès à distance. WMI accorde aux utilisateurs validés une forme d'accès contrôlé à l'ensemble du référentiel CIM (Common Information Model).

Dans sa version actuelle, WMI n'assure pas la sécurité pour les ressources système comme les classes et les instances. Ce qui n'est pas le cas de la version de WMI intégrée à Windows 2000, où les administrateurs peuvent utiliser WMI pour contrôler les autorisations globales sur les opérations relatives aux espaces de noms, comme limiter l'accès de certains utilisateurs aux opérations en lecture seule sur les données SMS. La version de WMI intégrée à SMS 2.0 pour l'installation sur des ordinateurs exécutant Windows NT 4.0, Windows 95 ou Windows 98 autorise uniquement le contrôle de l'accès à WMI, et non l'accès aux espaces de noms dans WMI.

Chaque nom d'espace WMI dispose de son propre descripteur de sécurité (SD), qui permet à l'espace de noms d'avoir ses propres paramètres de sécurité. Comme le système de fichiers Microsoft Windows NT (NTFS), la fonctionnalité d'héritage peut être utilisée pour simplifier l'administration de la sécurité. Chaque entrée de contrôle d'accès (ACE) dans le descripteur de sécurité de l'espace de noms comporte un champ d'indicateurs, qui précise si l'héritage peut être mis en œuvre. Par exemple, si l'héritage de contenu est autorisé, alors l'entrée de contrôle d'accès du descripteur de sécurité de l'espace de noms est transmise aux espaces de noms enfants.

Le descripteur de sécurité est composé lors de l'établissement de la première connexion à l'espace de noms. Il est élaboré à partir des entrées de contrôle d'accès des espaces de noms dans la chaîne d'héritage en suivant les modifications spécifiées par les bits hérités de chaque espace de noms. Par défaut, le propriétaire est le compte de l'administrateur local, et le groupe Administrateur local a des droits sur toutes les opérations, y compris l'accès distant.

Le descripteur de sécurité est également utilisé pour contrôler l'accès aux services WMI. Ce descripteur de sécurité standard Windows NT contient une liste de contrôle d'accès, c'est-à-dire la liste des entrées de contrôle d'accès. Chaque entrée de contrôle d'accès accorde l'autorisation d'exécuter une opération restreinte, comme les connexions, l'accès distant, l'exécution d'une méthode et l'écriture dans le référentiel CIM (la base de données WMI). Les descripteurs de sécurité de WMI sont stockés dans le référentiel CIM.

Sur les plates-formes Microsoft Windows NT/Windows 2000, il n'y a aucune distinction entre accès local et accès distant. Cependant, avec une connexion distante, les utilisateurs peuvent spécifier un nom d'utilisateur et un mot de passe, qui viennent remplacer le nom d'utilisateur et le mot de passe en cours. Avec une connexion locale, les utilisateurs ne peuvent pas effectuer ce remplacement. Sur les plates-formes Windows 95 et Windows 98, les utilisateurs locaux sont considérés comme étant des administrateurs et obtiennent tous les droits. Il n'y a aucune authentification. En revanche, les utilisateurs distants sont validés en utilisant des instances de classes système WMI.

Les administrateurs peuvent utiliser le programme WBEMperm.exe pour définir des autorisations pour les utilisateurs WMI sur des ordinateurs exécutant Windows NT Server et utiliser le contrôle WMI sur des ordinateurs exécutant Windows 2000 Server.

Sécurité DCOM

DCOM fait office de protocole principal pour les communications WMI. Comme WMI utilise son propre modèle de sécurité, il ne s'appuie pas sur la sécurité DCOM. Cette dernière ne répond pas aux besoins de WMI, car à l'inverse de la sécurité DCOM, la sécurité WMI est axée sur l'espace de noms et non sur des composants. Cependant, si la sécurité DCOM est rompue, la sécurité WMI est rompue, entraînant l'arrêt de SMS. C'est pour cette raison que l'administrateur SMS serait bien avisé de prendre en compte la sécurité DCOM.

La fonctionnalité DCOM (COM réparti) de Microsoft étend COM (Component Object Model) pour prendre en charge la communication entre les objets sur différents ordinateurs reliés par un réseau local, un réseau étendu ou même Internet. Avec DCOM, une application peut être répartie sur les emplacements les plus judicieux pour l'application. DCOM gère les détails de bas niveau des protocoles réseau. Le fait que les applications utilisent des réseaux pour la distribution suscite des difficultés non seulement en raison des limites physiques de la largeur de bande et du délai d'attente, mais de plus crée de nouveaux problèmes de sécurité entre et au sein des clients et des composants. Comme de nombreuses opérations sont physiquement accessibles par quiconque ayant accès au réseau, l'accès à ces opérations doit être restreint à un niveau supérieur.

Sans la prise en charge de la sécurité à partir de la plate-forme de développement réparti, chaque application, comme WMI, doit être impérativement amenée à implémenter ses propres fonctions de sécurité. Une fonctionnalité courante exige de passer un nom d'utilisateur et un mot de passe (ou une clé publique) généralement cryptée à une méthode d'ouverture de session. L'application valide ces informations d'identification en se référant à une base de données ou à un répertoire utilisateur et retourne un identifiant à utiliser dans les appels de méthodes à venir. Dès lors, à chaque nouvel appel de méthode sécurisée, les clients doivent transmettre cet identificateur de sécurité. Chaque application doit stocker et gérer une liste de noms d'utilisateurs et de mots de passe, protéger l'annuaire des utilisateurs de tout accès non autorisé, gérer les modifications de mots de passe et gérer les risques de sécurité liés à l'envoi de mots de passe sur le réseau.

Une plate-forme distribuée, comme DCOM, doit fournir un environnement de sécurité pour différencier les différents clients ou groupes de clients en toute sécurité, afin que le système ou que l'application dispose d'un moyen pour identifier l'utilisateur tentant d'exécuter une opération ou un composant. DCOM utilise l'environnement de sécurité extensible fourni par Windows NT. Windows NT fournit un ensemble intégré de prestataires de sécurité intégrée qui gèrent plusieurs fonctionnalités d'identification et d'authentification intégrées, à partir de modèles de sécurité approuvés usuels pour une mise à l'échelle massive des fonctionnalités de sécurité par clé publique qui ne sont pas gérés de façon centralisée. Une partie centrale de l'environnement de sécurité est un répertoire utilisateur, qui stocke les informations nécessaires pour valider les informations d'identification de l'utilisateur (nom d'utilisateur, mot de passe et clé publique).

Sécurité orientée composant DCOM

DCOM peut rendre des applications réparties fiabilisées sans code ou conception de sécurité spécifique dans le client ou le composant. De même que le modèle de programmation DCOM masque l'emplacement des composants, elle masque également les exigences de sécurité relatives aux composants. Le même code binaire (existant ou prêt à fonctionner) fonctionnant dans un environnement à un seul ordinateur, où la sécurité peut ne pas constituer un problème, peut être utilisé de façon sécurisée dans un environnement distribué. DCOM assure cette transparence en matière de sécurité en laissant les développeurs et les administrateurs configurer les paramètres de sécurité pour chaque composant. De même que le système de fichiers de Windows NT permet aux administrateurs de définir les listes de contrôle d'accès (ACL, Access Control List) relatives aux fichiers et aux répertoires, DCOM mémorise des listes de contrôle d'accès pour les composants. Ces listes ne font qu'indiquer les utilisateurs ou les groupes d'utilisateurs ayant le droit d'accéder à un composant d'une classe déterminée. Ces listes peuvent aisément être configurées à l'aide de l'outil de configuration de DCOM (DCOMCNFG) ou programmées à l'aide du Registre de Windows NT et des fonctions de sécurité de Win32.

Chaque fois qu'un client appelle une méthode ou crée l'instance d'un composant, DCOM obtient le nom d'utilisateur en cours du client qui est associé au processus en cours (en l'occurrence, le thread d'exécution en cours). Windows NT garantit que les informations d'identification de cet utilisateur sont authentiques. DCOM transmet ensuite le nom d'utilisateur de l'ordinateur ou du processus lors de l'exécution du composant. Ensuite, DCOM sur l'ordinateur du composant valide de nouveau le nom d'utilisateur à l'aide de la fonctionnalité d'authentification configurée et vérifie la liste de contrôle d'accès associée au composant (le premier composant s'exécutant dans le processus contenant le composant. Pour plus d'informations, consultez le document technique sur l'architecture DCOM, fourni sur TechNet et sur le site Web de Microsoft.) Si le nom d'utilisateur du client ne figure pas dans cette liste (soit directement soit indirectement en tant que membre d'un groupe d'utilisateurs) DCOM rejette l'appel avant que le composant ne soit sollicité de quelque façon que ce soit. DCOM est installé sur les niveaux inférieurs des protocoles réseau, notamment le protocole d'appel de procédure distant (RPC, Remote Procedure Call) et le protocole des canaux nommés. Chacun de ces niveaux peut également avoir des fonctionnalités de sécurité. Celles-ci ne sont néanmoins pas utilisées avec SMS ou WMI.

Sécurité physique

La sécurité logicielle est aussi fondamentale que la sécurité SMS, mais sans la sécurité physique de base appropriée, SMS reste vulnérable. SMS est fondé sur le principe que l'ordinateur client peut ne pas être physiquement fiable, et par conséquent les clients SMS n'ont pas de fonctionnalité dont la mise en œuvre présente un risque pour la sécurité de SMS.

Attention Cette présentation suppose que les ordinateurs clients soient utilisés par les utilisateurs n'ayant pas de privilèges renforcés sur d'autres ordinateurs. Les utilisateurs privilégiés ayant une connaissance suffisante peuvent aisément transformer un ordinateur client en console, et si leurs privilèges les autorisent à les rattacher à un serveur de sites, ils auront un accès complet au système SMS. Par ailleurs, le serveur de sites et les ordinateurs consoles sont souvent des ordinateurs clients, mais pour les besoins de cette présentation, ils ne seront pas considérés en tant qu'ordinateurs clients.

Lorsqu'elle est connectée à un serveur de sites SMS, une console Administrateur peut être utilisée à mauvais escient, au détriment de SMS lui-même ou de l'ordinateur qu'il gère. Par conséquent, ces consoles doivent toujours être physiquement sécurisées pendant les sessions d'utilisateur. D'une manière idéale, elles doivent être installées dans une salle fermée à clé, protégée de tout accès non autorisé. Si ceci n'est pas possible, il faut impérativement les sécuriser lorsque le personnel n'est pas physiquement présent dans la salle. Pour ce faire, il est possible de donner l'instruction à Windows NT de verrouiller le poste de travail ou d'utiliser un économiseur d'écran sécurisé qui entre en activité dès l'arrêt de la saisie par l'utilisateur.

Un serveur de site SMS est également exposé s'il n'est pas physiquement protégé pendant les sessions administrateur et lorsqu'il est laissé sans surveillance. Non seulement les serveurs de sites ont une console Administrateur SMS, mais ils ont également le programme de configuration requis pour réinitialiser les sites.

Stratégies et procédures de sécurité

Les stratégies et les procédures documentées sont profitables à tout système, mais elles conviennent tout particulièrement aux systèmes de sécurité des ordinateurs. En documentant les stratégies et les procédures de sécurité des ordinateurs de votre société qu'il faut utiliser, vous permettez à l'ensemble du personnel habilité et aux gestionnaires de vérifier systématiquement ces stratégies et ces procédures. Cette opération permet d'être assuré que les détails manquants seront ajoutés, les points faibles renforcés et les éléments inutiles supprimés. Par ailleurs, dans la mesure où l'ensemble du personnel sera parfaitement renseigné sur les stratégies et les procédures, une mauvaise utilisation du système par manque d'information ne pourra plus être invoquée.

Il convient de mettre en place des stratégies et des procédures pour chaque société, car les risques, les technologies, le personnel et les pratiques varient d'une société à une autre. Par conséquent, il est très improbable que les stratégies et les procédures d'une société donnée conviennent à une autre société.

En règle générale, les stratégies de sécurité traitent de questions comme déterminer les personnes ayant accès aux diverses ressources, définir la façon de configurer et d'appliquer la sécurité, et indiquer la façon dont la société répond aux violations et aux brèches de sécurité. Les procédures de sécurité définissent la façon dont un utilisateur demande, obtient et reçoit le droit d'accès à un système ; le mode de configuration de sécurité ; les réponses apportées à une brèche de sécurité, etc. Les procédures de sécurité doivent être cohérentes avec les stratégies de sécurité.

Les stratégies et les procédures de sécurité en bonne et due forme effectuent diverses fonctions :

• En fournissant une liste de contrôle des procédures, y compris les vérifications du système, elles garantissent une exécution intégrale des fonctions de sécurité en cours.

• Comme tous les membres du personnel sont parfaitement informés des conséquences produites par les fuites de sécurité, prétendre l'ignorance ne sera plus recevable si un acte inacceptable est commis.

• En anticipant les événements de sécurité et les réactions appropriées, elles accélèrent l'exécution de la riposte et réduisent au minimum les dégâts potentiels.

• Dans la mesure où elles sont informées correctement, toutes les personnes concernées sont assurées que les stratégies et les procédures sont raisonnables et complètes.

Les stratégies de sécurité SMS doivent être élaborées dans le cadre des stratégies de sécurité de la société. Elles doivent également prendre en compte les questions et les risques particuliers qu'un système de gestion des ordinateurs peut provoquer. Elles doivent appliquer le niveau de tolérance de votre société en matière de risque de sécurité, lequel est souvent régi par la nature de l'activité et des pratiques de votre entreprise. La partie 4, consacrée à la planification et à l'implémentation, traite plusieurs questions s'y rapportant.

Il faut développer des procédures de sécurité SMS pour implémenter les stratégies de sécurité SMS et veiller à ce qu'elles intègrent les détails techniques présentés dans le présent document et dans le Guide d'administration de Systems Management Server Version 2.0.

Dernière mise à jour le mercredi 29 janvier 2003

Pour en savoir plus

• L'article d'origine sur le site US

• Systems Management Server Version 2.0 Administrator's Guide (en anglais)

• Conception et planification de la sécurité interne de Windows NT

• La surveillance des processus, des services et de la sécurité de Windows NT

• Diagnostics à distance avec Systems Management Server Version 2.0

• Toutes les informations techniques concernant SMS

• Toutes les informations de TechNet sur la sécurité

Download

200030129 security.doc

0,98 Mo

Fichier Microsoft Word