Prácticas recomendadas para proteger las cuentas de servicio

Las cuentas de servicio difieren de las cuentas de usuario en que son un recurso y un principal:

  • Como principal, una cuenta de servicio puede obtener acceso a los recursos, como un bucket de Cloud Storage.
  • Como recurso, otros principales, como un usuario o grupo, pueden acceder a una cuenta de servicio y, tal vez, actuar en su nombre.

Para proteger las cuentas de servicio, considera su doble naturaleza:

  • Debido a que una cuenta de servicio es una principal, debes limitar sus privilegios para reducir el daño potencial que puede causar una cuenta de servicio vulnerada.
  • Debido a que una cuenta de servicio es un recurso, debes protegerla para que no se vea comprometida.

Existen varias formas en las que se puede abusar de una cuenta de servicio:

  • Elevación de privilegios: una persona/entidad que actúa de mala fe puede obtener acceso a recursos a los que, de lo contrario, no tendría acceso si actúa en nombre de la cuenta de servicio.
  • Falsificación de identidad: una persona/entidad que actúa de mala fe puede usar el robo de identidad de la cuenta de servicio para ocultar su identidad.
  • No rechazo: una persona/entidad que actúa de mala fe puede ocultar su identidad y sus acciones con una cuenta de servicio para realizar operaciones en su nombre. En algunos casos, es posible que no se pueda rastrear estas acciones hasta la persona/entidad que actúa de mala fe.
  • Divulgación de información: una persona/entidad que actúa de mala fe puede derivar información sobre la infraestructura, las aplicaciones o los procesos a partir de la existencia de ciertas cuentas de servicio.

En esta guía, se presentan prácticas recomendadas para limitar los privilegios de las cuentas de servicio y mitigar estos riesgos principales.

Limita los privilegios de la cuenta de servicio

Las cuentas de servicio son principales y se les puede otorgar acceso a un recurso como una cuenta de usuario normal.

No uses asignaciones de funciones automáticas para las cuentas de servicio predeterminadas

Algunos servicios de Google Cloud crean cuentas de servicio predeterminadas cuando habilitas por primera vez su API en un proyecto de Google Cloud. De forma predeterminada, a estas cuentas de servicio se les otorga la función de editor (roles/editor) en tu proyecto de Cloud, lo que les permite leer y modificar todos los recursos en el proyecto de Cloud. La función se otorga para tu comodidad, pero no es esencial que los servicios funciones: a fin de acceder a los recursos en tu proyecto de Cloud, los servicios de Google Cloud usan agentes de servicios, no las cuentas de servicio predeterminadas.

Para evitar que las cuentas de servicio predeterminadas reciban de forma automática la función de editor, habilita la restricción Inhabilita el otorgamiento automático de IAM para las cuentas de servicio predeterminadas (constraints/iam.automaticIamGrantsForDefaultServiceAccounts) en tu organización. Para aplicar la restricción a varios proyectos de Cloud, configúrala en la carpeta o el nodo de la organización. Cuando se aplica la restricción, no se quita la función editor de las cuentas de servicio predeterminadas existentes.

No dependas de los niveles de acceso cuando adjuntes una cuenta de servicio a una instancia de VM

Cuando conectas una cuenta de servicio a una instancia de VM, puedes especificar uno o más permisos de acceso. Los permisos de acceso te permiten restringir a qué servicios puede acceder la VM. Las restricciones se aplican junto con las políticas de administración de identidades y accesos (IAM).

Los permisos de acceso son generales. Por ejemplo, si usas el permiso https://www.googleapis.com/auth/devstorage.read_only, puedes restringir el acceso a las operaciones de solo lectura de Cloud Storage, pero no puedes restringir el acceso a buckets específicos. Por lo tanto, los permisos de acceso no son un reemplazo adecuado para políticas de IAM detalladas.

En lugar de depender de los permisos de acceso, crea una cuenta de servicio dedicada y usa políticas de IAM detalladas para restringir a qué recursos tiene acceso la cuenta de servicio.

Evita usar grupos para otorgar a las cuentas de servicio acceso a los recursos

