Preuves d’audit des fichiers Windows : SACL, 4656/4663

Qu’est-ce qu’une preuve d’audit des fichiers Windows ?

Une preuve d’audit des fichiers Windows relie la stratégie d’audit effective d’un serveur, les règles d’audit d’un fichier et une tentative d’accès contrôlée aux événements Security qui en résultent. Un paramètre de stratégie de groupe ne suffit pas à établir ce lien. Avant de modifier la stratégie de production, utilisez des fichiers factices pour déterminer quelles identités et quels droits sur les fichiers produisent réellement des preuves sur un serveur du périmètre convenu.

Ce guide distingue trois questions : Audit File System est-il activé sur ce serveur, le fichier possède-t-il une liste de contrôle d’accès système (SACL) correspondante et l’événement enregistré décrit-il l’opération testée ? Conservez les réponses ensemble dans un dossier de revue. Une valeur de stratégie rassurante sans événement correspondant laisse la preuve incomplète.

La procédure ci-dessous n’a pas été exécutée dans un domaine réel. Les commandes utilisent la syntaxe documentée par Microsoft ; les chemins et les identités sont des exemples à remplacer par des valeurs de test approuvées. Les observations attendues sont des critères d’acceptation, pas des résultats de laboratoire rapportés.

Fonctionnement de l’audit des fichiers : stratégie, SACL et accès

La documentation Microsoft d’Audit File System conditionne l’audit à une SACL correspondante : le compte demandeur et l’accès demandé doivent correspondre à ses entrées. L’audit des réussites et celui des échecs répondent à des résultats différents. Activer la sous-catégorie sans règles d’audit adaptées sur les objets n’établit pas une couverture au niveau des fichiers. Microsoft recommande également de prévoir comment les événements collectés seront analysés et de supprimer les règles d’audit excessives.

Les autorisations du fichier et ses règles d’audit ont des fonctions distinctes. Examinez la liste de contrôle d’accès discrétionnaire (DACL) pour établir l’accès autorisé ou refusé prévu, puis examinez la SACL pour établir quelles tentatives doivent être enregistrées. Ajouter une règle d’audit ne justifie pas d’accorder un droit sur le fichier qui n’était pas autorisé.

Choisissez le périmètre de preuve avant les tests. Quels serveurs et quels droits sur les fichiers doivent être démontrés ? Identifiez l’hôte, le chemin synthétique, l’identité de test, l’application et l’opération. Une lecture locale sur un serveur membre étaye ce cas précis ; elle n’établit pas une couverture de tous les serveurs ou applications. Distinguez la supervision des objets d’annuaire : notre guide de supervision AD sur la collecte d’événements, le mappage des champs et la validation explique la chaîne plus large de supervision des identités, notamment les événements d’annuaire. Ici, l’objet testé est un fichier factice.

Une demande de handle n’est pas un droit sur le fichier utilisé

Ces distinctions proviennent des références Microsoft de 4656 et de 4663. Chacun exige également l’entrée SACL pertinente. Pour ce protocole, une lecture de fichier autorisée doit être évaluée au regard d’un 4663 correspondant ; une demande de handle refusée doit être évaluée au regard d’un Failure 4656 correspondant.

Vérification : construire les preuves avant la remédiation

Étape 1 : consigner la stratégie effective sur le serveur choisi

Exécutez la commande suivante sur le serveur qui héberge les fichiers factices, avec un compte autorisé à inspecter la stratégie d’audit. Microsoft documente la sélection des catégories et sous-catégories ainsi que l’option de rapport CSV dans auditpol get :

auditpol /get /subcategory:* /r

Conservez la sortie complète avec le nom du serveur, l’heure de collecte et l’opérateur. Repérez File System et consignez ses paramètres de réussite et d’échec. Pour un protocole couvrant les accès autorisés comme refusés, établissez les deux paramètres avant d’attendre les deux types de preuves. Si un mode est désactivé, consignez cette observation et sa conséquence plutôt que de considérer le serveur entier comme vérifié.

Conservez la vue GPO comme un artefact distinct. Elle consigne la configuration déclarée ; la requête locale consigne la stratégie d’audit système retournée par cet hôte. Si une stratégie par utilisateur peut affecter l’identité de test, inspectez-la également à l’aide du sélecteur /user documenté. Consignez toute erreur d’autorisation comme une mesure incomplète plutôt que comme une stratégie vide ou désactivée.

