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 su Google Cloud. La guida è complementare alle best practice generali per la protezione di Active Directory pubblicate da Microsoft.
Architettura
Le sezioni seguenti descrivono in dettaglio le best practice relative all'architettura.
Utilizza il pattern di architettura più adatto ai tuoi requisiti
Per eseguire il deployment di Active Directory su Google Cloud, devi prima decidere quale dominio e quale architettura di foresta utilizzare. Se utilizzi già Active Directory, devi anche decidere se e come integrare i due ambienti.
La scelta del design più adatto alla tua situazione dipende da una serie di fattori, tra cui la progettazione della rete on-premise, il modo in cui le risorse on-premise e Google Cloud interagiranno, nonché i requisiti di disponibilità e autonomia amministrativa. Consulta i nostri pattern per l'utilizzo di Active Directory in un ambiente ibrido per capire in che modo questi fattori devono determinare il tuo design.
Se vuoi mantenere un confine di attendibilità tra Google Cloud e il tuo ambiente on-premise, ti consigliamo di implementare il pattern foresta di risorse. In questo pattern, esegui il deployment di un forest separato su Google Cloud e utilizzi una relazione di attendibilità tra foreste unidirezionale per integrare la foresta Google Cloud con la foresta Active Directory on-premise esistente.
Separare i test dalla produzione
A seconda dell'utilizzo di Active Directory, potrebbe essere necessario apportare modifiche frequenti in Active Directory durante lo sviluppo e il test delle applicazioni. Gli sviluppatori potrebbero dover essere in grado di creare e modificare account Active Directory, modificare le iscrizioni ai gruppi se le applicazioni utilizzano i gruppi per gestire l'autorizzazione oppure partecipare e rimuovere computer.
Per evitare che le attività di sviluppo e test influiscano sui carichi di lavoro di produzione o compromettano la sicurezza del deployment, ti consigliamo di eseguire il deployment di un dominio o di una foresta Active Directory separata per lo sviluppo e i test.
Avere un dominio o una foresta di sviluppo e test separati ti consente inoltre di verificare le modifiche amministrative prima di applicarle in produzione. Alcuni esempi di queste modifiche includono esperimenti con i criteri di gruppo, test di script di automazione o azioni potenzialmente rischiose come l'aumento del livello funzionale di una foresta.
Configurare la federazione di Cloud Identity oltre a eseguire il 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, di consentire agli utenti di accedere alle VM Windows utilizzando i loro account utente esistenti e di supportare le 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 autenticarti con un'identità Google. Pertanto, il deployment di Active Directory su Google Cloud non sostituisce la federazione di 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 con Active Directory on-premise, come illustrato nel seguente diagramma. Gli utenti con account in Active Directory on-premise possono quindi utilizzare gli strumenti che richiedono un'identità Google, nonché le tue applicazioni che si basano su Active Directory per l'autenticazione.
Se invece decidi di estendere la tua foresta o il tuo dominio esistente a Google Cloud, hai anche la possibilità di utilizzare i domain controller e i server AD FS di cui è stato eseguito il deployment su Google Cloud per configurare la federazione.
La federazione ti consente inoltre di applicare un ciclo di vita comune per gli account Google e Active Directory, in modo che quando disattivi un account utente in Active Directory on-premise, venga sospeso anche l'utente Google corrispondente.
Networking
La sezione seguente illustra le best practice relative al networking.
Esegui il 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:
Ogni applicazione che potrebbe richiedere l'accesso ad Active Directory può essere potenzialmente eseguita in un progetto separato. L'utilizzo di progetti separati consente di isolare le risorse e di gestire l'accesso singolarmente.
Puoi utilizzare un progetto dedicato per i controller di dominio Active Directory, che ti consente di avere un controllo granulare su quali utenti possono accedere alle risorse Google Cloud correlate.
Le reti VPC condiviso ti consentono di centralizzare la gestione degli indirizzi IP e la configurazione della 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 eseguire ulteriori passaggi per assicurarti che l'attivazione di Windows e gli aggiornamenti di Windows non siano 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. In questo modo, l'attivazione può avvenire senza accesso diretto a internet.
Esistono diverse opzioni per supportare gli aggiornamenti di Windows:
Se hai 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 attivare l'accesso a internet tramite un gateway NAT di cui hai eseguito il deployment con Cloud NAT.
Se hai configurato la connettività ibrida, puoi anche instradare il traffico in uscita tramite un gateway NAT o un server proxy on-premise.
Prenotare in anticipo gli indirizzi IP statici per i controller di dominio
Poiché i controller di dominio fungono da server DNS, devono essere assegnati un indirizzo IP che non cambia. Per farlo, configura indirizzi IP interni statici per le VM del controller di dominio.
Quando prenoti un indirizzo IP, il comportamento predefinito è che viene scelto automaticamente un indirizzo non utilizzato. Per assicurarti che gli indirizzi IP dei controller di dominio siano facili da memorizzare, prenota un indirizzo IP interno statico.
Sui controller di dominio, imposta l'indirizzo IP dell'adattatore di rete sullo stesso indirizzo. Anche se questo passaggio è facoltativo, impedisce ad Active Directory di emettere messaggi di avviso che indicano che l'indirizzo IP del computer potrebbe essere ancora assegnato in modo dinamico.
Esegui il deployment dei controller di dominio in più zone
Per aumentare la disponibilità, esegui il deployment di almeno due controller di dominio e distribuiscili su più zone. Poiché le subnet e gli indirizzi IP non sono legati a una zona, puoi implementare tutti i domain controller in un'unica subnet.
Se prevedi di eseguire il deployment dei carichi di lavoro in più regioni, valuta la possibilità di implementare i controller di dominio in ogni regione pertinente. Poiché le subnet sono una risorsa regionale, il deployment in un'altra regione richiederà una subnet aggiuntiva.
Crea un sito per regione
Quando un client tenta di individuare un controller di dominio, prima cerca un controller di dominio nel sito Active Directory corrispondente all'indirizzo IP del client. Se non è disponibile alcun controller di dominio in questo sito, il client procederà e tenterà di localizzarne uno 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 daranno quindi la preferenza all'utilizzo automatico dei controller di dominio situati nella stessa regione, il che può contribuire a ridurre la latenza e il costo del trasferimento dei dati in uscita tra le regioni.
Se hai clienti in regioni in cui non è presente un controller di dominio, puoi influenzare i controller di dominio scelti da questi clienti modificando i costi dei link ai siti in modo che riflettano la vicinanza geografica delle regioni e attivando l'impostazione Prova il sito più vicino successivo.
L'utilizzo di più siti influisce sul comportamento della replica tra i domain controller. Uno svantaggio dell'utilizzo di più siti può essere che la replica tra siti avviene meno di frequente rispetto alla replica all'interno del sito.
Tuttavia, non puoi creare siti Active Directory in Microsoft AD gestito perché quest'ultimo non supporta la funzionalità Siti e servizi Active Directory.
Utilizzare le zone di inoltro private di Cloud DNS
Quando crei una nuova istanza VM in Compute Engine, il sistema operativo viene preconfigurato per utilizzare un server DNS predefinito che fornisce l'accesso al DNS interno e al DNS pubblico.
Prima di poter aggiungere un computer a un dominio Active Directory, devi assicurarti che il computer 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 inoltro 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 tuoi controller di dominio.
L'utilizzo di una zona di inoltro DNS privata offre diversi vantaggi rispetto alla configurazione dei client in modo che utilizzino direttamente i tuoi domain controller Active Directory come server DNS:
Non è necessario modificare la configurazione di rete delle istanze VM. Questo simplifica la procedura di creazione di nuove VM.
Quando promuovi o demozioni un controller di dominio, devi solo aggiornare la configurazione della zona di inoltro DNS privato 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 inoltro DNS privata separata per ogni dominio Active Directory.
Le zone di inoltro private Cloud DNS hanno come ambito un singolo VPC. Se utilizzi più VPC connesse tramite peering, puoi esporre le zone di inoltro privato 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, l'indirizzo IP di un altro
domain controller come server DNS secondario. Per ulteriori informazioni, consulta
Impostazioni DNS consigliate e opzioni alternative.
Connettività ibrida
La sezione seguente illustra le best practice relative alla connettività ibrida.
Utilizza il forwarding DNS in entrata per risolvere i nomi DNS di Google Cloud dall'on-premise
I client della 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 espandi la foresta o esegui il deployment di una foresta di risorse su Google Cloud, utilizza il forwarding 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 il forwarding in entrata, crea un criterio del server DNS per allocare un indirizzo IP del forwarder in entrata e rendilo 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 forwarder in entrata. Il record NS fa sì che i client che tentano di cercare un nome DNS nel dominio ospitato su Google Cloud vengano reindirizzati all'indirizzo IP del forwarder in entrata.
Se i domini DNS utilizzati su Google Cloud e nel tuo Active Directory on-premise sono diversi (ad esempio cloud.example.com e
corp.example.com), configura il forwarding DNS condizionale nei tuoi
domini on-premise e utilizza l'indirizzo IP del forwarder in entrata come destinazione. Quando viene richiesto di risolvere un nome DNS nel dominio ospitato su Google Cloud, i controller di dominio on-premise inoltrano la richiesta all'indirizzo IP del forwarder in entrata.
Quando utilizzi il reindirizzamento DNS in entrata, assicurati che i firewall siano configurati adeguatamente.
L'inoltro in entrata DNS non è necessario se estendi il tuo dominio esistente ad Active Directory. In questo scenario, tutti i record DNS del dominio vengono replicati automaticamente su Google Cloud e nel tuo ambiente on-premise e resi disponibili per la ricerca in entrambi gli ambienti.
Utilizzare il forwarding DNS in uscita 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 espandi la foresta o implementi una foresta di risorse su Google Cloud, crea una zona di inoltro privata in Cloud DNS per inoltrare le query DNS per i tuoi domini on-premise ai tuoi server DNS on-premise.
Quando utilizzi l'inoltro DNS in uscita, assicurati che i firewall siano configurati in modo appropriato.
L'inoltro DNS in uscita non è necessario se estendi il tuo dominio esistente ad Active Directory. In questo scenario, tutti i record DNS del dominio vengono replicati automaticamente su 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 intensivo del protocollo LDAP. A differenza della maggior parte degli altri protocolli utilizzati da Active Directory, LDAP non è criptato per impostazione predefinita.
Google Cloud garantisce che il traffico tra le macchine virtuali sia criptato, pertanto l'utilizzo di LDAP non criptato all'interno della VPC è accettabile. Se colleghi la tua VPC a una rete on-premise, assicurati che il traffico LDAP venga scambiato solo tramite canali attendibili.
Se utilizzi Cloud VPN per connettere Google Cloud e la tua rete on-premise, il traffico viene criptato automaticamente utilizzando IPSec tra Google Cloud e l'endpoint VPN on-premise.
Cloud Interconnect e Partner Interconnect non forniscono la crittografia. Per garantire comunicazioni sicure, stabilisci un tunnel VPN sulla connessione Interconnect utilizzando un'appliance VPN disponibile su Google Cloud Marketplace.
Utilizzare l'autenticazione selettiva e AES per le attendibilità del dominio
Quando crei una relazione di attendibilità tra le foreste di Active Directory, preferisci le attendibilità tra foreste rispetto a quelle esterne e sfrutta le seguenti funzionalità per migliorare la sicurezza:
Attiva l'autenticazione selettiva per le relazioni di attendibilità in uscita nella foresta di risorse. L'autenticazione selettiva garantisce che gli utenti della foresta dell'organizzazione non possano accedere alle risorse della foresta delle risorse, a meno che non venga concessa l'autorizzazione esplicita.
Attiva l'applicazione per il confine del forest per la delega completa di Kerberos per i trust in entrata nel forest dell'organizzazione. Questa funzionalità aiuta a prevenire gli attacchi di escalation dei privilegi impedendo alle risorse nella foresta di risorse di richiedere TGT (Ticket Granting Ticket) agli utenti della foresta dell'organizzazione.
Attiva l'opzione L'altro dominio supporta la crittografia AES Kerberos quando crei le attendibilità. Questa opzione garantisce che i token utilizzati per l'autenticazione tra foreste vengano criptati utilizzando AES anziché l'algoritmo RC4 meno sicuro.
Sicurezza
La sezione seguente illustra le best practice relative alla sicurezza.
Evitare che la sicurezza di Google Cloud interferisca con la sicurezza di Active Directory
Active Directory ti offre un controllo granulare sugli utenti autorizzati a accedere alle risorse. Quando le macchine vengono implementate come istanze VM in Compute Engine e gli utenti hanno accesso al progetto Google Cloud di base, devi prendere in considerazione percorsi aggiuntivi che potrebbero consentire a un utente di accedere a una macchina:
Un membro di un progetto a cui è stato assegnato il ruolo Amministratore delle istanze Compute in un progetto Google Cloud può utilizzare la funzionalità di reimpostazione della password per creare account amministratore locale. Gli account amministrativo 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 che potrebbe acquisire le credenziali di dominio di altri utenti che hanno eseguito l'accesso.
Aggiungendo uno script di avvio, un membro del progetto con privilegi può iniettare 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. Windows considera gli accessi tramite il SAC come accessi locali. Pertanto, il SAC può essere usato impropriamente per eludere i criteri che negano gli accessi tramite RDP, ma non quelli locali.
Un membro del progetto con privilegi può utilizzare il SAC per emettere un comando
crashdump, che può causare la scrittura di un dump della memoria sul disco. Un dump della memoria di questo tipo potrebbe includere informazioni e credenziali sensibili.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, potenzialmente inclusi i dump della memoria, da macchine a cui l'utente non avrebbe altrimenti l'autorizzazione per accedere.
Quando utilizzi Microsoft AD gestito, per impostazione predefinita sei più protetto da questi percorsi di accesso aggiuntivi. Il servizio non consente agli utenti con privilegi nel tuo 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 ridurre ulteriormente questi rischi, assicurati che le autorizzazioni IAM dei progetti contenenti istanze VM aggiunte al dominio siano gestite in base al principio del privilegio minimo. Puoi ridurre ulteriormente il rischio da parte dell'utente dei criteri dell'organizzazione, dei criteri del gruppo e delle VM schermate:
Utilizza un criterio dell'organizzazione per disattivare l'accesso alla porta seriale.
Applica un criterio di gruppo che impedisca la creazione di account amministratore locale disattivando l'account manager. Definisci una preferenza per i 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 della proprietà:
true
Applica un criterio di gruppo che rimuove gli account amministratore locale dalle istanze VM. Utilizza la funzionalità Utenti e gruppi locali (Configurazione computer > Preferenze > Impostazioni del Pannello di controllo > Utenti e gruppi locali) per rimuovere l'appartenenza al gruppo Amministratori e ad altri gruppi sensibili.
Valuta la possibilità di utilizzare le VM isolate in combinazione con la crittografia dei dischi BitLocker per evitare che disco permanente o gli snapshot siano leggibili da utenti non autorizzati.
Evitare che la sicurezza di Active Directory interferisca con la sicurezza di Google Cloud
In un dominio Active Directory, le macchine ritengono attendibili i controller di dominio per gestire l'autenticazione e l'autorizzazione per loro conto. A meno che non sia limitato dai criteri del gruppo, dai criteri di sicurezza locali di un computer o dall'autenticazione selettiva, un utente che ha dimostrato la propria identità a uno dei controller di dominio è autorizzato ad accedere a qualsiasi computer del dominio.
La possibilità per gli utenti di Active Directory di accedere a qualsiasi computer potrebbe consentire agli autori di attacchi di eseguire movimenti laterali all'interno di un dominio. Questi movimenti laterali possono portare a riassegnazioni di privilegi se alcune istanze VM sono esenti dalle restrizioni del firewall o utilizzano account di servizio Google Cloud: le credenziali di un account di servizio sono accessibili a tutti i processi e gli utenti di un'istanza VM. Pertanto, qualsiasi utente che può utilizzare Active Directory per accedere a un computer può accedere a queste credenziali dell'account di servizio per ottenere l'accesso a qualsiasi risorsa Google Cloud a cui è concesso l'accesso all'account di servizio.
Quando configuri AD Microsoft gestito, il servizio crea un gruppo per facilitare la concessione a utenti specifici della possibilità di accedere tramite RDP alle VM aggiunte al dominio.
Per ridurre il rischio di movimenti 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.
In una topologia di foresta di risorse, sfrutta ulteriormente la autenticazione selettiva per limitare ulteriormente l'insieme di utenti di altre foreste autorizzati ad accedere alle VM. Puoi semplificare la gestione delle autorizzazioni di autenticazione selettiva allineando le strutture delle risorse di Google Cloud e Active Directory: se le unità organizzative di Active Directory sono mappate ai progetti Google Cloud, puoi grant agli utenti il diritto di autenticarsi a un livello corrispondente a un progetto Google Cloud.
Nei casi in cui non siano applicabili né l'autenticazione selettiva né i criteri di gruppo, crea un account di servizio separato, esporta le chiavi dell'account di servizio, salvale sul disco locale dell'istanza VM o in una condivisione file e proteggile utilizzando un ACL NTFS in modo che solo gli utenti di Active Directory autorizzati possano leggere e utilizzare le chiavi.
Utilizza progetti dedicati per i controller di dominio
I controller di dominio svolgono un ruolo fondamentale nella sicurezza di un dominio Active Directory e la compromissione di un singolo controller di dominio può comportare la compromissione dell'intera foresta di Active Directory.
Per limitare il rischio di accesso non autorizzato, utilizza un progetto Google Cloud distinto per eseguire il deployment dei controller di dominio e concedi l'accesso a questo progetto in base al principio del 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 l'eredità, ti consigliamo di creare il progetto al di fuori della normale gerarchia di cartelle.
Quando configuri i criteri IAM per il progetto, presta particolare attenzione a limitare l'accesso alle istanze VM, ai dischi permanenti che contengono il database ntds.dit, nonché a eventuali posizioni di archiviazione che potrebbero contenere i backup.
Oltre a utilizzare i criteri IAM per limitare l'accesso al progetto, proteggi il progetto dall'eliminazione accidentale.
Utilizza VM e progetti separati per la gestione di Active Directory
Per gestire Active Directory, devi essere in grado di utilizzare strumenti come Utenti e computer di Active Directory o il Centro amministrativo di Active Directory. Questi strumenti richiedono di accedere utilizzando un account di dominio con privilegi, il che rende la macchina su cui esegui questi strumenti un target interessante per il furto di credenziali o il keylogging.
Per ridurre al minimo il rischio che un malintenzionato ottenga le credenziali di dominio con privilegi, utilizza istanze VM dedicate per l'amministrazione del dominio e gestisci queste VM di gestione come 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 messe a rischio se i membri del progetto creano account amministratore locale, accedono tramite la console seriale o manomettono i dischi permanenti. Per limitare il rischio di accessi non autorizzati, utilizza un progetto Google Cloud separato per le VM amministrative e concedi l'accesso a questo progetto in base al principio del privilegio minimo.
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 ti consente di distinguere meglio le VM amministrative dalle altre VM durante la configurazione dei firewall on-premise. Se utilizzi un VPC condiviso, utilizza autorizzazioni a livello di subnet per assicurarti che solo gli amministratori con privilegi possano eseguire il deployment di istanze VM nella subnet di gestione. Questa pratica contribuisce ad assicurare che, se i firewall on-premise applicano regole diverse per le VM di gestione rispetto alle altre VM, gli utenti non possano eludere le regole del firewall inserendo le VM non di gestione nella sottorete di gestione.
Inoltre, ti consigliamo di limitare il criterio di gruppo che gestisce le limitazioni di accesso per le VM di gestione alla sottorete di gestione. Questa prassi impone l'allineamento tra le limitazioni di accesso (in base a un criterio di gruppo) e le regole del firewall (in base alla sottorete/all'indirizzo IP).
Oltre a utilizzare i criteri IAM per limitare l'accesso al progetto, proteggi il progetto dall'eliminazione accidentale.
Utilizzare 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, nonché le macchine in esecuzione on-premise, potrebbero dover accedere a sottoinsiemi diversi di questi servizi per sfruttare Active Directory.
Quando utilizzi Microsoft AD gestito, i controller di dominio AD vengono dipartiti in un progetto tenant dedicato. La rete che ospita i controller di dominio AD è protetta automaticamente con regole firewall specifiche per AD rafforzate.
Per ridurre la superficie di attacco dei domain controller e delle VM, utilizza i firewall per non consentire alcuna comunicazione di rete non strettamente necessaria. Consulta la nostra guida sull'utilizzo di Active Directory su firewall per informazioni dettagliate sulle configurazioni del firewall necessarie per accedere ad Active Directory dalla VPC o dalle reti on-premise.
Organizza le risorse e gli utenti di Active Directory in livelli amministrativi
Alcune macchine in una foresta di Active Directory sono più importanti per la sicurezza complessiva di Active Directory rispetto ad altre. I controllori 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 di livelli. Sebbene il numero di livelli giusti dipenda dalla tua configurazione specifica, puoi iniziare distinguendo tra tre livelli:
Livello 0 (molto critico): questo livello include tutte le macchine fondamentali per la sicurezza della foresta 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, inclusi i server di applicazioni e i server di database. Un server di primo livello compromesso potrebbe avere un impatto sostanziale sull'attività, ma non rappresenta una minaccia immediata per l'intera foresta.
Livello 2 (normale): questo livello include stazioni di lavoro o altre macchine per uso generale. Si prevede che la compromissione di una macchina di Livello 2 abbia un impatto limitato sull'attività e sulla sicurezza complessiva.
Sebbene l'impatto immediato di un computer di Livello 2 compromesso possa sembrare limitato, esiste il rischio di effetti a catena: quando un utente che dispone dell'accesso amministrativo alle macchine di Livello 0 o 1 viene indotto a eseguire l'accesso 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 essere utilizzate per attaccare macchine di livelli superiori, causando un aumento dell'impatto complessivo.
Per evitare questi effetti a catena, assicurati di classificare non solo le macchine, ma anche gli account utente e limitare l'insieme di macchine a cui questi utenti hanno accesso:
Livello 0 (molto critico): utenti che hanno accesso alle macchine di livello 0.
Livello 1 (critico): utenti che hanno accesso alle macchine di livello 1.
Livello 2 (normale): utenti che hanno accesso alle macchine di livello 2.
Utilizza la seguente tabella come linea guida per stabilire quali utenti devono avere accesso a quali risorse:
| Gruppo | Livello | Accesso al dominio | Accesso al computer di livello 0 | Accesso ai computer di Livello 1 | Accesso al computer di Livello 2 |
|---|---|---|---|---|---|
| Amministratori di Active Directory | 0 | Amministratore | Utente con limitazioni | Bloccato | Bloccato |
| Amministratori del server di gestione | 0 | Utente con limitazioni | Amministratore | Bloccato | Bloccato |
| Amministratori del server | 1 | Utente con limitazioni | Bloccato | Amministratore | Bloccato |
| Amministratori delle workstation VDI | 2 | Utente con limitazioni | Bloccato | Bloccato | Amministratore |
| Utenti delle workstation VDI | 2 | Utente con limitazioni | Bloccato | Bloccato | Utente con limitazioni |
Per ulteriori dettagli e best practice sull'implementazione di un modello di livelli amministrativi in Active Directory, consulta la documentazione Microsoft.
Quando utilizzi il modello di livello amministrativo nella foresta di Active Directory, assicurati che la sua integrità non sia minata dalle 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 all'interno dello stesso livello:
Se la foresta attendibile non implementa l'amministrazione a più livelli, mappala a un determinato livello e utilizza l'autenticazione selettiva per assicurarti che gli utenti della foresta attendibile possano accedere solo alle risorse di quel determinato livello.
Utilizzo di Controlli di servizio VPC e Accesso privato Google per gli host on-premise
Le API Microsoft AD gestite consentono di reimpostare la password dell'amministratore e di eseguire altre operazioni sensibili. Per i deployment di produzione critici, consigliamo di attivare i Controlli di servizio VPC e di utilizzare Accesso privato Google per gli host on-premise per aumentare la sicurezza.
Gestione
La sezione seguente illustra le best practice relative alla gestione di Active Directory.
Allinea le strutture delle risorse di Google Cloud e Active Directory
Quando esegui il deployment di un nuovo dominio o foresta Active Directory su Google Cloud, devi definire una struttura di unità organizzativa (OU) 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 OU in linea con la gerarchia delle risorse Google Cloud:
Se utilizzi un modello di amministrazione a più livelli, le OU di primo livello devono riflettere i tuoi livelli amministrativi.
Per ogni livello, crea OU per utenti e gruppi. Se prevedi di gestire un numero elevato di utenti e gruppi, crea OU secondarie come appropriato.
Per ogni livello, crea un'OU
Projectse sotto-OU per ogni progetto Google Cloud contenente risorse Active Directory. Utilizza la OU secondaria specifica del progetto per gestire account computer, account di servizio o altre risorse Active Directory corrispondenti alle risorse Google Cloud del rispettivo progetto. Assicurati che esista una mappatura 1:1 tra gli OU e i 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 OU piatta sotto l'UO Projects. Se prevedi di gestire un numero elevato di progetti e hai progettato la gerarchia delle risorse Google Cloud per utilizzare più livelli di cartelle, ti consigliamo di riflettere questa struttura di cartelle sotto l'OU Projects.
L'allineamento della struttura delle OU di Active Directory e della gerarchia delle risorse Google Cloud offre diversi vantaggi:
Quando deleghe le autorizzazioni amministrative a un progetto Google Cloud utilizzando i criteri IAM, potresti dover concedere agli utenti del progetto determinati privilegi in Active Directory. Ad esempio, gli amministratori di Compute Engine potrebbero dover essere in grado di unire le macchine al dominio in una determinata OU. L'allineamento delle OU e dei progetti Google Cloud consente di concedere queste autorizzazioni nello stesso livello di granularità in Active Directory come in Google Cloud.
Se prevedi di utilizzare oggetti di criteri di gruppo (GPO) per gestire i computer, una struttura OU che rispecchi la gerarchia delle risorse 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 una relazione di attendibilità tra foreste con autenticazione condizionale, puoi utilizzare le OU corrispondenti ai progetti Google Cloud per concedere l'autorizzazione Consentito per l'autenticazione in base al progetto.
Quando elimini un progetto in Google Cloud, puoi semplicemente eliminare la OU associata, riducendo il rischio di lasciare risorse obsolete nella directory.
Se ritieni che la struttura dell'OU debba discostarsi dalla struttura del progetto, potrebbe essere un'indicazione che la struttura del progetto è troppo granulare o troppo approssimativa.
Utilizzare i server di ora di Google
L'autenticazione Kerberos si basa su timestamp come parte del suo protocollo. Affinché l'autenticazione vada a buon fine, gli orologi della macchina client e del server devono essere sincronizzati 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 la sincronizzazione dell'ora:
- I computer associati al dominio sincronizzano l'ora con un controller di dominio.
- I controller di dominio sincronizzano l'ora con l'emulatore PDC del dominio.
- Gli emulatori PDC di tutti i domini sincronizzano il loro orario con l'emulatore PDC del dominio radice della foresta.
In questa configurazione, l'emulatore PDC del dominio principale della foresta è la fonte di tempo principale per Active Directory ed è comune configurare questa macchina in modo che utilizzi un server NTP esterno come origine di tempo.
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'ora corretta. L'unione di una VM a un
dominio Active Directory non modifica questa configurazione predefinita.
Mantieni la configurazione predefinita di Compute Engine, a meno che l'emulatore PDC del dominio principale della foresta non sia di'implementato al di fuori di Google Cloud.
Se l'emulatore PDC è disegnato all'esterno di Google Cloud, configuralo per utilizzare time.google.com come origine NTP.
In alternativa, puoi ripristinare il comportamento predefinito di Active Directory di sincronizzare il tempo con l'emulatore PDC riconfigurando le VM 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) ai tuoi controller di dominio.
Consolidare e monitorare gli audit log
Quando esegui il deployment di Active Directory su Google Cloud, la sicurezza della foresta Active Directory e dei progetti Google Cloud è legata a un'altra: un'attività sospetta in Active Directory e Windows potrebbe mettere a rischio la sicurezza di altre risorse, così come un'attività sospetta in Google Cloud potrebbe mettere a rischio Active Directory.
I log di controllo coerenti sono uno strumento importante per identificare tempestivamente minacce o configurazioni errate e consentono di ricostruire ed esaminare le attività passate. Cloud Audit Logging ti consente di acquisire e analizzare gli audit log delle attività di amministrazione e gli audit log di accesso ai dati. Analogamente, puoi utilizzare la registrazione 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 eventuali eventi correlati 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 quelli 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 di cui hai bisogno per le finalità di controllo. Consulta i consigli di Microsoft su come configurare i criteri di controllo e monitorare Active Directory per rilevare eventuali segni di compromissione per assicurarti di acquisire tutti gli eventi di controllo pertinenti.
Quando si ha a che fare con un volume elevato di eventi, è facile perderne di critici. Per evitare di perdere eventi critici, crea metriche basate sui log per gli eventi che potrebbero essere particolarmente critici o sospetti e valuta la possibilità di configurare avvisi per ricevere notifiche quando la frequenza degli 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 consentire alle VM di partecipare automaticamente a un dominio.
Prova le altre funzionalità di Google Cloud. Consulta i nostri tutorial.