Serveurs de fichiers : configurer l’audit d’accès aux fichiers et dossiers sur Windows Server
Sommaire
I. Présentation
Grâce à une stratégie d'audit Windows Server et des règles de surveillance adaptées, vous pouvez garder un œil sur l'activité de votre serveur de fichiers. Autrement dit, vous pouvez répondre à ce genre d'interrogations : quel utilisateur a fait quoi et quand avec les fichiers et les dossiers stockés dans un ensemble de dossiers partagés.
Ce tutoriel explique comment mettre en place une stratégie d'audit pour journaliser différentes actions, telles que :
- La lecture et la modification de dossiers et de fichiers,
- La suppression de données,
- La modification des permissions
Il est envisageable de tracer énormément de choses, mais il faut trouver le bon équilibre en fonction de la finalité. Si vous journalisez trop d'actions différentes, cela va consommer beaucoup de ressources et générer énormément d'événements (attention à la taille du journal "Sécurité"). Vous risquez donc d'être noyé dans les informations et de stocker des événements qui ne sont pas indispensables. Nous verrons par la suite sur quels paramètres on peut jouer pour garder le contrôle.
En complément de cet article, je vous recommande de lire celui-ci sur les stratégies d'audit Active Directory :
II. Configurer la stratégie d'audit globale
À partir de la console de Gestion de stratégies de groupe, une nouvelle GPO nommée "C_Audit_Files_Folders_Access" est créée. Elle va être utilisée pour personnaliser la stratégie d'audit de la machine. L'alternative consiste à modifier la stratégie d'audit en local avec l'outil auditpol.
Éditez la GPO puis parcourez les paramètres comme suit :
- Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégie d'audit
Pour auditer les accès aux fichiers, il n'est pas nécessaire d'utiliser une stratégie d'audit avancée. Vous devez configurer le paramètre nommé "Auditer l'accès aux objets", comme sur l'image ci-dessous. Activez au moins l'audit sur les tentatives réussies pour loguer tous les accès autorisés. Vous pouvez aussi loguer les échecs si vous le souhaitez en cochant la case correspondante.

C'est tout ce qu'il y a à faire dans la stratégie de groupe.
La stratégie de groupe "C_Audit_Files_Folders_Access" est associée à l'unité d'organisation "Serveurs" de mon annuaire AD. J'ai également appliqué un filtrage de sécurité pour l'appliquer uniquement aux serveurs de fichiers (ce groupe contient des objets ordinateurs).

La prochaine étape est habituelle : actualiser les GPO sur le serveur de fichiers pour appliquer les changements.
gpupdate /force
Je vous rappelle que vous pouvez afficher la stratégie d'audit appliquée via la commande auditpol.exe :
auditpol.exe /get /category:*
III. Activer l'audit d'accès sur un partage de fichiers
Créer une stratégie de groupe pour configurer la stratégie d'audit comme nous venons de le faire n'est pas suffisant pour auditer l'accès aux fichiers et dossiers sur Windows. Vous devez définir des règles d'audit sur les éléments, à savoir les fichiers et les dossiers de votre serveur. Cela correspond à ce que l'on appelle les SACL (System Access Control List), à ne pas confondre avec les DACL (utilisées pour déterminer les permissions).
Pour faire simple : la GPO est l'interrupteur principal qui autorise et active l'audit sur le serveur, alors que les SACL sont les "capteurs" que vous placez sur les dossiers et fichiers que vous voulez surveiller. Le résultat : des événements ajoutés dans le journal "Sécurité" de votre serveur.
Il est possible d'activer l'audit sur une arborescence complète, sur un dossier ou sur un fichier, grâce à des règles. Une règle peut cibler tous les utilisateurs ("Tout le monde"), un groupe de sécurité spécifique, voire même un utilisateur.
Note : la procédure est la même pour ajouter une règle d'audit, que le dossier soit partagé ou non. D'une manière générale, la procédure est identique pour les fichiers et les dossiers.
Voyons comment surveiller toute l'activité sur le dossier P:\Partage associé au partage \\srv-fichiers-01.it-connect.local\Partage.
1 - Accédez aux propriétés du dossier "Partage" (adaptez à votre besoin).
2 - Cliquez sur l'onglet "Sécurité".
3 - Cliquez sur le bouton "Avancé".
4 - Cliquez sur l'onglet "Audit".
5 - Vous remarquerez que la liste est vide : c'est normal, c'est l'état par défaut.