Étape 2 : inspecter les SACL des fichiers factices réellement utilisés

Préparez deux fichiers synthétiques selon la configuration de test approuvée, par exemple C:\AuditProof\allow.txt et C:\AuditProof\deny.txt. Faites en sorte que l’identité de test possède le droit sélectionné sur le premier et ne le possède pas sur le second. Inspectez les deux DACL avant de poursuivre ; ne supposez pas qu’un nom de fichier rend l’accès autorisé ou refusé.

Microsoft documente -Audit comme permettant de récupérer les données SACL dans Get-Acl. Ces commandes adaptent ses paramètres documentés aux chemins d’exemple. Exécutez chaque ligne séparément dans Windows PowerShell ou PowerShell sous Windows :

$allowAcl = Get-Acl -LiteralPath 'C:\AuditProof\allow.txt' -Audit
$allowAcl.Audit
$allowAcl.Sddl

$denyAcl = Get-Acl -LiteralPath 'C:\AuditProof\deny.txt' -Audit
$denyAcl.Audit
$denyAcl.Sddl

Conservez les entrées d’audit et le descripteur de sécurité retournés pour chaque fichier, ou l’erreur exacte si l’inspection échoue. Examinez l’identité, les droits audités, les indicateurs de réussite et d’échec et le périmètre d’héritage. Un nombre d’entrées ne suffit pas : l’entrée pertinente doit couvrir cette identité et cette opération sur cet objet. Une règle héritée doit être évaluée sur le fichier réellement utilisé, pas déduite uniquement d’un dossier parent.

La décision est ici concrète : quelle SACL couvre l’identité, les résultats et les droits requis sans bruit excessif ni contenu sensible ? Précisez les droits sélectionnés et pourquoi ils suffisent à la preuve. Évitez d’élargir le périmètre simplement pour obtenir davantage d’événements.

Étape 3 : exercer séparément les cas autorisé et refusé

Avec l’application de test choisie, exécutée sous l’identité de test ordinaire, effectuez l’opération sélectionnée sur allow.txt. Tentez ensuite la même opération sur deny.txt. Consignez les heures de début et de fin, l’application, l’identité, la cible et le résultat observé pour chaque cas. Évitez d’utiliser l’administrateur chargé de l’inspection comme identité du test d’accès ; le protocole doit exercer les autorisations examinées.

Pour un test de lecture, lisez réellement le fichier factice autorisé plutôt que de simplement le sélectionner dans un sélecteur de fichiers. Pour le cas refusé, consignez le refus de l’application et examinez les preuves de demande de handle associées. Si le refus survient avant d’atteindre le fichier visé, le cas ne démontre pas encore l’audit de ce fichier. Gardez ce résultat visible dans le dossier et examinez le chemin d’accès.

N’attendez pas un nombre fixe d’événements. Inspectez le journal Security de l’hôte dans Event Viewer pendant la fenêtre enregistrée et filtrez sur 4656 et 4663. Comparez le compte, l’objet et les champs d’accès avec la fiche de test avant d’attribuer un événement à un cas.

Étape 4 : préserver l’événement et expliquer la décision

Pour chaque événement pertinent, conservez son XML original à l’emplacement de preuves approuvé. Microsoft documente l’identité du sujet et l’identifiant de connexion, le type et le nom de l’objet, les informations sur le processus, l’identifiant de handle et les champs d’accès. Dans 4663, la liste d’accès décrit les droits utilisés ; dans 4656, elle décrit les droits demandés. Pour une lecture de fichier, le droit ReadData documenté est 0x1 ; distinguez-le de l’énumération d’un répertoire ou d’un accès limité aux métadonnées lors de l’interprétation de l’objet et de l’opération.

Utilisez l’identifiant de handle pour la corrélation lorsqu’il est disponible, avec l’hôte, l’heure, le sujet, le processus et l’objet. Microsoft précise que le champ de handle peut être 0x0 ; il ne doit pas être l’unique clé de jointure. Indiquez si chaque événement conservé étaye l’opération autorisée ou la demande refusée, et ce qui reste non démontré.

Si le contrat de supervision inclut une collecte centrale, retrouvez-y le même événement et comparez ses champs essentiels. Un événement local et un enregistrement exploitable centralement sont deux éléments de preuve distincts. Cette comparaison est une étape de validation proposée, pas une affirmation qu’un collecteur particulier préserve ces champs.

Remédiation : corriger la lacune démontrée et retester (Remediation)