En una organización, es común que varios empleados realicen funciones de trabajo similares o superpuestas y, por lo tanto, requieran acceso similar a los recursos. Mediante el uso de grupos, puedes aprovechar estas similitudes para reducir la sobrecarga administrativa.

Las cuentas de servicio están diseñadas para que las usen las aplicaciones. Es poco común que varias aplicaciones realicen la misma función y, por lo tanto, tengan requisitos de acceso similares o idénticos. En cambio, las aplicaciones tienden a ser únicas y los recursos a los que requieren acceso suelen ser diferentes para cada aplicación.

El uso de grupos para otorgar a las cuentas de servicio acceso a los recursos puede generar algunos resultados negativos:

  • Una proliferación de grupos, con cada grupo que contiene solo una cuenta de servicio o unas pocas cuentas de servicio.
  • Aumento de permisos: con el tiempo, a un grupo se le otorga acceso a una cantidad cada vez mayor de recursos, aunque cada miembro del grupo solo requiera acceso a un subconjunto de recursos.

A menos que el propósito de un grupo esté definido de forma estrecha, es mejor evitar usar grupos. En su lugar, otorga a las cuentas de servicio acceso directo a los recursos que necesitan.

Evita usar la delegación de todo el dominio

La delegación de todo el dominio permite que una cuenta de servicio actúe en nombre de cualquier usuario en una cuenta de Cloud Identity o de Google Workspace. La delegación de todo el dominio permite que una cuenta de servicio realice ciertas tareas administrativas en Google Workspace y Cloud Identity, o que acceda a las API de Google que no admiten cuentas de servicio externas a Google Cloud.

La delegación de todo el dominio no restringe una cuenta de servicio para actuar en nombre de un usuario en particular, pero le permite actuar en nombre de cualquier usuario en una cuenta de Cloud Identity o Google Workspace, incluidos los administradores avanzados. Si se permite que una cuenta de servicio use la delegación de todo el dominio, esta puede convertirse en un objetivo atractivo para los ataques de elevación de privilegios.

Evita usar la delegación de todo el dominio si puedes realizar la tarea directamente con una cuenta de servicio o mediante el flujo de consentimiento de OAuth.

Si no puedes evitar el uso de la delegación de todo el dominio, restringe el conjunto de permisos de OAuth que puede usar la cuenta de servicio. Aunque los permisos de OAuth no restringen los usuarios en cuyo nombre puede actuar la cuenta de servicio, sí restringen los tipos de datos del usuario a los que puede acceder la cuenta de servicio.

Usa límites de acceso a las credenciales para disminuir el alcance de los tokens de acceso

Los tokens de acceso de Google son tokens del portador, lo que significa que su uso no está vinculado a ninguna aplicación en particular. Si tu aplicación pasa un token de acceso a una aplicación diferente, entonces esa otra aplicación puede usar el token de la misma manera que tu aplicación. Del mismo modo, si un token de acceso se filtra a una persona/entidad que actúa de mala fe, dicha persona/entidad puede usar el token para obtener acceso.

Debido a que los tokens de acceso son tokens del portador, debes evitar que se filtren o se vuelvan visibles para las partes no autorizadas. Para limitar los potenciales daños que puede causar un token de acceso filtrado, restringe los recursos a los que otorga acceso. Este proceso se denomina reducción del alcance.

Usa los límites de acceso a las credenciales para disminuir el alcance de los tokens de acceso cada vez que pases un token de acceso a una aplicación diferente o a un componente distinto de tu aplicación. Establece el límite de acceso para que el token otorgue suficiente acceso a los recursos necesarios, pero no más.

Usar recomendaciones de funciones para identificar permisos sin usar

Cuando implementas una aplicación por primera vez, es posible que no estés seguro de qué funciones y permisos necesita la aplicación. Como resultado, puedes otorgar a la cuenta de servicio de la aplicación más permisos que necesite.

De manera similar, los requisitos de acceso de una aplicación pueden evolucionar con el tiempo y es posible que algunas de las funciones y los permisos que otorgaste al principio no sean necesarios.

Usa las recomendaciones de función para identificar qué permisos usa una aplicación y cuáles no se pueden usar. Ajusta las políticas de IAM de los recursos afectados para garantizar que a una aplicación no se le otorgue más acceso del que realmente necesita.

