Delegación de todo el dominio: riesgos de seguridad

En resumen. La delegación de todo el dominio (DWD, domain-wide delegation) permite que una cuenta de servicio o un cliente de API actúe como cualquier usuario del dominio para los scopes indicados, sin consentimiento del usuario. Una delegación con scopes de Gmail o Drive es una llave maestra para cada buzón o cada Drive. Las delegaciones nuevas aparecen en el registro de Admin como AUTHORIZE_API_CLIENT_ACCESS. Revise cada cliente delegado y sus scopes durante un incidente, y recuerde la investigación DeleFriend de 2023: quien pueda crear claves para una cuenta de servicio delegada en Google Cloud hereda la delegación.

Las autorizaciones OAuth por usuario se limitan a lo que alcanza un usuario. La DWD, no. Existe por buenas razones (herramientas de copia de seguridad, migración, integraciones de firma electrónica, el propio GAM), y por eso la mayoría de los tenants tienen alguna delegación que nadie recuerda haber aprobado. Para un atacante que llega a una cuenta de superadministrador, añadir una es la persistencia más silenciosa disponible. MITRE relaciona este terreno con T1098.001 Additional Cloud Credentials y T1484.002 Domain or Tenant Policy Modification: Trust Modification.

Cómo funciona la DWD

La página Control API access with domain-wide delegation de Google describe el mecanismo:

1. Se crea una cuenta de servicio en un proyecto de Google Cloud, o existe un cliente OAuth para una aplicación.
2. Un superadministrador añade su ID de cliente y una lista de scopes OAuth en Security → Access and data control → API controls → Manage Domain Wide Delegation (etiquetas de la consola en inglés).
3. El cliente ya puede solicitar tokens como cualquier usuario para esos scopes. Se omite el consentimiento del usuario.

Google recomienda scopes mínimos y revisiones periódicas en sus prácticas recomendadas de delegación de todo el dominio. Donde está activada la aprobación multiparte, un segundo superadministrador debe aprobar las delegaciones nuevas.

Qué muestran los registros

En el analizador, AUTHORIZE_API_CLIENT_ACCESS activa el hallazgo Delegación de todo el dominio concedida a un cliente de API (alta). Si esa misma cuenta de administrador tuvo un inicio de sesión de riesgo en los 14 días anteriores, la cadena «inicio de sesión de riesgo → cambio de administración» sube a crítica. La relajación de los controles de aplicaciones se marca por separado.

La investigación DeleFriend

En noviembre de 2023, el Team Axon de Hunters publicó «DeleFriend», un problema de diseño que había comunicado a Google en agosto de 2023. La delegación está ligada al ID de cliente de la cuenta de servicio, no a una clave privada concreta. Cualquiera con permiso en Google Cloud para crear claves de una cuenta de servicio que ya tenga DWD (iam.serviceAccountKeys.create, incluido en roles amplios como Editor) puede generar una clave nueva y usar la delegación existente. No hacen falta derechos de superadministrador de Workspace.

Consecuencias prácticas para una investigación:

• Comprometer el proyecto de Google Cloud que aloja una cuenta de servicio delegada es un compromiso de Workspace en potencia.
• El registro de Admin de Workspace no mostrará nada nuevo, porque la delegación ya existe. La señal está en el lado de Cloud (creación de claves) y en el registro de tokens (actividad de API nueva del cliente).
• Las delegaciones que ya no se usan son riesgo puro.

Investigar el lado de Google Cloud (claves de cuentas de servicio, cambios de IAM, registros de auditoría) es una disciplina propia. gcpforensics.com la cubre.

Lista de revisión

Durante un incidente, y al menos una vez al año:

1. Exporte la lista de delegaciones. La consola permite descargar en CSV las aplicaciones de terceros y los clientes con DWD. Para cada cliente: quién es el responsable, qué proyecto, qué scopes, cuándo se usó por última vez.
2. Señale los scopes amplios: https://mail.google.com/, gmail.*, drive, admin.directory.*, cloud-platform. La mayoría de las integraciones necesitan mucho menos.
3. Cruce cada AUTHORIZE_API_CLIENT_ACCESS del registro de Admin con una solicitud de cambio. Si no estaba planificado, es un incidente.
4. Revise los proyectos de Cloud propietarios: quién tiene Editor/Owner o permiso para crear claves en las cuentas de servicio delegadas, y si han aparecido claves nuevas.
5. Elimine las delegaciones que no se usan y rote las claves de las que mantenga.
6. Active la aprobación multiparte para las acciones de administración sensibles si su edición la ofrece.

Si encuentra una delegación ilegítima

• Quite el cliente de Manage Domain Wide Delegation de inmediato. Google indica que los cambios pueden tardar en aplicarse, normalmente menos de 24 horas.
• Desactive o elimine las claves de la cuenta de servicio en Google Cloud.
• Extraiga el registro de tokens OAuth de ese ID de cliente para todos los usuarios. Ese es el alcance del acceso a datos.
• Trate como comprometida la cuenta de superadministrador que la añadió: restablezca sus cookies de inicio de sesión, revise sus inicios de sesión y cada cambio que hizo. Véase abuso de roles de administrador y cambios de SSO.

En qué se diferencia del OAuth por usuario

Siguiente en la serie: descarga masiva de Drive y exfiltración con Takeout. Para revisar los cambios de delegación y confianza de su registro de Admin, cárguelo en el analizador.

FAQ

¿Quién puede conceder delegación de todo el dominio en Google Workspace?

Solo un superadministrador puede añadir o cambiar la delegación de todo el dominio, en Security → Access and data control → API controls → Manage Domain Wide Delegation. Si la aprobación multiparte está activada, otro superadministrador debe aprobarla.

¿Qué registro muestra los cambios de delegación de todo el dominio?

El registro de Admin. Añadir o cambiar los scopes delegados de un cliente se registra como AUTHORIZE_API_CLIENT_ACCESS, con el cliente y los scopes. Las llamadas a la API hechas después en nombre de los usuarios aparecen en el registro de tokens OAuth.