Che cos'è Active Directory nella sicurezza informatica? Guida alla difesa dell'identità (2026)
Cyberlord Security Team Profilo autore
Se stai cercando cos'è Active Directory nella sicurezza informatica, il primo dato da fissare è strategico: AD custodisce le identità, le autorizzazioni e le relazioni di fiducia della maggior parte degli ambienti Windows aziendali. Chi la compromette non conquista un server in più, ma la possibilità di presentarsi come utenti e amministratori legittimi, con biglietti che i sistemi considerano autentici.
Proprio perché tutto ruota intorno all'identità, un incidente qui non lascia la solita scia di allarmi: lascia accessi che sembrano normali. Questo articolo spiega come AD funziona davvero, perché gli attaccanti la scelgono e come trasformare questa consapevolezza in controlli concreti e misurabili.
Che cos'è Active Directory nella sicurezza informatica
Risposta breve: Active Directory nella sicurezza informatica è l'infrastruttura di identità che autentica utenti e computer, gestisce le autorizzazioni e applica criteri di gruppo all'interno di un dominio Windows.
La definizione giusta è operativa, non accademica. AD rilascia i biglietti Kerberos che provano chi sei, pubblica i gruppi che decidono cosa puoi toccare e replica il proprio database (NTDS.dit) su più controller di dominio. Autenticazione, autorizzazione e replica definiscono la superficie difensiva: proteggere il singolo server senza curare la topologia dei DC e le credenziali privilegiate significa tutelare solo il contorno.
Controller di dominio e Kerberos: come funziona l'autenticazione
Ogni accesso passa dal servizio di distribuzione Kerberos che gira sui controller di dominio: l'utente riceve un ticket di concessione (TGT) firmato con la chiave dell'account KRBTGT e con esso ottiene i biglietti per le singole risorse. L'autenticazione avviene una volta e si estende da sola per ore: la comodità coincide col rischio.
Tre conseguenze operative di cui tener conto:
- La chiave KRBTGT protegge tutti i TGT: chi la possiede può fabbricare biglietti apparentemente legittimi con qualsiasi privilegio.
- NTLM sopravvive per compatibilità come canale secondario, ed è la via preferita di tecniche come il pass-the-hash.
- I controller di dominio si replicano a vicenda: una compromissione non resta confinata al server colpito.
La difesa qui coincide con la custodia della chiave KRBTGT, dei gruppi con privilegi di replica e della topologia dei controller di dominio.
Perché AD è il bersaglio preferito degli attaccanti
Le tecniche applicate con più frequenza contro AD hanno un tratto in comune: non distruggono il servizio, lo imitano. Golden ticket, Silver ticket e DCSync ricalcano operazioni Kerberos e di replica perfettamente legittime, spesso senza far scattare gli avvisi predefiniti. Il risultato è un cambio di natura: l'avversario non è più un intruso visto dall'esterno, ma un amministratore dal punto di vista del sistema.
Per il monitoraggio ne discende una regola: le soglie predefinite non bastano, serve confrontare ogni azione con l'identità che la esegue - dove, da quale macchina, in quale orario - e quanto corrisponde al suo comportamento abituale.
Golden ticket e skeleton key: cosa osservare, in ottica difensiva
Il golden ticket emette biglietti firmati con la chiave KRBTGT. La contromisura più solida non è un avviso ma un reset: ruotando due volte la password dell'account KRBTGT si rendono inutili tutti i TGT esistenti, anche quelli emessi durante l'attacco. Procedura da provare prima dell'incidente, non durante. Nel monitoraggio di routine aiutano gli accessi privilegiati (ID 4672) a orari e da host inusuali per quella identità.
Il skeleton key aggiunge in memoria della LSA sui controller di dominio una password d'emergenza: accessi con credenziali errate iniziano a passare come corretti. Da osservare: provider di autenticazione inattesi sulla LSA di un DC e accessi interattivi NTLM riusciti per account che li rifiutavano da sempre. Un processo non riconosciuto su un DC non è un semplice avviso: è un incidente da dichiarare.
DCSync: il diritto di replica come bersaglio
Per un DCSync serve il diritto di replica completa della directory; gli eventi 4662 provenienti da identità che non sono controller di dominio restituiscono spesso la prova più diretta dell'abuso.
Il modello amministrativo a livelli: Tier 0, 1 e 2
Molti domini hanno un solo difetto strutturale: le credenziali più potenti si usano da qualunque postazione, così ogni workstation compromessa diventa un campo di raccolta privilegi. Il modello a livelli riduce questo rischio separando le superfici:
- Tier 0: identità con controllo completo sulla directory - controller di dominio, gruppi amministrativi massimi, infrastruttura di certificazione.
- Tier 1: server e applicazioni che elaborano dati aziendali.
- Tier 2: workstation e utenti ordinari.
La regola è non negoziabile: un'identità di un livello non si autentica mai verso il livello superiore. L'amministratore di dominio non esegue l'accesso da un desktop di Tier 2 e non si ripete la stessa password sui sistemi superiori. Si attua con gruppi dedicati, criteri di rete per livello e, quando possibile, workstation di amministrazione dedicate.
Attuazione a fasi senza bloccare il lavoro
La separazione si costruisce per fasi, non in un fine settimana: prima un audit di dove le identità privilegiate si autenticano davvero - spesso il quadro sorprende più del piano -, poi gruppi dedicati per livello affiancati ai gruppi esistenti, infine l'applicazione dei vincoli partendo dalle postazioni di Tier 2, dove l'impatto si legge subito nei ticket e nei rifiuti di accesso. Due accorgimenti evitano l'impasse: account di emergenza custoditi fuori dalla directory per riprendere il controllo dopo un errore di configurazione, e una finestra di test concordata con chi lavora su Tier 1, perché una regola scritta a tavolino che ostacola la produzione viene aggirata entro una settimana.
AD e Entra ID: un'identità che vive in due mondi
Negli scenari ibridi le identità si sincronizzano verso Entra ID e il perimetro si allarga: un dominio locale difeso a regola d'arte conta poco se un account con privilegi globali nel cloud usa una password debole senza seconda verifica. Controlli essenziali:
- revisione periodica di chi detiene ruoli amministrativi in Entra ID, secondo il privilegio minimo;
- autenticazione a più fattori e accesso condizionale su ogni account con privilegi cloud;
- consapevolezza della direzione della sincronizzazione: una credenziale locale debole può diventare una chiave cloud, e viceversa.
Disaster recovery di AD: un'operazione da esercitare, non da documentare
AD è un servizio distribuito: la ripresa dopo un errore di configurazione o un attacco si pianifica a livello di directory, non di singolo file. I punti sostanziali:
- backup dello stato di sistema dei controller di dominio, con ripristino provato: un backup mai ripristinato in test non è un backup;
- una decisione scritta su quando scegliere un ripristino autoritativo per un danno localizzato e quando invece si ricostruisce la foresta;
- la procedura per assumere i ruoli FSMO, con indicazione di chi esegue e come si verifica l'integrità della directory;
- il lato credenziali: dopo una compromissione, doppia rotazione di KRBTGT e disattivazione degli account coinvolti prima che la replica riprenda a diffondere residui di accesso.
Chi esercita il ripristino a cadenza fissa scopre errori di dettaglio che il piano scritto non mostra.
Errori comuni che ritornano nei domini reali
Anche domini sani presentano spesso gli stessi punti deboli: password di dominio riusate su workstation ordinarie; SPN fragili, esposti al Kerberoasting; criteri di comodo che aprono RDP o SMB a segmenti interi; aderenti permanenti ai gruppi Domain Admin ed Enterprise Admin; deleghe Kerberos non vincolate rimaste attive per ragioni ormai dimenticate. Per ogni voce vale una prova inversa: se questa credenziale finisse nelle mani sbagliate, fino a dove arriverebbe l'attaccante? Se la risposta è "ovunque", quel punto passa davanti a tutto.
Lista di controllo per l'hardening di AD
- Inventario dei controller di dominio e versioni: nessuna release fuori supporto in produzione.
- Appartenenze a Domain Admin e gruppi equivalenti ridotte al minimo e riviste mensilmente.
- Procedura scritta e provata per la doppia rotazione della password KRBTGT.
- Eventi di autenticazione e replica inoltrati verso un punto di log non raggiungibile da chi compromette un DC.
- Regole di monitoraggio di partenza: replica da identità non-DC (4662) e accessi privilegiati anomali (4672).
- Separazione per livelli reale, con amministrazione eseguita da sistemi dedicati.
- Backup dello stato di sistema dei DC, con ripristino esercitato su un ambiente di prova.
Riferimenti affidabili per approfondire
- Quadro di sicurezza informatica del NIST: https://www.nist.gov/cyberframework
- Risorse CISA sulla sicurezza informatica: https://www.cisa.gov/cybersecurity
- ATT&CK MITRE: https://attack.mitre.org/
- Documentazione sulla sicurezza Microsoft: https://learn.microsoft.com/security/
Domande frequenti
Qual è il rischio maggiore in termini di implementazione?
Avere credenziali privilegiate senza struttura: gruppi troppo popolati, accessi amministrativi da qualunque postazione e rotazioni mai pianificate per le chiavi di maggior valore, prima fra tutte quella di KRBTGT.
Quanto velocemente i team possono vedere i progressi?
Nei 30-90 giorni successivi è realistico chiudere tre filoni: appartenenze ai gruppi privilegiati, monitoraggio degli accessi privilegiati e una prima prova del piano di ripristino.
È solo per le organizzazioni aziendali?
No. Un dominio di dimensioni medie applica la versione snella: pochi gruppi privilegiati, log inoltrati a un punto centralizzato, backup dello stato di sistema verificati e una regola netta sui livelli.
Cosa dovrebbe essere misurato per primo?
Il numero e il comportamento delle identità che possono replicare la directory, la copertura degli eventi di autenticazione e il tempo effettivo per ruotare KRBTGT in un esercizio.
Come fanno i team a mantenerlo efficace?
Revisione periodica delle appartenenze, prove di ripristino a cadenza fissa e aggiornamento del playbook con gli scenari d'abuso più attuali: golden ticket, DCSync, skeleton key.
Conclusione
Ora hai una risposta pratica a cos'è Active Directory nella sicurezza informatica con ciò che cambia nella difesa reale: la custodia di Kerberos e KRBTGT, il modello a livelli, l'ibrido con Entra ID e un ripristino esercitato, non solo archiviato.
Serve una verifica indipendente sul tuo dominio? Contatta Cyberlord per una revisione concreta della difesa dell'identità.