Prácticas recomendadas para usar cuentas de servicio

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

Aunque las cuentas de servicio son una herramienta útil, hay varias formas de abusar de ellas:

• Elevación de privilegios: un agente pernicioso podría obtener acceso a recursos a los que no tendría acceso de otro modo suplantando la identidad de la cuenta de servicio.
• Suplantación de identidad: un agente malintencionado puede usar la suplantación de identidad de una cuenta de servicio para ocultar su identidad.
• No repudio: un agente pernicioso puede ocultar su identidad y sus acciones usando una cuenta de servicio para llevar a cabo operaciones en su nombre. En algunos casos, es posible que no se puedan rastrear estas acciones hasta el agente pernicioso.
• Divulgación de información: un agente malintencionado podría obtener información sobre tu infraestructura, aplicaciones o procesos a partir de la existencia de determinadas cuentas de servicio.

Para proteger las cuentas de servicio, ten en cuenta su doble naturaleza:

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

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

Elegir cuándo usar cuentas de servicio

No todos los casos requieren una cuenta de servicio para acceder a los servicios de Trusted Cloud, y en muchos casos se puede autenticar con un método más seguro que usar una clave de cuenta de servicio. Te recomendamos que evites usar claves de cuentas de servicio siempre que sea posible.

Cuando accedas a los servicios de Trusted Cloud by S3NS mediante la CLI de Google Cloud, las bibliotecas de cliente de Cloud, las herramientas que admiten Credenciales Predeterminadas de Aplicación (ADC) como Terraform o las solicitudes REST, usa el siguiente diagrama para elegir un método de autenticación:

Este diagrama te ayuda a responder las siguientes preguntas:

1. ¿Estás ejecutando 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í, ve a la pregunta 4.
   2. Si no es así, ve a la pregunta 2.
2. ¿Estás ejecutando código en Trusted Cloud by S3NS?
   1. Si es así, ve a la pregunta 3.
   2. Si no es así, ve a la pregunta 5.
3. ¿Ejecutas contenedores en Google Kubernetes Engine?
   1. Si es así, usa Workload Identity Federation for GKE para asociar cuentas de servicio a pods de Kubernetes.
   2. Si no es así, asigna una cuenta de servicio al recurso.

4. ¿Tu caso práctico requiere una cuenta de servicio?

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

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

Administrar cuentas de servicio

Las cuentas de servicio se diferencian de otros tipos de principales no solo en cómo se usan, sino también en cómo se deben gestionar. En las siguientes secciones se describen las prácticas recomendadas para gestionar cuentas de servicio.

Gestionar cuentas de servicio como recursos

Las cuentas de usuarios individuales se suelen gestionar de acuerdo con los procesos de incorporación, traslado y baja de una organización: cuando un empleado se incorpora, se crea una cuenta de usuario para él. Cuando cambian de departamento, su cuenta de usuario se actualiza. Cuando dejan la empresa, su cuenta de usuario se suspende o se elimina.

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

Para gestionar las cuentas de servicio de forma eficaz, no las analices de forma aislada. En su lugar, tenlos en cuenta en el contexto del recurso al que están asociados y gestiona la cuenta de servicio y el recurso asociado como una sola unidad: aplica los mismos procesos, el mismo ciclo de vida y la misma diligencia a la cuenta de servicio y al recurso asociado, y usa las mismas herramientas para gestionarlos.

Crear cuentas de servicio para un solo propósito

Compartir una misma cuenta de servicio entre varias aplicaciones puede complicar la gestión de la cuenta de servicio:

• Las aplicaciones pueden tener ciclos de vida diferentes. Si una aplicación se retira, puede que no esté claro si la cuenta de servicio también se puede retirar o si sigue siendo necesaria.
• Con el tiempo, los requisitos de acceso de las aplicaciones pueden divergir. Si las aplicaciones usan la misma cuenta de servicio, es posible que tengas que conceder acceso a la cuenta de servicio a un número cada vez mayor 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 ha realizado un cambio o ha accedido a los datos, pero no muestran el nombre de la aplicación que ha usado la cuenta de servicio. Si varias aplicaciones comparten una cuenta de servicio, es posible que no puedas rastrear la actividad hasta la aplicación correcta.

