Prácticas recomendadas para gestionar claves de cuentas de servicio

A diferencia de las cuentas de usuario, las cuentas de servicio no tienen contraseñas. En su lugar, las cuentas de servicio usan pares de claves RSA para la autenticación. Si conoces la clave privada del par de claves de una cuenta de servicio, puedes usarla para crear un token de portador JWT y, a continuación, usarlo para solicitar un token de acceso. El token de acceso resultante refleja la identidad de la cuenta de servicio y puedes usarlo para interactuar con las APIs deTrusted Cloud by S3NS en nombre de la cuenta de servicio.

Como la clave privada te permite autenticarte como la cuenta de servicio, tener acceso a ella es como conocer la contraseña de un usuario. La clave privada se conoce como clave de cuenta de servicio. Los pares de claves que utilizan las cuentas de servicio se dividen en dos categorías: gestionadas por Google y gestionadas por el usuario.

Las claves de las cuentas de servicio pueden suponer un riesgo para la seguridad si no se gestionan con cuidado. Siempre que sea posible, deberías elegir una alternativa más segura para la autenticación. Las principales amenazas relacionadas con las claves de cuenta de servicio son las siguientes:

• Fugas de credenciales: las claves de cuentas de servicio pueden acabar por error en lugares donde no deberían almacenarse. Un agente malicioso puede usar una clave de cuenta de servicio filtrada para autenticarse y acceder a tu entorno.
• Escalada de privilegios: si un agente pernicioso obtiene acceso a una clave de cuenta de servicio poco segura, puede usarla para aumentar sus privilegios.
• Divulgación de información: las claves de cuentas de servicio pueden revelar metadatos confidenciales por error.
• No repudio: al autenticarse mediante una clave de cuenta de servicio y permitir que la cuenta de servicio lleve a cabo operaciones en su nombre, un agente malintencionado podría ocultar su identidad y sus acciones.
• Configuraciones de credenciales maliciosas: un agente malicioso podría proporcionar una configuración de credenciales maliciosa para eludir tus defensas de seguridad.

La mejor forma de mitigar estas amenazas es evitar las claves de cuenta de servicio gestionadas por el usuario y usar otros métodos para autenticar las cuentas de servicio siempre que sea posible. También puedes usar condiciones de gestión de identidades y accesos y Controles de Servicio de VPC para restringir a qué recursos se puede acceder con una cuenta de servicio vulnerada.

En los casos en los que no puedas usar alternativas más seguras a las claves de cuentas de servicio, esta guía presenta prácticas recomendadas para gestionar, usar y proteger las claves de cuentas de servicio.

Protección contra la filtración de credenciales

Al igual que los nombres de usuario y las contraseñas, las claves de cuenta de servicio son un tipo de credencial. Si un usuario puede acceder a una clave de cuenta de servicio válida, puede usarla para autenticarse y acceder a los recursos a los que se le haya concedido acceso a la cuenta de servicio correspondiente.

Para los agentes perniciosos, las claves de cuenta de servicio pueden ser incluso más valiosas que una contraseña filtrada. Es poco probable que se pueda iniciar sesión con una contraseña filtrada si la cuenta de usuario se ha configurado para usar la verificación en dos pasos y las verificaciones de inicio de sesión. Por el contrario, es probable que la autenticación mediante una clave de cuenta de servicio filtrada se realice correctamente, ya que las cuentas de servicio no están sujetas a ninguna verificación de inicio de sesión adicional.

Los agentes perniciosos pueden buscar claves de cuentas de servicio en varios lugares, entre los que se incluyen los siguientes:

• Repositorios de código fuente de proyectos de software libre
• Segmentos públicos de Cloud Storage
• Volcado de datos públicos de servicios vulnerados

Además de las ubicaciones públicas, los agentes perniciosos pueden buscar claves de cuentas de servicio en ubicaciones privadas que hayan vulnerado. Estos son algunos ejemplos:

• Bandejas de entrada de correo electrónico
• Sistemas de archivos compartidos
• Almacenamiento de copias de seguridad
• Directorios del sistema de archivos temporales

