Surveiller les éventuelles modifications de permissions de dossier

: valider l’audit pour les événements d’accès aux objets réussis sur les serveurs qui contiennent des dossiers, et valider l’audit sur les dossiers à surveiller. Pour valider l’audit sur les événements d’accès aux objets réussis, vous pouvez soit utiliser un GPO (Group Policy Object) existant qui est appliqué à vos serveurs de fichiers, soit, si vous ne contrôlez pas déjà l’audit par les stratégies de groupe, vous pouvez le valider dans la Local Computer Policy de chaque serveur. Dans les deux cas, réglez la stratégie Audit Object Access sous Local Computer Policy\Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy (dans Group Policy Editor – GPE) sur Security Settings Success.

Pour valider l’audit d’un dossier, ouvrez la boîte de dialogue de ses propriétés, sélectionnez l’onglet Security, cliquez sur Advanced et sélectionnez l’onglet Auditing de la fenêtre Advanced Security Settings. Attention aux permissions que vous validez pour l’audit, parce que vous risquez fort de remplir le journal avec des événements d’accès. Dans votre cas, vous voulez suivre uniquement les utilisations réussies de la permission qui permet à un utilisateur de changer l’ACL d’un objet – la permission Change permissions.

La figure 1 montre que j’ai validé des événements Change permissions réussis sur le dossier DeptFiles. J’ai aussi indiqué Everyone comme nom de l’entrée d’audit parce que je veux que l’audit concerne tout le monde. Après avoir validé l’audit d’accès objet au niveau système et pour un dossier précis, vous commencerez à voir l’event ID 560 (Object open) dans le journal Security. Surveillez les apparitions de l’event ID 560, comme celui de la figure 2 dans lequel Object Name dans la description est le nom d’un dossier sur lequel vous avez validé l’audit. Ensuite, recherchez dans le champ Accesses, WRITE_DAC, qui est le nom de système pour Change permissions. La figure 2 montre que Fred a changé les permissions sur C:\DeptFiles.

Dans le journal Security, vous verrez aussi un event ID 562 suivant (un handle sur un objet a été fermé) avec le même handle ID que dans event ID 560. Event ID 562 est simplement la fermeture correspondant à l’ouverture dans event ID 560.

Si votre serveur utilise Windows Server 2003, vous verrez aussi event ID 567 (Object Access Attempt) entre les event ID 560 et 562. Event ID 567 fait partie du nouvel audit basé sur les opérations de Windows 2003. L’audit basé sur les opérations permet d’identifier les permissions qu’un utilisateur exerce réellement par rapport à celles qu’il possède mais n’utilise pas. Ainsi, un programme pourrait fort bien ouvrir un fichier pour l’accès en lecture et écriture (déclenchant un event ID 560 qui montre l’accès en lecture et écriture) mais ne jamais écrire aucune donnée dans le fichier. Windows 2003 journalise event ID 567 la première fois qu’une application utilise chaque permission pendant que le fichier est ouvert.

Une opération de changement de permission est atomique (c’est-à-dire que l’objet n’est pas ouvert pour suppression et ensuite supprimé : il est juste supprimé), donc il n’est pas nécessaire de rechercher event ID 567 puisqu’il devrait toujours être là.