Questo documento illustra i requisiti da considerare quando esegui il deployment di Active Directory in Google Cloud e ti aiuta a scegliere l'architettura giusta.
Se esegui la federazione di Active Directory con Cloud Identity o Google Workspace (consulta Modelli per l'autenticazione degli utenti della forza lavoro in un ambiente ibrido), puoi consentire agli utenti dei tuoi domini Active Directory esistenti di autenticarsi e accedere alle risorse su Google Cloud. Puoi anche eseguire il deployment di Active Directory su Google Cloud se prevedi di utilizzare Active Directory per gestire i server Windows su Google Cloud o se utilizzi protocolli che non sono supportati da Google Cloud.
Prima di eseguire il deployment di Active Directory in Google Cloud, devi prima decidere quale architettura di dominio e foresta utilizzare e come eseguire l'integrazione con la foresta Active Directory esistente.
Valutazione dei requisiti
Active Directory supporta una serie di architetture di domini e foreste. In un ambiente ibrido, un'opzione è estendere un singolo dominio Active Directory su più ambienti. In alternativa, puoi utilizzare foreste o domini distinti e collegarli tramite i trust. L'architettura migliore dipende dai tuoi requisiti.
Per scegliere l'architettura migliore, prendi in considerazione 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 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 criteri rigorosi di firewall, controllo o ispezione del traffico.
Lo scopo delle zone di sicurezza è più ampio del semplice controllo e limitazione delle comunicazioni di rete. Le zone di sicurezza devono implementare confini di attendibilità.
Limiti di trust
Ogni macchina di una rete esegue diversi processi. Questi processi potrebbero comunicare tra loro localmente utilizzando la comunicazione tra processi e comunicare tra macchine utilizzando protocolli come HTTP. In questo web di comunicazione, i peer non si fidano sempre l'uno dell'altro nella stessa misura. Ad esempio, i processi potrebbero considerare attendibili quelli in esecuzione sulla stessa macchina più di quelli in esecuzione su altre macchine. Inoltre, alcune macchine potrebbero essere considerate più attendibili di altre.
Un confine di attendibilità impone di distinguere tra le parti comunicanti, dando più attendibilità a un insieme di parti comunicanti rispetto a un altro.
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 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 malintenzionato abbia ottenuto il livello di accesso più elevato al target A (ad esempio, accesso amministrativo o root a una macchina o un'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, tra A e B esiste un confine di attendibilità.
Limitando la comunicazione di rete, le zone di sicurezza possono contribuire a implementare i confini 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 rete preferito su Google Cloud.
Se un singolo sistema è compromesso in un confine di attendibilità, puoi presumere che tutti i sistemi all'interno di questo confine siano compromessi. Questa ipotesi 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 conclusione logica: ogni macchina della rete viene trattata come una zona di sicurezza e un confine di attendibilità unici. Tutte le comunicazioni tra le macchine sono soggette 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.
Confini 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 sua identità a uno dei controller di dominio, può accedere per impostazione predefinita a tutte le 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. Tuttavia, una volta compromessa una macchina, un malintenzionato potrebbe essere in grado di rubare password, hash delle password o token Kerberos di altri utenti del dominio che hanno eseguito l'accesso alla stessa macchina. L'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
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, le due zone di sicurezza diventano un'unica zona 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 mina questo concetto e amplia il confine di sicurezza effettivo per includere tutte le macchine della foresta 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 su Google Cloud che richiede Active Directory, devi scegliere tra due opzioni per allineare il deployment alle tue zone di sicurezza esistenti:
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.
Le risorse di cui è stato eseguito il deployment on-premise e su Google Cloud che condividono una zona comune possono anche condividere una foresta Active Directory comune, quindi non è necessario eseguire il deployment di una foresta separata su 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, tutti i deployment su Google Cloud fanno parte anche di una di queste due zone di sicurezza e possono utilizzare le stesse foreste Active 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 trattare Google Cloud come zone di sicurezza aggiuntive.
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 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 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 con la luce
Se l'unico scopo dell'utilizzo di Active Directory su Google Cloud è gestire un parco di server Windows e consentire agli amministratori di accedere a questi server, il livello di interazione tra gli ambienti è ridotto:
- 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 autenticarsi, gestisci un insieme distinto di account utente per loro nella foresta Google Cloud.
La gestione di un insieme duplicato di account utente aumenta l'impegno amministrativo e introduce il rischio di dimenticare di disattivare gli account quando i dipendenti lasciano l'azienda. Un approccio migliore è 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 Active Directory con attendibilità tra foreste: utilizzando due foreste Active Directory e collegandole con una relazione di attendibilità tra foreste, puoi evitare di dover gestire 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 che accedono ai server Windows di cui è stato eseguito il deployment su Google Cloud potrebbero 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 distinte potrebbe essere troppo limitante: non puoi utilizzare Kerberos per l'autenticazione tra le due foreste e l'utilizzo dell'autenticazione passthrough NTLM richiede di mantenere sincronizzati gli account utente e le password.
In questo caso, ti consigliamo di utilizzare due foreste Active Directory con un'incredulità 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 messe in produzione su 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, 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 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 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à per gestire le risorse utilizzando l'amministrazione delegata o 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 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 amministrativo del coordinamento tra i team. In questo caso, ti consigliamo di utilizzare domini separati.
Disponibilità
L'ultimo fattore da considerare quando estendi Active Directory a Google Cloud è la disponibilità. Per ogni dominio in una foresta Active Directory, il controller di dominio funge da provider di identità per gli utenti di quel dominio.
Quando si utilizza Kerberos per l'autenticazione, un utente deve interagire con un domain controller Active Directory in vari punti:
- Autenticazione iniziale (ottenimento di un ticket 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, l'utente può utilizzare lo stesso controller di dominio (o un altro controller di dominio dello stesso dominio) per completare la procedura 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 le funzionalità uniche di ciascun ambiente di calcolo, potresti utilizzare un approccio ibrido per 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. Devi quindi esaminare ogni dipendenza tra questi ambienti.
Se esegui il deployment di un forest o di un dominio Active Directory separato su Google Cloud e utilizzi un trust per connetterlo ad Active Directory on-premise, potresti creare una dipendenza che mina 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 Active Directory separate in ogni ambiente che non sono collegate tra loro. In alternativa, puoi estendere un dominio Active Directory esistente a Google Cloud. Se esegui il deployment di altri controller di dominio in Google Cloud e replichi i contenuti della directory tra gli ambienti, assicuri che gli ambienti funzionino in isolamento.
Pattern di integrazione
Dopo aver valutato i requisiti, utilizza la seguente struttura decisionale per aiutarti a identificare un'architettura di foreste e domini adatta.
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 messe in produzione 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 sistema HR come sistema principale per gestire gli account utente, puoi configurarlo in modo da eseguire il provisioning degli account utente nel forest di Active Directory ospitato in 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 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.
- 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.
- 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 gestiscono la foresta Active Directory ospitata in 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, l'isolamento tra gli ambienti viene meno.
- 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 far evolvere questo modello in una topologia hub and spoke con la foresta Active Directory esistente al centro, collegata a molte foreste di risorse.
Valuta la possibilità di utilizzare il pattern foresta di risorse se si applica una o più delle seguenti condizioni:
- L'utilizzo previsto di Google Cloud rientra in uno dei pattern di deployment distribuiti 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 foresta di risorse ti consente di mantenere un confine di attendibilità tra i due ambienti Active Directory. A seconda di come è configurata la relazione di attendibilità, un malintenzionato che compromette un ambiente potrebbe ottenere un accesso ridotto 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 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 dominio esteso, estendi uno o più dei tuoi domini Active Directory esistenti a Google Cloud. Per ogni dominio, esegui il deployment di uno o più controller di dominio su Google Cloud, in modo che tutti i dati del dominio, nonché il catalogo globale, vengano replicati e resi disponibili su 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 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:
- 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 alta disponibilità.
- Puoi limitare la comunicazione tra la tua rete on-premise e Google Cloud. In questo modo puoi potenzialmente risparmiare larghezza di banda e migliorare la latenza.
- Tutti i contenuti del catalogo globale vengono replicati in Active Directory e possono essere accessibili in modo efficiente dalle risorse ospitate su Google Cloud.
Best practice:
- Se replichi tutti i domini, la comunicazione tra la rete on-premise e la rete Google Cloud è limitata alla replica di Active Directory tra i controller di dominio. Se replichi solo un sottoinsieme dei domini della 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'infrastruttura 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 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 controller RODC di memorizzare nella cache le password e precompilare la cache delle password, le risorse di cui è stato eseguito il deployment su Google Cloud possono rimanere invariate in caso di interruzione del servizio 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à 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 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 Active Directory e sarà possibile accedervi in modo efficiente dalle risorse ospitate su Google Cloud.
- Il traffico di replica tra la rete on-premise e Google Cloud è limitato alla replica del catalogo globale. In questo modo potresti limitare il consumo complessivo di larghezza di banda.
- Puoi concedere un elevato livello di autonomia amministrativa ai team che gestiscono il dominio Active Directory ospitato in 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 del pattern foresta di risorse. Il pattern foresta di risorse ti consente di mantenere un confine di attendibilità tra gli ambienti e di fornire autonomia amministrativa. Una limitazione della foresta di risorse è che la sua disponibilità complessiva dipende dalla disponibilità dei controller di dominio on-premise e dalla connettività di rete affidabile al data center on-premise.
Puoi superare queste limitazioni combinando il pattern foresta di risorse con il pattern di 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 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 con il tuo ambiente on-premise influisca sui tuoi carichi di lavoro ospitati su Google Cloud.
- Prevedi un'interazione moderata tra le risorse gestite da Active Directory on-premise e su Google Cloud.
- Hai molti utenti di un singolo dominio Active Directory che devono accedere alle risorse di cui è stato eseguito il deployment su Google Cloud, ad esempio alle applicazioni web che utilizzano 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.
- La comunicazione tra la rete on-premise e la rete Google Cloud è limitata alla replica di Active Directory tra i controller di dominio. Puoi implementare regole firewall per non consentire tutte le altre comunicazioni, rafforzando l'isolamento tra gli ambienti
- Puoi concedere un elevato livello di autonomia amministrativa ai team che gestiscono la foresta Active Directory ospitata 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 progetto Google Cloud e in un VPC separati per separare questi componenti dai componenti della foresta di risorse.
- Utilizza peering VPC per connettere il VPC a 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 del 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.
- 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 ridondante su Google Cloud.
- Consulta le nostre best practice per la progettazione di VPC.
- Per altre architetture di riferimento, diagrammi e best practice, visita il Cloud Architecture Center.