Prácticas recomendadas para usar cuentas de servicio

Nota interna de Google: jpassing@ escribió esta página

Las cuentas de servicio representan a usuarios que no son humanos. Se crearon para situaciones en las que una carga de trabajo, como una aplicación personalizada, necesita acceder a recursos o realizar acciones sin la participación del usuario final.

Las cuentas de servicio se diferencian de las cuentas de usuario normales de varias maneras:

  • No tienen una contraseña y no se pueden usar para el acceso basado en un navegador.
  • Se crean y administran como un recurso que pertenece a un proyecto de Google Cloud. Por el contrario, los usuarios se administran en cuentas de Cloud Identity o de Google Workspace.
  • Son específicas de Google Cloud. Por el contrario, los usuarios administrados en Cloud Identity o Google Workspace trabajan en una variedad de productos y servicios de Google.
  • Ambos 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.

Aunque las cuentas de servicio son una herramienta útil, existen varias formas de abuso 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 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.

Para ayudar a 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.

En esta guía, se presentan prácticas recomendadas para administrar, usar y proteger las cuentas de servicio.

Elige cuándo usar las cuentas de servicio

No todos los casos requieren una cuenta de servicio para acceder a los servicios de Google Cloud, y muchas situaciones se pueden autenticar con un método más seguro que el uso de una clave de cuenta de servicio. Te recomendamos que evites usar claves de cuenta de servicio siempre que sea posible.

Cuando accedes a los servicios de Google Cloud mediante Google Cloud CLI, las bibliotecas cliente de Cloud, las herramientas que admiten las credenciales predeterminadas de la aplicación (ADC), como Terraform, o las solicitudes de REST usa el siguiente diagrama para ayudarte a elegir un método de autenticación:

Árbol de decisión para elegir el método de autenticación según el caso de uso

En este diagrama, se te guiará a través de las siguientes preguntas:

  1. ¿Ejecutas código en un entorno de desarrollo de un solo usuario, como tu propia estación de trabajo, Cloud Shell o una interfaz de escritorio virtual?
    1. Si es así, continúa con la pregunta 4.
    2. De lo contrario, continúa con la pregunta 2.
  2. ¿Ejecutas código en Google Cloud?
    1. Si es así, continúa con la pregunta 3.
    2. De lo contrario, continúa con la pregunta 5.
  3. ¿Ejecutas contenedores en Google Kubernetes Engine o GKE Enterprise?
    1. Si es así, usa la federación de identidades para cargas de trabajo para GKE a fin de conectar cuentas de servicio a los Pods de Kubernetes.
    2. De lo contrario, conecta una cuenta de servicio al recurso.

  4. ¿Tu caso de uso requiere una cuenta de servicio?

    Por ejemplo, deseas configurar la autenticación y la autorización de manera coherente para tu aplicación en todos los entornos.

    1. De lo contrario, autentica con credenciales de usuario.
    2. Si es así, usa la identidad de una cuenta de servicio con credenciales de usuario.
  5. ¿Tu carga de trabajo se autentica con un proveedor de identidad externo que admite la federación de identidades para cargas de trabajo?
    1. Si es así, configura la federación de identidades para cargas de trabajo para permitir que las aplicaciones que se ejecutan de forma local o en otros proveedores de servicios en la nube usen una cuenta de servicio.
    2. De lo contrario, crea una clave de cuenta de servicio.

Administrar cuentas de servicio

Las cuentas de servicio difieren de las cuentas de usuario normales, no solo en cómo se usan, sino también en cómo deben administrarse. En las siguientes secciones, se proporcionan prácticas recomendadas para administrar cuentas de servicio.

Recomendaciones:

Administra cuentas de servicio como recursos.
Crea cuentas de servicio de un solo propósito.
Sigue una convención de nombres y documentación.
Identifica y, luego, inhabilita cuentas de servicio sin usar.
Inhabilita las cuentas de servicio que no se usen antes de borrarlas.

Administra cuentas de servicio como recursos

