Questo documento illustra i requisiti da considerare quando esegui il deployment a Google Cloud e ti aiuta a scegliere dell'architettura.
Mediante la federazione di Active Directory con Cloud Identity o Google Workspace (vedi Pattern per l'autenticazione degli utenti della forza lavoro in un ambiente ibrido), puoi consentire agli utenti dei tuoi domini Active Directory esistenti di eseguire l'autenticazione 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 che non sono supportati da Google Cloud.
Prima di eseguire il deployment di Active Directory in Google Cloud, devi decidere quale architettura di dominio e foresta utilizzare e come eseguire l'integrazione la foresta di 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 su più ambienti. In alternativa, puoi utilizzare domini separati o foreste e le collega utilizzando trust. L'architettura migliore dipende i tuoi requisiti.
Per scegliere l'architettura migliore, considera questi fattori:
- Allineamento alle zone di sicurezza esistenti
- Interazione tra risorse on-premise e Google Cloud
- Autonomia amministrativa
- Disponibilità
Le sezioni seguenti illustrano questi fattori.
Allineamento alle zone di sicurezza esistenti
Per iniziare, rivedi la progettazione della tua rete on-premise.
Nell'ambiente on-premise, potresti aver suddiviso 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 oppure soggetti a criteri firewall e di controllo semplici. Al contrario, qualsiasi comunicazione tra zone di sicurezza è soggetta a criteri rigorosi di firewall, controllo o ispezione del traffico.
L'intento delle zone di sicurezza è più vasto che limitarsi a vincolare e delle comunicazioni di rete, tuttavia, le zone di sicurezza dovrebbero implementare confini.
Limiti di trust
Ogni macchina di una rete esegue diversi processi. Questi processi possono comunicare tra loro localmente tramite comunicazioni inter-process, potrebbero comunicare tra le macchine usando protocolli come HTTP. In questo comunicano, i colleghi non sempre si fidano degli altri nella stessa misura. Ad esempio, i processi potrebbero considerare attendibili quelli in esecuzione più macchine rispetto ai processi in esecuzione su altre macchine. E alcuni potrebbero essere considerate più affidabili di altre.
Un confine di attendibilità impone la discriminazione tra le comunicazioni parti, affidando a un gruppo di parti di comunicazione più di un altro parti.
I confini di attendibilità sono fondamentali per contenere l'impatto di un attacco. Gli attacchi raramente terminano dopo la compromissione di un singolo sistema, che si tratti di un singolo processo o di un'intera macchina. È più probabile che un malintenzionato provi a estendere l'attacco ad altri sistemi. Poiché i sistemi in un confine di attendibilità discriminare tra loro, diffondendo un attacco all'interno del confine di fiducia è più facile che attaccare i sistemi attraverso un confine di attendibilità.
Una volta che un sistema in un confine di attendibilità è stato compromesso, si deve presumere che tutti gli altri sistemi in quel confine di attendibilità siano compromessi. Questa ipotesi può aiutare identificare i confini di attendibilità o verificare se un determinato confine del sistema è limite di attendibilità, ad esempio:
Supponiamo che un utente malintenzionato abbia raggiunto il massimo livello di accesso scegliere come target A (ad esempio, amministratore o accesso root a una macchina applicazione). Se può sfruttare questi privilegi per ottenere lo stesso livello di accesso al target B, A e B si trovano, per definizione, nello stesso ambito di attendibilità. In caso contrario, un confine di attendibilità si trova tra A e B.
Bloccando la comunicazione di rete, le zone di sicurezza possono aiutare a implementare limiti di attendibilità. Tuttavia, affinché una zona di sicurezza diventi un vero e proprio confine di attendibilità, i carichi di lavoro su ciascun lato del confine devono distinguere tra richieste provenienti dalla stessa zona di sicurezza e richieste provenienti da zone di sicurezza diverse e esaminare più da vicino quest'ultime.
Modello Zero Trust
Il modello Zero Trust è il modello di rete preferito su Google Cloud.
Se un singolo sistema è compromesso in un confine di attendibilità, puoi presumere che tutti i sistemi al suo interno siano compromessi. Questo presupposto suggerisce che confini di attendibilità più piccoli siano migliori. Più piccolo è il confine di attendibilità, meno sistemi vengono compromessi e più confini deve superare un malintenzionato per diffondere un attacco.
Il modello Zero Trust porta questa idea alla sua logica conclusione: ogni macchina in la rete viene trattata come una zona di sicurezza e un confine di attendibilità univoci. Tutte le comunicazioni tra le macchine sono soggette alle stesse verifiche e alla stessa applicazione di firewall e tutte le richieste di rete vengono trattate come provenienti da una fonte non attendibile.
A livello di rete, puoi implementare un modello zero trust utilizzando regole firewall per limitare il traffico e log di flusso VPC e logging delle regole firewall per analizzare il traffico. A livello di applicazione, devi assicurarti che tutte le applicazioni gestiscano in modo coerente e sicuro l'autenticazione, l'autorizzazione e il controllo.
Limiti di attendibilità in Active Directory
In un dominio Active Directory, le macchine si affidano ai controller di dominio per gestire l'autenticazione e l'autorizzazione per conto loro. Una volta che un utente ha dimostrato la propria a uno dei controller di dominio, possono accedere per impostazione predefinita a tutti più macchine dello stesso dominio. Qualsiasi diritto di accesso concesso all'utente dalla il controller di dominio (sotto forma di privilegi e iscrizioni a gruppi) si applicano molte macchine del dominio.
Utilizzando i criteri di gruppo, puoi impedire agli utenti di accedere a determinati computer o limitare i propri diritti su alcuni computer. Una volta che una macchina compromesso, tuttavia, un aggressore potrebbe riuscire a rubare password, hash delle password o token Kerberos di utenti di altri domini che hanno eseguito l'accesso allo stesso computer. L'utente malintenzionato può quindi sfruttare queste credenziali per estendere l'attacco ad altri domini della foresta.
Dati questi fattori, è meglio presumere che tutte le macchine in una foresta si trovino in un confine di sicurezza attendibile.
Rispetto ai confini di dominio, il cui scopo è controllare la replica e concedere l'autonomia amministrativa a parti diverse dell'organizzazione, i confini della foresta possono fornire un isolamento più efficace. Le foreste possono fungere da confine di attendibilità.
Allineamento delle foreste e delle zone di sicurezza di Active Directory
supporre che la foresta sia il confine di fiducia influenza la progettazione della sicurezza diverse. Se una foresta si estende su due zone di sicurezza, è più facile un malintenzionato per liberare il confine tra queste zone di sicurezza. Di conseguenza, due zone di sicurezza diventano effettivamente una e formano un unico confine di attendibilità.
In un modello Zero Trust, ogni macchina di una rete può essere considerata come una zona di sicurezza distinta. Il deployment di Active Directory in una rete di questo tipo compromette questo concetto e amplia il confine di sicurezza effettivo per includere tutte le macchine della foresta di Active Directory.
Affinché una zona di sicurezza possa fungere da confine di attendibilità, devi assicurarti che l'intera foresta Active Directory si trovi nella zona di sicurezza.
Impatto sull'estensione di Active Directory a Google Cloud
Quando pianifichi un deployment in Google Cloud che richiede Active Directory, è necessario scegliere tra due opzioni per allineare il deployment zone di sicurezza:
Estendi una zona di sicurezza esistente a Google Cloud. Puoi estendi una o più zone di sicurezza esistenti a Google Cloud eseguire il provisioning del VPC condiviso su Google Cloud e la sua connessione la zona esistente usando Cloud VPN o Cloud Interconnect.
Risorse con deployment on-premise e su Google Cloud che condividono una zona può anche condividere una foresta di Active Directory comune, il deployment di una foresta separata in Google Cloud.
Consideriamo, ad esempio, una rete esistente che ha una rete perimetrale e la rete perimetrale di produzione come zone di sicurezza con Foresta di directory in ogni zona di sicurezza. Se estendi le zone di sicurezza a Google Cloud, anche tutti i deployment su Google Cloud vengono parte di una di queste due zone di sicurezza e può usare lo stesso Foreste directory.
Introduzione di 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 tue zone di sicurezza esistenti non corrispondono ai requisiti dei tuoi implementazioni di Google Cloud. Puoi considerare Google Cloud come le aree di sicurezza.
Ad esempio, prendi in considerazione un ambiente on-premise con una rete perimetrale, ma che non distingue tra carichi di lavoro di sviluppo e di produzione. Per separare questi carichi di lavoro su Google Cloud, puoi creare due VPC condivisi e considerarli nuove zone di sicurezza. Poi, esegui il deployment di altri due forest di Active Directory su Google Cloud, uno per ogni zona di sicurezza. Se necessario, puoi stabilire relazioni di fiducia tra le foreste per abilitare l'autenticazione in più 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 tra utenti e risorse on-premise e Google Cloud. A seconda del caso d'uso, questa interazione può essere da leggera ad elevata.
Interazione leggera
Se l'unico scopo dell'utilizzo di Active Directory su Google Cloud è gestire un parco di server Windows e per consentire agli amministratori di accedere tra i server, il livello di interazione tra gli ambienti è basso:
- L'insieme di dipendenti che interagisce con le risorse su Google Cloud è solo al personale amministrativo.
- Le applicazioni di cui è stato eseguito il deployment in Google Cloud potrebbero non interagire delle applicazioni on-premise o lo farebbero senza affidarsi a Windows strumenti di autenticazione come Kerberos e NTLM.
In uno scenario leggero, valuta la possibilità di integrare i tuoi carichi di lavoro on-premise ambienti Google Cloud in uno dei due modi seguenti:
Due foreste Active Directory distinte: puoi isolare i due ambienti utilizzando due foreste Active Directory separate che non condividono una relazione di attendibilità. Per consentire agli amministratori di eseguire l'autenticazione, mantenere un insieme separato di account utente in Google Cloud in una foresta.
Mantenere un insieme duplicato di account utente aumenta le e introduce il rischio di dimenticarsi di disattivare gli account i dipendenti lasciano l'azienda. Un approccio migliore è eseguire il provisioning automaticamente.
Se il provisioning degli account utente nella tua Active Directory on-premise viene eseguito da un Sistema informatico delle risorse umane (HRIS), potresti essere in grado di utilizzare un meccanismo simile per eseguire il provisioning e la gestione degli account utente la foresta di Google Cloud. In alternativa, puoi utilizzare strumenti come Microsoft Identity Manager per sincronizzare gli account utente tra ambienti cloud-native.
Due foreste di Active Directory con attendibilità tra foreste: utilizzando due le foreste di Active Directory e il loro collegamento con un trust tra foreste, evitare di dover mantenere account duplicati. Gli amministratori utilizzano lo stesso account utente per autenticarsi in entrambi gli ambienti. Sebbene il livello di isolamento tra gli ambienti possa essere considerato più debole, l'utilizzo di foreste separate ti consente di mantenere un confine di attendibilità tra il tuo ambiente on-premise e quello Google Cloud.
Interazione moderata
Il tuo caso d'uso potrebbe essere più complesso. Ad esempio:
- Gli amministratori accedono ai server Windows su cui è stato eseguito il deployment Google Cloud potrebbe dover accedere alle condivisioni file ospitate on-premise.
- Le applicazioni potrebbero utilizzare Kerberos o NTLM per autenticarsi e comunicare tra i confini dell'ambiente.
- Potresti voler consentire ai dipendenti di utilizzare l'autenticazione integrata di Windows (IWA) per autenticarsi nelle applicazioni web di cui è stato eseguito il deployment su Google Cloud.
In uno scenario moderato, l'utilizzo di due foreste Active Directory separate potrebbe essere troppo limitante: non puoi utilizzare Kerberos per l'autenticazione tra le due foreste, e l'utilizzo di NTLM autenticazione passthrough richiede di mantenere sincronizzati gli account utente e le password.
In questo caso, consigliamo di utilizzare due foreste di Active Directory con un tra foreste.
Interazione intensa
Alcuni carichi di lavoro, tra cui i deployment dell'infrastruttura desktop virtuale (VDI), potrebbero richiedere un'interazione elevata tra risorse e risorse on-premise di cui è stato eseguito il deployment in Google Cloud. Quando le risorse tra gli ambienti sono strettamente correlate, provare a mantenere un confine di attendibilità 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, consigliamo di utilizzare un'unica foresta di Active Directory e di da più ambienti.
Autonomia amministrativa
Il terzo fattore da considerare quando estendi Active Directory Google Cloud è autonomia amministrativa.
Se hai intenzione di distribuire i carichi di lavoro tra on-premise e Google Cloud, i carichi di lavoro che eseguirai su Google Cloud potrebbero essere rispetto ai carichi di lavoro che mantieni on-premise. Potresti anche decidere che i due ambienti debbano essere gestiti da team diversi.
La separazione delle responsabilità tra team diversi richiede di concedere a ciascun team un po' di autonomia amministrativa. In Active Directory, puoi concedere ai team l'autorità competente per la gestione delle risorse amministrazione delegata o utilizzando domini separati.
L'amministrazione delegata è una soluzione delegare le mansioni amministrative e concedere una certa autonomia ai team. La gestione di un unico dominio può anche aiutarti a garantire la coerenza tra ambienti e team.
Tuttavia, non puoi delegare tutte le capacità amministrative e dominio singolo può aumentare l'overhead amministrativo del coordinamento tra team di sicurezza. In tal caso, consigliamo di utilizzare domini separati.
Disponibilità
L'ultimo fattore da considerare quando estendi Active Directory Google Cloud è la disponibilità. Per ogni dominio in una Active Directory foresta, il controller di dominio funge da provider di identità per gli utenti in 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-granting ticket).
- Riconvalida periodica (aggiornamento di un ticket-granting ticket).
- Autenticazione con una risorsa (ottenimento di un ticket di servizio).
L'esecuzione dell'autenticazione iniziale e della riautenticazione periodica richiede che comunica con un solo controller di dominio, 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ò di utilizzare lo stesso controller di dominio (o un altro controller di dominio stesso dominio) per completare il processo di autenticazione.
- Se la risorsa si trova in un dominio diverso, ma è presente un indirizzo in un rapporto di fiducia con il dominio dell'utente, quest'ultimo deve interagire almeno due controller di dominio: uno nel dominio delle risorse e uno nel dominio dell'utente.
- Se la risorsa e l'utente fanno parte di domini diversi e c'è solo una relazione di fiducia indiretta tra questi domini, quindi l'autenticazione richiede comunicare con i controller di dominio di ogni dominio nel percorso di attendibilità.
Localizzazione di utenti e risorse in diversi domini o foreste di Active Directory può limitare la disponibilità complessiva. Perché per l'autenticazione è necessario interagire con più domini, l'interruzione di un dominio può influire sulla disponibilità risorse in altri domini.
Considerando il potenziale impatto della topologia di Active Directory availability [disponibilità], consigliamo di allineare la topologia di Active Directory all'ambiente strategia.
Carichi di lavoro distribuiti
Per sfruttare al meglio le capacità uniche di ciascun ambiente di computing, potrebbe usare un approccio ibrido distribuire i carichi di lavoro tra questi ambienti. In una configurazione di questo tipo, è probabile che i carichi di lavoro di cui esegui il deployment su Google Cloud dipendono da altre infrastrutture o applicazioni in esecuzione on-premise, disponibilità elevata connettività ibrida un requisito fondamentale.
Se esegui il deployment di una foresta o di un dominio Active Directory separato in Google Cloud e utilizzare un trust per connetterlo alla tua 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à.
Carichi di lavoro ridondanti
Se usi Google Cloud per garantire la continuità aziendale, i carichi di lavoro su Google Cloud esegui il mirroring di alcuni carichi di lavoro dell'ambiente on-premise. Questa configurazione abilita una di assumere il ruolo dell'altro ambiente nel caso in cui che si verifica un errore. È quindi necessario considerare ogni dipendenza tra questi ambienti cloud-native.
Se esegui il deployment di una foresta o di un dominio Active Directory separato in Google Cloud e utilizzare un trust per connetterlo alla tua Active Directory on-premise, una dipendenza che compromette lo scopo della configurazione. Se l'Active Directory on-premise diventa non disponibile, tutti i carichi di lavoro di cui è stato eseguito il deployment Google Cloud che si basa sull'autenticazione interdominio o tra foreste non saranno più disponibili.
Se il tuo obiettivo è garantire la continuità aziendale, puoi utilizzare foreste Active Directory separate in ogni ambiente che non sono collegate tra loro. In alternativa, puoi estendere un dominio Active Directory esistente a Google Cloud. Eseguendo il deployment di controller di dominio aggiuntivi Google Cloud e la replica dei contenuti delle directory tra ambienti, garantire che gli ambienti funzionino in modo isolato.
Pattern di integrazione
Dopo aver valutato i requisiti, utilizza la seguente struttura decisionale per aiutarti a identificare un'architettura di foresta e dominio adatta.
Nelle sezioni seguenti viene descritto ciascun pattern.
Foreste sincronizzate
Nel pattern delle foreste sincronizzate, esegui il deployment di un'istanza Active Directory separata in Google Cloud. Utilizza 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 attendibilità tra la nuova foresta e una foresta on-premise esistente, sincronizzi gli account. Se utilizzi un HRIS come sistema principale per gestire gli account utente, puoi configurare l'HRIS in modo che esegua il provisioning degli account utente nella foresta di Active Directory in hosting su Google Cloud. In alternativa, puoi utilizzare strumenti come Microsoft Identity Manager per sincronizzare gli account utente tra gli ambienti.
Valuta la possibilità di utilizzare il pattern Foreste sincronizzate se si applica uno o più dei seguenti casi:
- L'utilizzo previsto di Google Cloud corrisponde a uno dei pattern di deployment ridondanti e vuoi evitare dipendenze di runtime tra il tuo ambiente on-premise e Google Cloud.
- Vuoi mantenere un confine di attendibilità tra le tue istanze attive on-premise Ambiente di directory e Active Directory ospitato su Google Cloud dell'ambiente di rete, come difesa in profondità misurare o perché ti fidi di un ambiente più dell'altro.
- Non prevedi alcuna o poca interazione tra le risorse gestite da Active Directory on-premise e su Google Cloud.
- Il numero di account utente necessari nell'ambiente Active Directory ospitato su Google Cloud è ridotto.
Vantaggi:
- Il pattern delle foreste sincronizzate ti consente di mantenere un'isolamento rigoroso tra i due ambienti Active Directory. Un utente malintenzionato che compromette un ambiente potrebbe trarre scarso vantaggio dall'attacco del secondo ambiente.
- Per utilizzare Active Directory, non è necessario configurare la connettività ibrida tra le reti on-premise e Google Cloud.
- L'Active Directory ospitata su Google Cloud non è interessata da un della tua Active Directory on-premise. Lo schema è adatta per casi d'uso di continuità aziendale o altri scenari che richiedono l'alta disponibilità.
- Puoi concedere un elevato livello di autonomia amministrativa ai team che gestiscono la foresta Active Directory ospitata su Google Cloud.
- Questo pattern è supportato da Managed Service for Microsoft Active Directory.
Best practice:
- Non sincronizzare le password degli account utente tra i due forest di Active Directory. In questo modo, viene minato l'isolamento tra gli ambienti.
- Non fare affidamento sull'autenticazione passthrough, 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 vengano disattivati o rimossi.
Foresta di risorse
Nel pattern foresta di risorse, esegui il deployment di una foresta Active Directory distinta su Google Cloud. Utilizza questa foresta per gestire le risorse di cui è stato eseguito il deployment in Google Cloud, nonché un insieme minimo di account utente amministrativo necessari per la gestione della 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 su Google Cloud.
Se necessario, puoi trasformare questo pattern in una topologia hub e spoke con alla foresta Active Directory esistente al centro, connessa a molte foreste.
Valuta l'utilizzo del pattern della foresta delle risorse se uno o più dei seguenti elementi si applica:
- L'utilizzo previsto di Google Cloud rientra in uno dei pattern di deployment distribuito, e una dipendenza tra l'ambiente on-premise e Google Cloud è accettabile.
- Vuoi mantenere un confine di attendibilità tra il tuo ambiente Active Directory on-premise e l'ambiente Active Directory ospitato in Google Cloud, come misura di difesa in profondità o perché ritieni 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 alle applicazioni web che utilizzano l'autenticazione IWA.
Vantaggi:
- Il pattern della foresta di risorse ti consente di mantenere un confine di attendibilità tra i due ambienti Active Directory. A seconda di come è configurato il rapporto di attendibilità, un malintenzionato che compromette un ambiente potrebbe ottenere un accesso ridotto 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 su Google Cloud.
Best practice:
- Connetti le due foreste di Active Directory utilizzando un trust unidirezionale l'Active Directory ospitata su Google Cloud considera attendibile il tuo Active Directory Google Cloud, ma non il contrario.
- Utilizza l'autenticazione selettiva per limitare le risorse in Active Directory ospitato su Google Cloud a cui gli utenti di Active Directory on-premise sono autorizzati ad accedere.
- Utilizza connessioni redundanti di Dedicated Interconnect, Partner Interconnect o Cloud VPN per garantire una connettività di rete altamente disponibile tra la tua rete on-premise e Google Cloud.
Dominio esteso
Nel pattern del dominio esteso, estendi uno o più dei tuoi asset esistenti domini Active Directory a Google Cloud. Per ogni dominio, esegui il deployment di uno o più controller di dominio su Google Cloud, per cui tutti i dati di dominio e il catalogo globale da replicare e rendere disponibile in Google Cloud. Se utilizzi siti Active Directory separati per le sottoreti on-premise e Google Cloud, garantisci che i client comunichino con i controller di dominio più vicini.
Valuta l'utilizzo del pattern del dominio esteso se uno o più dei seguenti elementi si applica:
- L'utilizzo previsto di Google Cloud corrisponde a uno dei modelli di deployment ridondanti e vuoi evitare dipendenze di runtime tra il tuo ambiente on-premise e Google Cloud.
- Prevedi una forte interazione tra le risorse gestite da Active Directory on-premise e su Google Cloud.
- Vuoi velocizzare l'autenticazione per le applicazioni che si basano su LDAP per l'autenticazione.
Vantaggi:
- L'Active Directory ospitata su Google Cloud non è interessata da un della tua Active Directory on-premise. Lo schema è adatta per casi d'uso di continuità aziendale o altri scenari che richiedono l'alta disponibilità.
- Puoi limitare la comunicazione tra la tua rete on-premise in 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 ed è accessibile in modo efficiente dalle risorse ospitate da 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 tua foresta, i server uniti 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 le comunicazioni tra on-premise e Google Cloud considerano pertinenti.
- Tieni presente che la replica tra siti avviene solo a determinati intervalli, pertanto gli aggiornamenti eseguiti su un'istanza di controller di dominio on-premise vengono applicati a 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 di dominio su Google Cloud, ma tieni presente che esiste un compromesso relativo alla memorizzazione nella cache delle password utente. Se consenti ai RODC di memorizzare le password nella cache e precompilare la cache delle password, Le risorse di cui è stato eseguito il deployment su Google Cloud possono non essere interessate da un'interruzione dei controller di dominio on-premise. Tuttavia, i vantaggi in termini di sicurezza dell'utilizzo di un RODC rispetto a un normale controller di dominio sono limitati. Se disattivi la memorizzazione nella cache delle password, un RODC compromesso potrebbe rappresentare un rischio limitato solo per il resto di Active Directory, ma perderai il vantaggio di avere Google Cloud inalterato da un'interruzione dei controller di dominio on-premise.
Foresta estesa
Nel pattern foresta estesa, esegui il deployment di un nuovo dominio Active Directory su Google Cloud, ma lo integri nella foresta esistente. Utilizza 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 amministrativo per la gestione del dominio.
Estendendo le relazioni di attendibilità implicite ad altri domini della foresta, consente agli utenti esistenti di altri domini di autenticarsi e accedere alle risorse gestite dal dominio Active Directory ospitato in Google Cloud.
Valuta l'utilizzo del motivo della foresta estesa se uno o più dei seguenti elementi si applica:
- 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.
- Le risorse che prevedi di eseguire il deployment in Google Cloud richiedono una configurazione o una struttura del 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 su 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 su Google Cloud, ad esempio alle applicazioni web che utilizzano l'autenticazione IWA.
Vantaggi:
- Tutti i contenuti del catalogo globale verranno replicati in Attivo a cui è possibile accedere in modo efficiente dalla piattaforma Google Cloud.
- del traffico di replica tra la rete on-premise Google Cloud è limitato alla replica del catalogo globale. Questa operazione potrebbe essere utile per 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 in Google Cloud.
Best practice:
- Utilizza connessioni redundanti di Dedicated Interconnect, Partner Interconnect o Cloud VPN 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 ti consente di mantenere un confine di attendibilità da un ambiente all'altro e 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 foresta di risorse con il pattern di dominio esteso. Replicando il dominio, i tuoi account utente si trovano in Google Cloud, e puoi assicurarti che gli utenti possano autenticarsi sui delle risorse anche quando i controller di dominio on-premise non sono disponibili si è interrotta.
Valuta l'utilizzo della foresta di risorse con un pattern del dominio esteso, se presente o più dei seguenti requisiti:
- Vuoi mantenere un confine di attendibilità tra la rete principale La foresta di directory e la foresta di risorse.
- Vuoi evitare che un'interruzione dei controller di dominio on-premise o la perdita della connettività di rete con il tuo ambiente on-premise influisca sui tuoi carichi di lavoro ospitati su Google Cloud.
- Prevedi un'interazione moderata tra le istanze gestite da Active Directory di risorse on-premise e su Google Cloud.
- Hai molti utenti da un singolo dominio Active Directory che devono accedere a risorse di cui è stato eseguito il deployment su Google Cloud, ad esempio per web che usano IWA per l'autenticazione.
Vantaggi:
- Le risorse ospitate da Google Cloud non sono interessate da un'interruzione del l'Active Directory on-premise. Il pattern è adatto per i casi d'uso della continuità aziendale o per altri scenari che richiedono un'alta disponibilità.
- Il pattern ti consente di mantenere un confine di attendibilità tra le due foreste Active Directory. A seconda di come è configurato il rapporto di attendibilità, un malintenzionato che compromette un ambiente potrebbe ottenere poco o nessun accesso 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 gestire la foresta di Active Directory in hosting su Google Cloud.
- Puoi utilizzare Microsoft Active Directory gestito per la foresta di risorse.
Best practice:
- Esegui il deployment dei controller di dominio per il dominio esteso in un'istanza del progetto Google Cloud VPC in modo da separare questi componenti dai componenti della risorsa in una foresta.
- 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 della foresta attendibile.
- Connetti le due foreste di Active Directory utilizzando un trust unidirezionale l'Active Directory ospitata su Google Cloud considera attendibile il tuo Active Directory Foresta di directory, ma non il contrario.
- Utilizza l'autenticazione selettiva per limitare le risorse nella risorsa foresta a cui possono accedere gli utenti di altre foreste.
- Tieni presente che la replica tra siti avviene a determinati intervalli quindi gli aggiornamenti eseguiti sulla piattaforma di un controller di dominio on-premise Google Cloud solo dopo un ritardo (e viceversa).
- Valuta la possibilità di utilizzare i controller RODC per il dominio esteso, ma assicurati di consentire la memorizzazione nella cache delle password per preservare i vantaggi in termini di disponibilità rispetto al pattern foresta di risorse.
Passaggi successivi
- Scopri di più su Microsoft AD gestito.
- Rivedi best practice per il deployment di una foresta di risorse Active Directory su Google Cloud.
- Scopri come eseguire il deployment in Google Cloud di un ambiente Active Directory a tolleranza di errore.
- Consulta le nostre best practice per la progettazione di VPC.
- Per altre architetture di riferimento, diagrammi e best practice, esplora il Centro architetture cloud.