Questo articolo illustra i requisiti da considerare per il deployment di Active Directory in Google Cloud e ti aiuta a scegliere la giusta architettura.
Federando Active Directory con Cloud Identity o Google Workspace (consulta l'articolo associato), 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 in Google Cloud se prevedi di utilizzare Active Directory per gestire server Windows su Google Cloud o se fai affidamento su protocolli che non sono supportati da Google Cloud.
Prima di eseguire il deployment di Active Directory in Google Cloud, devi decidere quale dominio e architettura di foreste utilizzare e come integrarli con la foresta Active Directory esistente.
Valutazione dei requisiti
Active Directory supporta una vasta gamma di architetture di domini e foreste. In un ambiente ibrido, un'opzione è quella di estendere un singolo dominio Active Directory in più ambienti. In alternativa, puoi usare foreste o domini separati e connetterli tramite trust. L'architettura più adatta dipende dai requisiti.
Per scegliere l'architettura migliore, considera questi fattori:
- Allineamento con zone di sicurezza esistenti
- Interazione tra risorse on-premise e Google Cloud
- Autonomia amministrativa
- Disponibilità
Questi fattori vengono descritti nelle sezioni seguenti.
Allineamento con zone di sicurezza esistenti
Per prima cosa, esamina 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 subnet o VLAN separate. In una rete segmentata in zone di sicurezza, la comunicazione all'interno di una zona di sicurezza non è soggetta a restrizioni o è soggetta solo a criteri di controllo e firewall leggeri. Al contrario, qualsiasi comunicazione tra le zone di sicurezza è soggetta a rigorosi criteri di firewall, controllo o ispezione del traffico.
Le zone di sicurezza hanno un obiettivo che va oltre la semplice limitazione e controllo delle comunicazioni di rete. Tuttavia, le zone di sicurezza devono implementare limiti di attendibilità.
Limiti di trust
Ogni computer in una rete esegue diversi processi. Questi processi possono comunicare tra loro localmente utilizzando la comunicazione tra processi e possono comunicare tra macchine utilizzando protocolli come HTTP. In questa rete di comunicazione, i colleghi non sempre si fidano gli uni degli altri alla stessa misura. Ad esempio, i processi potrebbero considerare attendibili i processi in esecuzione sulla stessa macchina rispetto a quelli in esecuzione su altre macchine. Alcune macchine potrebbero essere considerate più affidabili di altre.
Un confine di attendibilità impone la discriminazione tra le parti di comunicazione, affidando 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. Raramente gli attacchi terminano quando un singolo sistema viene compromesso, che si tratti di un singolo processo o di un'intera macchina. È probabile invece che un utente malintenzionato tenta di estendere l'attacco ad altri sistemi. Poiché i sistemi in un confine di attendibilità non discriminano tra loro, diffondere un attacco all'interno di quel confine di attendibilità è più facile che attaccare i sistemi attraverso un confine di attendibilità.
Una volta che un sistema in un confine di attendibilità è stato compromesso, tutti gli altri sistemi in quel confine di attendibilità devono essere considerati come compromessi. Questa ipotesi può aiutarti a identificare i limiti 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 al target A (ad esempio accesso root o amministratore a una macchina o a un'applicazione). Se possono sfruttare questi privilegi per ottenere lo stesso livello di accesso alla destinazione B, A e B si trovano, per definizione, all'interno dello stesso confine di attendibilità. In caso contrario, un confine di trust si trova tra A e B.
Vincolando la comunicazione di rete, le zone di sicurezza possono aiutare a implementare limiti di attendibilità. Affinché una zona di sicurezza diventi un vero confine di attendibilità, tuttavia, i carichi di lavoro su ogni lato del confine devono distinguere tra le richieste che provengono dalla stessa zona di sicurezza e le richieste che provengono da diverse zone di sicurezza ed esaminare quest'ultima in modo più approfondito.
Modello Zero Trust
Il modello Zero Trust è il modello di networking preferito su Google Cloud.
Dato un singolo sistema compromesso in un confine di attendibilità, puoi presumere che tutti i sistemi in quel confine siano compromessi. Questo presupposto suggerisce che i limiti di fiducia più ridotti sono migliori. Più ristretto è il confine di attendibilità, minore è il numero di sistemi compromessi e più i confini che un utente malintenzionato deve superare affinché un attacco si diffonda.
Il modello Zero Trust porta questa idea alla conclusione logica: ogni macchina nella rete viene considerata come una zona di sicurezza e un confine di attendibilità univoci. Tutte le comunicazioni tra le macchine sono soggette agli stessi controlli e 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 le regole firewall per limitare il traffico, 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 l'autenticazione, l'autorizzazione e il controllo.
Limiti di attendibilità in Active Directory
In un dominio Active Directory, le macchine ritengono che i controller di dominio gestiscano l'autenticazione e l'autorizzazione per loro conto. Una volta che un utente ha dimostrato la propria identità a uno dei controller di dominio, 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 iscrizioni 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. Tuttavia, se una macchina viene compromessa, un utente malintenzionato potrebbe riuscire a rubare le password, gli hash delle password o i token Kerberos di altri utenti del dominio che hanno eseguito l'accesso alla stessa macchina. L'utente malintenzionato può quindi utilizzare queste credenziali per diffondere l'attacco ad altri domini nella foresta.
Dati questi fattori, è meglio supporre che tutte le macchine in una foresta si trovino in un confine di sicurezza di attendibilità.
Rispetto ai confini dei domini, il cui scopo è controllare la replica e concedere autonomia amministrativa a diverse parti dell'organizzazione, i confini delle foreste possono fornire un isolamento più forte. Le foreste possono servare come confine di attendibilità.
Allineamento delle foreste e delle zone di sicurezza di Active Directory
Ssumere che la foresta come confine di attendibilità influenza la progettazione delle zone di sicurezza. Se una foresta si estende attraverso due zone di sicurezza, è più facile per un utente malintenzionato eliminare il confine tra queste zone di sicurezza. Di conseguenza, le due zone di sicurezza diventano di fatto una sola e formano un unico confine di attendibilità.
In un modello Zero Trust, ogni macchina in una rete può essere considerata come 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 in modo da includere tutte le macchine della foresta di Active Directory.
Affinché una zona di sicurezza funga da confine di attendibilità, devi assicurarti che l'intera foresta di 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, 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ù zone di sicurezza esistenti a Google Cloud eseguire il provisioning di un VPC condiviso su Google Cloud e connetterlo alla zona esistente utilizzando Cloud VPN o Interconnect.
Le risorse sottoposte a 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 in Google Cloud.
Come esempio, considera una rete esistente con una DMZ di sviluppoDMZ e 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 di Active Directory.
Introduci nuove zone di sicurezza. L'estensione di una zona di sicurezza potrebbe non essere applicabile, perché non vuoi espanderla ulteriormente o perché i requisiti di sicurezza delle zone di sicurezza esistenti non soddisfano i requisiti dei deployment Google Cloud. Puoi trattare Google Cloud come zone di sicurezza aggiuntive.
Prendiamo, ad esempio, un ambiente on-premise con una DMZ, ma che non fa distinzione 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. Successivamente, esegui il deployment in Google Cloud di altre due foreste Active Directory, una per 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 la tua 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 potrebbe variare da leggera a intensa.
Interazione leggera
Se l'unico scopo di Active Directory su Google Cloud è gestire un parco risorse di server Windows e consentire agli amministratori di accedere a questi server, il livello di interazione tra gli ambienti è minimo:
- Il gruppo 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 affatto con le applicazioni on-premise o potrebbero farlo senza fare affidamento sulle funzionalità di autenticazione di Windows come Kerberos e NTLM.
In uno scenario di lieve entità, valuta la possibilità di integrare i tuoi ambienti on-premise e Google Cloud in uno dei seguenti due modi:
Due foreste di Active Directory separate: puoi isolare i due ambienti utilizzando due foreste di Active Directory separate che non condividono una relazione di attendibilità. Per consentire agli amministratori di eseguire l'autenticazione, devi mantenere un insieme separato di account utente per loro nella foresta di Google Cloud.
Mantenere un insieme duplicato di account utente aumenta lo sforzo amministrativo e introduce il rischio di dimenticarsi di disattivare gli account quando i dipendenti lasciano l'azienda. Un approccio migliore è eseguire il provisioning automatico di questi account.
Se il provisioning degli account utente della tua Active Directory on-premise viene eseguito da un sistema HRIS (Human Resources Information System), 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 trust tra foreste: utilizzando due foreste di Active Directory e connettendole con un trust tra foreste, puoi evitare di mantenere 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 confine di attendibilità tra l'ambiente on-premise e l'ambiente Google Cloud.
Interazione moderata
Il tuo caso d'uso potrebbe essere più complesso. Ad esempio:
- Gli amministratori che accedono ai server Windows distribuiti in Google Cloud potrebbero dover accedere a condivisioni file ospitate on-premise.
- Le applicazioni possono utilizzare Kerberos o NTLM per eseguire l'autenticazione e comunicare tra i confini dell'ambiente.
- Potresti voler consentire ai dipendenti di utilizzare l'autenticazione integrata di Windows (IWA) per eseguire l'autenticazione nelle applicazioni web di cui è stato eseguito il deployment in Google Cloud.
In uno scenario moderato, l'utilizzo di due foreste di Active Directory separate potrebbe essere troppo limitato: non puoi utilizzare Kerberos per l'autenticazione nelle due foreste e utilizzare l'autenticazione passthrough di Hadoop richiede di mantenere sincronizzati gli account utente e le password.
In questo caso, consigliamo di utilizzare due foreste di Active Directory con un trust tra foreste.
Interazione intensiva
Determinati carichi di lavoro, inclusi i deployment dell'infrastruttura desktop virtuale (VDI), potrebbero richiedere un'interazione intensiva tra risorse on-premise e risorse di cui è stato eseguito il deployment su Google Cloud. Quando le risorse nei vari ambienti sono strettamente accoppiate, cercare di 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 una singola foresta Active Directory e di condividerla tra ambienti.
Autonomia amministrativa
Il terzo fattore da considerare quando estendi la tua Active Directory a Google Cloud è l'autonomia amministrativa.
Se prevedi di distribuire carichi di lavoro tra on-premise e Google Cloud, i carichi di lavoro che eseguirai su Google Cloud potrebbero essere molto diversi rispetto a quelli gestiti on-premise. Potresti anche decidere che team diversi debbano gestire i due ambienti.
Separare le responsabilità tra i diversi team richiede di concedere a ciascun team un'autonomia amministrativa. In Active Directory, puoi concedere ai team l'autorità per gestire le risorse utilizzando l'amministrazione delegata o domini separati.
L'amministrazione delegata è un modo semplice per delegare i compiti amministrativi 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 carico di lavoro amministrativo necessario per il coordinamento tra i team. In tal caso, consigliamo di utilizzare domini separati.
Disponibilità
L'ultimo fattore da considerare quando estendi la tua Active Directory a Google Cloud è la disponibilità. Per ogni dominio in una foresta di Active Directory, il controller di dominio funge da provider di identità per gli utenti di quel dominio.
Quando utilizza Kerberos per l'autenticazione, un utente deve interagire con un controller di dominio Active Directory in diversi punti:
- Autenticazione iniziale (ottenimento di un ticket per la concessione di licenze).
- Riautenticazione periodica (aggiornamento di un ticket per la concessione di un ticket).
- Autenticazione con una risorsa (ottenimento di un ticket di servizio).
L'esecuzione dell'autenticazione iniziale e della riautenticazione periodica richiede la comunicazione solo con un singolo controller di dominio, ovvero un controller di dominio del dominio di cui l'utente è membro.
Durante 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 il processo di autenticazione.
- Se la risorsa si trova in un dominio diverso, ma esiste una relazione di attendibilità diretta con il dominio dell'utente, quest'ultimo 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, un'autenticazione riuscita richiede la comunicazione con i controller di dominio di ogni dominio nel percorso di attendibilità.
La localizzazione di utenti e risorse in diversi domini o foreste di Active Directory può limitare la disponibilità complessiva. Poiché l'autenticazione richiede l'interazione con più domini, l'interruzione di un dominio può influire sulla disponibilità delle risorse in altri domini.
Considerando il potenziale impatto della topologia di Active Directory sulla disponibilità, ti consigliamo di allineare la tua topologia di Active Directory alla tua strategia ibrida.
Carichi di lavoro distribuiti
Per sfruttare le funzionalità esclusive di ogni ambiente di computing, puoi utilizzare un approccio ibrido per 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 in Google Cloud dipendono da altre infrastrutture o applicazioni in esecuzione on-premise, il che rende la connettività ibrida ad alta disponibilità un requisito critico.
Se esegui il deployment in Google Cloud di una foresta o di un dominio Active Directory distinti e utilizzi un trust per connetterlo all'Active Directory on-premise, aggiungi un'altra dipendenza tra Google Cloud e l'ambiente on-premise. Questa dipendenza ha un impatto minimo sulla disponibilità.
Carichi di lavoro ridondanti
Se utilizzi Google Cloud per garantire la continuità aziendale, i tuoi carichi di lavoro su Google Cloud eseguono il mirroring di alcuni 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 considerare ogni dipendenza tra questi ambienti.
Se esegui il deployment in Google Cloud di una foresta o di un dominio Active Directory distinti e utilizzi un trust per connetterlo alla tua Active Directory on-premise, potresti creare una dipendenza che comprometta lo scopo della configurazione. Se l'Active Directory on-premise non è più disponibile, anche tutti i carichi di lavoro di cui è stato eseguito il deployment in Google Cloud che si basano sull'autenticazione interdominio o tra foreste potrebbero non essere più disponibili.
Se il tuo obiettivo è garantire la continuità aziendale, puoi utilizzare foreste di Active Directory separate in ogni ambiente che non sono connesse tra loro. Oppure puoi estendere un dominio Active Directory esistente a Google Cloud. Eseguendo il deployment di controller di dominio aggiuntivi in Google Cloud e replicando i contenuti delle directory tra gli ambienti, ti assicuri che gli ambienti funzionino in modo isolato.
Pattern di integrazione
Dopo aver valutato i requisiti, utilizza il seguente albero decisionale per identificare una foresta e un'architettura di dominio adatte.
Le sezioni seguenti descrivono ogni pattern.
Foreste sincronizzate
Nel pattern foreste sincronizzate, esegui il deployment di una foresta di Active Directory separata in Google Cloud. Puoi utilizzare questa foresta per gestire le risorse di cui è stato eseguito il deployment su Google Cloud e gli account utente necessari per gestirle.
Anziché creare un trust tra la nuova foresta e una foresta on-premise esistente, puoi sincronizzare gli account. Se utilizzi un HRIS come sistema principale per gestire gli account utente, puoi configurarlo in modo da eseguire 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.
Valuta l'utilizzo del pattern di foreste sincronizzate se si applica uno o più dei seguenti scenari:
- L'uso previsto di Google Cloud rientra in 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 da Google Cloud, come misura di difesa in profondità o perché consideri attendibile un ambiente più dell'altro.
- Prevedi un'interazione leggera 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 su Google Cloud è ridotto.
Vantaggi:
- Il pattern di foreste sincronizzate consente di mantenere un forte isolamento tra i due ambienti Active Directory. Un utente malintenzionato che comprometta un ambiente potrebbe ottenere pochi vantaggi nell'attaccare il secondo ambiente.
- Per utilizzare Active Directory, non è necessario configurare la connettività ibrida tra le reti on-premise e Google Cloud.
- La Active Directory ospitata da Google Cloud non è interessata dall'interruzione della tua Active Directory on-premise. Il pattern è adatto a casi d'uso di continuità aziendale o ad altri scenari che richiedono un'alta disponibilità.
- Puoi concedere un livello elevato di autonomia amministrativa ai team che gestiscono la foresta di 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. Ciò compromette l'isolamento tra gli ambienti.
- Non utilizzare l'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 di Active Directory separata in Google Cloud. Puoi utilizzare 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 la gestione della foresta. Stabilisce un trust nella foresta di Active Directory on-premise esistente per consentire agli utenti della foresta esistente di eseguire l'autenticazione e accedere alle risorse gestite dalla foresta Active Directory ospitata da Google Cloud.
Se necessario, puoi trasformare questo pattern in una topologia hub/spoke con la foresta Active Directory esistente al centro, connessa a molte foreste di risorse.
Prova a utilizzare il pattern con foresta di risorse se si applica una o più delle seguenti condizioni:
- L'uso previsto di Google Cloud rientra in uno dei pattern di deployment distribuiti ed è accettabile una dipendenza 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 da Google Cloud, come misura di difesa in profondità o perché consideri un ambiente più affidabile dell'altro.
- Prevedi un livello moderato di interazione tra le risorse gestite da Active Directory on-premise e su Google Cloud.
- Un numero elevato di utenti deve accedere alle risorse di cui è stato eseguito il deployment su Google Cloud, ad esempio alle applicazioni web che utilizzano IWA per l'autenticazione.
Vantaggi:
- Il pattern con foresta di risorse consente di mantenere un confine di attendibilità tra i due ambienti Active Directory. A seconda della configurazione della relazione di fiducia, un utente malintenzionato che compromette un ambiente potrebbe avere un accesso minimo o nullo all'altro.
- Questo pattern è completamente supportato da Managed Microsoft AD.
- Puoi concedere un livello elevato di autonomia amministrativa ai team che gestiscono la foresta di Active Directory ospitata da Google Cloud.
Best practice:
- Connetti le due foreste di Active Directory utilizzando un trust unidirezionale in modo che Active Directory ospitata da Google Cloud consideri attendibile l'Active Directory esistente, ma non viceversa.
- Utilizza l'autenticazione selettiva per limitare le risorse in Active Directory ospitate da Google Cloud a cui sono autorizzati ad accedere gli utenti dell'Active Directory on-premise.
- Utilizza connessioni ridondanti di Dedicated Interconnect, Partner Interconnect o Cloud VPN per garantire una connettività di rete ad alta disponibilità tra la tua rete on-premise e Google Cloud.
Dominio esteso
Nel pattern esteso, estendi uno o più domini Active Directory esistenti a Google Cloud. Per ciascun dominio esegui il deployment di uno o più controller di dominio su Google Cloud, il che fa sì che tutti i dati del dominio e il catalogo globale vengano replicati e resi disponibili su Google Cloud. Utilizzando siti Active Directory distinti per le subnet on-premise e Google Cloud, ti assicuri che i client comunichino con i controller di dominio più vicini.
Prendi in considerazione l'utilizzo del pattern di dominio esteso se si applica una o più delle seguenti condizioni:
- L'uso previsto di Google Cloud si adatta a uno dei pattern di deployment ridondanti e vuoi evitare dipendenze di runtime tra il tuo ambiente on-premise e Google Cloud.
- Prevedi un'interazione pesante tra Active Directory, le risorse gestite on-premise e su Google Cloud.
- Vuoi velocizzare l'autenticazione per le applicazioni che si basano su LDAP per l'autenticazione.
Vantaggi:
- La Active Directory ospitata da Google Cloud non è interessata dall'interruzione della tua Active Directory on-premise. Il pattern è adatto a casi d'uso di continuità aziendale o ad altri scenari che richiedono un'alta disponibilità.
- Puoi limitare la comunicazione tra la tua rete on-premise e Google Cloud. Ciò può potenzialmente risparmiare larghezza di banda e migliorare la latenza.
- Tutti i contenuti del catalogo globale vengono replicati in Active Directory e sono accessibili in modo efficiente dalle risorse ospitate da Google Cloud.
Best practice:
- Se replichi tutti i domini, le comunicazioni tra la tua rete on-premise e la rete Google Cloud sono limitate alla replica di Active Directory tra i controller di dominio. Se replichi solo un sottoinsieme dei domini della tua foresta, i server uniti a un 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 siti avviene solo a intervalli determinati, quindi gli aggiornamenti eseguiti su un controller di dominio on-premise vengono visualizzati in Google Cloud solo dopo un ritardo (e viceversa).
- Prendi in considerazione l'utilizzo di 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 utente. Se consenti ai RODC di memorizzare le password e precompilare la cache delle password, le risorse di cui è stato eseguito il deployment in Google Cloud potrebbero non essere interessate da un'interruzione dei controller di dominio on-premise. Tuttavia, i vantaggi in termini di sicurezza derivanti dall'uso di un RODC rispetto a un normale controller di dominio sono limitati. Se disabiliti la memorizzazione nella cache delle password, un RODC compromesso potrebbe rappresentare solo un rischio limitato per il resto della tua Active Directory, ma perderai il vantaggio di Google Cloud che non è interessato da un'interruzione dei controller di dominio on-premise.
Foresta estesa
Nel pattern esteso della foresta, esegui il deployment di un nuovo dominio Active Directory su Google Cloud, ma lo integri nella tua foresta esistente. Puoi utilizzare 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 amministrativi per la gestione del dominio.
Estendendo le relazioni di attendibilità implicite ad altri domini della foresta, consenti agli utenti esistenti di altri domini di eseguire l'autenticazione e di accedere alle risorse gestite dal dominio Active Directory ospitato da Google Cloud.
Prendi in considerazione l'utilizzo del pattern a foresta estesa se si applica uno o più dei seguenti elementi:
- L'uso previsto di Google Cloud si adatta a uno dei pattern di deployment distribuiti e una dipendenza tra il tuo ambiente on-premise e Google Cloud è accettabile.
- Le risorse di cui prevedi di eseguire il deployment in Google Cloud richiedono una configurazione o una struttura di dominio diversa da quella fornita dai domini esistenti oppure vuoi concedere un alto livello di autonomia amministrativa ai team che amministrano il dominio ospitato su Google Cloud.
- Prevedi un'interazione da moderata a intensa tra le risorse gestite da Active Directory on-premise e su Google Cloud.
- Ci sono molti utenti che devono accedere alle risorse di cui è stato eseguito il deployment in Google Cloud, ad esempio nelle applicazioni web che utilizzano IWA per l'autenticazione.
Vantaggi:
- Tutti i contenuti del catalogo globale verranno replicati in Active Directory e potrai accedervi in modo efficiente dalle risorse ospitate da Google Cloud.
- Il traffico di replica tra la rete on-premise e Google Cloud è limitato alla replica del catalogo globale. Ciò potrebbe contribuire a limitare il consumo complessivo della larghezza di banda.
- Puoi concedere un livello elevato di autonomia amministrativa ai team che gestiscono il dominio Active Directory ospitato su Google Cloud.
Best practice:
- 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.
Foresta di risorse con dominio esteso
Il pattern foresta di risorse con dominio esteso è un'estensione del pattern della foresta di risorse. Il pattern con foresta di risorse consente di mantenere un confine di attendibilità tra gli ambienti e fornire autonomia amministrativa. Un limite della foresta di risorse è che la sua disponibilità complessiva dipende dalla disponibilità di controller di dominio on-premise e dalla connettività di rete affidabile al tuo data center on-premise.
Puoi superare queste limitazioni combinando il pattern della 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 eseguire l'autenticazione nelle risorse ospitate da Google Cloud anche quando i controller di dominio on-premise non sono disponibili o la connettività di rete viene persa.
Prova a utilizzare la foresta di risorse con pattern di dominio esteso se si applica uno o più dei seguenti casi:
- Vuoi mantenere un confine di attendibilità 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 della connettività di rete all'ambiente on-premise influisca sui carichi di lavoro ospitati su Google Cloud.
- Prevedi un'interazione moderata tra le risorse gestite da Active Directory, on-premise e su Google Cloud.
- Ci sono molti utenti di un singolo dominio Active Directory che devono accedere alle risorse distribuite su Google Cloud, ad esempio alle applicazioni web che utilizzano IWA per l'autenticazione.
Vantaggi:
- Le risorse ospitate da Google Cloud non sono interessate da un'interruzione della tua Active Directory on-premise. Il pattern è adatto per casi d'uso di continuità aziendale o altri scenari che richiedono un'alta disponibilità.
- Il pattern consente di mantenere un confine di attendibilità tra le due foreste di Active Directory. A seconda di come è configurata la relazione di fiducia, un utente 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 controller di dominio. Puoi implementare regole firewall per non consentire tutte le altre comunicazioni, rafforzando l'isolamento tra gli ambienti
- Puoi concedere un livello elevato di autonomia amministrativa ai team che gestiscono la foresta di Active Directory ospitata da Google Cloud.
- Puoi utilizzare Microsoft AD gestito per la foresta di risorse.
Best practice:
- Esegui il deployment dei controller di dominio per il dominio esteso in un progetto Google Cloud separato e in un VPC in modo da separare questi componenti dai componenti della foresta di risorse.
- Utilizza il peering VPC per connettere il VPC al VPC condiviso o al VPC condiviso utilizzato dalla foresta di risorse e configura i firewall per limitare la comunicazione all'autenticazione utente Kerberos e alla creazione di attendibilità nella foresta.
- Connetti le due foreste Active Directory utilizzando un trust unidirezionale in modo che Active Directory ospitata da Google Cloud consideri attendibile la foresta Active Directory esistente, ma non viceversa.
- Utilizza l'autenticazione selettiva per limitare le risorse nella foresta a cui possono accedere gli utenti di altre foreste.
- Tieni presente che la replica tra siti avviene solo a determinati intervalli, quindi gli aggiornamenti eseguiti su un controller di dominio on-premise vengono visualizzati in Google Cloud solo dopo un ritardo (e viceversa).
- Prendi in considerazione l'utilizzo di RODC per il dominio esteso, ma assicurati di consentire la memorizzazione delle password nella cache per preservare i vantaggi della disponibilità rispetto al pattern di foreste di risorse.
Passaggi successivi
- Scopri di più su Microsoft AD gestito.
- 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 in Google Cloud.
- Consulta le nostre best practice per la progettazione di VPC.
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Dai un'occhiata al nostro Cloud Architecture Center.