En concreto, algunos Trusted Cloud servicios, como App Engine y Compute Engine, crean una cuenta de servicio predeterminada que tiene el rol Editor (roles/editor) en el proyecto de forma 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 automáticamente la cuenta de servicio predeterminada. Aunque la cuenta de servicio predeterminada te facilita el inicio, es muy arriesgado compartir una cuenta de servicio tan potente entre varias aplicaciones.

Puedes tomar varias medidas para evitar estas complicaciones:

• Crea cuentas de servicio específicas para cada aplicación y evita usar cuentas de servicio predeterminadas.
• No utilices concesiones automáticas de roles en las cuentas de servicio predeterminadas.
• Usa las herramientas de Google para conocer el uso de las cuentas de servicio, lo que te ayudará a monitorizar el uso y evitar que las cuentas de servicio se compartan entre varias aplicaciones.

Sigue una convención de nomenclatura y documentación

Para hacer un seguimiento de la asociación entre un servicio y una aplicación o un recurso, sigue una convención de nomenclatura al crear cuentas de servicio:

• Añade un prefijo a la dirección de correo de la cuenta de servicio que identifique cómo se usa la cuenta. Por ejemplo:
  • vm- para las cuentas de servicio vinculadas a una instancia de VM.
  • wlifgke- para las cuentas de servicio que usa Workload Identity Federation para GKE.
  • wlif- para las cuentas de servicio que usa la federación de identidades de cargas de trabajo.
  • onprem- para las cuentas de servicio que usan las aplicaciones on-premise.
• Incluye el nombre de la aplicación en la dirección de correo 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 añadir una persona de contacto, enlaces a documentación relevante u otras notas.

No incluyas información ni términos sensibles en la dirección de correo de una cuenta de servicio.

Identificar e inhabilitar cuentas de servicio que no se usen

Cuando ya no se utilice una cuenta de servicio, inhabilítala. Al inhabilitar las cuentas de servicio que no se usan, reduces el riesgo de que un agente malicioso abuse de ellas para moverse lateralmente o para apropiarse de privilegios.

En el caso de las cuentas de servicio de un solo uso asociadas a un recurso concreto, como una instancia de VM, inhabilita la cuenta de servicio en cuanto se inhabilite o se elimine el recurso asociado.

Inhabilitar las cuentas de servicio que no se usen antes de eliminarlas

Si eliminas una cuenta de servicio y, después, creas otra con el mismo nombre, se le asignará una identidad diferente. Por lo tanto, ninguna de las vinculaciones de gestión de identidades y accesos originales se aplica a la nueva cuenta de servicio. Por el contrario, si inhabilitas y vuelves a habilitar una cuenta de servicio, todos los enlaces de gestión de identidades y accesos se mantienen intactos.

Para evitar que se pierdan enlaces de IAM por error, es mejor no eliminar las cuentas de servicio inmediatamente. En su lugar, inhabilita una cuenta de servicio si ya no la necesitas y elimínala solo después de que haya transcurrido un periodo determinado.

No elimines nunca las cuentas de servicio predeterminadas, como la cuenta de servicio predeterminada de App Engine o la cuenta de servicio predeterminada de Compute Engine. Estas cuentas de servicio no se pueden volver a crear sin inhabilitar y volver a habilitar la API correspondiente, lo que podría afectar a tu implementación. Si no usas las cuentas de servicio predeterminadas, inhabilítalas.

Limitar los privilegios de la cuenta de servicio

Las cuentas de servicio son principales y se les puede conceder acceso a un recurso como a cualquier otro tipo de principal. Sin embargo, las cuentas de servicio suelen tener más acceso a más recursos que otros tipos de principales. Además, a medida que añades funciones a tus aplicaciones, sus cuentas de servicio tienden a obtener más y más acceso con el tiempo. También es posible que olvides revocar el acceso que ya no es necesario.

