Autentica gli utenti della forza lavoro in un ambiente ibrido

Last reviewed 2024-06-26 UTC

Questo documento è la prima parte di una serie in più parti che illustra come: Estendi la tua soluzione di gestione delle identità a Google Cloud per consentire alla forza lavoro di autenticare e utilizzare i servizi in un ambiente ibrido nell'ambiente di computing.

La serie è costituita dai seguenti componenti:

Introduzione

Per gestire gli account utente e controllare l'accesso dei dipendenti alle applicazioni e delle risorse di calcolo è una responsabilità chiave dei reparti IT di un'impresa. A garantire coerenza ed efficienza amministrativa, la maggior parte delle aziende considera la gestione delle identità una funzione centrale e usare un sistema unificato per le identità di altro tipo. Più comunemente, le aziende si affidano al dominio Microsoft Active Directory (AD DS) per questo scopo.

Quando estendi un panorama IT a Google Cloud nell'ambito di un strategia ibrida, devi mantenere un unico punto in cui le identità gestito. Un sistema unificato di gestione delle identità riduce al minimo gli sforzi amministrativi la gestione degli account e controllo dell'accesso. Questo sistema aiuta anche a garantire che gli utenti e applicazioni possono eseguire l'autenticazione sicura in un ambiente ibrido.

Questo documento illustra i modi per integrare Google Cloud di gestione delle identità. Il documento ti aiuta a scegliere l'approccio più adatta alle tue esigenze.

Sebbene gran parte della discussione si applichi anche Google Workspace Il documento è incentrato esclusivamente Cloud Identity.

Valuta i requisiti per la gestione ibrida delle identità

Il modo migliore per estendere il tuo sistema di gestione delle identità a Google Cloud dipende da più fattori:

  • I pool di identità nella tua organizzazione
  • I provider di identità utilizzati per fornire servizi di autenticazione per i tuoi identità della forza lavoro
  • Le risorse e le applicazioni che vuoi che i tuoi utenti possano su Google Cloud
  • I tuoi requisiti di continuità aziendale

Le sezioni seguenti prendono in esame ciascuno di questi fattori.

Identità

Il primo fattore da considerare durante l'integrazione di Google Cloud e e di gestione delle identità è il modo in cui gestisci e tipi di identità. La maggior parte delle organizzazioni utilizza i seguenti tipi di identità:

  1. Le identità della forza lavoro sono le identità che gestisci per i dipendenti di dell'organizzazione. Queste identità vengono utilizzate per accedere alle workstation, all'email o per utilizzare le applicazioni aziendali.
  2. Le identità esterne sono quelle che gestisci per i non dipendenti. come i contrattisti o i partner a cui occorre concedere l'accesso ai Google Cloud.
  3. Le identità ospite sono identità gestite da un soggetto diverso, come un cliente o un partner che ha bisogno di accedere alle risorse aziendali.
  4. Le identità cliente sono le identità che gestisci per gli utenti nell'ordine per interagire con il tuo sito web o le tue applicazioni rivolte ai clienti.
  5. Le identità del carico di lavoro sono le identità che gestisci per abilitare per interagire con altre applicazioni o con la piattaforma sottostante.

Spesso le identità della forza lavoro formano un unico pool di identità, in cui di un dipendente ha una singola identità e tutte le identità sono gestite nello stesso modo, utilizzando gli stessi sistemi. Tuttavia, non è detto che sia così, come conseguenza di un fusione o acquisizione, ad esempio, potreste avere più pool di forza lavoro identità, ognuna gestita in modo diverso usando sistemi diversi. Tecnicamente, questo potrebbe essere necessario integrare più origini LDAP, Active Directory o tenant di Azure AD con Google Cloud.

L'integrazione di più pool aumenta la complessità dell'integrazione con in Google Cloud. Pertanto, devi valutare:

  • Tutti i pool di identità richiedono l'accesso a Google Cloud o solo selezionare un sottoinsieme?
  • Se tutti i pool di identità hanno accesso organizzazione in Google Cloud, o a uno diverso?
  • Esistono opzioni per ridurre il numero di pool, ad esempio, la creazione di trust tra foreste tra le foreste di Active Directory?

Le identità esterne sono spesso trattate in modo simile alle identità della forza lavoro, con queste eccezioni:

  • Il loro account potrebbe essere valido solo per un periodo di tempo limitato.
  • Per impostazione predefinita, potrebbero essere concessi meno diritti.
  • Potrebbero essere gestiti da una directory LDAP separata, Active Directory o un tenant di Azure AD.