Protección contra amenazas de elevación de privilegios

Una cuenta de servicio a la que no se le otorgaron funciones, no tiene acceso a ningún recurso y no está asociada a ninguna regla de firewall, por lo general, tiene un valor limitado. Después de otorgar a una cuenta de servicio acceso a los recursos, el valor de la cuenta de servicio aumenta: la cuenta de servicio se vuelve más útil para ti, pero también se convierte en un objetivo más atractivo para los ataques de elevación de privilegios.

Como ejemplo, considera una cuenta de servicio que tenga acceso completo a un bucket de Cloud Storage que contiene información sensible. En esta situación, la cuenta de servicio es tan valiosa como el bucket de Cloud Storage: en lugar de intentar acceder al bucket directamente, una persona/entidad que actúa de mala fe puede intentar tomar el control de la cuenta de servicio. Si ese intento se realiza correctamente, la persona/entidad que actúa de mala fe puede escalar sus privilegios mediante el robo de identidad de la cuenta de servicio, que, a su vez, le da acceso a la información sensible en el bucket.

Las técnicas de elevación de privilegios que involucran cuentas de servicio generalmente se dividen en estas categorías:

  • Robo de identidad directa: Podrías otorgarle de forma involuntaria permiso al usuario para suplantar la identidad de una cuenta de servicio o para crear una clave de cuenta de servicio para una cuenta de servicio. Si la cuenta de servicio tiene más privilegios que el usuario, puede usar esa capacidad para aumentar sus privilegios y obtener acceso a recursos a los que no podría acceder.
  • Robo de identidad indirecto: Si un usuario no puede actuar directamente como una cuenta de servicio, es posible que pueda hacerlo de forma indirecta si una canalización de CI/CD, la instancia de VM o un sistema de automatización diferente usa la cuenta de servicio al que pueden acceder: Si el sistema no implementa restricciones de acceso adecuadas, el usuario podría permitir que el sistema realice operaciones que no podría realizar por su cuenta, de manera que escalen sus privilegios.
  • Modificaciones de la política de IAM, del grupo o de la función personalizada: Un usuario que no tiene acceso a una cuenta de servicio con privilegios aún podría tener permiso para modificar las políticas de IAM de la cuenta de servicio, el proyecto de Cloud o la carpeta de Cloud. Luego, el usuario puede extender una de estas políticas de IAM para otorgarse el permiso (directa o indirectamente) de actuar en nombre de la cuenta de servicio.

En las siguientes secciones, se proporcionan prácticas recomendadas para proteger las cuentas de servicio de las amenazas de elevación de privilegios.

Evita permitir que los usuarios actúen en nombre de las cuentas de servicio que tienen más privilegios que ellos

Cuando un usuario actúa en nombre de una cuenta de servicio, obtiene acceso a algunos de los recursos o a todos los recursos a los que puede acceder la cuenta de servicio. Si la cuenta de servicio tiene un acceso más extenso que el usuario, significa que tiene más privilegios que el usuario.

Otorgar a un usuario permiso para actuar en nombre de una cuenta de servicio más privilegiada puede ser una manera de permitir de forma intencional que los usuarios eleven temporalmente sus privilegios, similar al uso de la herramienta sudo en Linux o mediante la elevación de procesos en Windows. A menos que trabajes con una situación en la que se necesita esa elevación temporal de privilegios, es mejor evitar que los usuarios actúen en nombre de una cuenta de servicio con más privilegios.

Los permisos que permiten a un usuario actuar en nombre de una cuenta de servicio incluyen los siguientes:

  • iam.serviceAccounts.getAccessToken
  • iam.serviceAccounts.getOpenIdToken
  • iam.serviceAccounts.actAs
  • iam.serviceAccounts.implicitDelegation
  • iam.serviceAccountKeys.create
  • iam.serviceAccountKeys.get
  • deploymentmanager.deployments.create
  • cloudbuild.builds.create

