Il modello di amministrazione a livelli di Active Directory spiegato
Sep 3, 2026
Il modello di amministrazione a livelli di Active Directory blocca un percorso comune dall’esposizione delle credenziali su una workstation compromessa a Domain Admin. Separa gli account e i sistemi privilegiati in base all’ambito di controllo, quindi applica limiti di accesso in modo che una credenziale privilegiata possa autenticarsi solo da un sistema approvato. Account dedicati e workstation amministrative rinforzate sopportano la maggior parte del carico.
Un amministratore di dominio accede al laptop di un utente per risolvere un problema con la stampante. Un malware già presente su quel laptop legge le credenziali dalla memoria del Local Security Authority Subsystem Service (LSASS) e le riproduce nell'ambiente, rendendo il piano di controllo dell'identità dell'intero dominio raggiungibile da una macchina del help desk.
Questo accade costantemente, e i numeri lo confermano. Il Netwrix 2026 Data and Identity Security Report ha rilevato che il 75% delle esposizioni di dati sensibili inizia con identità compromesse o permessi configurati in modo errato. La maggior parte inizia con una credenziale privilegiata presente nella memoria di una macchina non attendibile.
La domanda ovvia è perché i controlli che la maggior parte delle organizzazioni già utilizza non sono riusciti a fermarlo. L'autenticazione multifattoriale (MFA), privileged access management (PAM) e l'Accesso Condizionale agiscono sulla credenziale solo una volta che raggiunge il dispositivo, il che è troppo tardi per intervenire. Il modello di amministrazione a livelli funziona prima, regolando dove una credenziale privilegiata può comparire in primo luogo.
Cos'è il modello di amministrazione a livelli di Active Directory?
Il modello di amministrazione a livelli di Active Directory (AD) è un design di accesso privilegiato che separa account, sistemi e strumenti amministrativi in Livello 0, Livello 1 e Livello 2 in base alla loro portata di controllo sull’ambiente. La sua regola di sicurezza principale è che le credenziali di livello superiore si autenticano solo da sistemi approvati nel loro livello assegnato, riducendo il furto di credenziali e i movimenti laterali.
Il principio alla base è che è la tastiera, e non il sistema di destinazione, a stabilire il livello di fiducia effettivo di una sessione. Una credenziale Domain Admin inserita su un laptop dell'help desk trasferisce l'esposizione di quel laptop direttamente al controller di dominio che gestisce. La documentazione del modello a livelli AD di Microsoft considera quindi la workstation amministrativa come parte del confine di sicurezza.
Le unità organizzative (OUs), i gruppi e Group Policy Objects (GPOs) sono il punto di partenza per i team e organizzano solo gli oggetti a cui si applica il modello. La separazione dei livelli avviene tramite account dedicati per livello, applicazione del login, workstation amministrative, delegazione deliberata, monitoraggio e un processo per la revisione delle eccezioni.
Perché la gerarchia di Active Directory è ancora importante
La stratificazione precede la maggior parte degli strumenti ora venduti per risolvere l'accesso privilegiato. Le organizzazioni che utilizzano MFA, Privileged Access Management e Accesso Condizionale portano ancora l'esposizione che è stata progettata per chiudere, e le ragioni si riducono al raggio d'azione, al percorso di attacco e alla copertura.
Contiene un raggio d'azione che copre l'intero ambiente
La stratificazione limita fino a dove può arrivare una credenziale esposta, cosa che conta di più in AD perché AD è il piano di controllo dell'identità. Gli account privilegiati e i servizi dietro di essi controllano l'accesso, l'autenticazione, le policy e il recupero per ogni sistema che si fida del dominio.
Senza quel limite, una singola credenziale di amministratore di directory è sufficiente per accedere a tutto. Recuperare un server membro richiede un pomeriggio, mentre recuperare un piano di controllo dell’identità su cui un attaccante ha avuto diritti amministrativi è un progetto di recupero della foresta.
Chiude il percorso che la maggior parte delle violazioni effettivamente usa
Il tiering blocca la singola condizione necessaria da cui dipendono la maggior parte delle compromissioni di dominio: una credenziale con privilegi elevati che appare su una workstation a fiducia inferiore. Pass-the-hash, il dumping delle credenziali LSASS e il furto di ticket Kerberos richiedono che ciò sia accaduto prima.
Rimuovere la precondizione, invece di rilevare ogni tecnica, rende il controllo duraturo, poiché resiste a strumenti che nessuno ha ancora creato.
Colma una lacuna che Privileged Access Management e MFA da soli non possono coprire
La stratificazione governa dove una credenziale può essere utilizzata, che è l’unica domanda che gli altri controlli lasciano aperta. Le workstation di accesso privilegiato (PAWs) stabiliscono la fiducia dell’endpoint, PAM e l’accesso just-in-time (JIT) governano la durata, e MFA e Accesso Condizionale governano la forza dell’autenticazione.
Il token theft playbook di Microsoft mostra quanto poco aiuti la forza dell'autenticazione una volta che una credenziale è già su un endpoint compromesso, poiché un attaccante che ruba e riproduce un token emesso ottiene l'accesso anche se l'utente ha soddisfatto MFA.
Netwrix Auditor monitora le modifiche privilegiate di AD, i cambiamenti di appartenenza ai gruppi e le modifiche GPO fino alla workstation di origine. Richiedi una demo.
I tre livelli di amministrazione di Active Directory
Ogni livello raggruppa risorse e identità amministrative in base al controllo che detengono, e i requisiti per workstation e accesso si fanno più stringenti con l’aumentare di tale controllo. Il livello di un sistema è determinato da ciò che può raggiungere.
Tier | Purpose | Typical assets | Typical admin identities | Core rule |
|---|---|---|---|---|
|
Tier 0 |
Identity control plane |
Domain controllers, AD CS, AD FS, Entra Connect, Tier 0 groups and accounts |
Domain and Enterprise Admins, identity admins, PKI and sync admins |
Use Tier 0 accounts only from Tier 0 workstations |
|
Tier 1 |
Enterprise servers and applications |
Member servers, SQL Server, Exchange, SharePoint, application and database servers |
Server, application, database, and workload administrators |
Use Tier 1 accounts only on Tier 1 administrative systems |
|
Tier 2 |
End-user computing and support |
User workstations, laptops, help desk tooling |
Desktop support and help desk administrators |
Access limited to end-user computing and support |
Livello 0: Il piano di controllo dell'identità
Il Tier 0 contiene ogni risorsa che controlla il servizio directory, direttamente o indirettamente. L'inventario di Microsoft copre i controller di dominio e Active Directory Domain Services (AD DS), Active Directory Certificate Services (AD CS) e l'infrastruttura a chiave pubblica (PKI) che li supporta, e Active Directory Federation Services (AD FS). Anche Microsoft Entra Connect e gli account e gruppi del Tier 0 appartengono qui.
Anche i sistemi di backup in grado di ripristinare un controller di dominio appartengono qui. Qualsiasi cosa possa ripristinare un controller di dominio può anche ricostruirne uno secondo le condizioni di un attaccante.
Gli amministratori di Tier 0 lavorano solo da Tier 0 PAWs, utilizzando account dedicati di Tier 0. Proteggere i controller di dominio inizia controllando quali credenziali possono raggiungerli.
Livello 1: Server, carichi di lavoro e applicazioni aziendali
Il Tier 1 copre server membri, applicazioni, database e gli account che li amministrano, corrispondenti ai piani di gestione e dati/carichi di lavoro nel Enterprise Access Model di Microsoft.
In pratica, ciò significa file server, SQL Server, Exchange Server, applicazioni di linea di business e piattaforme di virtualizzazione limitate ai carichi di lavoro Tier 1. La restrizione vale in entrambe le direzioni. Un amministratore Tier 1 accede solo ai sistemi Tier 1, e i sistemi Tier 1 avviano solo l’amministrazione Tier 1.
Livello 2: Postazioni di lavoro e supporto utenti
Il Tier 2 presenta la maggiore esposizione tra i tre, a causa di ciò che accade quotidianamente su quegli endpoint. Gli utenti navigano sul web, aprono allegati, installano software e subiscono i tentativi di phishing che avviano la maggior parte delle intrusioni.
Copre le postazioni di lavoro degli utenti finali, i laptop, gli account utente e le identità che li supportano. Il lavoro di help desk si svolge qui, coprendo il reset delle password, il supporto alle postazioni di lavoro e la risoluzione dei problemi degli endpoint, e i diritti degli account di Tier 2 restano limitati alle risorse di Tier 2.
Come implementare il modello a livelli in Active Directory
L'implementazione inizia con un inventario accurato e termina con un'applicazione che resiste a un amministratore locale. Microsoft considera la sua sequenza raccomandata come un percorso e non come una catena di dipendenze rigida, quindi le fasi successive possono essere eseguite in parallelo.
1. Inventariare ogni account e asset privilegiato
Catalogare ogni sistema AD, account e strumento con accesso amministrativo. Quelli indiretti sono i più importanti, perché nulla indica che possano raggiungere Tier 0. Questa lista include service accounts, piattaforme di backup che possono ripristinare controller di dominio, l'infrastruttura a chiave pubblica e Entra Connect, che Microsoft classifica come componente Tier 0.
Solo il 36% delle organizzazioni ha condotto una valutazione completa della sicurezza di AD negli ultimi 12 mesi, secondo il Netwrix 2026 Data and Identity Security Report, quindi la maggior parte degli inventari parte da zero anziché da un record esistente.
2. Classifica ogni asset in base a ciò che può controllare
Qualsiasi account o sistema che può gestire un livello superiore appartiene a quel livello, indipendentemente da dove era destinato a trovarsi.
Le piattaforme di backup, gli host di virtualizzazione che eseguono macchine virtuali di Tier 0, gli agenti di endpoint detection and response sui controller di dominio e i diritti di gestione di Group Policy appartengono tutti a Tier 0 quando possono raggiungere asset di Tier 0. Microsoft Incident Response ha documentato il costo di un errore: un misconfigured PAM server posizionato in Tier 1 deteneva le chiavi di Tier 0 e ha fornito agli attaccanti una via attraverso il confine.
3. Crea account separati per ogni livello
Fornisci agli amministratori account distinti per livello, senza sovrapposizioni. Ciò significa un account identity-admin di Tier 0, un account server-admin di Tier 1 e credenziali standard per l’uso quotidiano per tutto il resto.
Il piano di modernizzazione rapida di Microsoft mira al 100% degli utenti privilegiati on-premises con account dedicati separati. La separazione degli account consente anche l’applicazione del login, poiché un singolo account usato su più livelli non offre nulla da limitare.
4. Applicare restrizioni di accesso al controller di dominio e all’endpoint
Distribuisci entrambi i meccanismi disponibili invece di scegliere tra loro. Group Policy offre una copertura ampia sugli endpoint, e le policy di autenticazione Kerberos aggiungono un confine che il controller di dominio applica autonomamente, che è la parte che rimane valida anche dopo che una macchina di livello inferiore è stata completamente compromessa.
Le restrizioni di accesso basate su GPO negano i diritti di accesso interattivo, Remote Desktop Protocol (RDP), di rete, batch e servizio per account di livello superiore su endpoint di livello inferiore tramite l'assegnazione dei diritti utente. L'Autorità di sicurezza locale dell'endpoint le applica, motivo per cui Microsoft riconosce che un amministratore locale può bypassare la Group Policy e che la restrizione si applica solo alle macchine Windows aderenti ad AD.
Le policy di autenticazione Kerberos e i silos di policy di autenticazione limitano da dove può provenire una credenziale privilegiata, e il Key Distribution Center (KDC) del controller di dominio applica il controllo quando emette un ticket. AD rifiuta di emettere un Ticket Granting Ticket da un computer non autorizzato anche se le credenziali sono corrette.
Entrambi i meccanismi hanno prerequisiti facili da trascurare. I controlli del dispositivo sorgente richiedono che il Kerberos armoring, chiamato anche Flexible Authentication Secure Tunneling, sia abilitato su controller di dominio e client. Le politiche di autenticazione esentano anche l’account Administrator di dominio integrato, che deve essere gestito separatamente.
5. Fornisci a ogni livello una propria workstation protetta
Distribuisci un PAW per livello in modo che l'ambiente imponga la separazione invece di affidarsi all'amministratore che ricordi una regola sotto pressione di tempo. La guida di Microsoft afferma che il modello a livelli dipende dall'amministrazione che parte da una workstation attendibile corrispondente al livello amministrato.
Un PAW di Livello 0 segue rigide restrizioni applicative che rimuovono email, navigazione e software di produttività, che sono le vie di consegna per malware che raccolgono credenziali. Abbinare il PAW con Windows Defender Credential Guard mantiene le credenziali derivate fuori portata sulla macchina stessa.
6. Distribuire in fasi, iniziando con Tier 0
Proteggi prima il Tier 0, coprendo account, PAW e applicazione, prima di estendere lo stesso processo al Tier 1 e poi al Tier 2. Le fasi successive dipendono da un piano di controllo dell'identità pulito.
Testa le GPO di applicazione fuori produzione prima che raggiungano un dominio attivo, perché Microsoft avverte che un ordine errato dei collegamenti può bloccare gli amministratori di dominio su ogni sistema Windows nel dominio, inclusi i controller di dominio.
Errori comuni da evitare durante l'implementazione del modello a livelli in Active Directory
La maggior parte dei programmi di tiering sono progettati correttamente e poi compromessi dal divario tra il progetto e ciò che viene effettivamente applicato. Ogni errore amplia prevedibilmente questo divario, e ciascuno emerge mesi dopo la chiusura del progetto.
Considerare il tiering come un progetto di redesign dell’OU
Creare solo le OU di Tier 0, Tier 1 e Tier 2 lascia gli account privilegiati liberi di autenticarsi ovunque. Le policy di autenticazione e i diritti di negazione GPO fanno rispettare il confine, mentre la struttura del contenitore organizza solo a cosa si applicano quei controlli.
Configura le restrizioni di accesso prima di spostare gli oggetti AD nella nuova struttura OU, poiché le regole di negazione hanno la precedenza su quelle di autorizzazione e una struttura parzialmente migrata può causare sorprese in entrambe le direzioni.
Consentire account e endpoint a doppio uso
Conserva le credenziali di Tier 0 su endpoint amministrativi dedicati. Microsoft Incident Response rileva ripetutamente che gli amministratori che utilizzano dispositivi amministrativi ordinari per il lavoro quotidiano lasciano credenziali privilegiate che gli strumenti di dumping delle credenziali possono recuperare.
Account separati e PAW sono controlli, non comodità, e abbandonarli sotto pressione temporale è il modo più comune in cui il tiering smette silenziosamente di funzionare.
Supervisione degli account di servizio e automazione
Attività pianificate, strumenti di distribuzione, script e account di servizio necessitano della stessa disciplina a livelli degli amministratori umani, cioè un proprietario nominato, least privilege e un percorso di autenticazione allineato al livello.
Negare i diritti di accesso interattivo per gli account di servizio e manterrete il percorso di autenticazione di ogni servizio all'interno del livello assegnato. Group Managed Service Accounts aiutano rimuovendo la password statica condivisa che rende un account di servizio portatile tra i livelli.
Lacune nel monitoraggio degli accessi cross-tier
Attenzione a una credenziale Tier 0 che si autentica su un sistema Tier 1 o Tier 2. Microsoft valuta l’Evento 4964 come ad alta criticità e consiglia che un accesso di Domain Admin a una workstation utente finale dovrebbe attivare sia un avviso che un’indagine.
I tentativi di accesso falliti e l'uso esplicito delle credenziali, gli ID evento 4625 e 4648, sono segnali utili per le indagini insieme a le modifiche all'appartenenza a privileged-group, le modifiche a GPO e le eccezioni concesse una volta e mai revisionate. Configura esplicitamente la policy di audit, perché molte impostazioni GPO correlate all'audit sono impostate su Non Configurato.
Come Netwrix supporta la visibilità a livelli e le prove di audit
La stratificazione è una decisione di progettazione e applicazione di cui l'organizzazione è proprietaria. Gli strumenti coprono ciò che il design non può fare da solo: dimostrare che i confini tengono ancora mesi dopo e rimuovere le credenziali permanenti che rendono utile tentare il passaggio.
Netwrix Auditor monitora le modifiche privilegiate a ogni livello
Netwrix Auditor è un prodotto di auditing IT on-premises che traccia modifiche privilegiate in AD, cambiamenti nella membership dei gruppi, modifiche GPO e cambiamenti di permessi con valori prima e dopo. I suoi report rispondono a chi ha cambiato cosa, quando e dove, fino alla workstation di origine.
Diverse di queste funzionalità si collegano direttamente all'applicazione dei livelli. L'analisi dei tentativi di accesso falliti evidenzia i tentativi di autenticazione che una restrizione tra livelli ha appena bloccato, dimostrando che l'applicazione funziona e non è solo configurata.
Gli avvisi di rilevamento dell'escalation dei privilegi si attivano quando un account ottiene un accesso elevato che non possedeva in precedenza, e il rilevamento delle anomalie segnala comportamenti amministrativi che si discostano dalla baseline dell'account. La copertura si estende a Entra ID insieme ad AD on-premises, così una mappa a livelli ibrida rimane visibile in un unico posto.
Flagler Bank ha ottenuto una visione continua del suo profilo di rischio IT con un reparto IT composto da una sola persona, riducendo le indagini da ore a 10 minuti e raggiungendo il primo valore 30 minuti dopo l’installazione.
Netwrix Privilege Secure supporta la separazione degli account e l’accesso just-in-time
Netwrix Privilege Secure fornisce accesso privilegiato limitato al compito e crea una traccia di controllo per ogni sessione. Crea un account effimero per la sessione e lo distrugge dopo, quindi la credenziale privilegiata esiste solo durante il lavoro approvato.
Questo è importante perché il 76% delle organizzazioni non può revocare immediatamente l'accesso permanente una volta che non è più necessario, secondo il Netwrix 2026 Data and Identity Security Report.
Eastern Carver County Schools ha sostituito i privilegi permanenti con accesso just-in-time su sistemi che contengono dati di 9.300 studenti, completando il rollout in pochi giorni e eliminando la confusione nelle verifiche causata dai diritti amministrativi permanenti.
Nessuno dei prodotti implementa il modello a livelli; entrambi servono a dimostrare che funziona ancora dopo il completamento del lavoro di progettazione.
Inizia con Tier 0, poi rendi operativo il modello
Un programma a livelli diventa operativo quando il team può dimostrare che le credenziali di livello superiore sono rimaste all’interno dei percorsi di autenticazione approvati, che un responsabile ha esaminato ogni eccezione e che la traccia di controllo dimostra che l’applicazione è stata mantenuta. Accessi bloccati tra livelli, modifiche ai gruppi privilegiati, età delle eccezioni e proprietà del controllo sono le misure da monitorare.
Per la maggior parte delle organizzazioni, il punto di partenza efficace non è una riprogettazione. Inventaria e proteggi il piano di controllo dell'identità Tier 0, emetti account Tier 0 separati, distribuisci PAW rinforzati e applica restrizioni di accesso sia all'endpoint che al KDC.
Richiedi una demo per vedere come Netwrix traccia le modifiche privilegiate tra i livelli, segnala gli accessi tra livelli e conserva le prove di audit che dimostrano che i confini sono rispettati.
Domande frequenti sul modello di amministrazione a livelli di Active Directory
Condividi su
Scopri di più
Informazioni sull'autore