No utilizar concesiones automáticas de roles en las cuentas de servicio predeterminadas

Algunos Trusted Cloud by S3NS servicios crean cuentas de servicio predeterminadas la primera vez que habilitas su API en un Trusted Cloud proyecto. En función de la configuración de tu política de organización, es posible que a estas cuentas de servicio se les conceda automáticamente el rol Editor (roles/editor) en tu proyecto Trusted Cloud , lo que les permite leer y modificar todos los recursos del proyecto Trusted Cloud . El rol se asigna para tu comodidad, pero no es esencial para que los servicios funcionen: para acceder a los recursos de tu Trusted Cloud proyecto Trusted Cloud ,los servicios usan agentes de servicio, no las cuentas de servicio predeterminadas.

Para evitar que se conceda automáticamente el rol Editor a las cuentas de servicio predeterminadas, habilita la restricción Inhabilitar concesiones automáticas de gestión de identidades y accesos a cuentas de servicio predeterminadas (constraints/iam.automaticIamGrantsForDefaultServiceAccounts) en tu organización. Para aplicar la restricción a varios Trusted Cloud proyectos,configúrala en la carpeta o en el nodo de la organización. Al aplicar la restricción, no se quita el rol Editor de las cuentas de servicio predeterminadas.

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

No utilices ámbitos de acceso al adjuntar una cuenta de servicio a una instancia de VM

Cuando asocias una cuenta de servicio a una instancia de VM, puedes especificar uno o varios ámbitos de acceso. Los ámbitos de acceso te permiten restringir los servicios a los que puede acceder la VM. Las restricciones se aplican además de las políticas de permiso.

Los permisos de acceso son genéricos. Por ejemplo, si usas el ámbito 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 segmentos específicos. Por lo tanto, los ámbitos de acceso no son un sustituto adecuado de las políticas de permiso pormenorizadas.

En lugar de usar ámbitos de acceso, crea una cuenta de servicio específica y usa políticas de autorización pormenorizadas para restringir los recursos a los que 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, utiliza conjuntos de principales de cuentas de servicio para asignarles roles en lugar de usar grupos personalizados.

Usar la API Service Account Credentials para elevar los privilegios de forma temporal

Algunas aplicaciones solo requieren acceso a determinados recursos en momentos concretos 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 necesite ese acceso una vez que se haya inicializado.
• Una aplicación de supervisor puede iniciar periódicamente trabajos en segundo plano en los que cada trabajo tenga requisitos de acceso diferentes.

En estos casos, usar una sola cuenta de servicio y concederle acceso a todos los recursos va en contra del principio de mínimos accesos. 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 Service Account Credentials para elevar los privilegios de forma temporal:

• Crea cuentas de servicio específicas para cada parte de la aplicación o caso práctico y concede a la cuenta de servicio acceso únicamente a los recursos necesarios.
• Crea otra cuenta de servicio que actúe como supervisor. Asigna a la cuenta de servicio supervisora el rol Creador de tokens de cuenta de servicio en las otras cuentas de servicio para que pueda solicitar tokens de acceso de corta duración para estas cuentas.
• Divide tu aplicación de forma que una parte de la aplicación actúe como intermediario de tokens y solo permite que esta parte de la aplicación use las cuentas de servicio de supervisor.
• Usa el intermediario de tokens para emitir cuentas de servicio de corta duración a las otras partes de la aplicación.

Si necesitas ayuda para crear credenciales de duración reducida, consulta el artículo Crear credenciales de duración reducida para una cuenta de servicio.

Protección frente a las amenazas de apropiación de privilegios