Las cuentas de usuario normales, por lo general, se administran de acuerdo con los procesos joiner-mover-leaver de una organización: cuando se une un empleado, se crea una nueva cuenta de usuario para él. Cuando se cambia de departamento, su cuenta de usuario se actualiza. Y cuando abandona la empresa, su cuenta de usuario se suspende o borra.

Por el contrario, las cuentas de servicio no están asociadas con ningún empleado en particular. En su lugar, es mejor pensar en las cuentas de servicio como recursos que pertenecen a otro recurso (o forman parte de él), como una instancia de VM específica o una aplicación.

Para administrar las cuentas de servicio de manera eficaz, no las consideres de forma aislada. Por el contrario, considéralas en el contexto del recurso con el que están asociadas y administra la cuenta de servicio y su recurso asociado como una unidad: aplica los mismos procesos, el mismo ciclo de vida y la misma diligencia a la cuenta de servicio y su recurso asociado, y usa las mismas herramientas para administrarlas.

Crea cuentas de servicio de un solo propósito

Compartir una sola cuenta de servicio en varias aplicaciones puede complicar la administración de la cuenta:

  • Las aplicaciones podrían tener ciclos de vida diferentes. Si una aplicación se retira del servicio, es posible que no esté claro si la cuenta de servicio también se puede retirar o si aún es necesaria.
  • Con el tiempo, los requisitos de acceso de las aplicaciones podrían diferir. Si las aplicaciones usan la misma cuenta de servicio, es posible que debas otorgar acceso a la cuenta de servicio a una mayor cantidad de recursos, lo que, a su vez, aumenta el riesgo general.
  • Los Registros de auditoría de Cloud incluyen el nombre de la cuenta de servicio que realizó un cambio o accedió a los datos, pero no muestran el nombre de la aplicación que usó la cuenta de servicio. Si varias aplicaciones comparten una cuenta de servicio, es posible que no puedas hacer seguimiento de la actividad hasta la aplicación correcta.

En particular, algunos servicios de Google Cloud, incluidos App Engine y Compute Engine, crean una cuenta de servicio predeterminada que tiene el rol de editor (roles/editor) en el proyecto según la configuración predeterminada. Cuando creas un recurso, como una instancia de máquina virtual (VM) de Compute Engine, y no especificas una cuenta de servicio, el recurso puede usar la cuenta de servicio predeterminada de forma automática. Aunque la cuenta de servicio predeterminada te facilita comenzar, es muy riesgoso compartir una cuenta de servicio tan potente en varias aplicaciones.

Puede seguir estos pasos para evitar estas complicaciones:

Sigue una convención de nombres y documentación

Para facilitar el seguimiento de la asociación entre un servicio y una aplicación o recurso, sigue una convención de nombres cuando crees cuentas de servicio nuevas:

  • Agrega un prefijo a la dirección de correo electrónico de la cuenta de servicio que identifique cómo se usa la cuenta. Por ejemplo:
    • vm- para las cuentas de servicio conectadas a una instancia de VM
    • wlifgke- para las cuentas de servicio que usa Workload Identity Federation for GKE
    • wlif- para las cuentas de servicio que usa la federación de identidades para cargas de trabajo
    • onprem- para las cuentas de servicio que usan las aplicaciones locales
  • Incorpora el nombre de la aplicación en la dirección de correo electrónico de la cuenta de servicio, por ejemplo: vm-travelexpenses@ si la VM ejecuta una aplicación de gastos de viaje.
  • Usa el campo de descripción para agregar una persona de contacto, vínculos a la documentación relevante y otras notas.

No incorpores información sensible ni condiciones en la dirección de correo electrónico de una cuenta de servicio.

Identifica y, luego, inhabilita cuentas de servicio sin usar

Cuando ya no se use una cuenta de servicio, inhabilítala. Cuando inhabilitas las cuentas de servicio sin usar, reduces el riesgo de que estas se usen de forma inadecuada para el movimiento lateral o para la elevación de privilegios por parte de una persona o entidad que actúa de mala fe.

En el caso de las cuentas de servicio de un solo propósito asociadas con un recurso específico, como una instancia de VM, inhabilita la cuenta de servicio apenas se inhabilite o se borre el recurso asociado.

