Prácticas recomendadas para mitigar los tokens de OAuth vulnerados en Google Cloud CLI

Last reviewed 2025-03-10 UTC

En este documento se describe cómo mitigar el impacto de un atacante que haya vulnerado los tokens de portador de OAuth que usa la CLI de gcloud.

Un atacante puede vulnerar estos tokens de OAuth si obtiene acceso a un endpoint en el que una cuenta de usuario o una cuenta de servicio legítimas ya se hayan autenticado con la CLI de gcloud. Después, el atacante puede copiar estos tokens en otro endpoint que controle para hacer solicitudes que suplanten la identidad legítima. Aunque elimines el acceso del atacante al endpoint vulnerado, este podrá seguir haciendo solicitudes de API autenticadas con los tokens copiados. Para mitigar este riesgo, puedes controlar el acceso a tus sistemas mediante credenciales que tengan una duración breve y sean contextuales.

Este documento está dirigido a equipos de seguridad o arquitectos de nube que sean responsables de proteger sus recursos en la nube frente al acceso ilegítimo. En este documento se presentan los controles disponibles que puedes usar para reducir de forma proactiva el impacto de los tokens de OAuth de la CLI de gcloud vulnerados y para corregir tu entorno después de que se haya vulnerado un endpoint.

Información general

Para entender cómo funciona esta amenaza, debes saber cómo almacena la CLI de gcloud las credenciales de OAuth 2.0 y cómo se pueden usar de forma inadecuada si un atacante las pone en peligro.

Tipos de credenciales almacenadas por la CLI de gcloud

La CLI de gcloud usa tokens de acceso de OAuth 2.0 para autenticar solicitudes de APIs de Google Cloud . El flujo de OAuth varía según los tipos de credenciales que se utilicen, pero, por lo general, se puede acceder de forma local al token de acceso y a otras credenciales. En cada caso, el token de acceso caduca a los 60 minutos, pero otros tipos de credenciales pueden ser persistentes.

Cuando autorizas la CLI de gcloud con una cuenta de usuario, la CLI de gcloud inicia un flujo de consentimiento de OAuth de tres vías para acceder a lasGoogle Cloud APIs en nombre del usuario. Una vez que el usuario completa el flujo de consentimiento, la CLI de gcloud recibe un token de acceso y un token de actualización que le permiten solicitar nuevos tokens de acceso. El token de actualización de larga duración se mantiene hasta que se cumplen sus condiciones de vencimiento.

Cuando autorizas la CLI de gcloud con una cuenta de servicio, la CLI de gcloud inicia un flujo de OAuth de dos pasos para acceder a las APIs deGoogle Cloud como identidad de la cuenta de servicio. Después de activar una cuenta de servicio desde un archivo de clave privada, esta clave se usa para solicitar periódicamente un token de acceso. La clave privada de larga duración se almacena en la configuración de la CLI de gcloud y sigue siendo válida hasta que elimines la clave de la cuenta de servicio.

Cuando ejecutas la CLI de gcloud en un entorno de Google Cloud, como Compute Engine o Cloud Shell, la aplicación puede encontrar automáticamente las credenciales y autenticarse como una cuenta de servicio. Por ejemplo, en Compute Engine, una aplicación como la CLI de gcloud puede consultar el servidor de metadatos para obtener un token de acceso. Google gestiona y rota la clave de firma privada que se usa para crear el token de acceso, y las credenciales de larga duración no se exponen a la aplicación.

Cuando te autenticas con la federación de identidades de cargas de trabajo, las aplicaciones se autentican en función de una credencial de un proveedor de identidades externo y reciben un token de acceso federado de corta duración. Para obtener más información sobre cómo almacenar y gestionar las credenciales de larga duración que usa el proveedor de identidades externo, consulta las prácticas recomendadas para usar la federación de identidades de cargas de trabajo.

Cómo puede usar un atacante tokens de OAuth vulnerados

Si un atacante consigue vulnerar un endpoint, las credenciales, como los tokens de OAuth, son objetivos valiosos porque permiten a los atacantes mantener o ampliar su acceso.

