Auditare Active Directory in ambiente air-gapped

Come auditare Active Directory in un ambiente air-gapped senza falsa sicurezza

Se devi capire come auditare Active Directory in un ambiente air-gapped, inizia da una domanda di perimetro, non da una domanda di tooling. Molti team dicono « air-gapped » quando in realta intendono « senza accesso diretto a Internet », « logicamente isolato » oppure « fortemente segmentato ». Questa distinzione conta, perche il metodo di audit, la catena di evidenze e i controlli accettabili cambiano in base al modello reale di connettivita.

La guida di implementazione della CISA per la BOD 23-01 traccia un confine utile: molti ambienti descritti come air-gapped sono in realta solo logicamente isolati, e qualsiasi sistema collegato direttamente all'ambiente operativo, oppure collegato a un altro sistema che a sua volta e collegato a quell'ambiente, non viene trattato come fisicamente air-gapped in quella guida. Per un audit di Active Directory, questa e una regola operativa utile: non assumere isolamento solo perche una rete non ha navigazione web diretta.

Questo articolo usa termini pratici di audit invece di pretendere una tassonomia universale di vendor:

Modello di isolamento	Significato pratico per un audit AD	Conseguenza per l'audit
Senza Internet	L'ambiente non ha accesso diretto in uscita a Internet, ma esiste ancora routing interno locale.	Un audit locale e relativamente semplice, ma i workflow gestiti dal cloud potrebbero non essere utilizzabili.
Isolato logicamente	L'accesso e limitato tramite gateway, jump host, broker o percorsi di trasferimento controllati.	Lo scoping e il trasferimento delle evidenze contano quanto l'audit stesso.
Segmentato	L'ambiente e instradabile, ma vincolato da firewall, VLAN o ACL.	Va trattato come connesso per i rischi legati a privilegi e protocolli.
Fisicamente air-gapped	Non esiste alcun percorso di rete verso Internet o verso l'ambiente operativo piu ampio.	Raccolta, revisione ed esportazione richiedono un workflow completamente locale.

Il punto non e semantico. Il punto e evitare falsa sicurezza. Una foresta Active Directory isolata puo comunque avere deriva dei privilegi, delega insicura, impostazioni di protocollo deboli, account privilegiati obsoleti, percorsi GPO scrivibili, certificate template esposti o una audit policy debole. Se il directory cambia, deve comunque essere misurato.

Perche l'isolamento non elimina il rischio AD

L'isolamento riduce alcuni percorsi di attacco esterni, ma non elimina il rischio identita all'interno del perimetro che devi comunque difendere. Active Directory continua a contenere gruppi privilegiati, impostazioni Kerberos, trust relationship, delega, ACL, Group Policy e spesso servizi di certificazione. Questi control plane restano critici per la sicurezza anche se l'ambiente non tocca mai un servizio SaaS pubblico.

Per questo anche un ambiente isolato ha bisogno della stessa disciplina di revisione descritta in Audit della sicurezza di Active Directory: checklist pratica. I gruppi privilegiati continuano ad accumulare eccezioni, i vecchi account di servizio sopravvivono alle migrazioni e i permessi del directory continuano a derivare tra una bonifica e l'altra. Se esegui gia revisioni periodiche, la stessa lezione illustrata in Audit ricorrente di Active Directory: perche gli audit annuali diventano obsoleti e come monitorare la postura in continuo vale ancora di piu nelle reti isolate: una bonifica una tantum non resta corretta da sola.

La guida ANSSI del 2023 sull'amministrazione sicura dei sistemi che si basano su Active Directory e utile qui perche non tratta AD come un directory statico. Lo tratta come un piano di amministrazione che deve essere compartimentato, monitorato e governato con disciplina. In pratica, questo significa che un AD air-gapped o isolato deve comunque essere valutato come un control plane vivo, non come un'isola legacy che sarebbe piu sicura solo perche e piu difficile da raggiungere da Internet.

Cosa puoi auditare senza accesso a Internet

Una revisione offline ben delimitata puo coprire la maggior parte della control surface che conta davvero in un ambiente AD:

Struttura di identita e privilegi: gruppi privilegiati, gruppi nidificati, diritti delegati, principal con capacita di DCSync, amministratori obsoleti, account di servizio e anomalie di ownership.
Impostazioni di sicurezza del directory: LDAP signing, channel binding, esposizione NTLM, SMB signing, SMBv1, cached logons, policy Kerberos, deployment di LAPS e configurazione dei trust.
Integrita di Group Policy e SYSVOL: collegamenti GPO, security filtering, ereditarieta dei permessi, esposizione di password in SYSVOL e hardened UNC paths.
Visibilita dei cambiamenti: se audit policy, architettura di raccolta eventi e modello di retention sono davvero sufficienti per rilevare localmente modifiche AD critiche.
AD CS, se presente: esposizione del ruolo CA, rischio dei certificate templates, superfici di enrollment e problemi di strong certificate binding.

Per questo l'audit offline di Active Directory non e solo possibile; spesso e piu concreto di quanto i team si aspettino. Microsoft documenta che i dati di AD sono accessibili tramite i protocolli di directory e che Group Policy e divisa tra metadati nel directory e contenuti file-based in SYSVOL. Questo significa che un audit offline serio non si limita a screenshot o a interviste spot con amministratori. Puo raccogliere evidenze direttamente dal directory e dalle relative condivisioni file.

Fonti di dati da raccogliere localmente

L'audit offline piu affidabile usa piu fonti locali di dati, perche nessuna fonte singola risponde a tutte le domande.

Fonte dati	Cosa ti dice	Perche conta offline
LDAP o LDAPS	Utenti, gruppi, computer, attributi rilevanti per ACL, impostazioni di delega, trust, password policy e Kerberos, metadati dei certificate templates	Inventario principale e analisi delle misconfiguration arrivano dal directory stesso.
SYSVOL via SMB	File GPO, script, impostazioni di policy, artefatti di preferences, indizi sulla coerenza di replica	La sicurezza delle GPO non puo essere valutata correttamente solo via LDAP.
Security event log	Modifiche del directory, cambiamenti della audit policy, accesso a oggetti, logon privilegiati, variazioni di membership ai gruppi	Servono evidenze locali per la deriva e per la validazione post-remediation.
Topologia WEF/WEC, se usata	Se gli eventi vengono davvero centralizzati all'interno del perimetro isolato	Il design della raccolta locale conta quando non esiste un percorso verso un SIEM cloud.
Log CA e certificati, se AD CS esiste	Enrollment, attivita dei template, eventi di emissione ed esposizione dei ruoli	L'abuso di certificati resta rilevante negli ambienti Windows isolati.
Metadati dello snapshot	Data dell'audit, scope dei DC, domini esclusi, host irraggiungibili, privilegi usati	Senza questo, i rerun sono difficili da confrontare e i findings difficili da sostenere.

Ci sono due dettagli che e facile trascurare.

Primo: la documentazione Microsoft su Group Policy e importante perche ogni GPO ha sia dati nel directory sia una componente file system in SYSVOL. Se interroghi solo LDAP, perdi una parte della superficie di policy. Questo e uno dei motivi per cui gli audit offline sottostimano spesso il rischio legato a script, file di preferences o integrita dei percorsi di policy.

Secondo: usa LDAPS invece di presumere che LDAP in chiaro sia accettabile solo perche l'ambiente e interno. La documentazione attuale del collector EtcSec e esplicita su questo punto in modalita standalone: ldaps:// e il percorso supportato e raccomandato per la raccolta AD, mentre LDAP non cifrato non e la baseline supportata in produzione.

Costruire un workflow di audit offline affidabile

Un workflow offline difendibile dipende soprattutto dalla ripetibilita.

1. Definire esattamente il confine di fiducia

Documenta se l'ambiente e fisicamente air-gapped, logicamente isolato o semplicemente separato da Internet pubblico. Se l'esportazione dei dati e possibile tramite jump host, broker o processo manuale di trasferimento, va scritto. Il report di audit deve spiegare il modello di connettivita, perche le ipotesi della revisione dipendono da questo.

2. Raccogliere da un host locale fidato

Esegui l'engine di audit da un host all'interno dello stesso confine di fiducia del directory che stai esaminando. Evita laptop amministrativi improvvisati. Quando possibile usa un host dedicato alla review e mantieni configurazione del collector e output sotto change control.

3. Raccogliere insieme evidenze di directory e SYSVOL

Non separare la review dell'identita dalla review delle GPO. In un AD isolato, parte della deriva piu pericolosa dal punto di vista operativo vive nel rapporto tra oggetti del directory e contenuti di policy basati su file. E per questo che articoli come NTLM Relay Attacks in Active Directory e SMB Signing Disabled: Why It Still Enables NTLM Relay restano rilevanti anche in ambienti « offline »: l'esposizione sottostante di protocollo e percorso file e locale, non dipende da Internet.