Las funciones que contienen algunos de estos permisos incluyen (entre otras):

  • Propietario (roles/owner)
  • Editor (roles/editor)
  • Usuario de la cuenta de servicio (roles/iam.serviceAccountUser)
  • Creador de tokens de cuenta de servicio (roles/iam.serviceAccountTokenCreator)
  • Administrador de claves de cuentas de servicio (roles/iam.serviceAccountKeyAdmin)
  • Administrador de cuenta de servicio (roles/iam.serviceAccountAdmin)
  • Usuario de Workload Identity (roles/iam.workloadIdentityUser)
  • Editor de Deployment Manager (roles/deploymentmanager.editor)
  • Editor de Cloud Build (roles/cloudbuild.builds.editor)

Antes de asignar cualquiera de estas funciones a un usuario, hazte las siguientes preguntas:

  • ¿A qué recursos dentro y fuera del proyecto actual de Cloud podría acceder el usuario si actúa en nombre de la cuenta de servicio?
  • ¿Se justifica este nivel de acceso?
  • ¿Hay suficientes protecciones implementadas que controlan en qué circunstancias el usuario puede actuar en nombre de la cuenta de servicio?

No asignes la función si no puedes confirmar todas las preguntas. En su lugar, considera darle al usuario una cuenta de servicio diferente y menos privilegiada.

Evita permitir que los usuarios cambien las políticas de IAM de cuentas de servicio con más privilegios

La política de IAM de la cuenta de servicio captura qué usuarios pueden usar o actuar en nombre de una cuenta de servicio. Los usuarios que tienen el permiso iam.serviceAccounts.setIamPolicy en la cuenta de servicio específica pueden modificar o extender la política de IAM. Las funciones que contienen ese permiso incluyen las siguientes:

  • Propietario (roles/owner)
  • Administrador de seguridad (roles/iam.securityAdmin)
  • Administrador de cuenta de servicio (roles/iam.serviceAccountAdmin)

Las funciones que incluyen el permiso iam.serviceAccounts.setIamPolicy otorgan a un usuario control total sobre una cuenta de servicio:

  • El usuario puede otorgarse permiso para actuar en nombre de la cuenta de servicio, lo que le da la capacidad de acceder a los mismos recursos que la cuenta de servicio.
  • El usuario puede otorgar a otros usuarios el mismo nivel de acceso o uno similar a la cuenta de servicio.

Antes de asignar cualquiera de estas funciones a un usuario, pregúntate a qué recursos dentro y fuera del proyecto actual de Cloud podría obtener acceso el usuario si actúa en nombre de la cuenta de servicio. No permitas que un usuario cambie la política de IAM de una cuenta de servicio si esta tiene más privilegios que el usuario.

No permitas que los usuarios creen o suban claves de cuenta de servicio

Las claves de las cuentas de servicio permiten que las aplicaciones o los usuarios se autentiquen como una cuenta de servicio. A diferencia de otras formas de robo de identidad de cuentas de servicio, el uso de una clave de cuenta de servicio no requiere ninguna forma de autenticación previa; cualquier persona que posea una clave de cuenta de servicio puede usarla.

El efecto neto del uso de una clave de cuenta de servicio para la autenticación es similar a otras formas de robo de identidad. Si le otorgas a un usuario acceso a una clave de cuenta de servicio o le das permiso para crear una clave de cuenta de servicio nueva, el usuario puede actuar en nombre de la cuenta de servicio y acceder a todos los recursos a los que tiene acceso esa cuenta de servicio.

Crear o subir una clave de cuenta de servicio requiere el permiso iam.serviceAccountKeys.create, que se incluye en el administrador (roles/iam.serviceAccountKeyAdmin) y el editor (roles/editor) de clave de la cuenta de servicio.

Antes de asignar cualquier función que incluya el permiso iam.serviceAccountKeys.create a un usuario, pregúntate a qué recursos dentro y fuera del proyecto actual de Cloud podría acceder el usuario si actúa en nombre de la cuenta de servicio. No permitas que un usuario cree claves de cuenta de servicio para las cuentas de servicio que tienen más privilegios que el usuario.

Si tu proyecto de Cloud no requiere claves de cuenta de servicio, aplica las restricciones de las políticas de la organización Inhabilita la creación de claves de cuentas de servicio y, también, Inhabilita la carga de claves de cuentas de servicio al proyecto de Cloud o la carpeta adjunta. Estas restricciones impiden que todos los usuarios creen y suban claves de cuenta de servicio, incluso aquellas con el permiso iam.serviceAccountKeys.create en una cuenta de servicio.

