HSC
Cabinet de consultants en sécurité informatique depuis 1989 - Spécialisé sur Unix, Windows, TCP/IP et Internet
Mode texte : accès au contenu de la page
Hervé Schauer Consultants
Vous êtes ici : Accueil > Ressources > Articles > Modèle de sécurité du système Windows
Accéder au : Site HSC des formations
Recherche :  
English version
   Services   
o Domaines de compétences
o Conseil & Expertise
o Prestations ISO 27001
o Audit & Évaluation
o Tests d'intrusion
o Tests de vulnérabilités (TSAR)
o Analyse Forensique
o Certification ARJEL
o Formations
o E-learning
   Conférences   
o Agenda
o Interventions passées
o Tutoriels
   Ressources   
o Index thématique
o Brèves
o Présentations
o Cours
o Articles
o Outils (téléchargement)
o Veille en vulnérabilité
   Société   
o Hervé Schauer
o Equipe
o Offres d'emploi
o Références
o Historique
o Partenariats
o Associations
   Presse et
 communication
 
 
o Newsletter HSC
o Revue de presse
o Communiqués de presse
o Publications
   Contacts   
o Coordonnées
o Requêtes particulières
o Accès à nos locaux
o Hôtels proches de nos locaux
|>|Modèle de sécurité du système Windows  
> Accès au contenu HTML Début de l'article  
> Description Article décrivant le modèle de sécurité des systèmes Windows (services d'authentification, d'autorisation et d'audit)  
> Contexte & Dates Article paru dans le numéro 2 de la revue MISC (Multi-System & Internet Security Cookbook), Avril 2002.
Publication sur www.hsc.fr le 14 octobre 2002.  
> Auteur Jean-Baptiste Marchand  
> Langue et Nature  
> Résumé &
Table des matières
1. Introduction
2. Vue d'ensemble
3. Acteurs et concepts du modèle
3.1. Principaux
3.2. Groupes
3.3. Domaine
3.4. Relations de confiance
4. Authentification
4.1. Phase d'authentification
4.2. Attributs d'autorisation
4.3. Session de connexion
5. Autorisation
5.1. Contrôle d'accès
5.2. Permissions
5.3. Descripteur de sécurité
5.4. Jeton
5.5. Algorithme du contrôle d'accès
5.6. Origine des descripteurs de sécurité
5.7. Privilèges
6. Audit
6.1. Administration et exploitation de l'audit
6.2. Audit des accès
7. Ce dont nous n'avons pas parlé
8. Conclusion
9. Références
 
> Documents liés
themeWindows
[Formation]  Sécurité Windows
[Formation]  Sécuriser Windows - SANS SEC505
[Présentation]  Extraction de données authentifiantes de la mémoire Windows [29 mai 2013 - Français]
[Présentation]  Extraction de données authentifiantes de la mémoire Windows [4 avril 2013 - Français]
[Présentation]  Skyrack, rop for masses [17 juin 2011 - Anglais]
[Présentation]  Extraction des empreintes de mots de passe en environnement Windows [10 mai 2011 - Français]
[Outil]  Outil SSToPer [Implémentation Linux d'un client SSTP - Anglais]
[Présentation]  Rainbow Tables et caractères accentués sous Windows [31 mai 2007 - Français]
[Présentation]  Sécurité des Postes Clients [29 mars 2007 - Français]
[Brève]  Présentation des Alternates Data Stream (ADS) de NTFS. [28 octobre 2005 - Français]
[Présentation]  Sessions nulles dans MSRPC - exploitation et protection [29 juin 2005 - Anglais]
[Brève]  Windows remote administration tools overview [15 juin 2005 - Anglais]
[Article]  Windows log files [6 juin 2005 - Anglais]
[Présentation]  Active Directory network protocols and traffic [4 mai 2005 - Anglais]
[Brève]  Minimizing Windows Server 2003 network services [6 avril 2005 - Anglais]
[Présentation]  Le principe du moindre privilège appliqué aux systèmes Windows [7 février 2005 - Français]
[Présentation]  SSLTunnel pour Windows [22 septembre 2004 - Français]
[Présentation]  Protocoles et trafic réseau en environnements Active Directory [13 septembre 2004 - Français]
[Présentation]  Services réseaux Windows [13 janvier 2004 - Français]
[Présentation]  Windows network services internals - HiverCon 03 [6 novembre 2003 - Anglais]
[Article]  Windows network services internals [22 octobre 2003 - Anglais]
[Présentation]  Services réseaux sous Windows [14 avril 2003 - Anglais]
[Brève]  Minimization of network services on Windows systems [2 septembre 2002 - Anglais]
[Article]  Services réseaux des systèmes Windows - Étude de cas avec Windows 2000 et Windows XP [6 juin 2002 - Français]
[Brève]  Minimisation des services réseaux sur les systèmes Windows [3 juin 2002 - Français]
[Brève]  Administration distante de systèmes Windows (Partie 2) - rpcclient [18 février 2002 - Français]
[Brève]  Administration distante de systèmes Windows (Partie 1) - SSH [19 novembre 2001 - Français]
[Présentation]  Le filtrage IP et IPsec dans Windows 2000 [7 septembre 2001 - Français]
[Présentation]  Microsoft & sécurité : attention danger [13 mars 2001 - Français]
[Présentation]  Flux réseau de Windows NT [24 septembre 1998 - Français]
[Article]  Les registres de NT4 relatifs à la sécurité [avril 1998 - Français]
> Droits d'auteur © 2002, Editions Diamond. Reproduction interdite. Reproduit sur le site web d'HSC avec autorisation.

 


1. Introduction

La sécurité des systèmes Windows (issus de la famille Windows NT, tels Windows NT 4.0, Windows 2000 ou Windows XP) est souvent l'objet de critiques. Des exemples récents de vulnérabilités graves peuvent laisser croire que ces systèmes sont intrinsèquement non sûrs. Cependant, il n'en est rien, Windows NT ayant été conçu dans l'objectif d'offrir des fonctionnalités de sécurité complètes. Cet article s'attache à présenter la mise en oeuvre dans Windows de trois services de sécurité : authentification, autorisation et audit.

Convention : tous les paramètres de configuration cités correspondent à une version anglaise du système. Ils apparaissent en italique, de même que les termes techniques anglais.


2. Vue d'ensemble

Avant d'aborder plus en détails les services de sécurité fournis par le système Windows, commençons par en présenter une vue d'ensemble.

Le service de sécurité le plus intuitif est probablement le contrôle d'accès aux ressources. Ce service permet de définir qui peut accéder aux ressources du système et de quelle manière. Ceci implique de pouvoir distinguer différentes entités y ayant accès. Le service d'authentication permet à une entité de prouver son identité au système, afin de disposer des autorisations qui lui ont été accordées.

Le service d'audit est plus facile à percevoir du point de vue de l'administrateur. Il permet d'avoir une certaine visibilité sur l'état du système, en gardant trace de certains événements significatifs dans son fonctionnement.

Ces services pouvant sembler abstraits, voyons concrètement comment ils sont utilisés dans le système Windows.

Sous Windows, toutes les ressources sont gérées de façon générique et centralisée sous forme d'objets. Par exemple, dans Windows 2000, il y a 27 types d'objets, tels que les objets fichier (File), processus (Process) ou encore clé de la base de registres (Key). Chaque objet du système est protégé par un descripteur de sécurité (Security Descriptor), qui définit quels types d'accès sont autorisés de la part de quelles entités.

En pratique, une entité n'accède pas directement à un objet. Ce sont des processus, fonctionnant sous son identité, qui accèdent à des objets. C'est donc au niveau du processus que les attributs d'autorisation doivent être conservés, de sorte que chaque processus dispose d'un contexte de sécurité lui permettant d'accèder ou non à des objets. Cette structure, attachée à tout processus, porte le nom de jeton d'accès (access token), ou tout simplement, jeton.

Avant de pouvoir lancer des processus, une entité doit s'authentifier auprès du système. Plusieurs méthodes d'authentification sont possibles telles que la connaissance d'un mot de passe (voir l'article de Denis Ducamp dans ce même numéro pour une présentation détaillée de l'authentification par mot de passe) , la présentation d'une carte à puce ou encore l'analyse biométrique. Dans tous les cas, une session de connexion (logon session) est accordée à tout utilisateur correctement authentifié. La session de connexion définit le contexte de sécurité d'une entité connectée à un système donné. C'est au sein de cette session de connexion que des processus peuvent être lancés, disposant chacun d'un contexte de sécurité personnalisable, par l'intermédiaire du jeton.


3. Acteurs et concepts du modèle

Nous présentons ici les acteurs et concepts constituant le modèle de sécurité du système Windows.

3.1. Principaux

En introduction, nous avons utilisé le terme entité pour désigner l'acteur qui s'authentifie auprès du système. En sécurité, il est courant de désigner une telle entité sous le terme de principal. La catégorie de principal la plus courante est celle des utilisateurs du système, tels qu'un administrateur système. De façon moins intuitive, les systèmes Windows sont également des principaux. En effet, ils ont aussi à s'authentifier auprès d'autres systèmes, tels que des contrôleurs de domaines.

Les informations propres à chaque principal sont conservées dans ce qu'il est d'usage d'appeler un compte, qui n'est autre qu'une entrée dans la base de données de sécurité du système (SAM dans Windows NT 4.0, Active Directory à partir de Windows 2000). Alors qu'il est plus simple pour des humains de faire référence à un principal en le désignant par un nom, par exemple Administrator, le système manipule plus aisément les principaux via une structure de donnée de longueur variable, appelée identifiant de sécurité (security identifier) et abrégée en SID.

Un SID peut être représenté sous la forme d'une chaîne de caractères, de la forme S-R-I-XXX-XXX-XXX, où S est la lettre S (pour rappeler qu'il s'agit d'un SID), R est le numéro du format binaire du SID (actuellement, 1), I est un entier identifiant l'autorité ayant émis le SID et XXXX-XXXX-XXXX est une suite de longueur variable, formée d'identifiants de sous-autorités ou d'identifiants relatifs (relative identifier, abrégé en RID). Par exemple, le SID correspondant au principal Administrator d'un système local sera de la forme S-1-5-21-XXXX-XXXX-XXXX-500. L'autorité ayant émis ce SID a pour identifiant 5 (SECURITY_NT_AUTHORITY). Plus précisément c'est la sous-autorité ayant pour identifiant 21 (SECURITY_NT_NON_UNIQUE) qui est à l'origine de ce SID, la suite notée XXXX-XXXX-XXXX formant un identifiant unique du système local. Enfin, 500 est le RID du principal Administrator.

Il n'est pas nécessaire de connaître parfaitement le format exact d'un SID. La chose importante à retenir est que, quel que soit sa longueur et son format, un SID identifie de façon unique un principal, au sein d'une autorité.

3.2. Groupes

Pour simplifier la gestion des principaux, il est d'usage de les placer dans des groupes, souvent en fonction de critères tels que des besoins similaires d'utilisation du système. Il existe deux grandes catégories de groupes : les groupes locaux à un système (connu des administrateurs sous le terme d'alias), visibles uniquement à l'échelle d'un système et les groupes globaux, visibles à plus grande échelle, que ce soit d'un domaine ou d'une forêt dans le cas d'Active Directory. Ces groupes sont également identifiés de façon unique par des SID.

3.3. Domaine

Un domaine définit un espace de confiance au sein duquel un contrôleur de domaine gère de façon centralisée les comptes des principaux ainsi que les différentes requêtes d'authentification. Un principal peut alors s'authentifier auprès de tout système faisant partie d'un domaine, chaque système du domaine utilisant le service d'authentification fourni par un contrôleur du domaine.

3.4. Relations de confiance

Pour un système, faire partie d'un domaine implique d'avoir confiance en ses contrôleurs de domaine. En effet, lorsqu'un principal se connecte à un système du domaine, ce système délègue l'authentification à l'un des contrôleurs du domaine, chargé d'authentifier le principal de façon honnête.

Lorsqu'un principal à authentifier ne fait pas partie du même domaine que le système sur lequel l'authentification se fait, le contrôleur de domaine contacté par le système s'adresse à l'un des contrôleurs de domaine de l'utilisateur, lui demandant d'authentifier celui-ci. Le domaine du système fait donc confiance au domaine de l'utilisateur, puisqu'il lui délègue le service d'authentification.

Les acteurs et concepts ayant été introduits, nous pouvons aborder le premier service de sécurité, l'authentification.


4. Relations de confiance

Tout principal souhaitant se connecter à un système Windows doit s'y authentifier. Après authentification, une session de connexion est créée, au sein de laquelle le principal va pouvoir lancer des processus.

4.1. Phase d'authentification

L'authentification elle-même peut être réalisée par le système local ou déléguée à un contrôleur de domaine.

Dans le cas d'une authentification locale, le composant réalisant l'authentification est l'autorité de sécurité locale (local security authority), abrégée en LSA. Dans ce cas, la base de données utilisée est la base SAM du système local.

Dans le cas d'une authentification sur un domaine, le système local délègue l'authentification à un contrôleur du domaine, qui peut alors authentifier le principal si celui-ci appartient au même domaine ou déléguer l'authentification à un autre contrôleur de domaine dans le cas contraire.

Dans les deux cas, si l'authentification se déroule correctement, la LSA du système récupère les attributs d'autorisation du principal, afin de pouvoir construire une session de connexion ayant le contexte de sécurité du principal authentifié.

4.2. Attributs d'autorisation

Les attributs d'autorisation sont récupérés à l'issue de la phase d'authentification, pour être affectés à la session de connexion et placés dans les jetons des processus rattachés à la session.

Les attributs d'autorisation sont composés de SID et des privilèges. Les SID sont utilisés pour le contrôle d'accès, tandis que les privilèges autorisent certaines actions, pour lesquelles le mécanisme de contrôle d'accès traditionnel n'est pas adapté.

Les groupes locaux et privilèges sont des attributs d'autorisation locaux, attribués au niveau du système local. En revanche, les SID des groupes globaux dont fait partie le principal sont des attributs d'autorisation globaux, qui doivent être transmis par un contrôleur de domaine à la LSA du système local.

4.3. Session de connexion

Il y a quatre types de session de connexion possibles (logon session) pour un principal : interactive, via le réseau, en tant que service et en tant que batch.

La session de connexion interactive est la plus courante : elle est créée lorsqu'un utilisateur se connecte de façon interactive, en saisissant son identifiant et son mot de passe à l'invite du programme winlogon.

Une session de connexion via le réseau est typiquement utilisée lorsqu'un principal se connecte à un système distant, par exemple pour accéder à des ressources sur un serveur distant. Les sessions de connexion en tant que service sont utilisées par les services Windows tandis que les sessions de connexion en tant que batch le sont pour des serveurs lancés par le gestionnaire de services COM.

A ceci s'ajoute une session de connexion spéciale et unique, la session de connexion SYSTEM. Cette session est créée au lancement du système et regroupe les processus systèmes. C'est également dans cette session de connexion que fonctionnent par défaut les services Windows. Tout processus fonctionnant dans cette session a tout pouvoir sur le système. Ce n'est pas le cas d'un processus lancé par un administrateur, qui ne possède pas certains privilèges.

Suivant le type de session de connexion utilisée, les possibilités ne sont pas les mêmes. Par exemple, une session de connexion réseau n'a pas la possibilité d'établir à son tour une session de connexion réseau, ceci afin de protéger des connexions par rebonds successifs sur plusieurs systèmes.

Aspect intéressant pour le contrôle d'accès, un SID est affecté à chaque type de session de connexion et placé dans les jetons des processus appartenant à un type de session de connexion donné. Par exemple, le SID dont le nom en clair est INTERACTIVE se retrouvera dans les jetons des processus appartenant à des sessions de connexion interactives. Ainsi, il est possible d'autoriser des accès à certains objets uniquement aux utilisateurs connectés de façon interactive.

Une session de connexion est repérée par un identifiant localement unique. Cet identifiant est utilisé pour construire un SID désignant cette session de connexion et placé dans les jetons de processus de cette session. Il est donc possible de faire du contrôle d'accès fin, non plus sur des principaux mais des instances de ces principaux, une session de connexion devant être vue comme une instance d'un principal sur le système. Cette possibilité est utilisée lorsqu'un même principal a plusieurs sessions de connexion et qu'elles doivent être isolées au niveau du contrôle d'accès.


5. Autorisation

Le service d'autorisation décide d'autoriser ou non les actions entreprises par des processus, en se basant sur les attributs d'autorisation contenus dans le jeton de chaque processus.

Parmi les attributs d'autorisation, les différents SID sont utilisés par le contrôle d'accès, mécanisme qui permet de contrôler quels principaux ont accès aux objets et de quelles façons. Les privilèges sont eux utilisés lorsque l'autorisation par contrôle d'accès n'est pas adaptée.

5.1. Contrôle d'accès

Le contrôle d'accès a lieu dans le contexte d'un processus accédant à un objet. Pour un processus, l'accès à un objet se fait toujours via une référence (handle), obtenue lors de l'ouverture de l'objet, via les fonctions de l'API Win32 du type OpenXxx() et CreateXxx(). Il est important de retenir que le contrôle d'accès, de même que l'audit, ont lieu lors de l'ouverture d'un l'objet. Si le contrôle d'accès valide l'ouverture d'un objet avec certaines permissions, il n'y a ensuite plus de contrôle pour cet objet, exceptés ceux s'assurant que l'objet est utilisé dans les limites de ce qui a été autorisé lors de son ouverture.

Par exemple, si au moment de l'ouverture en lecture seule d'un fichier par un processus, le fichier était en lecture et écriture pour le principal Administrator, une tentative d'écriture dans le fichier ne sera pas autorisée puisque le fichier a été ouvert en lecture seule. Si le fichier est fermé puis ré-ouvert en lecture-écriture, les deux types d'accès seront autorisés tant que le fichier reste ouvert, même si, entre temps, le droit d'écriture sur ce fichier est retiré au principal Administrator.

Le contrôle d'accès fonctionne en faisant le rapprochement entre trois éléments : les permissions spécifiées lors de l'ouverture d'un objet, le descripteur de sécurité de l'objet accédé et le jeton du processus (attributs d'autorisation) réalisant l'accès.

5.2. Permissions

Lorsqu'un processus ouvre une référence à un objet, il précise quels types d'accès il veut réaliser sur l'objet, via un masque de permissions décrivant les permissions sur l'objet dont il souhaite disposer. Si ces permissions sont compatibles avec le descripteur de sécurité de l'objet, une référence à l'objet est accordée, le système se contentant ensuite de vérifier que les types d'accès font partie de ceux spécifiés lors de l'ouverture de l'objet. Dans les fonctions de l'API Win32 du type OpenXxx() et CreateXxx(), le masque de permissions est fourni dans la paramètre de nom dwDesiredAccess.

Un masque de permissions est une valeur de 32 bits, subdivisée en 4 : permissions standards (8 bits), permissions spécifiques (16 bits), permissions génériques (4 bits) et divers drapeaux (4 bits).

Les permissions standards sont des permissions qui s'appliquent à tous les types d'objets. 5 sont actuellement définies : suppression de l'objet (DELETE), lecture du contenu du descripteur de sécurité de l'objet (READ_CONTROL), changement du propriétaire de l'objet (WRITE_OWNER), changement de la liste de contrôle d'accès de l'objet (WRITE_DAC) et autorisation de se synchroniser sur cet objet (SYNCHRONIZE).

Les permissions spécifiques ne s'appliquent qu'à un type d'objet donné. Par exemple, pour un objet du type processus, une permission, PROCESS_TERMINATE, est définie pour autoriser la terminaison d'un processus.

Enfin, quatre permissions génériques sont définies : lecture (GENERIC_READ), écriture (GENERIC_WRITE), exécution (GENERIC_EXECUTE) et les trois à la fois (GENERIC_ALL). Elles s'appliquent à tous les types d'objets et permettent un polymorphisme des permissions, chacune des 4 permissions génériques étant équivalente à une liste de permissions standards et spécifiques. Par exemple, la permission générique de lecture (GENERIC_READ) sur un objet de type clé de la base de registres accorde la permission standard READ_CONTROL et les trois permissions spécifiques KEY_QUERY_VALUE, KEY_ENUMERATE_SUB_KEYS et KEY_NOTIFY. Cette possibilité est intéressante pour le paramétrage des permissions sur les nouveaux objets créés, comme nous le verrons plus loin.

5.3. Descripteur de sécurité

A tout objet sécurisable est associé un descripteur de sécurité (security descriptor, abrégé en SD), qui contient trois informations principales : le SID du propriétaire de l'objet, sa liste de contrôle d'accès discrétionnaire (DACL) et sa liste de contrôle d'accès système (SACL), traitée en détail dans la partie audit.

Tout objet a un propriétaire, dont le SID est stocké dans le SD. Le propriétaire d'un objet a toujours le droit de lire et de modifier la DACL des objets lui appartenant. C'est pour cette raison que le contrôle d'accès est qualifié de discrétionnaire, étant à la discrétion du propriétaire.

La DACL est simplement une liste d'entrées de contrôle d'accès (access control entry, abrégée en ACE) listant quels accès sont possibles à quels SID. Ces SID peuvent désigner des principaux uniques, des groupes locaux ou globaux.

Une ACE peut être positive ou négative : si elle est positive, elle accorde un type d'accès ; si elle est négative, elle refuse un type d'accès. Le type d'accès est spécifié sous la forme d'un masque de permissions.

5.4. Jeton

Un jeton est attaché à un processus et définit son contexte de sécurité. Son contenu se subdivise en trois catégories : identité et attributs d'autorisation, sécurité par défaut pour les nouveaux objets créés et divers paramètres.

Pour le contrôle d'accès, les attributs d'autorisation utilisés sont les SID. Il y a au moins le SID du propriétaire du processus puis la liste des SID des groupes globaux (au niveau du domaine) et des groupes locaux (alias, au niveau du système local) dont le principal fait partie. Sont également présents un SID indiquant le type de session de connexion (par exemple, interactive) ainsi qu'un SID identifiant la session de connexion.

5.5. Algorithme du contrôle d'accès

L'algorithme utilisé pour le contrôle d'accès utilise trois éléments : le masque de permissions représentant le type d'accès demandé, le descripteur de sécurité représentant la protection de l'objet et le jeton du processus, contenant les attributs d'autorisation.

L'algorithme utilise un entier de la même taille qu'un masque de permissions (32 bits), qui sert d'accumulateur des permissions accordées. Il est initialisé à zéro au début de l'algorithme.

  • le système remplit l'accumulateur avec les permissions implicites. Si les permissions ainsi accumulées ne sont pas suffisantes, l'algorithme se poursuit.
  • Chaque entrée (ACE) de la DACL est examinée en séquence. Si une ACE autorise certaines permissions d'accès pour l'un des SID contenu dans le jeton, ces permissions sont accumulées.
  • L'algorithme se poursuit jusqu'à ce que l'un des trois événements suivants se produise : toutes les permissions présentes dans le masque de permissions spécifié lors de l'accès ont été accumulées, auquel cas l'accès est accordé ; une ACE refusant un accès à un SID contenu dans le jeton est rencontrée, auquel cas l'accès est refusé ; la fin de la DACL est atteinte sans que toutes les permissions aient été accumulées, auquel cas l'accès est également refusé.
La première étape permet de donner certaines permissions dites implicites. Par exemple, nous avons vu que le propriétaire d'un objet possède toujours les permissions de lire et de modifier la DACL de cet objet. Un autre cas est celui d'un jeton possédant le privilège de modifier le propriétaire de tout objet, ce qui donne implicitement la permission correspondante sur tout objet accédé.

Dans la seconde étape, chaque ACE est examinée et prise en compte si, d'une part, elle concerne l'un des SID du jeton et, d'autre part, elle concerne l'une des permissions demandées dans le masque de permissions. Toute ACE d'interdiction interrompt le parcours et provoque un refus d'accès. L'ordre des ACE dans une DACL est donc important, les ACE d'interdiction devant apparaître devant les ACE d'autorisation. Le système se charge de faire respecter cet ordre pour les ACE éditées via l'interface graphique de l'éditeur de contrôle d'accès, tel que celui utilisé par l'explorateur de fichiers.

5.6. Origine des descripteurs de sécurité

Nous avons vu que l'accès aux objets est protégé grâce à la structure de descripteur de sécurité. Il est donc légitime de se demander comment ces descripteurs de sécurité sont créés en premier lieu.

Lorsque nous avons examiné la structure de jeton, nous avons vu qu'en plus des attributs d'autorisation, des informations permettant de paramétrer la sécurité des objets créés par le processus. Dans les fonctions de l'API Win32 permettant de créer des objets, il est toujours possible de passer une structure de type LPSECURITY_ATTRIBUTES, à partir de laquelle sera construit le descripteur de sécurité du nouvel objet. Cependant, cette approche est lourde, obligeant à spécifier pour chaque objet des paramètres de sécurité. Il est souvent d'usage de mettre ce paramètre à NULL : dans ce cas, le descripteur de sécurité est construit à partir des paramètres de sécurité trouvés dans le jeton. Ceci permet donc de réduire le code ayant à manipuler la sécurité des objets, tout en assurant la cohérence des permissions sur les objets créés.

Les informations pour la sécurité des nouveaux objets sont le propriétaire par défaut ainsi qu'une DACL par défaut. La DACL devant être valable pour tous les types d'objets, les permissions autorisées sont uniquement des permissions génériques ou standards. C'est là tout l'intérêt de disposer de permissions génériques polymorphes : il est ainsi possible d'accorder la permission générique de lecture à un certain principal pour tous les nouveaux objets créés, cette permission générique étant traduite en terme de permissions standards et spécifiques, suivant le type d'objet.

Dans le cas d'objets stockés dans une structure hiérarchique, tels que des fichiers contenus dans des répertoires ou des objets contenus dans des conteneurs d'Active Directory, il existe également une fonctionnalité d'héritage des DACL. Ceci évite par exemple d'avoir à spécifier explicitement les DACL de fichiers contenus dans un même répertoire. Il suffit alors de configurer la DACL sur le répertoire et d'indiquer que les fichiers (voire les répertoires) situés sous ce répertoire en héritent.

Dans Windows NT 4.0, l'héritage des ACL était gérée de façon manuelle : il n'y avait pas de mécanisme automatique pour propager les ACE héritées en cas de changement sur un objet parent. De plus, il n'y avait pas de distinction entre une ACE héritée et une ACE propre à l'objet. Ce modèle d'héritage n'était donc pas très flexible en pratique.

Dans Windows 2000, le modèle d'héritage a été étendu, notamment à cause de l'importance de l'héritage pour les objets contenus dans l'annuaire Active Directory. Dans ce nouveau modèle, l'héritage est dynamique, de sorte que lorsque les permissions sont modifiées sur un objet parent, il y a propagation automatique aux objets contenus. De plus, les ACE héritées sont marquées comme telles, afin de les distinguer des ACE propres à un objet. Il devient ainsi possible d'utiliser l'héritage pour gérer de façon globale des permissions, tout en gardant la possibilité d'écraser, de façon locale, certaines permissions. Du coup, les ACE héritées doivent apparaître après les ACE propres à un objet, afin qu'il soit possible de redéfinir des permissions par rapport à celles héritées.

5.7. Privilèges

Les privilèges permettent une autre forme d'autorisation que le contrôle d'accès. En effet, le contrôle d'accès n'est pas adapté à toutes les situations.

L'exemple typique dans lequel un privilège est plus adapté que le contrôle d'accès sont les privilèges de sauvegarde et de restauration de fichiers. Lorsqu'ils sont donnés à un principal, ils permettent de lire et écrire tous fichiers du système, en contournant les mécanismes de contrôle d'accès. L'intérêt d'utiliser un privilège pour autoriser ce genre de tâche est double. En premier lieu, il évite d'avoir à autoriser les opérateurs de sauvegarde à lire ou écrire tous les fichiers du système. Cette technique obligerait à modifier la liste de contrôle d'accès de chaque fichier. En second lieu, il ne rend possible la lecture et l'écriture de fichiers que dans le cadre d'opérations de sauvegarde. En effet, pour pouvoir sauvegarder ou restaurer un fichier, il faut activer ce privilège et ouvrir le fichier à sauvegarder ou restaurer avec un drapeau spécial.

Les privilèges sont également utilisés lorsque le contrôle d'accès n'est pas possible, aucun objet n'ayant été défini pour autoriser ce que le privilège permet. Par exemple, il existe des privilèges permettant d'arrêter le système ou d'en changer l'heure, l'hypothétique objet de type system, sur lequel il serait possible de définir les permissions d'arrêt et de changement d'heure, n'existant pas.

Les privilèges sont des attributs d'autorisation locaux et n'ont donc de sens que sur le système local. Ils sont affectés à des principaux par l'administrateur du système, pour lequel ils sont connus sous le nom de droits utilisateurs. Les privilèges se retrouvent dans les jetons des processus mais ne sont, pour la plupart, pas activés. Ils doivent donc être explicitement activés avant de pouvoir être utilisés. Un programme correctement écrit n'active les privilèges nécessaires que le temps d'exécuter une action privilégiée.


6. Audit

L'audit permet à un administrateur de prendre connaissance des événements significatifs observés sur le système, qu'ils soient liés à la sécurité ou non.

L'administrateur définit au prélable une politique d'audit, c'est à dire le type d'événements à surveiller. Lorsque ces événements se produisent, ils sont consignés dans un journal dédié, le journal sécurité (security log).

6.1. Administration et exploitation de l'audit

Sur un système Windows par défaut, aucune politique d'audit n'est définie. Il est préférable de mettre en place une politique d'audit minimale, afin d'avoir un mimimum de visibilité sur le fonctionnement du système.

Neuf catégories d'événements sont auditables dans Windows 2000 et Windows XP. Ces catégories regroupent des événements liés à la vie du système (Audit policy change, Audit process tracking, Audit system events), aux connexions au système (Audit logon events, Audit account logon events), à la gestion des comptes utilisateurs (Audit account management) ou encore à l'utilisation des privilèges (Audit privilege use). Les deux catégories restantes (Audit object access et Audit directory service access) définissent si les accès aux objets (objets classiques ou contenus dans l'annuaire Active Directory) doivent être consignés.

Pour chaque catégorie d'événements peuvent être définis les types d'accès à auditer : accès accordés (Success), refusés (Failure), ou les deux (Success, Failure). Par exemple, pour la catégorie concernant les connexions au système local (Audit logon events), si seuls les accès refusés sont audités, seules les connexions refusées seront journalisées.

L'audit utilise le mécanisme de journalisation standard du système. Chaque entrée du journal sécurité est identifiée par un numéro d'événement et contient diverses informations suivant le type d'événement. En conservant l'exemple précédent, il sera possible de déterminer, en se basant sur le numéro d'événement, pour quelle raison une connexion a été refusée (compte désactivé, mot de passe expiré, etc).

L'exploitation des événements d'audit n'est cependant pas une tâche simple. Suivant l'étendue de la politique d'audit, le nombre d'événements peut rapidement devenir important. De plus, de nombreux types d'événements existent (voir les articles Q299475 et Q301677 de la base de connaissance Microsoft pour une liste concernant Windows 2000), les informations associées n'étant pas toujours évidentes à déchiffer. Il est donc courant d'avoir recours à des outils de traitement des événements d'audit, capables par exemple de classifier les événements par niveau de criticité. Un certain nombre de logiciels commerciaux offrent ce type de fonctionnalités, l'offre dans le domaine du logiciel libre étant, à notre connaissance, restreinte, voire nulle.

6.2. Audit des accès

Nous présentons plus en détails l'audit des accès, qui correspond aux deux catégories Audit object access et Audit directory service access. Si l'audit d'une ou de ces deux catégories est activée, tout accès à un objet explicitement audité sera consigné par le système.

Dans le cas d'objets stockés sur disque tels que des fichiers ou des clés de la base de registre, l'administrateur peut aisément configurer les types d'accès à auditer, au même endroit que la configuration du contrôle d'accès. Par exemple, sous l'explorateur de fichiers, dans les propriétés de sécurité avancées d'un fichier, l'onglet Auditing, permet la définition des types d'accès à auditer. La configuration suit le même principe que la définition des permissions sur un fichier, sauf qu'au lieu d'autoriser ou de refuser un accès, il s'agit d'auditer les accès autorisés, refusés ou les deux. De la même façon, les accès à certaines clés de la base de registre peuvent être définis, via les outils regedt32 (Windows NT et 2000) et regedit (Windows XP et ultérieurs).

Il est important de garder à l'esprit que l'audit sert à l'administrateur d'un système et non aux utilisateurs. A l'inverse du contrôle d'accès discrétionnaire, paramétrable par l'utilisateur propriétaire d'un objet, l'audit des accès n'est paramétrable que par un principal possédant un privilège prévu à cet effet (Manage auditing and security log). Ce privilège, accordé par défaut à l'alias Administrators permet de modifier l'audit sur des objets et d'effacer le journal sécurité.

Au niveau interne, la configuration de l'audit des accès est stockée dans le descripteur de sécurité de chaque objet, dans la liste de contrôle d'accès système (SACL) évoquée plus haut. L'audit se fait en même temps que le contrôle d'accès, c'est-à-dire lorsqu'un objet est accédé, sa DACL et sa SACL sont évaluées. Pour avoir le droit de générer un événement d'audit dans le journal sécurité, il faut disposer d'un privilège dédié (Generate security audits). Ce privilège est activé dans la session de connexion SYSTEM, de sorte que tout processus fonctionnant dans cette session peut créer des événements d'audit.


7. Ce dont nous n'avons pas parlé

Cet article a volontairement évité d'aborder certains détails du modèle de sécurité de Windows, inutiles pour la compréhension générale de celui-ci.

Les techniques sur lesquelles repose la sécurité distribuée n'ont pas été traités. Cependant, il suffit d'introduire un protocole d'authentification réseau (NTLM ou Kerberos) ainsi que la technique d'impersonnalisation de thread pour avoir une bonne idée du fonctionnement de la sécurité distribuée dans Windows.

D'autre sujets, tels que la protection des objets constituant l'interface graphique utilisateur ou le modèle de sécurité par rôles utilisé dans COM+ sont plus spécialisés mais se construisent sur les concepts présentés ici.


8. Conclusion

Le modèle de sécurité de Windows est un modèle complet, supportant trois services de sécurité fondamentaux : authentification, autorisation et audit. Bien que complexe à première vue, il est intéressant de l'étudier, afin d'en avoir une bonne compréhension et de l'utiliser à bon escient. Il devient alors possible d'envisager une sécurisation efficace de ce système et des applications s'y exécutant.


9. Références

  • Programming Windows Security. Keith Brown. Addison-Wesley, 2001.
  • Inside Windows 2000. David A. Salomon, Mark E. Russinovitch. Microsoft Press, 2000.
  • Microsoft Platform SDK Documentation. Microsoft, 2001.
Dernière modification le 27 décembre 2005 à 16:42:39 CET - webmaster@hsc.fr
Informations sur ce serveur - © 1989-2013 Hervé Schauer Consultants