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 è composta 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. Per garantire coerenza ed efficienza amministrativa, la maggior parte delle aziende considera la gestione delle identità una funzione centrale e utilizza un sistema unificato per gestire le identità. 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 di gestione delle identità unificato riduce al minimo lo sforzo amministrativo necessario per gestire gli account e il controllo dell'accesso. Questo sistema contribuisce inoltre ad assicurare che gli utenti e le applicazioni possano autenticarsi in modo sicuro in un ambiente ibrido.

Questo documento illustra i modi per integrare Google Cloud con il tuo sistema di gestione delle identità. Il documento ti aiuta a scegliere l'approccio più adatto 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 sistema di gestione delle identità a Google Cloud dipende da diversi 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 a cui vuoi che i tuoi utenti possano accedere su Google Cloud
  • Requisiti di continuità aziendale

Le sezioni seguenti prendono in esame ciascuno di questi fattori.

Identità

Il primo fattore da considerare quando si integra Google Cloud e il sistema di gestione delle identità è il modo in cui gestisci e distingui i 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 della tua organizzazione. Queste identità vengono utilizzate per accedere alle workstation, all'email o per utilizzare le applicazioni aziendali.
  2. Le identità esterne sono le identità che gestisci per i non dipendenti, come consulenti o partner, a cui deve essere concesso l'accesso alle risorse aziendali.
  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 ogni impiegato ha un'unica identità e tutte le identità vengono 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 significa che potresti dover integrare più origini LDAP, foreste Active Directory o tenant 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à devono accedere a Google Cloud o solo un insieme selezionato?
  • 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 creando relazioni di attendibilità tra 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, una foresta Active Directory o un tenant Azure AD separati.

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 si verificano identità ospite negli ambienti on-premise.

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à potrebbero anche essere sottoposte a provisioning 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, tra cui Active Directory Lightweight Directory Services (AD LDS)

Invece di utilizzare un solo sistema, potresti utilizzarne diversi per gestire pool di utenti diversi, gestire account esterni o fornire servizi di autenticazione diversi per gli stessi pool di utenti. Ecco alcuni esempi in cui vengono utilizzati più provider di identità per gestire gli stessi pool:

  • 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 contribuisce inoltre a garantire che la tua IdP rimanga la fonte attendibile.
  • 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 è a quali risorse Google Cloud prevedi di concedere l'accesso agli utenti della 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 in base al fatto che devono, possono o non possono utilizzare 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 IdP includono la console Google Cloud, gcloud CLI, le applicazioni protette con IAP e altri strumenti e servizi Google. 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à. Pertanto, se concedi agli utenti l'accesso a una di queste risorse, devi federare il tuo provider di identità con Google Cloud.

Dopo aver federato il tuo IdP con Google Cloud, valuta la possibilità di utilizzare Google come IdP per altre risorse, incluse le applicazioni che potrebbero utilizzare 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 destinate agli utenti della forza lavoro che prevedi di implementare su Google Cloud.
  • Applicazioni esistenti, destinate agli utenti della forza lavoro, che prevedi di eseguire il lift and shift o di trasferire e migliorare in 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 di settore per la gestione dell'autenticazione, dell'autorizzazione e dell'accesso singolo. Protocolli supportati include:

  • OAuth 2.0, che si applica a client mobile, client fat e altre applicazioni non browser.
  • OpenID Connect 1.0 (OIDC), che si applica alle applicazioni basate su browser.
  • SAML 2.0, che si applica all'integrazione di applicazioni di terze parti.

Per le applicazioni che prevedi di sviluppare, OAuth 2.0 o OIDC dovrebbe essere la tua scelta migliore. Questi protocolli sono ampiamente adottati e puoi usufruire di molte librerie e strumenti 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, dovrebbe essere possibile passare all'utilizzo di Google come provider di identità con poche o nessuna modifica al codice.

LDAP

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

  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. Al contrario, mostra all'utente un modulo di accesso che richiede nome utente e password, quindi utilizza le credenziali fornite per tentare un'operazione bind LDAP. Se il tentativo va a buon fine, le credenziali vengono 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 che l'utente è stato autenticato, l'applicazione utilizza il server LDAP per eseguire query su informazioni aggiuntive sull'utente, come nome e appartenenza 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, l'applicazione e il server non richiedono l'accesso alla password dell'utente. L'applicazione può eseguire le sue query LDAP utilizzando un utente di servizio dedicato.

