Messa in sicurezza Active Directory

La messa in sicurezza Active Directory non è un semplice progetto GPO né una checklist da eseguire una sola volta. Un piano utile di messa in sicurezza di Active Directory riduce il numero di percorsi privilegiati, rimuove protocolli deboli e segreti riutilizzabili e dimostra poi che i controlli continuano a funzionare dopo il rollout. Se prima ti serve il workflow di revisione più ampio, inizia da Auditare la sicurezza di Active Directory: cosa verificare per prima e come dimostrare la remediation. Questo articolo è più ristretto: si concentra su cosa bloccare per primo.

Cosa significa davvero la messa in sicurezza Active Directory

In pratica, mettere in sicurezza Active Directory significa ridurre il numero di modi in cui un attaccante può raggiungere il controllo privilegiato e poi proteggere e monitorare i percorsi amministrativi che rimangono. La strategia Microsoft per l’accesso privilegiato tratta esplicitamente l’accesso privilegiato come la priorità di sicurezza più alta e raccomanda di limitare le azioni privilegiate a pochi percorsi autorizzati, poi strettamente protetti e monitorati.

Per questo un buon lavoro di messa in sicurezza deve essere ordinato. Se inizi con un tuning cosmetico della baseline prima di separare le identità privilegiate, irrobustire gli host amministrativi e rimuovere i segreti riutilizzabili, il control plane può restare facile da raggiungere. La Guida ANSSI Active Directory: come applicare in pratica le raccomandazioni di sicurezza arriva alla stessa conclusione operativa da un’altra angolazione: prima compartimentare il modello di amministrazione, poi irrobustire i controlli che lo sostengono.

La messa in sicurezza di Active Directory parte dagli accessi privilegiati e dai percorsi amministrativi

La prima priorità è l’accesso privilegiato, non perché sia un tema di moda, ma perché la compromissione di account e percorsi privilegiati fa spesso crollare il resto del modello di sicurezza della directory. La guidance Microsoft sugli secure administrative hosts è diretta: non si dovrebbe mai amministrare un sistema trusted da un host meno trusted, e gli host amministrativi dedicati non dovrebbero eseguire software da uso comune come email, browser web o suite di produttività.

Questo porta alla prima sequenza di messa in sicurezza:

Separare gli account privilegiati dalle identità di tutti i giorni.
Spostare l’amministrazione privilegiata su workstation dedicate, jump host o secure administrative hosts equivalenti.
Limitare dove le identità ad alto privilegio possono autenticarsi.
Misurare se sessioni privilegiate continuano ancora a partire da normali dispositivi utente.

Qui rientrano anche controlli come il gruppo di sicurezza Protected Users e Authentication Policies / Authentication Policy Silos. Sono controlli di contenimento utili per gli account giusti, ma non sono punti di partenza universali. Microsoft documenta caveat importanti: i membri di Protected Users devono potersi autenticare con AES, gli account di servizio e computer non dovrebbero essere aggiunti e gli account altamente privilegiati non dovrebbero essere aggiunti prima di avere validato l’impatto operativo. Gli authentication policy silos possono inoltre limitare su quali host alcuni account utente, computer e di servizio altamente privilegiati sono autorizzati ad autenticarsi, il che li rende utili dopo avere già definito i tier amministrativi e i relativi percorsi.

Ridurre poi l’esposizione dei protocolli e della directory

Una volta ristretti i percorsi privilegiati, il passo successivo nella messa in sicurezza di Active Directory è ridurre l’esposizione dei protocolli che ancora consente intercettazione, manomissione o abitudini amministrative deboli.

LDAP signing e channel binding

Microsoft documenta LDAP signing e LDAP channel binding come protezioni del traffico LDAP di AD DS. LDAP signing aiuta a verificare autenticità e integrità, mentre channel binding collega il livello applicativo alla sessione TLS sottostante per aiutare a impedire hijacking e scenari man-in-the-middle. In pratica, questo significa che un piano serio di messa in sicurezza deve verificare se SASL bind non firmati o pattern LDAP insicuri sono ancora tollerati dai domain controller.

L’errore classico è imporre la configurazione alla cieca. Prima di irrigidirla, valida quali applicazioni, appliance, script o middleware legacy dipendono ancora da un comportamento LDAP debole. Poi conserva la prova di quella revisione di compatibilità e dello stato finale imposto. Il deep dive associato resta in inglese: LDAP Signing Disabled: How Unsigned Binds Expose Active Directory.

SMB signing

La guidance Microsoft su SMB signing è altrettanto utile come controllo di messa in sicurezza perché protegge l’integrità dei messaggi e aiuta a difendersi da relay e spoofing. Richiedere SMB signing sui percorsi amministrativi e di file management ad alto valore è spesso un controllo da prioritizzare presto.

Anche qui conta l’ordine di enforcement. Microsoft osserva che possono emergere problemi di compatibilità quando i requisiti di firma vengono imposti in ambienti che usano file server non Microsoft. La mossa corretta non è «attivarlo ovunque subito», ma «misurare dove SMB non firmato conta ancora, validare le dipendenze e solo dopo imporre con evidenza». Il deep dive associato è Firma SMB disabilitata: perché continua ad abilitare NTLM relay.

