Protezione dei controller di dominio dagli attacchi
Legge numero tre: se un malintenzionato ha accesso fisico illimitato al computer di un utente, quel computer non appartiene più all'utente. - 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, a meno che non sia possibile eseguire il ripristino usando un backup valido noto e per chiudere le lacune che hanno consentito la compromissione.
A seconda della preparazione, degli strumenti e della competenza di un utente malintenzionato, è possibile che si verifichino danni irreparabili in pochi minuti, non in giorni o settimane. Ciò che conta non è quanto tempo un utente malintenzionato ha accesso con privilegi ad Active Directory, ma quanto l'utente malintenzionato ha pianificato di fare nel momento in cui ottiene l'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 in 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 un piccolo sovraccarico delle prestazioni, ma protegge la directory da compromissione anche se i dischi vengono rimossi dal server. BitLocker consente inoltre di proteggere i sistemi da attacchi come i rootkit perché la modifica dei file di avvio causa l'avvio del server in modalità di ripristino, in modo che possano essere caricati i file binari originali. 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 vengano eseguiti anche in host fisici separati rispetto ad 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.
Nota
Se si intende condividere i controller di dominio virtualizzati con altre macchine virtuali meno sensibili negli stessi server di virtualizzazione fisica (host), è consigliabile implementare una soluzione che impone la separazione dei compiti basata sui ruoli, ad esempio macchine virtuali schermate in Hyper-V. Questa tecnologia offre una protezione completa da amministratori di infrastruttura dannosi o senza indizi (tra cui virtualizzazione, rete, archiviazione e amministratori di backup). Sfrutta la radice fisica dell'attendibilità con l'attestazione remota e il provisioning sicuro delle macchine virtuali e garantisce in modo efficace il livello di sicurezza equivalente a un server fisico dedicato.
Succursali
Controller di dominio fisici nelle succursali
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 un locale chiuso a chiave in una succursale, è consigliabile distribuire controller di dominio di sola lettura in tali posizioni.
Controller di dominio virtuali in succursali
Quando possibile, è necessario eseguire controller di dominio virtuali nelle succursali in host fisici separati rispetto alle altre macchine virtuali nel sito. Nelle succursali in cui i controller di dominio virtuali non possono essere eseguiti in host fisici separati dal resto della popolazione dei server virtuali, è necessario implementare chip TPM e crittografia unità BitLocker almeno negli host in cui i controller di dominio virtuali vengono eseguiti almeno e, se possibile, in tutti gli host. 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, con altri server in esecuzione 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 di Hyper-V Solution Accelerator nel sito Web Microsoft.
Sistemi operativi dei controller di dominio
È consigliabile eseguire tutti i controller di dominio nella versione più recente di Windows Server supportata all'interno dell'organizzazione. Le organizzazioni devono classificare in ordine di priorità la rimozione delle autorizzazioni dei sistemi operativi legacy nel popolamento dei controller di dominio. È consigliabile stabilire una priorità mantenendo i controller di dominio correnti ed eliminando i controller di dominio legacy; questo consente di sfruttare nuove funzionalità e sicurezza. Questa funzionalità potrebbe non essere disponibile in domini o foreste con controller di dominio che eseguono il sistema operativo legacy.
Nota
Per quanto riguarda qualsiasi configurazione sensibile alla sicurezza e a scopo singolo, è consigliabile distribuire il sistema operativo nell'opzione di installazione di Server Core. Questo offre diversi vantaggi, ad esempio la riduzione della superficie di attacco, il miglioramento delle prestazioni e la riduzione della probabilità di errore umano. È consigliabile eseguire tutte le operazioni e la gestione in remoto da endpoint altamente protetti dedicati, ad esempio workstation con accesso con privilegi (PAW) o host amministrativi protetti.
Configurazione sicura dei controller di dominio
Esistono strumenti che possono essere usati per creare una linea di base di configurazione di sicurezza iniziale per i controller di dominio che possono essere applicati dagli oggetti Criteri di gruppo. Questi strumenti sono descritti nella sezione Amministrare le impostazioni dei criteri di sicurezza della documentazione dei sistemi operativi Microsoft o DSC (Desired State Configuration) per Windows.
Restrizioni RDP
Gli oggetti Criteri di gruppo che collegano a tutte le unità organizzative dei 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 configurazione di Windows Firewall con sicurezza avanzata (WFAS). Questi controlli possono essere implementati con oggetti Criteri di gruppo in modo che i criteri vengano applicati 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, nonché controllare in modo rigoroso 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 di browser Web 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à con download che tramite 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.
L'avvio di browser Web nei controller di dominio deve essere limitato da criteri e controlli tecnici. L'accesso generale a Internet da e verso i controller di dominio deve essere strettamente controllato.
Microsoft incoraggia tutte le organizzazioni a passare a un approccio basato sul cloud per la gestione delle identità e degli accessi e a 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 inoltre 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 delle identità, la governance delle identità e la gestione delle identità con privilegi.
La maggior parte delle organizzazioni opererà in un modello di identità ibrido durante la transizione al cloud, in cui alcuni elementi di Active Directory locale verranno sincronizzati usando Microsoft Entra Connect. Sebbene questo modello ibrido esista in qualsiasi organizzazione, Microsoft consiglia la protezione basata sul cloud di tali identità locali usando Microsoft Defender per identità. La configurazione del sensore Defender per identità nei controller di dominio e nei server AD FS consente una connessione unidirezionale e sicura al cloud tramite un proxy e per endpoint specifici. Una spiegazione completa su come configurare questa connessione proxy è disponibile nella documentazione tecnica di 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à. Microsoft consiglia inoltre di proteggere questi server con il rilevamento di endpoint basati 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, Microsoft consiglia di 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 possono dover comunicare attraverso i limiti del sito, i firewall perimetrali possono essere configurati per consentire la comunicazione tra siti seguendo le linee guida fornite nella sezione Come configurare un firewall per i domini di Active Directory e i trust.
Impedire l'esplorazione Web dai controller di dominio
È possibile usare una combinazione di configurazione di AppLocker, configurazione proxy "black hole" e configurazione WFAS per impedire ai controller di dominio di accedere a Internet e impedire l'uso di Web browser nei controller di dominio.