A differenza delle identità esterne, le identità guest non sono gestite da te, ma da un parti diverse. In applicazioni SaaS come Google Workspace le identità guest possono eliminare la necessità di mantenere le identità esterne clienti o partner. Raramente incontri identità guest on-premise ambienti cloud-native.

Questo documento si concentra sulle identità della forza lavoro e sulle identità esterne.

Se hai utilizzato servizi come Google Ads, alcuni dei tuoi dipendenti potrebbero avere già un Account Google non collegato al personale , nel senso che hanno due identità. In tal caso, prendi in considerazione consolidando queste identità.

Provider di identità

Il secondo fattore da considerare sono i provider di identità. Un provider di identità (IdP) è un sistema che fornisce servizi di autenticazione per i carichi di lavoro decide infine se autenticare un utente.

Oltre a fornire i servizi di autenticazione, spesso gli IdP gestiscono ciclo di vita delle identità. Non deve necessariamente essere così, dal momento che le identità possono anche essere prese in considerazione da un sistema di risorse umane separato.

I provider di identità più comuni includono:

  • Active Directory (AD DS)
  • Azure Active Directory (Azure AD)
  • Provider IDaaS come ForgeRock, Okta o Ping Identity
  • Altre directory LDAP, inclusa Active Directory Lightweight Directory Servizi (AD LDS)

Invece di utilizzare un solo sistema, potresti utilizzare più sistemi, per gestire diversi pool di utenti, gestire account esterni o fornire diversi per gli stessi pool di utenti. Esempi di utilizzo Per gestire gli stessi pool vengono utilizzati più IdP, ad esempio:

  • Active Directory federata con Azure AD
  • Active Directory federata con un provider IDaaS come ForgeRock, Okta o Ping Identità
  • Active Directory con repliche AD LDS

Per utilizzare il tuo IdP su Google Cloud, puoi seguire due approcci di base:

  • Federa il tuo provider di identità con Cloud Identity: tramite federare con Cloud Identity puoi consentire a Google di diventare un IdP aggiuntivo che gli utenti della tua forza lavoro possono e su cui può fare affidamento le applicazioni di cui è stato eseguito il deployment su Google Cloud. Invece di mantenere le identità Google per ogni utente, puoi dipendono dalla relazione di federazione per mantenere le identità automaticamente. Questa relazione aiuta anche a garantire che l'IdP rimane la fonte di verità.
  • Estendi il tuo provider di identità a Google Cloud: puoi consentire di cui è stato eseguito il deployment su Google Cloud per riutilizzare il tuo IdP, connettendoti direttamente o mantenendo una replica dell'IdP in Google Cloud.

A seconda degli altri fattori di gestione delle identità, potrebbe essere necessario combinare entrambi gli approcci per supportare gli scenari di utilizzo ibrido.

Risorse

Il terzo fattore da considerare è quali risorse Google Cloud prevedi di utilizzare per concedere l'accesso agli utenti della tua forza lavoro. Questo fattore include Google Cloud devi consentire ai team responsabili di gestire Google Cloud utilizzando Console Google Cloud, il gcloud CLI o API.

Altre risorse potrebbero includere:

Queste risorse differiscono nell'ambito di applicazione: devono, possono o non possono usare Google come provider di identità. Le sezioni seguenti esaminano questi tre casi.

Risorse che devono utilizzare Google come IdP

Le risorse che devono utilizzare Google come provider di identità includono la console Google Cloud, gcloud CLI, applicazioni protette con IAP e altre applicazioni strumenti e servizi. Per concedere agli utenti della tua forza lavoro l'accesso a queste risorse, devono eseguire il provisioning di un'identità Google per ogni utente.

Mantenere separate le identità Google è in contrasto con l'idea di e la gestione delle identità. Quindi concedere agli utenti l'accesso a una qualsiasi di queste risorse implica che devi federare il tuo IdP con Google Cloud.

Dopo aver federato il tuo IdP con Google Cloud, valuta la possibilità di utilizzare Google come IdP per ulteriori risorse, incluse le applicazioni che potrebbero servirsi di altri mezzi per autenticare gli utenti.

Risorse che potrebbero utilizzare Google come provider di identità

Le risorse che potrebbero utilizzare Google come provider di identità, ma che al momento non lo utilizzano, includono:

  • Nuove applicazioni, rivolte agli utenti della forza lavoro, su cui prevedi di eseguire il deployment in Google Cloud.
  • Applicazioni esistenti, rivolte agli utenti della forza lavoro, che prevedi di utilizzare lift and shift o spostamento e miglioramento a Google Cloud.

La possibilità di utilizzare Google come provider di identità da parte di queste applicazioni dipende dai protocolli che utilizzi per l'autenticazione e l'autorizzazione.