Para las cuentas de servicio que se usan con varios propósitos o se comparten entre varios recursos, puede ser más difícil identificar si la cuenta de servicio aún se utiliza. En estos casos, puedes usar el Analizador de actividad a fin de ver las actividades de autenticación más recientes para tus cuentas de servicio.

Inhabilita las cuentas de servicio que no se usen antes de borrarlas

Si borras una cuenta de servicio y, luego, creas una nueva con el mismo nombre, se asignará una identidad diferente a la cuenta de servicio nueva. Como resultado, ninguna de las vinculaciones de IAM originales se aplica a la cuenta de servicio nueva. Por el contrario, si inhabilitas y vuelves a habilitar una cuenta de servicio, todas las vinculaciones de IAM permanecen intactas.

A fin de evitar perder de forma involuntaria las vinculaciones de IAM, es mejor no borrar cuentas de servicio de inmediato. En su lugar, inhabilita una cuenta de servicio si ya no es necesaria y solo bórrala una vez transcurrido cierto período.

Nunca borres las cuentas de servicio predeterminadas, como la cuenta de servicio predeterminada de App Engine o de Compute Engine. Estas cuentas de servicio no se pueden volver a crear sin inhabilitar y volver a habilitar la API respectiva, lo que puede interrumpir la implementación existente. Si no usas las cuentas de servicio predeterminadas, inhabilítalas.

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. Sin embargo, las cuentas de servicio a menudo tienen un mayor acceso a más recursos que un usuario típico. Además, a medida que agregas funcionalidad a tus aplicaciones, sus cuentas de servicio tienden a obtener más y más acceso a lo largo del tiempo. es posible que también olvides revocar el acceso que ya no es necesario.

Recomendaciones:

No uses asignaciones de funciones automáticas para las cuentas de servicio predeterminadas.
No dependas de los niveles de acceso cuando adjuntes una cuenta de servicio a una instancia de VM.
Evita usar grupos para otorgar a las cuentas de servicio acceso a los recursos.
Evita usar la delegación de todo el dominio.
No uses cuentas de servicio para acceder a los datos del usuario sin su consentimiento.
Usa la API de credenciales de IAM para la elevación de privilegios temporales.
Usa límites de acceso a las credenciales para disminuir el permiso de los tokens de acceso.
Usar recomendaciones de funciones para identificar permisos sin usar.
Usa las estadísticas de movimiento lateral para limitar el movimiento lateral.

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. Según la configuración de la política de tu organización, es posible que a estas cuentas de servicio se les otorgue automáticamente el rol de editor (roles/editor) en tu proyecto de Google Cloud, lo que les permite leer y modificar todos los recursos en el proyecto de Google 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 Google 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 Google 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.

Si aplicas esta restricción, las cuentas de servicio predeterminadas de los proyectos nuevos no tendrán acceso a tus recursos de Google Cloud. Debes otorgar los roles adecuados a las cuentas de servicio predeterminadas para que puedan acceder a tus recursos.

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 además de las políticas de permisos.

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 permisos detalladas.

En lugar de depender de los permisos de acceso, crea una cuenta de servicio dedicada y usa políticas de permisos 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.

Una aplicación puede requerir acceso a datos sensibles o personales del usuario. Algunos ejemplos de esos datos incluyen el buzón o calendario de un usuario, los documentos almacenados en Google Drive o un conjunto de datos de BigQuery que contienen datos sensibles.

El uso de una cuenta de servicio para acceder a los datos del usuario puede ser adecuado si la aplicación realiza tareas en segundo plano sin supervisión, como indexación o escaneos de Prevención de pérdida de datos (DLP), o si el usuario final no se autenticó con una identidad de Google. En todos los demás casos en los que una aplicación actúa en nombre de un usuario final, es mejor evitar el uso de cuentas de servicio.