No otorgues acceso a las cuentas de servicio a nivel de proyecto o carpeta de Cloud.

Las cuentas de servicio son recursos y forman parte de la jerarquía de recursos. Por lo tanto, puedes administrar el acceso a las cuentas de servicio en cualquiera de los siguientes niveles:

  • La cuenta de servicio individual
  • El proyecto de Cloud adjunto
  • Una carpeta en el principal del proyecto de Cloud
  • El nodo de la organización

Administrar el acceso a nivel de proyecto de Cloud o un nivel superior de la jerarquía de recursos puede ayudar a reducir la sobrecarga administrativa, pero también puede generar exceso de entrega de privilegios. Por ejemplo, si otorgas a un usuario la función de creador de tokens de la cuenta de servicio en un proyecto de Cloud, el usuario puede actuar en nombre de cualquier cuenta de servicio en el proyecto de Cloud. La posibilidad de actuar en nombre de cualquier cuenta de servicio implica que el usuario puede obtener acceso a todos los recursos a los que tienen acceso esas cuentas de servicio, incluidos los recursos fuera de ese proyecto de Cloud.

Para evitar este exceso de otorgamiento, no administres el acceso a las cuentas de servicio a nivel de proyecto o carpeta de Cloud. En su lugar, administra de forma individual el acceso para cada cuenta de servicio.

No ejecutes el código desde fuentes menos protegidas en recursos de procesamiento que tengan una cuenta de servicio con privilegios adjunta

Cuando conectas una cuenta de servicio a un recurso de procesamiento, como una instancia de VM o una aplicación de Cloud Run, los procesos que se ejecutan en ese recurso pueden usar el servidor de metadatos para realizar las siguientes acciones: solicitar tokens de acceso y tokens de ID. Estos tokens permiten que el proceso actúe en nombre de la cuenta de servicio y acceda a los recursos en su nombre.

De forma predeterminada, el acceso al servidor de metadatos no está restringido a procesos o usuarios específicos. En cambio, cualquier código que se ejecuta en el recurso de procesamiento puede acceder al servidor de metadatos y obtener un token de acceso. Este código podría incluir lo siguiente:

  • El código de tu aplicación
  • Código que envían los usuarios finales, si tu aplicación permite cualquier evaluación de secuencia de comandos del servidor.
  • El código leído desde un repositorio de origen remoto, si el recurso de procesamiento es parte de un sistema de CI/CD.
  • Secuencias de comandos de inicio y apagado que entrega un bucket de Cloud Storage.
  • Políticas de invitado que distribuye VM Manager.

Si los usuarios envían el código o este se lee desde una ubicación de almacenamiento remoto, debes asegurarte de que sea confiable y que las ubicaciones de almacenamiento remoto estén tan bien protegidas como la cuenta de servicio conectada. Si una ubicación de almacenamiento remoto está menos protegida que la cuenta de servicio, una persona/entidad que actúa de mala fe podría elevar sus privilegios. Para hacerlo, inserta un código malicioso que use los privilegios de la cuenta de servicio en esa ubicación.

Limita el acceso de la shell a las VM que tienen adjuntas una cuenta de servicio con privilegios

Algunos recursos de procesamiento admiten el acceso interactivo y permiten que los usuarios obtengan acceso de shell al sistema. Por ejemplo:

  • Compute Engine te permite usar SSH o RDP para acceder a una instancia de VM.
  • Google Kubernetes Engine te permite usar kubectl exec para ejecutar un comando o iniciar un shell en un contenedor de Kubernetes.

Si una instancia de VM tiene una cuenta de servicio con privilegios adjunta, cualquier usuario con acceso de shell al sistema puede actuar en nombre de la cuenta de servicio y acceder a los recursos en su nombre. Para evitar que los usuarios abusen de esta capacidad para aumentar sus privilegios, debes asegurarte de que el acceso de shell sea al menos tan seguro como la cuenta de servicio adjunta.