Una forma eficaz de reducir el riesgo de que se filtren claves de cuentas de servicio es disminuir el número de claves en circulación y desincentivar la creación de nuevas claves. En las secciones siguientes se describe cómo puedes limitar el número de claves de cuentas de servicio en circulación y qué otras medidas pueden ayudarte a limitar el riesgo de que se filtren cuentas de servicio.

Ofrecer alternativas a la creación de claves de cuentas de servicio

Asegúrate de que los usuarios de tu organización conozcan las alternativas y puedan justificar el riesgo adicional y la sobrecarga de gestión que supone usar una clave de cuenta de servicio:

• Informa a tus desarrolladores sobre alternativas más seguras a las claves de cuentas de servicio
• Establece un proceso para ayudar a los desarrolladores a decidir qué método de autenticación es el adecuado para su caso práctico antes de crear una clave de cuenta de servicio.
• Usa restricciones de políticas de organización para evitar que se creen claves de cuentas de servicio y permite excepciones solo en proyectos que hayan demostrado que no pueden usar una alternativa más segura.

Usar restricciones de política de organización para limitar los proyectos que pueden crear claves de cuenta de servicio

Teniendo en cuenta las alternativas más seguras a las claves de cuentas de servicio, es mejor considerar el uso de estas claves como una excepción y no como la norma.

Para evitar que se usen claves de cuentas de servicio innecesarias, utiliza restricciones de políticas de la organización:

• En la raíz de la jerarquía de recursos de tu organización, aplica las restricciones Inhabilitar la creación de claves de cuentas de servicio y Inhabilitar la subida de claves de cuentas de servicio para establecer un valor predeterminado en el que no se permitan las claves de cuentas de servicio.

• Cuando sea necesario, anula una de las restricciones de los proyectos seleccionados para volver a habilitar la creación o la subida de claves de cuentas de servicio.

Para modificar las restricciones de las políticas de organización, se necesita el permiso orgpolicy.policy.set. Como ni el rol de propietario (roles/owner) ni el de editor (roles/editor) incluyen este permiso, las restricciones también pueden ser eficaces en entornos que no sean de producción en los que algunas entidades principales tengan acceso de propietario o de editor a los proyectos.

No dejes claves de cuentas de servicio en ubicaciones temporales

Cuando creas una clave de cuenta de servicio mediante la consola Trusted Cloud , la mayoría de los navegadores descargan inmediatamente la nueva clave y la guardan en una carpeta de descargas de tu ordenador. Debes mover la clave inmediatamente a la ubicación donde quieras almacenarla. Asegúrate de no dejar una copia por error en la carpeta de descargas o en la papelera de reciclaje de tu ordenador.

Para reducir el riesgo de dejar copias de claves de cuentas de servicio por error en ubicaciones temporales, usa la CLI de Google Cloud. El comando gcloud iam service-accounts keys create te permite escribir el archivo de claves de la cuenta de servicio directamente en la ubicación que necesites. Además, en la mayoría de los sistemas operativos, la CLI de gcloud ajusta automáticamente los permisos de los archivos para que solo tú puedas acceder a ellos.

No compartas claves de cuentas de servicio entre usuarios

Cuando implementas una aplicación que requiere una clave de cuenta de servicio, es posible que no tengas permiso para crearla tú mismo. En su lugar, es posible que tengas que pedirle a otra persona que cree una clave de cuenta de servicio por ti.

En los casos en los que varios usuarios participan en la creación y la implementación de una clave de cuenta de servicio, aumenta el riesgo de que se conserven copias de la clave en buzones, historiales de chat u otras ubicaciones. Cuando sea necesario transferir la propiedad entre usuarios, puede ser más seguro subir una clave de cuenta de servicio:

1. Como usuario que implementa la aplicación, crea un certificado autofirmado que use un par de claves RSA de 2048 bits en la máquina de destino. Para crear el certificado, puedes usar openssl, certutil, New-SelfSignedCertificate u otras herramientas del sistema operativo.
2. Envía el archivo de certificado al usuario que tenga permiso para subir el certificado y mantén la clave privada en el equipo de destino. Cuando envíes el certificado, asegúrate de que no se pueda sustituir ni manipular, pero no es necesario que lo mantengas confidencial.
3. Como usuario que tiene los permisos necesarios para gestionar las claves de cuentas de servicio, sube el certificado para asociarlo a una cuenta de servicio.