Un desarrollador puede tener una necesidad legítima de ver sus propias credenciales al escribir y depurar código. Por ejemplo, un desarrollador puede necesitar autenticarse para usar solicitudes REST a Google Cloud servicios cuando trabaje con una biblioteca de cliente no compatible. El desarrollador puede ver las credenciales de varias formas, entre las que se incluyen las siguientes:

Sin embargo, un atacante podría usar estas mismas técnicas después de haber comprometido un endpoint.

Si un atacante vulnera un endpoint, como una estación de trabajo de un desarrollador, la principal amenaza es que pueda ejecutar comandos de la CLI de gcloud u otro código con las credenciales legítimas de la identidad autenticada. Además, el atacante podría copiar los tokens de OAuth en otro endpoint que controle para mantener el acceso. Cuando se produce este robo de credenciales, existe una amenaza secundaria: el atacante puede seguir usando los tokens de OAuth de larga duración para tener acceso persistente incluso después de que hayas retirado el acceso al endpoint vulnerado.

Si el atacante consigue vulnerar los tokens de OAuth, puede hacer lo siguiente:

  • Un atacante puede suplantar la identidad del usuario o de la cuenta de servicio vulnerados. El tráfico de la API que usa los tokens vulnerados se registra como si procediera de la cuenta de usuario o de servicio vulnerada, lo que dificulta distinguir entre la actividad normal y la maliciosa en los registros.
  • Un atacante puede actualizar el token de acceso indefinidamente mediante un token de actualización persistente asociado a un usuario o una clave privada asociada a una cuenta de servicio.
  • Un atacante puede eludir la autenticación con la contraseña o la verificación en dos pasos del usuario, ya que los tokens se conceden después del flujo de inicio de sesión.

Prácticas recomendadas para mitigar los riesgos

Implementa los controles descritos en las siguientes secciones para mitigar el riesgo de que se vulneren los tokens de la CLI de gcloud. Si sigue las prácticas recomendadas de seguridad que se describen en el plan de fundamentos empresariales o en el diseño de la zona de aterrizaje en Google Cloud, es posible que ya tenga estos controles implementados.

Configurar la duración de las sesiones de los servicios de Google Cloud

Para reducir el tiempo que un atacante puede aprovechar una token vulnerado, define la duración de la sesión de los Google Cloud servicios. En el caso de los clientes nuevos, se aplica automáticamente una duración de sesión predeterminada de 16 horas. Los clientes que crearon su Google Cloud organización antes del 2023 pueden tener una configuración predeterminada que nunca requiera la reautenticación. Revisa este ajuste para asegurarte de que tienes una política de reautenticación con una duración de sesión de entre 1 y 24 horas. La política de reautenticación invalida el token de actualización y obliga al usuario a reautenticar periódicamente la CLI de gcloud con su contraseña o llave de seguridad.

La duración de la sesión de los servicios de Google Cloud es una opción distinta de la duración de la sesión de los servicios de Google, que controla las sesiones web para iniciar sesión en los servicios de Google Workspace, pero no controla la reautenticación de los Google Cloud. Si usas servicios de Google Workspace, define la duración de las sesiones de ambos.

Configurar Controles de Servicio de VPC

Configura los Controles de Servicio de VPC en tu entorno para asegurarte de que solo el tráfico de la API Google Cloud que se origine dentro del perímetro definido pueda acceder a los recursos admitidos. El perímetro de servicio limita la utilidad de las credenciales vulneradas, ya que bloquea las solicitudes a servicios restringidos que proceden de endpoints controlados por atacantes que están fuera de tu entorno.

Configurar Chrome Enterprise Premium

Configura las políticas de Chrome Enterprise Premium para proteger Google Cloud la consola y las Google Cloud APIs. Configura un nivel de acceso de Chrome Enterprise Premium y una vinculación para permitir de forma selectiva los atributos que se evalúan en cada solicitud de API, incluido el acceso basado en IP o el acceso basado en certificados para TLS mutuo. Las solicitudes que usen credenciales de autorización vulneradas, pero que no cumplan las condiciones definidas en tu política de Chrome Enterprise Premium, se rechazarán.

