Modelli per l'autenticazione degli utenti della forza lavoro in un ambiente ibrido

Questo documento è la seconda parte di una serie in più parti che illustra come estendere la soluzione di gestione delle identità a Google Cloud per consentire agli utenti della tua forza lavoro di autenticarsi e utilizzare i servizi in un ambiente di computing ibrido.

La serie è costituita dai seguenti documenti:

• Autenticazione degli utenti della forza lavoro in un ambiente ibrido
• Modelli per l'autenticazione degli utenti aziendali in un ambiente ibrido (questo documento)

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à nei vari ambienti. Quando progetti e personalizzi la tua architettura per soddisfare questi vincoli e requisiti, puoi fare affidamento su alcuni pattern comuni. Questi pattern 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 gestite automaticamente e l'IdP rimanga l'origine di riferimento.
• Pattern per estendere un IdP a Google Cloud. In questi pattern, consenti alle applicazioni di cui è stato eseguito il deployment su Google Cloud di riutilizzare il tuo IdP, connettendoti direttamente o mantenendo una replica dell'IdP su Google Cloud.

Pattern per la federazione di un IdP esterno con Google Cloud

Per consentire l'accesso alla console Google Cloud , alla Google Cloud CLI o a qualsiasi altra risorsa che utilizza Google come IdP, un utente della forza lavoro deve disporre di 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à utente 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 contribuisce a garantire quanto segue:

• Il tuo IdP rimane l'unica fonte di verità per la gestione delle identità.
• Per tutti gli account utente gestiti dal tuo IdP o per un sottoinsieme selezionato di questi account, viene creato automaticamente un Account Google.
• Se un account viene disattivato o eliminato nel tuo IdP, l'Account Google corrispondente viene sospeso o eliminato.
• Per impedire la copia di password o altre credenziali, l'autenticazione di un utente viene delegata al tuo IdP.

Federare Active Directory con Cloud Identity utilizzando Google Cloud Directory Sync e AD FS

Se utilizzi Active Directory come IdP, puoi federare Active Directory con Cloud Identity utilizzando Google Cloud Directory Sync (GCDS) e Active Directory Federation Services (AD FS):

• GCDS è uno strumento gratuito fornito da Google che implementa il processo di sincronizzazione. GCDS comunica con Identity Platform tramite Secure Sockets Layer (SSL) e in genere viene eseguito nell'ambiente di computing esistente.
• AD FS è fornito da Microsoft nell'ambito di Windows Server. Con AD FS, puoi utilizzare Active Directory per l'autenticazione federata. AD FS viene in genere eseguito nell'ambiente di computing esistente.

Per informazioni più dettagliate su questo approccio, vedi Federare Google Cloud 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

1. Quando richiedi la risorsa protetta, viene visualizzata la schermata di accesso di Google, che ti chiede il tuo indirizzo email.
2. Se l'indirizzo email è noto per essere associato a un account sincronizzato da Active Directory, viene reindirizzato ad AD FS.
3. A seconda della configurazione di AD FS, potresti visualizzare una schermata di accesso che ti chiede il nome utente e la password di Active Directory. In alternativa, AD FS potrebbe tentare di accedere automaticamente in base all'accesso a Windows (IWA).
4. Una volta autenticato, AD FS ti reindirizza alla risorsa protetta.

Vantaggi

• L'approccio consente un'esperienza Single Sign-On per le applicazioni e le risorse on-premise su Google Cloud.
• Se hai configurato AD FS in modo da richiedere l'autenticazione a più fattori, questa configurazione viene applicata automaticamente a Google Cloud.
• Non è necessario sincronizzare le 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 valuta quale modo di mappare domini, identità e gruppi è più adatto alla tua situazione. Per informazioni più dettagliate, consulta la nostra guida alla federazione Google Cloud con Active Directory.
• Sincronizza i gruppi oltre agli utenti. Con questo approccio, puoi configurare IAM in modo da utilizzare le appartenenze ai gruppi in Active Directory per controllare chi ha accesso alle risorse in Google Cloud.
• Esegui il deployment ed esponi AD FS in modo che gli utenti della forza lavoro possano accedervi, ma non esporlo più del necessario. Sebbene gli utenti della forza lavoro debbano essere in grado di accedere ad AD FS, non è necessario che AD FS sia raggiungibile da Google o da qualsiasi applicazione di cui è stato eseguito il deployment su Google Cloud.
• Valuta la possibilità di attivare l'autenticazione integrata di Windows (IWA) in AD FS per consentire agli utenti di accedere automaticamente in base all'accesso a Windows.
• Se AD FS non è disponibile, gli utenti potrebbero non essere in grado di utilizzare la consoleGoogle 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 siano implementati e dimensionati per soddisfare i tuoi obiettivi di disponibilità.
• Se utilizzi Google Cloud per garantire la continuità aziendale, affidarsi a 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 Active Directory su Google Cloud e esegui il deployment di GCDS su Google Cloud.
  • Esegui server AD FS dedicati su Google Cloud. Questi server utilizzano i domain controller Active Directory in esecuzione su Google Cloud.
  • Configura Cloud Identity per utilizzare i server AD FS di cui è stato eseguito il deployment su Google Cloud per il Single Sign-On.