Si sigues este proceso, no tendrás que transferir la clave privada y solo intercambiarás información pública entre los usuarios.

No envíes claves de cuentas de servicio a repositorios de código fuente

Las claves de cuentas de servicio son credenciales y deben protegerse frente al acceso no autorizado. Si envías una clave de cuenta de servicio a un repositorio de código fuente, aumenta el riesgo de que la clave sea accesible para usuarios no autorizados y agentes malintencionados:

• Los agentes malintencionados pueden analizar el código fuente de repositorios de código fuente públicos para buscar claves filtradas.
• En el futuro, puede que decidas convertir un repositorio de origen privado en público sin comprobar primero si contiene claves.
• Otros miembros del equipo pueden almacenar copias del código fuente en su estación de trabajo.

Cuando trabajes en código que utilice una clave de cuenta de servicio, almacénala siempre por separado del código fuente para reducir el riesgo de enviar la clave al repositorio de origen por error. En muchos casos, puedes reducir aún más este riesgo si no usas claves de cuentas de servicio durante el desarrollo y utilizas tus credenciales personales en lugar de claves de cuentas de servicio.

Además, configura tu sistema de control de versiones para que detecte los envíos accidentales de claves de cuentas de servicio:

• Si usas Cloud Source Repositories, habilita la detección de claves para bloquear las operaciones git push que contengan claves privadas y para enviar notificaciones a los usuarios.
• Si usas GitHub, habilita la detección de secretos en tus repositorios.
• Si tu sistema de gestión de control de versiones no admite el análisis automático, usa una herramienta de código abierto como truffleHog para analizar tu código fuente en busca de secretos mediante un hook pre-commit, añadiendo un paso a la canalización de integración continua o ambas opciones.

No insertes claves de cuentas de servicio en archivos binarios de programas

Las claves de cuentas de servicio son cadenas que siguen un patrón determinado y se pueden identificar aunque estén insertadas en otros archivos o binarios. Si un agente malintencionado tiene acceso al archivo binario, puede extraer cualquier clave de cuenta de servicio insertada en él.

Los archivos binarios de los programas de las aplicaciones del lado del servidor se pueden alojar en repositorios de artefactos o se pueden copiar en las estaciones de trabajo de los desarrolladores con fines de depuración. Mantener las claves de cuenta de servicio separadas de los archivos binarios del programa ayuda a asegurar que un usuario que puede acceder al archivo binario no obtenga acceso implícito a las credenciales de la cuenta de servicio.

• En el caso de las aplicaciones del lado del cliente, como herramientas, programas de escritorio o aplicaciones móviles, no utilices cuentas de servicio. En su lugar, permite que los usuarios se autentiquen con sus propias credenciales.
• En el caso de las aplicaciones del lado del servidor, no insertes claves de cuentas de servicio en el archivo binario. En su lugar, mantén las claves separadas del archivo binario de la aplicación.

Usar métricas para identificar claves de cuentas de servicio sin usar

Para minimizar el número de claves de cuentas de servicio válidas en circulación, lo mejor es inhabilitar las claves en cuanto ya no se necesiten y, después, eliminarlas cuando tengas la certeza de que ya no se van a usar.

Si no sabes con certeza si una clave sigue en uso, puedes comprobar su uso monitorizando sus métricas de autenticación. Si monitorizas la métrica Eventos de autenticación de claves, puedes averiguar cuándo se usó por última vez una clave de cuenta de servicio y con qué frecuencia se usó para autenticar una cuenta de servicio.

Rota las claves de las cuentas de servicio para reducir el riesgo de seguridad que provocan las claves filtradas

Aunque puedes reducir la probabilidad de que se filtre accidentalmente una clave de cuenta de servicio, es difícil eliminar el riesgo por completo.