Protocolli Single Sign-On web

Google supporta diversi protocolli standard del settore per la gestione l'autenticazione, l'autorizzazione e il Single Sign-On. Protocolli supportati include:

  • OAuth 2.0, che si applica a client mobili, client grassi e altri client non basati sul browser diverse applicazioni.
  • OpenID Connect 1.0 (OIDC), applicabile alle applicazioni basate su browser.
  • SAML 2.0, e l'integrazione di applicazioni di terze parti.

Per le applicazioni che prevedi di sviluppare, OAuth 2.0 o OIDC deve essere la tua è la scelta preferita. Questi protocolli sono ampiamente adottati e potete trarre vantaggio di molti strumenti e librerie ben testati. Inoltre, basandosi su questi protocolli implica che puoi eventualmente utilizzare Google come IdP, conservando al contempo la flessibilità necessaria per cambiare provider di identità.

Se hai applicazioni che utilizzano SAML, OAuth 2.0 o OIDC, consentire l'uso di Google come provider di identità con una modifiche al codice.

LDAP

Uno dei protocolli più versatili e utilizzati per l'autenticazione e è il protocollo LDAP (Lightweight Directory Access Protocol). Esistono i diversi modi in cui un'applicazione può utilizzare LDAP per l'autenticazione e l'autorizzazione. Ecco i due scenari più comuni:

  1. Utilizzo di LDAP per l'autenticazione e l'esecuzione di query sulle informazioni degli utenti: in in questo scenario, un'applicazione non usa il Single Sign-On. Invece, mostra all'utente un modulo di accesso che richiede nome utente e password utilizza le credenziali fornite per tentare un'operazione bind LDAP. Se l'operazione riesce, le credenziali sono considerate valide. E oltre informazioni sull'utente, come nome e appartenenza al gruppo, potrebbero essere viene interrogato dalla directory e utilizzato per autorizzare l'accesso.

  2. Utilizzo di SAML per l'autenticazione e LDAP per eseguire query sulle informazioni utente: In questo scenario, l'applicazione autentica l'utente utilizzando un singolo protocollo Sign-On: le applicazioni spesso usano SAML a questo scopo. Dopo il l'utente è stato autenticato, l'applicazione utilizza il server LDAP per eseguire query informazioni aggiuntive sull'utente, come nome e iscrizione ai gruppi.

La differenza fondamentale tra i due scenari è che il primo scenario richiede che sia l'applicazione sia il server LDAP abbiano accesso ai dati password per verificare le credenziali. Nel secondo scenario, e il server non richiede l'accesso alla password dell'utente; l'applicazione può eseguire le proprie query LDAP utilizzando un utente del servizio dedicato.

Con LDAP sicuro, puoi accedere alle informazioni su utenti e gruppi in Cloud Identity utilizzando il Protocollo LDAP. Se Google è il tuo IdP principale, Secure LDAP ti consente di supportare in entrambi gli scenari. Tuttavia, se integri Cloud Identity con un e un IdP esterno, Cloud Identity non gestisce una copia delle password degli utenti. Di conseguenza, solo il secondo scenario può essere abilitato con Secure LDAP.

Kerberos e NTLM

Se prevedi di eseguire la migrazione dei carichi di lavoro basati su Windows su Google Cloud, queste applicazioni potrebbero affidarsi IWA (Integrated Windows Authentication) anziché utilizzare protocolli standard. IWA è una scelta comune per le applicazioni basate su ASP.NET di applicazioni in esecuzione su Microsoft IIS. IWA è molto popolare perché consente un'esperienza Single Sign-On semplificata per gli utenti che hanno eseguito l'accesso ai propri sistemi Windows utilizzando le credenziali del dominio.

IWA si basa su NTLM o Kerberos. Richiede la workstation dell'utente e il server su cui è in esecuzione l'applicazione far parte dello stesso dominio Active Directory o di domini attendibili.

Una conseguenza dell'utilizzo di NTLM e Kerberos è che un'applicazione che utilizza IWA non possono utilizzare Google come IdP. Tuttavia, potresti comunque riuscire a eseguire il refactoring per l'uso di OIDC. OIDC non richiede la workstation dell'utente o server da unire a un dominio. Il refactoring potrebbe semplificare l'implementazione e ti aiuteranno perseguire opzioni di deployment alternative.

