Questo articolo è la seconda parte di una serie in più parti che descrive come estendere la soluzione di gestione delle identità a Google Cloud per consentire agli utenti della tua forza lavoro di autenticare e utilizzare servizi in un ambiente di computing ibrido.
La serie è composta dai seguenti articoli:
- Autenticazione degli utenti della forza lavoro in un ambiente ibrido
- Modelli per l'autenticazione degli utenti della forza lavoro in un ambiente ibrido (questo articolo)
Introduzione
Quando estendi il tuo panorama IT a Google Cloud nell'ambito di una strategia ibrida, ti consigliamo di adottare un approccio coerente alla gestione delle identità in più ambienti. Durante la progettazione e la personalizzazione dell'architettura per soddisfare questi vincoli e requisiti, puoi fare affidamento su alcuni pattern comuni. Questi modelli rientrano in due categorie:
- Pattern per la federazione di un provider di identità (IdP) esterno con Google Cloud. Lo scopo di questi pattern è consentire a Google di diventare un IdP per gli utenti della tua forza lavoro, in modo che le identità Google vengano mantenute automaticamente e che l'IdP rimanga la fonte attendibile.
- Pattern per l'estensione di un IdP a Google Cloud. In questi pattern, puoi consentire alle applicazioni di cui è stato eseguito il deployment su Google Cloud di riutilizzare il tuo IdP, connettendoti direttamente all'IdP o gestendo una replica del tuo IdP su Google Cloud.
Pattern per federare un IdP esterno con Google Cloud
Per abilitare l'accesso alla console Google Cloud, a Google Cloud CLI o a qualsiasi altra risorsa che utilizza Google come IdP, l'utente della forza lavoro deve avere un'identità Google. Mantenere le identità Google per ogni dipendente sarebbe complicato quando tutti i dipendenti hanno già un account in un IdP. Federando le identità degli utenti tra il tuo IdP e Google Cloud, puoi automatizzare la manutenzione degli Account Google e collegare il loro ciclo di vita agli account esistenti. La federazione aiuta a garantire quanto segue:
- L'IdP rimane l'unica fonte attendibile per la gestione delle identità.
- Per tutti gli account utente gestiti dall'IdP o per un sottoinsieme selezionato di questi account, viene creato automaticamente un Account Google.
- Se un account viene disattivato o eliminato nell'IdP, l'Account Google corrispondente viene sospeso o eliminato.
- Per impedire la copia di password o altre credenziali, l'atto di autenticazione di un utente viene delegato al tuo IdP.
Federare Active Directory con Cloud Identity utilizzando GCDS e AD FS
Se utilizzi Active Directory come IdP, puoi federe Active Directory con Cloud Identity utilizzando Google Cloud Directory Sync (GCDS) e Active Directory Federation Services (ADFS):
- Google Cloud Directory Sync è uno strumento gratuito fornito da Google che implementa il processo di sincronizzazione. Google Cloud Directory Sync comunica con Google Identity Platform tramite SSL (Secure Sockets Layer) e di solito viene eseguito nell'ambiente di elaborazione esistente.
- AD FS è fornito da Microsoft come parte di Windows Server. Con AD FS, puoi utilizzare Active Directory per l'autenticazione federata. AD FS viene generalmente eseguito nell'ambiente di elaborazione esistente.
Per informazioni più dettagliate su questo approccio, consulta Federazione di GCP con Active Directory.
Per una variante di questo pattern, puoi anche utilizzare Active Directory Lightweight Directory Services (AD LDS) o una directory LDAP diversa con AD FS o un altro IdP conforme a SAML.
Esperienza utente
- Quando richiedi la risorsa protetta, il sistema ti reindirizzerà alla schermata di accesso di Google, che richiede l'indirizzo email.
- Se è noto che l'indirizzo email è associato a un account che è stato sincronizzato da Active Directory, verrai reindirizzato ad AD FS.
- A seconda della configurazione di AD FS, è possibile che venga visualizzata una schermata di accesso che richiede il nome utente e la password di Active Directory. Oppure AD FS potrebbe tentare di farti accedere automaticamente in base alle tue credenziali di accesso a Windows (IWA).
- Una volta eseguito l'autenticazione da AD FS, il sistema ti reindirizzerà alla risorsa protetta.
Vantaggi
- L'approccio consente un'esperienza Single Sign-On per tutte le applicazioni e le risorse on-premise su Google Cloud.
- Se hai configurato AD FS per richiedere l'autenticazione a più fattori, la configurazione si applica automaticamente a Google Cloud.
- Non è necessario sincronizzare password o altre credenziali con Google.
- Poiché l'API Cloud Identity è accessibile pubblicamente, non è necessario configurare la connettività ibrida tra la rete on-premise e Google Cloud.
best practice
- Active Directory e Cloud Identity utilizzano una struttura logica diversa. Assicurati di comprendere le differenze e di valutare quale metodo di mappatura di domini, identità e gruppi è più adatto alla tua situazione. Per informazioni più dettagliate, consulta la nostra guida alla federazione di Google Cloud con Active Directory.
- Sincronizzare i gruppi oltre agli utenti. Con questo approccio, puoi configurare IAM in modo da poter utilizzare le iscrizioni ai gruppi in Active Directory per controllare chi ha accesso alle risorse in Google Cloud.
- Esegui il deployment di AD FS ed esponilo in modo che gli utenti della forza lavoro possano accedervi, ma non esporlo più del necessario. Anche se gli utenti della forza lavoro devono essere in grado di accedere ad AD FS, non esiste alcun requisito che AD FS sia raggiungibile da Google o da qualsiasi applicazione di cui è stato eseguito il deployment su Google Cloud.
- Potresti abilitare l'autenticazione integrata di Windows (IWA) in AD FS per consentire agli utenti di accedere automaticamente in base alle credenziali di accesso a Windows.
- Se AD FS non è più disponibile, gli utenti potrebbero non essere in grado di utilizzare la console Google Cloud o qualsiasi altra risorsa che utilizza Google come IdP. Pertanto, assicurati che AD FS e i controller di dominio su cui si basa AD FS vengano distribuiti e ridimensionati in modo da soddisfare i tuoi obiettivi di disponibilità.
- Se utilizzi Google Cloud per garantire la continuità aziendale, fare affidamento su un AD FS on-premise potrebbe compromettere l'intento di utilizzare Google Cloud come copia indipendente del deployment. In questo caso, valuta la possibilità di eseguire il deployment delle repliche di tutti i sistemi pertinenti su Google Cloud:
- Replica la tua Active Directory in Google Cloud ed esegui il deployment di GCDS per l'esecuzione su Google Cloud.
- Eseguire server AD FS dedicati su Google Cloud. Questi server utilizzano i controller di dominio Active Directory in esecuzione su Google Cloud.
- Configura Cloud Identity per utilizzare i server AD FS di cui è stato eseguito il deployment in Google Cloud per il Single Sign-On.
Federazione di Azure AD con Cloud Identity
Se sei un cliente Microsoft Office 365 o Azure, potresti aver connesso la tua Active Directory on-premise ad Azure AD. Se tutti gli account utente che potenzialmente devono accedere a Google Cloud sono già in fase di sincronizzazione con Azure AD, puoi riutilizzare questa integrazione federando Cloud Identity con Azure AD, come mostra il seguente diagramma.
Per informazioni più dettagliate su questo approccio, consulta Federazione di GCP con Azure Active Directory.
Esperienza utente
- Quando richiedi la risorsa protetta, il sistema ti reindirizzerà alla schermata di accesso di Google, che richiede l'indirizzo email.
- Se l'indirizzo email è associato a un account che è stato sincronizzato da Azure AD, si aprirà la pagina di Azure AD.
- A seconda di come è connessa la tua Active Directory on-premise ad Azure AD, Azure AD potrebbe chiederti un nome utente e una password. oppure potrebbe reindirizzarti a un server AD FS on-premise.
- Dopo l'autenticazione con Azure AD, il sistema ti reindirizzerà alla risorsa protetta.
Vantaggi
- Non è necessario installare software aggiuntivo on-premise.
- L'approccio consente un'esperienza Single Sign-On per Office 365, Azure e risorse su Google Cloud.
- Se hai configurato Azure AD per richiedere l'autenticazione a più fattori (MFA), l'autenticazione MFA si applica automaticamente a Google Cloud.
- Se la tua Active Directory on-premise utilizza più domini o foreste e hai impostato una configurazione personalizzata di Azure AD Connect per mappare questa struttura a un tenant Azure AD, puoi sfruttare questa operazione di integrazione.
- Non è necessario sincronizzare password o altre credenziali con Google.
- Poiché l'API Cloud Identity è accessibile pubblicamente, non è necessario configurare la connettività ibrida tra la rete on-premise e Google Cloud o tra Azure e Google Cloud.
- Puoi visualizzare la console Google Cloud come riquadro nel portale di Office 365.
best practice
- Poiché Azure AD e Cloud Identity utilizzano una struttura logica diversa, assicurati di comprendere le differenze. Valuta quale modo di mappare domini, identità e gruppi si adatta meglio alla tua situazione. Per informazioni più dettagliate, consulta federe Google Cloud con Azure AD.
- Sincronizzare i gruppi oltre agli utenti. Con questo approccio, puoi configurare IAM in modo da poter utilizzare le iscrizioni ai gruppi in Azure AD per controllare chi ha accesso alle risorse in Google Cloud.
- Se utilizzi Google Cloud per garantire la continuità aziendale, affidarti ad Azure AD per l'autenticazione potrebbe compromettere l'intento di utilizzare Google Cloud come copia indipendente del deployment.
Modelli per l'estensione di un IdP esterno a Google Cloud
Alcune delle applicazioni di cui prevedi di eseguire il deployment su Google Cloud potrebbero richiedere l'utilizzo di protocolli di autenticazione non offerti da Cloud Identity. Per supportare questi carichi di lavoro, devi consentire a queste applicazioni di utilizzare il tuo IdP da Google Cloud.
Le seguenti sezioni descrivono pattern comuni per consentire l'utilizzo dell'IdP da parte dei carichi di lavoro di cui è stato eseguito il deployment su Google Cloud.
Esposizione di un AD FS on-premise su Google Cloud
Se un'applicazione richiede l'utilizzo di WS-Trust o WS-Federation, oppure si basa su funzionalità o attestazioni specifiche di AD FS quando si utilizza OpenID Connect, puoi consentire all'applicazione di utilizzare direttamente AD FS per l'autenticazione.
Grazie ad AD FS, un'applicazione può autenticare un utente. Tuttavia, poiché l'autenticazione non è basata su un'identità Google, l'applicazione non sarà in grado di eseguire chiamate API autenticate con credenziali utente. Tutte le chiamate alle API Google Cloud devono invece essere autenticate utilizzando un account di servizio.
Esperienza utente
- Quando richiedi la risorsa protetta, il sistema ti reindirizzerà alla schermata di accesso di ADFS, che richiede l'indirizzo email. Se AD FS non è esposto pubblicamente su internet, per accedere ad AD FS potrebbe essere necessario connettersi alla rete aziendale o alla VPN aziendale.
- A seconda della configurazione di AD FS, è possibile che venga visualizzata una schermata di accesso che richiede il nome utente e la password di Active Directory. Oppure AD FS potrebbe tentare di farti accedere automaticamente in base alle tue credenziali di accesso a Windows.
- Una volta eseguito l'autenticazione da AD FS, il sistema ti reindirizzerà alla risorsa protetta.
Vantaggi
- Puoi utilizzare protocolli di autenticazione non supportati da Cloud Identity, tra cui WS-Trust e WS-Federation.
- Se l'applicazione è stata sviluppata e testata rispetto ad AD FS, puoi evitare i rischi che potrebbero derivare dal passaggio dell'applicazione all'utilizzo di Cloud Identity.
- Non è necessario configurare la connettività ibrida tra la rete on-premise e Google Cloud.
best practice
- Esegui il deployment di AD FS ed esponilo in modo che gli utenti della forza lavoro possano accedervi, ma non esporlo più del necessario. Anche se gli utenti della forza lavoro devono essere in grado di accedere ad AD FS, non esiste alcun requisito che AD FS sia raggiungibile da Google o da qualsiasi applicazione di cui è stato eseguito il deployment su Google Cloud.
- Se AD FS non è più disponibile, gli utenti potrebbero non essere più in grado di utilizzare l'applicazione. Assicurati che AD FS e i controller di dominio su cui si basa siano sottoposti a deployment e dimensionati in modo da soddisfare gli obiettivi di disponibilità.
- Valuta la possibilità di eseguire il refactoring delle applicazioni che si basano su WS-Trust e WS-Federation per utilizzare SAML o OpenID Connect.
- Se l'applicazione si basa sulle informazioni del gruppo esposte come dichiarazioni in
IdTokensemesse da ADFS, valuta la possibilità di recuperare le informazioni del gruppo da un'origine diversa, ad esempio l'API Directory. L'esecuzione di query sull'API Directory è un'operazione con privilegi che richiede l'utilizzo di un account di servizio abilitato per la delega a livello di dominio di Google Workspace.
Esposizione di una directory LDAP on-premise a Google Cloud
Alcune delle tue applicazioni potrebbero richiedere agli utenti di fornire nome utente e password e di utilizzare queste credenziali per tentare un'operazione di associazione LDAP. Se non riesci a modificare queste applicazioni per utilizzare altri metodi, ad esempio SAML, per eseguire l'autenticazione, puoi concedere loro l'accesso a una directory LDAP on-premise.
Vantaggi
- Non è necessario modificare l'applicazione.
best practice
- Utilizza Cloud VPN o Cloud Interconnect per stabilire una connettività ibrida tra Google Cloud e la tua rete on-premise, in modo da non dover esporre la directory LDAP su internet.
- Verifica che la latenza introdotta eseguendo una query su una directory LDAP on-premise non influisca negativamente sull'esperienza utente.
- Assicurati che la comunicazione tra l'applicazione e la directory LDAP sia criptata. Puoi ottenere questa crittografia utilizzando Cloud VPN o Cloud Interconnect con LDAP/S.
- Se la directory LDAP o la connettività privata tra Google Cloud e la rete on-premise non sono più disponibili, gli utenti potrebbero non essere più in grado di utilizzare un'applicazione basata su LDAP. Pertanto, assicurati che venga eseguito il deployment dei rispettivi server e che vengano dimensionati in modo da soddisfare gli obiettivi di disponibilità e valuta la possibilità di utilizzare tunnel VPN ridondanti o interconnessioni.
- Se utilizzi Google Cloud per garantire la continuità aziendale, l'utilizzo di una directory LDAP on-premise potrebbe compromettere l'intento di utilizzare Google Cloud come copia indipendente del deployment esistente. In questo caso, prendi in considerazione la replica della directory LDAP in Google Cloud.
- Se utilizzi Active Directory, valuta la possibilità di eseguire una replica su Google Cloud, in particolare se prevedi di aggiungere ad Active Directory macchine Windows aggiunte al dominio in esecuzione su Google Cloud.
Replica di una directory LDAP on-premise su Google Cloud
La replica di una directory LDAP on-premise in Google Cloud è simile al pattern dell'esposizione di una directory LDAP on-premise a Google Cloud. Per le applicazioni che utilizzano LDAP per verificare nomi utente e password, lo scopo di questo approccio è poter eseguire le applicazioni su Google Cloud. Anziché consentire a queste applicazioni di eseguire query sulla directory LDAP on-premise, puoi mantenere una replica della directory on-premise su Google Cloud.
Vantaggi
- Non è necessario modificare l'applicazione.
- La disponibilità delle applicazioni basate su LDAP in esecuzione su Google Cloud non dipende dalla disponibilità della directory on-premise o dalla connettività alla rete on-premise. Questo pattern è particolarmente adatto per scenari ibridi di continuità aziendale.
best practice
- Utilizza Cloud VPN o Cloud Interconnect per stabilire una connettività ibrida tra Google Cloud e la tua rete on-premise, in modo da non dover esporre la directory LDAP su internet.
- Assicurati che la replica tra la directory LDAP on-premise venga eseguita su un canale sicuro.
- Esegui il deployment di più repliche di directory LDAP in più zone o regioni per raggiungere i tuoi obiettivi di disponibilità. Puoi utilizzare un bilanciatore del carico interno per distribuire le connessioni LDAP tra più repliche di cui è stato eseguito il deployment nella stessa area geografica.
- Utilizza un progetto Google Cloud separato con un VPC condiviso per eseguire il deployment delle repliche LDAP e concedere l'accesso a questo progetto sulla base del privilegio minimo.
Estensione di una Active Directory on-premise a Google Cloud
Alcuni dei carichi di lavoro di cui prevedi di eseguire il deployment su Google Cloud potrebbero dipendere dai servizi di dominio Active Directory, ad esempio:
- Computer Windows che devono essere uniti al dominio
- Applicazioni che utilizzano Kerberos o NTLM per l'autenticazione
- Le applicazioni che usano Active Directory come directory LDAP per verificare nomi utente e password
Per supportare questi carichi di lavoro, puoi estendere la tua foresta di Active Directory on-premise a Google Cloud, ad esempio eseguendo il deployment di una foresta di risorse in Google Cloud e connettendola alla tua foresta Active Directory on-premise, come illustrato nel diagramma seguente.
Per ulteriori dettagli su questo approccio e su altri modi per eseguire il deployment di Active Directory in un ambiente ibrido, consulta Pattern per l'utilizzo di Active Directory in un ambiente ibrido.
Vantaggi
- I carichi di lavoro possono sfruttare appieno Active Directory, inclusa la possibilità di aggiungere macchine Windows al dominio Active Directory.
- La disponibilità delle applicazioni basate su Active Directory in esecuzione su Google Cloud non dipende dalla disponibilità delle risorse on-premise o dalla connettività alla rete on-premise. Il modello è adatto per scenari ibridi di continuità aziendale.
best practice
- Utilizza Cloud VPN o Cloud Interconnect per stabilire una connettività ibrida tra Google Cloud e la tua rete on-premise.
- Per ridurre al minimo la comunicazione tra Google Cloud e la tua rete on-premise, crea un sito Active Directory separato per i deployment di Google Cloud. Puoi utilizzare un singolo sito per VPC condiviso o, per ridurre al minimo le comunicazioni tra regioni, un sito per VPC condiviso e regione.
- Crea un dominio Active Directory separato dedicato alle risorse di cui è stato eseguito il deployment in Google Cloud e aggiungi il dominio alla foresta esistente. L'utilizzo di un dominio separato consente di ridurre l'overhead di replica e le dimensioni delle partizioni.
- Per aumentare la disponibilità, esegui il deployment di almeno due controller di dominio distribuiti su più zone. Se usi più regioni, valuta la possibilità di eseguire il deployment dei controller di dominio in ogni regione.
- Utilizza un progetto Google Cloud separato con un VPC condiviso per eseguire il deployment dei controller di dominio e concedere l'accesso a questo progetto sulla base del privilegio minimo. Generando una password o accedendo alla console seriale delle istanze del controller di dominio, i membri non autorizzati del progetto potrebbero altrimenti compromettere il dominio.
- Valuta la possibilità di eseguire il deployment di una server farm AD FS e di GCDS su Google Cloud. Questo approccio ti consente di federe Active Directory con Cloud Identity senza dipendere dalla disponibilità delle risorse o dalla connettività alla rete on-premise.
Passaggi successivi
- Scopri di più su come federe Google Cloud con Active Directory.
- Scopri di più sui pattern per l'utilizzo di Active Directory in un ambiente ibrido.
- Scopri come federe Cloud Identity con Azure AD.
- Progetta la gerarchia delle risorse per la tua zona di destinazione Google Cloud.
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Dai un'occhiata al nostro Cloud Architecture Center.