Una cuenta de servicio a la que no se le ha asignado ningún rol no tiene acceso a ningún recurso y, por lo general, no tiene mucho valor si no está asociada a ninguna regla de cortafuegos. Después de conceder acceso a los recursos a una cuenta de servicio, el valor de la cuenta aumenta: la cuenta de servicio te resulta más útil, pero también se convierte en un objetivo más atractivo para los ataques de escalada de privilegios.

Por ejemplo, supongamos que tienes una cuenta de servicio con acceso completo a un segmento de Cloud Storage que contiene información sensible. En esta situación, la cuenta de servicio tiene el mismo valor que el segmento de Cloud Storage. En lugar de intentar acceder directamente al contenedor, un agente malintencionado podría intentar tomar el control de la cuenta de servicio. Si ese intento se realiza con éxito, el agente malintencionado puede aumentar sus privilegios suplantando la identidad de la cuenta de servicio, lo que a su vez le da acceso a la información sensible del contenedor.

Las técnicas de elevación de privilegios que implican cuentas de servicio suelen clasificarse en estas categorías:

• Autenticación como cuenta de servicio: es posible que concedas por error a un usuario permiso 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 propio usuario, este puede autenticarse como la cuenta de servicio para aumentar sus privilegios y acceder a recursos a los que no podría acceder de otro modo.

• Usar recursos que tengan una cuenta de servicio asociada: si un usuario tiene permiso para acceder y modificar las canalizaciones de CI/CD, las instancias de VM u otros sistemas de automatización que tengan cuentas de servicio asociadas, es posible que pueda realizar acciones con las cuentas de servicio asociadas a esos recursos. Por lo tanto, aunque no tengan permiso para suplantar la identidad de la cuenta de servicio, es posible que puedan usar los permisos de la cuenta de servicio para realizar acciones que no podrían llevar a cabo por sí 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 vinculada a la instancia.

• Modificaciones de políticas de autorización, grupos o roles personalizados: un usuario que no tenga acceso a una cuenta de servicio con privilegios puede tener permiso para modificar las políticas de autorización de la cuenta de servicio, elTrusted Cloud proyecto o la carpeta que la contenga. El usuario podría ampliar una de estas políticas de permiso para concederse permiso para autenticarse (directa o indirectamente) como la cuenta de servicio.

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

Evitar que los usuarios se autentiquen como cuentas de servicio que tengan más privilegios que ellos

Al suplantar la identidad de una cuenta de servicio, un usuario obtiene acceso a algunos o a todos los recursos a los que puede acceder la cuenta de servicio. Si la cuenta de servicio tiene un acceso más amplio que el usuario, será más privilegiada que el usuario.

Conceder a un usuario permiso para suplantar la identidad de una cuenta de servicio con más privilegios puede ser una forma de permitir deliberadamente que los usuarios aumenten sus privilegios temporalmente, de forma similar a como se usa la herramienta sudo en Linux o la elevación de procesos en Windows. A menos que te encuentres en una situación en la que sea necesario elevar los privilegios de forma temporal, es mejor evitar que los usuarios suplanten la identidad de una cuenta de servicio con más privilegios.

Los usuarios también pueden obtener indirectamente los permisos de una cuenta de servicio asociándola a un recurso y, a continuación, ejecutando código en ese recurso. Ejecutar código de esta forma no es suplantación de identidad de cuentas de servicio, ya que solo implica una identidad autenticada (la de la cuenta de servicio). Sin embargo, puede dar acceso a un usuario que no lo tendría de otro modo.

Los permisos que permiten a un usuario suplantar la identidad de una cuenta de servicio o asociar una cuenta de servicio a un recurso son 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

Entre los roles que incluyen algunos de estos permisos se encuentran los siguientes:

• Propietario (roles/owner)
• Editor (roles/editor)
• Usuario de 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 cuentas de servicio (roles/iam.serviceAccountAdmin)
• Usuario de Workload Identity (roles/iam.workloadIdentityUser)
• Editor de Deployment Manager (roles/deploymentmanager.editor)
• Editor de versiones de Cloud (roles/cloudbuild.builds.editor)