En lugar de usar una cuenta de servicio para acceder a los datos del usuario (posiblemente realizar una transición principal), usa el flujo de consentimiento de OAuth a fin de solicitar el consentimiento del usuario final. Luego, deja que la aplicación actúe con la identidad del usuario final. Si usas OAuth en lugar de una cuenta de servicio, ayudas a garantizar lo siguiente:

  • Los usuarios pueden revisar a qué recursos están a punto de otorgar acceso a la aplicación y pueden expresar o denegar explícitamente su consentimiento.
  • Los usuarios pueden revocar su consentimiento en su página Mi cuenta en cualquier momento.
  • No necesitas una cuenta de servicio que tenga acceso ilimitado a todos los datos del usuario.

Cuando dejas que la aplicación use credenciales de usuario final, aplazas las verificaciones de permisos en las API de Google Cloud. Este enfoque limita el riesgo de exponer accidentalmente los datos a los que el usuario no debería tener acceso debido a un error de codificación (problema de engaño de aplicación delegada).

Usa la API de Credentials de IAM para la elevación de privilegios temporales

Algunas aplicaciones solo requieren acceso a ciertos recursos en momentos específicos o en circunstancias específicas. Por ejemplo:

  • Una aplicación puede requerir acceso a los datos de configuración durante el inicio, pero puede que no lo requiera una vez que se inicialice.
  • Una aplicación de supervisión podría iniciar trabajos en segundo plano de forma periódica, en los que cada trabajo tenga diferentes requisitos de acceso.

En esas situaciones, el uso de una cuenta de servicio única y otorgarle acceso a todos los recursos implica el principio de mínimo privilegio: en cualquier momento, es probable que la aplicación tenga acceso a más recursos de los que necesita.

A fin de asegurarte de que las diferentes partes de tu aplicación solo tengan acceso a los recursos que necesitan, usa la API de Credentials de IAM para la elevación de privilegios temporales:

  • Crea cuentas de servicio dedicadas para cada parte de la aplicación o caso de uso, y solo otorga acceso a la cuenta de servicio a los recursos necesarios.
  • Crea otra cuenta de servicio que actúe como supervisor. Otorga a la cuenta de servicio de supervisor la función de Creador de tokens de cuenta de servicio en las otras cuentas de servicio, a fin de que pueda solicitar tokens de acceso de corta duración para estas cuentas.
  • Divide la aplicación para que una parte funcione como agente de tokens y solo permita que esta parte de la aplicación use las cuentas de servicio de supervisor.
  • Usa el agente de tokens para emitir cuentas de servicio de corta duración en las otras partes de la aplicación.

Si deseas obtener ayuda con la creación de credenciales de corta duración, consulta Crea credenciales de corta duración para una 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 que actúa de mala fe, pueden 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 permisos de los recursos afectados para garantizar que a una aplicación no se le otorgue más acceso del que realmente necesita.

Usa las estadísticas de movimiento lateral para limitar el movimiento lateral

El movimiento posterior es cuando una cuenta de servicio en un proyecto tiene permiso para actuar en nombre de una cuenta de servicio en otro proyecto. Por ejemplo, es posible que se haya creado una cuenta de servicio en el proyecto A, pero que tenga permisos para actuar en nombre de una cuenta de servicio en el proyecto B.

Estos permisos pueden generar una cadena de robo de identidad en todos los proyectos que les otorga a las principales acceso no deseado a los recursos. Por ejemplo, una principal podría actuar en nombre de una cuenta de servicio en el proyecto A y, luego, usarla para actuar en nombre de una cuenta de servicio en el proyecto B. Si la cuenta de servicio en el proyecto B tiene permiso para actuar en nombre de otras cuentas en otros proyectos de tu organización, la principal podría seguir usando el robo de identidad de la cuenta de servicio para moverse de un proyecto a otro, lo que le permite obtener permisos a medida que avanzan.

El recomendador proporciona estadísticas de movimiento lateral para ayudarte a mitigar este problema. Las estadísticas de movimiento posteriores identifican funciones que permiten que una cuenta de servicio en un proyecto actúe en nombre de una cuenta de servicio en otro proyecto. Si deseas obtener más información para ver y administrar las estadísticas de movimiento laterales directamente, consulta Administrar estadísticas de movimiento laterales.

