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 della forza lavoro in un ambiente ibrido (questo documento)

Introduzione

Quando estendi il tuo ambiente IT su Google Cloud nell'ambito di un 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:

• 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 vengano mantenute le identità Google automaticamente e l'IdP rimane la fonte attendibile.
• 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 collegandosi direttamente o mantenendo una replica del tuo IdP su Google Cloud.

Pattern per federare un IdP esterno con Google Cloud

Per consentire l'accesso alla console Google Cloud, alla CLI Google Cloud 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 gravoso quando tutti i dipendenti dispongono già di un account in un IdP. Se esegui la federazione delle identità utente tra il tuo provider di identità 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:

• 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 per 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 l'autenticazione di un utente viene delegata al tuo IdP.

Federate 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 durante il processo di sincronizzazione. GCDS comunica con Identity Platform su SSL (Secure Sockets Layer) e di solito viene eseguito l'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 usare 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 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, potrebbe essere visualizzata una schermata di accesso che richiede il nome utente e la password di Active Directory. Oppure AD FS potrebbe tentare di accedere automaticamente in base alle tue credenziali di accesso a Windows (IWA).
4. Una volta che AD FS ha eseguito l'autenticazione, il sistema ti reindirizzerà 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, 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 logica alla struttura del centro di costo. Assicurati di comprendere le differenze e valuta quale metodo di mappatura di domini, identità e gruppi è più adatto alla tua situazione. Consulta le nostre guida alla federazione di Google Cloud con Active Directory per informazioni più dettagliate.
• Sincronizzare i gruppi, oltre agli utenti. Con questo approccio, puoi definire di IAM per poter utilizzare le appartenenze ai gruppi in stato Directory per controllare chi può accedere 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 è più disponibile, gli utenti potrebbero non essere in grado di utilizzare Console Google Cloud o qualsiasi altra risorsa che utilizza Google come IdP. Quindi... assicura che AD FS e i controller di dominio su cui si basa AD FS deployment e dimensioni 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 delle repliche di tutti i sistemi pertinenti su Google Cloud:
  • Replica la tua Active Directory in Google Cloud ed eseguire il deployment di GCDS per eseguirlo 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 per utilizzare i server AD FS di cui è stato eseguito il deployment in Google Cloud per il Single Sign-On.

Eseguire la federazione di Azure AD con Cloud Identity

Se sei un cliente di Microsoft Office 365 o Azure, potresti dover connesso la tua Active Directory on-premise ad Azure AD. Se tutti gli account utente che potenzialmente hanno bisogno di accedere a Google Cloud sono già in fase di sincronizzazione ad Azure AD, puoi riutilizzare questa integrazione attraverso la federazione di Cloud Identity con Azure AD, come mostra il diagramma seguente.

Per ulteriori informazioni su questo approccio, consulta Google Cloud federato con Azure Active Directory.

Esperienza utente

1. Quando richiedi la risorsa protetta, si apre la pagina di accesso in cui viene richiesto l'indirizzo email.
2. Se l'indirizzo email è associato a un account con sincronizzato da Azure AD, il sistema ti reindirizzerà ad Azure AD.
3. A seconda di come è connessa la tua Active Directory on-premise Azure AD, Azure AD potrebbe richiedere 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 Single Sign-On su Office 365, Azure e risorse su Google Cloud.
• Se hai configurato Azure AD per richiedere l'autenticazione a più fattori (MFA), 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 struttura a un tenant Azure AD, puoi sfruttare questa integrazione al lavoro.
• 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. Valutare qual è il modo la mappatura di domini, identità e gruppi si adatta meglio alla situazione. Per maggiori informazioni informazioni dettagliate, vedi federare 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 lo scopo 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 usare il tuo IdP dall'interno di Google Cloud.

Le seguenti sezioni descrivono i modelli comuni per consentire agli utenti IdP che deve essere utilizzato dai carichi di lavoro di cui è stato eseguito il deployment su Google Cloud.

Esponi un AD FS on-premise in Google Cloud

Se un'applicazione richiede l'utilizzo di WS-Trust o WS-Federation o si basa su alle funzionalità o alle rivendicazioni specifiche di AD FS quando utilizzi OpenID Connect, puoi consentire l'applicazione per 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 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, potrebbe essere visualizzata 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

• Eseguire il deployment ed esporre AD FS in modo che gli utenti della forza lavoro possano accedervi, non esporli 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 in grado di utilizzare l'applicazione. Assicurati che AD FS e i controller di dominio lo eseguano il deployment e le dimensioni necessarie per soddisfare gli 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 sui gruppi esposte come rivendicazioni in IdTokens emesse da AD FS, valuta la possibilità di recuperare le informazioni sul gruppo da un'altra origine, 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 che è abilitato per 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 proprio nome utente e e utilizzare queste credenziali per tentare un'operazione di associazione LDAP. Se non può modificare queste applicazioni di utilizzare altri mezzi come SAML per eseguire l'autenticazione, puoi concedere a una directory LDAP on-premise.

Vantaggi

• Non è necessario modificare l'applicazione.

Best practice

• Utilizza le funzionalità di Cloud VPN o Cloud Interconnect per stabilire la connettività ibrida tra Google Cloud e 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.
• Verificare che la comunicazione tra l'applicazione e il protocollo LDAP è crittografata. Puoi ottenere questa crittografia utilizzando Cloud VPN o utilizzando Cloud Interconnect con LDAP/S.
• Se la directory LDAP o la connettività privata tra Google Cloud e la tua rete on-premise non sono più disponibili, gli utenti potrebbe non essere più in grado di utilizzare un'applicazione basata su LDAP. Pertanto, garantire che il deployment dei rispettivi server e le relative dimensioni per soddisfare gli obiettivi di disponibilità e valuta la possibilità di tunnel VPN ridondanti o interconnect.
• 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, soprattutto se prevedi di aggiungere i computer 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 su Google Cloud è simile alla lo schema di Presentazione 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 a scenari ibridi di continuità aziendale.

Best practice

• Utilizza Cloud VPN o Cloud Interconnect per stabilire una connettività ibrida tra Google Cloud e la tua in modo da non dover esporre la directory LDAP su internet.
• Assicurati che la replica tra la directory LDAP on-premise sia condotte su un canale sicuro.
• Eseguire il deployment di più repliche di directory LDAP su 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 carichi di lavoro di cui prevedi di eseguire il deployment su Google Cloud potrebbero dipendere su Active Directory Domain Services, ad esempio:

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

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

Per maggiori dettagli su questo approccio e su altri modi per eseguire il deployment di Active Directory in un ambiente ibrido, vedi 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. Lo schema è 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.
• Per ridurre al minimo la comunicazione tra Google Cloud e la tua rete on-premise crea un sito Active Directory separato per Google Cloud deployment di machine learning. Puoi utilizzare un singolo sito per VPC condivisa o, per minimizzare le comunicazioni tra regioni, un sito per VPC condivisa e regione.
• Crea un dominio Active Directory separato dedicato alle risorse di cui è stato eseguito il deployment Google Cloud e aggiungere il dominio alla foresta esistente. L'utilizzo di un un dominio separato consente di ridurre l'overhead e le dimensioni delle partizioni di replica.
• 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 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 federare Google Cloud con Active Directory.
• Scopri di più sui pattern per utilizzare 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, esplora il Centro architetture cloud.