Questa guida presenta le best practice per l'esecuzione di Active Directory su Google Cloud. La guida è incentrata su pratiche specifiche per Google Cloud o di particolare importanza durante il deployment di Active Directory su 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 le best practice relative all'architettura.
Utilizza il pattern dell'architettura più adatto alle tue esigenze
Per eseguire il deployment di Active Directory su Google Cloud, devi prima decidere quale dominio e architettura della foresta utilizzare. Se utilizzi già 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 tua rete on-premise, il modo in cui le risorse on-premise e da Google Cloud interagiscono, nonché i tuoi 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 della foresta della risorsa. Con questo pattern, esegui il deployment di una foresta separata su Google Cloud e utilizzi un trust forestale unidirezionale per integrare la foresta di Google Cloud con la foresta esistente di Active Directory on-premise.
Test e produzione separati
A seconda del tuo 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 account Active Directory, cambiare le iscrizioni ai gruppi se le applicazioni usano i gruppi per gestire l'autorizzazione oppure iscriversi e rimuovere i computer.
Per evitare che i lavori di sviluppo e test influiscano sui carichi di lavoro di produzione o ostacolano la sicurezza del deployment, valuta la possibilità di eseguire il deployment di un dominio o una foresta Active Directory separato per lo sviluppo e i test.
Avere un dominio o una foresta di test e sviluppo separato ti consente anche di verificare le modifiche amministrative prima di applicarle in produzione. Alcuni di questi cambiamenti includono esperimenti con criteri di gruppo, test degli script di automazione o azioni potenzialmente rischiose, come l'aumento del livello funzionale della 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 basate 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 sostituisce quindi la federazione della tua 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 rispetto ad Active Directory on-premise, come illustrato nel diagramma seguente. Gli utenti con account nell'Active Directory on-premise possono quindi utilizzare 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 tua foresta esistente o il tuo dominio a Google Cloud, puoi anche 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 anche di applicare un ciclo di vita comune per gli account Google e gli account Active Directory, in modo che quando disattivi un account utente nella tua Active Directory on-premise, venga sospeso anche l'utente Google corrispondente.
Networking
La sezione seguente illustra le best practice relative al networking.
Deployment di Active Directory in una rete VPC condivisa
Per consentire l'utilizzo di Active Directory in più progetti, esegui il deployment dei controller di dominio in una rete VPC condivisa. L'utilizzo di una rete VPC condivisa presenta diversi vantaggi:
Ogni applicazione che potrebbe richiedere l'accesso Active Directory può essere sottoposta a deployment in un progetto separato. L'uso 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 consente di controllare in modo granulare quali degli utenti possono accedere alle risorse Google Cloud correlate.
Le reti VPC condivise consentono di centralizzare la gestione degli indirizzi IP e la configurazione del firewall, per garantire la coerenza in più progetti.
Poiché i VPC sono una risorsa globale, puoi utilizzare la stessa rete VPC condivisa in più aree geografiche.
Non esporre i controller di dominio esternamente
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 effettuare ulteriori passaggi per assicurarti che l'attivazione di Windows 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 intendi 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 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 abilitare l'accesso a Internet tramite un gateway NAT eseguendo il deployment di Cloud NAT.
Se hai configurato la connettività ibrida, puoi anche indirizzare 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
Dato che i controller di dominio funzionano come server DNS, è necessario assegnare loro un indirizzo IP che non cambi. Per farlo, prenota e assegna indirizzi IP interni statici alle VM del controller di dominio.
Quando prenoti un indirizzo IP, il comportamento predefinito è quello di scegliere un indirizzo inutilizzato automaticamente. 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 della scheda di rete sullo stesso indirizzo. Anche se questo passaggio è facoltativo, impedisce che Active Directory emetta 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 in 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ù aree geografiche, valuta la possibilità di eseguire il deployment dei controller di dominio in ogni area geografica pertinente. Poiché le subnet sono una risorsa di area geografica, il deployment in un'area geografica aggiuntiva richiede una subnet aggiuntiva.
Creare un sito per area geografica
Quando un client tenta di individuare un controller di dominio, cercherà innanzitutto un controller di dominio nel sito Active Directory che corrisponda all'indirizzo IP del client. Se in questo sito non è disponibile alcun controller di dominio, il client continuerà e tenterà di individuare un controller di dominio in un altro sito.
Puoi sfruttare questo comportamento creando un sito separato per ogni area geografica in cui esegui il deployment dei controller di dominio o dei client di dominio. I client preferiscono quindi in automatico l'utilizzo di controller di dominio che si trovano nella stessa area geografica, il che può aiutare a ridurre la latenza e il costo di uscita tra aree geografiche.
Se hai client in regioni che non hanno un controller di dominio, puoi influenzare i controller di dominio scelti da questi client regolando i costi del link del sito per riflettere la vicinanza geografica delle regioni e attivando l'impostazione Prova il sito più vicino successivo.
L'utilizzo di più siti influisce sul comportamento di replica tra i controller di dominio. Uno svantaggio dell'utilizzo di più siti può essere che la replica tra siti si verifica meno frequentemente rispetto alla replica tra siti.
Tuttavia, non puoi creare siti Active Directory in Microsoft AD gestito perché Microsoft Active Directory gestito non supporta i siti e i servizi Active Directory.
Utilizza le zone di forwarding 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 accesso a DNS interno e 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 l'accesso al DNS interno e al DNS pubblico, ma non potrà risolvere i nomi DNS gestiti da Active Directory.
Crea una zona di forwarding DNS privato in Cloud DNS per consentire ai client di risolvere i record DNS gestiti da Active Directory. Configura la zona per inoltrare le query che corrispondono al dominio Active Directory ai controller di dominio.
L'utilizzo di una zona di forwarding DNS privata presenta numerosi vantaggi rispetto alla configurazione dei client per l'uso diretto dei controller di dominio Active Directory come server DNS:
Non è necessario regolare 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 privato e non modificare alcuna impostazione del client.
Le istanze VM hanno ancora accesso al DNS interno.
I record DNS che non corrispondono al 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 privato 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.
Dovrai comunque configurare manualmente le impostazioni DNS sui controller di dominio. Utilizza 127.0.0.1 come server DNS principale e imposta l'indirizzo di loopback come server DNS secondario. Scopri di più sulle impostazioni DNS consigliate e sulle opzioni alternative.
Connettività ibrida
La sezione seguente illustra le best practice relative alla connettività ibrida.
Utilizza l'inoltro DNS in entrata per risolvere i nomi Google Cloud DNS da 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 in Google Cloud. Se estendi la foresta o esegui il deployment di una foresta delle risorse su Google Cloud, utilizza l'inoltro DNS in entrata per consentire ai client on-premise di cercare i record DNS per le risorse di cui è stato eseguito il deployment in Google Cloud. Per utilizzare l'inoltro in entrata, crea un criterio del server DNS per allocare un indirizzo IP di 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 rimandi all'indirizzo IP del server forwarding 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 forwarding in entrata.
Se i domini DNS utilizzati su Google Cloud e la 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 inoltrano la Quest all'indirizzo IP del forwarding in entrata.
Quando utilizzi il DNS in entrata, assicurati che i firewall siano configurati in modo appropriato.
Il forwarding 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 su Google Cloud e nel tuo ambiente on-premise e resi disponibili per la ricerca in entrambi gli ambienti.
Utilizza l'inoltro 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 sottoposte a deployment on-premise. Se estendi la foresta o esegui il deployment di una foresta delle risorse su Google Cloud, crea una zona di forwarding privata in Cloud DNS per inoltrare le query DNS per i domini on-premise ai server DNS on-premise.
Quando utilizzi l'inoltro DNS in uscita, assicurati che i firewall siano configurati in modo appropriato.
L'inoltro in uscita DNS non è necessario se estendi il 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 ampio uso 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 macchine virtuali sia criptato, quindi l'uso di LDAP non criptato all'interno del tuo VPC è accettabile. 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 criptato automaticamente utilizzando IPSec tra Google Cloud e l'endpoint VPN on-premise.
Cloud Interconnect e Partner Interconnect non forniscono crittografia. Per garantire una comunicazione sicura, stabilisci un tunnel VPN sulla connessione di interconnessione utilizzando un'appliance VPN da Google Cloud Marketplace.
Utilizza l'autenticazione selettiva e l'AES per i trust forestali
Quando crei una relazione di trust tra foreste di Active Directory, prevedi i Forest Forest rispetto ai trust esterni e sfrutta le seguenti funzionalità per migliorare la sicurezza:
Abilita l'autenticazione selettiva sui trust in uscita nella foresta delle risorse. L'autenticazione selettiva garantisce che gli utenti della foresta organizzativa non possano accedere alle risorse nella foresta, a meno che non venga concessa esplicitamente l'autorizzazione.
Abilita l'applicazione dei limiti di foresta per la delega completa di Kerberos sui trust in entrata nella foresta dell'organizzazione. Questa funzionalità contribuisce a impedire attacchi di riassegnazione dei privilegi impedendo alle risorse nella foresta di richiedere i ticket di concessione di biglietti (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 con crittografia AES anziché con 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 offre un controllo granulare sugli utenti autorizzati ad accedere a determinate risorse. Quando le macchine vengono sottoposte a deployment come istanze VM in Compute Engine e gli utenti hanno accesso al progetto Google Cloud sottostante, devi prendere in considerazione 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 della password per creare account amministratore locale. Gli account amministratore locale rappresentano una minaccia per la sicurezza del dominio Active Directory, poiché possono essere utilizzati per compromettere i criteri di gruppo o per installare software dannoso che potrebbe acquisire le credenziali del dominio di altri utenti registrati.
Aggiungendo uno script di avvio, un membro del progetto con privilegi può inserire codice dannoso in una VM che viene eseguita come
nt authority\systemal successivo riavvio della macchina.Utilizzando la console di serie, un membro del progetto con privilegi può anche accedere alla Console di amministrazione speciale di Windows (SAC). Windows considera i log tramite il SAC come locali. Il SAC può quindi essere utilizzato in modo improprio per eludere i criteri che negano gli accessi tramite RDP, ma perdono di negare gli accessi locali.
Un membro del progetto con privilegi può utilizzare il SAC per emettere un comando
crashdump, il che può causare la scrittura su disco di un dump della memoria. Un tale dump della memoria potrebbe includere informazioni e credenziali sensibili.Montando il disco permanente su una VM diversa o utilizzando snapshot, un membro del progetto con privilegi potrebbe essere in grado di accedere ai contenuti del disco, inclusi i dump della memoria, dalle macchine a cui l'utente non avrebbe l'autorizzazione per accedere.
Quando utilizzi Managed Microsoft AD, per impostazione predefinita sei meglio protetto da questi percorsi di accesso aggiuntivi. 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 delle VM del controller di dominio AD.
Per ridurre ulteriormente questi rischi, assicurati che le autorizzazioni IAM dei progetti contenenti istanze VM aggiunte a un dominio siano gestite con priorità minima per i privilegi. Puoi ridurre ulteriormente il rischio per l'utente dei criteri dell'organizzazione, dei criteri di gruppo e delle VM schermate:
Utilizza un criterio organizzativo per disabilitare l'accesso alle porte seriali.
Per applicare un criterio di gruppo che impedisce la creazione di account amministratore locale, disattiva l'account manager. Definisci la preferenza INI Files nei criteri di gruppo (Computer Configuration > Preferences > Windows Settings > Ini Files) per applicare la seguente impostazione:
- Azione: aggiorna
- Percorso file:
C:\Program Files\Google\Compute Engine\instance_configs.cfg - Nome della sezione:
accountManager - Nome proprietà:
disable - Valore della proprietà:
true
Applica un criterio di gruppo che rimuove gli account amministratore locali 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 ai gruppi dal gruppo Amministratori e da altri gruppi sensibili.
Considera l'utilizzo di VM schermate in combinazione con la crittografia del disco di BitLocker per evitare che gli dischi permanenti 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 si affidano ai controller di dominio per gestire l'autenticazione e l'autorizzazione per loro conto. A meno che non siano limitati dai criteri di gruppo, da un sistema di sicurezza locale di una macchina o da un'autenticazione selettiva, un utente che abbia dimostrato di avere identità di uno dei controller di dominio può accedere a qualsiasi computer del 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 escalation del privilegio se alcune istanze VM sono esenti dalle restrizioni di firewall o utilizzano 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 possa utilizzare Active Directory per accedere a una macchina può quindi accedere alle credenziali di questo account di servizio per ottenere l'accesso a qualsiasi risorsa di Google Cloud a cui ha accesso l'account di servizio.
Quando configuri Microsoft AD gestito, il servizio crea un gruppo per consentire a utenti specifici di eseguire facilmente il RDP nelle VM con dominio aggiunto.
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 Remote Desktop Services per limitare l'accesso alle tue VM in base al livello.
In una topologia di foresta delle risorse, sfrutta ulteriormente l'autenticazione selettiva per limitare ulteriormente l'insieme di utenti di altre foreste a cui è consentito accedere alle VM. Puoi semplificare la gestione delle autorizzazioni di autenticazione selettive mediante l'allineamento delle strutture di risorse Google Cloud e Active Directory: se le unità organizzative Active Directory vengono mappate ai progetti Google Cloud, puoi concedere agli utenti il diritto di autenticazione su un livello che corrisponde a un progetto Google Cloud.
Nei casi in cui non sono applicabili né l'autenticazione selettiva né i criteri di gruppo, crea un account di servizio separato, esporta le chiavi dell'account di servizio, salvale nel disco locale o nella condivisione di file dell'istanza VM e proteggile con un ACL NTFS in modo che solo gli utenti 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 il rischio di compromettere l'intera foresta di Active Directory.
Per limitare il rischio di accessi non autorizzati, utilizza un progetto Google Cloud separato per eseguire il deployment dei controller di dominio e concedere l'accesso a questo progetto con privilegi minimi. Quando crei il progetto, tieni presente che alcune autorizzazioni potrebbero essere ereditate dalle cartelle principali. Per evitare di concedere inavvertitamente l'accesso tramite l'ereditarietà, valuta la possibilità di creare il progetto al di fuori della tua normale gerarchia di 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, proteggi il progetto dall'eliminazione accidentale.
Usa VM e progetti separati per gestire Active Directory
Per gestire Active Directory, devi poter utilizzare strumenti quali Utenti e computer di Active Directory o Centro amministrativo di Active Directory. Questi strumenti richiedono l'accesso utilizzando un account di dominio con privilegi, che rende la macchina che esegui questi strumenti su un target interessante per il furto di credenziali o il logging delle chiavi.
Per ridurre al minimo il rischio che un utente malintenzionato ottenga credenziali di dominio con privilegi, utilizza le istanze VM dedicate per l'amministrazione del dominio e gestisci tali VM di gestione, come le workstation con accesso con privilegi:
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 dai membri del progetto che creano account amministratore locali, che accedono tramite la console di serie o che manomettono i dischi permanenti. Per limitare il rischio di accessi non autorizzati, utilizza un progetto separato di Google Cloud per le VM amministrative e concedi l'accesso a questo progetto con 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 le VM amministrative e le altre VM durante la configurazione dei firewall on-premise. Se utilizzi un VPC condiviso, usa le autorizzazioni a livello di subnet per assicurarti che solo gli amministratori con privilegi siano autorizzati a eseguire il deployment delle istanze VM nella subnet di gestione. Questa prassi contribuisce 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 del firewall inserendo le VM non di gestione nella subnet di gestione.
Inoltre, valuta la possibilità di limitare i criteri di gruppo che gestiscono le limitazioni di accesso per le VM di gestione alla subnet di gestione. Questa pratica impone l'allineamento tra le limitazioni di accesso (in base a un criterio di gruppo) e le regole firewall (basate sull'indirizzo subnet/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 e i server di dominio
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 in Google Cloud e le macchine in esecuzione on-premise potrebbero dover accedere a sottoinsiemi di questi servizi per poter sfruttare Active Directory.
Quando utilizzi Microsoft Active Directory gestito, il deployment dei controller di dominio AD viene eseguito in un progetto tenant dedicato. La rete che ospita i controller di dominio AD viene automaticamente protetta con regole firewall specifiche per AD.
Per ridurre la superficie di attacco dei controller di dominio e delle VM, utilizza i firewall per impedire qualsiasi comunicazione di rete non strettamente richiesta. Fai riferimento alla nostra guida sull'utilizzo di Active Directory tra firewall per i dettagli sulle configurazioni firewall necessarie per accedere ad Active Directory dal tuo VPC o dalle reti on-premise.
Organizzare risorse e utenti di Active Directory in livelli amministrativi
Alcune macchine in una foresta Active Directory sono più critiche per la sicurezza generale 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 ai potenziali attacchi.
Per identificare la criticità di ogni macchina, utilizza una tassonomia di livelli. Il numero corretto di livelli dipende dalla configurazione specifica, ma puoi iniziare destringendo da 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 (importante): questo livello include la maggior parte dei server presenti nel tuo ambiente, inclusi i server delle applicazioni e dei database. Un server di livello 1 compromesso potrebbe avere un impatto aziendale significativo, ma non rappresenta una minaccia immediata per l'intera foresta.
Livello 2 (normale): questo livello include workstation o altre macchine per uso generico. La compromissione di una macchina di livello 2 dovrebbe avere un impatto limitato sulla sicurezza aziendale e generale.
Anche se l'impatto immediato di una macchina di livello 2 compromesso potrebbe sembrare limitato, esiste il rischio di effetti collaterali: quando un utente che ha accesso amministrativo alle macchine di livello 0 o di livello 1 viene attirato su un computer compromesso di livello 2, potrebbe essere vittima di un keylogger o di altre forme di furto di credenziali. Le credenziali acquisite potrebbero quindi essere utilizzate per attaccare le macchine di livello superiore, causando un escalation dell'impatto complessivo.
Per evitare effetti simili, assicurati di classificare non solo le macchine, ma anche gli account utente e di limitare l'insieme di macchine a cui questi utenti hanno accesso:
Livello 0 (altamente critico): utenti che hanno accesso alle macchine di livello 0.
Livello 1 (importante): gli utenti che hanno accesso alle macchine di livello 1.
Livello 2 (normale): gli utenti che hanno accesso alle macchine di livello 2.
Utilizza la seguente tabella come linea guida per quali utenti dovrebbero avere accesso a determinate risorse:
| Gruppo | Livello | Accesso al dominio | Accesso ai 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 server di gestione | 0 | Utente con limitazioni | Amministratore | Bloccata | Bloccata |
| Amministratori 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à non sia compromessa dalle relazioni di trust forestale. 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 siano autorizzati ad accedere solo alle risorse all'interno dello stesso livello:
Se la foresta attendibile non implementa l'amministrazione a più 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 particolare 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, ti consigliamo di abilitare i controlli di servizio VPC e di utilizzare l'accesso privato Google per gli host on-premise per aumentare la sicurezza.
Management
La seguente sezione descrive le best practice relative alla gestione di Active Directory.
Allineare le strutture di risorse di Google Cloud e Active Directory
Quando esegui il deployment di un nuovo dominio o di una foresta Active Directory su Google Cloud, devi definire una struttura di unità organizzative (UO) per organizzare le risorse con il dominio Active Directory. Anziché progettare una struttura completamente nuova o applicare la struttura che utilizzi nel tuo ambiente on-premise, crea una struttura UO in linea con la tua gerarchia di risorse di Google Cloud:
Se utilizzi un modello di amministrazione a più livelli, le unità organizzative di primo livello devono rispecchiare i tuoi livelli amministrativi.
Per ogni livello, crea unità organizzative per utenti e gruppi. Se prevedi di gestire un numero elevato di utenti e gruppi, crea unità organizzative secondarie appropriate per le tue esigenze.
Per ogni livello, crea una UO
Projectse crea delle unità secondarie per ogni progetto Google Cloud che contiene risorse di Active Directory. Utilizza l'unità organizzativa secondaria specifica del progetto per gestire account di computer, account di servizio o altre risorse di Active Directory corrispondenti alle risorse di Google Cloud del rispettivo progetto. Assicurati che vi sia una mappatura 1:1 tra le UO 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 UO piatta sotto l'unità organizzativa Projects. Se prevedi di gestire un numero elevato di progetti e hai progettato la gerarchia delle risorse di Google Cloud in modo da utilizzare più livelli di cartelle, ti consigliamo di riflettere la struttura delle cartelle sotto l'unità organizzativa Projects.
L'allineamento della struttura organizzativa di Active Directory e della gerarchia delle risorse di Google Cloud presenta diversi vantaggi:
Quando deleghi le autorizzazioni amministrative a un progetto Google Cloud utilizzando i criteri IAM, potresti anche dover concedere agli utenti del progetto alcuni 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 UO. L'allineamento di unità organizzative e progetti Google Cloud ti consente di concedere tali autorizzazioni allo stesso livello di granularità in Active Directory e in Google Cloud.
Se prevedi di utilizzare oggetti Criteri di gruppo (GPO) per gestire i computer, una struttura UO che rifletta la gerarchia delle risorse di Google Cloud ti aiuta ad assicurare che gli oggetti Criteri di gruppo siano applicati in modo coerente a tutte le VM di un determinato progetto o cartella.
Se utilizzi un trust cross-forestale con l'autenticazione condizionale, puoi utilizzare le UO corrispondenti ai progetti Google Cloud per concedere l'autorizzazione Consentita con autenticazione in base al progetto.
Quando elimini un progetto in Google Cloud, puoi semplicemente eliminare l'unità organizzativa associata, riducendo il rischio di lasciare risorse non aggiornate nella directory.
Se ritieni che la struttura dell'UO debba essere diversa da quella del progetto, questo potrebbe indicare che la struttura del progetto è troppo granulare o troppo granulare.
Utilizzare i server di Google
L'autenticazione Kerberos si basa su timestamp come parte del suo protocollo. Affinché l'autenticazione vada a buon fine, gli orologi del computer 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, le seguenti sono la configurazione predefinita di sincronizzazione:
- I computer aggiunti a un dominio sincronizzano il loro tempo con un controller di dominio.
- I controller di dominio sincronizzano il loro tempo con l'emulatore PDC del dominio.
- Gli emulatori PDC di tutti i domini sincronizzano il proprio tempo con l'emulatore PDC del dominio principale della foresta.
In questa configurazione, l'emulatore PDC del dominio principale della foresta è l'ultima origine di tempo per Active Directory ed è comune per configurare questa macchina in modo che utilizzi un server NTP esterno come origine temporale.
Su Compute Engine, la configurazione predefinita per le VM Windows consiste nell'utilizzare il 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'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 venga eseguito il deployment dell'emulatore PDC del dominio principale della foresta al di fuori di Google Cloud.
Se il deployment dell'emulatore PDC viene 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 della sincronizzazione con l'emulatore PDC riconfigurando le VM di Compute Engine in modo da utilizzare l'origine NTP DOMHIER e configurando le regole firewall per consentire il traffico in entrata NTP (UDP/123) ai controller di dominio.
Consolidare e monitorare 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: attività sospette in Active Directory e Windows. Potrebbero mettere in pericolo la sicurezza di alcune altre risorse allo stesso modo in cui le attività sospette in Google Cloud potrebbero mettere a rischio la tua Active Directory.
Gli audit log coerenti rappresentano uno strumento importante per identificare in anticipo le minacce o gli errori di configurazione e consentirti di ricostruire ed esaminare le attività passate. Cloud Audit Logging ti consente di acquisire e analizzare i log delle attività di amministrazione e i log di accesso ai dati. Analogamente, puoi utilizzare il logging delle regole firewall e i log di flusso VPC per analizzare il traffico di rete. Tuttavia, questi servizi di piattaforma non sono a conoscenza di eventuali eventi relativi alla sicurezza che si verificano in Active Directory. Per definire un audit trail coerente che copra sia gli eventi di controllo relativi alla piattaforma sia gli eventi di controllo correlati ad Active Directory, installa l'agente Cloud Logging sui controller di dominio e sui computer facenti parte del 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 includere tutti gli eventi di cui hai bisogno per scopi di controllo. Leggi i consigli Microsoft sulla configurazione dei criteri di controllo e sul monitoraggio di Active Directory per individuare eventuali segni di compromissione per assicurarti di acquisire tutti gli eventi di controllo pertinenti.
Quando si ha a che fare con un grande volume di eventi, è facile perdere gli eventi critici. Per evitare di perdere eventi critici, crea metriche basate su log per eventi potenzialmente particolarmente critici o sospetti e valuta la possibilità di configurare gli avvisi per ricevere notifiche quando la frequenza degli eventi cambia o supera le soglie accettabili.
Passaggi successivi
Scopri quale pattern di utilizzo di Active Directory in un ambiente ibrido è il più adatto alla tua situazione.
Scopri come configurare Active Directory per le VM in modo che si uniscano automaticamente a un dominio.
Prova altre funzionalità di Google Cloud. Vedi i nostri tutorial.