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

Last reviewed 2024-06-26 UTC

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

La serie è composta dai seguenti documenti:

• Autenticazione degli utenti della forza lavoro in un ambiente ibrido
• Modelli per l'autenticazione degli utenti del personale 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à in più ambienti. Quando progetti e personalizzi l'architettura per soddisfare questi vincoli e requisiti, puoi fare affidamento su alcuni pattern comuni. Questi pattern rientrano in due categorie:

• Modelli 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 il tuo IdP rimanga l'origine di riferimento.
• Pattern per estendere un provider di identità a Google Cloud. In questi pattern, consenti alle applicazioni di cui è stato eseguito il deployment su Google Cloud di riutilizzare il tuo IdP collegandosi direttamente o mantenendo una replica del tuo IdP su Google Cloud.

Pattern per la federazione di un provider di identità esterno con Google Cloud

Per consentire l'accesso alla console Google Cloud, a Google Cloud CLI o a qualsiasi altra risorsa che utilizza Google come IdP, un utente della forza lavoro deve disporre di un'identità Google. Gestire le identità Google per ogni dipendente sarebbe complicato se tutti i dipendenti hanno già un account in un provider di identità. Se esegui la federazione delle identità utente tra il tuo IdP e Google Cloud, puoi automatizzare la manutenzione degli Account Google e associarne il ciclo di vita agli account esistenti. La federazione contribuisce a garantire quanto segue:

• Il tuo provider di identità rimane l'unica fonte attendibile per la gestione delle identità.
• Per tutti gli account utente gestiti dalla tua 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 fornitore di servizi di identità.

Eseguire la federazione di Active Directory con Cloud Identity utilizzando Google Cloud Directory Sync e AD FS

Se utilizzi Active Directory come provider di identità, 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 di solito viene eseguito nell'ambiente di calcolo 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 solitamente eseguito nell'ambiente di calcolo esistente.

Per informazioni più dettagliate su questo approccio, consulta Eseguire la federazione di Google Cloud con Active Directory.

Per una variante di questo pattern, puoi anche utilizzare Active Directory Lightweight Directory Services (AD LDS) o un'altra directory LDAP con AD FS o un altro IdP conforme a SAML.

Esperienza utente

1. Quando richiedi la risorsa protetta, viene visualizzata la schermata di accesso a Google, in cui ti viene chiesto il tuo indirizzo email.
2. Se è noto che l'indirizzo email è associato a un account che è stato sincronizzato da Active Directory, viene visualizzato un messaggio di reindirizzamento 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 farti accedere automaticamente in base al tuo accesso Windows (IWA).
4. Una volta autenticato, AD FS ti reindirizzerà alla risorsa protetta.

Vantaggi

• L'approccio consente un'esperienza di accesso singolo per le applicazioni e le risorse on-premise su Google Cloud.
• Se hai configurato AD FS in modo che richieda l'autenticazione a più fattori, questa configurazione viene applicata 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 valuta quale metodo di mappatura di domini, identità e gruppi è più adatto alla tua situazione. Per informazioni più dettagliate, consulta la nostra guida sulla federazione di Google Cloud con Active Directory.
• Sincronizzare i gruppi oltre agli utenti. Con questo approccio, puoi configurare IAM in modo da utilizzare le iscrizioni ai gruppi in Active Directory per controllare chi ha accesso alle risorse in Google Cloud.
• Esegui il deployment e esponi AD FS in modo che gli utenti del personale 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 al loro accesso a Windows.
• Se AD FS non è 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 siano di dimensioni adeguate e siano dipiattaforma 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 minare l'intenzione di utilizzare Google Cloud come copia indipendente del tuo deployment. In questo caso, valuta la possibilità di eseguire il deployment di repliche di tutti i sistemi pertinenti su Google Cloud:
  • Esegui la replica di Active Directory su Google Cloud e esegui il deployment di GCDS in modo che venga eseguito su Google Cloud.
  • Esegui server AD FS dedicati su Google Cloud. Questi server utilizzano i controller di dominio Active Directory in esecuzione su Google Cloud.
  • Configura Cloud Identity in modo da utilizzare i server AD FS di cui è stato eseguito il deployment su Google Cloud per il Single Sign-On.

Eseguire la federazione di Azure AD con Cloud Identity

Se sei un cliente Microsoft Office 365 o Azure, potresti aver collegato la tua Active Directory on-premise ad Azure AD. Se tutti gli account utente che potenzialmente richiedono l'accesso 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, consulta Eseguire la federazione di Google Cloud con Azure Active Directory.

Esperienza utente

1. Quando richiedi la risorsa protetta, viene visualizzata la schermata di accesso a Google, in cui ti viene chiesto il tuo indirizzo email.
2. Se l'indirizzo email è associato a un account sincronizzato da Azure AD, verrà visualizzato un messaggio di reindirizzamento ad Azure AD.
3. A seconda di come Active Directory on-premise è connesso ad Azure AD, quest'ultimo potrebbe chiederti un nome utente e una password. In alternativa, potrebbe essere visualizzato un messaggio di reindirizzamento ad un AD FS on-premise.
4. Dopo l'autenticazione con Azure AD, il sistema ti reindirizzerà nuovamente alla risorsa protetta.

Vantaggi