Mettere in sicurezza Active Directory significa ridurre i segreti riutilizzabili

Molte intrusioni AD continuano ad accelerare perché i segreti riutilizzabili restano troppo facili da rubare, riusare o sfruttare lateralmente. Questa è la terza priorità perché spesso limita fino a dove può propagarsi la compromissione di un singolo host.

Windows LAPS

Microsoft documenta Windows LAPS come la funzionalità integrata che gestisce e salva automaticamente le password degli account amministratore locale e che può anche gestire la password DSRM sui domain controller Windows Server Active Directory. Questo la rende un controllo centrale di messa in sicurezza, non una semplice comodità. Se le password di amministratore locale o DSRM restano statiche, condivise o ruotate manualmente, l’ambiente continua a portarsi dietro un rischio laterale evitabile.

L’obiettivo non è solo il deployment. Bisogna validare la rotazione delle password, i permessi di recupero, la destinazione del backup e se le eccezioni stanno ancora lasciando parte del parco fuori controllo. Deep dive associato: Windows LAPS non distribuito: perché le password condivise di amministratore locale contano ancora.

Password degli account di servizio e gMSA

La guidance Microsoft sui group Managed Service Accounts è preziosa perché riduce il carico amministrativo della gestione delle password degli account di servizio e semplifica la gestione degli SPN. Dove il supporto applicativo lo consente, passare da account di servizio tradizionali basati su utenti a gMSA elimina una classe di password di lunga durata gestite manualmente.

Questo non è un ordine di migrazione universale. Prima della conversione occorre validare supporto applicativo, comportamento di cluster o farm, dipendenze SPN e ownership operativo. Per gli account che non possono ancora migrare a gMSA, riduci l’età delle password, rimuovi privilegi non necessari e verifica se l’account è ancora il principal corretto per il servizio.

Irrigidimento mirato delle password policy

La guidance Microsoft sulle fine-grained password policies è utile qui, ma solo nel giusto scope. Le fine-grained password policies si applicano a gruppi di sicurezza globali e oggetti utente, non come sostituto universale della governance generale delle password. Usale quando hai bisogno di un trattamento più rigoroso per popolazioni selezionate di account amministrativi o di servizio, non come sostituto di una migliore igiene generale delle credenziali. Per il livello adiacente di controllo password, il deep dive resta in inglese: Active Directory Password Security: Misconfigurations That Matter.

Limitare la delega e gli altri percorsi di escalation

La quarta priorità è il control plane attorno alla directory stessa: permessi delegati, controllo dei gruppi privilegiati, amministrazione delle GPO e diritti collegati alla replica che non dovrebbero restare ampiamente raggiungibili.

La documentazione Microsoft su Group Policy ricorda che una GPO non è soltanto «un’impostazione». Ha una componente AD e una componente file system, ed è applicata tramite la normale logica di scope della directory. Per questo i permessi GPO e lo scope dei link fanno parte del lavoro di messa in sicurezza, non solo del troubleshooting. Se utenti a basso privilegio possono influenzare una GPO che raggiunge sistemi privilegiati, il programma di messa in sicurezza ha una lacuna strutturale. L’articolo adiacente resta in inglese: GPO Misconfigurations: How Group Policy Becomes an Attack Vector.

La stessa logica vale per i permessi legati alla replica. Microsoft documenta Replicating Directory Changes come una ACE presente su ogni domain naming context e assegnabile esplicitamente ad account. Questo significa che l’accesso con capacità di replica deve essere trattato come privilegiato e rivisto esplicitamente, non considerato innocuo solo perché non si chiama «Domain Admin». Il problema più ampio delle catene di abuso è trattato in Percorsi di attacco AD: come le configurazioni errate si concatenano fino a Domain Admin.

Se AD CS è distribuito, dovrebbe entrare nello stesso programma di messa in sicurezza. Microsoft documenta AD CS come il ruolo Windows Server che emette e gestisce certificati usati per comunicazione sicura e autenticazione. In altre parole, se nell’ambiente esiste autenticazione basata su certificati, mettere in sicurezza la directory ignorando il control plane dei certificati lascia una lacuna materiale. Mantieni lo scope condizionale: se AD CS non è distribuito, non forzarlo nel programma. Se è presente, rileggi Percorsi di attacco ADCS: come errori nei certificati diventano percorsi di escalation in Active Directory.

Costruire logging e validazione nel piano di messa in sicurezza

Una messa in sicurezza che non può essere misurata di nuovo torna rapidamente nel campo delle supposizioni. Le raccomandazioni Microsoft su audit policy e raccolta eventi rendono il punto operativo chiaro: servono prima le giuste impostazioni di audit e poi il giusto percorso di raccolta e retention.

