Autenticazione degli utenti della forza lavoro in un ambiente ibrido

Last reviewed 2022-10-02 UTC

Questo articolo è la prima parte di una serie in più parti che descrive come estendere la soluzione di gestione delle identità a Google Cloud per consentire alla forza lavoro di autenticare e utilizzare i servizi in un ambiente di computing ibrido.

La serie è costituita dai seguenti componenti:

Introduzione

La gestione degli account utente e il controllo dell'accesso dei dipendenti alle applicazioni e alle risorse di computing sono una responsabilità fondamentale dei reparti IT aziendali. Per garantire coerenza ed efficienza amministrativa, la maggior parte delle aziende considera la gestione delle identità come una funzione centrale e utilizza un sistema unificato per gestire le identità. A questo scopo, più comunemente le aziende si affidano ai Servizi di dominio Microsoft Active Directory (AD DS).

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 al minimo lo sforzo amministrativo per la gestione degli account e controllo dell'accesso. Inoltre, questo sistema garantisce che utenti e applicazioni possano eseguire l'autenticazione in modo sicuro in un ambiente ibrido.

Questo articolo illustra i modi per integrare Google Cloud con il tuo sistema di gestione delle identità. L'articolo ti aiuta a scegliere l'approccio più adatto alle tue esigenze.

Sebbene la maggior parte della discussione riguardi anche Google Workspace, l'articolo si concentra esclusivamente su Cloud Identity.

Valutazione dei requisiti per la gestione ibrida delle identità

Il modo migliore per estendere il tuo 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 i servizi di autenticazione per le identità
  • Le risorse e le applicazioni a cui vuoi che i tuoi utenti possano accedere su Google Cloud
  • I tuoi requisiti di continuità aziendale

Le sezioni seguenti analizzano 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 si gestiscono e si distinguono 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 dell'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, ad esempio contrattisti o partner a cui è necessario concedere 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 identità che gestisci per gli utenti al fine di interagire con il tuo sito web o con le applicazioni rivolte ai clienti.
  5. Le identità del carico di lavoro sono quelle 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 un'unica identità e tutte le identità sono gestite nello stesso modo, utilizzando gli stessi sistemi. Tuttavia, anche questo non deve essere necessariamente il caso: a seguito di una fusione o di un'acquisizione, ad esempio, potresti avere più pool di identità della forza lavoro, ciascuno gestito in modo diverso utilizzando sistemi diversi. Tecnicamente, questo significa che potrebbe essere necessario integrare più origini LDAP, foreste di Active Directory o tenant di Azure AD con Google Cloud.

L'integrazione di più pool aggiunge alla complessità dell'integrazione con Google Cloud. Pertanto, devi valutare:

  • Tutti i pool di identità devono accedere a Google Cloud o solo a un sottoinsieme selezionato?
  • Tutti i pool di identità devono avere accesso alla stessa organizzazione in Google Cloud o a una diversa?
  • Esistono opzioni per ridurre il numero di pool, ad esempio creando 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 suo account potrebbe essere valido solo per un periodo di tempo limitato.
  • Potrebbero essere concessi meno diritti per impostazione predefinita.
  • Potrebbero essere gestiti da una directory LDAP separata, una foresta di Active Directory o un tenant di Azure AD.

A differenza delle identità esterne, le identità ospite non vengono gestite da te, ma da una parte diversa. Nelle applicazioni SaaS come Google Workspace, le identità ospite possono eliminare la necessità di gestire identità esterne per clienti o partner. È raro che si verifichino identità ospite in ambienti on-premise.

Questo articolo 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 all'identità della loro forza lavoro, ovvero due identità. In tal caso, valuta la possibilità di consolidare 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 e alla fine decide se autenticare un utente.

Oltre a fornire servizi di autenticazione, spesso gli IdP gestiscono il ciclo di vita delle identità. Tuttavia, non è necessario che sia così, perché il provisioning delle identità potrebbe essere eseguito anche da un sistema di risorse umane separato.

I provider di identità 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, è possibile che tu stia utilizzando più sistemi per gestire diversi pool di utenti, gestire account esterni o fornire servizi di autenticazione diversi per gli stessi pool di utenti. Ecco alcuni esempi in cui vengono utilizzati più IdP per gestire gli stessi pool:

  • Active Directory federata con Azure AD
  • Active Directory federata 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:

  • Federa il tuo provider di identità con Cloud Identity: grazie alla federazione con Cloud Identity, consenti a Google di diventare un ulteriore IdP che gli utenti della tua forza lavoro possono utilizzare e su cui le applicazioni di cui è stato eseguito il deployment su Google Cloud possono fare affidamento. Anziché gestire le identità Google per ciascuno dei tuoi utenti, puoi fare affidamento sulla relazione di federazione per mantenere le identità automaticamente. Questa relazione aiuta anche a far sì che l'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, connettendoti direttamente o gestendo una replica del tuo IdP su Google Cloud.

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