Federare Azure AD con Cloud Identity

Se sei un cliente Microsoft Office 365 o Azure, potresti aver collegato Active Directory on-premise ad Azure AD. Se tutti gli account utente che potenzialmente devono accedere a Google Cloud sono già sincronizzati con Azure AD, puoi riutilizzare questa integrazione federando Cloud Identity con Azure AD, come mostrato nel seguente diagramma.

Per informazioni più dettagliate su questo approccio, vedi Federare Google Cloud con Azure Active Directory.

Esperienza utente

1. Quando richiedi la risorsa protetta, viene visualizzata la schermata di accesso di Google, che ti chiede il tuo indirizzo email.
2. Se l'indirizzo email è associato a un account sincronizzato da Azure AD, viene reindirizzato ad Azure AD.
3. A seconda di come è connesso Active Directory on-premise ad Azure AD, Azure AD potrebbe chiederti un nome utente e una password. oppure potrebbe reindirizzarti a un AD FS on-premise.
4. Dopo l'autenticazione riuscita con Azure AD, il sistema ti reindirizza alla risorsa protetta.

Vantaggi

• Non è necessario installare software on-premise aggiuntivi.
• Questo approccio consente un'esperienza Single Sign-On in Office 365, Azure e risorse su Google Cloud.
• Se hai configurato Azure AD in modo da richiedere l'autenticazione a più fattori (MFA), questa viene applicata automaticamente a Google Cloud.
• Se la tua Active Directory on-premise utilizza più domini o foreste e hai configurato una configurazione personalizzata di Azure AD Connect per mappare questa struttura a un tenant Azure AD, puoi sfruttare questa integrazione.
• Non è necessario sincronizzare le password o altre credenziali con Google.
• Poiché l'API Cloud Identity è accessibile pubblicamente, non è necessario configurare la connettività ibrida tra la tua rete on-premise e Google Cloud o tra Azure eGoogle Cloud.
• Puoi visualizzare la console Google Cloud come riquadro nel portale 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 è più adatto alla tua situazione. Per informazioni più dettagliate, consulta la sezione Federazione Google Cloud con Azure AD.
• Sincronizza i gruppi oltre agli utenti. Con questo approccio, puoi configurare IAM in modo da utilizzare le appartenenze ai gruppi in Azure AD per controllare chi ha accesso alle risorse in Google Cloud.
• Se utilizzi Google Cloud per garantire la continuità aziendale, l'utilizzo di Azure AD per l'autenticazione potrebbe compromettere l'intento di utilizzareGoogle Cloud come copia indipendente del deployment.

Pattern per estendere un IdP esterno a Google Cloud

Alcune delle applicazioni che prevedi di implementare su Google Cloud potrebbero richiedere l'utilizzo di protocolli di autenticazione non offerti da Cloud Identity. Per supportare questi workload, devi consentire a queste applicazioni di utilizzare il tuo IdP da Google Cloud.

Le sezioni seguenti descrivono i pattern comuni per consentire l'utilizzo del tuo IdP da parte dei carichi di lavoro di cui è stato eseguito il deployment su Google Cloud.

Esporre un AD FS on-premise a 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 utilizza OpenID Connect, puoi consentire all'applicazione di utilizzare direttamente AD FS per l'autenticazione.

Utilizzando AD FS, un'applicazione può autenticare un utente. Tuttavia, poiché l'autenticazione non si basa su un'identità Google, l'applicazione non sarà in grado di eseguire chiamate API autenticate con le credenziali utente. Al contrario, tutte le chiamate alle API di Google Cloud devono essere autenticate utilizzando un service account.

Esperienza utente

1. Quando richiedi la risorsa protetta, viene visualizzata la schermata di accesso ADFS, che ti chiede l'indirizzo email. Se AD FS non è esposto pubblicamente su internet, l'accesso ad AD FS potrebbe richiedere la connessione alla rete aziendale o alla VPN aziendale.
2. A seconda della configurazione di AD FS, potresti visualizzare una schermata di accesso che ti chiede il nome utente e la password di Active Directory. In alternativa, AD FS potrebbe tentare di accedere automaticamente in base all'accesso a Windows.
3. Una volta autenticato, AD FS ti reindirizza alla risorsa protetta.

Vantaggi

• Puoi utilizzare protocolli di autenticazione non supportati da Cloud Identity, inclusi WS-Trust e WS-Federation.
• Se l'applicazione è stata sviluppata e testata in base 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 tua rete on-premise e Google Cloud.

Best practice