Algunas estadísticas de movimiento laterales se asocian con recomendaciones de funciones. Puedes aplicar esas recomendaciones para reducir el movimiento lateral en todos tus proyectos. Si deseas obtener información para hacerlo, consulta Revisa y aplica recomendaciones.

Protégete 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:

  • Autenticación como la cuenta de servicio: Podrías otorgarle de forma involuntaria permiso al usuario para actuar en nombre de una cuenta de servicio o para crear una cuenta de servicio clave para una cuenta de servicio. Si la cuenta de servicio tiene más privilegios que el usuario, puede autenticarse como la cuenta de servicio para aumentar sus privilegios y obtener acceso a recursos a los que no podría acceder.

  • Uso de recursos que tienen una cuenta de servicio adjunta: Si un usuario tiene permiso para acceder y modificar canalizaciones de CI/CD, instancias de VM o algún otro sistema de automatización que tenga cuentas de servicio adjuntas, es posible que pueda realizar acciones con las cuentas de servicio adjuntas de esos recursos. Como resultado, a pesar de que no tienen permiso para actuar en nombre de la cuenta de servicio, es posible que aún puedan usar los permisos de la cuenta de servicio para realizar acciones que no podrían realizar ellos mismos.

    Por ejemplo, si un usuario tiene acceso SSH a una instancia de VM de Compute Engine, puede ejecutar código en la instancia para acceder a cualquier recurso al que pueda acceder la cuenta de servicio adjunta de la instancia.

  • Modificaciones de la política de permisos, del grupo o del rol personalizado: 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 permisos de la cuenta de servicio, la carpeta o el proyecto de Google Cloud que la contiene. Luego, el usuario puede extender una de estas políticas de permisos para otorgarse el permiso (directa o indirectamente) de autenticarse como 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.

Recomendaciones:

Evita permitir que los usuarios actúen en nombre de las cuentas de servicio que tienen más privilegios que ellos.
Evita permitir que los usuarios cambien las políticas de permisos de las cuentas de servicio que tienen más privilegios que los usuarios en sí.
No permitas que los usuarios creen o suban claves de cuenta de servicio.
No otorgues acceso a las cuentas de servicio a nivel de proyecto o carpeta de Google Cloud.
No ejecutes el código desde fuentes menos protegidas en recursos de procesamiento que tengan una cuenta de servicio con privilegios adjunta.
Limita el acceso de la shell a las VMs que tienen una cuenta de cuenta de servicio con privilegios adjunta.
Limita el acceso del servidor de metadatos a los usuarios y procesos seleccionados.

Evita permitir que los usuarios se autentiquen como 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 usuarios también pueden obtener indirectamente los permisos de una cuenta de servicio si la adjuntan a un recurso y, luego, ejecutan código en ese recurso. Ejecutar el código de esta manera no es usar la identidad temporal como cuenta de servicio porque solo implica una identidad autenticada (la de la cuenta de servicio). Sin embargo, puede otorgarle a un usuario acceso que no tendría de otra manera.

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

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

Los roles 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 Google 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 permisos de cuentas de servicio con más privilegios

La política de permisos 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 permisos. 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 Google 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 permisos 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 al efecto de identidad temporal como cuenta de servicio. Si un usuario tiene acceso a una clave de cuenta de servicio o le das permiso para crear una clave de cuenta de servicio nueva, el usuario puede autenticarse como 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 Google 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 Google 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 Google 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 Google 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 Google Cloud adjunto
  • Una carpeta en el principal del proyecto de Google Cloud
  • El nodo de la organización

Administrar el acceso a nivel de proyecto de Google 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 Google Cloud, el usuario puede actuar en nombre de cualquier cuenta de servicio en el proyecto de Google 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 Google Cloud.

