Cosa significa validare i backup di Active Directory per ripristinare una foresta
La validazione dei backup di Active Directory per il ripristino di una foresta pone due domande: il backup può essere ripristinato e l’organizzazione può giustificare la propria fiducia nella foresta recuperata da quel backup? Un ripristino riuscito risponde alla prima. La seconda richiede un punto di ripristino esaminato, una procedura provata e le evidenze che la directory ripristinata soddisfi i criteri di recupero.
La guida Microsoft al ripristino delle foreste Active Directory offre un modello da adattare all’ambiente. Le sue indicazioni per la valutazione dell’incidente escludono esplicitamente raccomandazioni di sicurezza complete per recuperare una foresta violata o compromessa. Utilizza la procedura di ripristino insieme alle attività di risposta all’incidente necessarie per stabilire la fiducia.
Qui, ripristino validato indica un’esercitazione o un ripristino documentati, con controlli di accettazione registrati e limiti esplicitamente dichiarati. È una definizione editoriale, non una certificazione Microsoft. «Il DC si è avviato» e «la replica funziona» sono osservazioni utili, ma nessuna delle due dimostra che lo stato della directory selezionato sia sicuro.
| Domanda | Evidenze da richiedere | Cosa rimane aperto |
|---|---|---|
| Il backup è ripristinabile? | Il risultato di un ripristino reale del backup e del percorso di recupero scelti | Se lo stato ripristinato sia affidabile |
| Il ripristino è ripetibile? | Una procedura aggiornata e un verbale di esercitazione datato | Se il prossimo incidente avrà lo stesso perimetro |
| Il punto di ripristino è giustificabile? | Una cronologia dell’incidente e le ragioni per accettare quel backup | Modifiche malevole non coperte dall’indagine |
| La foresta recuperata è pronta? | Controlli operativi registrati e decisioni della revisione di sicurezza | Dipendenze o persistenza al di fuori di quei controlli |
Tratta il tempo impiegato per il ripristino come un altro risultato da registrare. Un’esercitazione rapida con credenziali sconosciute, dati non esaminati o errori di validazione irrisolti non dovrebbe essere descritta come un ripristino validato.
Scegliere uno stato affidabile prima del ripristino
Le indicazioni Microsoft per la selezione dei backup avvertono che un backup più recente può reintrodurre dati pericolosi. Se il momento del guasto è sconosciuto, indaga sull’ultimo stato sicuro. Il recupero perde gli oggetti, gli aggiornamenti e le modifiche di configurazione o schema successivi.
La stessa pagina raccomanda di eseguire regolarmente il backup di almeno due DC scrivibili per dominio. Richiede le credenziali Domain Admin per ogni dominio e la password DSRM. Un backup di un RODC non può ripristinare un DC scrivibile; il ripristino dello stato del sistema su una nuova installazione di Windows non è supportato. Pianifica il percorso appropriato di recupero completo del server. Dsamain e un browser LDAP come Ldp possono aiutare a ispezionare i dati della directory presenti nel backup.
Con il Cestino abilitato, la validità del backup è limitata dal minore tra deletedObjectLifetime e tombstoneLifetime. Queste condizioni rendono «abbiamo un file recente» un argomento incompleto per giustificare il recupero.
Per la decisione di ripristino, registra quale backup è stato scelto, quale dominio rappresenta, perché il suo stato è accettabile e quali modifiche andranno perse. Se l’indagine non consente di sostenere un punto affidabile, registra tale incertezza invece di rietichettare come pulito il backup più recente.
Le affermazioni sulla persistenza devono rimanere condizionali
L’inferenza relativa al ripristino è condizionale: se una modifica malevola della directory è presente nel backup scelto e rientra nello stato ripristinato, ripristinare quello stato può reintrodurre la modifica. È una deduzione dal comportamento documentato di ritorno a uno stato precedente, non un’affermazione Microsoft secondo cui ogni backdoor ritorna necessariamente intatta.
Questa distinzione è importante per ACL e AdminSDHolder. Il nostro articolo su AdminSDHolder e SDProp spiega la persistenza tramite un modello di ACL modificato e perché correggere soltanto l’ACL di un oggetto protetto può lasciare irrisolto il problema del modello. Per il ripristino, verifica se il modello salvato e le autorizzazioni pertinenti corrispondono a una baseline accettata. Le pagine Forest Recovery citate qui non descrivono esplicitamente il ripristino di una backdoor AdminSDHolder.
La documentazione Microsoft sui modelli di certificato afferma che i modelli delle CA aziendali risiedono in AD DS. Distingue la modifica di un modello, l’abilitazione dell’emissione su una CA e la pubblicazione di un certificato emesso. Un modello modificato contenuto nello stato della directory ripristinato potrebbe quindi ricomparire: è un’inferenza condizionale. Non stabilisce la condizione ripristinata di ogni CA, certificato emesso o segreto PKI. Definisci separatamente la revisione PKI complementare.
Il nostro articolo sul Golden Ticket descrive il rischio di persistenza associato a un segreto krbtgt compromesso. Le istruzioni di ripristino e gli intervalli di reset riportati sotto provengono da Microsoft Learn. Il collegamento spiega perché il segreto conta; non è la fonte autorevole per questa procedura di ripristino.
Seguire la sequenza di ripristino con punti di validazione
I prerequisiti Microsoft presuppongono che la causa e i possibili rimedi siano stati valutati con il supporto Microsoft e che il ripristino della foresta sia il rimedio scelto, spesso come ultima opzione. Richiedono anche un piano documentato e testato in laboratorio usando backup di produzione.
Prepara questa decisione prima di iniziare passaggi distruttivi di recupero. Registra il perimetro dell’incidente, le credenziali di ripristino, le informazioni di accesso di emergenza e i backup scelti. La procedura dovrebbe rendere chiara la decisione successiva anche quando i normali servizi di directory non sono disponibili.
Quanto segue è una panoramica della sequenza Microsoft di ripristino iniziale, non un sostituto eseguibile della procedura completa:
- Ripristinare in isolamento. Inizia con un DC scrivibile nel dominio radice della foresta, poi recupera gli altri domini, prima i genitori e poi i figli.
- Usare la modalità corretta per il primo DC ripristinato di ogni dominio. Ripristina AD DS in modo non autorevole e SYSVOL in modo autorevole, seguendo il metodo documentato. I DC successivi di quel dominio devono risincronizzare SYSVOL dalla copia autorevole.
- Verificare i dati ripristinati prima della connessione alla produzione. Completa i passaggi documentati per FSMO, metadati, DNS, RID, password degli account e ora. Un’intrusione sospetta richiede il reset delle password amministrative e la sostituzione di tutte le password gMSA. Anche una sospetta compromissione di account utente richiede di pianificare il reset delle password per tutti gli utenti del dominio.
- Validare insieme i DC recuperati. Usa una rete isolata comune prima della transizione alla produzione.
- Eseguire il backup dei DC ripristinati prima di ridistribuire i DC rimanenti.
La pagina documenta anche questi controlli operativi nella sezione sullo stato della replica della foresta, dopo la transizione alla rete di produzione:
repadmin /replsum
DCDiag /v
Valutano la replica e lo stato dei DC e di DNS. Un risultato positivo non certifica l’assenza di persistenza. Mantieni distinguibili le evidenze operative e le conclusioni della revisione di sicurezza nel registro di ripristino.
Reimpostare krbtgt due volte con l’intervallo documentato
La procedura Microsoft di reset di krbtgt si applica ai DC scrivibili, non ai RODC. In Utenti e computer di Active Directory, abilita Funzionalità avanzate, apri il contenitore Users del dominio e usa Reimposta password su krbtgt.
Esegui l’operazione due volte. L’account conserva le due password più recenti; due reset rimuovono la vecchia password dalla cronologia. Learn richiede 10 ore tra i reset con le durate massime predefinite dei ticket utente e di servizio. Se la durata massima viene modificata, il periodo di attesa deve essere maggiore del valore configurato. Non presumere che il primo reset invalidi universalmente ogni ticket contraffatto.
Per un recupero che coinvolge RODC, Learn indica di non eliminare i relativi account krbtgt_number. Non applicare loro la procedura dei DC scrivibili.
Rilevamento: misurare l’età dei backup e le evidenze mancanti
Il successo di un’attività di backup, un timestamp della directory e un’esercitazione di ripristino descrivono evidenze diverse. Esamina ciascuna per ciò che dimostra.
Le indicazioni Microsoft sulla latenza dei backup documentano:
Repadmin.exe /showbackup
Raccogli le date di backup riportate per i DC e i contesti di denominazione interessati e registra il perimetro reale del comando. Repadmin richiede credenziali amministrative su ogni DC di destinazione. Microsoft spiega che il timestamp del backup viene scritto dai backup che usano le API standard di backup; una copia a livello di file del database AD non offre questa protezione.
Indaga quando i backup sono più vecchi di metà della durata tombstone della foresta. Learn afferma che i backup più vecchi della durata tombstone sono invalidi e raccomanda backup almeno quotidiani in quasi tutti gli scenari. Leggi le impostazioni reali delle durate della foresta. Non sostituirle con un valore universale di 180 giorni o con la soglia indipendente di 60 giorni del collettore.
Un timestamp recente non dimostra comunque l’integrità del supporto o un ripristino riuscito.
| Segnale da indagare | Evidenze da raccogliere | Decisione successiva |
|---|---|---|
| Informazioni di backup mancanti o datate | Risultati di /showbackup con il relativo perimetro, cronologia delle attività e inventario dei backup disponibili | Correggere la copertura mancante o le attività fallite |
| Nessuna esercitazione di ripristino registrata | Data dell’ultima prova, identificativi dei backup e risultati dei controlli | Pianificare un’esercitazione con backup di produzione |
| Punto di recupero incerto | Cronologia dell’incidente e revisione dello stato candidato salvato nei backup | Stabilire l’ultimo punto affidabile o mantenere l’incertezza |
| Cestino non disponibile o stato sconosciuto | Stato reale della funzionalità e revisione dei prerequisiti | Pianificare l’abilitazione prima di future eliminazioni |
| Controlli di ripristino falliti | Risultati diagnostici salvati e scostamenti dalla procedura | Risolvere il problema prima di accettare il ripristino |
Questi sono spunti d’indagine, non osservazioni di un ambiente cliente. Richiedi gli artefatti dietro «testato» o «recuperabile»: quale backup, quale dominio, quale revisione della procedura e quali controlli superati?
Correzione: documentare, esercitarsi e preparare il recupero degli oggetti (Remediation)
1. Rendere la procedura specifica per la foresta
Le indicazioni Microsoft per la pianificazione richiedono una mappa della topologia che includa DC, ruoli, stato dei backup e relazioni di trust. Raccomandano di esercitarsi nel recupero della foresta almeno ogni anno e suggeriscono prove anche quando cambia la composizione di Domain Admins o Enterprise Admins.
Trasforma la mappa in un registro di decisioni utilizzabile: identifica il DC di recupero per ogni dominio, i criteri di selezione dei backup, gli accessi richiesti e i punti di validazione. Assegna la responsabilità di mantenere aggiornate queste informazioni. Una lacuna inspiegata deve restare visibile anziché essere nascosta da una checklist completata.
2. Ripetere il ripristino e conservare i risultati
I prerequisiti richiedono backup e ripristini regolari in laboratorio di AD DS e SYSVOL, revisioni periodiche della procedura e aggiornamenti dopo modifiche al sistema operativo o all’architettura. Prova il percorso di recupero effettivo con backup di produzione.
Un verbale di esercitazione utile identifica la revisione della procedura, i backup scelti, gli operatori, i controlli eseguiti, i risultati e gli scostamenti. Includi il tempo trascorso, ma dichiara anche cosa l’esercitazione ha validato e cosa non ha validato. Se un backup si avvia correttamente ma la revisione dei dati fallisce, conserva entrambi i risultati. Se un accesso richiesto non era disponibile, registralo come dipendenza del recupero da correggere.
Distingui «la procedura è stata eseguita» da «i criteri di accettazione sono stati superati». Ripetere una procedura senza esaminarne i risultati non risolve la questione della fiducia.
3. Abilitare il Cestino prima che serva
Le indicazioni Microsoft sul Cestino affermano che la funzionalità è disabilitata per impostazione predefinita e che l’attivazione è irreversibile. Conserva gli attributi e i collegamenti degli oggetti eliminati, comprese le appartenenze ai gruppi. Può recuperare soltanto oggetti eliminati dopo l’abilitazione.
Verifica i prerequisiti documentati: livelli funzionali di foresta e dominio di Windows Server 2008 R2 o superiori, le autorizzazioni amministrative indicate e ADAC o il modulo PowerShell Active Directory.
Per il percorso ADAC documentato, seleziona il dominio di destinazione appropriato, scegli Abilita Cestino nel riquadro Attività, conferma i messaggi e aggiorna ADAC. Dopo un’eliminazione di prova controllata, usa il contenitore Oggetti eliminati per ripristinare l’oggetto selezionato e verificarne la posizione.
Registra la decisione di abilitazione e un test controllato di ripristino di un oggetto. Il Cestino riguarda il recupero degli oggetti; non valida una foresta compromessa. Mantieni quel test separato dall’esercitazione di ripristino della foresta.
4. Colmare le lacune di evidenza prima di dichiarare validato il ripristino
Usa un breve registro di accettazione che colleghi ogni conclusione alle evidenze. «Backup disponibile» deve nominare il backup. «Recupero provato» deve identificare l’esercitazione. «Stato affidabile» deve identificare l’indagine e la revisione della baseline. «Controlli operativi superati» deve identificare i risultati registrati.
Quando l’incidente richiede ulteriore lavoro di sicurezza o PKI, indica l’attività irrisolta e il suo responsabile. Non lasciare che un controllo di replica riuscito diventi tacitamente l’approvazione di tutto ciò che è fuori dal suo perimetro.
Come EtcSec rileva questi segnali
Il collettore fornisce tre controlli attivi pertinenti a questo argomento. Individuano segnali di configurazione o revisione; non dimostrano la recuperabilità della foresta.
| Controllo attivo | Predicato effettivo | Limite |
|---|---|---|
HDS_5_8_DR_PLAN_MISSING | Meno di 2 DC inventariati produce Count 1 | Un’euristica basata sul numero di DC. Non legge procedure, backup o esercitazioni. Due DC nella stessa sede senza un piano possono superarla; una distribuzione con un solo DC ben pianificata può fallire. |
DC_BACKUP_OLD | L’assenza di DomainInfo o LastADBackupDate produce Count 1; altrimenti più di 60 giorni interi produce Count 1 | Il provider popola il campo con il massimo whenChanged tra gli oggetti nTDSDSA. È un indicatore indiretto di metadati NTDS a livello di raccolta, non l’età dei backup per DC. Le modifiche alla topologia possono farlo sembrare recente. Esattamente 60 giorni interi non attivano il controllo. |
RECYCLE_BIN_DISABLED | RecycleBinEnabled=false produce Count 1; true produce Count 0 | Se manca DomainInfo, il risultato è sconosciuto con Count 0. Non è la prova che la funzionalità sia abilitata. |
L’identificativo HDS non stabilisce un requisito HDS numerato specifico né dimostra l’assenza di un piano di recupero. Usalo per sollecitare una revisione umana della topologia e della pianificazione del recupero.
BACKUP_AD_NOT_VERIFIED non è misurato dal collettore. Il suo rilevatore ritirato non restituisce risultati e non è registrato. È escluso dai tag di vulnerabilità di questo articolo. Verificare il ripristino richiede evidenze operative al di fuori di questi controlli della directory.
Esplora le pagine di identity security collegate a questo tema