Prove di audit dei file Windows: SACL, 4656/4663

Che cosa sono le prove di audit dei file Windows?

Le prove di audit dei file Windows collegano il criterio di audit effettivo di un server, le regole di audit di un file e un tentativo di accesso controllato ai conseguenti eventi Security. Una sola impostazione di Criteri di gruppo non può stabilire questo collegamento. Prima di cambiare il criterio in produzione, usate file fittizi per determinare quali identità e diritti sui file producono effettivamente evidenze su un server nell’ambito concordato.

Questa guida distingue tre domande: Audit File System è abilitato su quel server, il file ha una lista di controllo di accesso al sistema (SACL) corrispondente e l’evento registrato descrive l’operazione testata? Conservate insieme le risposte in un verbale di verifica. Un valore di criterio rassicurante senza l’evento corrispondente lascia la prova incompleta.

La procedura seguente non è stata eseguita in un dominio reale. I comandi usano la sintassi documentata da Microsoft; i percorsi e le identità sono esempi da sostituire con valori di test approvati. Le osservazioni attese sono criteri di accettazione, non risultati di laboratorio riportati.

Come funziona l’audit dei file: criterio, SACL e accesso

La documentazione Microsoft di Audit File System subordina l’audit a una SACL corrispondente: l’account richiedente e l’accesso richiesto devono corrispondere alle sue voci. L’audit degli esiti positivi e quello degli esiti negativi servono a risultati diversi. Abilitare la sottocategoria senza regole di audit adeguate sugli oggetti non dimostra la copertura a livello di file. Microsoft consiglia inoltre di pianificare come analizzare gli eventi raccolti e di rimuovere le regole di audit eccessive.

Le autorizzazioni del file e le sue regole di audit hanno compiti distinti. Esaminate la lista di controllo di accesso discrezionale (DACL) per stabilire l’accesso consentito o negato previsto, quindi esaminate la SACL per stabilire quali tentativi debbano essere registrati. Aggiungere una regola di audit non giustifica la concessione di un diritto sul file altrimenti non autorizzato.

Scegliete l’ambito della prova prima del test. Quali server e diritti sui file devono essere dimostrati? Identificate l’host, il percorso sintetico, l’identità di test, l’applicazione e l’operazione. Una lettura locale su un server membro supporta quel caso specifico; non dimostra la copertura di ogni server o applicazione. Tenete distinto il monitoraggio degli oggetti di directory: la nostra guida al monitoraggio AD su raccolta degli eventi, mappatura dei campi e validazione spiega il processo più ampio di monitoraggio delle identità, inclusi gli eventi di directory. Qui l’oggetto testato è un file fittizio.

Una richiesta di handle non è un diritto sul file utilizzato

Queste distinzioni provengono dalla documentazione Microsoft di 4656 e 4663. Ciascuno richiede anche la voce SACL pertinente. Per questo protocollo, una lettura di file consentita va valutata rispetto a un 4663 corrispondente; una richiesta di handle negata va valutata rispetto a un Failure 4656 corrispondente.

Verifica: costruire le evidenze prima della correzione

Passaggio 1: registrare il criterio effettivo sul server scelto

Eseguite il comando seguente sul server che ospita i file fittizi, usando un account autorizzato a esaminare il criterio di audit. Microsoft documenta la selezione di categorie e sottocategorie e l’opzione di rapporto CSV in auditpol get:

auditpol /get /subcategory:* /r

Conservate l’output completo con il nome del server, l’ora di raccolta e l’operatore. Individuate File System e registrate le impostazioni degli esiti positivi e negativi. Per un protocollo che copra sia l’accesso consentito sia quello negato, accertate entrambe le impostazioni prima di aspettarvi entrambi i tipi di evidenze. Se una modalità è disabilitata, registrate l’osservazione e la sua conseguenza anziché considerare verificato l’intero server.

Conservate la vista GPO come artefatto separato. Registra la configurazione dichiarata; la query locale registra il criterio di audit del sistema restituito da quell’host. Se un criterio per utente può influire sull’identità di test, esaminate anche quel criterio usando il selettore /user documentato. Registrate qualsiasi errore di autorizzazione come misurazione incompleta anziché come criterio vuoto o disabilitato.