Étape 5 : modifier la stratégie ou la SACL qui a échoué à la vérification

Si l’audit des réussites ou des échecs de File System manque, traitez la stratégie applicable au serveur choisi. La documentation d’auditpol set permet de spécifier une sous-catégorie par son nom ou son GUID et d’activer chaque résultat. Sur un pilote approuvé avec un nom de sous-catégorie anglais, la commande correspondante est :

auditpol /set /subcategory:"File System" /success:enable /failure:enable

Traitez cela comme une modification locale sur le pilote, en conservant les paramètres précédents pour le retour arrière. Pour un déploiement géré, corrigez la stratégie applicable via le processus de modification des GPO de l’équipe et vérifiez à nouveau l’état obtenu sur l’hôte. Une réponse de commande réussie ne suffit pas à combler la lacune de preuves d’accès aux fichiers.

Sur les systèmes localisés, utilisez le nom ou le GUID réel obtenu à partir de la commande auditpol list documentée par Microsoft :

auditpol /list /subcategory:* /r

Si la stratégie est activée, mais que la SACL ne correspond pas, corrigez l’entrée d’audit pour l’identité, le droit et le résultat de test choisis en suivant le processus de sécurité des objets approuvé. Préservez la DACL et la SACL originale pour la revue. Répétez l’inspection avant de répéter l’accès ; modifier les autorisations d’accès autorisé ou refusé changerait le test lui-même.

Étape 6 : résoudre les divergences de stratégie sans déclarer la réussite

Lorsque les paramètres GPO historiques semblent corrects, mais que le comportement de l’hôte diffère, inspectez la stratégie avancée applicable et l’option de sécurité de priorité des sous-catégories. Microsoft documente SCENoApplyLegacyAuditPolicy comme empêchant l’application de stratégies au niveau catégorie. Notre guide des stratégies d’audit sur les paramètres effectifs et les conflits entre stratégies historiques et avancées fournit le contexte de configuration plus large.

La décision non résolue porte sur les preuves à conserver lorsque l’événement attendu est absent malgré une configuration historique rassurante. Gardez ensemble la sortie de stratégie locale, la SACL réelle, le résultat du test, la fenêtre de recherche et l’emplacement de collecte. Attribuez la divergence à un responsable. Après la modification ciblée, répétez la même opération et la revue des preuves ; ne remplacez pas un cas non résolu par un test plus large et plus facile.

Comment EtcSec détecte ce problème

Au commit du collecteur bcd03c540bfccdeecf70f36bb80fd58bbe0bef1d, HDS_5_4_LOG_ACCESS_TO_HEALTH_DATA lit GPOPolicies et leurs valeurs historiques EventAudit.AuditObjectAccess. Le fournisseur SMB renseigne ce champ à partir de [Event Audit] dans GptTmpl.inf. Il collecte séparément le fichier avancé audit.csv, mais ce Detect() ne l’utilise pas.

La condition implémentée accepte toute GPO collectée non nulle avec un EventAudit non nul et AuditObjectAccess >= 3. Lorsqu’une telle GPO existe, Count vaut zéro. Sinon, Count vaut un si la collection de stratégies GPO n’est pas vide ; une collection vide donne également Count zéro. Bien que le commentaire décrive l’exigence d’exactement 3, la condition exécutable est >= 3.

Par conséquent, une GPO hors du périmètre du serveur testé peut supprimer le constat. Ce contrôle n’observe ni la stratégie effective par serveur, ni les SACL, ni les chemins de fichiers, ni les tentatives d’accès, ni la classification des données de santé, ni les événements Security. Ni un constat ni Count zéro n’établit le résultat de ce protocole de validation. Utilisez le signal pour demander des preuves sur un périmètre défini et documenter ses limites.

Clôturer la revue avec un verdict limité au périmètre

Consignez un verdict pour chaque serveur, objet, identité et droit : démontré, en échec ou incomplet. Incluez les artefacts de stratégie et de SACL, le résultat réel dans l’application, les événements pertinents, toute comparaison de collecte centrale, la décision de remédiation et le résultat du nouveau test. Précisez explicitement les exclusions pour permettre au lecteur de distinguer un cas réussi sur un fichier factice d’une couverture qui n’a jamais été testée.

Sources techniques et implémentation du collecteur examinées le 4 octobre 2026. Les exemples restent une procédure à exécuter avec des données factices approuvées, sans capturer le contenu de données de santé.