La rotación de claves es el proceso de sustituir las claves que ya tienes por otras nuevas y, a continuación, invalidar las claves sustituidas. Te recomendamos que rotes periódicamente todas las claves que gestionas, incluidas las de tus cuentas de servicio.

Rotar las claves de cuentas de servicio puede ayudar a reducir el riesgo que suponen las claves filtradas o robadas. Si se filtra una clave, los agentes perniciosos pueden tardar días o semanas en descubrirla. Si rotas las claves de tu cuenta de servicio con regularidad, es más probable que las claves filtradas no sean válidas cuando un agente malintencionado las obtenga.

Tener un proceso establecido para rotar las claves de cuenta de servicio también te ayuda a actuar rápidamente si sospechas que una clave de cuenta de servicio se ha visto comprometida.

Si has generado el par de claves pública y privada, has almacenado la clave privada en un módulo de seguridad de hardware (HSM) y has subido la clave pública a Trusted Cloud, puede que no tengas que rotar la clave con regularidad. En su lugar, puedes rotar la clave si crees que se ha podido vulnerar.

Usar tiempos de vencimiento para que las claves caduquen automáticamente

De forma predeterminada, las claves de cuenta de servicio que creas y descargas desde IAM no tienen fecha de vencimiento y siguen siendo válidas hasta que las eliminas. Si defines un tiempo de vencimiento para las claves de cuentas de servicio, puedes limitar el riesgo de seguridad, ya que se reduce el tiempo de vida de la credencial persistente. Sin embargo, hay otros riesgos asociados a la configuración de tiempos de vencimiento. Por ejemplo, si se configura un tiempo de vencimiento, las cargas de trabajo pueden fallar cuando caduquen sus claves.

Usa tiempos de vencimiento cuando necesites acceso temporal a un sistema que requiera una clave de cuenta de servicio. Por ejemplo, usa tiempos de vencimiento cuando hagas lo siguiente:

• Desarrollar código en un entorno que no es de producción para una aplicación que solo puede autenticarse con claves de cuentas de servicio
• Usar una herramienta de terceros que solo pueda autenticarse con claves de cuentas de servicio

No utilice tiempos de vencimiento en los siguientes casos:

• Cargas de trabajo de producción. En producción, una clave de cuenta de servicio caducada podría provocar una interrupción accidental. En su lugar, usa claves que no caduquen y gestiona su ciclo de vida con la rotación de claves.
• Cargas de trabajo de no producción que necesitan acceso permanente, como un flujo de integración continua (CI).
• Sistemas de rotación de claves que impiden que se use una clave después de un periodo especificado. Para obtener información sobre las estrategias de rotación de claves recomendadas, consulta Rotación de claves de cuentas de servicio.

Para limitar la validez de las claves de cuenta de servicio, puedes configurar un tiempo de vencimiento para las claves que crees en tu proyecto, carpeta u organización. El tiempo de vencimiento no se aplica a las claves que ya existen.

También puedes subir una clave de cuenta de servicio y especificar una fecha de Validez en el archivo del certificado X.509. Una vez que haya pasado la fecha de vencimiento, la clave no se podrá usar para la autenticación. Sin embargo, seguirá asociada a la cuenta de servicio hasta que la elimines.

Usar restricciones de políticas de organización para inhabilitar automáticamente las claves filtradas

Aunque sigas todas las prácticas recomendadas para las claves de cuentas de servicio, es posible que se filtren.

Para gestionar las credenciales filtradas, asegúrate de que la restricción Service Account Key Exposure Response esté definida como DISABLE_KEY. Si asignas este valor a la restricción, Trusted Cloud by S3NS inhabilitará automáticamente las claves filtradas que detecte.

Si se inhabilita una clave porque se ha filtrado, se añadirán los siguientes campos a los metadatos de la clave:

• "disable_reason": "SERVICE_ACCOUNT_KEY_DISABLE_REASON_EXPOSED": indica que la clave se ha inhabilitado porque se ha expuesto.
• "extended_status": "SERVICE_ACCOUNT_KEY_EXTENDED_STATUS_KEY_EXPOSED"": indica que la clave se expuso públicamente en algún momento. Este valor se mantiene incluso si vuelves a habilitar la clave.
• "extended_status_message": "LINK_TO_EXPOSURE": si está disponible, los metadatos contienen un enlace al lugar donde se detectó la clave, que puedes usar para corregir el problema.

Estas claves se pueden volver a habilitar si es necesario para mitigar una interrupción. Sin embargo, te recomendamos que los inhabilites de nuevo lo antes posible, ya que las claves expuestas públicamente suponen un riesgo para la seguridad, aunque se haya eliminado la exposición inicial.

Para obtener información sobre otras prácticas recomendadas para gestionar credenciales vulneradas, consulta el artículo Gestionar credenciales Trusted Cloud vulneradas.

Protección contra la apropiación de privilegios

Si las claves están menos protegidas que los recursos a los que conceden acceso, pueden producirse ataques de elevación de privilegios.

Por ejemplo, supongamos que un agente malicioso ya ha conseguido acceder a tu entorno y ahora intenta acceder a determinados recursos de Trusted Cloud . Es posible que sigan sin tener los permisos necesarios para acceder a estos recursos, pero sus privilegios pueden ser suficientes para acceder a una clave de cuenta de servicio almacenada en una máquina virtual, un recurso compartido de archivos u otra ubicación menos segura. Al autenticarse con la clave de la cuenta de servicio, el agente malintencionado puede asumir la identidad de la cuenta de servicio. La cuenta de servicio puede permitir que el agente pernicioso acceda a recursos a los que antes no tenía acceso, lo que aumenta sus privilegios.

Como una clave de cuenta de servicio concede acceso indirecto a los recursos de Trusted Cloud, debes considerar que la clave en sí tiene el mismo valor y merece la misma protección que los recursos.

En las siguientes secciones se describen las prácticas recomendadas para proteger las claves de cuentas de servicio y reducir el riesgo de acceso no autorizado y la consiguiente elevación de privilegios.

Evita almacenar claves en un sistema de archivos

Las claves de cuenta de servicio creadas con la consola de Trusted Cloud o la CLI de gcloud son archivos JSON. Puedes copiar estos archivos en el sistema de archivos del ordenador en el que se necesiten. Sin embargo, almacenar claves de cuentas de servicio como archivos en un sistema de archivos puede exponerte a varios riesgos, entre los que se incluyen los siguientes:

• Algunos sistemas de archivos, como NTFS, usan permisos heredados de forma predeterminada. Si no se inhabilita, un permiso añadido a una carpeta superior puede provocar que un archivo clave sea más accesible y visible para usuarios no autorizados.
• En un entorno virtualizado, los agentes maliciosos podrían poner en riesgo la seguridad del sistema de archivos accediendo al disco virtual subyacente.
• El acceso al sistema de archivos y los cambios en los permisos no suelen registrarse en los registros de auditoría. Si los permisos de los archivos se cambian por error y la clave se hace visible para usuarios no autorizados, puede ser difícil analizar cuándo y quién hizo estos cambios.
• Los archivos se pueden copiar fácilmente y, por lo tanto, se pueden extraer si un agente malintencionado obtiene acceso.

Siempre que sea posible, evita almacenar claves de cuentas de servicio en un sistema de archivos. Si no puedes evitar almacenar claves en el disco, asegúrate de restringir el acceso al archivo de claves, configurar la auditoría de acceso a archivos y cifrar el disco subyacente.

Usar un HSM o un TPM para almacenar claves

Cuando creas una clave de cuenta de servicio mediante la Trusted Cloud consola o la CLI de gcloud, Trusted Cloud genera la clave privada y te la muestra. Muchos de los riesgos de seguridad asociados a las claves de cuenta de servicio se deben a que la clave privada está disponible, de forma temporal o permanente, en texto sin formato y, por lo tanto, puede ser difícil de proteger.

En lugar de dejar que Trusted Cloud genere un par de claves, puedes usar un módulo de seguridad de hardware (HSM) o un módulo de plataforma de confianza (TPM) para crear y gestionar claves:

1. Usa un HSM o un TPM para generar un par de claves RSA.
2. Usa el par de claves para crear un certificado autofirmado.
3. Sube el certificado como clave de cuenta de servicio.
4. Permite que la aplicación use la API de firma del HSM o TPM para firmar el JWT y autenticar la cuenta de servicio.

Un HSM o un TPM te permiten usar una clave privada sin revelar nunca la clave en texto sin formato. Por lo tanto, usar un HSM o un TPM para gestionar las claves de cuentas de servicio te ayuda a aplicar el control de acceso y, al mismo tiempo, a reducir el riesgo de que las claves se copien en otros sistemas.

Algunas plataformas proporcionan abstracciones que te permiten aprovechar una TPM sin tener que interactuar directamente con ella. Por ejemplo, Windows te permite gestionar claves protegidas por TPM mediante la API CryptoNG en combinación con Microsoft Platform Crypto Provider.

Las claves de cuenta de servicio gestionadas por un TPM son únicas para una máquina física o virtual. Puedes permitir que varios equipos compartan una cuenta de servicio asociando la clave de cada equipo a una cuenta de servicio común.

Usar un almacén de claves basado en software

En los casos en los que no sea viable usar un almacén de claves basado en hardware, utiliza un almacén de claves basado en software para gestionar las claves de las cuentas de servicio. Al igual que las opciones basadas en hardware, un almacén de claves basado en software permite que los usuarios o las aplicaciones usen claves de cuenta de servicio sin revelar la clave privada. Las soluciones de almacén de claves basadas en software pueden ayudarte a controlar el acceso a las claves de forma pormenorizada y también pueden asegurar que se registre cada acceso a las claves.

La seguridad de un almacén de claves basado en software suele depender de cómo se proteja su clave maestra. Antes de usar un almacén de claves basado en software, consulta lo siguiente:

• Cómo se protege la clave maestra en reposo.
• Cómo funciona el proceso de desprecintado y quién puede iniciarlo.
• Cómo se protege a las claves para que no se extraigan de la memoria.
• Cómo se protege el almacén de claves para que no se vea comprometido si un atacante obtiene acceso a la shell o al hipervisor del sistema subyacente.

No almacenes claves en almacenes de secretos basados en la nube

No recomendamos usar servicios de gestión de secretos basados en la nube, como Azure Key Vault y AWS Secret Manager, para almacenar y rotar claves de cuentas de servicio. Esto se debe a que, para acceder a estos secretos almacenados, tu aplicación necesita una identidad que el proveedor de la nube pueda reconocer. Si tu aplicación ya tiene una identidad que el proveedor de la nube puede reconocer, puede usarla para autenticarse en lugar de usar una clave de cuenta de servicio.

No utilices el rol Editor en proyectos que permitan crear o subir claves de cuentas de servicio

Una diferencia fundamental entre los roles básicos de editor (roles/editor) y propietario (roles/owner) es que el rol de editor no permite cambiar las políticas ni los roles de gestión de identidades y accesos. Por lo tanto, con el rol Editor no puedes ampliar fácilmente tu propio acceso ni conceder acceso a los recursos del proyecto a otros usuarios.

Las limitaciones del rol Editor pueden verse afectadas si un proyecto contiene cuentas de servicio. Como los roles de editor conceden permiso para crear o subir claves de cuentas de servicio, un agente malintencionado puede crear claves nuevas para cuentas de servicio que ya existan y usar estas claves para aumentar su propio acceso o para dar las claves a otros usuarios y que estos obtengan acceso a los recursos del proyecto.

En lugar de usar el rol Editor o cualquier otro rol básico, es mejor usar los roles predefinidos más específicos o crear roles personalizados que solo concedan los permisos necesarios.

Si necesitas usar el rol Editor, inhabilita la subida de claves de cuentas de servicio y la creación de claves mediante restricciones de políticas de organización para asegurarte de que el rol Editor no se pueda usar de forma inadecuada para aumentar los privilegios.

Protección frente a amenazas de divulgación de información

Evitar revelar información confidencial en los certificados X.509 subidos

