Prácticas recomendadas para proteger las credenciales de desarrollador

Obtén información sobre las prácticas recomendadas para proteger las estaciones de trabajo para desarrolladores y evitar el robo y el uso inadecuado de Google Cloud credenciales, incluidos los tokens de portador de OAuth de laCLI de Google Cloud, las credenciales predeterminadas de la aplicación y las claves locales.

Este documento está dirigido a los equipos de seguridad o arquitectos de la nube que son responsables de proteger los recursos de la nube del acceso ilegítimo. Obtén información sobre los controles disponibles que puedes usar para reducir de forma proactiva el impacto de las credenciales de desarrollador vulneradas y corregir el entorno después de que se haya vulnerado un extremo.

El riesgo de las credenciales vulneradas

Un atacante puede comprometer las credenciales si obtiene acceso a un extremo en el que una cuenta de usuario o una cuenta de servicio legítima ya se autenticó con Google Cloud o la gcloud CLI. Luego, el atacante puede copiar estos tokens en otro extremo que controle para realizar solicitudes que actúen en nombre de la identidad legítima. Incluso después de quitar el acceso del atacante al extremo vulnerado, el atacante puede seguir realizando solicitudes a la API autenticadas mediante los tokens copiados. Para mitigar este riesgo, puedes controlar el acceso a tus sistemas mediante credenciales de corta duración y contextuales.

Descripción general de las credenciales de desarrollador

Las siguientes Google Cloud credenciales suelen encontrarse en las estaciones de trabajo para desarrolladores:

En las siguientes secciones, se describe cómo se almacena y se usa cada tipo de credencial.

Tokens de OAuth de gcloud CLI

La gcloud CLI usa tokens de acceso de OAuth 2.0 para autenticar solicitudes a las Google Cloud APIs. El flujo de OAuth varía según los tipos de credenciales que se usan, 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 vence después de 60 minutos de forma predeterminada, pero puede durar hasta 12 horas en condiciones de restricción de tiempo de actividad extendido. Sin embargo, otros tipos de credenciales pueden ser persistentes.

Cuando autorizas gcloud CLI con una cuenta de usuario, gcloud CLI inicia un flujo de consentimiento de OAuth de tres segmentos para acceder a las Google Cloud APIs en nombre del usuario. Después de que el usuario completa el flujo de consentimiento, gcloud CLI recibe un token de acceso y un token de actualización que le permite solicitar nuevos tokens de acceso. El token de actualización de larga duración persiste hasta que se cumplan las condiciones de vencimiento.

Cuando autorizas gcloud CLI con una cuenta de servicio, gcloud CLI inicia un flujo de OAuth de dos segmentos para acceder a las Google Cloud APIs como la identidad de la cuenta de servicio. Después de activar una cuenta de servicio desde un archivo de claves privadas, la gcloud CLI usa esta clave para solicitar de forma periódica un token de acceso. La clave privada de larga duración se almacena en la configuración de la gcloud CLI y permanece válida hasta que inhabilites o borres la clave de la cuenta de servicio.

Cuando ejecutas gcloud CLI dentro de un Google Cloud entorno, como Compute Engine o Cloud Shell, la aplicación puede encontrar credenciales y autenticarse como una cuenta de servicio. Por ejemplo, en Compute Engine, una aplicación como gcloud CLI puede consultar el servidor de metadatos para obtener un token de acceso. Google administra 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.

Credenciales predeterminadas de la aplicación

Las aplicaciones usan las credenciales predeterminadas de la aplicación para autenticarse con Google Cloud las APIs. Los desarrolladores pueden generar credenciales predeterminadas de la aplicación ejecutando gcloud auth application-default login. Este comando escribe un archivo JSON de texto sin formato ($HOME/.config/gcloud/application_default_credentials.json o %APPDATA%\gcloud\application_default_credentials.json), que contiene un token de actualización de OAuth 2.0 y credenciales de cliente para las bibliotecas cliente.

Cualquier biblioteca cliente o secuencia de comandos personalizada puede usar estas credenciales para llamar a Google Cloud las APIs.

