Autenticare 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 descrive come estendere la tua soluzione di gestione delle identità a Google Cloudper consentire ai tuoi dipendenti di autenticarsi e utilizzare i servizi in un ambiente di computing ibrido.

La serie è composta dalle seguenti parti:

Introduzione

La gestione degli account utente e il controllo dell'accesso dei dipendenti alle applicazioni e alle risorse di calcolo sono una responsabilità fondamentale dei reparti IT aziendali. 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à. In genere, le aziende si affidano a Microsoft Active Directory Domain Services (AD DS) per questo scopo.

Quando estendi un panorama IT a Google Cloud nell'ambito di una strategia ibrida, vuoi mantenere un unico punto in cui vengono gestite le identità. Un sistema di gestione delle identità unificato riduce lo sforzo amministrativo nella gestione degli account e controllo dell'accesso. Questo sistema contribuisce anche a garantire che utenti e applicazioni possano autenticarsi in modo sicuro in un ambiente ibrido.

Questo documento esamina 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 la maggior parte della discussione si applichi anche a Google Workspace, il documento si concentra esclusivamente su Cloud Identity.

Valutare 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 le identità della tua forza lavoro
  • Le risorse e le applicazioni a cui vuoi che i tuoi utenti possano accedere su Google Cloud
  • I requisiti di continuità aziendale

Le sezioni seguenti esaminano ciascuno di questi fattori.

Identità

Il primo fattore da considerare quando si integra Google Cloud e il tuo 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 una parte diversa, ad esempio un cliente o un partner che ha bisogno di accedere alle risorse aziendali.
  4. Le identità cliente sono le identità che gestisci per consentire agli utenti di interagire con il tuo sito web o con le applicazioni rivolte al cliente.
  5. Le identità dei workload sono le identità che gestisci per consentire alle applicazioni di interagire con altre applicazioni o con la piattaforma sottostante.

Spesso, le identità della forza lavoro formano un unico pool di identità, in cui ogni dipendente ha una sola identità e tutte le identità vengono gestite allo stesso modo, utilizzando gli stessi sistemi. Tuttavia, non è sempre così: a seguito di una fusione o acquisizione, ad esempio, potresti avere più pool di identità della forza lavoro, ognuno gestito in modo diverso utilizzando sistemi diversi. Tecnicamente, ciò 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 Google Cloud. Pertanto, devi valutare:

  • Tutti i pool di identità devono accedere a Google Cloudo solo a un sottoinsieme selezionato?
  • Tutti i pool di identità devono avere accesso alla stessa organizzazione in Google Cloud, o ognuno a una diversa?
  • Esistono opzioni per ridurre il numero di pool, ad esempio creando trust tra foreste tra le foreste Active Directory?

Le identità esterne vengono spesso trattate in modo simile alle identità della forza lavoro, con le seguenti 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, da una foresta Active Directory o da un tenant Azure AD.

A differenza delle identità esterne, le identità ospite non sono gestite da te, ma da una terza parte. Nelle applicazioni SaaS come Google Workspace, le identità guest possono eliminare la necessità di gestire identità esterne per clienti o partner. Raramente si incontrano identità ospite in 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 già avere un Account Google non collegato alla loro identità di forza lavoro, il che significa che hanno due identità. In questo caso, valuta la possibilità di consolidare queste identità.

Provider di identità

Il secondo fattore da esaminare sono i provider di identità. Un provider di identità (IdP) è un sistema che fornisce servizi di autenticazione per i tuoi carichi di lavoro e decide in ultima analisi se autenticare un utente.

Oltre a fornire servizi di autenticazione, i provider di identità spesso gestiscono il ciclo di vita delle identità. Tuttavia, non è sempre così, perché le identità possono essere sottoposte a provisioning anche da un sistema di risorse umane separato.

