Questo documento illustra i requisiti da considerare quando esegui il deployment di Active Directory in Google Cloud e ti aiuta a scegliere l'architettura corretta.
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 autenticare 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 dai tuoi requisiti.
Per scegliere l'architettura migliore, prendi in considerazione questi fattori:
- Allinearsi 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 prima cosa, esamina il design 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 è senza restrizioni o soggetta solo a criteri di firewall e controllo leggeri. Al contrario, qualsiasi comunicazione tra zone di sicurezza è soggetta a rigidi criteri 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 in 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 molto più della macchina 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 limiti di attendibilità sono fondamentali per contenere l’impatto di un attacco. Attacchi raramente terminano una volta che un singolo sistema è stato compromesso, indipendentemente dal fatto che si tratti di un un singolo processo o un'intera macchina. È probabile che un aggressore tenti di per estendere l'attacco ad altri sistemi. Poiché i sistemi all'interno di un confine di attendibilità non fanno distinzioni tra loro, è più facile diffondere un attacco all'interno di questo confine di attendibilità rispetto ad attaccare i sistemi al di là di 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ò aiutarti a identificare i confini di attendibilità o a verificare se un determinato confine di sistema è un confine 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 possono sfruttare questi privilegi per ottenere lo stesso livello di accesso al target B, allora A e B sono, per definizione, all'interno dello stesso confine 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 quest'ultime più da vicino.
Modello Zero Trust
Il modello Zero Trust è il modello di networking preferito su Google Cloud.
Se un singolo sistema è compromesso in un confine di attendibilità, puoi presumere che tutti i sistemi all'interno di quel confine siano compromessi. Questo presupposto suggerisce che i confini della fiducia sono migliori. Più piccolo è il confine di attendibilità, minore è il numero di sistemi sono compromessi e maggiori sono i confini che un aggressore deve sgombrare affinché un attacco si diffonda.
Il modello Zero Trust porta questa idea alla sua conclusione logica: ogni macchina della rete viene trattata come una zona di sicurezza e un confine di attendibilità unici. Tutti le comunicazioni tra le macchine sono soggette allo stesso controllo e al livello di firewall, e tutte le richieste di rete vengono trattate come provenienti da una fonte non attendibile.
A livello di networking, 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 ritengono attendibili i controller di dominio per gestire l'autenticazione e l'autorizzazione per loro conto. 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 dal controller di dominio (sotto forma di privilegi e iscrizioni a gruppi) si applica 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 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 dei domini, il cui scopo è controllare replica e concessione di autonomia amministrativa a diverse parti dell'organizzazione, i confini delle foreste possono fornire un isolamento maggiore. Le foreste possono svolgono la funzione di confine di attendibilità.
Allineamento di foreste e zone di sicurezza di Active Directory
L'assunzione della foresta come confine di attendibilità influisce sulla progettazione delle zone di sicurezza. Se una foresta si estende su due zone di sicurezza, è più facile per un malintenzionato superare il confine tra queste zone. Di conseguenza, due zone di sicurezza diventano effettivamente una e formano un unico confine di attendibilità.
In un modello Zero Trust, ogni macchina in una rete può essere considerata una in una zona di sicurezza separata. 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 funzioni come confine di attendibilità, devi assicurarti che l'intera foresta di Active Directory si trova 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:
Estendere una zona di sicurezza esistente a Google Cloud. Puoi estendere una o più zone di sicurezza esistenti a Google Cloud eseguendo il provisioning di un VPC condiviso su Google Cloud e collegandolo alla zona esistente utilizzando 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.
Ad esempio, prendi in considerazione 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 vengono parte di una di queste due zone di sicurezza e può usare lo stesso Foreste directory.
Introduci nuove zone di sicurezza. Ampliamento di una sicurezza perché questa zona potrebbe non essere applicabile, perché non vuoi non si espande una zona o perché i requisiti di sicurezza le zone di sicurezza non corrispondono ai requisiti di Google Cloud deployment di machine learning. Puoi considerare Google Cloud come le aree di sicurezza.
Considera ad esempio un ambiente on-premise che ha un perimetro rete, ma non fa distinzione tra sviluppo e produzione carichi di lavoro con scale out impegnativi. Per separare questi carichi di lavoro su Google Cloud, puoi creare due VPC condivisi e considerarli nuove zone di sicurezza. Poi eseguire il deployment di due foreste Active Directory in Google Cloud, per ogni zona di sicurezza. Se necessario, puoi stabilire relazioni di attendibilità tra le foreste per abilitare l'autenticazione nelle zone di sicurezza.
Interazione tra risorse on-premise e Google Cloud
Il secondo fattore da considerare quando estendi Active Directory Google Cloud è l'interazione di utenti e risorse tra on-premise e Google Cloud. A seconda del caso d'uso, questa interazione potrebbe essere ovunque, da leggera a intensa.
Interazione con la luce
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 interagiscono con le risorse su Google Cloud è limitado al personale amministrativo.
- Le applicazioni di cui è stato eseguito il deployment su Google Cloud potrebbero non interagire affatto con le applicazioni on-premise o potrebbero farlo senza fare affidamento su strutture di autenticazione di Windows come Kerberos e NTLM.
In uno scenario semplice, valuta la possibilità di integrare i tuoi ambienti on-premise e Google Cloud in uno dei seguenti due modi:
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 di questi account automaticamente.
Se il provisioning degli account utente in Active Directory on-premise viene eseguito da un sistema di informazioni sulle risorse umane (HRIS), potresti essere in grado di utilizzare un meccanismo simile per eseguire il provisioning e gestire gli account utente nella foresta Google Cloud. In alternativa, puoi utilizzare strumenti come Microsoft Identity Manager per sincronizzare gli account utente tra gli ambienti.
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 eseguire l'autenticazione in entrambi gli ambienti. Sebbene il livello di isolamento tra gli ambienti può essere considerato più debole, usando foreste ti consente di mantenere un confine di fiducia tra nell'ambiente on-premise e 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 l'autenticazione e la comunicazione oltre i confini ambientali.
- 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, inclusi i deployment di Virtual Desktop Infrastructure (VDI), potrebbero richiedere un'interazione intensa tra le risorse on-premise e quelle implementate su Google Cloud. Quando le risorse nei vari ambienti sono strettamente dall'accoppiamento, il tentativo di mantenere un confine di attendibilità tra gli ambienti potrebbe non essere pratici e l'utilizzo di due foreste con un trust tra foreste può essere troppo limitante.
In questo caso, ti consigliamo di utilizzare un'unica 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 tra l'ambiente 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 e i team devono gestire i due ambienti.
Separare le responsabilità tra team diversi richiede di concedere a ciascun team una certa 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 con delega è un modo semplice per delegare le funzioni 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 i 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 Directory del controller di dominio in vari punti:
- Autenticazione iniziale (ottenimento di un ticket che concede un 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 riconferma periodica richiede la comunicazione con un solo controller di dominio, ovvero il 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ò 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 esiste un rapporto di attendibilità diretto 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 tra questi domini esiste solo una relazione di attendibilità indiretta, per un'autenticazione riuscita è necessaria la comunicazione con i controller di dominio di ogni dominio nel percorso di attendibilità.
La localizzazione di utenti e risorse in foreste o domini 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à delle risorse in altri domini.
Tenendo conto del 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 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, i carichi di lavoro di cui esegui il deployment in Google Cloud probabilmente dipendono da altre infrastrutture o applicazioni in esecuzione on-premise, il che rende la connettività ibrida ad alta disponibilità un requisito fondamentale.
Se esegui il deployment di una foresta o di un dominio Active Directory separato in 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à.
Carichi di lavoro 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. È 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 Active Directory on-premise diventa non disponibile, anche tutti i carichi di lavoro di cui è stato eseguito il deployment su Google Cloud e che si basano sull'autenticazione tra domini o tra foreste potrebbero non essere più disponibili.
Se il tuo obiettivo è garantire la continuità aziendale, puoi utilizzare Foreste di Active Directory in ogni ambiente che non sono connesse a uno un'altra. In alternativa, puoi estendere un dominio Active Directory esistente in 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 il seguente albero decisionale per per identificare un'architettura adatta alle foreste e ai domini.
Le sezioni seguenti descrivono ciascun pattern.
Foreste sincronizzate
Nel pattern foreste sincronizzate, esegui il deployment di una foresta Active Directory distinta in Google Cloud. Utilizza questa foresta per gestire le risorse di cui è stato eseguito il deployment su Google Cloud, nonché gli account utente richiesti 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 come Microsoft Identity Manager per sincronizzare gli account utente ambienti cloud-native.
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 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 che un ambiente sia più attendibile dell'altro.
- Prevedi un'interazione minima o nulla tra le piattaforme gestite da Active Directory di risorse on-premise e su Google Cloud.
- Il numero di account utente di cui hai bisogno nel cluster ospitato da Google Cloud L'ambiente di Active Directory è di dimensioni ridotte.
Vantaggi:
- Il pattern delle foreste sincronizzate ti consente di mantenere un'isolamento rigoroso tra i due ambienti Active Directory. Un aggressore che compromettono un ambiente potrebbero avere pochi vantaggi nell’attacco nel secondo ambiente.
- Per utilizzare Active Directory, non è necessario configurare la connettività ibrida tra le reti on-premise e Google Cloud.
- Active Directory ospitato su Google Cloud non è interessato da un interruttore del servizio Active Directory on-premise. Il pattern è ben adatto per casi d'uso di continuità aziendale o altri scenari che richiedono un'alta disponibilità.
- Puoi concedere un elevato livello di autonomia amministrativa ai team che gestire la foresta di Active Directory in hosting 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. Ciò compromette 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 della struttura delle risorse, esegui il deployment di una foresta di Active Directory separata a Google Cloud. che puoi utilizzare per gestire le risorse di cui è stato eseguito il deployment Google Cloud e un insieme minimo di account utente amministrativi richiesta per la gestione della foresta. Instaurando un trust forestale per il una foresta Active Directory on-premise esistente, puoi abilitare foresta esistente per autenticare e accedere alle risorse gestite Foresta di Active Directory ospitata da 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 le tue istanze attive on-premise Ambiente di directory e Active Directory ospitato su Google Cloud dell'ambiente, come misura di difesa in profondità o perché si considera un ambiente più affidabile rispetto all'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 foresta di risorse consente di mantenere un confine di attendibilità tra i due ambienti Active Directory. A seconda di come l'affidabilità è configurata, un aggressore che compromette un ambiente potrebbero avere un accesso minimo o nullo all'altro ambiente.
- Questo pattern è completamente supportato da Microsoft AD gestito.
- Puoi concedere un elevato livello di autonomia amministrativa ai team che gestiscono la foresta Active Directory ospitata in Google Cloud.
Best practice:
- Collega i due forest di Active Directory utilizzando un trust unidirezionale in modo che Active Directory ospitato su Google Cloud attenda il tuo Active Directory esistente, ma non viceversa.
- Utilizza le funzionalità di autenticazione selettiva per limitare le risorse nell'Active Directory in hosting su Google Cloud a cui possono accedere gli utenti di Active Directory on-premise.
- 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 la possibilità di utilizzare il pattern di dominio esteso se si applica una o più delle seguenti condizioni:
- L'utilizzo previsto di Google Cloud rientra in uno dei di deployment ed evitare le dipendenze di runtime dell'ambiente on-premise e di Google Cloud.
- Prevedi che intensa interazione tra Active Directory: risorse gestite on-premise e on in 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 e Google Cloud. In questo modo puoi 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 del firewall che si applicano alla comunicazione tra l'ambiente on-premise e Google Cloud tengano conto di tutti i casi 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 l'uso di controller di dominio di sola lettura per mantenere una copia di sola lettura dei dati del dominio su Google Cloud, ma tieni presente che esiste un compromesso relativamente alla memorizzazione nella cache delle password degli utenti. 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 di memorizzazione nella cache, un RODC compromesso potrebbe rappresentare solo un rischio limitato di Active Directory, ma perderai il vantaggio Google Cloud rimane non interessato da un'interruzione del dominio on-premise controller.
Foresta estesa
Nel pattern della foresta estesa, esegui il deployment di un nuovo dominio Active Directory a Google Cloud, ma integrarlo nella tua 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à implicita 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 la possibilità di utilizzare il pattern foresta estesa se si applica una o più delle seguenti condizioni:
- L'utilizzo previsto di Google Cloud rientra in uno dei pattern di deployment e una dipendenza tra l'ambiente on-premise e Google Cloud è accettabile.
- 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.
- Sono molti gli utenti che hanno bisogno di accedere alle risorse di cui è stato eseguito il deployment a Google Cloud, ad esempio alle applicazioni web che utilizzano IWA per 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.
- 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 gestire il dominio Active Directory ospitato su Google Cloud.
Best practice:
- Utilizza connessioni redundanti Dedicated Interconnect, Partner Interconnect o Cloud VPN per garantire una connettività di rete altamente disponibile 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 della foresta di risorse pattern. 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 della foresta di risorse con pattern del dominio esteso. Se replichi il dominio, i tuoi account utente si trovano in Google Cloud e puoi assicurarti che gli utenti possano autenticarsi nelle risorse ospitate su Google Cloud anche 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 applica una o più delle seguenti condizioni:
- 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 su Google Cloud non sono interessate da un'interruzione del servizio Active Directory on-premise. Il pattern è adatto per i casi d'uso della continuità aziendale o 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.
- Comunicazione tra la tua rete on-premise e Google Cloud la rete è limitata alla replica di Active Directory tra il dominio controller. 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 in 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 le funzionalità di Peering VPC per connettere il VPC al VPC condiviso o al VPC utilizzato dalla risorsa foresta e configurare i firewall per limitare la comunicazione all'autenticazione utente Kerberos e alla creazione di trust della foresta.
- Collega i due forest di Active Directory utilizzando un trust unidirezionale in modo che Active Directory ospitato su Google Cloud attenda la tua forest di Active Directory esistente, ma non viceversa.
- Utilizza l'autenticazione selettiva per limitare le risorse della foresta di risorse a cui gli utenti di altre foreste sono autorizzati ad accedere.
- 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 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 di un ambiente Active Directory ridondante su Google Cloud.
- Consulta le nostre best practice sulla progettazione di VPC.
- Per altre architetture di riferimento, diagrammi e best practice, esplora il Centro architetture cloud.