Debido a que las credenciales predeterminadas de la aplicación se guardan en texto simple, cualquier proceso o secuencia de comandos no confiable que se ejecute en el contexto del usuario puede acceder al archivo directamente o usar comandos como gcloud auth application-default print-access-token para recuperar tokens de acceso activos.

El malware típico suele atacar el directorio ~/.config/gcloud/ para obtener application_default_credentials.json.

Para obtener más información, consulta Credenciales predeterminadas de la aplicación.

Claves de cuenta de servicio

Las claves de cuenta de servicio son archivos de claves JSON privadas que se descargan de la Google Cloud consola. Las aplicaciones usan estas claves para autenticarse con Google Cloud las APIs. Las claves de cuenta de servicio se pueden almacenar en las siguientes ubicaciones:

  • Directorio de configuración de gcloud CLI después de ejecutar gcloud auth activate-service-account
  • El sistema de archivos local
  • Un repositorio de código interno

Las claves de cuenta de servicio en los extremos de desarrollador no están vinculadas a la verificación en 2 pasos, no tienen límites de sesión y no vencen automáticamente.

Un atacante que roba una clave de cuenta de servicio puede crear tokens de acceso de cuenta de servicio para mantener el acceso persistente.

Si quieres obtener más información, consulta las prácticas recomendadas para administrar claves de cuentas de servicio.

Claves SSH

Las claves SSH se usan para autenticarse con instancias de Compute Engine. Los desarrolladores pueden generar claves SSH con gcloud compute ssh. Este comando genera claves privadas locales en ~/.ssh/google_compute_engine. Las claves SSH son de larga duración.

Un atacante puede usar una clave SSH robada para acceder a una VM y, luego, consultar el servidor de metadatos para extraer un token de cuenta de servicio adjunto. Este ataque omite los firewalls perimetrales externos.

En lugar de usar claves SSH, considera el Acceso al SO con la verificación en 2 pasos. Para obtener más información, consulta Aplica la verificación en 2 pasos para el acceso al servidor remoto.

Cookies del navegador

Las cookies del navegador autentican las solicitudes HTTP web a la Google Cloud consola y Cloud Shell. Las cookies del navegador se crean automáticamente cuando un usuario accede a la Google Cloud consola.

Las cookies se almacenan en el directorio de perfiles del navegador en la estación de trabajo local. Por ejemplo, Google Chrome almacena cookies en ~/.config/google-chrome/ en Linux o %LOCALAPPDATA%\Google\Chrome\User Data en Windows.

Las cookies del navegador son credenciales de larga duración que solo se invalidan cuando un usuario sale, cuando se produce un tiempo de espera de la sesión o cuando un administrador restablece la sesión del usuario en la Consola del administrador.

Un atacante que roba estas cookies puede importarlas a otro navegador para secuestrar sesiones activas de la Google Cloud consola y omitir la autenticación.

Para reducir el riesgo de que se roben las cookies de sesión, establece la duración de la sesión para Google Cloud los servicios.

Tokens de acceso de la federación de identidades de personal

Los desarrolladores pueden usar la federación de identidades de personal para autenticarse a través de un proveedor de identidad externo, de modo que puedan acceder a los Google Cloud recursos.

Para acceder con una identidad federada, los desarrolladores usan un archivo de configuración de acceso (que se crea con el gcloud iam workforce-pools create-login-config comando) y acceden a la CLI de gcloud. Después de la autenticación con el proveedor de identidad externo, el servicio de token seguro intercambia el código de autorización por un token de acceso federado de corta duración y un token de actualización de OAuth.

Gcloud CLI almacena metadatos de credenciales y tokens de actualización en una base de datos de credenciales local y almacena en caché los tokens de acceso activos en el directorio de configuración de gcloud CLI. Los tokens de acceso federados son credenciales de corta duración que vencen después de un tiempo establecido (60 minutos de forma predeterminada).