• Non è necessario installare alcun software aggiuntivo on-premise.
• L'approccio consente un'esperienza di Single Sign-On in Office 365, in Azure e nelle risorse su Google Cloud.
• Se hai configurato Azure AD in modo che richieda l'autenticazione a più fattori (MFA), l'MFA 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 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 metodo di mappatura di domini, identità e gruppi è più adatto alla tua situazione. Per informazioni più dettagliate, consulta la sezione sulla federazione di Google Cloud con Azure AD.
• Sincronizzare i gruppi oltre agli utenti. Con questo approccio, puoi configurare IAM in modo da 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, fare affidamento su Azure AD per l'autenticazione potrebbe minare l'intenzione di utilizzare Google Cloud come copia indipendente del tuo deployment.

Pattern per estendere un IdP esterno a Google Cloud

Alcune delle applicazioni che prevedi di eseguire 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 sezioni seguenti descrivono pattern comuni per consentire l'utilizzo della tua identity provider 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 o si basa su funzionalità o claim specifici di AD FS quando utilizzi 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 potrà eseguire chiamate API autenticate con le credenziali utente. Invece, qualsiasi chiamata alle API Google Cloud deve essere autenticata utilizzando un account di servizio.

Esperienza utente

1. Quando richiedi la risorsa protetta, viene visualizzata la schermata di accesso ADFS, in cui ti viene chiesto il tuo indirizzo email. Se AD FS non è esposto pubblicamente su internet, per accedere ad AD FS potrebbe essere necessario collegarti alla rete aziendale o alla VPN aziendale.
2. A seconda della configurazione di AD FS, potresti visualizzare una schermata di accesso che richiede il nome utente e la password di Active Directory. In alternativa, AD FS potrebbe tentare di farti accedere automaticamente in base al tuo accesso a Windows.
3. Una volta autenticato, AD FS 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 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 e esponi AD FS in modo che gli utenti del personale 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 è 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 di dimensioni adeguate e siano implementati in modo da soddisfare i tuoi obiettivi di disponibilità.
• Valuta la possibilità di eseguire il refactoring delle applicazioni che si basano su WS-Trust e WS-Federation in modo da utilizzare SAML o OpenID Connect.
• Se l'applicazione si basa su informazioni del gruppo esposte come rivendicazioni in IdTokens emesse da AD FS, valuta la possibilità di recuperare le informazioni del gruppo da un'altra origine, ad esempio l'API Directory. L'esecuzione di query sull'API Directory è un'operazione privilegiata che richiede l'utilizzo di un account di servizio per cui è attivata 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 il nome utente e la password e utilizzare queste credenziali per tentare un'operazione di associazione LDAP. Se non puoi modificare queste applicazioni per utilizzare altri mezzi come SAML per eseguire l'autenticazione, puoi conceder loro 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 dalla query di un 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 è disponibile, gli utenti potrebbero non essere più in grado di utilizzare un'applicazione basata su LDAP. Pertanto, assicurati che i rispettivi server siano di dimensioni adeguate e siano stati implementati in modo da 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, fare affidamento su una directory LDAP on-premise potrebbe minare l'intenzione di utilizzare Google Cloud come copia indipendente del tuo deployment esistente. In questo caso, ti consigliamo di replicare la directory LDAP su Google Cloud.
• Se utilizzi Active Directory, valuta la possibilità di eseguire una replica su Google Cloud, in particolare se prevedi di aggiungere i computer Windows in esecuzione su Google Cloud ad Active Directory.

Replicare una directory LDAP on-premise su 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 è poterle eseguire su Google Cloud. Anziché consentire a queste applicazioni di eseguire query sulla tua 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 è adatto per scenari ibride di business continuity.

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 della 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 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 carichi di lavoro che prevedi di eseguire su Google Cloud potrebbero dipendere da Active Directory Domain Services, ad esempio:

• Computer Windows che devono essere associati al 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 su Google Cloud e collegandola alla foresta Active Directory on-premise, come nel seguente diagramma.

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 tuoi carichi di lavoro possono sfruttare appieno Active Directory, inclusa la possibilità di unire i computer 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 pattern è ben adatto per gli 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 distinto per i deployment di Google Cloud. Puoi utilizzare un singolo sito per VPC condiviso o, per minimizzare le comunicazioni interregionali, un sito per VPC condiviso e regione.
• Crea un dominio Active Directory separato dedicato alle risorse di cui è stato eseguito il deployment su Google Cloud e aggiungilo alla foresta esistente. L'utilizzo di un dominio distinto consente di ridurre il sovraccarico della replica e le dimensioni delle partizioni.
• Per aumentare la disponibilità, esegui il deployment di almeno due controller di dominio, distribuiti su più zone. Se utilizzi più regioni, ti consigliamo di implementare i 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 di minima autorizzazione. Se generano una password o accedono alla console seriale delle istanze del controller di dominio, i membri del progetto malintenzionati potrebbero essere in grado di compromettere il dominio.
• Valuta la possibilità di eseguire il deployment di un farm di server AD FS e GCDS su Google Cloud. Questo approccio ti consente di federare 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 eseguire la federazione di 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 zona di destinazione Google Cloud.
• Per altre architetture di riferimento, diagrammi e best practice, visita il Cloud Architecture Center.