I provider di identità comuni includono:

  • Active Directory (AD DS)
  • Azure Active Directory (Azure AD)
  • Fornitori di IDaaS come ForgeRock, Okta o Ping Identity
  • Altre directory LDAP, tra cui Active Directory Lightweight Directory Services (AD LDS)

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

  • Active Directory federato con Azure AD
  • Active Directory federato con un provider IDaaS come ForgeRock, Okta o Ping Identity
  • Active Directory con repliche AD LDS

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

  • Federare il tuo provider di identità con Cloud Identity: se esegui la federazione con Cloud Identity, consenti a Google di diventare un IdP aggiuntivo che i tuoi utenti della forza lavoro possono utilizzare e su cui possono fare affidamento le applicazioni di cui è stato eseguito il deployment su Google Cloud . Anziché gestire le identità Google per ogni utente, puoi affidarti alla relazione di federazione per gestire le identità automaticamente. Questa relazione contribuisce anche a garantire che il tuo IdP rimanga la fonte di riferimento.
  • Estendi il tuo provider di identità a Google Cloud: puoi consentire alle applicazioni implementate su Google Cloud di riutilizzare il tuo IdP, connettendosi direttamente o mantenendo una replica dell'IdP su Google Cloud.

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

Risorse

Il terzo fattore da considerare è a quali Google Cloud risorse prevedi di concedere l'accesso agli utenti della tua forza lavoro. Questo fattore include Google Cloud stesso: devi consentire ai team responsabili di gestire Google Cloud utilizzando la consoleGoogle Cloud , l'interfaccia a riga di comando gcloud o le API.

Altre risorse potrebbero includere:

Queste risorse differiscono per il fatto che devono, potrebbero o non possono utilizzare Google come Identity Provider. 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, devi eseguire il provisioning di un'identità Google per ogni utente.

Il mantenimento di identità Google separate è contrario all'idea di gestione unificata delle identità. Pertanto, la concessione dell'accesso degli utenti a una qualsiasi di queste risorse implica che devi federare il tuo IdP con Google Cloud.

Dopo aver federato l'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 IdP

Le risorse che potrebbero utilizzare Google come IdP, ma attualmente non lo fanno, 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 spostare e migliorare in Google Cloud.

La possibilità di utilizzare Google come IdP dipende dai protocolli che utilizzi per l'autenticazione e l'autorizzazione.

Protocolli Single Sign-On per il web

Google supporta diversi protocolli standard di settore per la gestione dell'autenticazione, dell'autorizzazione e del Single Sign-On. I protocolli supportati includono:

  • OAuth 2.0, che si applica a client mobile, fat client 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 devono essere la tua scelta preferita. Questi protocolli sono ampiamente adottati e puoi usufruire di molte librerie e strumenti ben testati. Inoltre, fare affidamento su questi protocolli implica che puoi utilizzare Google come IdP, mantenendo la flessibilità di cambiare i provider di identità in base alle esigenze.

Se hai applicazioni che utilizzano SAML, OAuth 2.0 o OIDC, il passaggio all'utilizzo di Google come provider di identità dovrebbe essere possibile con poche o nessuna modifica del codice.

LDAP

Uno dei protocolli più versatili e affidabili per l'autenticazione e l'autorizzazione è LDAP (Lightweight Directory Access Protocol). Esistono 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'interrogazione delle informazioni utente: in questo scenario, un'applicazione non utilizza Single Sign-On. Mostra invece all'utente un modulo di accesso che richiede nome utente e password e poi utilizza le credenziali fornite per tentare un'operazione LDAP bind. Se il tentativo va a buon fine, le credenziali vengono considerate valide. Ulteriori informazioni sull'utente, come nome e appartenenza al gruppo, potrebbero essere interrogate dalla directory e utilizzate per autorizzare l'accesso.

  2. Utilizzo di SAML per l'autenticazione e di LDAP per l'interrogazione delle informazioni utente: In questo scenario, l'applicazione autentica l'utente utilizzando un protocollo Single Sign-On. Le applicazioni spesso utilizzano SAML a questo scopo. Dopo l'autenticazione dell'utente, l'applicazione utilizza il server LDAP per eseguire query su informazioni aggiuntive sull'utente, come nome e appartenenza a gruppi.