Passaggio 2: esaminare le SACL dei file fittizi effettivi

Preparate due file sintetici tramite la configurazione di test approvata, per esempio C:\AuditProof\allow.txt e C:\AuditProof\deny.txt. Fate in modo che l’identità di test abbia il diritto selezionato sul primo e non lo abbia sul secondo. Esaminate entrambe le DACL prima di procedere; non presumete che il nome di un file renda l’accesso consentito o negato.

Microsoft documenta -Audit come opzione per recuperare i dati SACL in Get-Acl. Questi comandi adattano i parametri documentati ai percorsi di esempio. Eseguite ogni riga separatamente in Windows PowerShell o PowerShell su 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

Conservate le voci di audit e il descrittore di sicurezza restituiti per ciascun file, oppure l’errore esatto se l’ispezione fallisce. Esaminate l’identità, i diritti sottoposti ad audit, i flag di esito positivo e negativo e l’ambito di ereditarietà. Il numero delle voci non basta: la voce pertinente deve coprire questa identità e questa operazione su questo oggetto. Una regola ereditata va valutata sul file effettivamente usato, non dedotta soltanto da una cartella padre.

La decisione qui è concreta: quale SACL copre l’identità, gli esiti e i diritti richiesti senza rumore eccessivo o contenuti sensibili? Indicate i diritti selezionati e perché sono sufficienti per la prova. Evitate di ampliare l’ambito soltanto per ottenere più eventi.

Passaggio 3: eseguire separatamente i casi consentito e negato

Usando l’applicazione di test scelta con l’identità di test ordinaria, eseguite l’operazione selezionata su allow.txt. Poi tentate la stessa operazione su deny.txt. Registrate gli orari di inizio e fine, l’applicazione, l’identità, la destinazione e l’esito osservato per ciascun caso. Evitate di usare l’amministratore dell’ispezione come identità del test di accesso; il protocollo deve esercitare le autorizzazioni esaminate.

Per un test di lettura, leggete effettivamente il file fittizio consentito anziché limitarvi a selezionarlo in una finestra di scelta dei file. Per il caso negato, registrate il rifiuto dell’applicazione ed esaminate le evidenze associate alla richiesta di handle. Se il rifiuto avviene prima che il file previsto sia raggiunto, il caso non dimostra ancora l’audit di quel file. Conservate visibile questo esito nel verbale ed esaminate il percorso di accesso.

Non aspettatevi un numero fisso di eventi. Esaminate il registro Security dell’host in Event Viewer durante la finestra registrata e filtrate per 4656 e 4663. Confrontate account, oggetto e campi di accesso con la scheda di test prima di assegnare un evento a un caso.

Passaggio 4: conservare l’evento e spiegare la decisione

Per ogni evento pertinente, conservate l’XML originale dell’evento nella posizione approvata per le evidenze. Microsoft documenta l’identità del soggetto e l’ID di accesso, il tipo e il nome dell’oggetto, le informazioni del processo, l’ID di handle e i campi di accesso. In 4663, la lista di accesso descrive i diritti utilizzati; in 4656 descrive i diritti richiesti. Per una lettura di file, il diritto ReadData documentato è 0x1; distinguetelo dall’elenco di directory o dall’accesso ai soli metadati nell’interpretare l’oggetto e l’operazione.

Usate l’ID di handle per la correlazione quando disponibile, insieme all’host, all’ora, al soggetto, al processo e all’oggetto. Microsoft precisa che il campo handle può essere 0x0; non deve essere l’unica chiave di join. Scrivete se ciascun evento conservato supporta l’operazione consentita o la richiesta negata e che cosa resta non dimostrato.

Se il contratto di monitoraggio comprende la raccolta centrale, individuate lì lo stesso evento e confrontatene i campi essenziali. Un evento locale e un record utilizzabile centralmente sono elementi di evidenza distinti. Questo confronto è un passaggio di validazione proposto, non un’affermazione che un particolare collector conservi quei campi.

Correzione: risolvere la lacuna dimostrata e ripetere il test (Remediation)

Passaggio 5: cambiare il criterio o la SACL che non ha superato la verifica