Para las instancias de Linux, puedes hacer que el acceso SSH sea más restrictivo que el acceso a la cuenta de servicio adjunta mediante el acceso del SO: para conectarte a una instancia de VM que tiene el acceso a SO habilitado, un usuario no debe ser solo puede usar el acceso a SO , pero también debe contar con laiam.serviceAccounts.actAs permiso en la cuenta de servicio adjunta.

El mismo nivel de control de acceso no se aplica a las instancias de VM que usan claves basadas en metadatos ni a las instancias de Windows: la publicación de una clave SSH a los metadatos o la solicitud de credenciales de Windows requiere acceso a los metadatos de la instancia de VM y el permiso iam.serviceAccounts.actAs en la cuenta de servicio adjunta. Sin embargo, después de publicar la clave SSH o de obtener las credenciales de Windows, los accesos posteriores no estarán sujetos a ninguna verificación de permisos de IAM adicional.

Del mismo modo, si una instancia de VM usa un módulo de autenticación personalizado que se puede conectar en Linux para la autenticación o es miembro de un dominio de Active Directory, es posible que los usuarios que no tendrían permiso para actuar en nombre de la cuenta de servicioo de otra manera puedan acceder.

En particular, para las instancias de VM que no usan el acceso al SO, considera controlar el acceso a la shell mediante Identity-Aware Proxy. Solo otorga la función de usuario de túnel protegido con IAP a los usuarios que deben poder actuar en nombre de la cuenta de servicio adjunta a la instancia de VM.

Limita el acceso del servidor de metadatos a los usuarios y procesos seleccionados

Cuando adjuntas una cuenta de servicio a una instancia de VM, las cargas de trabajo implementadas en la VM pueden acceder al servidor de metadatos a fin de solicitar tokens para las cuentas de servicio. De forma predeterminada, el acceso al servidor de metadatos no se limita a ningún proceso o usuario específico en la VM: incluso los procesos que se ejecutan como usuarios de privilegios bajos, como nobody en Linux o LocalService en Windows, tienen acceso completo al servidor de metadatos y pueden obtener tokens para la cuenta de servicio.

Para limitar el acceso del servidor de metadatos a usuarios específicos, configura el firewall del host del sistema operativo invitado a fin de permitir que estos usuarios abran conexiones salientes al servidor de metadatos.

En Linux, puedes usar las opciones --uid-owner y --gid-owner para configurar una regla iptables que solo se aplique a usuarios o grupos específicos. En Windows, el comando Set-NetFirewallSecurityFilter te permite personalizar una regla de firewall para que se aplique a usuarios o grupos seleccionados.

Proporciona protección contra amenazas de falsificación de identidad

La federación de Workload identity te permite crear una relación de confianza unidireccional entre un proyecto de Cloud y un proveedor de identidad externo. Una vez que hayas establecido esta relación de confianza, puedes intercambiar las credenciales obtenidas del proveedor de identidad externo por un token del servicio de token de seguridad (STS). Luego, puedes usar ese token del STS para acceder a una cuenta de servicio o actuar en nombre de una cuenta de servicio.

Los tokens del STS se diferencian de los tokens de acceso en que no corresponden a una identidad específica de Google. Además, los tokens del STS no corresponden a una identidad específica en el proveedor de identidad externo. En su lugar, un token del STS representa un conjunto de atributos. Según cuáles sean estos atributos, podrían corresponder a una o varias identidades en el proveedor de identidad externo.

Si los atributos representados por un token del STS son ambiguos o se usan de forma inadecuada, podrían permitir que las personas/entidades que actúan de mala fe falsifiquen la identidad. En la siguiente sección, se describen las prácticas recomendadas que te ayudan a brindar protección contra esas amenazas de falsificación de identidad.

No permitas que se modifiquen las asignaciones de atributos

La federación de Workload Identity usa asignaciones de atributos para seleccionar qué atributos del proveedor de identidad externo se deben incorporar a un token del STS y cómo se deben traducir los nombres de los atributos. La configuración de las asignaciones de atributos es un paso clave para configurar la relación de confianza entre el proveedor de identidad externo y Google Cloud.

