Protezione dei controller di dominio da attacchi

Legge 3: Se un cattivo attore ha accesso fisico illimitato al computer, non è più il computer. - Dieci leggi immutabili di sicurezza (versione 2.0).

I controller di dominio forniscono l'archiviazione fisica per il database di Active Directory Domain Services (AD DS), oltre a fornire i servizi e i dati che consentono alle aziende di gestire in modo efficace server, workstation, utenti e applicazioni. Se l'accesso con privilegi a un controller di dominio viene ottenuto da un utente malintenzionato, questo potrà modificare, danneggiare o distruggere il database di AD DS e, per estensione, tutti i sistemi e gli account gestiti da Active Directory.

Poiché i controller di dominio possono leggere e scrivere in qualsiasi elemento nel database di Active Directory Domain Services, la compromissione di un controller di dominio significa che la foresta di Active Directory non può mai essere considerata attendibile di nuovo, a meno che non sia possibile recuperarla usando un backup valido noto e chiudere le lacune che hanno consentito la compromissione.

A seconda della preparazione, degli strumenti e della competenza di un utente malintenzionato, il danno irreparabile può essere completato in minuti o ore, non in giorni o settimane. Ciò che conta non è quanto tempo un utente malintenzionato ha accesso con privilegi ad Active Directory, ma il modo in cui l'utente malintenzionato è pronto al momento dell'accesso con privilegi. Compromettere un controller di dominio può fornire il percorso più diretto alla distruzione di server membri, workstation e Active Directory. A causa di questa minaccia, i controller di dominio devono essere protetti separatamente e più rigorosamente rispetto all'infrastruttura generale.

Sicurezza fisica per i controller di dominio

In questa sezione vengono fornite informazioni sulla protezione fisica dei controller di dominio. I controller di dominio possono essere macchine fisiche o virtuali, in data center, succursali o località remote.

Controller di dominio datacenter

Controller di dominio fisici

Nei data center, i controller di dominio fisici devono essere installati in rack o cage sicuri e dedicati, separati dalla popolazione server generale. Quando possibile, i controller di dominio devono essere configurati con chip TPM (Trusted Platform Module) e tutti i volumi nei server controller di dominio devono essere protetti tramite Crittografia unità BitLocker. BitLocker aggiunge una piccola quantità di overhead delle prestazioni, ma protegge la directory da compromissione anche se i dischi vengono rimossi dal server. BitLocker può anche aiutare a proteggere i sistemi da attacchi come rootkit perché la modifica dei file di avvio causa l'avvio del server in modalità di ripristino in modo che i file binari originali possano essere caricati. Se un controller di dominio è configurato per l'uso di RAID software, SCSI collegato a serie, archiviazione SAN/NAS o volumi dinamici, BitLocker non può essere implementato, quindi l'archiviazione collegata localmente (con o senza RAID hardware) deve essere usata nei controller di dominio quando possibile.

Controller di dominio virtuali

Se si implementano controller di dominio virtuali, è necessario assicurarsi che anche i controller di dominio vengano eseguiti in host fisici separati da altre macchine virtuali nell'ambiente. Anche se si usa una piattaforma di virtualizzazione non Microsoft, è consigliabile distribuire controller di dominio virtuali in Hyper-V in Windows Server. Questa configurazione fornisce una superficie di attacco minima e può essere gestita con i controller di dominio che ospita anziché essere gestita con il resto degli host di virtualizzazione. Se si implementa System Center Virtual Machine Manager (SCVMM) per la gestione dell'infrastruttura di virtualizzazione, è possibile delegare l'amministrazione per gli host fisici in cui risiedono le macchine virtuali del controller di dominio e i controller di dominio stessi agli amministratori autorizzati. È anche consigliabile separare l'archiviazione dei controller di dominio virtuali per impedire agli amministratori di archiviazione di accedere ai file delle macchine virtuali.

Località di succursale

Controller di dominio fisici nei rami