Se manca l’audit degli esiti positivi o negativi di File System, intervenite sul criterio applicabile al server scelto. La documentazione di auditpol set consente di specificare una sottocategoria per nome o GUID e abilitare ciascun esito. Su un sistema pilota approvato con un nome di sottocategoria inglese, il comando corrispondente è:

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

Trattatelo come una modifica locale sul sistema pilota, conservando le impostazioni precedenti per il ripristino. Per una distribuzione gestita, correggete il criterio applicabile tramite il processo del team per le modifiche alle GPO e verificate nuovamente lo stato risultante dell’host. Una risposta riuscita del comando da sola non colma la lacuna nelle evidenze di accesso ai file.

Sui sistemi localizzati, usate il nome o GUID effettivo ottenuto dal comando auditpol list documentato da Microsoft:

auditpol /list /subcategory:* /r

Se il criterio è abilitato ma la SACL non corrisponde, correggete la voce di audit per l’identità di test, il diritto e l’esito scelti usando il processo approvato di sicurezza degli oggetti. Conservate la DACL e la SACL originale per la verifica. Ripetete l’ispezione prima di ripetere l’accesso; cambiare le autorizzazioni che consentono o negano l’accesso cambierebbe il test stesso.

Passaggio 6: risolvere le divergenze dei criteri senza dichiarare successo

Quando le impostazioni GPO legacy sembrano corrette ma il comportamento dell’host differisce, esaminate il criterio avanzato applicabile e l’opzione di sicurezza per la precedenza delle sottocategorie. Microsoft documenta SCENoApplyLegacyAuditPolicy come meccanismo che impedisce l’applicazione dei criteri a livello di categoria. La nostra guida ai criteri di audit sulle impostazioni effettive e sui conflitti tra legacy e avanzati fornisce il contesto di configurazione più ampio.

La decisione irrisolta riguarda quali evidenze conservare quando l’evento atteso è assente nonostante una configurazione legacy rassicurante. Conservate insieme l’output del criterio locale, la SACL effettiva, l’esito del test, la finestra di ricerca e la posizione di raccolta. Assegnate la discrepanza a un responsabile. Dopo la modifica mirata, ripetete la stessa operazione e la verifica delle evidenze; non sostituite un caso irrisolto con un test più ampio e più facile.

Come EtcSec rileva questo problema

Al commit del collector bcd03c540bfccdeecf70f36bb80fd58bbe0bef1d, HDS_5_4_LOG_ACCESS_TO_HEALTH_DATA legge GPOPolicies e i relativi valori legacy EventAudit.AuditObjectAccess. Il provider SMB popola quel campo da [Event Audit] in GptTmpl.inf. Raccoglie separatamente il file avanzato audit.csv, ma questo Detect() non lo utilizza.

La condizione implementata accetta qualsiasi GPO raccolta non nulla con EventAudit non nullo e AuditObjectAccess >= 3. Quando esiste una GPO di questo tipo, Count è zero. Altrimenti Count è uno se la raccolta dei criteri GPO non è vuota; anche una raccolta vuota restituisce Count zero. Sebbene il commento descriva la richiesta di esattamente 3, la condizione eseguibile è >= 3.

Di conseguenza, una GPO esterna all’ambito del server testato può sopprimere il rilievo. Questo controllo non osserva il criterio effettivo per server, le SACL, i percorsi dei file, i tentativi di accesso, la classificazione dei dati sanitari o gli eventi Security. Né un rilievo né Count zero dimostrano l’esito di questo protocollo di validazione. Usate il segnale per richiedere evidenze su un ambito definito e documentarne i limiti.

Chiudere la verifica con un verdetto limitato all’ambito

Registrate un verdetto per ciascun server, oggetto, identità e diritto: dimostrato, fallito o incompleto. Includete gli artefatti di criterio e SACL, l’esito effettivo dell’applicazione, gli eventi pertinenti, qualsiasi confronto della raccolta centrale, la decisione di correzione e il risultato del nuovo test. Dichiarate esplicitamente le esclusioni, affinché chi verifica possa distinguere un caso riuscito su un file fittizio da una copertura mai testata.

Fonti tecniche e implementazione del collector esaminate il 4 ottobre 2026. Gli esempi restano una procedura da eseguire con dati fittizi approvati, senza acquisire contenuti di dati sanitari.