Prácticas recomendadas para usar cuentas de servicio

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.

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 Cloud de Confiance, 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 Cloud de Confiance by S3NS servicios con 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:

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 Cloud de Confiance by S3NS?
   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?
   1. Si es así, usa la federación de identidades para cargas de trabajo para GKE para 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 otros tipos de principales, 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.

Administra cuentas de servicio como recursos

Las cuentas de usuarios individuales suelen administrarse 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 Cloud de Confiance , 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:

• Crea cuentas de servicio dedicadas para cada aplicación y evita usar cuentas de servicio predeterminadas.
• No uses asignaciones de funciones automáticas para las cuentas de servicio predeterminadas.
• Usa las herramientas de Google para comprender el uso de la cuenta de servicio, que puede ayudarte a supervisar el uso y evitar que las cuentas de servicio se compartan entre varias aplicaciones.

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.

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.

Para 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. Si esperas para borrar la cuenta de servicio, te aseguras de poder quitarla de forma segura sin afectar ninguna de tus vinculaciones de IAM.

Puedes borrar las cuentas de servicio predeterminadas, como la cuenta de servicio predeterminada de App Engine o la cuenta de servicio predeterminada de Compute Engine. Sin embargo, ten en cuenta lo siguiente cuando decidas si borrar una cuenta de servicio predeterminada:

• Cuando borras una cuenta de servicio predeterminada, mejoras la seguridad de tu implementación. Sin embargo, sin una cuenta de servicio predeterminada, el servicio correspondiente no puede implementar automáticamente trabajos que accedan a otrosCloud de Confiance , a menos que configures manualmente una cuenta de servicio nueva y le otorgues los roles adecuados.
• Para volver a crear las cuentas de servicio predeterminadas, debes inhabilitar y volver a habilitar la API respectiva, lo que podría interrumpir tu implementación existente. Si no usas las cuentas de servicio predeterminadas, te recomendamos que las inhabilites.

Antes de borrar una cuenta de servicio predeterminada, te recomendamos que verifiques si la usas en tu implementación. Si deseas obtener instrucciones para ver el uso de una cuenta de servicio en particular, consulta Consulta las métricas de uso de una sola cuenta de servicio.

Limita los privilegios de la cuenta de servicio

Las cuentas de servicio son principales y se les puede otorgar acceso a un recurso como a cualquier otro tipo de principal. Sin embargo, las cuentas de servicio a menudo tienen un mayor acceso a más recursos que otros tipos de principales. 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.

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

Algunos Cloud de Confiance by S3NS servicios crean cuentas de servicio predeterminadas cuando habilitas por primera vez su API en un proyecto Cloud de Confiance . Según la configuración de la política de la 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 Cloud de Confiance , lo que les permite leer y modificar todos los recursos en el proyecto de Cloud de Confiance . La función se otorga para tu comodidad, pero no es esencial que los servicios funcionen: Para acceder a los recursos en tu proyecto de Cloud de Confiance ,los servicios de Cloud de Confiance usan agentes de servicio, 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 de Confiance , 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 Cloud de Confiance . 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.

Si todas las cuentas de servicio actuales y futuras de un proyecto, una carpeta o una organización específicos comparten requisitos, usa conjuntos de principales de cuentas de servicio para otorgarles roles en lugar de usar grupos personalizados.

Usa la API de Service Account Credentials 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 privilegio mínimo. Esto se debe a que, en cualquier momento, es probable que la aplicación tenga acceso a más recursos de los que realmente necesita.

Para asegurarte de que las diferentes partes de tu aplicación solo tengan acceso a los recursos que necesitan, usa la API de Service Account Credentials 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.

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 suplantando la identidad de la cuenta de servicio, lo 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, este 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 elCloud de Confiance proyecto 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.

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 adjuntándola a un recurso y, luego, ejecutando 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 Cloud de Confiance actual 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 Cloud de Confiance actual 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 puede acceder 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 rol que incluya el permiso iam.serviceAccountKeys.create a un usuario, pregúntate a qué recursos dentro y fuera del proyecto actual deCloud de Confiance 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 Cloud de Confiance 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 Cloud de Confiance o la carpeta adjunta. Estas restricciones impiden que todos los usuarios creen y suban claves de cuenta de servicio, incluso aquellos con el permiso iam.serviceAccountKeys.create en una cuenta de servicio.

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

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 Cloud de Confiance adjunto
• Una carpeta en el principal del proyecto Cloud de Confiance
• El nodo de la organización

Administrar el acceso a nivel de Cloud de Confiance proyecto 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 el rol de creador de tokens de cuenta de servicio en un proyecto Cloud de Confiance , el usuario puede suplantar la identidad de cualquier cuenta de servicio en el proyecto Cloud de Confiance . La posibilidad de suplantar 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 de Confiance .

Para evitar este exceso de otorgamiento, no administres el acceso a las cuentas de servicio a nivel deCloud de Confiance proyecto o carpeta. 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, los procesos que se ejecutan en ese recurso pueden usar el servidor de metadatos para 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 las prácticas recomendadas para ejecutar Active Directory enCloud de Confiance.

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

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 de Confiance , 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 Cloud de Confiance y su visibilidad también la controla ese otro proyecto Cloud de Confiance .

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.s3ns.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 Cloud de Confiance con el ID deployment-project-123, sino que el proyecto Cloud de Confiance ejecuta un servidor de Jenkins. Cuando eliges un nombre más genérico, como deployer@deployment-project-123.s3ns.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 Cloud de Confiance que tiene un acceso menos controlado (como una zona de pruebas o un proyecto de desarrolloCloud de Confiance ), 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 enCloud de Confiance, 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 los registros de auditoría de Cloud indiquen que una cuenta de servicio realizó la actividad, es posible que esa información no sea suficiente para reconstruir la cadena completa de eventos. En estos casos, 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.

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 aplicando la restricción de la política de la organización Inhabilitar la creación de claves de cuentas de servicio al proyecto Cloud de Confiance o a la carpeta que lo 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 deCloud de Confiance que contienen cuentas de servicio
• API de Security Token Service en todos los proyectos de Cloud de Confiance que contienen grupos de identidades para cargas de trabajo

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 Cloud de Confiance, 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 Cloud de Confiance, 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 Cloud de Confiancede 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 Cloud de Confiancey 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?

• Comprende las prácticas recomendadas para administrar claves de cuentas de servicio.
• Revisa nuestras prácticas recomendadas para usar cuentas de servicio en las canalizaciones de implementación.
• Obtén más información sobre las prácticas recomendadas para usar la federación de identidades para cargas de trabajo.