Antes de asignar alguno de estos roles a un usuario, pregúntate lo siguiente:

• ¿A qué recursos dentro y fuera del proyecto actual podría acceder el usuario suplantando la cuenta de servicio? Trusted Cloud
• ¿Está justificado este nivel de acceso?
• ¿Se han implementado las protecciones suficientes para controlar en qué circunstancias puede el usuario suplantar la identidad de la cuenta de servicio?

No asignes el rol si no puedes confirmar todas las preguntas. En su lugar, puedes darle al usuario otra cuenta de servicio con menos privilegios.

Evitar que los usuarios cambien las políticas de autorización de las cuentas de servicio con más privilegios

La política de autorización de la cuenta de servicio determina qué usuarios pueden usarla o representarla. Los usuarios que tengan el permiso iam.serviceAccounts.setIamPolicy en la cuenta de servicio en cuestión pueden modificar o ampliar la política de autorización. Entre los roles que contienen ese permiso se incluyen los siguientes:

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

Los roles que incluyen el permiso iam.serviceAccounts.setIamPolicy dan a un usuario control total sobre una cuenta de servicio:

• El usuario puede concederse permiso para suplantar la identidad de la cuenta de servicio, lo que le permite acceder a los mismos recursos que la cuenta de servicio.
• El usuario puede conceder a otros usuarios el mismo nivel de acceso o uno similar a la cuenta de servicio.

Antes de asignar cualquiera de estos roles a un usuario, pregúntate a qué recursos dentro y fuera del proyecto actual podría acceder el usuario suplantando la cuenta de servicio. Trusted Cloud No permitir que un usuario cambie la política de autorización de una cuenta de servicio si esta tiene más privilegios que el usuario.

No permitir que los usuarios creen ni suban claves de cuentas de servicio

Las claves de cuenta de servicio permiten que las aplicaciones o los usuarios se autentiquen como una cuenta de servicio. A diferencia de otras formas de suplantación 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 tenga una clave de cuenta de servicio puede usarla.

El efecto neto de usar una clave de cuenta de servicio para autenticarse es similar al de la suplantación de identidad de una cuenta de servicio. Si un usuario tiene acceso a una clave de cuenta de servicio o le das permiso para crear una, el usuario puede autenticarse como la cuenta de servicio y acceder a todos los recursos a los que puede acceder la cuenta de servicio.

Para crear o subir una clave de cuenta de servicio, se necesita el permiso iam.serviceAccountKeys.create, que se incluye en los roles Administrador de claves de cuenta de servicio (roles/iam.serviceAccountKeyAdmin) y Editor (roles/editor).

Antes de asignar a un usuario un rol que incluya el permiso iam.serviceAccountKeys.create, pregúntate a qué recursos dentro y fuera del proyecto actual Trusted Cloud podría acceder el usuario suplantando la cuenta de servicio. No permitir que un usuario cree claves de cuentas de servicio que tengan más privilegios que él.

Si tu Trusted Cloud proyecto no requiere claves de cuentas de servicio, aplica las restricciones de la política de la organización Inhabilitar la creación de claves de cuentas de servicio y Inhabilitar la subida de claves de cuentas de servicio al Trusted Cloud proyecto o a la carpeta que lo contiene. Estas restricciones impiden que todos los usuarios creen y suban claves de cuentas de servicio, incluidos los que tengan el permiso iam.serviceAccountKeys.create en una cuenta de servicio.

No concedas acceso a cuentas de servicio a nivel de Trusted Cloud proyecto o carpeta

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

• La cuenta de servicio individual
• El proyecto Trusted Cloud en el que se incluye
• Una carpeta en la jerarquía del proyecto Trusted Cloud
• El nodo de organización