Nelle posizioni in cui risiedono più server che tuttavia non sono fisicamente protetti in modo tale da proteggere i data center, i controller di dominio fisici devono essere configurati con chip TPM e Crittografia unità BitLocker per tutti i volumi del server. Se un controller di dominio non può essere archiviato in una sala bloccata in posizioni di succursali, è consigliabile distribuire Read-Only controller di dominio in tali posizioni.

Controller di dominio virtuali nei rami

Quando possibile, è necessario eseguire controller di dominio virtuali nelle succursali in host fisici separati dalle altre macchine virtuali nel sito. Nelle succursali in cui i controller di dominio virtuali non possono essere eseguiti su host fisici separati dal resto del popolamento dei server virtuali, è necessario implementare chip TPM e Crittografia unità BitLocker negli host in cui vengono eseguiti i controller di dominio virtuali, almeno e in tutti gli host, se possibile. A seconda delle dimensioni della succursale e della sicurezza degli host fisici, è consigliabile distribuire controller di dominio di sola lettura nelle succursali.

Posizioni remote con spazio limitato e sicurezza

Se l'infrastruttura include percorsi in cui è possibile installare un solo server fisico, è necessario installare un server in grado di eseguire carichi di lavoro di virtualizzazione e la crittografia unità BitLocker deve essere configurata per proteggere tutti i volumi nel server. Una macchina virtuale nel server deve essere eseguita come controller di dominio di sola lettura e altri server devono essere eseguiti come macchine virtuali separate nell'host. Le informazioni sulla pianificazione della distribuzione dei controller di dominio di sola lettura sono disponibili nella guida alla pianificazione e alla distribuzione dei controller di dominio di sola lettura. Per altre informazioni sulla distribuzione e la protezione dei controller di dominio virtualizzati, vedere Esecuzione di controller di dominio in Hyper-V. Per indicazioni più dettagliate sulla protezione avanzata di Hyper-V, sulla delega della gestione delle macchine virtuali e sulla protezione delle macchine virtuali, vedere la guida alla sicurezza diHyper-V.

Sistemi operativi controller di dominio

È consigliabile eseguire tutti i controller di dominio nella versione più recente di Windows Server supportata dall'organizzazione. Le organizzazioni dovrebbero prioritizzare la dismissione dei sistemi operativi legacy nella popolazione dei controller di dominio. La definizione delle priorità per mantenere i controller di dominio correnti ed eliminare i controller di dominio legacy consente di sfruttare nuove funzionalità e sicurezza. Questa funzionalità potrebbe non essere disponibile in domini o foreste con controller di dominio che eseguono sistemi operativi legacy.

Configurazione sicura dei controller di dominio

È possibile usare gli strumenti per creare una linea di base di configurazione della sicurezza iniziale per i controller di dominio da applicare con oggetti Criteri di gruppo. Questi strumenti sono descritti in Amministrare le impostazioni dei criteri di sicurezza e la panoramica di Desired State Configuration.

Restrizioni RDP

Gli oggetti Criteri di gruppo che si collegano a tutte le unità organizzative del controller di dominio in una foresta devono essere configurati per consentire le connessioni RDP solo da utenti e sistemi autorizzati, ad esempio jump server. Il controllo può essere ottenuto tramite una combinazione di impostazioni dei diritti utente e Windows Firewall con la configurazione sicurezza avanzata. Questi controlli possono essere implementati con oggetti Criteri di gruppo in modo che la politica venga applicata in modo coerente. Se i criteri vengono ignorati, l'aggiornamento successivo di Criteri di gruppo restituisce al sistema la configurazione corretta.

Gestione delle patch e della configurazione per i controller di dominio

Sebbene possa sembrare controintuitivo, è consigliabile applicare le patch ai controller di dominio e ad altri componenti critici dell'infrastruttura separatamente dall'infrastruttura Windows generale. Se si usa un software di gestione della configurazione aziendale per tutti i computer dell'infrastruttura, la compromissione di tale software può danneggiare o distruggere tutti i componenti dell'infrastruttura da esso gestiti. Separando la gestione delle patch e dei sistemi per i controller di dominio dalla popolazione generale, è possibile ridurre la quantità di software installato nei controller di dominio oltre a controllarne strettamente la gestione.

