|
|
 | | |  | Modèle de sécurité du système Windows |  |
|
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.
|
![[Formation]](/gif/icone.formations.png){kind=small}
![[Outil]](/gif/icone.outils.png){kind=small}
]
![[Présentation]](/gif/icone.supports.png){kind=small}
]
![[Brève]](/gif/icone.breves.png){kind=small}
![[Article]](/gif/icone.articles.png){kind=small}