Autenticare gli utenti della forza lavoro in un ambiente ibrido

Last reviewed 2024-06-26 UTC

Questo documento è la prima parte di una serie di articoli che illustra come estendere la tua soluzione di gestione delle identità a Google Cloud per consentire al personale di autenticarsi e utilizzare i servizi in un ambiente di cloud computing ibrido.

La serie è composta dai seguenti componenti:

Introduzione

La gestione degli account utente e il controllo dell'accesso dei dipendenti alle applicazioni e alle risorse di calcolo è una responsabilità chiave 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 Servizi di dominio Microsoft Active Directory (AD DS) per questo scopo.

Quando estendi un panorama IT a Google Cloud nell'ambito di una strategia ibrida, devi mantenere un unico punto in cui vengono gestite le identità. Un sistema di gestione delle identità unificato riduce al minimo lo sforzo amministrativo necessario per gestire gli account e 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 la maggior parte della discussione riguardi anche 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à della tua organizzazione
  • I provider di identità utilizzati per fornire servizi di autenticazione per le tue identità del personale
  • 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 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'altra parte, ad esempio un cliente o un partner che deve accedere alle risorse aziendali.
  4. Le identità cliente sono le identità che gestisci per gli utenti in modo che possano 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 impiegato ha un'unica identità e tutte le identità vengono gestite nello stesso modo, utilizzando gli stessi sistemi. Tuttavia, non è sempre così: ad esempio, a seguito di una fusione o un'acquisizione, potresti avere più pool di identità del personale, ciascuno gestito in modo diverso utilizzando 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 Google Cloud. Pertanto, devi valutare:

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

Le identità esterne vengono spesso trattate in modo simile alle identità del personale, con queste eccezioni:

  • Il suo 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à degli ospiti non sono gestite da te, ma da un'altra parte. Nelle applicazioni SaaS come Google Workspace, le identità ospite possono eliminare la necessità di gestire identità esterne per clienti o partner. Raramente si verificano identità ospite negli ambienti on-premise.

Questo documento si concentra sulle identità del personale 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à lavorativa, 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 tuoi provider di identità. Un provider di identità (IdP) è un sistema che fornisce servizi di autenticazione per i tuoi carichi di lavoro e decide infine se autenticare un utente.

Oltre a fornire servizi di autenticazione, le IdP spesso gestiscono il ciclo di vita delle identità. Tuttavia, non è sempre così, perché il provisioning delle identità può essere eseguito anche da un sistema delle 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 utilizzare più sistemi 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 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:

  • Esegui la federazione del tuo provider di identità con Cloud Identity: con la federazione con Cloud Identity, consenti a Google di diventare un IdP aggiuntivo che gli utenti della tua 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 ciascuno dei tuoi utenti, puoi fare affidamento sulla relazione di federazione per gestire automaticamente le identità. 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 alle applicazioni di cui è stato eseguito il deployment su Google Cloud di riutilizzare il tuo IdP collegandoti direttamente o mantenendo una replica del tuo IdP su Google Cloud.

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

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 stesso: devi consentire ai team responsabili di gestire Google Cloud utilizzando la console Google Cloud, gcloud CLI o le 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 del tuo personale l'accesso a queste risorse, devi eseguire il provisioning di un'identità Google per ogni utente.

La gestione di identità Google separate è in contrasto con l'idea di gestione dell'identità unificata. 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 IdP

Le risorse che potrebbero utilizzare Google come provider di identità, ma che al momento 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 di trasferire e migliorare in Google Cloud.