Las asignaciones de atributos también son fundamentales para la seguridad del uso de la federación de Workload Identity: si otorgaste un conjunto principal o principal federado para que actúe en nombre de una cuenta de servicio y, luego, cambias la asignación de atributos, puedes cambiar qué usuarios tienen acceso a la cuenta de servicio.

Modifica las asignaciones de atributos requiere el permiso iam.googleapis.com/workloadIdentityPoolProviders.update. Las funciones que contienen este permiso incluyen las siguientes opciones:

  • Propietario (roles/owner)
  • Administrador de grupos de Workload Identity de IAM (roles/iam.workloadIdentityPoolAdmin)

Si una persona malintencionada tiene permiso para modificar las asignaciones de atributos, es posible que pueda cambiar las reglas de asignación de una manera que le permita falsificar su identidad y obtener acceso a una cuenta de servicio. A fin de evitar tales modificaciones maliciosas, asegúrate de que solo algunos usuarios con acceso de administrador tengan permiso para modificar las asignaciones de atributos.

Considera crear un proyecto de Cloud dedicado para administrar los grupos de Workload Identity a fin de limitar el riesgo de que se asigne de forma inadvertida una de estas funciones a un nivel superior de la jerarquía de recursos.

No confíes en atributos que no sean estables ni confiables

Cuando usas la federación de Workload Identity, confías en un proveedor de identidad externo para autenticar a los usuarios y enviar información precisa sobre el usuario autenticado a Google Cloud.

Un proveedor de identidad usa atributos para comunicar información sobre los usuarios autenticados. Si bien se garantiza que algunos de estos atributos sean confiables, otros pueden no serlo: por ejemplo, un proveedor de identidad externo puede incorporar un nombre de usuario y un ID del usuario en un token de ID de OpenID Connect. Ambos atributos identifican de forma única a un usuario y pueden parecer intercambiables. Sin embargo, el proveedor de identidad externo puede permitir que los usuarios cambien su nombre de usuario, a la vez que garantiza que su ID de usuario sea estable y confiable.

Si las asignaciones de atributos se basan en atributos que no son estables ni confiables, una persona/entidad que actúa de mala fe puede falsificar su identidad mediante la modificación de su perfil de usuario en el proveedor de identidad externo. Por ejemplo, pueden cambiar su nombre de usuario por el de un usuario que se borró en el proveedor de identidad externo hace poco, pero que aún tiene acceso a una cuenta de servicio en Google Cloud.

Para evitar estos ataques de falsificación de identidad, asegúrate de que las asignaciones de atributos solo dependan de los atributos que el proveedor de identidad externo garantiza que sean estables y confiables.

Proporciona protección contra amenazas de divulgación de información

Evita divulgar información confidencial en las direcciones de correo electrónico de la cuenta de servicio

Para otorgar a una cuenta de servicio acceso a un recurso en otro proyecto de Cloud, puedes agregar una vinculación de función a la política de IAM del recurso. Al igual que el recurso en sí, la política de IAM es parte del otro proyecto de Cloud y su visibilidad también la controla ese otro proyecto de Cloud.

Por lo general, la visualización de las políticas de IAM no se considera una operación con privilegios. Muchas funciones incluyen el permiso *.getIamPolicy requerido, incluida la función de visualizador básica.

Un usuario que tiene permiso para ver una política de IAM también puede ver las direcciones de correo electrónico de las principales a las que se les otorgó acceso al recurso. En el caso de las cuentas de servicio, las direcciones de correo electrónico pueden proporcionar sugerencias a las personas/entidades que actúan de mala fe.

Por ejemplo, una política de IAM puede incluir una vinculación para una cuenta de servicio con la dirección de correo electrónico jenkins@deployment-project-123.gserviceaccount.com. Para una persona/entidad que actúa de mala fe, esta dirección de correo electrónico no solo revela que hay un proyecto de Cloud con el ID deployment-project-123, sino que el proyecto de Cloud ejecuta un servidor de Jenkins. Cuando eliges un nombre más genérico, como deployer@deployment-project-123.gserviceaccount.com, evitas divulgar información sobre el tipo de software que ejecutas en deployment-project-123.