• Esegui il deployment ed esponi AD FS in modo che gli utenti della forza lavoro possano accedervi, ma non esporlo più del necessario. Sebbene gli utenti della forza lavoro debbano essere in grado di accedere ad AD FS, non è necessario 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 da cui dipende siano implementati e dimensionati per soddisfare i tuoi 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 sull'esposizione delle informazioni sui gruppi come attestazioni in IdTokens emesso da AD FS, valuta la possibilità di recuperare le informazioni sui gruppi da un'altra origine, ad esempio l'API Directory. L'interrogazione dell'API Directory è un'operazione privilegiata che richiede l'utilizzo di un service account abilitato per la delega a livello di dominio di Google Workspace.

Esporre una directory LDAP on-premise a Google Cloud

Alcune delle tue applicazioni potrebbero richiedere agli utenti di fornire nome utente e password e utilizzare queste credenziali per tentare un'operazione di binding LDAP. Se non puoi modificare queste applicazioni per utilizzare altri mezzi come 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 la 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 dall'interrogazione di 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 tua rete on-premise non è più disponibile, gli utenti potrebbero non essere più in grado di utilizzare un'applicazione basata su LDAP. Pertanto, assicurati che i rispettivi server siano implementati e dimensionati per soddisfare i tuoi obiettivi di disponibilità e valuta la possibilità di utilizzare tunnel VPN ridondanti o interconnessioni.
• Se utilizzi Google Cloud per garantire la continuità aziendale, affidarsi a una directory LDAP on-premise potrebbe compromettere l'intento di utilizzare Google Cloud come copia indipendente del deployment esistente. In questo caso, valuta la possibilità di replicare la directory LDAP in Google Cloud .
• Se utilizzi Active Directory, valuta la possibilità di eseguire una replica su Google Cloud , soprattutto se prevedi di aggiungere al dominio le macchine Windows in esecuzione su Google Cloud ad Active Directory.

Replica una directory LDAP on-premise in Google Cloud

La replica di una directory LDAP on-premise in Google Cloud è simile al pattern di 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 è quello di poter eseguire queste applicazioni su Google Cloud. Anziché consentire a queste applicazioni di eseguire query nella 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 è ideale per scenari ibridi di business continuity.

Best practice

• Utilizza Cloud VPN o Cloud Interconnect per stabilire la 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 della directory LDAP in più zone o regioni per soddisfare 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 regione.
• Utilizza un progetto Google Cloud separato con un VPC condiviso per eseguire il deployment delle repliche LDAP e concedere l'accesso a questo progetto in base al principio del privilegio minimo.

Estendere un Active Directory on-premise a Google Cloud

Alcuni dei workload che prevedi di eseguire il deployment su Google Cloud potrebbero dipendere da Active Directory Domain Services, ad esempio:

• Macchine Windows che devono essere aggiunte a un dominio
• Applicazioni che utilizzano Kerberos o NTLM per l'autenticazione
• Applicazioni che utilizzano Active Directory come directory LDAP per verificare nomi utente e password

Per supportare questi carichi di lavoro, puoi estendere la foresta Active Directory on-premise a Google Cloud, ad esempio eseguendo il deployment di una foresta di risorse inGoogle Cloud e connettendola alla foresta Active Directory on-premise, come nel seguente diagramma.

Per maggiori 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 tuoi carichi di lavoro possono sfruttare appieno Active Directory, inclusa la possibilità di unire le macchine Windows al dominio Active Directory.
• La disponibilità delle applicazioni basate su Active Directory in esecuzione su Google Cloud non dipende dalla disponibilità di risorse on-premise o dalla connettività alla rete on-premise. Il pattern è ideale per scenari ibridi di business continuity.

Best practice

• Utilizza Cloud VPN o Cloud Interconnect per stabilire la 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 le implementazioni di Google Cloud. Puoi utilizzare un singolo sito per ogni VPC condiviso oppure, per ridurre al minimo la comunicazione tra regioni, un sito per ogni VPC condiviso e regione.
• Crea un dominio Active Directory separato dedicato alle risorse di cui è stato eseguito il deployment su Google Cloud e aggiungi il dominio alla foresta esistente. L'utilizzo di un dominio separato contribuisce a ridurre il sovraccarico di replica e le dimensioni delle partizioni.
• Per aumentare la disponibilità, esegui il deployment di almeno due domain controller, distribuiti su più zone¹. Se utilizzi 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 in base al principio del privilegio minimo. Se generi una password o accedi alla console seriale delle istanze del controller di dominio, i membri del progetto malintenzionati potrebbero altrimenti essere in grado di 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 federare Active Directory con Cloud Identity senza dipendere dalla disponibilità di risorse o dalla connettività alla rete on-premise.

Passaggi successivi

• Scopri di più sulla federazione Google Cloud con Active Directory.
• Scopri di più sui pattern per l'utilizzo di Active Directory in un ambiente ibrido.
• Scopri come federare Cloud Identity con Azure AD.
• Progetta la gerarchia delle risorse per la tua Google Cloud landing zone.
• Per ulteriori architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.