Para evitar este exceso de otorgamiento, no administres el acceso a las cuentas de servicio a nivel de proyecto o carpeta de Google 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 se autentique como 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 autenticarse y acceder a los recursos como la cuenta de servicio. 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 autenticar como la cuenta de servicio de otra manera puedan acceder. Para obtener más información, consulta Prácticas recomendadas para ejecutar Active Directory en Google Cloud.

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 el rol de usuario de túnel protegido con IAP (roles/iap.tunnelResourceAccessor) a los usuarios que deben poder autenticar como 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.

Protégete contra las amenazas de divulgación de información

Recomendaciones:

Evita divulgar información confidencial en las direcciones de correo electrónico de las cuentas de servicio.

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 Google Cloud, puedes agregar una vinculación de rol a la política de permisos del recurso. Al igual que el recurso en sí, la política de permisos es parte del otro proyecto de Google Cloud y su visibilidad también la controla ese otro proyecto de Google Cloud.

Por lo general, la visualización de las políticas de permisos no se considera una operación con privilegios. Muchos roles incluyen el permiso *.getIamPolicy requerido, incluido el rol básico de visualizador.

Un usuario que puede ver una política de permisos 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 permisos puede incluir una vinculación para una cuenta de servicio con la dirección de correo electrónico jenkins@deployment-project-123.iam.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 Google Cloud con el ID deployment-project-123, sino que el proyecto de Google Cloud ejecuta un servidor de Jenkins. Cuando eliges un nombre más genérico, como deployer@deployment-project-123.iam.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 Google Cloud que tiene un acceso menos controlado (como una zona de pruebas o un proyecto de Google 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.

Protégete contra amenazas de no repudio

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.

Recomendaciones:

Usa las claves de cuenta de servicio solo cuando no haya una alternativa viable.
Habilita los registros de acceso a los datos para las APIs de IAM.
Asegúrate de que el historial de CI/CD pueda correlacionarse con los registros de auditoría de Cloud.
Crea entradas de registro personalizadas para los usuarios individuales de una aplicación.

Usa las claves de las cuentas de servicio solo cuando no haya una alternativa viable

Si no puedes usar métodos de autenticación más seguros, es posible que debas crear una clave de cuenta de servicio para la aplicación. Sin embargo, la autenticación con una clave de cuenta de servicio presenta una amenaza de no repudio. Los registros de auditoría de Cloud crean un registro cuando una cuenta de servicio modifica un recurso, pero si la cuenta de servicio se autentica con una clave de cuenta de servicio, no existe una forma confiable de saber quién usó la clave. En comparación, la autenticación como una cuenta de servicio mediante el uso de la identidad de la cuenta de servicio con credenciales de usuario registra la principal que actuó como la cuenta de servicio.

Recomendamos evitar la creación de claves de cuentas de servicio mediante la restricción de la política de la organización Inhabilitar la creación de claves de cuentas de servicio en el proyecto de Google Cloud o en la carpeta que las contiene. Si debes usar claves de cuenta de servicio para una situación que no se puede abordar con ninguna de las alternativas recomendadas, otorga una excepción a la restricción de la política, tan limitada como sea posible, y revisa las prácticas recomendadas para administrar claves de cuentas de servicio.

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 Google Cloud que contienen cuentas de servicio
  • API de servicio de token de seguridad en todos los proyectos de Google 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. Terraform puede agregar automáticamente este encabezado si especificas un motivo de solicitud.

    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.

Crea entradas de registro personalizadas para usuarios individuales de una aplicación

Las cuentas de servicio también son útiles para aplicaciones en las que un usuario se autentica con un esquema de autenticación personalizado y, luego, accede a los recursos de Google Cloud de forma indirecta. Estas aplicaciones pueden confirmar que el usuario está autenticado y autorizado y, luego, usar una cuenta de servicio para autenticarse en los servicios de Google Cloud y acceder a los recursos. Sin embargo, los registros de auditoría de Cloud registrarán que la cuenta de servicio accedió a un recurso, no qué usuario usó tu aplicación.

Para ayudar a rastrear ese acceso hasta el usuario, diseña la lógica de la aplicación a fin de escribir una entrada de registro personalizada cada vez que un usuario acceda a un recurso y correlacionar las entradas de registro personalizadas con los registros de auditoría de Cloud.

¿Qué sigue?