GCP - Understanding Domain-Wide Delegation
Questo post è l'introduzione di https://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover che può essere consultato per ulteriori dettagli.
Comprendere la Delegazione a Livello di Dominio
La delegazione a livello di dominio di Google Workspace consente a un oggetto identità, sia un app esterna dal Google Workspace Marketplace che un Account di Servizio GCP interno, di accedere ai dati attraverso il Workspace per conto degli utenti. Questa funzionalità, cruciale per le app che interagiscono con le API o i servizi Google che necessitano di impersonificazione dell'utente, migliora l'efficienza e riduce l'errore umano automatizzando i compiti. Utilizzando OAuth 2.0, gli sviluppatori di app e gli amministratori possono dare a questi account di servizio accesso ai dati degli utenti senza il consenso individuale degli utenti. Google Workspace consente la creazione di due principali tipi di identità delegate globali:
Applicazioni GWS: Le applicazioni del Marketplace di Workspace possono essere configurate come un'identità delegata. Prima di essere rese disponibili nel marketplace, ogni applicazione Workspace viene sottoposta a una revisione da parte di Google per minimizzare il potenziale abuso. Anche se questo non elimina completamente il rischio di abuso, aumenta significativamente la difficoltà affinché tali incidenti si verifichino.
Account di Servizio GCP: Scopri di più su Account di Servizio GCP qui.
Delegazione a Livello di Dominio: Dietro le Quinte
Ecco come un Account di Servizio GCP può accedere alle API Google per conto di altre identità in Google Workspace:
L'identità crea un JWT: L'identità utilizza la chiave privata dell'account di servizio (parte del file della coppia di chiavi JSON) per firmare un JWT. Questo JWT contiene dichiarazioni sull'account di servizio, l'utente target da impersonare e gli ambiti OAuth di accesso all'API REST richiesta.
L'identità utilizza il JWT per richiedere un token di accesso: L'applicazione/utente utilizza il JWT per richiedere un token di accesso dal servizio OAuth 2.0 di Google. La richiesta include anche l'utente target da impersonare (l'email dell'utente Workspace) e gli ambiti per i quali viene richiesto l'accesso.
Il servizio OAuth 2.0 di Google restituisce un token di accesso: Il token di accesso rappresenta l'autorità dell'account di servizio di agire per conto dell'utente per gli ambiti specificati. Questo token è tipicamente a breve termine e deve essere rinnovato periodicamente (in base alle necessità dell'applicazione). È essenziale comprendere che gli ambiti OAuth specificati nel token JWT hanno validità e impatto sul token di accesso risultante. Ad esempio, i token di accesso che possiedono più ambiti manterranno validità per numerose applicazioni API REST.
L'identità utilizza il token di accesso per chiamare le API Google: Ora con un token di accesso pertinente, il servizio può accedere all'API REST richiesta. L'applicazione utilizza questo token di accesso nell'intestazione "Authorization" delle sue richieste HTTP destinate alle API Google. Queste API utilizzano il token per verificare l'identità impersonata e confermare che ha l'autorizzazione necessaria.
Le API Google restituiscono i dati richiesti: Se il token di accesso è valido e l'account di servizio ha l'autorizzazione appropriata, le API Google restituiscono i dati richiesti. Ad esempio, nell'immagine seguente, abbiamo utilizzato il metodo users.messages.list per elencare tutti gli ID dei messaggi Gmail associati a un utente target di Workspace.
Last updated
