Questo documento illustra i requisiti da considerare quando implementi Active Directory in Google Cloud e ti aiuta a scegliere l'architettura giusta.
Se federi Active Directory con Cloud Identity o Google Workspace (vedi Modelli per l'autenticazione degli utenti della forza lavoro in un ambiente ibrido), puoi consentire agli utenti dei tuoi domini Active Directory esistenti di autenticarsi e accedere alle risorse su Google Cloud. Puoi anche eseguire il deployment di Active Directory su Google Cloud se prevedi di utilizzare Active Directory per gestire i server Windows su Google Cloud o se utilizzi protocolli non supportati da Google Cloud.
Prima di eseguire il deployment di Active Directory in Google Cloud, devi prima decidere quale architettura di dominio e foresta utilizzare e come integrarla con la foresta Active Directory esistente.
Valutazione dei requisiti
Active Directory supporta una serie di architetture di domini e foreste. In un ambiente ibrido, un'opzione è estendere un singolo dominio Active Directory a più ambienti. In alternativa, puoi utilizzare domini o foreste separati e collegarli utilizzando le relazioni di trust. L'architettura migliore dipende dai tuoi requisiti.
Per scegliere l'architettura migliore, considera questi fattori:
- Allineamento con le zone di sicurezza esistenti
- Interazione tra risorse on-premise e Google Cloud
- Autonomia amministrativa
- Disponibilità
Le sezioni che seguono illustrano questi fattori.
Allineamento con le zone di sicurezza esistenti
Inizia esaminando la progettazione della tua rete on-premise.
Nel tuo ambiente on-premise, potresti aver segmentato la rete in più zone di sicurezza, ad esempio utilizzando VLAN o subnet separate. In una rete segmentata in zone di sicurezza, la comunicazione all'interno di una zona di sicurezza è illimitata o soggetta solo a policy di firewall e controllo leggere. Al contrario, qualsiasi comunicazione tra zone di sicurezza è soggetta a rigidi criteri di firewall, controllo o ispezione del traffico.
L'obiettivo delle zone di sicurezza è più ampio della semplice limitazione e dell'audit della comunicazione di rete. Le zone di sicurezza devono implementare limiti di attendibilità.
Limiti di trust
Ogni macchina di una rete esegue diversi processi. Questi processi potrebbero comunicare tra loro localmente utilizzando la comunicazione tra processi e potrebbero comunicare tra macchine utilizzando protocolli come HTTP. In questa rete di comunicazione, i peer non si fidano sempre l'uno dell'altro allo stesso modo. Ad esempio, i processi potrebbero considerare più attendibili quelli in esecuzione sulla stessa macchina rispetto a quelli in esecuzione su altre macchine. e alcune macchine potrebbero essere considerate più affidabili di altre.
Un limite di attendibilità impone la discriminazione tra le parti di comunicazione, fidandosi di un insieme di parti di comunicazione più di un altro insieme di parti.
I limiti di attendibilità sono fondamentali per contenere l'impatto di un attacco. Gli attacchi raramente terminano una volta compromesso un singolo sistema, che si tratti di un singolo processo o di un'intera macchina. Al contrario, è probabile che un malintenzionato tenti di estendere l'attacco ad altri sistemi. Poiché i sistemi all'interno di un confine di trust non fanno distinzione tra loro, diffondere un attacco all'interno di questo confine di trust è più facile che attaccare sistemi oltre un confine di trust.
Una volta compromesso un sistema in un perimetro di attendibilità, si deve presumere che tutti gli altri sistemi in questo perimetro di attendibilità siano compromessi. Questo presupposto può aiutarti a identificare i limiti di attendibilità o a verificare se un determinato limite di sistema è un limite di attendibilità, ad esempio:
Supponiamo che un malintenzionato abbia ottenuto il livello di accesso più elevato al target A (ad esempio, accesso amministratore o root a una macchina o applicazione). Se possono sfruttare questi privilegi per ottenere lo stesso livello di accesso al target B, allora A e B si trovano, per definizione, all'interno dello stesso confine di attendibilità. In caso contrario, tra A e B si trova un limite di trust.
Limitando la comunicazione di rete, le zone di sicurezza possono contribuire a implementare i confini di attendibilità. Affinché una zona di sicurezza diventi un vero confine di attendibilità, tuttavia, i carichi di lavoro su ciascun lato del confine devono distinguere tra le richieste provenienti dalla stessa zona di sicurezza e quelle provenienti da zone di sicurezza diverse e analizzare queste ultime più attentamente.
Modello Zero Trust
Il modello Zero Trust è il modello di networking preferito su Google Cloud.
Dato un singolo sistema compromesso in un perimetro di attendibilità, puoi presumere che tutti i sistemi in quel perimetro siano compromessi. Questo presupposto suggerisce che i limiti di attendibilità più piccoli sono migliori. Più piccolo è il confine di attendibilità, meno sistemi vengono compromessi e più confini un malintenzionato deve superare per diffondere un attacco.
Il modello Zero Trust porta questa idea alla sua logica conclusione: ogni macchina della rete viene trattata come una zona di sicurezza e un confine di attendibilità unici. Tutte le comunicazioni tra le macchine sono soggette allo stesso controllo e firewall e tutte le richieste di rete vengono trattate come se provenissero da un'origine non attendibile.
A livello di networking, puoi implementare un modello zero-trust utilizzando le regole firewall per limitare il traffico e i log di flusso VPC e il logging delle regole firewall per analizzare il traffico. A livello di applicazione, devi assicurarti che tutte le applicazioni gestiscano in modo coerente e sicuro autenticazione, autorizzazione e controllo.
Limiti di attendibilità in Active Directory
In un dominio Active Directory, le macchine si affidano ai domain controller per gestire l'autenticazione e l'autorizzazione per loro conto. Una volta che un utente ha dimostrato la propria identità a uno dei domain controller, può accedere per impostazione predefinita a tutte le macchine dello stesso dominio. Tutti i diritti di accesso concessi all'utente dal controller di dominio (sotto forma di privilegi e appartenenze a gruppi) si applicano a molte macchine del dominio.
Utilizzando i criteri di gruppo, puoi impedire agli utenti di accedere a determinate macchine o limitare i loro diritti su determinate macchine. Una volta compromessa una macchina, tuttavia, un malintenzionato potrebbe essere in grado di rubare password, hash delle password o token Kerberos di altri utenti del dominio che hanno eseguito l'accesso alla stessa macchina. L'autore dell'attacco può quindi sfruttare queste credenziali per estendere l'attacco ad altri domini nella foresta.
Tenendo conto di questi fattori, è meglio presupporre che tutte le macchine di una foresta si trovino in un confine di sicurezza di trust.
Rispetto ai limiti di dominio, il cui scopo è controllare la replica e la concessione dell'autonomia amministrativa a diverse parti dell'organizzazione, i limiti della foresta possono fornire un isolamento più forte. Le foreste possono fungere da limite di trust.
Allineamento delle foreste Active Directory e delle zone di sicurezza
Supponendo che la foresta sia il limite di trust, si influenza la progettazione delle zone di sicurezza. Se una foresta si estende su due zone di sicurezza, è più facile per un malintenzionato eliminare il confine tra queste zone di sicurezza. Di conseguenza, le due zone di sicurezza diventano effettivamente una sola e formano un unico limite di trust.
In un modello Zero Trust, ogni macchina di una rete può essere considerata una zona di sicurezza separata. Il deployment di Active Directory in una rete di questo tipo mina questo concetto e amplia il perimetro di sicurezza effettivo in modo da includere tutte le macchine della foresta Active Directory.
Affinché una zona di sicurezza funga da limite di trust, devi assicurarti che l'intera foresta di Active Directory si trovi nella zona di sicurezza.
Impatto dell'estensione di Active Directory a Google Cloud
Quando pianifichi un deployment in Google Cloud che richiede Active Directory, devi scegliere tra due opzioni per allineare il deployment alle zone di sicurezza esistenti:
Estendi una zona di sicurezza esistente a Google Cloud. Puoi estendere una o più delle tue zone di sicurezza esistenti a Google Cloud mediante il provisioning del VPC condiviso su Google Cloud e la connessione alla zona esistente utilizzando Cloud VPN o Cloud Interconnect.
Le risorse di cui è stato eseguito il deployment on-premise e su Google Cloud che condividono una zona comune possono anche condividere una foresta Active Directory comune, quindi non è necessario eseguire il deployment di una foresta separata per Google Cloud.
Ad esempio, considera una rete esistente con una rete perimetrale di sviluppo e una rete perimetrale di produzione come zone di sicurezza con una foresta Active Directory separata in ogni zona di sicurezza. Se estendi le zone di sicurezza a Google Cloud, anche tutti i deployment su Google Cloud fanno parte di una di queste due zone di sicurezza e possono utilizzare le stesse foreste Active Directory.
Introduci nuove zone di sicurezza. L'estensione di una zona di sicurezza potrebbe non essere applicabile, perché non vuoi espandere ulteriormente una zona o perché i requisiti di sicurezza delle zone di sicurezza esistenti non corrispondono a quelli delle tue implementazioni di Google Cloud. Puoi trattare Google Cloud come zone di sicurezza aggiuntive.
Ad esempio, considera un ambiente on-premise con una rete perimetrale, ma che non distingue tra carichi di lavoro di sviluppo e produzione. Per separare questi carichi di lavoro su Google Cloud, puoi creare due VPC condivisi e considerarli nuove zone di sicurezza. A questo punto, distribuisci due foreste Active Directory aggiuntive a Google Cloud, una per zona di sicurezza. Se necessario, puoi stabilire relazioni di trust tra le foreste per attivare l'autenticazione tra le zone di sicurezza.
Interazione tra risorse on-premise e Google Cloud
Il secondo fattore da considerare quando estendi Active Directory a Google Cloud è l'interazione di utenti e risorse tra on-premise e Google Cloud. A seconda del caso d'uso, questa interazione può essere leggera o intensa.
Interazione con la luce
Se l'unico scopo dell'utilizzo di Active Directory su Google Cloud è la gestione di una flotta di server Windows e l'accesso degli amministratori a questi server, il livello di interazione tra gli ambienti è leggero:
- Il set di dipendenti che interagiscono con le risorse su Google Cloud è limitato al personale amministrativo.
- Le applicazioni di cui è stato eseguito il deployment in Google Cloud potrebbero non interagire con le applicazioni on-premise o potrebbero farlo senza fare affidamento su funzionalità di autenticazione Windows come Kerberos e NTLM.
In uno scenario leggero, valuta la possibilità di integrare gli ambienti on-premise e Google Cloud in uno dei due modi seguenti:
Due foreste Active Directory disgiunte: puoi isolare i due ambienti utilizzando due foreste Active Directory separate che non condividono una relazione di trust. Per consentire l'autenticazione degli amministratori, mantieni un insieme separato di account utente per loro nella foresta Google Cloud.
La gestione di un insieme duplicato di account utente aumenta l'impegno amministrativo e introduce il rischio di dimenticare di disattivare gli account quando i dipendenti lasciano l'azienda. Un approccio migliore è quello di eseguire il provisioning di questi account automaticamente.
Se gli account utente in Active Directory on-premise vengono sottoposti a provisioning da un sistema informativo delle risorse umane (HRIS), potresti essere in grado di utilizzare un meccanismo simile per eseguire il provisioning e gestire gli account utente nella forestaGoogle Cloud . In alternativa, puoi utilizzare strumenti come Microsoft Identity Manager per sincronizzare gli account utente tra gli ambienti.
Due foreste Active Directory con trust tra foreste: utilizzando due foreste Active Directory e collegandole con un trust tra foreste, puoi evitare di dover gestire account duplicati. Gli amministratori utilizzano lo stesso account utente per l'autenticazione in entrambi gli ambienti. Sebbene il livello di isolamento tra gli ambienti possa essere considerato più debole, l'utilizzo di foreste separate consente di mantenere un limite di attendibilità tra l'ambiente on-premise e Google Cloud .
Interazione moderata
Il tuo caso d'uso potrebbe essere più complesso. Ad esempio:
- Gli amministratori che accedono ai server Windows di cui è stato eseguito il deployment su Google Cloud potrebbero dover accedere alle condivisioni di file ospitate on-premise.
- Le applicazioni potrebbero utilizzare Kerberos o NTLM per autenticarsi e comunicare oltre i confini dell'ambiente.
- Potresti voler consentire ai dipendenti di utilizzare l'autenticazione integrata di Windows (IWA) per l'autenticazione alle applicazioni web implementate su Google Cloud.
In uno scenario moderato, l'utilizzo di due foreste Active Directory disgiunte potrebbe essere troppo limitante: non puoi utilizzare Kerberos per l'autenticazione nelle due foreste e l'utilizzo dell'autenticazione pass-through NTLM richiede la sincronizzazione degli account utente e delle password.
In questo caso, consigliamo di utilizzare due foreste Active Directory con una relazione di trust tra foreste.
Interazione elevata
Alcuni workload, inclusi i deployment dell'infrastruttura desktop virtuale (VDI), potrebbero richiedere una forte interazione tra le risorse on-premise e le risorse deployate su Google Cloud. Quando le risorse tra gli ambienti sono strettamente accoppiate, tentare di mantenere un confine di trust tra gli ambienti potrebbe non essere pratico e l'utilizzo di due foreste con un trust tra foreste può essere troppo limitante.
In questo caso, ti consigliamo di utilizzare una singola foresta Active Directory e di condividerla tra gli ambienti.
Autonomia amministrativa
Il terzo fattore da considerare quando estendi Active Directory a Google Cloud è l'autonomia amministrativa.
Se prevedi di distribuire i carichi di lavoro on-premise e Google Cloud, i carichi di lavoro che eseguirai su Google Cloud potrebbero essere molto diversi da quelli che mantieni on-premise. Potresti anche decidere che team diversi devono gestire i due ambienti.
La separazione delle responsabilità tra team diversi richiede la concessione a ciascun team di una certa autonomia amministrativa. In Active Directory, puoi concedere ai team l'autorità per gestire le risorse utilizzando l'amministrazione delegata o utilizzando domini separati.
L'amministrazione delegata è un modo semplice per delegare le attività amministrative e concedere una certa autonomia ai team. La gestione di un singolo dominio può anche aiutarti a garantire la coerenza tra ambienti e team.
Tuttavia, non puoi delegare tutte le funzionalità amministrative e la condivisione di un singolo dominio potrebbe aumentare il sovraccarico amministrativo di coordinamento tra i team. In questo caso, ti consigliamo di utilizzare domini separati.
Disponibilità
L'ultimo fattore da considerare quando estendi Active Directory a Google Cloud è la disponibilità. Per ogni dominio in una foresta Active Directory, il controller di dominio funge da identity provider per gli utenti di quel dominio.
Quando si utilizza Kerberos per l'autenticazione, un utente deve interagire con un domain controller Active Directory in vari punti:
- Autenticazione iniziale (ottenimento di un ticket di concessione di ticket).
- Riautenticazione periodica (aggiornamento di un ticket-granting ticket).
- Autenticazione con una risorsa (ottenimento di un service ticket).
L'esecuzione dell'autenticazione iniziale e della riautenticazione periodica richiede la comunicazione con un solo controller di dominio, ovvero un controller di dominio del dominio di cui l'utente è membro.
Quando esegui l'autenticazione con una risorsa, potrebbe essere necessario interagire con più controller di dominio, a seconda del dominio in cui si trova la risorsa:
- Se la risorsa si trova nello stesso dominio dell'utente, quest'ultimo può utilizzare lo stesso controller di dominio (o un controller di dominio diverso dello stesso dominio) per completare la procedura di autenticazione.
- Se la risorsa si trova in un dominio diverso, ma esiste una relazione di trust diretta con il dominio dell'utente, l'utente deve interagire con almeno due controller di dominio: uno nel dominio della risorsa e uno nel dominio dell'utente.
- Se la risorsa e l'utente fanno parte di domini diversi e esiste solo una relazione di attendibilità indiretta tra questi domini, l'autenticazione riuscita richiede la comunicazione con i controller di dominio di ogni dominio nel percorso di attendibilità.
L'individuazione di utenti e risorse in domini o foreste Active Directory diversi può limitare la disponibilità complessiva. Poiché l'autenticazione richiede l'interazione con più domini, un'interruzione di un dominio può influire sulla disponibilità di risorse in altri domini.
Considerando il potenziale impatto della topologia di Active Directory sulla disponibilità, ti consigliamo di allineare la topologia di Active Directory alla tua strategia ibrida.
Carichi di lavoro distribuiti
Per sfruttare le funzionalità uniche di ogni ambiente di computing, puoi utilizzare un approccio ibrido per distribuire i carichi di lavoro in questi ambienti. In una configurazione di questo tipo, i carichi di lavoro di cui esegui il deployment in Google Cloud dipendono probabilmente da altre infrastrutture o applicazioni in esecuzione on-premise, il che rende la connettività ibrida ad alta disponibilità un requisito fondamentale.
Se implementi una foresta o un dominio Active Directory separato per Google Cloud e utilizzi un trust per connetterlo ad Active Directory on-premise, aggiungi un'altra dipendenza tra Google Cloud e il tuo ambiente on-premise. Questa dipendenza ha un effetto minimo sulla disponibilità.
Workload ridondanti
Se utilizzi Google Cloud per garantire la continuità aziendale, i tuoi carichi di lavoro su Google Cloud rispecchiano alcuni dei carichi di lavoro nel tuo ambiente on-premise. Questa configurazione consente a un ambiente di assumere il ruolo dell'altro ambiente in caso di errore. Devi quindi esaminare ogni dipendenza tra questi ambienti.
Se implementi una foresta o un dominio Active Directory separato per Google Cloud e utilizzi un trust per connetterlo ad Active Directory on-premise, potresti creare una dipendenza che compromette lo scopo della configurazione. Se Active Directory on-premise non è più disponibile, anche tutti i carichi di lavoro di cui è stato eseguito il deployment su Google Cloud che si basano sull'autenticazione tra domini o foreste potrebbero non essere più disponibili.
Se il tuo obiettivo è garantire la continuità operativa, puoi utilizzare foreste Active Directory separate in ogni ambiente che non sono connesse tra loro. In alternativa, puoi estendere un dominio Active Directory esistente a Google Cloud. Se implementi controller di dominio aggiuntivi inGoogle Cloud e replichi i contenuti della directory tra gli ambienti, ti assicuri che gli ambienti operino in isolamento.
Pattern di integrazione
Dopo aver valutato i tuoi requisiti, utilizza la seguente struttura decisionale per identificare un'architettura di foresta e dominio adatta.
Le sezioni seguenti descrivono ogni pattern.
Foreste sincronizzate
Nel pattern foreste sincronizzate, esegui il deployment di una foresta Active Directory separata per Google Cloud. Utilizzi questa foresta per gestire le risorse di cui è stato eseguito il deployment su Google Cloud , nonché gli account utente necessari per gestire queste risorse.
Invece di creare una relazione di trust tra la nuova foresta e una foresta on-premise esistente, sincronizzi gli account. Se utilizzi un sistema HRIS come sistema principale per gestire gli account utente, puoi configurare HRIS per il provisioning degli account utente nella foresta Active Directory ospitata da Google Cloud. In alternativa, puoi utilizzare strumenti come Microsoft Identity Manager per sincronizzare gli account utente tra gli ambienti.
Prendi in considerazione l'utilizzo del pattern delle foreste sincronizzate se si verifica una o più delle seguenti condizioni:
- L'utilizzo previsto di Google Cloud corrisponde a uno dei pattern di deployment ridondanti e vuoi evitare dipendenze di runtime tra l'ambiente on-premise e Google Cloud.
- Vuoi mantenere un limite di trust tra l'ambiente Active Directory on-premise e l'ambiente Active Directory ospitato su Google Cloud, come misura di difesa in profondità o perché ti fidi di più di un ambiente rispetto all'altro.
- Prevedi un'interazione minima o nulla tra le risorse gestite da Active Directory on-premise e su Google Cloud.
- Il numero di account utente necessari nell'ambiente Active Directory ospitato da Google Cloudè ridotto.
Vantaggi:
- Il pattern delle foreste sincronizzate consente di mantenere un forte isolamento tra i due ambienti Active Directory. Un utente malintenzionato che compromette un ambiente potrebbe ottenere pochi vantaggi attaccando il secondo ambiente.
- Per utilizzare Active Directory non è necessario configurare la connettività ibrida tra le reti on-premise e Google Cloud .
- L'istanza di Active Directory ospitata da Google Cloudnon è interessata da un'interruzione di Active Directory on-premise. Il pattern è ideale per i casi d'uso di continuità operativa o altri scenari che richiedono un'elevata disponibilità.
- Puoi concedere un elevato livello di autonomia amministrativa ai team che gestiscono la foresta Active Directory ospitata da Google Cloud.
- Questo pattern è supportato da Managed Service for Microsoft Active Directory.
Best practice:
- Non sincronizzare le password degli account utente tra le due foreste di Active Directory. In questo modo, l'isolamento tra gli ambienti viene compromesso.
- Non fare affidamento all'autenticazione pass-through, perché richiede la sincronizzazione delle password degli account utente.
- Assicurati che quando un dipendente lascia l'azienda, i suoi account in entrambi gli ambienti Active Directory siano disattivati o rimossi.
Foresta di risorse
Nel pattern foresta di risorse, esegui il deployment di una foresta Active Directory separata in Google Cloud. Utilizzi questa foresta per gestire le risorse di cui è stato eseguito il deployment in Google Cloud , nonché un insieme minimo di account utente amministrativi necessari per gestire la foresta. Se stabilisci un trust della foresta con la foresta Active Directory on-premise esistente, consenti agli utenti della foresta esistente di autenticarsi e accedere alle risorse gestite dalla foresta Active Directory ospitata daGoogle Cloud.
Se necessario, puoi trasformare questo pattern in una topologia hub-spoke con la foresta Active Directory esistente al centro, collegata a molte foreste di risorse.
Prendi in considerazione l'utilizzo del pattern della foresta di risorse se si verifica una o più delle seguenti condizioni:
- L'utilizzo previsto di Google Cloud corrisponde a uno dei pattern di deployment distribuiti, ed è accettabile una dipendenza tra l'ambiente on-premise e Google Cloud.
- Vuoi mantenere un limite di trust tra l'ambiente Active Directory on-premise e l'ambiente Active Directory ospitato su Google Cloud, come misura di difesa in profondità o perché consideri un ambiente più attendibile dell'altro.
- Prevedi un livello moderato di interazione tra le risorse gestite da Active Directory on-premise e su Google Cloud.
- Hai un numero elevato di utenti che devono accedere alle risorse di cui è stato eseguito il deployment su Google Cloud, ad esempio ad applicazioni web che utilizzano IWA per l'autenticazione.
Vantaggi:
- Il pattern della foresta di risorse consente di mantenere un limite di trust tra i due ambienti Active Directory. A seconda di come è configurato il rapporto di trust, un malintenzionato che compromette un ambiente potrebbe ottenere un accesso minimo o nullo all'altro ambiente.
- Questo pattern è completamente supportato da Managed Microsoft AD.
- Puoi concedere un elevato livello di autonomia amministrativa ai team che gestiscono la foresta Active Directory ospitata da Google Cloud.
Best practice:
- Collega le due foreste di Active Directory utilizzando una relazione di trust unidirezionale in modo che l'istanza di Active Directory ospitata su Google Cloudconsideri attendibile la tua istanza di Active Directory esistente, ma non viceversa.
- Utilizza l'autenticazione selettiva per limitare le risorse in Active Directory ospitato da Google Clouda cui gli utenti di Active Directory on-premise possono accedere.
- Utilizza connessioni Dedicated Interconnect, Partner Interconnect o Cloud VPN ridondanti per garantire una connettività di rete ad alta disponibilità tra la tua rete on-premise e Google Cloud.
Dominio esteso
Nel pattern dominio esteso, estendi uno o più domini Active Directory esistenti a Google Cloud. Per ogni dominio, esegui il deployment di uno o più controller di dominio su Google Cloud, il che comporta la replica e la disponibilità di tutti i dati del dominio e del catalogo globale suGoogle Cloud. Utilizzando siti Active Directory separati per le subnet on-premise e Google Cloud , ti assicuri che i client comunichino con i domain controller più vicini.
Valuta la possibilità di utilizzare il pattern di dominio esteso se si verifica una o più delle seguenti condizioni:
- L'utilizzo previsto di Google Cloud corrisponde a uno dei pattern di deployment ridondanti e vuoi evitare dipendenze di runtime tra l'ambiente on-premise e Google Cloud.
- Prevedi un'interazione intensa tra le risorse gestite di Active Directory on-premise e suGoogle Cloud.
- Vuoi velocizzare l'autenticazione per le applicazioni che si basano su LDAP per l'autenticazione.
Vantaggi:
- L'istanza di Active Directory ospitata da Google Cloudnon è interessata da un'interruzione di Active Directory on-premise. Il pattern è ideale per i casi d'uso di continuità aziendale o altri scenari che richiedono un'elevata disponibilità.
- Puoi limitare la comunicazione tra la rete on-premise e Google Cloud. In questo modo, puoi potenzialmente risparmiare larghezza di banda e migliorare la latenza.
- Tutti i contenuti del catalogo globale vengono replicati in Active Directory e possono essere accessibili in modo efficiente dalle risorse ospitate su Google Cloud.
Best practice:
- Se replichi tutti i domini, la comunicazione tra la rete on-premise e la rete Google Cloud è limitata alla replica di Active Directory tra i controller di dominio. Se replichi solo un sottoinsieme dei domini della foresta, i server aggiunti al dominio in esecuzione su Google Cloud potrebbero comunque dover comunicare con i controller di dominio dei domini non replicati. Assicurati che le regole firewall che si applicano alla comunicazione tra on-premise e Google Cloud considerino tutti i casi pertinenti.
- Tieni presente che la replica tra i siti avviene solo a determinati intervalli, pertanto gli aggiornamenti eseguiti su un domain controller on-premise vengono visualizzati su Google Cloud solo dopo un ritardo (e viceversa).
- Valuta la possibilità di utilizzare controller di dominio di sola lettura (RODC) per mantenere una copia di sola lettura dei dati del dominio su Google Cloud, ma tieni presente che esiste un compromesso relativo alla memorizzazione nella cache delle password degli utenti. Se consenti ai controller di dominio di sola lettura di memorizzare nella cache le password e precompilare la cache delle password, le risorse di cui è stato eseguito il deployment su Google Cloud possono rimanere inalterate da un'interruzione dei controller di dominio on-premise. Tuttavia, i vantaggi in termini di sicurezza dell'utilizzo di un RODC rispetto a un controller di dominio normale sono limitati. Se disattivi la memorizzazione nella cache delle password, un RODC compromesso potrebbe rappresentare un rischio limitato per il resto di Active Directory, ma perdi il vantaggio di Google Cloud che rimane inalterato da un'interruzione dei controller di dominio on-premise.
Foresta estesa
Nel pattern foresta estesa, implementi un nuovo dominio Active Directory su Google Cloud, ma lo integri nella foresta esistente. Utilizzi il nuovo dominio per gestire le risorse di cui è stato eseguito il deployment su Google Cloud e per mantenere un insieme minimo di account utente amministratore per gestire il dominio.
Estendendo le relazioni di attendibilità implicita ad altri domini della foresta, consenti agli utenti esistenti di altri domini di autenticarsi e accedere alle risorse gestite dal dominio Active Directory ospitato da Google Cloud.
Valuta la possibilità di utilizzare il pattern foresta estesa se si verifica una o più delle seguenti condizioni:
- L'utilizzo previsto di Google Cloud corrisponde a uno dei pattern di deployment distribuiti e una dipendenza tra l'ambiente on-premise e Google Cloud è accettabile.
- Le risorse che prevedi di eseguire il deployment richiedono una configurazione o una struttura di dominio diversa da quella fornita dai tuoi domini esistenti oppure vuoi concedere un elevato livello di autonomia amministrativa ai team che amministrano il dominio ospitato da Google Cloud. Google Cloud
- Prevedi un'interazione da moderata a elevata tra le risorse gestite da Active Directory on-premise e su Google Cloud.
- Hai molti utenti che devono accedere alle risorse di cui è stato eseguito il deployment in Google Cloud, ad esempio alle applicazioni web che utilizzano IWA per l'autenticazione.
Vantaggi:
- Tutti i contenuti del catalogo globale verranno replicati in Active Directory e sarà possibile accedervi in modo efficiente dalle risorse ospitate su Google Cloud.
- Il traffico di replica tra la rete on-premise e Google Cloud è limitato alla replica del catalogo globale. In questo modo, potresti limitare il consumo complessivo di larghezza di banda.
- Puoi concedere un elevato livello di autonomia amministrativa ai team che gestiscono il dominio Active Directory ospitato da Google Cloud.
Best practice:
- Utilizza connessioni Dedicated Interconnect, Partner Interconnect o Cloud VPN ridondanti per garantire una connettività di rete a disponibilità elevata tra la tua rete on-premise e Google Cloud.
Foresta di risorse con dominio esteso
Il pattern foresta di risorse con dominio esteso è un'estensione del pattern foresta di risorse. Il pattern della foresta di risorse consente di mantenere un limite di attendibilità tra gli ambienti e di fornire autonomia amministrativa. Una limitazione della foresta di risorse è che la sua disponibilità complessiva dipende dalla disponibilità dei controller di dominio on-premise e dalla connettività di rete affidabile al data center on-premise.
Puoi superare queste limitazioni combinando il pattern della foresta di risorse con il pattern del dominio esteso. Se replichi il dominio, i tuoi account utente si trovano in Google Cloude puoi assicurarti che gli utenti possano autenticarsi alle risorse ospitate su Google Cloudanche quando i controller di dominio on-premise non sono disponibili o la connettività di rete viene persa.
Valuta la possibilità di utilizzare la foresta di risorse con il pattern di dominio esteso se si verifica una o più delle seguenti condizioni:
- Vuoi mantenere un limite di trust tra la foresta Active Directory principale e la foresta di risorse.
- Vuoi evitare che un'interruzione dei controller di dominio on-premise o la perdita di connettività di rete al tuo ambiente on-premise influiscano sui tuoi carichi di lavoro ospitati suGoogle Cloud.
- Prevedi un'interazione moderata tra le risorse gestite da Active Directory on-premise e su Google Cloud.
- Hai molti utenti di un singolo dominio Active Directory che devono accedere alle risorse di cui è stato eseguito il deployment su Google Cloud, ad esempio per applicazioni web che utilizzano IWA per l'autenticazione.
Vantaggi:
- Le risorse ospitate suGoogle Cloudnon sono interessate da un'interruzione di Active Directory on-premise. Il pattern è adatto a casi d'uso di continuità aziendale o ad altri scenari che richiedono alta disponibilità.
- Il pattern ti consente di mantenere un limite di trust tra le due foreste di Active Directory. A seconda di come è configurata la relazione di trust, un malintenzionato che compromette un ambiente potrebbe ottenere un accesso minimo o nullo all'altro ambiente.
- La comunicazione tra la rete on-premise e la rete Google Cloud è limitata alla replica di Active Directory tra i controller di dominio. Puoi implementare regole firewall per non consentire tutte le altre comunicazioni, rafforzando l'isolamento tra gli ambienti
- Puoi concedere un elevato livello di autonomia amministrativa ai team che gestiscono la foresta Active Directory ospitata da Google Cloud.
- Puoi utilizzare Microsoft Active Directory gestito per la foresta di risorse.
Best practice:
- Esegui il deployment dei domain controller per il dominio esteso in un progettoGoogle Cloud e in un VPC separati per separare questi componenti da quelli della foresta di risorse.
- Utilizza il peering VPC per connettere il VPC al VPC condiviso o al VPC utilizzato dalla foresta di risorse e configura i firewall per limitare la comunicazione all'autenticazione utente Kerberos e alla creazione di trust tra foreste.
- Collega le due foreste di Active Directory utilizzando una relazione di trust unidirezionale in modo che Active Directory ospitato su Google Cloudconsideri attendibile la tua foresta di Active Directory esistente, ma non viceversa.
- Utilizza l'autenticazione selettiva per limitare le risorse nella foresta di risorse a cui gli utenti di altre foreste possono accedere.
- Tieni presente che la replica tra i siti avviene solo a determinati intervalli, pertanto gli aggiornamenti eseguiti su un domain controller on-premise vengono visualizzati suGoogle Cloud solo dopo un ritardo (e viceversa).
- Valuta la possibilità di utilizzare i controller di dominio di sola lettura per il dominio esteso, ma assicurati di consentire la memorizzazione nella cache delle password per preservare i vantaggi di disponibilità rispetto al pattern della foresta di risorse.
Passaggi successivi
- Scopri di più su Managed Microsoft AD.
- Consulta le best practice per il deployment di una foresta di risorse Active Directory su Google Cloud.
- Scopri come eseguire il deployment di un ambiente Active Directory a tolleranza di errore su Google Cloud.
- Esamina le nostre best practice sulla progettazione del VPC.
- Per ulteriori architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.