GCP - Understanding Domain-Wide Delegation
Este post es la introducción de https://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover al cual se puede acceder para más detalles.
Comprendiendo la Delegación a Nivel de Dominio
La delegación a nivel de dominio de Google Workspace permite que un objeto de identidad, ya sea una aplicación externa del Marketplace de Google Workspace o una Cuenta de Servicio de GCP interna, pueda acceder a datos en todo el Workspace en nombre de los usuarios. Esta característica, crucial para aplicaciones que interactúan con las API de Google o servicios que necesitan la suplantación de usuarios, mejora la eficiencia y minimiza errores humanos al automatizar tareas. Utilizando OAuth 2.0, los desarrolladores de aplicaciones y administradores pueden dar acceso a estos cuentas de servicio a los datos de usuario sin el consentimiento individual del usuario. Google Workspace permite la creación de dos tipos principales de identidades de objeto delegadas a nivel global:
Aplicaciones de GWS: Las aplicaciones del Marketplace de Workspace pueden configurarse como una identidad delegada. Antes de estar disponibles en el marketplace, cada aplicación de Workspace es revisada por Google para minimizar posibles abusos. Si bien esto no elimina por completo el riesgo de abuso, aumenta significativamente la dificultad para que ocurran tales incidentes.
Cuenta de Servicio de GCP: Aprende más sobre las Cuentas de Servicio de GCP aquí.
Delegación a Nivel de Dominio: Bajo la Superficie
Así es como una Cuenta de Servicio de GCP puede acceder a las API de Google en nombre de otras identidades en Google Workspace:
La Identidad crea un JWT: La Identidad utiliza la clave privada de la cuenta de servicio (parte del archivo de par de claves JSON) para firmar un JWT. Este JWT contiene reclamaciones sobre la cuenta de servicio, el usuario objetivo a suplantar y los ámbitos OAuth de acceso a la API REST que se está solicitando.
La Identidad utiliza el JWT para solicitar un token de acceso: La aplicación/usuario utiliza el JWT para solicitar un token de acceso del servicio OAuth 2.0 de Google. La solicitud también incluye al usuario objetivo a suplantar (el correo electrónico del usuario de Workspace) y los ámbitos para los cuales se solicita acceso.
El servicio OAuth 2.0 de Google devuelve un token de acceso: El token de acceso representa la autoridad de la cuenta de servicio para actuar en nombre del usuario para los ámbitos especificados. Este token suele tener una duración corta y debe actualizarse periódicamente (según la necesidad de la aplicación). Es esencial entender que los ámbitos OAuth especificados en el token JWT tienen validez e impacto en el token de acceso resultante. Por ejemplo, los tokens de acceso que poseen múltiples ámbitos tendrán validez para numerosas aplicaciones de API REST.
La Identidad utiliza el token de acceso para llamar a las API de Google: Ahora, con un token de acceso relevante, el servicio puede acceder a la API REST requerida. La aplicación utiliza este token de acceso en el encabezado "Autorización" de sus solicitudes HTTP destinadas a las API de Google. Estas API utilizan el token para verificar la identidad suplantada y confirmar que tiene la autorización necesaria.
Las API de Google devuelven los datos solicitados: Si el token de acceso es válido y la cuenta de servicio tiene la autorización adecuada, las API de Google devuelven los datos solicitados. Por ejemplo, en la siguiente imagen, hemos aprovechado el método users.messages.list para listar todos los IDs de mensajes de Gmail asociados con un usuario objetivo de Workspace.
Última actualización