La differenza fondamentale tra i due scenari è che il primo richiede che sia l'applicazione sia il server LDAP abbiano accesso alla password dell'utente 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 query LDAP utilizzando un utente di servizio dedicato.

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

Kerberos e NTLM

Se prevedi di eseguire la migrazione dei carichi di lavoro basati su Windows a Google Cloud, alcune di queste applicazioni potrebbero basarsi sull'autenticazione integrata di Windows (IWA) anziché utilizzare protocolli standard. L'autenticazione integrata di Windows è una scelta comune per le applicazioni basate su ASP.NET in esecuzione su Microsoft IIS. L'autenticazione integrata di Windows è molto diffusa 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.

L'autenticazione integrata di Windows si basa su NTLM o Kerberos. Richiede che la workstation dell'utente e il server su cui è in esecuzione l'applicazione siano uniti allo stesso dominio Active Directory o a 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 essere in grado di eseguire il refactoring dell'applicazione per utilizzare OIDC. OIDC non richiede che la workstation dell'utente o il server siano uniti al dominio. Pertanto, il refactoring potrebbe semplificare il deployment e aiutarti a perseguire opzioni di deployment alternative.

Considerando l'esperienza di Single Sign-On fluida fornita da IWA, l'utilizzo di OIDC invece di IWA potrebbe sembrare un passo indietro in termini di esperienza utente. Tuttavia, non è necessario se ti assicuri che gli utenti possano accedere senza problemi ad AD FS o Azure AD:

  • Se federi Google Cloud con Active Directory e AD FS, vengono applicati tutti i metodi di autenticazione configurati in AD FS. Se configuri ADFS per consentire l'IWA, gli utenti che hanno eseguito l'accesso alla propria workstation Windows utilizzando le credenziali di dominio possono essere autenticati senza problemi a qualsiasi applicazione che utilizza Google come IdP.
  • Se federi Google Cloud con Azure AD, puoi attivare l'accesso SSO facile di Azure AD per ottenere lo stesso risultato.

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

Come utilizzare Cloud Identity, AD FS e IWA per implementare il Single Sign-On automatico 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, chiedendo 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 utilizzare l'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, il che attiva la richiesta del browser al sistema operativo Windows sottostante di ottenere un ticket adatto.
  7. A meno che non sia stata memorizzata nella cache una richiesta adatta, Windows contatta il centro di distribuzione delle chiavi (KDC) di Active Directory e richiede l'emissione di una richiesta di servizio adatta in base alla richiesta di concessione di ticket (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 controllando la sua firma crittografica, estrae l'identità dell'utente dal ticket ed emette un token SAML per l'endpoint di accesso Google.
  10. Utilizzando le informazioni di autenticazione del token SAML, l'endpoint di accesso di Google completa l'accesso OIDC ed emette token OpenID Connect per l'applicazione web.
  11. Una volta autenticato l'utente, la pagina protetta può essere restituita all'utente.

Autenticazione a chiave pubblica SSH

Quando prevedi di eseguire macchine virtuali (VM) Linux su Google Cloud, probabilmente hai 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, l'autenticazione con chiave pubblica SSH non si basa su un IdP centralizzato per prendere decisioni di autenticazione. Al contrario, le decisioni di autenticazione sono decentralizzate: ogni macchina gestisce l'autenticazione in base a un insieme locale di chiavi pubbliche autorizzate.

Puoi colmare il divario tra l'autenticazione decentralizzata con chiave pubblica SSH e la gestione centralizzata delle identità utilizzando OS Login. OS Login lega il ciclo di vita delle chiavi SSH al ciclo di vita degli account utente:

  • 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 l'utente ha diritto di accedere.
  • Decommissioning della chiave pubblica dell'utente quando l'accesso all'account viene revocato, disattivato o eliminato.