Chrome Enterprise Premium es un control centrado en el usuario que rechaza el tráfico de la API de los usuarios que no cumplen las condiciones definidas. Controles de Servicio de VPC es un control centrado en los recursos que define los perímetros en los que pueden comunicarse los recursos. Controles de Servicio de VPC se aplica a todas las identidades de usuario y de cuenta de servicio, mientras que Chrome Enterprise Premium solo se aplica a las identidades de usuario de tu organización. Si se usan conjuntamente, Chrome Enterprise Premium y los Controles de Servicio de VPC reducen la eficacia de las credenciales vulneradas en una máquina controlada por un atacante que se encuentra fuera de tu entorno.

Implementar obligatoriamente la verificación en dos pasos para acceder al servidor remoto

Si permites que los desarrolladores accedan a los recursos de Compute Engine mediante SSH, configura OS Login con la verificación en dos pasos. De esta forma, se aplica un punto de control adicional en el que el usuario debe volver a autenticarse con su contraseña o llave de seguridad. Esta función bloquea a los atacantes que hayan vulnerado tokens de OAuth, pero no tengan la contraseña ni la llave de seguridad.

El acceso al protocolo de escritorio remoto (RDP) a instancias de Windows en Compute Engine no es compatible con el servicio OS Login, por lo que no se puede aplicar la verificación en dos pasos de forma granular a las sesiones de RDP. Cuando uses IAP Desktop o complementos de RDP basados en Google Chrome, define controles generales como la duración de la sesión de los servicios de Google y la verificación en dos pasos para las sesiones web del usuario, e inhabilita la opción Permitir que el usuario confíe en el dispositivo en la verificación en dos pasos.

Restringir el uso de claves de cuentas de servicio

Cuando usas una clave de cuenta de servicio para autenticarte, el valor de la clave se almacena en los archivos de configuración de la CLI de gcloud, por separado del archivo de clave descargado. Un atacante con acceso a tu entorno podría copiar la clave de la configuración de la CLI de gcloud o copiar el archivo de claves de tu sistema de archivos local o repositorio de código interno. Por lo tanto, además de tu plan para mitigar los tokens de acceso vulnerados, debes tener en cuenta cómo gestionas los archivos de claves de cuenta de servicio descargados.

Consulta alternativas de autenticación más seguras para reducir o eliminar los casos prácticos que dependen de una clave de cuenta de servicio y aplica la restricción de la política de organización iam.disableServiceAccountKeyCreation para inhabilitar la creación de claves de cuentas de servicio.

Ten en cuenta el principio de mínimos accesos

Al diseñar políticas de gestión de identidades y accesos, ten en cuenta el principio de mínimos privilegios. Concede a los usuarios los roles que necesiten para llevar a cabo una tarea con el menor permiso posible. No les concedas roles que no necesiten. Revisa y aplica las recomendaciones de roles para evitar que haya políticas de gestión de identidades y accesos con roles innecesarios y excesivos en tu entorno.

Protege tus endpoints

Piensa en cómo podría obtener un atacante acceso físico o remoto a tus endpoints, como estaciones de trabajo de desarrolladores o instancias de Compute Engine. Aunque es importante tener un plan para hacer frente a la amenaza de las tokens de OAuth vulneradas, también debes pensar en cómo responder a la amenaza de que un atacante pueda vulnerar tus endpoints de confianza. Si un atacante tiene acceso a tus endpoints de confianza, puede ejecutar comandos de la CLI de gcloud u otro código directamente en el endpoint.

