Auditare la sicurezza di Active Directory: checklist pratica

Un audit di sicurezza di Active Directory deve fare più che elencare configurazioni errate. Deve aiutare il team a rispondere a tre domande pratiche:

1. Quali evidenze espongono Tier 0 o identità privilegiate?
2. Quali percorsi possono essere abusati realisticamente come passo successivo?
3. Quali interventi di remediation vanno affrontati per primi?

Se vuoi la strada più breve, inizia con un workflow dedicato di Active Directory security audit ed esegui il collector localmente tramite ETC Collector. Se invece vuoi prima la checklist completa, usa la guida qui sotto.

1. Parti dalle identità privilegiate e da Tier 0

Molti programmi di audit AD perdono tempo perché partono dall’igiene generale invece che dall’esposizione privilegiata. Il primo passaggio dovrebbe concentrarsi su:

• Domain Admins, Enterprise Admins, Schema Admins e altri gruppi privilegiati integrati
• percorsi di amministrazione delegata
• account con diritti di replica
• account privilegiati con password obsolete o protezioni deboli
• anomalie adminCount e protezioni orfane

In questa fase devi capire quali identità possono modificare i confini di trust del dominio, non solo quali impostazioni sembrano disordinate.

2. Rivedi Kerberos e i percorsi di abuso della delega

Le debolezze Kerberos continuano a generare molti finding AD ad alto impatto. Un audit pratico dovrebbe verificare:

• account kerberoastable
• account vulnerabili ad AS-REP Roasting
• delega unconstrained
• delega constrained con target rischiosi
• abuso di resource-based constrained delegation
• account privilegiati con SPN
• account che dipendono ancora da cifrature deboli

Questi controlli contano perché si collegano direttamente a furto di credenziali, movimento laterale ed escalation di privilegi.

3. Verifica policy password e igiene degli account

La revisione delle password policy resta utile, ma deve essere collegata all’esposizione e all’impatto della remediation. Concentrati su:

• password never expires
• password not required
• reversible encryption
• account privilegiati obsoleti
• account disabilitati dentro gruppi amministrativi
• copertura debole delle fine-grained password policies

Se nel tuo ambiente esistono ancora eccezioni, documenta se sono giustificate, temporanee e assegnate a un owner chiaro.

4. Audita ADCS e i percorsi di abuso dei certificati

ADCS viene spesso escluso dalle revisioni interne anche se può creare percorsi diretti di escalation. Il tuo audit dovrebbe coprire:

• template di certificato vulnerabili
• ACL pericolose sui template
• abuso di enrollment agent
• certificate mapping debole
• flag di CA rischiosi e impostazioni RPC deboli

Se il processo attuale non valuta percorsi di abuso dei certificati in stile ESC, l’audit resta incompleto per una difesa AD moderna.

5. Ispeziona ACL, diritti di replica e attack path

Una semplice revisione delle ACL non basta. Devi capire quali permessi possono concatenarsi in abusi significativi. Un audit solido dovrebbe evidenziare:

• abuso di GenericAll, WriteDacl, WriteOwner e diritti estesi
• diritti di replica e principal capaci di DCSync
• permessi pericolosi su OU, GPO e AdminSDHolder
• attack path che raggiungono asset di livello dominio in uno o due passaggi

Qui si vede la differenza tra un’analisi profonda e un controllo di postura di base.

6. Includi GPO, logging e hardening

Group Policy e hardening del piano di controllo continuano a offrire miglioramenti rapidi. Verifica:

• password policy troppo debole nella Default Domain Policy
• assenza di LDAP signing o channel binding
• mancanza di PowerShell logging
• UNC path hardening insufficiente
• script di logon pericolosi
• esposizione SMB e TLS debole sui domain controller

Questi finding possono sembrare operativi, ma sono esattamente i controlli che cambiano il costo dell’attacco nella pratica.

7. Dai priorità alla remediation in base all’impatto identitario

Non gestire la remediation come una coda piatta. Raggruppa invece l’output per impatto:

• critico: esposizione privilegiata diretta, scorciatoie di attack path, abuso di certificati, capacità DCSync
• alto: abuso della delega, account privilegiati roastable, ACL rischiose, legacy auth o protocolli deboli
• medio: deriva di hygiene e policy che amplia la superficie d’attacco
• basso: pulizia informativa con scarso valore di sfruttamento

Se hai bisogno di un workflow costruito su questo modello, la pagina Active Directory security audit mostra come strutturare la review, e EtcSec pricing spiega quando il layer SaaS di follow-up diventa utile sopra ETC Collector.

8. Ripeti la revisione dopo i cambiamenti

Un audit AD non dovrebbe diventare un artefatto annuale. Ripeti gli stessi controlli dopo:

• cambi di ruolo
• aggiornamenti GPO
• modifiche ai certificate services
• cambiamenti nella delega amministrativa
• fusioni, nuovi siti o nuovi domini

È anche per questo che molti team valutano una PingCastle alternative: il problema reale spesso non è il primo report, ma la mancanza di un ciclo di revisione ripetibile in seguito.