Gestionar el acceso a nivel de proyecto o a un nivel superior de la jerarquía de recursos puede ayudar a reducir la sobrecarga administrativa, pero también puede provocar que se concedan privilegios en exceso. Trusted Cloud Por ejemplo, si asignas a un usuario el rol Creador de tokens de cuenta de servicio en un Trusted Cloud proyecto, el usuario podrá suplantar la identidad de cualquier cuenta de servicio del Trusted Cloud proyecto. Poder suplantar la identidad de cualquier cuenta de servicio implica que el usuario puede obtener acceso a todos los recursos a los que pueden acceder esas cuentas de servicio, incluidos los recursos que no pertenezcan a ese proyecto de Trusted Cloud .

Para evitar que se concedan más permisos de los necesarios, no gestione el acceso a las cuentas de servicio a nivel deTrusted Cloud proyecto o carpeta. En su lugar, gestiona el acceso de cada cuenta de servicio de forma individual.

No ejecutes código de fuentes menos protegidas en recursos de computación que tengan asociada una cuenta de servicio con privilegios

Cuando asocias una cuenta de servicio a un recurso de computación, 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 su lugar, cualquier código que se ejecute en el recurso de computación puede acceder al servidor de metadatos y obtener un token de acceso. Este código puede incluir lo siguiente:

• El código de tu aplicación.
• Código enviado por los usuarios finales, si tu aplicación permite la evaluación de secuencias de comandos del lado del servidor.
• Código leído de un repositorio de origen remoto, si el recurso de computación forma parte de un sistema de integración continua o entrega continua.
• Secuencias de comandos de inicio y apagado alojadas en un segmento de Cloud Storage.
• Políticas de invitados distribuidas por VM Manager.

Si los usuarios envían código o se lee desde una ubicación de almacenamiento remoto, debe asegurarse de que sea de confianza y de que las ubicaciones de almacenamiento remoto estén al menos tan protegidas como la cuenta de servicio adjunta. Si una ubicación de almacenamiento remoto está menos protegida que la cuenta de servicio, un agente malintencionado podría aumentar sus privilegios. Para ello, podrían insertar código malicioso que utilice los privilegios de la cuenta de servicio en esa ubicación.

Limitar el acceso a la shell de las máquinas virtuales que tengan una cuenta de servicio privilegiada asociada

Algunos recursos de computación admiten el acceso interactivo y permiten a los usuarios obtener acceso a la shell del sistema. Por ejemplo:

• Compute Engine te permite usar SSH o RDP para iniciar sesión en 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 asociada una cuenta de servicio con privilegios, cualquier usuario con acceso a la shell del sistema puede autenticarse y acceder a los recursos como la cuenta de servicio. Para evitar que los usuarios hagan un uso inadecuado de esta función para aumentar sus privilegios, debes asegurarte de que el acceso a la shell esté al menos tan protegido como la cuenta de servicio asociada.

En el caso de las instancias de Linux, puedes hacer que el acceso SSH sea más restrictivo que el acceso a la cuenta de servicio conectada mediante OS Login. Para conectarse a una instancia de VM que tenga habilitado OS Login, un usuario no solo debe tener permiso para usar OS Login, sino que también debe tener el permiso iam.serviceAccounts.actAs en la cuenta de servicio conectada.

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: para publicar una clave SSH en los metadatos o solicitar credenciales de Windows, se necesita acceso a los metadatos de la instancia de VM y el permiso iam.serviceAccounts.actAs en la cuenta de servicio adjunta. Sin embargo, una vez que se ha publicado la clave SSH o se han obtenido las credenciales de Windows, los inicios de sesión posteriores no están sujetos a ninguna comprobación de permisos de gestión de identidades y accesos adicional.

Del mismo modo, si una instancia de VM usa un módulo de autenticación conectable de Linux personalizado para la autenticación o es miembro de un dominio de Active Directory, es posible que se permita iniciar sesión a usuarios que, de otro modo, no tendrían permiso para autenticarse como la cuenta de servicio. Para obtener más información, consulta las prácticas recomendadas para ejecutar Active Directory enTrusted Cloud.

Limitar el acceso al servidor de metadatos a usuarios y procesos concretos

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