Aunque la protección integral de las estaciones de trabajo de los desarrolladores va más allá del alcance de este documento, evalúa cómo pueden ayudarte tus herramientas y operaciones de seguridad a proteger y monitorizar tus endpoints para detectar si se han visto comprometidos. Plantéate las siguientes preguntas:

  • ¿Cómo se protege la seguridad física de las estaciones de trabajo de los desarrolladores?
  • ¿Cómo identificáis las brechas de seguridad en la red y respondéis a ellas?
  • ¿Cómo obtienen los usuarios acceso remoto a las sesiones SSH o RDP?
  • ¿Cómo se pueden vulnerar otras credenciales persistentes, como las claves SSH o las claves de cuentas de servicio?
  • ¿Hay flujos de trabajo que usen credenciales persistentes que se puedan sustituir por credenciales de corta duración?
  • ¿Hay dispositivos compartidos en los que alguien podría leer las credenciales de la CLI de gcloud almacenadas en caché de otro usuario?
  • ¿Puede un usuario autenticarse con la CLI de gcloud desde un dispositivo no fiable?
  • ¿Cómo se conecta el tráfico aprobado a los recursos que hay dentro de tu perímetro de Controles de Servicio de VPC?

Asegúrate de que tus operaciones de seguridad responden a todas estas preguntas.

Coordina tus equipos de respuesta

Asegúrate de que los equipos de seguridad responsables de la respuesta ante incidentes tengan el acceso adecuado a la consola de Google Cloud y a la consola de administración. Si hay equipos diferentes que gestionan la consola y la consola de administración, es posible que la respuesta se demore durante un incidente. Google Cloud

Para quitar el acceso de una cuenta de usuario vulnerada, tu equipo de respuesta ante incidentes necesita un rol de consola de administración, como el de administrador de gestión de usuarios. Para evaluar si se ha producido actividad sospechosa en tus Google Cloud recursos, es posible que este equipo también necesite roles de gestión de identidades y accesos, como el de lector de seguridad en todos los proyectos o el de lector de registros en un receptor de registros centralizado. Los roles necesarios para tu equipo de seguridad variarán en función del diseño y el funcionamiento de tu entorno.

Prácticas recomendadas para la corrección después de un incidente de seguridad

Una vez que se haya vulnerado la seguridad de un endpoint, como parte de tu plan de gestión de incidentes, determina cómo responder a la amenaza principal de un endpoint vulnerado y cómo mitigar los posibles daños continuos de la amenaza secundaria de los tokens vulnerados. Si un atacante tiene acceso persistente a la estación de trabajo del desarrollador, podría volver a copiar los tokens después de que el usuario legítimo vuelva a autenticarse. Si sospecha que las tokens de la CLI de gcloud pueden haberse visto comprometidas, abra una incidencia con Asistencia de Google Cloud y siga las recomendaciones de las secciones siguientes. Estas acciones pueden ayudar a limitar el impacto de un evento como este en tu organización. Google Cloud

Las recomendaciones de esta sección se solapan con las directrices generales sobre gestión de credenciales comprometidas Google Cloud , pero se centran específicamente en la amenaza de los tokens de la CLI de gcloud que se copian de un endpoint comprometido.

Hacer que caduquen los tokens activos de todas las cuentas de usuario con Google Cloud control de sesión

Si aún no has aplicado el Google Cloud control de sesiones, habilítalo inmediatamente con una frecuencia de reautenticación breve. Este control ayuda a asegurar que todos los tokens de actualización caduquen al final del periodo que definas, lo que limita el tiempo que un atacante puede usar los tokens vulnerados.

Invalidar manualmente los tokens de las cuentas de usuario vulneradas

Consulta las directrices sobre gestión de credenciales vulneradas para las identidades de usuario que puedan haberse visto comprometidas. En concreto, eliminar las credenciales de la CLI de gcloud es el método más eficaz para que un equipo de seguridad resuelva el problema de las tokens de OAuth vulnerables de las identidades de usuario. Para invalidar inmediatamente los tokens de actualización y los tokens de acceso de gcloud CLI, y obligar al usuario a volver a autenticarse con su contraseña o llave de seguridad, quita gcloud CLI de la lista de aplicaciones conectadas del usuario.

Un usuario también puede eliminar las credenciales de la CLI de gcloud de su cuenta.

Otros métodos, como suspender al usuario, cambiar su contraseña o restablecer las cookies de inicio de sesión, no abordan específicamente la amenaza de los tokens de OAuth vulnerados. Estos métodos suelen ser útiles para responder a incidentes, pero no invalidan los tokens de acceso que ya controla el atacante. Por ejemplo, si decides suspender a un usuario durante una investigación, pero no revocas los tokens de la CLI de gcloud, es posible que los tokens de acceso sigan siendo válidos si se restaura al usuario suspendido antes de que caduquen los tokens de acceso.