Pour ajouter une nouvelle règle :
1 - Cliquez sur le bouton "Ajouter".
2 - Vous devez commencer par sélectionner à qui s'applique cette règle de surveillance. Le fait de spécifier "Tout le monde" va surveiller tous les accès, y compris ceux initiés par le système. Le problème d'utiliser un groupe trop restrictif (comme le groupe des utilisateurs disposant d'un accès), c'est que vous pourriez manquer certaines tentatives, notamment si l'analyse est effectuée dans un contexte post-incident. Par contre, il est judicieux d'indiquer le groupe "Utilisateurs du domaine", car cela englobe tous les utilisateurs de l'annuaire AD.
3 - Sélectionnez si vous auditez uniquement les succès, uniquement les échecs, ou les deux ("Tout").

Vous devez également déterminer quelles actions doivent être surveillées : cliquez sur le lien "Afficher les autorisations avancées", cela offre plus de souplesse. Si votre objectif est de journaliser uniquement les accès en lecture et écriture, cochez ces trois cases :
- Liste du dossier/lecture de données
- Création de fichier/écriture de données
- Création de dossier/ajout de données
Vous pouvez aussi aller plus loin en surveillant les actions de suppression, voire même les modifications d'autorisations (NTFS) sur ce dossier partagé et ses sous-éléments. Dans ce cas, intéressez-vous aux cases encadrées en jaune sur l'image ci-dessous. Mais, attention, souvenez-vous que plus vous journalisez d'actions, plus cela va générer des logs et consommer des ressources sur le serveur.

Attention : ne configurez jamais une SACL sur "Contrôle Total" pour "Tout le monde" sur un dossier racine très fréquenté. Cela générerait énormément d'événements chaque seconde !
Désormais, la règle d'audit SACL est configurée : Windows Server va commencer à journaliser les accès aux fichiers et aux dossiers.
IV. Définir une règle d'audit d'accès avec PowerShell
À l'aide de PowerShell, vous pourriez afficher la stratégie d'audit propre à ce dossier grâce à la commande spécifiée ci-dessous. Cela peut être intéressant si vous envisagez d'automatiser la gestion des règles SACL : repérez les valeurs de la propriété FileSystemRights pour identifier à quelle action cela correspond.
(Get-Acl "P:\Partage" -Audit).Audit

Mieux encore, vous pouvez utiliser PowerShell pour définir une nouvelle règle sur un dossier. Le script ci-dessous configure une règle sur le dossier "P:\Logiciels", en ciblant le groupe "IT-Connect\Utilisateurs du domaine". Pour le reste la configuration est identique à celle effectuée précédemment en interface graphique. Le fait de spécifier ReadData,CreateFiles,AppendData permet d'auditer les accès en lecture et écriture sur les fichiers et les dossiers.
# Racine sur laquelle appliquer la règle
$TargetPath = "P:\Logiciels"
# Personnalisation de l'ACE
$InheritanceFlags = 'ContainerInherit, ObjectInherit'
$PropagationFlags = 'None'
$AuditFlags = 'Success, Failure'
$Rights = 'ReadData,CreateFiles,AppendData'
$User = 'IT-Connect\Utilisateurs du domaine'
# Construire l'objet SACL
$SACLRules = New-Object System.Security.AccessControl.FileSystemAuditRule($User, $Rights, $InheritanceFlags, $PropagationFlags, $AuditFlags)
# Ajouter la règle
$UpdateSACL = Get-Acl -Path $TargetPath
$UpdateSACL.AddAuditRule($SACLRules)
Set-Acl -Path $TargetPath -AclObject $UpdateSACL
V. Les logs d'audit sur les accès fichiers
A. Filtrer le journal "Sécurité" sur les accès fichiers et dossiers
Pour consulter les journaux liés à l'activité sur vos partages, vos dossiers et vos fichiers, vous devez vous rendre ici : Observateur d'événements > Journaux Windows > Sécurité. D'ailleurs, vous pouvez filtrer ce journal pour afficher uniquement les événements relatifs au système de fichiers. Néanmoins, certains événements, comme la modification des permissions, ne sont pas associés à la même source que celle spécifiée ci-dessous.
1 - Effectuez un clic droit sur le journal "Sécurité" pour configurer le filtre.
2 - Choisissez la source d'événements nommée "Microsoft Windows security auditing".
3 - Sélectionnez "File System" comme catégorie de tâches.

B. Tracer la lecture d'un fichier
Vous devriez voir apparaître de nombreux événements. Dans la fenêtre précédente, vous pourriez même rajouter un filtre sur l'ID 4663. Cet identifiant regroupe les événements de plusieurs actions, y compris l'accès à un fichier. Même si l'accès est distant, le log contient le chemin local vers la ressource.
L'exemple ci-dessous répond bien à la question précisée en introduction de l'article : on sait que l'utilisateur guy.mauve a ouvert un fichier DOCX (action de lecture), et il y a même la date et l'heure de l'événement.

Ci-dessous, un autre événement qui est en réalité plus du bruit. En effet, il s'agit d'une action de suppression effectuée par le même utilisateur, mais en réalité il n'a rien fait. Le coupable ici, c'est Word : il crée un fichier temporaire ~$ quand vous éditez un fichier, et ce dernier est supprimé par Word lorsque le fichier est fermé. Donc, cela crée temporairement un autre fichier : c'est journalisé également.
Cela veut donc dire qu'une seule et même action peut générer X événements dans les logs, donc si vous multipliez ça par le nombre d'utilisateurs, cela peut faire beaucoup de logs !

Note : dans le tutoriel sur la configuration d'une stratégie d'audit avancée, j'ai expliqué comment augmenter la taille du journal "Sécurité" de Windows.
C. Tracer les modifications de permissions
Si vous activez l'audit sur le changement des permissions et que vous filtrez sur la tâche "Authorization Policy Change", vous pouvez avoir des logs lorsque des permissions NTFS sont modifiées. Le journal indique les permissions d'origine et les nouvelles permissions. Le seul inconvénient, c'est qu'il affiche les SID des utilisateurs, et ils ne sont pas traduits automatiquement, donc il y a un travail de correspondance à effectuer (un script PowerShell peut accomplir cette tâche).

Ici, quelques recherches m'ont permis de voir que le SID finissant par 7156-1133 correspond à l'utilisateur AD guy.mauve, et c'est bien lui qui a été ajouté en direct sur ce répertoire.
Note : pour explorer facilement les journaux et même recevoir des alertes lorsqu'un comportement anormal est détecté, il existe des outils comme Netwrix Auditor.
VI. Conclusion
En suivant ce tutoriel, vous devriez être en mesure de mettre en place une stratégie d'audit pour correctement auditer les accès sur votre serveur de fichiers. La procédure est la même pour tracer les accès sur un autre serveur, par exemple, s'il y a un dossier applicatif que vous souhaitez surveiller en particulier.
Enfin, je vous recommande vivement de centraliser les journaux dans un outil adapté et capable de les stocker et de les analyser (ELK, Graylog, etc.).
FAQ
L'activation de l'audit des fichiers va-t-elle ralentir mon serveur ?
Oui, cela peut impacter les performances si c'est configuré de façon à générer trop d'événements et s'il y a beaucoup d'utilisateurs. L'erreur classique est d'auditer "Tout le monde" avec tous les types d'actions sur des dossiers très sollicités. Cela oblige le processeur du serveur à générer un événement pour chaque action sur l'espace de stockage.
Quelles sont les différences entre SACL vs DACL ?
Ci-dessous, un tableau récapitulatif pour vous aider à bien comprendre la distinction entre ces deux types de règles d'accès (ACL) complémentaires.
| Caractéristiques | DACL (Permissions) | SACL (Audit) |
|---|---|---|
| Onglet Windows | Sécurité > Modifier | Sécurité > Avancé > Audit |
| Fonction | Autoriser ou refuser l'accès | Enregistrer l'activité dans les logs |
| Impact utilisateur | Bloque l'utilisateur si l'accès est refusé | Transparent : l'utilisateur ne sait pas qu'il est audité |
Puis-je savoir si un utilisateur a copié un fichier sur une clé USB ?
Non, pas directement. Windows ne fait pas la différence entre "Ouvrir un fichier pour le lire à l'écran" et "Ouvrir un fichier pour le copier" (avec Enregistrer sous, par exemple). Dans les deux cas, c'est un accès ReadData (ID 4663) qui sera visible dans les logs. Ici, on est plus sur un autre aspect : la protection contre les fuites de données (DLP).
Faut-il auditer les "Réussites" ou les "Échecs" ?
Cela dépend de l'objectif de votre stratégie d'audit. Pour tracer une suppression de fichier par un employé, ou l'accès aux données, auditez les Réussites. Pour détecter une tentative d'intrusion sur des dossiers protégés, auditez les Échecs (car les accès refusés seront tracés).
Puis-je auditer qui a changé les permissions d'un dossier ?
Oui, s'est associé à l'ID 4670, à condition que la règle SACL adéquate soit créée. Il vous permet de voir si un administrateur (ou un intrus) s'est donné des droits d'accès sur un dossier confidentiel (comme celui de la RH).
Un administrateur peut-il effacer ses traces après avoir consulté un fichier ?
Si l'administrateur a le droit d'effacer les journaux de sécurité (Clear-EventLog), oui. Mais, attention, cette action peut générer une alerte si vous avez configuré la stratégie d'audit pour surveiller l'action de nettoyage du journal "Sécurité". De plus, si les logs sont envoyés vers un serveur centralisé (puits de logs, SIEM) qui récupère les événements en temps réel, il sera tout de même conservé.