Considerando l'esperienza Single Sign-On senza interruzioni fornita da IWA, utilizzando OIDC anziché IWA potrebbe sembrare un passo indietro in termini di esperienza utente. Tuttavia, se ti assicuri che gli utenti possano puoi accedere senza problemi ad AD FS o Azure AD:

  • Se federate Google Cloud con Active Directory e AD FS, si applicano tutti i metodi di autenticazione configurati in AD FS. Se configuri AD FS per consentire IWA, gli utenti che hanno eseguito l'accesso alla propria workstation Windows le credenziali del dominio possono essere autenticate senza problemi in qualsiasi applicazione che utilizza Google come IdP.
  • Se federate Google Cloud con Azure AD, puoi abilitare il servizio SSO senza interruzioni di Azure AD per ottenere lo stesso effetto.

Il seguente diagramma mostra un esempio semplificato di come puoi utilizzare Cloud Identity, AD FS e IWA per implementare facilmente il Single Sign-On di un'applicazione web:

Come utilizzare Cloud Identity, AD FS e IWA per implementare facilmente il Single Sign-On per un'applicazione web

  1. Il browser richiede una pagina protetta utilizzando un browser web.
  2. L'applicazione web avvia un accesso utilizzando OIDC (flusso di autenticazione OIDC). Questo flusso reindirizza il browser all'endpoint di accesso di Google.
  3. L'endpoint di accesso con Google restituisce la pagina di accesso di Google all'utente, richiesta dell'indirizzo email.
  4. L'utente inserisce il proprio indirizzo email.
  5. In base all'indirizzo email, l'endpoint di Accedi con Google identifica l'account Cloud Identity e riconosce che è configurato per utilizzare SSO. L'endpoint di accesso avvia quindi un accesso SAML con AD FS.
  6. AD FS, configurato per utilizzare IWA, richiede al browser di presentare un Kerberos ticket, che attiva la richiesta del browser dei file Windows sottostanti. per ottenere un ticket appropriato.
  7. A meno che non sia stato memorizzato nella cache un ticket idoneo, Windows contatta il il centro di distribuzione delle chiavi (KDC) di Active Directory e richiede un ticket di servizio da emettere in base al ticket Grant (TGT) che è stata ottenuta quando l'utente ha eseguito l'accesso a Windows.
  8. Il browser presenta il ticket appena ottenuto ad AD FS.
  9. AD FS convalida il ticket controllandone la firma crittografica. estrae l'identità utente dal ticket ed emette un token SAML Endpoint di accesso di Google.
  10. Utilizzando le informazioni di autenticazione del token SAML, Google L'endpoint di accesso completa l'accesso OIDC e emette i token OpenID Connect all'applicazione web.
  11. Quando l'utente viene autenticato, la pagina protetta può essere restituita a per l'utente.

Autenticazione a chiave pubblica SSH

Quando prevedi di eseguire macchine virtuali (VM) Linux su Google Cloud, probabilmente avranno bisogno dell'accesso SSH a queste macchine. Il metodo di autenticazione più comune per SSH è l'autenticazione a chiave pubblica.

A differenza dei protocolli Single Sign-On discussi in precedenza, il protocollo l'autenticazione non si basa su un IdP centralizzato prendono le loro decisioni. Le decisioni di autenticazione sono invece decentralizzate, in quanto ogni macchina Gestisce l'autenticazione in base a un set locale di chiavi pubbliche autorizzate.

Puoi colmare il divario tra l'autenticazione a chiave pubblica SSH decentralizzata e gestione centralizzata delle identità mediante OS Login. OS Login collega il ciclo di vita delle chiavi SSH a quello degli account utente tramite:

  • Pubblicazione di una chiave pubblica SSH quando un utente viene creato o sta tentando di utilizzare SSH per la prima volta.
  • Provisioning della chiave pubblica dell'utente sulle macchine a cui un utente è autorizzato ad accedere.
  • Eseguire il deprovisioning della chiave pubblica dell'utente quando l'accesso all'account viene revocato. disattivato o eliminato.

Utilizzare OS Login in modo efficace rende Cloud Identity l'IdP per alle tue istanze Linux.

Risorse che non possono utilizzare Google come IdP

Alcune risorse non possono usare direttamente Google come IdP. ma puoi comunque queste risorse su Google Cloud combinando due approcci:

Se una risorsa si basa su protocolli non supportati dall'IdP Google, non può usare Google come IdP. Tali protocolli includono:

  • LDAP per l'autenticazione: anche se puoi utilizzare LDAP sicuro per facilitare l'autenticazione interrogare le informazioni utente da Cloud Identity tramite LDAP, Cloud Identity non supporta l'uso di LDAP per l'autenticazione quando federato con un IdP esterno.

    Per consentire alle applicazioni di utilizzare LDAP per l'autenticazione, puoi: esporre o replicare una directory LDAP on-premise oppure puoi estendere la tua Active Directory a Google Cloud.

  • WS-Trust, WS-Federation: in particolare se utilizzi AD FS, potresti comunque si affida a WS-Trust o WS-Federation per gestire l'autenticazione basata su token. A meno che tu non possa modificare le applicazioni interessate in modo che utilizzino SAML o OpenID Connect. è meglio esporre i tuoi annunci AD FS on-premise a Google Cloud e fare in modo che le applicazioni utilizzino direttamente AD FS.

  • OpenID Connect con dichiarazioni specifiche per AD FS: AD FS e supporto Google OpenID Connect. Se utilizzavi AD FS come provider OpenID Connect, è possibile fare affidamento su determinate affermazioni specifiche di AD FS che non sono supportate da Google. In tal caso, prendi in considerazione esponendo gli annunci AD FS on-premise a Google Cloud e le applicazioni interessate usano direttamente AD FS.

  • Kerberos, NTLM. Se alcune delle tue applicazioni utilizzano Kerberos o NTLM per l'autenticazione, potresti riuscire a modificarle OpenID Connect o SAML. Se questo non è possibile, puoi eseguire il deployment di queste applicazioni in Windows Server e esporre o replicare Active Directory on-premise a Google Cloud.

  • Macchine virtuali Windows: se esegui carichi di lavoro Windows su Google Cloud, devi poter accedere a queste VM tramite Desktop Protocol (RDP), tramite un gateway Remote Desktop o tramite e i relativi vantaggi. Se un utente ha accesso in scrittura al progetto Google Cloud in cui è stata creata, Google Cloud consente all'utente creare un utente e una password, che crea un account nel Security Account Manager (SAM) locale della VM per configurare un database. Fondamentalmente, l'account SAM Windows risultante non è connesso all'Account Google dell'utente e non sono soggetti allo stesso ciclo di vita dell'account. Se sospendi o elimini l'Account Google dell'utente, l'account SAM Windows non è interessato e potrebbe continuare a fornire l'accesso alla VM.

    Se hai un numero moderato di VM Windows e utenti che devono poter accedere a queste macchine e consentire agli utenti di generare Gli account utente e le password di Windows potrebbero essere un approccio attuabile. Ma quando gestire parchi di server Windows più grandi, può essere meglio estendere una Active Directory on-premise a Google Cloud e nell'unione del dominio ai rispettivi server. Anche i server di join dominio sono se utilizzi l'autenticazione a livello di rete.

Disponibilità

L'ultimo fattore da considerare è la disponibilità. La possibilità di autenticare gli utenti è probabilmente critico per molti carichi di lavoro e un'interruzione del servizio conseguenze di vasta portata. L'approccio giusto per garantire una disponibilità adeguata dipende da come intendi utilizzare Google Cloud e da come si integra una strategia ibrida.

Carichi di lavoro distribuiti

Per sfruttare al meglio le capacità uniche di ciascun ambiente di elaborazione puoi utilizzare un approccio multi-cloud ibrido distribuire i carichi di lavoro tra questi ambienti. Questi ambienti potrebbero avere dipendenze l'uno dall'altro che sono fondamentali per la disponibilità dei carichi di lavoro. Le dipendenze potrebbero includere VPN tunnel o interconnect, che comunicano tra loro applicazioni o sistemi che accedono ai dati ambienti di computing.

Quando federati o estendi l'IdP esterno a Google Cloud, assicurati la disponibilità dell'IdP esterno e degli altri sistemi richiesti l'autenticazione soddisfa o supera la disponibilità di altre risorse critiche delle dipendenze. Questo requisito significa che potrebbe essere necessario eseguire eseguire il deployment dell'IdP esterno e delle sue dipendenze e garantire che la rete ridondante e la connettività privata.

Carichi di lavoro ridondanti

Se usi Google Cloud per assicurarti continuità aziendale, i tuoi carichi di lavoro su Google Cloud eseguiranno il mirroring di alcuni che hai nel tuo ambiente informatico. Lo scopo di questa configurazione è abilitare un ambiente di computing per assumere il ruolo dell'altro, se che si verifica un errore. È quindi necessario considerare ogni dipendenza tra questi ambienti cloud-native.

Facendo affidamento su Google Cloud su un IdP esterno in esecuzione on-premise, per creare una dipendenza. Questa dipendenza potrebbe minare l'intento di avere Google Cloud sia una copia indipendente del tuo ambiente di computing.

Prova a replicare l'IdP in Google Cloud in modo che tutti i carichi di lavoro su Google Cloud non sono interessate da un'interruzione del computing on-premise dell'ambiente o della connettività tra Google Cloud e la tua rete on-premise in ogni rete.

Passaggi successivi