Risorse

Il terzo fattore da considerare sono le risorse Google Cloud a cui 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 console Google Cloud, gcloud CLI o le API.

Altre risorse potrebbero includere:

Queste risorse si differenziano per il fatto che devono, possono o non possono utilizzare Google come provider di identità. Le sezioni seguenti analizzano 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 forza lavoro l'accesso a queste risorse, devi eseguire il provisioning di un'identità Google per ciascun utente.

Mantenere identità Google separate è in contrasto con l'idea di gestione unificata delle identità. Pertanto, concedere agli utenti l'accesso a una di queste risorse implica che devi federe il tuo IdP con Google Cloud.

Dopo aver federato l'IdP con Google Cloud, valuta la possibilità di utilizzare Google come IdP per ulteriori risorse, comprese 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 che al momento non lo fanno, includono:

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

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

Protocolli Web Single Sign-On

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, applicato a client mobile, fat client e altre applicazioni non browser.
  • OpenID Connect 1.0 (OIDC), applicabile alle applicazioni basate su browser.
  • SAML 2.0, applicabile all'integrazione di applicazioni di terze parti

Per le applicazioni che intendi sviluppare, OAuth 2.0 o OIDC dovrebbe essere la tua scelta preferita. Questi protocolli sono ampiamente diffusi e puoi sfruttare moltissime librerie e strumenti testati. Inoltre, basarsi su questi protocolli implica che puoi facoltativamente utilizzare Google come IdP, mantenendo la flessibilità di cambiare provider di identità in base alle esigenze.

Se disponi di applicazioni che utilizzano SAML, OAuth 2.0 o OIDC, il passaggio a Google come provider di identità dovrebbe essere possibile con poche modifiche al codice o nessuna.

LDAP

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

  1. Utilizzo di LDAP per l'autenticazione e l'esecuzione di query sulle informazioni degli utenti: 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 e poi utilizza le credenziali fornite per tentare un'operazione bind LDAP. Se il tentativo ha esito positivo, le credenziali sono considerate valide. Inoltre, potrebbero essere richieste ulteriori informazioni sull'utente come nome e appartenenza al gruppo dalla directory e utilizzate per autorizzare l'accesso.

  2. Utilizzo di SAML per l'autenticazione e LDAP per l'esecuzione di query sulle informazioni degli utenti: in questo scenario l'applicazione autentica l'utente utilizzando un protocollo Single Sign-On, che spesso le applicazioni utilizzano SAML. Dopo l'autenticazione dell'utente, l'applicazione utilizza il server LDAP per eseguire query su ulteriori informazioni sull'utente, come nome e iscrizioni ai gruppi.

La differenza fondamentale tra i due scenari è che il primo richiede sia l'applicazione che il 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 proprie query LDAP utilizzando un utente del servizio dedicato.

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

Kerberos e Dataplex

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

IWA si basa su NTLM o Kerberos. Richiede che la workstation dell'utente e il server su cui è in esecuzione l'applicazione siano aggiunti allo stesso dominio Active Directory o a domini attendibili.

Una conseguenza dell'utilizzo di Hadoop 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 o il server dell'utente siano uniti al dominio. Di conseguenza, il refactoring potrebbe semplificare il deployment e aiutarti a proporre opzioni di deployment alternative.

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

  • Se hai federato Google Cloud con Active Directory e AD FS, si applica qualsiasi metodo di autenticazione configurato in AD FS. Se configuri ADFS per consentire IWA, gli utenti che hanno eseguito l'accesso alla workstation Windows utilizzando le credenziali di dominio possono essere autenticati senza problemi per qualsiasi applicazione che utilizzi Google come IdP.
  • Se hai federato Google Cloud con Azure AD, puoi abilitare il servizio SSO senza interruzioni di Azure AD allo stesso modo.

Il seguente diagramma mostra un esempio semplificato di come utilizzare Cloud Identity, AD FS e IWA per implementare il Single Sign-On senza interruzioni 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 tramite 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 all'utente la pagina di accesso di Google, richiedendo l'indirizzo email.
  4. L'utente inserisce il proprio indirizzo email.
  5. In base all'indirizzo email, l'endpoint di accesso con Google identifica l'account Cloud Identity e riconosce che è configurato per l'utilizzo del servizio SSO. L'endpoint di accesso avvia quindi un accesso SAML con AD FS.
  6. AD FS, configurato per l'utilizzo di IWA, richiede al browser di presentare un ticket Kerberos, che attiva il browser di richiedere al sistema operativo Windows sottostante per ottenere un ticket appropriato.
  7. A meno che un ticket idoneo non sia stato memorizzato nella cache, Windows contatta il Key Distribution Center (KDC) di Active Directory per richiedere l'emissione di un ticket di servizio adeguato in base al ticket di concessione dei ticket (TGT) ottenuto quando l'utente ha eseguito l'accesso a Windows.
  8. Il browser presenta il ticket appena ottenuto in AD FS.
  9. AD FS convalida il ticket controllando la sua firma crittografica, estrae l'identità utente dal ticket ed emette un token SAML all'endpoint di accesso di Google.
  10. Utilizzando le informazioni di autenticazione del token SAML, l'endpoint di accesso con Google completa l'accesso OIDC e rilascia i token OpenID Connect all'applicazione web.
  11. Una volta autenticato, la pagina protetta può essere restituita all'utente.

