Questa guida presenta le best practice per l'esecuzione di Active Directory su Google Cloud. La guida si concentra sulle pratiche specifiche per Google Cloud o di particolare importanza durante il deployment di Active Directory in Google Cloud. Considera la guida come complementare alle best practice generali per la protezione di Active Directory pubblicate da Microsoft.
Architettura
Le seguenti sezioni descrivono nel dettaglio le best practice relative all'architettura.
Utilizza il modello di architettura che meglio si adatta ai tuoi requisiti
Per eseguire il deployment di Active Directory su Google Cloud, devi prima decidere quale dominio e architettura di foreste utilizzare. Se già utilizzi Active Directory, devi anche decidere se e come integrare i due ambienti.
La progettazione più adatta alla tua situazione dipende da una serie di fattori, tra cui la progettazione della rete on-premise, l'interazione tra le risorse on-premise e Google Cloud e i requisiti di disponibilità e autonomia amministrativa. Fai riferimento ai nostri pattern per l'utilizzo di Active Directory in un ambiente ibrido per vedere come questi fattori devono determinare la tua progettazione.
Se vuoi mantenere un confine di attendibilità tra Google Cloud e il tuo ambiente on-premise, valuta la possibilità di implementare il pattern foresta di risorse. In questo pattern, esegui il deployment di una foresta separata su Google Cloud e utilizzi un trust forestale unidirezionale per integrare la foresta Google Cloud con la tua foresta Active Directory on-premise esistente.
Test separati e produzione
A seconda dell'utilizzo di Active Directory, potrebbe essere necessario eseguire modifiche frequenti in Active Directory durante lo sviluppo e il test delle applicazioni. Gli sviluppatori potrebbero dover essere in grado di creare e modificare gli account Active Directory, cambiare le iscrizioni ai gruppi se le applicazioni utilizzano gruppi per gestire l'autorizzazione o partecipare e rimuovere computer.
Per evitare che il lavoro di sviluppo e test influisca sui carichi di lavoro di produzione o ostacolando la sicurezza del deployment, valuta la possibilità di eseguire il deployment di una foresta o di un dominio Active Directory separato per lo sviluppo e il test.
La presenza di una foresta o di un dominio di sviluppo e test separato ti consente anche di verificare le modifiche amministrative prima di applicarle alla produzione. Esempi di queste modifiche includono esperimenti con i criteri di gruppo, test degli script di automazione o azioni potenzialmente rischiose come il miglioramento del livello funzionale di una foresta.
Configura la federazione di Cloud Identity oltre al deployment di Active Directory su Google Cloud
Il deployment di Active Directory su Google Cloud ti consente di gestire le VM Windows su Google Cloud, può consentire agli utenti di accedere alle VM Windows utilizzando i loro account utente esistenti e supporta applicazioni che si basano su Kerberos, NTLM o LDAP per l'autenticazione.
Tuttavia, per utilizzare la console Google Cloud, lo strumento a riga di comando gcloud o altri strumenti Google e Google Cloud, devi eseguire l'autenticazione con un'identità Google. Il deployment di Active Directory su Google Cloud non è
quindi un sostituto della fedementazione della Active Directory esistente con
Google Cloud se intendi utilizzare Active Directory
come sistema principale per la gestione degli utenti.
Ad esempio, se esegui il deployment di una foresta separata su Google Cloud, puoi configurare la federazione sulla tua Active Directory on-premise, come illustrato nel seguente diagramma. Gli utenti con account nell'Active Directory on-premise possono utilizzare gli strumenti che richiedono un'identità Google e le tue applicazioni che si basano su Active Directory per l'autenticazione.
Se invece decidi di estendere la foresta esistente o il dominio a Google Cloud, hai anche la possibilità di utilizzare i controller di dominio e i server AD FS di cui è stato eseguito il deployment su Google Cloud per configurare la federazione.
La federazione consente inoltre di applicare un ciclo di vita comune per gli Account Google e gli account Active Directory in modo che, quando disabiliti un account utente nella tua Active Directory on-premise, anche l'utente Google corrispondente venga sospeso.
Networking
La seguente sezione descrive in dettaglio le best practice relative al networking.
Deployment di Active Directory in una rete VPC condiviso
Per consentire l'utilizzo di Active Directory in più progetti, esegui il deployment dei controller di dominio in una rete VPC condiviso. L'utilizzo di una rete VPC condiviso presenta diversi vantaggi:
Il deployment di ogni applicazione che potrebbe richiedere l'accesso ad Active Directory può essere eseguito in un progetto separato. L'utilizzo di progetti separati consente di isolare le risorse e di gestire gli accessi individualmente.
Puoi utilizzare un progetto dedicato per i controller di dominio Active Directory, in modo da avere un controllo granulare su quali utenti possono accedere alle risorse Google Cloud correlate.
Le reti VPC condiviso consentono di centralizzare la gestione degli indirizzi IP e la configurazione del firewall, il che contribuisce a garantire la coerenza tra più progetti.
Poiché i VPC sono una risorsa globale, puoi utilizzare la stessa rete VPC condiviso in più regioni.
Non esporre i controller di dominio all'esterno
Per ridurre la superficie di attacco di Active Directory, evita di assegnare indirizzi IP esterni ai controller di dominio.
Poiché le istanze VM senza indirizzi IP esterni non hanno accesso a internet per impostazione predefinita, devi adottare ulteriori misure per assicurarti che l'attivazione e gli aggiornamenti di Windows non vengano compromessi sui controller di dominio.
Per supportare l'attivazione di Windows, abilita l'accesso privato Google nella subnet in cui prevedi di eseguire il deployment dei controller di dominio e assicurati che le istanze VM possano accedere a kms.windows.googlecloud.com. Ciò consente l'attivazione senza accesso diretto a internet.
Sono disponibili diverse opzioni per supportare gli aggiornamenti di Windows:
Se disponi di un server WSUS on-premise, puoi configurare la connettività ibrida e i controller di dominio in modo che utilizzino il server WSUS come origine per gli aggiornamenti.
Puoi abilitare l'accesso a internet tramite un gateway NAT eseguendo il deployment di Cloud NAT.
Se hai configurato la connettività ibrida, puoi anche instradare il traffico in uscita tramite un gateway NAT on-premise o un server proxy.
Prenota in anticipo gli indirizzi IP statici per i controller di dominio
Poiché i controller di dominio fungono da server DNS, devono avere un indirizzo IP che non cambia. A questo scopo, configura gli indirizzi IP interni statici per le VM del controller di dominio.
Quando prenoti un indirizzo IP, il comportamento predefinito prevede che venga scelto automaticamente un indirizzo inutilizzato. Per assicurarti che gli indirizzi IP dei controller di dominio siano facili da memorizzare, prenota un indirizzo IP statico interno.
Sui controller di dominio, imposta l'indirizzo IP dell'adattatore di rete sullo stesso indirizzo. Sebbene questo passaggio sia facoltativo, impedisce ad Active Directory di emettere messaggi di avviso che indicano che l'indirizzo IP della macchina potrebbe essere ancora assegnato in modo dinamico.
Esegui il deployment dei controller di dominio su più zone
Per aumentare la disponibilità, esegui il deployment di almeno due controller di dominio e distribuiscili su più zone. Poiché subnet e indirizzi IP non sono collegati a una zona, puoi eseguire il deployment di tutti i controller di dominio in un'unica subnet.
Se prevedi di eseguire il deployment dei carichi di lavoro in più regioni, valuta la possibilità di eseguire il deployment dei controller di dominio in ogni regione pertinente. Poiché le subnet sono una risorsa a livello di regione, il deployment in una regione aggiuntiva richiederà una subnet aggiuntiva.
Crea un sito per regione
Quando un client tenta di individuare un controller di dominio, cercherà prima nel sito di Active Directory un controller di dominio che corrisponda all'indirizzo IP del client. Se nessun controller di dominio è disponibile in questo sito, il client procederà e tenterà di individuare un controller di dominio in un altro sito.
Puoi sfruttare questo comportamento creando un sito separato per ogni regione in cui esegui il deployment di controller di dominio o client di dominio. I client preferiranno automaticamente l'utilizzo di controller di dominio situati nella stessa regione, il che può contribuire a ridurre la latenza e i costi del trasferimento di dati in uscita tra le regioni.
Se disponi di client in regioni che non dispongono di un controller di dominio, puoi influire sui controller di dominio scelti da questi client modificando i costi di collegamento dei siti in modo che riflettano la vicinanza geografica delle regioni e attivando l'impostazione Prova il sito successivo più vicino.
L'utilizzo di più siti influisce sul comportamento di replica tra controller di dominio. Uno svantaggio dell'utilizzo di più siti può essere che la replica tra siti avviene meno frequentemente rispetto alla replica tra siti.
Tuttavia, non puoi creare siti di Active Directory in Microsoft AD gestito perché Microsoft Active Directory gestito non supporta la funzionalità Siti e servizi di Active Directory.
Usa le zone di forwarding privato di Cloud DNS
Quando crei una nuova istanza VM in Compute Engine, il sistema operativo verrà preconfigurato per l'utilizzo di un server DNS predefinito che fornisce accesso al DNS interno e al DNS pubblico.
Prima di poter aggiungere una macchina a un dominio Active Directory, devi assicurarti che la macchina sia in grado di risolvere i record DNS gestiti da Active Directory. Il server DNS predefinito configurato da Compute Engine per un'istanza VM fornisce accesso al DNS interno e al DNS pubblico, ma non sarà in grado di risolvere i nomi DNS gestiti da Active Directory.
Crea una zona di forwarding DNS privata in Cloud DNS per consentire ai client di risolvere i record DNS gestiti da Active Directory. Configura la zona per inoltrare le query corrispondenti al tuo dominio Active Directory ai controller di dominio.
L'utilizzo di una zona di forwarding DNS privata offre diversi vantaggi rispetto alla configurazione dei client per l'utilizzo diretto dei controller di dominio Active Directory come server DNS:
Non è necessario modificare la configurazione di rete delle istanze VM. Questo semplifica il processo di creazione di nuove VM.
Quando promuovi o fai retrocedere un controller di dominio, devi solo aggiornare la configurazione della zona di forwarding DNS privata e non devi modificare le impostazioni del client.
Le istanze VM hanno ancora accesso al DNS interno.
Tutti i record DNS che non corrispondono al tuo dominio Active Directory verranno gestiti da Cloud DNS, riducendo il carico sui controller di dominio.
Se utilizzi più domini, crea una zona di forwarding DNS privata separata per ogni dominio Active Directory.
Le zone di forwarding private di Cloud DNS hanno come ambito un singolo VPC. Se utilizzi più VPC connessi tramite peering, puoi esporre le zone di forwarding private ad altri VPC configurando il peering DNS.
Devi comunque configurare manualmente le impostazioni DNS sui controller di dominio. Utilizza 127.0.0.1 come server DNS principale e, facoltativamente, utilizza l'indirizzo IP di un altro controller di dominio come server DNS secondario. Per ulteriori informazioni, consulta Impostazioni DNS consigliate e opzioni alternative.
Connettività ibrida
La seguente sezione descrive in dettaglio le best practice relative alla connettività ibrida.
Utilizza l'inoltro in entrata DNS per risolvere i nomi DNS di Google Cloud dall'ambiente on-premise
I client nella tua rete on-premise potrebbero dover essere in grado di risolvere i nomi DNS delle risorse di cui è stato eseguito il deployment su Google Cloud. Se estendi la tua foresta o esegui il deployment di una foresta di risorse su Google Cloud, utilizza l'inoltro in entrata DNS per consentire ai client on-premise di cercare i record DNS per le risorse di cui è stato eseguito il deployment su Google Cloud. Per utilizzare l'inoltro in entrata, crea un criterio del server DNS per allocare un indirizzo IP del forwarding in entrata e rendi questo indirizzo accessibile alla rete on-premise.
Se il dominio DNS utilizzato su Google Cloud (ad esempio cloud.example.com) è un sottodominio del dominio DNS utilizzato on-premise (ad esempio example.com), configura la delega DNS. Crea un record NS nel dominio on-premise che punti all'indirizzo IP del forwarding in entrata. A causa del record NS, i client che tentano di cercare un nome DNS nel dominio ospitato da Google Cloud vengono reindirizzati all'indirizzo IP del forwarding in entrata.
Se i domini DNS utilizzati su Google Cloud e nella tua Active Directory on-premise sono diversi (ad esempio, cloud.example.com e corp.example.com), configura l'inoltro DNS condizionale nei domini on-premise e utilizza l'indirizzo IP del forwarding in entrata come destinazione. Quando viene richiesto di risolvere un nome DNS nel dominio ospitato da Google Cloud, i controller di dominio on-premise inoltreranno la Quest all'indirizzo IP del forwarding in entrata.
Quando utilizzi l'inoltro del DNS in entrata, assicurati che i firewall siano configurati correttamente.
L'inoltro in entrata DNS non è necessario se estendi il dominio esistente ad Active Directory. In questo scenario, tutti i record DNS del dominio vengono replicati automaticamente in Google Cloud e nel tuo ambiente on-premise e resi disponibili per la ricerca in entrambi gli ambienti.
Utilizzare l'inoltro in uscita DNS per risolvere i nomi DNS on-premise da Google Cloud
I client in esecuzione su Google Cloud potrebbero dover essere in grado di risolvere i nomi delle risorse di cui è stato eseguito il deployment on-premise. Se estendi la foresta o esegui il deployment di una foresta di risorse su Google Cloud, crea una zona di forwarding privata in Cloud DNS per inoltrare le query DNS per i tuoi domini on-premise ai server DNS on-premise.
Quando utilizzi l'inoltro DNS in uscita, assicurati che i firewall siano configurati correttamente.
L'inoltro DNS in uscita non è necessario se estendi il dominio esistente ad Active Directory. In questo scenario, tutti i record DNS del dominio vengono replicati automaticamente in Google Cloud e nel tuo ambiente on-premise e resi disponibili per la ricerca in entrambi gli ambienti.
Utilizzare i tunnel VPN per proteggere il traffico LDAP
Active Directory fa un uso ampio del protocollo LDAP. A differenza della maggior parte degli altri protocolli utilizzati da Active Directory, per impostazione predefinita il protocollo LDAP non è criptato.
Google Cloud garantisce che il traffico tra macchine virtuali sia criptato, perciò è accettabile l'utilizzo di LDAP non criptato all'interno del VPC. Se connetti il tuo VPC a una rete on-premise, assicurati che il traffico LDAP venga scambiato solo su canali attendibili.
Se utilizzi Cloud VPN per connettere Google Cloud e la tua rete on-premise, il traffico viene automaticamente criptato tramite IPSec tra Google Cloud e il tuo endpoint VPN on-premise.
Cloud Interconnect e Partner Interconnect non forniscono la crittografia. Per garantire una comunicazione sicura, stabilisci un tunnel VPN sulla connessione Interconnect utilizzando un'appliance VPN da Google Cloud Marketplace.
Utilizza l'autenticazione selettiva e AES per i trust nelle foreste
Quando crei una relazione di attendibilità tra foreste di Active Directory, preferisci i trust forest rispetto ai trust esterni e sfrutta le seguenti funzionalità per migliorare la sicurezza:
Abilita l'autenticazione selettiva sui trust in uscita nella foresta di risorse. L'autenticazione selettiva assicura che gli utenti della foresta organizzativa non possano accedere alle risorse nella foresta di risorse, a meno che non venga concessa esplicitamente l'autorizzazione.
Attiva l'applicazione forzata dei confini della foresta per la delega completa Kerberos sui trust in entrata nella foresta organizzativa. Questa funzionalità aiuta a prevenire gli attacchi di escalation dei privilegi impedendo alle risorse nella foresta di risorse di richiedere biglietti di concessione (TGT) agli utenti della foresta organizzativa.
Attiva l'opzione L'altro dominio supporta la crittografia AES Kerberos durante la creazione di trust. Questa opzione garantisce che i ticket vengano utilizzati per l'autenticazione tra foreste e che siano criptati utilizzando l'algoritmo AES anziché l'algoritmo RC4 meno sicuro.
Sicurezza
La seguente sezione descrive in dettaglio le best practice relative alla sicurezza.
Evitare che la sicurezza di Google Cloud interferisca con la sicurezza di Active Directory
Active Directory offre un controllo granulare sugli utenti autorizzati ad accedere a determinate risorse. Quando le macchine vengono distribuite come istanze VM in Compute Engine e gli utenti hanno accesso al progetto Google Cloud sottostante, devi considerare altri percorsi che potrebbero consentire a un utente di accedere a una macchina:
Un membro del progetto a cui è stato assegnato il ruolo Amministratore istanze Compute in un progetto Google Cloud può utilizzare la funzionalità di reimpostazione password per creare account amministratore locali. Gli account amministratore locale rappresentano una minaccia per la sicurezza del tuo dominio Active Directory in quanto possono essere utilizzati per minare i criteri di gruppo o per installare software dannoso in grado di acquisire le credenziali del dominio di altri utenti registrati.
Aggiungendo uno script di avvio, un membro del progetto con privilegi può inserire un codice dannoso in una VM che viene eseguita come
nt authority\systemal successivo riavvio della macchina.Utilizzando la console seriale, un membro del progetto con privilegi può anche accedere alla Console di amministrazione speciale (SAC) di Windows. Gli accessi tramite SAC vengono considerati da Windows come accessi locali. Di conseguenza, la SAC può essere utilizzata in modo improprio per eludere i criteri che negano gli accessi tramite RDP, ma non per negare gli accessi locali.
Un membro del progetto con privilegi può utilizzare la SAC per inviare un comando
crashdump, che può causare la scrittura di un dump della memoria su disco. Un tale dump della memoria potrebbe includere informazioni sensibili e credenziali.Montando il disco permanente su una VM diversa o utilizzando gli snapshot, un membro del progetto con privilegi potrebbe essere in grado di accedere ai contenuti del disco, inclusi potenzialmente i dump della memoria, da macchine a cui l'utente altrimenti non avrebbe l'autorizzazione per accedere.
Quando utilizzi Microsoft Active Directory gestito, hai una migliore protezione da questi percorsi di accesso aggiuntivi per impostazione predefinita. Il servizio non consente agli utenti con privilegi nel progetto di reimpostare la password dell'amministratore di dominio, eseguire script di avvio o accedere alla console seriale sulle VM del controller di dominio AD.
Per mitigare ulteriormente questi rischi, assicurati che le autorizzazioni IAM dei progetti che contengono istanze VM aggiunte al dominio siano gestite con privilegi minimi. Puoi ridurre ulteriormente il rischio da parte dell'utente dei criteri dell'organizzazione, dei criteri di gruppo e delle Shielded VM:
Utilizza un criterio dell'organizzazione per disattivare l'accesso alle porte seriali.
Applica un criterio di gruppo che impedisca la creazione di account amministratore locali disattivando il gestore dell'account. Definisci una preferenza File INI nel criterio di gruppo (Configurazione computer > Preferenze > Impostazioni di Windows > File Ini) per applicare la seguente impostazione:
- Azione: aggiornamento
- Percorso del file:
C:\Program Files\Google\Compute Engine\instance_configs.cfg - Nome sezione:
accountManager - Nome proprietà:
disable - Valore proprietà:
true
Applica un criterio di gruppo che rimuove qualsiasi account amministratore locale dalle istanze VM. Utilizza la funzionalità Utenti e gruppi locali (Configurazione computer > Preferenze > Impostazioni pannello di controllo > Utenti e gruppi locali) per rimuovere l'appartenenza ai gruppi dal gruppo Amministratori e da altri gruppi sensibili.
Prendi in considerazione l'utilizzo di Shielded VM insieme alla crittografia del disco BitLocker per evitare che disco permanente o gli snapshot siano leggibili da utenti non autorizzati.
Evitare interferenze tra la sicurezza di Active Directory e la sicurezza di Google Cloud
In un dominio Active Directory, le macchine considerano attendibili i controller di dominio per gestire l'autenticazione e l'autorizzazione per loro conto. A meno che non siano limitati dai criteri di gruppo, dai criteri di sicurezza locale di una macchina o dall'autenticazione selettiva, un utente che ha dimostrato la propria identità a uno dei controller di dominio può accedere a qualsiasi macchina nel dominio.
La possibilità per gli utenti di Active Directory di accedere a qualsiasi macchina potrebbe consentire agli utenti malintenzionati di eseguire movimenti laterali all'interno di un dominio. Questi movimenti laterali possono portare a un'escalation dei privilegi se alcune istanze VM sono esenti dalle restrizioni del firewall o utilizzano gli account di servizio Google Cloud: le credenziali di un account di servizio sono accessibili a tutti i processi e gli utenti su un'istanza VM. Qualsiasi utente che può utilizzare Active Directory per accedere a una macchina può quindi accedere a queste credenziali dell'account di servizio per accedere a qualsiasi risorsa Google Cloud a cui è concesso l'accesso all'account di servizio.
Durante la configurazione di Microsoft Active Directory gestito, il servizio crea un gruppo per consentire a utenti specifici di utilizzare RDP in VM aggiunte al dominio.
Per ridurre il rischio di spostamenti laterali, organizza gli utenti in livelli amministrativi e utilizza i criteri di gruppo Nega l'accesso a questo computer dalla rete e Nega l'accesso tramite Servizi desktop remoto per limitare l'accesso alle VM in base al livello del livello.
In una topologia a foresta di risorse, sfrutta ulteriormente l'autenticazione selettiva per limitare ulteriormente l'insieme di utenti di altre foreste a cui è consentito accedere alle tue VM. Puoi semplificare la gestione delle autorizzazioni di autenticazione selettive allineando le strutture delle risorse di Google Cloud e Active Directory. Se le unità organizzative di Active Directory sono mappate a progetti Google Cloud, puoi concedere agli utenti il diritto di eseguire l'autenticazione a un livello corrispondente a un progetto Google Cloud.
Nei casi in cui non siano applicabili criteri di gruppo o un'autenticazione selettiva, crea un account di servizio separato, esporta le chiavi dell'account di servizio, salvale sul disco locale dell'istanza VM o su una condivisione file e proteggili con un ACL NTFS in modo che solo gli utenti di Active Directory autorizzati possano leggere e utilizzare le chiavi.
Usa progetti dedicati per i controller di dominio
Il ruolo dei controller di dominio è fondamentale per la sicurezza di un dominio Active Directory e la compromissione di un singolo controller di dominio può compromettere l'intera foresta di Active Directory.
Per limitare il rischio di accessi non autorizzati, utilizza un progetto Google Cloud distinto per eseguire il deployment dei controller di dominio e concedere l'accesso a questo progetto con il privilegio minimo. Quando crei il progetto, tieni presente che alcune autorizzazioni potrebbero essere ereditate dalle cartelle principali. Per evitare di concedere inavvertitamente l'accesso tramite ereditarietà, valuta la possibilità di creare il progetto al di fuori della consueta gerarchia delle cartelle.
Quando configuri i criteri IAM per il progetto, presta particolare attenzione alla limitazione dell'accesso alle istanze VM, ai dischi permanenti che contengono il database ntds.dit e a tutte le posizioni di archiviazione che potrebbero contenere backup.
Oltre a utilizzare i criteri IAM per limitare l'accesso al progetto, proteggerlo dall'eliminazione accidentale.
Usa VM e progetti separati per la gestione di Active Directory
Per gestire Active Directory, devi poter utilizzare strumenti come Utenti e computer di Active Directory o il Centro di amministrazione di Active Directory. Questi strumenti richiedono l'accesso utilizzando un account di dominio con privilegi, il che rende la macchina su cui esegui questi strumenti un bersaglio allettante per il furto di credenziali o il keylogging.
Per ridurre al minimo il rischio che un utente malintenzionato ottenga credenziali di dominio con privilegi, utilizza istanze VM dedicate per l'amministrazione del dominio e gestisci queste VM di gestione come le workstation con accesso privilegiato:
Utilizza i criteri di gruppo per assicurarti che solo un sottoinsieme selezionato di utenti abbia il diritto di accedere alle VM di gestione. Se hai implementato l'amministrazione a più livelli, questo gruppo di utenti corrisponde al livello 0.
Analogamente ai controller di dominio, le VM amministrative possono essere esposte a rischi se i membri del progetto creano account amministratore locali, accedono tramite la console seriale o manomettono i dischi permanenti. Per limitare il rischio di accessi non autorizzati, utilizza un progetto Google Cloud distinto per le VM amministrative e concedi l'accesso a questo progetto secondo i privilegi minimi.
Se prevedi di accedere alle VM amministrative da una rete on-premise utilizzando la connettività ibrida, esegui il deployment delle VM amministrative in una subnet VPC dedicata. Una subnet dedicata alle VM di gestione consente di distinguere meglio tra le VM amministrative e le altre VM durante la configurazione dei firewall on-premise. Se utilizzi un VPC condiviso, utilizza le autorizzazioni a livello di subnet per garantire che solo gli amministratori con privilegi siano autorizzati a eseguire il deployment delle istanze VM nella subnet di gestione. Questa prassi aiuta a garantire che, se i firewall on-premise applicano regole diverse per le VM di gestione rispetto ad altre VM, gli utenti non possono eludere le regole firewall inserendo VM non di gestione nella subnet di gestione.
Inoltre, valuta la possibilità di limitare alla subnet di gestione il criterio di gruppo che gestisce le restrizioni di accesso per le VM di gestione. Questa pratica applica l'allineamento tra le limitazioni di accesso (basate su un criterio di gruppo) e le regole firewall (in base a subnet/indirizzo IP).
Oltre a utilizzare i criteri IAM per limitare l'accesso al progetto, proteggerlo dall'eliminazione accidentale.
Utilizza le regole firewall per proteggere i controller di dominio e i server
I controller di dominio espongono una serie di servizi, tra cui LDAP, DNS, Kerberos e RPC. A seconda dei casi d'uso, le VM di cui è stato eseguito il deployment su Google Cloud, così come le macchine in esecuzione on-premise, potrebbero aver bisogno di accedere a diversi sottoinsiemi di questi servizi per sfruttare Active Directory.
Quando si utilizza Managed Microsoft AD, il deployment dei controller di dominio AD viene eseguito in un progetto tenant dedicato. La rete che ospita i controller di dominio AD è protetta automaticamente con regole firewall specifiche per AD.
Per ridurre la superficie di attacco dei controller di dominio e delle tue VM, utilizza i firewall per non consentire le comunicazioni di rete non strettamente necessarie. Per i dettagli sulle configurazioni dei firewall necessarie per accedere ad Active Directory dall'interno del tuo VPC o dalle reti on-premise, consulta la nostra guida sull'utilizzo di Active Directory tra diversi firewall.
Organizza le risorse e gli utenti di Active Directory in livelli amministrativi
Alcune macchine in una foresta di Active Directory sono più critiche per la sicurezza complessiva di Active Directory rispetto ad altre. I controller di dominio e le VM amministrative sono due esempi di macchine particolarmente critiche e quindi particolarmente sensibili a potenziali attacchi.
Per identificare la criticità di ciascuna delle tue macchine, utilizza una tassonomia dei livelli. Il numero giusto di livelli dipende dalla configurazione specifica, ma puoi iniziare decidendo tra tre livelli:
Livello 0 (altamente critico): questo livello include tutte le macchine fondamentali per la sicurezza della foresta di Active Directory. Una volta compromessa una singola macchina di livello 0, devi presumere che l'intera foresta sia compromessa.
Livello 1 (critico): questo livello include la maggior parte dei server nel tuo ambiente, tra cui i server delle applicazioni e i server di database. Un server di livello 1 compromesso potrebbe avere un impatto sostanziale sull'attività, ma non rappresenta una minaccia immediata per l'intera foresta.
Livello 2 (normale): questo livello include workstation o altre macchine per uso generico. Si prevede che una compromissione di una macchina di livello 2 avrà un impatto limitato sull'attività e sulla sicurezza in generale.
Sebbene l'impatto immediato di una macchina di livello 2 compromessa possa sembrare limitato, esiste il rischio di effetti a effetto: quando un utente che ha accesso amministrativo a macchine di livello 0 o 1 viene attirato ad accedere a una macchina di livello 2 compromessa, potrebbe cadere vittima di un keylogger o di altre forme di furto di credenziali. Le credenziali acquisite potrebbero quindi essere utilizzate per attaccare macchine di livello superiore, causando un'escalation dell'impatto complessivo.
Per evitare questo tipo di effetti, assicurati di classificare non solo le macchine, ma anche gli account utente, e vincola l'insieme di macchine a cui questi utenti hanno accesso:
Livello 0 (molto critico): utenti che hanno accesso a macchine di livello 0.
Livello 1 (critico): utenti che hanno accesso alle macchine di livello 1.
Tier 2 (normale): utenti che hanno accesso alle macchine di livello 2.
Utilizza la seguente tabella come linea guida per determinare quali utenti devono avere accesso a determinate risorse:
| Gruppo | Livello | Accesso al dominio | Accesso computer di livello 0 | Accesso ai computer di livello 1 | Accesso ai computer di livello 2 |
|---|---|---|---|---|---|
| Amministratori di Active Directory | 0 | Amministratore | Utente con limitazioni | Bloccata | Bloccata |
| Amministratori del server di gestione | 0 | Utente con limitazioni | Amministratore | Bloccata | Bloccata |
| Amministratori del server | 1 | Utente con limitazioni | Bloccata | Amministratore | Bloccata |
| Amministratori workstation VDI | 2 | Utente con limitazioni | Bloccata | Bloccata | Amministratore |
| Utenti di workstation VDI | 2 | Utente con limitazioni | Bloccata | Bloccata | Utente con limitazioni |
Per ulteriori dettagli e best practice sull'implementazione di un modello di livello amministrativo in Active Directory, consulta la documentazione di Microsoft.
Quando utilizzi il modello di livello amministrativo nella foresta di Active Directory, assicurati che l'integrità del modello non sia compromessa da relazioni di attendibilità della foresta. Se la foresta attendibile applica anche un modello di amministrazione a più livelli, utilizza l'autenticazione selettiva per assicurarti che gli utenti della foresta attendibile possano accedere solo alle risorse dello stesso livello:
Se la foresta attendibile non implementa l'amministrazione a livelli, mappa la foresta attendibile a un determinato livello e utilizza l'autenticazione selettiva per assicurarti che gli utenti della foresta attendibile siano autorizzati ad accedere solo alle risorse di quel livello specifico.
Utilizzo dei Controlli di servizio VPC e dell'accesso privato Google per gli host on-premise
Le API Microsoft AD gestite consentono di reimpostare la password di amministratore e di eseguire altre operazioni sensibili. Per i deployment di produzione critici, consigliamo di abilitare i Controlli di servizio VPC e di utilizzare l'accesso privato Google per gli host on-premise al fine di aumentare la sicurezza.
Gestione
La seguente sezione descrive in dettaglio le best practice per la gestione di Active Directory.
Allinea le strutture di risorse di Google Cloud e Active Directory
Quando esegui il deployment di un nuovo dominio o foresta di Active Directory su Google Cloud, devi definire una struttura di unità organizzative (UO) per organizzare le risorse con il tuo dominio Active Directory. Anziché progettare una struttura completamente nuova o applicare la struttura che utilizzi nel tuo ambiente on-premise, crea una struttura di UO in linea con la gerarchia delle risorse di Google Cloud:
Se utilizzi un modello di amministrazione a livelli, le UO di primo livello devono riflettere i livelli amministrativi.
Per ogni livello, crea delle UO per gli utenti e i gruppi. Se prevedi di gestire un numero elevato di utenti e gruppi, crea delle UO secondarie in base alle tue esigenze.
Per ogni livello, crea un'UO
Projectse crea delle UO secondarie per ogni progetto Google Cloud che contiene risorse Active Directory. Utilizza l'UO secondaria specifica del progetto per gestire account computer, account di servizio o altre risorse di Active Directory che corrispondono alle risorse Google Cloud del rispettivo progetto. Accertati che esista un mapping 1:1 tra UO e progetti.
Il seguente diagramma mostra una gerarchia di esempio che segue questi principi:
Se il numero di progetti che contengono risorse Active Directory è moderato, puoi creare una struttura di UO fissa sotto l'UO Projects. Se prevedi di gestire un numero elevato di progetti e hai progettato la gerarchia delle risorse Google Cloud in modo da utilizzare più livelli di cartelle, valuta la possibilità di riflettere questa struttura di cartelle sotto l'UO Projects.
L'allineamento della struttura di UO di Active Directory e della gerarchia delle risorse di Google Cloud offre diversi vantaggi:
Quando deleghi le autorizzazioni amministrative a un progetto Google Cloud utilizzando i criteri IAM, potresti anche dover concedere agli utenti del progetto determinati privilegi in Active Directory. Ad esempio, gli amministratori di Compute Engine potrebbero dover essere in grado di aggiungere le macchine al dominio in una determinata UO. L'allineamento di UO e progetti Google Cloud consente di concedere queste autorizzazioni allo stesso livello di granularità in Active Directory e in Google Cloud.
Se prevedi di utilizzare oggetti dei criteri di gruppo (GPO) per gestire i computer, una struttura di UO che riflette la gerarchia delle risorse di Google Cloud ti aiuta a garantire che i GPO vengano applicati in modo coerente a tutte le VM di un determinato progetto o cartella.
Se utilizzi un trust tra foreste con autenticazione condizionale, puoi utilizzare le UO corrispondenti ai progetti Google Cloud per concedere l'autorizzazione Autorizzata per l'autenticazione in base al singolo progetto.
Quando elimini un progetto in Google Cloud, puoi semplicemente eliminare l'UO associata, riducendo il rischio di lasciare risorse obsolete nella directory.
Se ritieni che la tua struttura di UO debba deviare dalla struttura del progetto, questo potrebbe indicare che la struttura del tuo progetto è troppo granulare o troppo granulare.
Utilizza i server di riferimento dell'ora di Google
L'autenticazione Kerberos si basa sugli indicatori orari come parte del protocollo. Affinché l'autenticazione abbia esito positivo, gli orologi della macchina client e server devono sincronizzarsi entro un determinato margine. Per impostazione predefinita, Active Directory non consente più di 5 minuti di differenza.
In un ambiente Active Directory on-premise, di seguito è riportata la configurazione predefinita per il tempo di sincronizzazione:
- I computer aggiunti a un dominio sincronizzano il proprio orario con un controller di dominio.
- I controller di dominio sincronizzano il proprio orario con l'emulatore PDC del proprio dominio.
- Gli emulatori PDC di tutti i domini sincronizzano l'ora con l'emulatore PDC del dominio principale della foresta.
In questa configurazione, l'emulatore PDC del dominio principale della foresta è l'ultima fonte di tempo per Active Directory ed è comune configurare questa macchina in modo che utilizzi un server NTP esterno come origine dell'ora.
In Compute Engine, la configurazione predefinita per le VM Windows prevede l'utilizzo del server metadati (metadata.google.internal) come server NTP, che a sua volta si basa sui server NTP di Google per ottenere l'orario corretto. L'aggiunta di una VM a un dominio Active Directory non modifica questa configurazione predefinita.
Mantieni la configurazione predefinita di Compute Engine, a meno che non sia stato eseguito il deployment dell'emulatore PDC del dominio principale della foresta.
Se il deployment dell'emulatore PDC è stato eseguito al di fuori di Google Cloud, configuralo in modo che utilizzi time.google.com come origine NTP.
In alternativa, puoi ripristinare il comportamento predefinito di Active Directory relativo alla sincronizzazione del tempo con l'emulatore PDC riconfigurando le VM di Compute Engine in modo che utilizzino l'origine NTP DOMHIER e configurando le regole del firewall per consentire il traffico NTP in entrata (UDP/123) verso i controller di dominio.
Consolida e monitora gli audit log
Quando esegui il deployment di Active Directory su Google Cloud, la sicurezza della tua foresta di Active Directory e dei tuoi progetti Google Cloud è collegata a un'altra: le attività sospette in Active Directory e Windows potrebbero mettere in pericolo la sicurezza di altre risorse nello stesso modo delle attività sospette in Google Cloud potrebbero mettere a rischio Active Directory.
Audit log coerenti sono uno strumento importante per identificare tempestivamente minacce o errori di configurazione e consentirti di ricostruire ed esaminare l'attività passata. L'audit logging di Cloud consente di acquisire e analizzare i log delle attività di amministrazione e i log degli accessi ai dati. Allo stesso modo, puoi utilizzare il logging delle regole firewall e i log di flusso VPC per analizzare il traffico di rete. Tuttavia, questi servizi della piattaforma non sono a conoscenza di eventi relativi alla sicurezza che si verificano in Active Directory. Per stabilire un audit trail coerente che copra sia gli eventi di controllo relativi alla piattaforma sia gli eventi di controllo relativi ad Active Directory, installa l'agente Cloud Logging sui controller di dominio e sulle macchine aggiunte al dominio per esportare i log degli eventi di sicurezza di Windows in Cloud Logging.
Per impostazione predefinita, il log degli eventi di sicurezza di Windows potrebbe non acquisire tutti gli eventi necessari ai fini del controllo. Fai riferimento ai suggerimenti di Microsoft sulla configurazione dei criteri di controllo e sul monitoraggio di Active Directory per rilevare eventuali segni di compromissione per assicurarti di acquisire tutti gli eventi di controllo pertinenti.
Quando si lavora a un grande volume di eventi, è facile sfuggire agli eventi critici. Per evitare di perdere eventi critici, crea metriche basate su log per eventi che potrebbero essere particolarmente critici o sospetti e valuta la possibilità di configurare avvisi per ricevere una notifica quando la frequenza di eventi cambia o supera le soglie accettabili.
Passaggi successivi
Scopri quale pattern per l'utilizzo di Active Directory in un ambiente ibrido più adatto alla tua situazione.
Scopri come configurare Active Directory per l'aggiunta automatica delle VM a un dominio.
Prova le altre funzionalità di Google Cloud. Guarda i nostri tutorial.