La possibilità per queste applicazioni di utilizzare Google come IdP dipende dai protocolli utilizzati 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. I 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, l'utilizzo di questi protocolli implica che, se vuoi, puoi usare Google come provider di identità mantenendo la flessibilità di cambiare provider di identità in base alle tue esigenze.

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 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 la query sulle informazioni utente: in questo scenario, un'applicazione non utilizza 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. Inoltre, altre informazioni sull'utente, come il nome e l'appartenenza al gruppo, potrebbero essere richieste dalla directory e utilizzate per autorizzare l'accesso.

  2. Utilizzo di SAML per l'autenticazione e di LDAP per eseguire query sulle informazioni utente: in questo scenario, l'applicazione autentica l'utente utilizzando un protocollo di accesso singolo. Per questo scopo, le applicazioni spesso utilizzano SAML. 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 richiede sia all'applicazione sia al server LDAP di avere 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 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 IdP esterno, Cloud Identity non gestisce una copia delle password degli utenti. Di conseguenza, solo il secondo scenario può essere attivato 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 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 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 in modo da utilizzare OIDC. OIDC non richiede che la workstation o il server dell'utente 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 senza interruzioni fornita dall'IWA, l'utilizzo di OIDC invece di IWA potrebbe sembrare un passo indietro in termini di esperienza utente. Tuttavia, non è necessario se garantisci agli utenti la possibilità di 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 federi Google Cloud con Azure AD, puoi attivare l'accessoSSO senza problemi di Azure AD con lo stesso effetto.

Il seguente diagramma mostra un esempio semplificato di come 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 token controllandone la firma crittografica, estrae l'identità utente dal token e emette un token SAML per l'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, la pagina protetta può essere restituita all'utente.

Autenticazione a chiave pubblica SSH

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

A differenza dei protocolli di accesso singolo discussi in precedenza, l'autenticazione con chiave pubblica SSH non si basa su un'identità provider centralizzata per prendere decisioni di autenticazione. Le decisioni di autenticazione sono invece decentralizzate: ogni macchina gestisce l'autenticazione in base a un insieme locale di chiavi pubbliche autorizzate.

Puoi colmare il divario tra l'autenticazione con chiave pubblica SSH decentralizzata e la gestione delle identità centralizzata 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.
  • Eseguire il provisioning della chiave pubblica dell'utente sulle macchine a cui l'utente ha diritto di accedere.
  • Il provisioning della chiave pubblica dell'utente viene rimosso 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ò utilizzare Google come IdP. Questi protocolli includono:

  • LDAP per l'autenticazione: anche se puoi utilizzare Secure LDAP per semplificare la query delle informazioni utente da Cloud Identity tramite LDAP, Cloud Identity non supporta l'utilizzo di LDAP per l'autenticazione quando è federato con un provider di identità 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 comunque fare affidamento su WS-Trust o WS-Federation per gestire l'autenticazione basata su token. A meno che non sia possibile modificare le applicazioni interessate in modo che utilizzino SAML o OpenID Connect, è meglio esporre 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 utilizzi AD FS come provider OpenID Connect, potresti fare affidamento su determinati claim specifici di AD FS non supportati da Google. In questo caso, ti consigliamo di esporre AD FS on-premise a Google Cloud e di 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 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 essere in grado di accedere a queste VM tramite il protocollo Remote Desktop (RDP), tramite un gateway di desktop remoto 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, che generano un account nel database del Security Account Manager (SAM) locale della VM. È fondamentale che l'account SAM di Windows risultante non sia collegato all'Account Google dell'utente e non sia soggetto 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 essere in grado di accedere a queste macchine, consentire agli utenti di generare account utente e password di Windows potrebbe essere un approccio valido. Tuttavia, se gestisci parchi di server Windows più grandi, può essere meglio estendere un Active Directory on-premise a Google Cloud e unire i rispettivi server al dominio. L'unione dei server al dominio è un requisito anche 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 fondamentali per la disponibilità dei tuoi carichi di lavoro. Le dipendenze potrebbero includere tunnel o interconnessioni VPN, applicazioni che comunicano tra loro o sistemi che accedono ai dati in ambienti di calcolo.

Quando esegui la federazione o l'estensione del tuo IdP esterno a Google Cloud, assicurati che la disponibilità dell'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.

Carichi di lavoro ridondanti

Se utilizzi Google Cloud per garantire la continuità aziendale, i tuoi workload su Google Cloud rispecchieranno alcuni dei workload 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.

Se fai in modo che Google Cloud si basi su un provider di identità esterno in esecuzione on-premise, crei 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 su Google Cloud in modo che tutti i carichi di lavoro su Google Cloud non siano interessati da un'interruzione del tuo ambiente di calcolo on-premise o della connettività tra Google Cloud e la tua rete on-premise.

Passaggi successivi