Un atacante que compromete un extremo puede extraer tokens de acceso federados activos o usar gcloud auth print-access-token para actuar en nombre de la principal del personal. Si la identidad del personal tiene derechos de suplantación, el atacante también puede solicitar tokens de acceso de cuenta de servicio para elevar los privilegios.

Para reducir el riesgo, configura la duración de la sesión en tu grupo de identidades de personal a la duración mínima necesaria y alinea la duración con las políticas de reautenticación y tiempo de espera de la sesión de tu proveedor de identidad externo. Para obtener más información sobre cómo almacenar y administrar las credenciales, consulta las prácticas recomendadas para usar la federación de identidades para cargas de trabajo.

Impacto de las credenciales vulneradas

Si un atacante logra comprometer un extremo, las credenciales como los tokens de OAuth son objetivos valiosos, ya que permiten a los atacantes conservar o escalar su acceso.

Es posible que un desarrollador tenga una necesidad legítima de ver sus propias credenciales cuando escribe y depura el código. Por ejemplo, es posible que un desarrollador necesite autenticar solicitudes de REST a los Google Cloud servicios cuando trabaja con una biblioteca cliente no compatible. El desarrollador puede ver las credenciales a través de varios métodos, incluidos los siguientes:

Sin embargo, un atacante podría usar estas mismas técnicas después de que haya comprometido un extremo.

Si un atacante compromete un extremo, la amenaza principal es que puede ejecutar comandos de la gcloud CLI o algún otro código con las credenciales legítimas de la identidad autenticada. Además, el atacante puede copiar las credenciales en otro extremo que controle para conservar su acceso. Cuando ocurre este robo de credenciales, se produce una amenaza secundaria. El atacante aún puede usar las credenciales de larga duración para tener acceso persistente incluso después de quitar el acceso al extremo vulnerado.

Si el atacante logra comprometer las credenciales de desarrollador, puede completar las siguientes acciones:

  • Actuar en nombre de un usuario o una cuenta de servicio vulnerados. El tráfico de la API que usa los tokens vulnerados se registra como si proviniera del usuario o cuenta de servicio vulnerados, lo que dificulta distinguir entre la actividad normal y la maliciosa en los registros.
  • Solicitar tokens de acceso de forma indefinida mediante un token de actualización de OAuth persistente (desde la gcloud CLI o las credenciales predeterminadas de la aplicación) o una clave privada asociada con una cuenta de servicio.
  • Omitir la autenticación con la contraseña del usuario o la verificación en 2 pasos porque los tokens se otorgan después del flujo de acceso.
  • Usar claves SSH robadas para acceder a instancias de Compute Engine y consultar el servidor de metadatos para robar tokens de cuenta de servicio adjuntos.
  • Usar cookies de navegador robadas para secuestrar sesiones activas Google Cloud de la consola sin requerir la contraseña del usuario ni la verificación en 2 pasos.
  • Usar tokens de acceso federados robados para acceder a los recursos otorgados a los grupos de identidades de personal o elevar los privilegios actuando en nombre de las cuentas de servicio.

Prácticas recomendadas para mitigar riesgos

Implementa los controles que se describen en las siguientes secciones para mitigar el riesgo de credenciales de desarrollador vulneradas. Si sigues las prácticas recomendadas de seguridad que se describen en el plano de las bases empresarial o en el diseño de la zona de destino en Google Cloud, es posible que ya tengas habilitados estos controles.

Establece la duración de la sesión para los Google Cloud servicios

Para reducir la cantidad de tiempo que un atacante puede explotar un token vulnerado, establece la duración de la Google Cloud sesión para los servicios. Para los clientes nuevos, se aplica automáticamente una duración de sesión predeterminada de 16 horas. Es posible que los clientes que crearon su Google Cloud organización antes de 2023 tengan una configuración predeterminada para no requerir nunca la reautenticación. Revisa esta configuración para asegurarte de tener una política de reautenticación con una duración de sesión que esté entre 1 y 24 horas. La política de reautenticación obliga al usuario a volver a autenticar gcloud CLI con regularidad mediante su contraseña o clave de seguridad.