4. Conservare uno snapshot confrontabile

Conserva la data dell'audit, l'insieme dei domain controller raggiunti, se tutti i domini previsti erano inclusi e se AD CS o i trust erano nel perimetro. Un report senza contesto di raccolta e difficile da confrontare in seguito. Se vuoi che le remediation tengano, ti serve una baseline prima/dopo pulita e non un singolo PDF esportato senza metadati di raccolta.

5. Misurare di nuovo dopo la bonifica

Una volta corretti i findings, riesegui esattamente lo stesso scope e confronta le stesse classi di evidenze. Questo e l'unico modo affidabile per dimostrare che la deriva dei privilegi, l'hardening dei protocolli o la pulizia delle policy hanno davvero retto dopo la change window.

Event logging e detection in AD isolato

Offline non significa invisibile. Significa che la visibilita deve essere progettata localmente.

La documentazione Microsoft su Windows Event Forwarding e utile qui perche spiega cosa WEF fa davvero e cosa non fa. WEF puo inoltrare eventi dalle sorgenti a un collector, ma resta passivo rispetto alla generazione degli eventi. Non abilita per te le subcategory corrette della audit policy e non ridimensiona i log per te. Se i domain controller non registrano gli eventi giusti, un Windows Event Collector locale centralizzera solo piu velocemente evidenze incomplete.

Per questo la configurazione di advanced audit policy deve far parte della review stessa. Microsoft raccomanda anche pianificazione e validazione pilota prima di un deployment ampio, perche le domande reali riguardano volume eventi, utilita operativa e capacita dei team di capire gli eventi che stanno raccogliendo.

Per una review di AD isolato, parti da una baseline locale di detection volutamente ristretta:

Obiettivo	Evidenze locali da verificare
Integrita della audit policy	Modifiche della audit policy come Event ID 4719 e prova che le subcategory critiche siano abilitate sui DC
Visibilita delle modifiche di directory	Copertura di Directory Service Changes, incluso Event ID 5136 quando appropriato
Accesso a oggetti sensibili	Object access auditing come Event ID 4662 quando configurato intenzionalmente su oggetti ad alto valore
Tracciamento delle modifiche privilegiate	Cambi di membership ai gruppi, uso di account admin e pattern di logon privilegiato
Centralizzazione nel perimetro isolato	Subscription WEF/WEC, stato del collector locale, retention e procedura di export

Queste non sono detection basate su un singolo evento. Sono classi di evidenze da correlare con il tuo inventario e con la baseline attesa. Se la tua policy dice che nessuno dovrebbe ottenere diritti equivalenti a DCSync e che nessun gruppo privilegiato dovrebbe cambiare fuori da una finestra controllata, i tuoi log devono essere in grado di sostenere questa affermazione localmente.

Se ti serve una mappa piu dettagliata evento per evento, Monitoraggio sicurezza AD: Event ID che contano entra molto piu a fondo sul lato del logging di sicurezza Windows.

Findings da priorizzare in un AD air-gapped

Un ambiente isolato non dovrebbe cambiare molto il tuo ordine di priorita. Dovrebbe cambiare il tuo metodo di raccolta.

Deriva dei privilegi e percorsi amministrativi obsoleti

Inizia con le stesse domande poste in Deriva degli accessi privilegiati in Active Directory: come i diritti admin ritornano dopo gli audit e Account obsoleti e sovraprivilegiati in AD: chi e effettivamente privilegiato oggi, come ha ottenuto quell'accesso e quell'accesso sarebbe ancora approvato se venisse rivisto adesso?

Questo include:

membership diretta e annidata nei gruppi privilegiati
account con capacita di DCSync
diritti delegati che concedono GenericAll, WriteDACL, WriteOwner o percorsi equivalenti di escalation
deriva collegata ad AdminSDHolder
account disabilitati o inattivi che conservano membership in gruppi privilegiati

Hardening dei protocolli e superficie di relay

Successivamente, dai priorita alle impostazioni di protocollo che restano pericolose anche all'interno di reti isolate:

LDAP signing e channel binding
SMB signing
esposizione a SMBv1
impostazioni NTLM e fallback non necessario
weak certificate mapping o emissione insicura di certificati se AD CS e presente