Blocco dell'accesso a Internet per i controller di dominio

Uno dei controlli eseguiti come parte di una valutazione della sicurezza di Active Directory è l'uso e la configurazione dei Web browser nei controller di dominio. Nessun Web browser deve essere usato nei controller di dominio. Un'analisi di migliaia di controller di dominio ha rivelato numerosi casi in cui gli utenti con privilegi hanno usato Internet Explorer per esplorare la intranet dell'organizzazione o Internet.

L'esplorazione di Internet o di una rete Intranet infetta da uno dei computer più potenti di un'infrastruttura Windows rappresenta un rischio straordinario per la sicurezza di un'organizzazione. Sia tramite un'unità da scaricare che tramite il download di "utilità" infettate da malware, gli utenti malintenzionati possono ottenere l'accesso a tutto ciò che devono compromettere completamente o distruggere l'ambiente Active Directory.

È consigliabile limitare l'avvio di Web browser nei controller di dominio usando i criteri e i controlli tecnici. È necessario controllare rigorosamente anche l'accesso a Internet generale da e verso i controller di dominio.

Si consiglia a tutte le organizzazioni di passare a un approccio basato sul cloud alla gestione delle identità e degli accessi ed eseguire la migrazione da Active Directory a Microsoft Entra ID. Microsoft Entra ID è una soluzione completa per la gestione delle identità e degli accessi cloud per la gestione delle directory, l'accesso alle app locali e cloud e la protezione delle identità dalle minacce alla sicurezza. Microsoft Entra ID offre un set affidabile e granulare di controlli di sicurezza per proteggere le identità, ad esempio l'autenticazione a più fattori, i criteri di accesso condizionale, la protezione id, la governance delle identità e Privileged Identity Management.

La maggior parte delle organizzazioni opera in un modello di identità ibrida durante la transizione al cloud, in cui alcuni elementi dell'istanza locale di Active Directory vengono sincronizzati tramite Microsoft Entra Connect. Anche se questo modello ibrido esiste in qualsiasi organizzazione, è consigliabile usare la protezione basata sul cloud di tali identità locali tramite Microsoft Defender per identità. La configurazione del sensore Defender per identità nei controller di dominio e nei server AD FS consente una connessione unidirezionale sicura al cloud tramite un proxy e endpoint specifici. Per una spiegazione completa di come configurare questa connessione proxy, vedere la documentazione tecnica per Defender per identità. Questa configurazione strettamente controllata garantisce che il rischio di connettere questi server al servizio cloud sia mitigato e le organizzazioni traggono vantaggio dall'aumento delle funzionalità di protezione offerte da Defender per identità. È anche consigliabile proteggere questi server con il rilevamento degli endpoint basato sul cloud, ad esempio Microsoft Defender per server.

Per le organizzazioni che dispongono di requisiti normativi o basati su altri criteri per mantenere un'implementazione solo locale di Active Directory, è consigliabile limitare completamente l'accesso a Internet da e verso i controller di dominio.

Restrizioni del firewall perimetrale

I firewall perimetrali devono essere configurati per bloccare le connessioni in uscita dai controller di dominio a Internet. Anche se i controller di dominio potrebbero dover comunicare attraverso i limiti del sito, è possibile configurare firewall perimetrali per consentire la comunicazione tra siti seguendo le linee guida fornite in Come configurare un firewall per domini e trust di Active Directory.

Impedire l'esplorazione Web dai controller di dominio

È possibile usare una combinazione di configurazione di AppLocker, configurazione proxy "black hole" e Windows Firewall con configurazione sicurezza avanzata per impedire ai controller di dominio di accedere a Internet e impedire l'uso di Web browser nei controller di dominio.