Modelli per l'utilizzo di Active Directory in un ambiente ibrido

Last reviewed 2024-06-26 UTC

Questo documento illustra i requisiti da considerare quando esegui il deployment di Active Directory in Azure e ti aiuta a scegliere l'architettura corretta. Google Cloud

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 in Google Cloud se prevedi di utilizzare Active Directory per gestire i server Windows su Google Cloud o se utilizzi protocolli che sono non supportati da Google Cloud.

Prima di eseguire il deployment di Active Directory in Google Cloud, devi prima decidere quale architettura di dominio e foresta utilizzare e come 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 separati 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, nonché esaminare più da vicino quest'ultime.

Modello Zero Trust

Il modello Zero Trust è il modello di rete preferito su Google Cloud.

Se un singolo sistema è compromesso in un confine di attendibilità, puoi presumere che tutti i sistemi all'interno di quel 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 in Google Cloud che richiede Active Directory, devi scegliere tra due opzioni per allineare il deployment alle tue zone di sicurezza esistenti:

  • Espandi 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 Google Cloud 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 aGoogle Cloud, tutti i deployment suGoogle Cloudfanno anche parte di una di queste due zone di sicurezza e possono utilizzare le stesse foreste Active Directory. Google Cloud

    Estensione di una zona di sicurezza a Google Cloud

  • 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 Google Cloud. Puoi trattarle 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 condivise e considerarle nuove zone di sicurezza. Poi, implementa altri due forest di Active Directory in 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.

    Separazione dei carichi di lavoro su Google Cloud mediante la creazione di due VPC condivisi come nuove zone di sicurezza.

Interazione tra risorse on-premise e Google Cloud

Il secondo fattore da considerare quando estendi Active Directory aGoogle 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 è 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 su funzionalità di autenticazione di Windows come Kerberos e NTLM.

In uno scenario semplice, ti consigliamo di integrare gli ambienti on-premise eGoogle 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 forestaGoogle 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 l'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 potrebberebbero 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 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, consigliamo di utilizzare due foreste Active Directory con un'incredulità tra foreste.

Interazione intensa

Alcuni workload, inclusi i deployment dell'infrastruttura desktop virtuale (VDI), potrebbero richiedere un'interazione intensa tra le risorse on-premise e le risorse implementate su Google Cloud. Quando le risorse tra gli ambienti sono strettamente correlate, provare a mantenere un confine basato sull'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 aGoogle Cloud è l'autonomia amministrativa.

Se prevedi di distribuire i carichi di lavoro tra on-premise e Google Cloud, i carichi di lavoro su cui eseguirai l' 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 aGoogle 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 Google Cloud probabilmente dependono su 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 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 una foresta o di un dominio Active Directory separato in Google Cloud e utilizzi un trust per collegarlo ad Active Directory on-premise, potresti creare una dipendenza che mina lo scopo della configurazione. Se Active Directory on-premise diventa non disponibile, tutti i carichi di lavoro di cui è stato eseguito il deployment suGoogle Cloud e che si basano sull'autenticazione tra domini o tra foreste potrebbero diventare non 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 aGoogle Cloud. Se esegui il deployment di altri controller di dominio inGoogle 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.

Albero decisionale per aiutarti a scegliere un'architettura di foresta e dominio

Le sezioni seguenti descrivono ciascun pattern.

Foreste sincronizzate

Nel pattern delle 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 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 Active Directory ospitato da Google Cloud. In alternativa, puoi utilizzare strumenti come Microsoft Identity Manager per sincronizzare gli account utente tra gli ambienti.

Deployment di una foresta Active Directory separata in Google Cloud

Valuta la possibilità di utilizzare il pattern Foreste sincronizzate se si applica uno o più dei seguenti casi:

  • L'utilizzo previsto di Google Cloud è conforme 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 da Google Cloud, come misura di difesa in profondità o perché ritieni che un ambiente sia più attendibile dell'altro.
  • Non prevedi interazioni o interazioni minime tra le risorse on-premise e su Google Cloudgestite da Active Directory.
  • Il numero di account utente necessari nell'ambiente Active Directory ospitato da Google Cloudè ridotto.

Vantaggi:

  • Il pattern delle foreste sincronizzate ti consente di mantenere un'isolamento rigoroso tra i due ambienti Active Directory. Un utente malintenzionato che compromette un ambiente potrebbe trarre scarso vantaggio dall'attacco del secondo ambiente.
  • Per utilizzare Active Directory, non è necessario configurare la connettività ibrida tra le reti on-premise e Google Cloud .
  • L'Active Directory ospitato in Google Cloudnon è interessato da un'interruzione 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 Google Cloud. Utilizza questa foresta per gestire le risorse di cui è stato eseguito il deployment inGoogle Cloud , nonché un insieme minimo di account utente amministrativo necessari per la gestione della foresta. Stabilendo un trust di foresta con la foresta Active Directory on-premise esistente, consenti agli utenti della foresta esistente di autenticarsi e accedere alle risorse gestite dalla foresta Active Directory ospitata daGoogle Cloud.