La duración de la sesión para los Google Cloud servicios es una configuración distinta de la duración de la sesión para los servicios de Google, que controla las sesiones web de acceso a todos los servicios de Google Workspace, pero no controla la reautenticación para Google Cloud. Si usas los servicios de Google Workspace, establece la duración de la sesión para ambos.

Configura los Controles del servicio de VPC

Configura Controles del servicio de VPC en todo tu entorno para garantizar que solo Google Cloud pueda acceder a los recursos admitidos el tráfico de la API que se origina dentro del perímetro definido. El perímetro de servicio limita la utilidad de las credenciales vulneradas porque el perímetro bloquea las solicitudes a servicios restringidos que se originan en extremos controlados por atacantes que están fuera de tu entorno.

Configura Chrome Enterprise Premium

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

Chrome Enterprise Premium es un control centrado en el usuario que rechaza el tráfico de la API de usuario que no cumple con las condiciones definidas. Los Controles del servicio de VPC son un control centrado en los recursos que define los perímetros dentro de los cuales pueden comunicarse los recursos. Los Controles del servicio de VPC se aplican a todas las identidades de usuarios y las cuentas de servicio, pero Chrome Enterprise Premium solo se aplica a las identidades de usuarios dentro de tu organización. Cuando se usan en conjunto, los Controles del servicio de VPC y Chrome Enterprise Premium reducen la efectividad de las credenciales vulneradas en una máquina controlada por atacantes que está fuera de tu entorno.

Aplica la verificación en 2 pasos para el acceso al servidor remoto

Si permites que los desarrolladores accedan a los recursos de Compute Engine mediante SSH, configura el Acceso al SO con la verificación en 2 pasos. Esto aplica un punto de control adicional en el que un usuario debe volver a autenticarse con su contraseña o clave de seguridad. Un atacante con tokens de OAuth vulnerados, pero sin una contraseña ni una llave de seguridad está bloqueado por esta función.

El acceso de protocolo de escritorio remoto (RDP) a las instancias de Windows en Compute Engine no admite el servicio de Acceso al SO, por lo que la verificación en 2 pasos no se puede aplicar de forma detallada para las sesiones de RDP. Cuando uses Identity-Aware Proxy (IAP) Desktop o complementos RDP basados en Google Chrome, completa lo siguiente:

Restringe 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 gcloud CLI, por separado del archivo de claves descargado. Un atacante con acceso a tu entorno puede copiar la clave de la configuración de la gcloud CLI o copiar el archivo de claves del sistema de archivos local o del repositorio de código interno. Por lo tanto, además de tu plan para mitigar los tokens de acceso vulnerados, considera cómo administras los archivos de claves de la cuenta de servicio descargados.

Revisa alternativas más seguras para la autenticación para reducir o eliminar los casos de uso que dependen de una clave de cuenta de servicio. Además, aplica las restricciones de la política de la organización constraints/iam.disableServiceAccountKeyCreation y constraints/iam.disableServiceAccountKeyUpload para inhabilitar la creación de claves de cuentas de servicio.

Aplica el principio de privilegio mínimo

Cuando diseñes políticas de Identity and Access Management (IAM), considera el privilegio mínimo. Otorga a los usuarios solo los roles que necesiten para realizar una tarea con el permiso más bajo. Revisa y aplica recomendaciones de roles para evitar políticas de IAM con roles excesivos y sin usar en tu entorno.

Protege tus extremos

Considera cómo un atacante puede obtener acceso físico o remoto a tus extremos, como estaciones de trabajo para desarrolladores o instancias de Compute Engine. Si bien un plan para abordar la amenaza de credenciales vulneradas es importante, también considera el riesgo de que un atacante comprometa tus extremos de confianza. Si un atacante tiene acceso a tus extremos de confianza, puede ejecutar comandos de la gcloud CLI o algún otro código directamente en los extremos.