Conclusione

Un audit di sicurezza AD efficace è una revisione ripetibile dell’esposizione privilegiata, non solo un rapporto di salute. Parti da Tier 0, Kerberos, delega, ADCS e percorsi di abuso ACL. Poi dai priorità alla remediation in base a ciò che cambia davvero la portata di un attaccante.

Se vuoi un workflow dedicato, parti dalla pagina Active Directory security audit oppure guarda come ETC Collector esegue la raccolta tecnica localmente.

9. Costruisci un pacchetto di evidenze per ogni ciclo di revisione

Un audit AD utile diventa più rapido e coerente quando il team definisce un pacchetto di evidenze ripetibile. Invece di eseguire controlli ad hoc ogni volta che cambia un amministratore, conviene stabilire in anticipo quali export, screenshot e snapshot della directory verranno raccolti in ogni revisione. Questo rende più semplice confrontare un ciclo con il successivo, giustificare le priorità di remediation e spiegare perché un finding è ancora aperto.

L’obiettivo di questo pacchetto di evidenze non è la burocrazia, ma la coerenza. Quando gli stessi dati vengono esportati in ogni ciclo, la revisione diventa confrontabile. Il team può mostrare se un percorso privilegiato è nuovo, invariato o solo parzialmente sanato, invece di discutere a memoria. Diventa anche più facile separare i problemi che richiedono cambiamenti architetturali da quelli che hanno bisogno soprattutto di ownership e pulizia.

Aiuta anche una convenzione di naming semplice. Salva gli export per data della revisione, dominio e area di controllo, così il prossimo analista potrà confrontare rapidamente i risultati. Se partecipano più team, definisci chi raccoglie, chi valida i finding e chi approva le eccezioni. In questo modo l’audit diventa un processo operativo ripetibile invece di un esercizio tecnico isolato.

FAQ

Con quale frequenza dovrebbe essere eseguito un audit di sicurezza AD?

La maggior parte dei team interni dovrebbe ripetere la revisione principale almeno ogni trimestre e dopo cambiamenti importanti legati all’identità. Questo include fusioni, ristrutturazioni di domini, modifiche ai certificate services, nuovi modelli di amministrazione delegata o grandi revisioni delle GPO. Se l’ambiente cambia rapidamente o operano molti amministratori, controlli mensili su esposizione Tier 0 e gruppi privilegiati sono spesso giustificati.

Cosa dovrebbe essere corretto per primo dopo l’audit?

Inizia dai finding che danno a un attaccante accesso privilegiato diretto o quasi diretto. Appartenenza eccessiva a gruppi privilegiati, account in grado di fare DCSync, delega non vincolata, template di certificato pericolosi e attack path molto corti dovrebbero venire prima dell’igiene generale. Problemi di età delle password, account obsoleti e lacune nel logging restano importanti, ma raramente meritano la massima priorità quando esiste già un percorso chiaro di escalation a livello di dominio.

Chi dovrebbe essere owner della remediation?

In genere il team di sicurezza dovrebbe guidare la prioritizzazione e validare i risultati, ma l’owner della remediation deve essere il team che può davvero modificare la configurazione rischiosa. Può trattarsi del team AD, dell’endpoint management, dei responsabili PKI o dei team applicativi che dipendono dagli account di servizio. L’audit diventa molto più utile quando ogni finding rilevante ha un owner nominato, una data target e una decisione esplicita se il rischio non può essere rimosso subito.

ADCS deve essere sempre nel perimetro?

Se ADCS esiste da qualche parte nella foresta, deve rientrare nel perimetro. I percorsi di escalation basati su certificati possono indebolire un lavoro altrimenti solido su gruppi privilegiati, policy delle password e hardening della delega. I team interni spesso lasciano ADCS a una revisione PKI separata, ma questa separazione crea punti ciechi. Un audit AD è più forte quando tratta template, diritti di enrollment e impostazioni della CA come parte della stessa esposizione privilegiata.

Quali evidenze devono essere conservate tra un ciclo e l’altro?

Conserva abbastanza evidenze da mostrare cosa è cambiato, cosa è rimasto aperto e cosa è stato accettato come eccezione. In pratica questo significa di solito i dataset esportati usati nella revisione, la lista finale dei finding, il tracker di remediation e il registro delle eccezioni con owner e date di revisione. Conservare solo il report finale non basta, perché rende più lenta la revisione successiva e indebolisce la prova dei progressi.

Quando conviene combinare l’audit AD con una revisione di Entra ID?

Se amministratori privilegiati usano anche servizi cloud, se la sincronizzazione ibrida o la gestione delle applicazioni influenza identità critiche, o se i processi di recovery dipendono da ruoli cloud, la revisione AD dovrebbe essere combinata con una revisione Entra. Molti team scoprono che la postura on-prem appare più pulita del piano complessivo di controllo dell’identità. Combinare la vista Active Directory security audit con la vista Microsoft Entra ID security audit aiuta a evitare questi punti ciechi.