Gli ambienti offline mantengono spesso piu a lungo impostazioni legacy, perche le change window sono piu difficili e i test di interoperabilita sono piu lenti. Questo non rende l'esposizione meno reale.

Igiene delle password degli amministratori locali

Le password condivise degli amministratori locali restano un problema di lateral movement negli ambienti Windows isolati. Windows LAPS non distribuito: perche le password admin locali condivise contano ancora resta rilevante qui, perche il rischio e il riuso locale delle credenziali tra sistemi, non la connettivita Internet.

Kerberos, account di servizio e delega

Account di servizio, vecchi SPN, delega constrained o unconstrained e postura di cifratura debole restano controlli prioritari anche in AD isolato. Se l'ambiente contiene server legacy di linea di business, la probabilita di trovare vecchi pattern di account di servizio e spesso maggiore, non minore.

Remediation e validazione senza dipendenza cloud

In un AD air-gapped, la remediation va gestita come qualsiasi altra modifica ad alto rischio dell'identita Windows: correggere la condizione pericolosa, rieseguire la stessa raccolta di evidenze e dimostrare il risultato all'interno dello stesso confine.

⚠️ Avviso: non trattare i report esportabili come prova in se. Un report e difendibile solo se scope di raccolta, privilegi usati e metodo di rerun sono abbastanza stabili da poter essere confrontati nel tempo.

Una sequenza pratica e questa:

Rimuovere o ridurre prima i percorsi di privilegio a rischio piu alto: account privilegiati obsoleti, ACL insicure, diritti DCSync non necessari, delega insicura e impostazioni deboli di protocollo.
Verificare di nuovo l'integrita di GPO e SYSVOL dopo ogni modifica a protocollo o policy, soprattutto se hai toccato SMB, hardened UNC paths o administrative templates.
Validare che la audit policy locale continui a coprire i cambiamenti che contano per te e che il design WEF/WEC continui a raccoglierli dove applicabile.
Rieseguire esattamente lo stesso scope di audit e confrontare i findings prima/dopo invece di fidarsi di controlli manuali puntuali.
Documentare cio che resta accettato intenzionalmente per vincoli operativi, soprattutto in ambienti legacy isolati dove il lavoro di compatibilita richiede piu tempo.

Quest'ultimo punto conta. Negli ambienti isolati, le eccezioni vengono spesso giustificate come temporanee. Se non le documenti con owner e data di review, diventano architettura permanente.

Come EtcSec supporta gli audit AD air-gapped

Per questo caso d'uso, il confine di prodotto importante e semplice: la modalita standalone del collector EtcSec non richiede dipendenza SaaS. La documentazione locale descrive una modalita server standalone in cui il collector gira all'interno del tuo ambiente e comunica localmente con Active Directory, inclusi LDAP o LDAPS per i dati del directory e accesso SMB a SYSVOL per la review di Group Policy.

Questo conta negli ambienti isolati perche l'audit puo restare all'interno dello stesso confine di fiducia del directory in esame. Per una valutazione solo AD, puoi mantenere lo scope locale senza assumere accesso in uscita a servizi cloud.

Quando l'ambiente e pronto per una misurazione della postura, i check EtcSec piu utili in questo contesto sono quelli che dimostrano la salute dei controlli locali, non una generica esposizione a Internet. Esempi sono LDAP_SIGNING_DISABLED, SMB_SIGNING_DISABLED, LAPS_NOT_DEPLOYED, DCSYNC_CAPABLE, ACL_GENERICALL, KERBEROASTING_RISK e ADMIN_SD_HOLDER_MODIFIED.

Il punto chiave non e che un AD air-gapped richieda uno standard di review diverso. Il punto chiave e che il workflow di raccolta e validazione deve poter operare localmente, essere rieseguito localmente ed essere confrontato localmente.

Controlli correlati

percorsi di amministrazione dedicati e igiene delle workstation privilegiate
enforcement di LDAP signing, channel binding e SMB signing
deployment di Windows LAPS e rotazione delle password degli amministratori locali
review degli accessi privilegiati e rimozione dei percorsi admin obsoleti
design WEF/WEC piu advanced audit policy validata sui DC
review dell'integrita di GPO e SYSVOL
review di AD CS dove esistono servizi di certificazione
rimisurazione ricorrente invece di bonifica una tantum

Come auditare Active Directory in un ambiente air-gapped