Aunque la protección integral de las estaciones de trabajo para desarrolladores está fuera del alcance de este documento, evalúa cómo tus herramientas y operaciones de seguridad pueden ayudar a proteger y supervisar los extremos a fin de lograr riesgos. Ten en cuenta las siguientes preguntas:

  • ¿Cómo está protegida la seguridad física de las estaciones de trabajo para desarrolladores?
  • ¿Cómo identificas y respondes a las vulneraciones de la red?
  • ¿Cómo obtienen los usuarios el acceso remoto a las sesiones de SSH o RDP?
  • ¿Cómo se pueden comprometer las credenciales persistentes, como las claves SSH o las claves de cuenta de servicio?
  • ¿Hay flujos de trabajo que usen credenciales persistentes que se puedan reemplazar por credenciales de corta duración?
  • ¿Hay dispositivos compartidos en los que alguien pueda leer las credenciales de gcloud CLI de otro usuario almacenadas en caché?
  • ¿Puede un usuario autenticarse con gcloud CLI desde un dispositivo no confiable?
  • ¿Cómo se conecta el tráfico aprobado a los recursos dentro del perímetro de Controles del servicio de VPC?

Asegúrate de que tus operaciones de seguridad aborden cada una de estas preguntas.

Alinea a tus equipos de respuesta

Asegúrate de antemano de que los equipos de seguridad que son responsables de la respuesta ante incidentes tengan el acceso adecuado en la Google Cloud consola y la Consola del administrador. Si equipos separados administran la Google Cloud consola y la Consola del administrador, es posible que tengas una respuesta retrasada durante un incidente.

Para evaluar y responder a una vulneración, consulta Responde a las credenciales vulneradas Google Cloud .

Supervisa la vulneración de credenciales

Para supervisar posibles vulneraciones, considera lo siguiente:

  • Busca secretos en tus repositorios de código con herramientas como la detección de anomalías o el análisis de secretos.

  • En los Registros de auditoría de Cloud, configura alertas para lo siguiente:

    • Métodos iamcredentials.googleapis.com (como GenerateAccessToken, GenerateIdToken, SignJwt) para auditar la generación de tokens de cuenta de servicio

      Estos registros requieren que habilites los registros de acceso a los datos.

    • protoPayload.authenticationInfo.serviceAccountDelegationInfo.firstPartyPrincipal.principalEmail para auditar las suplantaciones de identidad de usuarios y cuentas de servicio

    • Solicitudes de intercambio sts.googleapis.com para aserciones de identidad anómalas

  • En Security Command Center, supervisa los siguientes hallazgos de amenazas de Event Threat Detection:

    • Persistencia: Nueva geografía
    • Persistencia: Usuario-agente nuevo
    • Persistencia: Nuevo método de la API
    • Evasión: Acceso desde un proxy de anonimización
    • Elevación de privilegios: Suplantación de identidad anómala de la cuenta de servicio en la actividad del administrador
    • Elevación de privilegios: Uso de identidad anómalo de la cuenta de servicio para actividades de administrador
    • Acceso inicial: Se usó una clave de cuenta de servicio filtrada
    • Persistencia: Se creó la clave de cuenta de servicio
    • Acceso inicial: Acceso sospechoso bloqueado
    • Acceso inicial: Usurpación de cuenta inhabilitada

    Para cada amenaza, pasos de investigación recomendadosse proporcionan para ayudarte en tu respuesta.

  • Supervisa los accesos de los usuarios en Google Workspace y Cloud Identity. Para realizar un mejor seguimiento de los problemas, considera exportar los registros a Cloud Logging.

  • Supervisa los registros de Chrome Enterprise Premium y los Controles del servicio de VPC para detectar intentos de acceso fuera del perímetro con tokens robados.

  • Supervisa las anomalías en el uso de la clave de la cuenta de servicio mediante Cloud Monitoring.

Asegúrate de que el centro de operaciones de seguridad (SOC) reciba una notificación oportuna y tenga las guías, las herramientas y el acceso necesarios para responder con rapidez a las posibles sospechas de compromisos. También puedes integrar Security Command Center en tu SIEM existente o importar registros a Google Security Operations para realizar un análisis más detallado.

¿Qué sigue?