Invalidar tokens de muchas cuentas de usuario de forma programática

Si sospechas que se ha producido una brecha de seguridad, pero no puedes identificar a los usuarios afectados, considera la posibilidad de revocar las sesiones activas de todos los usuarios de tu organización más rápido de lo que permite la política de reautenticación.

Este enfoque puede interrumpir la actividad de los usuarios legítimos y finalizar procesos de larga duración que dependen de las credenciales de los usuarios. Si decides adoptar este enfoque, prepara una solución con secuencias de comandos para que tu centro de operaciones de seguridad (SOC) la ejecute con antelación y pruébala con algunos usuarios.

El siguiente código de ejemplo usa el SDK de administrador de Workspace para identificar todas las identidades de usuario de tu cuenta de Google Workspace o Cloud Identity que tengan acceso a la CLI de gcloud. Si un usuario ha autorizado la CLI de gcloud, la secuencia de comandos revoca el token de actualización y el token de acceso, y le obliga a volver a autenticarse con su contraseña o llave de seguridad. Para obtener instrucciones sobre cómo habilitar la API del SDK de administrador y ejecutar este código, consulta la guía de inicio rápido de Google Apps Script.

/**
 * Remove access to the Google Cloud CLI for all users in an organization
 * @see https://developers.google.com/admin-sdk/directory/reference/rest/v1/tokens
 * @see https://developers.google.com/admin-sdk/directory/reference/rest/v1/users
 * @see https://developers.google.com/apps-script/guides/services/advanced#enabling_advanced_services
 */

function listUsersAndInvalidate() {
  const users = AdminDirectory.Users.list({
    customer: 'my_customer' // alias to represent your account's customerId
    }).users;
  if (!users || users.length === 0) {
    Logger.log('No users found.');
    return;
  }
  for (const user of users){
    let tokens = AdminDirectory.Tokens.list(user.primaryEmail).items
    if (!tokens || tokens.length === 0) {
      continue;
    }
    for (const token of tokens) {
      if (token.clientId === "32555940559.apps.googleusercontent.com") {
        AdminDirectory.Tokens.remove(user.primaryEmail, token.clientId)
        Logger.log('Invalidated the tokens granted to gcloud for user %s', user.primaryEmail)
      }
    }
  }
}

Invalidar y cambiar las credenciales de las cuentas de servicio

A diferencia de los tokens de acceso que se conceden a identidades de usuario, los tokens de acceso que se conceden a cuentas de servicio no se pueden invalidar a través de la consola de administración ni con comandos como gcloud auth revoke. Además, la duración de la sesión que especifiques en la aplicación Google Cloud control de sesiones se aplica a las cuentas de usuario de tu directorio de Cloud Identity o Google Workspace, pero no a las cuentas de servicio. Por lo tanto, tu respuesta ante incidentes en cuentas de servicio vulneradas debe abordar tanto los archivos de claves persistentes como los tokens de acceso de corta duración.

Si sospechas que las credenciales de una cuenta de servicio se han visto comprometidas, inhabilita la cuenta de servicio, elimina las claves de la cuenta de servicio si hay alguna y, después de 60 minutos, habilita la cuenta de servicio. Si se elimina una clave de cuenta de servicio, se puede invalidar la credencial de larga duración para que un atacante no pueda solicitar un nuevo token de acceso, pero no se invalidan los tokens de acceso que ya se hayan concedido. Para asegurarte de que los tokens de acceso no se usen de forma inadecuada durante su tiempo de vida de 60 minutos, debes inhabilitar la cuenta de servicio durante 60 minutos.

También puedes eliminar y sustituir la cuenta de servicio para revocar inmediatamente todas las credenciales de corta y larga duración, pero esto puede requerir más trabajo para sustituir la cuenta de servicio en las aplicaciones.

Siguientes pasos