Auditer l’accès aux fichiers

liaison avec les objets ayant fait l’objet d’un accès dans le SAM. Mais vous ne verrez pas d’événements d’accès pour les fichiers ou autres objets, parce que chaque objet a ses propres paramètres d’audit et que l’auditing est désactivé sur la plupart des objets par défaut. C’est d’ailleurs une bonne chose parce que si vous essayiez d’auditer chaque tentative d’accès sur chaque fichier et autre objet, votre système demanderait grâce et votre journal de Sécurité se remplirait rapidement – quel que soit l’espace que vous lui auriez alloué. N’utilisez donc cette catégorie que pour des fichiers importants sur lesquels les listes de contrôle sont critiques.

Pour valider l’audit pour un objet donné, ouvrez sa boîte de dialogue Properties, sélectionnez l’onglet Security, cliquez sur Advanced, sélectionnez l’onglet Auditing et cliquez sur Add. Par exemple, dans la figure 4, vous voyez les paramètres d’audit pour le First Quarter Cost Center.xls, que j’ai ouvert à partir de Windows Explorer. A noter que vous pouvez spécifier les utilisateurs ou les groupes dont vous voulez auditer l’accès à ce fichier, ainsi que exactement quel type d’accès vous voulez auditer et s’il faut enregistrer les tentatives d’accès réussies et/ou en échec. Une fois que vous avez validé l’audit sur un objet, Windows commence à enregistrer les événements open, close et autres, d’après la stratégie d’audit pour cet objet.

Nouveau dans Windows 2003 : Le Win2K Security log indique très bien quels types d’accès un utilisateur et son application a sur un objet, mais pas quels types d’accès l’utilisateur a vraiment exercé. Ainsi, Bob pourrait ouvrir un document sur lequel il a un accès en lecture et écriture. A ce stade, Win2K journalise l’event ID 560 qui montre qu’un utilisateur avec des types d’accès List Folder / Read Data et Create Files / Write Data a ouvert un fichier. Quand Bob ferme le fichier, Win2K journalise l’event ID 562, qui montre qu’un utilisateur a fermé un fichier. Mais dans Win2K, aucun événement n’indique si Bob a réellement changé le fichier. Windows 2003 introduit l’event ID 567. Si Bob changeait le fichier sur une machine Windows 2003, vous verriez un event ID 567 entre open et close. Event ID 567 indique le nom de l’objet, l’utilisateur, et le type d’accès que celui-ci a exercé. Si vous ne voyez pas un event ID 567, c’est que l’utilisateur n’a pas mis à jour le fichier.