Con Secure LDAP, puoi accedere alle informazioni utente e di gruppo in Cloud Identity utilizzando il protocollo LDAP. Se Google è il tuo provider di identità principale, LDAP sicuro ti consente di supportare 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 a Google Cloud, alcune di queste applicazioni potrebbero fare affidamento sull'autenticazione Windows integrata (IWA) anziché utilizzare protocolli standard. IWA è una scelta comune per le applicazioni basate su ASP.NET di applicazioni in esecuzione su Microsoft IIS. L'autenticazione WIA è molto utilizzata perché consente un'esperienza Single Sign-On senza interruzioni per gli utenti che hanno eseguito l'accesso alla propria workstation Windows utilizzando le credenziali di 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 può utilizzare Google come IdP. Tuttavia, potresti comunque riuscire a eseguire il refactoring per l'uso di OIDC. OIDC non richiede che la workstation o il server dell'utente siano uniti al dominio. Il refactoring potrebbe semplificare l'implementazione e ti aiuteranno perseguire opzioni di deployment alternative.

Considerando l'esperienza di Single Sign-On senza interruzioni fornita dall'IWA, l'utilizzo di OIDC invece di 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 federi 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 l'autenticazione IWA, gli utenti che hanno eseguito l'accesso alla propria stazione di lavoro Windows utilizzando le credenziali di dominio possono essere autenticati 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 l'accesso singolo senza problemi per un'applicazione web:

Come utilizzare Cloud Identity, AD FS e IWA per implementare il Single Sign-On senza interruzioni 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 di Google restituisce all'utente la pagina di accesso di Google, in cui viene richiesto l'indirizzo email.
  4. L'utente inserisce il proprio indirizzo email.
  5. In base all'indirizzo email, l'endpoint di accesso Google identifica l'account Cloud Identity e riconosce che è configurato per l'utilizzo del 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 ticket Kerberos, che attiva il browser per richiedere al sistema operativo Windows sottostante di ottenere un ticket adatto.
  7. A meno che non sia stato memorizzato nella cache un ticket adatto, Windows contatta il centro di distribuzione delle chiavi (KDC) di Active Directory e richiede l'emissione di un ticket di servizio adatto in base al ticket di assegnazione dei ticket (TGT) ottenuto 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, l'endpoint di accesso di Google completa l'accesso OIDC e emette token OpenID Connect all'applicazione web.
  11. Una volta autenticato, l'utente può visualizzare nuovamente la pagina protetta.

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 viene creato un utente o quando tenta 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.

L'utilizzo di Accesso sistema operativo rende Cloud Identity l'IdP per le tue istanze Linux.

Risorse che non possono utilizzare Google come IdP

Alcune risorse non possono utilizzare direttamente Google come IdP. Tuttavia, puoi comunque supportare 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 o estendere Active Directory a Google Cloud.

  • WS-Trust, WS-Federation: soprattutto se utilizzi AD FS, potresti comunque fare affidamento su 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 attestazioni specifiche di AD FS: AD FS e Google supportano 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 essere in grado di modificarle in modo da utilizzare OpenID Connect o SAML. Se non è possibile, puoi eseguire il deployment di queste applicazioni su server Windows uniti al dominio e esporre o replicare Active Directory on-premise su 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 dispone dell'accesso in scrittura al progetto Google Cloud in cui è stata creata la VM, Google Cloud consente all'utente di creare un utente e una password, che generano un account nel database SAM (Security Account Manager) locale della VM. 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 di Windows rimane invariato 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 capacità di autenticare gli utenti è probabilmente fondamentale per molti dei tuoi carichi di lavoro e un'interruzione del servizio di un provider di identità può avere conseguenze di vasta portata. L'approccio giusto per garantire una disponibilità adeguata dipende da come intendi utilizzare Google Cloud e da come si inserisce nella tua strategia ibrida.

Carichi di lavoro distribuiti

Per sfruttare le funzionalità uniche offerte da ciascun ambiente di calcolo, puoi utilizzare un approccio multi-cloud ibrido per distribuire i carichi di lavoro in questi ambienti. Questi ambienti potrebbero avere dipendenze tra loro che sono fondamentali per la disponibilità dei tuoi 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 potresti dover eseguire il deployment ridondante dell'IDP esterno e delle relative dipendenze e garantire la connettività di rete ridondante.

Carichi di lavoro ridondanti

Se utilizzi Google Cloud per garantire la continuità aziendale, i tuoi carichi di lavoro su Google Cloud rispecchieranno alcuni dei carichi di lavoro presenti nel tuo ambiente di calcolo. Lo scopo di questa configurazione è consentire a un ambiente di calcolo di assumere il ruolo dell'altro ambiente in caso di errore. Devi quindi esaminare ogni dipendenza tra questi ambienti.

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

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