L'utilizzo di OS Login 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 ospitare queste risorse su Google Cloud combinando due approcci:

Se una risorsa si basa su protocolli non supportati dal provider di identità Google, non può utilizzare Google come provider di identità. Questi protocolli includono:

  • LDAP per l'autenticazione: anche se puoi utilizzare Secure LDAP per facilitare l'interrogazione delle informazioni utente da Cloud Identity tramite LDAP, Cloud Identity non supporta l'utilizzo 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 Active Directory a Google Cloud.

  • WS-Trust, WS-Federation: soprattutto se utilizzi AD FS, potresti ancora affidarti 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 il tuo AD FS on-premise a Google Cloud e fare in modo che le applicazioni utilizzino AD FS direttamente.

  • OpenID Connect con attestazioni specifiche di AD FS: AD FS e Google supportano OpenID Connect. Se hai utilizzato AD FS come provider OpenID Connect, potresti fare affidamento su determinati attestati specifici di AD FS che Google non supporta. In questo caso, valuta la possibilità di esporre il tuo AD FS on-premise a Google Cloud e fare in modo che le applicazioni interessate utilizzino direttamente AD FS.

  • Kerberos, NTLM: se alcune delle tue applicazioni utilizzano Kerberos o NTLM per l'autenticazione, potresti essere in grado di modificarle per utilizzare OpenID Connect o SAML. Se non è possibile, puoi eseguire il deployment di queste applicazioni su server Windows aggiunti al dominio e esporre o replicare Active Directory on-premise in Google Cloud.

  • Macchine virtuali Windows: se esegui carichi di lavoro Windows su Google Cloud, devi essere in grado di accedere a queste VM tramite Remote Desktop Protocol (RDP), tramite un gateway Remote Desktop o con altri mezzi. 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, il che crea un account nel database SAM (Security Account Manager) locale della VM. È fondamentale sottolineare che l'account SAM di Windows risultante non è collegato all'Account Google dell'utente e non è soggetto allo stesso ciclo di vita dell'account. Se sospendi o elimini l'Account Google dell'utente, l'account SAM di Windows non viene interessato e potrebbe continuare a fornire l'accesso alla VM.

    Se hai un numero moderato di VM Windows e utenti che devono essere in grado di accedere a questi computer, consentire agli utenti di generare account utente e password Windows potrebbe essere un approccio valido. Tuttavia, quando gestisci flotte più grandi di server Windows, può essere meglio estendere un Active Directory on-premise a Google Cloud e unire i rispettivi server al dominio. L'aggiunta di server al dominio è un requisito anche se utilizzi l'autenticazione a livello di rete.

Disponibilità

L'ultimo fattore da esaminare è la disponibilità. La possibilità di autenticare gli utenti è probabilmente fondamentale per molti dei tuoi carichi di lavoro e un'interruzione dell'IdP 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 ogni ambiente di computing, puoi utilizzare un approccio multi-cloud ibrido per distribuire i carichi di lavoro in questi ambienti. Questi ambienti potrebbero avere dipendenze reciproche fondamentali per la disponibilità dei tuoi carichi di lavoro. Le dipendenze potrebbero includere tunnel VPN o interconnessioni, applicazioni che comunicano tra loro o sistemi che accedono ai dati in ambienti di computing.

Quando federi o estendi il tuo IdP esterno a Google Cloud, assicurati che la disponibilità del tuo IdP esterno e di altri sistemi necessari per l'autenticazione soddisfi o superi la disponibilità di altre dipendenze critiche. Questo requisito significa che potresti dover eseguire il deployment ridondante dell'IdP esterno e delle relative dipendenze e garantire la connettività di rete ridondante.

Workload ridondanti

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

Se Google Cloud si basa su un IdP esterno in esecuzione on-premise, crei una dipendenza. Questa dipendenza potrebbe compromettere l'intento di avere Google Cloud come copia indipendente del tuo ambiente di computing.

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

Passaggi successivi