Si otorgas a una cuenta de servicio acceso a los recursos de un proyecto de Cloud que tiene un acceso menos controlado (como una zona de pruebas o un proyecto de Cloud de desarrollo), asegúrate de que la dirección de correo electrónico de la cuenta de servicio no divulgue ninguna información En particular, no divulgues información confidencial o que pueda proporcionar sugerencias a los atacantes.

Cómo brindar protección contra amenazas no repudiantes

Cada vez que observes una actividad sospechosa que afecte a uno de tus recursos en Google Cloud, los registros de auditoría de Cloud son una fuente importante de información para saber cuándo ocurrió la actividad y qué usuarios participaron.

Siempre que Cloud Audit Logging indique que una cuenta de servicio realizó la actividad, que esa información podría no ser suficiente para reconstruir la cadena completa de eventos: también debes poder averiguar qué usuario o aplicación causó que la cuenta de servicio realizara la actividad.

En esta sección, se incluyen prácticas recomendadas que pueden ayudarte a mantener un registro de auditoría que no se pueda rechazar.

Habilita los registros de acceso a los datos para las API de IAM

Los servicios como Compute Engine incluyen una sección serviceAccountDelegationInfo en los registros de auditoría de Cloud para ayudarte a identificar y comprender las situaciones de robo de identidad de las cuentas de servicio. En esta sección, se indica si se realizó el robo de identidad de la cuenta de servicio y mediante qué usuario.

No todos los servicios incluyen detalles de robo de identidad en sus registros de auditoría de Cloud. Para registrar todos los eventos de robo de identidad, también debes habilitar los registros de acceso a los datos para las siguientes API:

  • API de Identity and Access Management (IAM) en todos los proyectos de Cloud que contienen cuentas de servicio
  • API de servicio de token de seguridad en todos los proyectos de Cloud que contienen grupos de Workload Identity

Cuando habilitas estos registros, te aseguras de que se agregue una entrada a los registros de auditoría de Cloud cada vez que un usuario solicita un token de acceso o un token de ID para una cuenta de servicio.

Asegúrate de que el historial de CI/CD pueda correlacionarse con los registros de auditoría de Cloud

Los sistemas de CI/CD suelen usar las cuentas de servicio para realizar implementaciones después de que se verificó y aprobó con éxito un cambio de código para la implementación. Por lo general, los sistemas de CI/CD mantienen un historial de eventos que generaron una implementación. Este historial puede incluir los ID de las revisiones de código, las confirmaciones y las ejecuciones de canalización correspondientes, además de información sobre quién aprobó la implementación.

Si una implementación modifica algún recurso en Google Cloud, se hace un seguimiento de estos cambios en los registros de auditoría de Cloud de los recursos respectivos. Los registros de auditoría de Cloud contienen información sobre el usuario o la cuenta de servicio que inició el cambio. Sin embargo, en una implementación activada por un sistema de CI/CD, la cuenta de servicio a menudo no es suficiente para reconstruir toda la cadena de eventos que generaron el cambio.

Para establecer un registro de auditoría coherente en el sistema de CI/CD y en Google Cloud, debes asegurarte de que los registros de auditoría de Cloud se puedan correlacionar con eventos en el historial del sistema de CI/CD. Si encuentras un evento inesperado en los registros de auditoría de Cloud, puedes usar esta correlación para determinar si el sistema de CI/CD realizó el cambio, por qué se realizó y quién lo aprobó.

Las formas de establecer una correlación entre los registros de auditoría de Cloud y los eventos en el historial del sistema de CI/CD incluyen las siguientes opciones:

  • Registra las solicitudes a la API que realiza cada ejecución de canalización de CI/CD.
  • Siempre que la API muestre un ID de operación, registra el ID en los registros del sistema de CI/CD.
  • Agrega un encabezado HTTP X-Goog-Request-Reason a las solicitudes a la API y pasa el ID de la ejecución de la canalización de CI/CD. Como alternativa, incorpora la información en el encabezado User-Agent para que se capture en los registros de auditoría de Cloud.

A fin de garantizar que no sean repudiables, configura los archivos de registro y los historiales de confirmaciones para que sean inmutables y una persona/entidad que actúa de mala fe no pueda ocultar sus seguimientos de forma retroactiva.

¿Qué sigue?