En IAM, puedes descargar un certificado X.509 desde el endpoint https://www.googleapis.com/service_accounts/v1/metadata/x509/ACCOUNT_EMAIL para cada clave de cuenta de servicio. Este endpoint es público y no requiere autenticación.

En el caso de las claves gestionadas por el sistema Google Cloud-powered keys y las claves gestionadas por el usuario que hayas creado con la Trusted Cloud consola o la CLI de gcloud, los certificados X.509 se crean automáticamente y solo contienen metadatos básicos, como la dirección de correo y la fecha de vencimiento.

En el caso de las claves de cuenta de servicio subidas, el certificado X.509 proporcionado por el endpoint público es el mismo que has subido. Si el certificado que has subido contenía algún atributo opcional (como la dirección o la información de ubicación insertada en el nombre común), esta información también se hará pública. Un agente malicioso podría usar esta información para obtener más detalles sobre tu entorno.

Para evitar que se divulgue información confidencial, no añada ningún atributo opcional a los certificados X.509 subidos y utilice un Subject genérico.

Protección frente a amenazas de no repudio

Cuando detectas actividad sospechosa que afecta a tus recursos de Trusted Cloudy quieres analizar sus orígenes, necesitas datos que te permitan reconstruir la cadena de eventos que ha llevado a la actividad sospechosa. La fuente de datos principal para llevar a cabo este tipo de análisis suelen ser los registros de auditoría.

Analizar los registros de auditoría puede resultar más difícil cuando hay cuentas de servicio implicadas. Si una cuenta de servicio ha iniciado una actividad, la entrada de registro contiene la dirección de correo de la cuenta de servicio, pero también debes averiguar qué usuario o aplicación estaba usando la cuenta de servicio en ese momento.

En las siguientes secciones se indican las prácticas recomendadas para usar las claves de cuentas de servicio de forma que te ayuden a monitorizar su uso.

Usar una cuenta de servicio específica para cada aplicación

Todos los registros de auditoría contienen un campo principalEmail que identifica la entidad de seguridad que ha iniciado la actividad. Si compartes una clave de cuenta de servicio en varias aplicaciones, puede ser difícil identificar qué aplicación ha realizado una actividad, ya que los registros de auditoría contienen el mismo valor de principalEmail.

En lugar de compartir una clave entre varias aplicaciones, crea una cuenta de servicio específica para cada aplicación. De esta forma, el campo principalEmail te permite identificar la aplicación asociada a una cuenta de servicio, lo que puede ayudarte a reconstruir la cadena de eventos que ha llevado a una actividad sospechosa.

Usar una clave específica para cada máquina que ejecute una aplicación

Si ejecutas varias copias de la misma aplicación en varios equipos, el campo principalEmail puede permitirte identificar la aplicación, pero no el equipo en el que se ha originado una actividad concreta.

Para acotar las posibles fuentes de actividad sospechosa, crea claves individuales para cada copia de la aplicación. De esta forma, puedes usar el campo serviceAccountKeyName que muchos servicios añaden a los registros de auditoría para distinguir desde qué máquina se ha originado una actividad.

Protección frente a configuraciones de credenciales maliciosas

Algunas configuraciones de credenciales contienen URLs y rutas de archivo que, si una carga de trabajo no las valida correctamente, podrían provocar que la carga de trabajo use endpoints maliciosos.

Validar las claves adquiridas de una fuente externa antes de usarlas para autenticar las APIs de Google

Cuando aceptes una clave de cuenta de servicio de una fuente externa, debes validarla antes de usarla. Si no valida la clave, un agente malintencionado podría usarla para que su carga de trabajo acceda a endpoints maliciosos.

Si tu sistema solo espera claves de cuentas de servicio, asegúrate de que el valor del campo type sea service_account.

Para obtener más información, consulta Requisitos de seguridad al usar configuraciones de credenciales de una fuente externa.

Siguientes pasos

• Consulta más información sobre las prácticas recomendadas para trabajar con cuentas de servicio.
• Consulta nuestras prácticas recomendadas para usar cuentas de servicio en las pipelines de implementación.