La catégorie Object Access permet de superviser l’accès aux fichiers, dossiers, imprimantes, clés de registres et services système. Mais la plupart des gens utilisent cette catégorie pour superviser les fichiers et les dossiers. Si vous validez cette catégorie, le journal de Sécurité commencera immédiatement par montrer quelques événements journalisés en
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.
Téléchargez cette ressource

État des lieux de la réponse à incident de cybersécurité
Les experts de Palo Alto Networks, Unit 42 et Forrester Research livrent dans ce webinaire exclusif leurs éclairages et stratégies en matière de réponses aux incidents. Bénéficiez d'un panorama complet du paysage actuel de la réponse aux incidents et de sa relation avec la continuité de l'activité, des défis auxquels font face les entreprises et des tendances majeures qui modèlent ce domaine. Un état des lieux précieux pour les décideurs et professionnels IT.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Les risques liés à l’essor fulgurant de l’IA générative
- Pourquoi est-il temps de repenser la gestion des vulnérabilités ?
- Reporting RSE : un levier d’innovation !
- De la 5G à la 6G : la France se positionne pour dominer les réseaux du futur
- Datanexions, acteur clé de la transformation numérique data-centric