Autenticazione a chiave pubblica SSH

Quando prevedi di eseguire macchine virtuali (VM) Linux su Google Cloud, è probabile che tu abbia 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 set locale di chiavi pubbliche autorizzate.

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

  • 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 alle macchine a cui un utente ha il diritto di accedere.
  • Eseguire il deprovisioning della chiave pubblica dell'utente quando all'account viene revocato l'accesso, disabilitato o eliminato.

L'utilizzo efficace di OS Login fa di 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. Ma puoi comunque utilizzare queste risorse su Google Cloud combinando due approcci:

Se una risorsa si basa su protocolli che l'IdP Google non supporta, non può utilizzare Google come IdP. Tali protocolli includono:

  • LDAP per l'autenticazione: anche se puoi utilizzare Secure LDAP per semplificare l'esecuzione di query sulle informazioni degli utenti da Cloud Identity tramite LDAP, Cloud Identity non supporta l'uso di LDAP per l'autenticazione se in federazione con un IdP esterno.

    Per consentire alle applicazioni di utilizzare LDAP per l'autenticazione, puoi esporre o replicare una directory LDAP on-premise oppure estendere la tua 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, ti consigliamo di esporre AD FS on-premise a Google Cloud e fare in modo che le applicazioni utilizzino direttamente AD FS.

  • OpenID Connect con rivendicazioni specifiche di AD FS: AD FS e Google supportano OpenID Connect. Se utilizzi AD FS come provider OpenID Connect, potresti fare affidamento su alcune dichiarazioni specifiche di AD FS non supportate da Google. In tal caso, valuta la possibilità di esporre AD FS on-premise su Google Cloud e fai 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 questo non è possibile, puoi eseguire il deployment di queste applicazioni su server Windows aggiunti a un dominio ed esporre o replicare la tua 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 Remote Desktop Protocol (RDP), tramite un gateway desktop remoto o in altri modi. Se un utente ha accesso in scrittura al progetto Google Cloud in cui è stata creata la VM, Google Cloud gli consente di creare un utente e una password, creando così un account nel database locale del gestore dell'account di sicurezza (SAM) della VM. Fondamentalmente, l'account Windows SAM 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 sarà 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, consentire agli utenti di generare account utente e password di Windows potrebbe essere un approccio valido. Ma quando si gestiscono gruppi più grandi di server Windows, può essere preferibile estendere una Active Directory on-premise a Google Cloud e unire i rispettivi server. I server di unione di domini sono obbligatori 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 carichi di lavoro e un'interruzione dell'IdP può avere conseguenze di vasta portata. L'approccio giusto per garantire una disponibilità adatta dipende da come intendi utilizzare Google Cloud e da come si inserisce nella tua strategia ibrida.

Carichi di lavoro distribuiti

Per sfruttare al meglio le funzionalità uniche offerte da ogni ambiente di computing, potresti utilizzare un approccio multi-cloud ibrido per distribuire i carichi di lavoro tra questi ambienti. Questi ambienti potrebbero avere dipendenze fondamentali per la disponibilità dei carichi di lavoro. Le dipendenze possono includere tunnel o interconnessioni VPN, applicazioni che comunicano tra loro o sistemi che accedono ai dati in ambienti di computing.

Durante la federazione o l'estensione dell'IdP esterno a Google Cloud, assicurati che la disponibilità dell'IdP esterno e di altri sistemi richiesti per l'autenticazione soddisfi o superi la disponibilità di altre dipendenze critiche. Questo requisito significa che potresti dover eseguire il deployment in modo ridondante dell'IdP esterno e delle sue dipendenze e garantire una 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 computing. Lo scopo di questa configurazione è consentire a un ambiente di computing di assumere il ruolo dell'altro ambiente in caso di guasto. Pertanto, è necessario considerare ogni dipendenza tra questi ambienti.

Poiché Google Cloud si basa su un IdP esterno in esecuzione on-premise, crei una dipendenza. Questa dipendenza potrebbe minare l'intento di far che Google Cloud sia una copia indipendente dell'ambiente di computing.

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

Passaggi successivi