Para limitar el acceso al servidor de metadatos a usuarios específicos, configura el cortafuegos del host del sistema operativo invitado para que solo permita a estos usuarios abrir 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 concretos.

Protegerse frente a las amenazas de divulgación de información

Evitar revelar información confidencial en las direcciones de correo de las cuentas de servicio

Para dar acceso a una cuenta de servicio a un recurso de otro Trusted Cloud proyecto, puedes añadir un enlace de rol a la política de permisos del recurso. Al igual que el propio recurso, la política de permiso forma parte del otro proyecto Trusted Cloud y su visibilidad también está controlada por ese otro proyecto Trusted Cloud .

Ver las políticas de permiso no suele considerarse una operación con privilegios. Muchos roles incluyen el permiso *.getIamPolicy necesario, incluido el rol Lector básico.

Un usuario que puede ver una política de permiso también puede ver las direcciones de correo de las entidades a las que se les ha concedido acceso al recurso. En el caso de las cuentas de servicio, las direcciones de correo pueden dar pistas a los agentes malintencionados.

Por ejemplo, una política de permiso podría incluir un enlace para una cuenta de servicio con la dirección de correo jenkins@deployment-project-123.s3ns-system.iam.gserviceaccount.com. Para un actor malintencionado, esta dirección de correo no solo revela que hay un Trusted Cloud proyecto con el ID deployment-project-123, sino también que el Trusted Cloud proyecto ejecuta un servidor Jenkins. Si eliges un nombre más genérico, como deployer@deployment-project-123.s3ns-system.iam.gserviceaccount.com, no revelarás información sobre el tipo de software que estás ejecutando en deployment-project-123.

Si das acceso a una cuenta de servicio a los recursos de un Trusted Cloud proyecto que tenga un acceso menos controlado (como un entorno de pruebas o un proyecto de desarrollo),Trusted Cloud asegúrate de que la dirección de correo de la cuenta de servicio no revele ninguna información. En concreto, no divulgues información confidencial ni datos que puedan dar pistas a los atacantes.

Protegerse frente a amenazas de no repudio

Cuando detectes actividad sospechosa que afecte a uno de tus recursos enTrusted Cloud, los registros de auditoría de Cloud serán una fuente de información importante para averiguar cuándo se produjo la actividad y qué usuarios estuvieron implicados.

Cuando los registros de auditoría de Cloud indican que una actividad la ha realizado una cuenta de servicio, es posible que esa información por sí sola no sea suficiente para reconstruir la cadena completa de eventos. En estos casos, también debes poder averiguar qué usuario o aplicación ha provocado que la cuenta de servicio realice la actividad.

En esta sección se incluyen prácticas recomendadas que pueden ayudarte a mantener una pista de auditoría irrefutable.

Usa claves de cuentas de servicio solo cuando no haya otra alternativa viable

Si no puedes usar métodos de autenticación más seguros, puede que tengas que crear una clave de cuenta de servicio para la aplicación. Sin embargo, la autenticación con una clave de cuenta de servicio introduce una amenaza de no repudio. Cloud Audit Logs crea 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 hay forma fiable de saber quién ha usado la clave. En cambio, al autenticarse como cuenta de servicio suplantando la identidad de la cuenta de servicio con las credenciales de usuario, se registra el principal que actuó como cuenta de servicio.

Te recomendamos que impidas la creación de claves de cuentas de servicio aplicando la restricción de la política de organización Inhabilitar la creación de claves de cuentas de servicio al proyecto Trusted Cloud o a la carpeta que lo contiene. Si debes usar claves de cuentas de servicio en un caso que no se puede abordar con ninguna de las alternativas recomendadas, concede una excepción a la restricción de la política, de la forma más limitada posible, y consulta las prácticas recomendadas para gestionar claves de cuentas de servicio.

Habilitar los registros de acceso a datos de las APIs de IAM

