Active Directory Tiered Admin Model: costruire tier che reggono (da ESAE a RAMP)

Cos'è l'Active Directory Tiered Admin Model

L'Active Directory Tiered Admin Model è l'architettura di sicurezza che impedisce a un attaccante che ha compromesso un laptop dell'help desk di arrivare direttamente a Domain Admin. Suddivide ogni identità, workstation e server in livelli di fiducia — Tier 0 (il piano di controllo dell'identità stesso), Tier 1 (server e applicazioni di business) e Tier 2 (workstation degli utenti finali e account standard) — e applica una regola in entrambe le direzioni: le credenziali di un tier superiore non devono mai essere esposte a un tier inferiore, e le credenziali di un tier inferiore non devono mai poter controllare un tier superiore (Microsoft Learn, AD DS Tier Model).

La maggior parte degli ambienti che dichiarano di adottare un modello a tier in realtà non lo applica. I Domain Admin fanno RDP sui server membri per "controllare solo una cosa". Una GPO del service desk di Tier 1 viene collegata un'OU più in alto del dovuto e finisce sull'OU dei domain controller. Un account break-glass resta fuori da Protected Users perché nessuno si è ricordato di aggiungerlo. Presi singolarmente sono scostamenti piccoli; insieme, fanno crollare il confine tra tier che il modello esiste per proteggere — esattamente il tipo di deriva degli accessi privilegiati che si reinsinua dopo un hardening a meno che qualcosa non continui a riverificarlo.

Sbagliare quel confine costa caro, perché una compromissione di Tier 0 non è un incidente localizzato — è totale. Un attaccante che ottiene una credenziale Tier 0 (tramite un logon cross-tier, una GPO con ambito sbagliato, o un account dimenticato fuori da Protected Users) può in genere eseguire un DCSync dell'intera directory e forgiare ticket Kerberos per qualsiasi identità del dominio. Il modello a tier esiste proprio per contenere questo esito a una violazione di Tier 0, invece di lasciare che una singola workstation helpdesk compromessa arrivi a quel punto.

Dalle OU all'applicazione concreta: come funziona davvero il tiering

Il tiering non è uno schema — è una struttura di OU, un insieme di GPO con un ambito ben definito e un confine rigido su dove gli account privilegiati possono effettuare il logon interattivo.

Struttura delle OU

Gli asset Tier 0 (domain controller, AD FS, server PKI/ADCS, infrastruttura di backup in grado di ripristinare un DC, e gli account/gruppi che li amministrano) risiedono in un albero di OU Tier 0 dedicato, separato dai server Tier 1 e dalle workstation Tier 2. Delega e collegamenti GPO seguono lo stesso confine — una GPO di hardening delle workstation Tier 2 non deve mai essere collegata vicino all'OU Tier 0, e viceversa (Microsoft Community Hub, Initially Isolate Tier 0 Assets with Group Policy).

Privileged Access Workstations (PAW)

Gli account admin Tier 0 dovrebbero poter effettuare il logon interattivo solo su un piccolo insieme dedicato di dispositivi Tier 0 — PAW collegate alla propria OU, con GPO di hardening (nessuna navigazione internet, nessuna email, allow-listing delle applicazioni) circoscritte esclusivamente a quell'OU (Microsoft Learn, PAW legacy guidance). Questa è l'applicazione pratica della Regola n. 1: se una credenziale Tier 0 può autenticarsi su un dispositivo Tier 1 o Tier 2, il confine è già compromesso, indipendentemente da cosa dicano l'organigramma o lo schema sul wiki.

Disciplina nell'ambito delle GPO

Collegate le GPO di hardening solo all'OU appropriata per quel tier — mai alla radice del dominio, mai alla Default Domain Policy. Collegare una GPO attraverso OU di tier diversi è uno dei modi più comuni in cui i confini tra tier si erodono silenziosamente nell'arco di mesi, perché nessuno nota l'aggiunta di un collegamento come noterebbe un nuovo account admin.

Rilevamento: individuare le violazioni di tier prima che vengano sfruttate

Una violazione di tier non è un evento isolato — è uno schema in cui un'identità privilegiata o un collegamento GPO compare dove non dovrebbe. Costruite i vostri rilevamenti attorno a questi segnali:

Perché l'Event ID 4672 è il segnale ad alta affidabilità

L'Event ID 4672 ("privilegi speciali assegnati a un nuovo logon") scatta immediatamente dopo un 4624 riuscito per qualsiasi account con diritti equivalenti ad admin, e il suo Logon ID è la chiave di join lungo l'intero ciclo di vita della sessione — 4624 → 4672 → attività → 4634/4647 (Microsoft Learn, Event 4672). Su una workstation dove un Domain Admin non dovrebbe mai effettuare il logon interattivo, un singolo 4672 per quell'account è un alert ad alta affidabilità e basso sforzo — non serve strumentazione UEBA per intercettare il caso ovvio, basta la regola di correlazione giusta nell'ambito di OU giusto.

Remediation: costruire tier che reggono

1. Spostate gli account privilegiati in un'OU admin Tier 0 dedicata. È il controllo che ANSSI cita direttamente — gli account con adminCount=1 che vivono fuori da un'OU dedicata e strettamente delegata rompono la segmentazione da cui dipende il resto del modello (ANSSI-PA-099, "Recommandations relatives à l'administration sécurisée des systèmes d'information reposant sur Microsoft Active Directory", ott. 2023).

2. Aggiungete tutti gli account Tier 0 a Protected Users. Questo blocca l'autenticazione NTLM, la crittografia Kerberos DES/RC4, la delega unconstrained/constrained e i TGT a lunga durata per quegli account — chiudendo diversi dei percorsi di furto di credenziali che le lacune di delega altrimenti espongono.

3. Applicate una Fine-Grained Password Policy ai gruppi Tier 0. I Domain e gli Enterprise Admin non dovrebbero ereditare la password policy di dominio predefinita; una PSO dedicata, con requisiti di lunghezza e rotazione più rigidi, limita il raggio d'impatto se una credenziale Tier 0 viene comunque esposta.

4. Circoscrivete rigorosamente ogni GPO alla sua OU di tier. Verificate i collegamenti GPO esistenti alla ricerca di qualsiasi cosa tocchi sia un'OU Tier 0 sia una Tier 1/2, e separatele. Non aggiungete mai impostazioni di applicazione del tiering alla Default Domain Policy — create GPO dedicate e collegatele solo all'OU di tier pertinente.

5. Implementate le PAW per il logon interattivo Tier 0, e poi applicatelo tecnicamente. Usate GPO sui diritti di logon (Deny log on locally / Deny log on through Remote Desktop Services) sugli asset Tier 1/2 per gli account Tier 0, non solo come documentazione di policy — una regola scritta che nessuno può violare tecnicamente non sopravvive a un incidente.

6. Rifate la baseline trimestralmente, non una volta sola. I confini tra tier si spostano con il normale lavoro amministrativo — un nuovo admin di server aggiunto al gruppo sbagliato, una GPO ricollegata durante una migrazione, o account privilegiati obsoleti che nessuno ha rimosso da Tier 0. Un progetto di tiering una tantum senza audit ricorrente degenera di nuovo in amministrazione piatta in meno di un anno; vedere la guida più ampia alle priorità di hardening per capire come questo si inserisce in una sequenza più ampia di hardening di AD, e le raccomandazioni ANSSI in pratica per la checklist completa orientata alla compliance di cui questo modello fa parte.

Come EtcSec rileva tutto questo

L'audit Active Directory di EtcSec verifica le violazioni del modello a tier direttamente sulla vostra directory live: ANSSI_R15_TIER_MODEL_VIOLATION segnala account privilegiati fuori da un'OU admin dedicata, ANSSI_R40_NO_PSO_TIER0 segnala gruppi Tier 0 privi di una Fine-Grained Password Policy, ANSSI_R86_ADMIN_FOREST_SEGREGATION verifica la segregazione di trust della foresta di amministrazione quando ne viene usata una, NOT_IN_PROTECTED_USERS segnala account privilegiati assenti dal gruppo Protected Users, e EXCESSIVE_PRIVILEGED_ACCOUNTS segnala confini di tier cresciuti troppo per essere verificati manualmente.