Se necessario, puoi far evolvere questo pattern in una topologia hub and spoke con la foresta Active Directory esistente al centro, collegata a molte foreste di risorse.

Un'attendibilità foresta alla tua foresta Active Directory on-premise, che consente agli utenti della foresta esistente di autenticarsi e accedere alle risorse gestite dalla foresta Active Directory ospitata daGoogle Cloud

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 si adatta a uno dei pattern di implementazione distribuita, 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 da 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 Google Cloud, ad esempio alle applicazioni web che utilizzano le IWA per l'autenticazione.

Vantaggi:

  • Il pattern foresta di risorse 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 le due foreste di Active Directory utilizzando una relazione di attendibilità unidirezionale in modo che Active Directory ospitato da Google Cloudabbia attendibilità per il tuo Active Directory esistente, ma non viceversa.
  • Utilizza l'autenticazione selettiva per limitare le risorse in Active Directory ospitato in 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 ad alta disponibilità tra la tua rete on-premise e Google Cloud.

Dominio esteso

Nel pattern dominio esteso, espandi 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 suGoogle Cloud. Se utilizzi siti Active Directory distinti per le tue sottoreti on-premise e Google Cloud , ti assicuri che i client comunichino con i domain controller più vicini.

Estendere uno o più domini Active Directory esistenti a Google Cloud

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 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 una forte interazione tra le risorse gestite da Active Directory on-premise e suGoogle Cloud.
  • Vuoi velocizzare l'autenticazione per le applicazioni che si basano su LDAP per l'autenticazione.

Vantaggi:

  • L'Active Directory ospitato in Google Cloudnon è interessato da un'interruzione 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 aggiunti al dominio in esecuzione suGoogle Cloud potrebberebbero comunque comunicare con i controller di dominio dei domini non replicati. Assicurati che le regole del firewall che si applicano alla comunicazione tra le risorse on-premise e quelle cloud prendano in considerazione tutti i casi pertinenti. Google Cloud
  • Tieni presente che la replica tra siti avviene solo a determinati intervalli, pertanto gli aggiornamenti eseguiti su un'istanza di domain controller on-premise vengono applicati aGoogle 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 di precompilare la cache delle password, le risorse di cui è stato eseguito il deployment su Google Cloud possono rimanere inalterate da un'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 diGoogle Cloud rimanere invariato in caso di interruzione dei controller di dominio on-premise.

Foresta estesa

Nel modello di 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 gestire il dominio.

Estendendo le relazioni di attendibilità implicite ad altri domini della foresta, consente agli utenti esistenti di altri domini di autenticarsi e accedere alle risorse gestite dal dominio Active Directory ospitato in Google Cloud.

Esegui il deployment di un nuovo dominio Active Directory su Google Cloud, ma integrandolo nella foresta esistente

Valuta la possibilità di utilizzare il pattern foresta estesa se si applica una o più delle seguenti condizioni:

  • L'utilizzo previsto di Google Cloud è conforme a uno degli schemi 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 da 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 Google Cloud, ad esempio alle applicazioni web che utilizzano le IWA per l'autenticazione.

Vantaggi:

  • Tutti i contenuti del catalogo globale verranno replicati in Active Directory e sarà possibile accedervi in modo efficiente dalle risorse ospitate su Google Cloud.
  • Il traffico di replica tra la rete on-premise eGoogle 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 Dedicated Interconnect, Partner Interconnect o Cloud VPN ridondanti 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 Cloudanche quando i controller di dominio on-premise non sono disponibili o la connettività di rete viene persa. Google Cloud

Combinazione della foresta di risorse e dei pattern di dominio esteso

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 carichi di lavoro ospitati suGoogle Cloud.
  • Prevedi un'interazione moderata tra le risorse on-premise e su Google Cloudgestite da Active Directory.
  • Hai molti utenti di un singolo dominio Active Directory che devono accedere alle risorse di Google Cloud, ad esempio alle applicazioni web che utilizzano IWA per l'autenticazione.

Vantaggi:

  • Le risorse ospitate suGoogle Cloudnon 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 Google CloudPuoi 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 unGoogle Cloud progetto e 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 le due foreste di Active Directory utilizzando una relazione di attendibilità unidirezionale in modo che Active Directory ospitato su Google Cloudabbia attendibilità per la tua foresta 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 domain controller on-premise vengono applicati aGoogle 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