Windows Event Forwarding e Windows Event Collector possono centralizzare gli eventi che scegli di inoltrare, ma non sostituiscono il design dell’audit policy. La telemetria sulle modifiche agli oggetti della directory è utile solo quando esistono le impostazioni di audit necessarie e la corretta copertura SACL. Per esempio, Microsoft documenta che l’Event 5136 viene generato quando un oggetto del servizio directory viene modificato, ma solo se l’oggetto possiede la voce SACL pertinente per l’azione di scrittura sottoposta ad audit.

Questo porta a una regola pratica per i programmi di messa in sicurezza:

conservare esportazioni pre e post cambiamento per membership dei gruppi privilegiati, stato delle GPO, stato delle policy LDAP e SMB e permessi delegati
verificare che domain controller e sistemi amministrativi registrino davvero gli eventi sui quali intendi basarti
trattare WEF/WEC come infrastruttura di trasporto e retention, non come prova che il design di audit sia completo

Per il livello di visibilità sugli eventi, usa Monitoraggio della sicurezza AD: gli Event ID che contano davvero e Audit ricorrente di Active Directory: perché gli audit annuali deragliano e come rimisurare in continuo.

Matrice delle priorità di messa in sicurezza di Active Directory

Area di controllo	Perché arriva presto	Cosa validare prima dell’enforcement	Cosa conservare come prova dopo il rollout
Account privilegiati e host amministrativi	La compromissione di un percorso privilegiato fa spesso crollare per primo il resto del modello di directory	Host amministrativi dedicati, identità admin separate, percorsi di autenticazione autorizzati, impatto di Protected Users e authentication silos	Inventario degli host amministrativi, scope degli account privilegiati, assegnazioni di policy, validazione dei percorsi di accesso
LDAP signing e SMB signing	Protocolli deboli mantengono relay, manomissione e workflow amministrativi insicuri	App legacy, appliance, script, file server non Microsoft, dipendenze TLS e LDAP	Stato effettivo delle policy, registro delle eccezioni, risultati dei test di compatibilità
Segreti di admin locale, DSRM e account di servizio	I segreti riutilizzabili accelerano movimento laterale e persistenza	Copertura Windows LAPS, gestione DSRM, supporto gMSA, ownership degli account di servizio, dipendenze di rotazione password	Evidenza di rotazione, report di copertura LAPS, revisione delle ACL di recupero, record di migrazione dei servizi
Permessi delegati, controllo GPO e accesso legato alla replica	L’abuso del control plane aggira spesso la visione centrata solo sui gruppi admin nominati	Permessi GPO, delega di OU, diritti con capacità di replica, governance dei gruppi privilegiati, presenza di AD CS se distribuito	Review dei permessi prima/dopo, diff delle GPO, inventario degli admin delegati, evidenza di approvazione
Audit policy e workflow di validazione	Senza visibilità, la messa in sicurezza non può essere rimisurata né difesa nel tempo	Copertura di audit, design delle SACL, routing WEF/WEC, retention, ownership degli alert	Campioni di eventi prima/dopo, salute del collector, evidenza conservata per i rerun

Se AD CS è presente, includi esposizione dei certificate template, configurazione della CA ed enrollment endpoints nella stessa matrice come riga condizionale invece di trattarli come progetto futuro separato.

Validazione dopo i cambiamenti di messa in sicurezza

Un programma di messa in sicurezza è concluso solo quando i controlli continuano a funzionare in condizioni di produzione. Evidenze di validazione utili includono:

Prova che l’amministrazione privilegiata ora origina solo da host approvati o da jump path definiti.
Prova che i client LDAP continuano a funzionare con la postura target per LDAP signing e channel binding.
Prova che i workflow amministrativi e di file SMB continuano a funzionare con i requisiti di firma previsti.
Prova che Windows LAPS ruota i segreti di admin locale e DSRM e che i diritti di recupero sono strettamente limitati.
Prova che le migrazioni degli account di servizio verso gMSA o verso una gestione operativa più rigorosa non hanno lasciato SPN rotti né eccezioni non gestite.
Prova che permessi delegati, diritti legati alla replica e percorsi di controllo GPO sono stati rivisti prima e dopo il cambiamento.
Prova che audit policy e pipeline degli eventi catturano davvero i controlli sui quali intendi fare affidamento.

Anche per questo questo pillar si colloca accanto, e non sopra, al pillar di audit. La domanda hardening è «che cosa blocchiamo per primo?». La domanda audit è «che cosa rivediamo in modo ricorrente e come dimostriamo deriva o remediation nel tempo?». Entrambe contano, ma non sono lo stesso workflow.

Come EtcSec supporta review ripetibili di messa in sicurezza AD

EtcSec si inserisce qui come livello di misurazione ripetibile, non come scorciatoia che aggira il lavoro reale di messa in sicurezza. Un collector locale read-only può aiutare a rimisurare la dispersione degli account privilegiati, i permessi con capacità di replica, l’esposizione LDAP signing, l’esposizione SMB signing e la copertura Windows LAPS dopo ogni wave di cambiamento. Questo è utile quando serve verificare che una decisione di messa in sicurezza abbia davvero ridotto l’esposizione, invece di aver solo cambiato un’impostazione di policy sulla carta.

Messa in sicurezza Active Directory: cosa bloccare prima e come validarlo