Para ayudarte a identificar y comprender los casos de suplantación de identidad de cuentas de servicio, servicios como Compute Engine incluyen una sección serviceAccountDelegationInfo en los registros de auditoría de Cloud. En esta sección se indica si se ha suplantado la cuenta de servicio y por qué usuario.

No todos los servicios incluyen detalles de suplantación de identidad en sus registros de auditoría de Cloud. Para registrar todos los eventos de suplantación de identidad, también debe habilitar los registros de acceso a datos de las siguientes APIs:

• API Gestión de Identidades y Accesos (IAM) en todos losTrusted Cloud proyectos que contengan cuentas de servicio
• API Security Token Service en todos los Trusted Cloud proyectos que contengan grupos de identidades de carga de trabajo

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

Asegurarse de que el historial de CI/CD se pueda correlacionar con los registros de auditoría de Cloud

Los sistemas de CI/CD suelen usar cuentas de servicio para realizar implementaciones después de que se haya verificado y aprobado correctamente un cambio de código. Normalmente, los sistemas de CI/CD mantienen un historial de los eventos que llevan a una implementación. Este historial puede incluir los IDs de las revisiones de código, las confirmaciones y las ejecuciones de la canalización correspondientes, así como información sobre quién aprobó la implementación.

Si una implementación modifica algún recurso en Trusted Cloud, estos cambios se registran en los registros de auditoría de Cloud de los recursos correspondientes. Los registros de auditoría de Cloud contienen información sobre el usuario o la cuenta de servicio que ha iniciado el cambio. Sin embargo, en una implementación activada por un sistema de CI/CD, la cuenta de servicio en sí suele ser insuficiente para reconstruir toda la cadena de eventos que han llevado al cambio.

Para establecer un registro de auditoría coherente en todo tu sistema de CI/CD y Trusted Cloud, debes asegurarte de que los registros de auditoría de Cloud se puedan correlacionar con los eventos del historial del sistema de CI/CD. Si detectas un evento inesperado en los registros de auditoría de Cloud, puedes usar esta correlación para determinar si el cambio lo ha realizado el sistema de integración continua y entrega continua, por qué se ha realizado y quién lo ha aprobado.

Para establecer una correlación entre los registros de auditoría de Cloud y los eventos del historial del sistema de CI/CD, puedes hacer lo siguiente:

• Registra las solicitudes a la API realizadas por cada ejecución del flujo de procesamiento de CI/CD.
• Cada vez que la API devuelva un ID de operación, registra el ID en los registros del sistema de integración continua y entrega continua.

• Añade un X-Goog-Request-Reason encabezado HTTP a las solicitudes de la API y envía el ID de la ejecución de la canalización de CI/CD. Terraform puede añadir automáticamente este encabezado si especificas un motivo de la solicitud.

  También puedes insertar la información en el encabezado User-Agent para que se registre en los registros de auditoría de Cloud.

Para ayudar a garantizar el no repudio, configura los archivos de registro y los historiales de confirmaciones de forma que sean inmutables y que un agente malintencionado no pueda ocultar sus rastros de forma retroactiva.

Crear entradas de registro personalizadas para usuarios concretos de una aplicación

Las cuentas de servicio también son útiles para las aplicaciones en las que un usuario se autentica con un esquema de autenticación personalizado y, a continuación, accede indirectamente a los recursos Trusted Cloud. Estas aplicaciones pueden confirmar que el usuario está autenticado y autorizado, y luego usar una cuenta de servicio para autenticarse en los servicios y acceder a los recursos. Trusted CloudSin embargo, Registros de auditoría de Cloud registrará que la cuenta de servicio ha accedido a un recurso, pero no qué usuario estaba usando tu aplicación.

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

Siguientes pasos

• Consulta las prácticas recomendadas para gestionar las claves de cuentas de servicio.
• Consulta nuestras prácticas recomendadas para usar cuentas de servicio en las pipelines de implementación.
• Consulta las prácticas recomendadas para usar la federación de identidades de cargas de trabajo.