Accès aux objets

et chaque objet à  surveiller. Spécifiez la liste de contrôle d’audit d’un objet
comme s’il s’agissait de l’ACL d’un objet. Cette liste spécifie les utilisateurs
et les types d’accès dont on veut faire le suivi.

L’audit de l’accès aux objets utilise un journal d’événements au lieu d’un journal
de transactions. NT n’indique donc pas ce que l’utilisateur a fait à  l’objet,
mais plutôt le type d’accès utilisé pour ouvrir l’objet. Par exemple, un événement
peut indiquer que Jean a ouvert salaires.xls pour un accès Lecture, Ecriture,
Exécution ou Suppression, mais ne dit pas si Jean a modifié le fichier et quelles
modifications il a apportées.
Par ailleurs lorsqu’on audite l’accès aux objets il faut savoir qu’une action
exécutée par un utilisateur peut occasionner beaucoup d’événements dans le Journal
de sécurité. Par exemple, sélectionner un fichier texte avec Windows Explorer
et double-cliquer pour l’afficher dans le bloc-notes, provoque plus de 20 événements
lorsqu’on audite tout accès à  ce fichier et à  son répertoire parent.

Là  où l’audit d’un objet se montre le plus utile c’est avec les applications conventionnelles
utilisant directement des fichiers identifiés, comme les applications Microsoft
Office. Les autres applications client-serveur, comme SAP, stockent toutes leurs
tables de données dans quelques grands fichiers de bases de données Microsoft
SQL Server. Si l’audit de ces fichiers est activé, on voit ordinairement les objets
s’ouvrir et se fermer lorsque le serveur de bases de données démarre et s’arrête.
On ne peut pas déterminer l’utilisateur qui exécute des transactions ou fait des
modifications, ni les tables qu’il modifie. Il faut compter sur l’application
pour fournir ces informations.
Cependant, une bonne raison d’auditer ces fichiers de serveurs de bases de données
monolithiques est la possibilité de surprendre quelqu’un en train de les modifier
en dehors de l’application. Avec la plupart des serveurs de bases de données,
y compris SQL Server, on peut arrêter le service, remplacer les fichiers de bases
de données par une version différente et redémarrer le service sans que l’action
soit détectée par le serveur de bases de données. L’audit de l’accès aux objets
permet de surprendre un trafic de cette nature.

Avec la plupart des SGBD, on peut arrêter le service, remplacer les fichiers de
données et redémarrer le service sans que l’action soit détectée

Les deux principaux événements de l’accès aux objets sont objet ouvert, ID d’événement
560, et pointeur fermé, ID 562. Ces deux événements sont complémentaires, tout
comme ceux d’ouverture et de fermeture de session. Les événements de l’ID 560
ayant réussi (figure 2), indiquent l’objet ouvert, le programme employé par l’utilisateur
et le niveau d’accès de ce dernier.
Avant de pouvoir accéder à  un objet, un programme doit l’ouvrir, spécifier le
type d’accès et obtenir un ID de pointeur, c’est-à -dire un numéro utilisé par
l’OS pour faire le suivi des objets ouverts. L’ID de pointeur est semblable à 
l’ID de connexion. Elle peut servir à  lier un événement d’objet ouvert (ID 560)
à  l’événement fermé de son pointeur correspondant (ID 562) pour déterminer la
durée pendant laquelle l’utilisateur a maintenu l’objet ouvert. L’ID du pointeur
apparaît aussi dans la description de l’événement, comme sur la Figure 2, ce qui
permet d’identifier la session de connexion dans laquelle l’utilisateur a accédé
à  l’objet.

La description de l’événement spécifie deux utilisateurs : primaire et client.
Si vous utilisez une application conventionnelle (par exemple Word) pour ouvrir
un fichier sur votre système local, seules sont intéressantes les informations
sur l’utilisateur. Mais si vous accédez à  un objet avec une application client-serveur
pratiquant l’usurpation au niveau de l’OS, les informations sur l’utilisateur
primaire identifient le compte d’utilisateur de l’application serveur et celles
concernant le client reflètent l’utilisateur au nom duquel le serveur agit.
Un exemple commun de ce type de scénario est le traitement par NT du partage de
fichiers. Lorsque vous accédez à  un fichier d’ordinateur par le réseau au moyen
d’un répertoire partagé, le service de votre poste de travail local se connecte
au service du Serveur de l’autre système et lance une ouverture de session de
type 3. Avant de traiter une requête, le serveur usurpe l’utilisateur distant
et provoque des événements d’accès aux objets pour enregistrer des informations
à  la fois sur les utilisateurs primaires et clients. Dans ce cas, le Nom d’utilisateur
primaire est SYSTEME, c’est-à -dire le compte dans lequel le service Serveur s’exécute.
Le Nom d’utilisateur client indique à  quel titre le client s’est connecté au serveur
de fichiers, c’est-à -dire, ordinairement, le nom de domaine de cet utilisateur.

La zone Accès de la description de l’ID d’événement 560 indique quel(s) type(s)
d’accès l’utilisateur a employé(s) pour ouvrir l’objet. Les valeurs des types
d’accès correspondent à  des permissions de niveau inférieur dans les ACL. Par
exemple, lorsqu’on modifie un fichier texte dans WordPad, NT consigne l’ID d’événement
560 avec des accès tels que ReadDate, WriteDate et AppenData.

Une dernière information importante à  propos de la description de l’ID d’événement
560 est l’ID de processus, qui peut servir à  déterminer le programme avec lequel
l’utilisateur a accédé au fichier. L’ID de processus peut être lié à  d’autres
événements, évoqués plus loin, pour déterminer si un utilisateur a utilisé Word,
WordPad ou NotePad pour modifier un fichier. Toutefois il n’est utile que si l’objet
accédé se trouve sur le même système que l’utilisateur accédant à  l’objet.
Autrement, comme dans le cas d’un serveur de fichiers, l’ID de processus correspondra
à  l’application serveur et ne révélera pas beaucoup d’informations.
L’autre événement important de la catégorie d’accès aux objets est objet supprimé,
ID d’événement 564. Cette ID spécifie uniquement l’ID de pointeur et l’ID de processus.
Pour déterminer l’utilisateur et l’objet supprimé par celui-ci, il faut utiliser
l’ID de pointeur pour lier l’événement de suppression de l’objet (événement 464)
à  l’événement correspondant, objet ouvert (événement 560). Ce dernier indique
l’utilisateur qui a ouvert l’objet avec l’accès suppression, et l’événement correspondant,
à  savoir objet supprimé, confirme que l’utilisateur a supprimé l’objet.

L’audit de l’accès aux objets est puissant mais peut s’avérer laborieux et risque
de ralentir les performances du système

L’audit de l’accès aux objets est puissant mais peut s’avérer laborieux et risque
de ralentir les performances du système selon le nombre d’objets audités et le
poids que fait peser l’activité sur ces objets. Je recommande d’utiliser avec
parcimonie l’audit de l’accès aux objets. Outre la protection de ressources extrêmement
importantes, le personnel de sécurité l’utilise souvent pour prouver la présence
d’un utilisateur trafiquant les données. Il arrive aussi que des administrateurs
activent l’audit des objets sur des fichiers leurres, comme, par exemple, un fichier
salaires.xls fictif, pour attraper des suspects.
Mais il faut tenir compte des considérations de propriété avant d’utiliser cette
approche. N’oubliez pas qu’il faut activer l’audit des objets dans le Gestionnaire
des utilisateurs du système dans lequel résident les objets en question pour consigner
les événements d’accès et non pas nécessairement sur le poste de travail local
de l’utilisateur