Prácticas recomendadas para administrar claves de cuenta de servicio

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

A diferencia de los usuarios normales, 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 usar la clave privada para crear un token del portador de JWT y usar el token del portador para solicitar un token de acceso. El token de acceso resultante refleja la identidad de la cuenta de servicio y puedes usarla para interactuar con las API de Google Cloud en nombre de la cuenta de servicio.

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

Si no se administran con cuidado, las claves de cuenta de servicio pueden convertirse en un riesgo para la seguridad. Debes elegir una alternativa más segura para la autenticación siempre que sea posible. Las principales amenazas relacionadas con las claves de cuenta de servicio son las siguientes:

• Filtración de credenciales: las claves de cuenta de servicio pueden terminar de forma involuntaria en lugares en los que no deben almacenarse. Una persona/entidad que actúa de mala fe puede usar una clave de cuenta de servicio que se haya filtrado para autenticarse y obtener acceso al entorno.
• Elevación de privilegios: si una persona/entidad que actúa de mala fe obtiene acceso a una clave de cuenta de servicio poco segura, es posible que pueda usar la clave para elevar los privilegios.
• Divulgación de información: las claves de cuenta de servicio pueden divulgar de forma involuntaria metadatos confidenciales.
• No rechazo: si realizas la autenticación con una clave de cuenta de servicio y permites que la cuenta de servicio realice operaciones en su nombre, una persona/entidad que actúa de mala fe podría ocultar su identidad y sus acciones.

La mejor manera de mitigar estas amenazas es evitar las claves de cuenta de servicio administradas por el usuario y usar otros métodos para autenticar cuentas de servicio siempre que sea posible. También puedes usar condiciones de IAM y Controles del servicio de VPC para restringir los recursos a los que puede acceder una cuenta de servicio vulnerada.

En situaciones en las que no puedes usar alternativas más seguras que las claves de cuentas de servicio, usa esta guía en la que se presentan prácticas recomendadas para administrar, usar y proteger las claves de cuentas de servicio.

Proporciona protección contra filtraciones de credenciales

Al igual que un nombre de usuario y una contraseña, las claves de cuenta de servicio son una forma 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 otorgó acceso a la cuenta de servicio respectiva.

Para las personas/entidades que actúan de mala fe, las claves de cuenta de servicio pueden ser aún más valiosas que una contraseña filtrada: es poco probable que el acceso a través de una contraseña filtrada tenga éxito si la cuenta de usuario se configuró para usar la verificación en dos pasos y las verificaciones de identidad. Por el contrario, es probable que la autenticación mediante el uso de una clave de cuenta de servicio filtrada tenga éxito, ya que las cuentas de servicio no están sujetas a ninguna verificación de acceso adicional.

Las personas/entidades que actúan de mala fe pueden buscar claves de cuenta de servicio en varios lugares, como los siguientes:

• Repositorios de código fuente de proyectos de código abierto
• Buckets públicos de Cloud Storage
• Volcados de datos públicos de servicios incumplidos

Además de las ubicaciones públicas, las personas/entidades que actúan de mala fe pueden buscar claves de cuenta de servicio en ubicaciones privadas que hayan vulnerado. Entre los ejemplos, se incluye lo siguiente:

• Bandejas de entrada de los correos electrónicos
• Archivos compartidos
• Almacenamiento en copias de seguridad
• Directorios temporales del sistema de archivos

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

Proporciona alternativas a la creación de claves de cuenta de servicio

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

• Capacita a tus desarrolladores sobre alternativas más seguras que las claves de cuentas de servicio.
• Establece un proceso que ayude a los desarrolladores a decidir el método de autenticación apropiado para su caso de uso antes de crear una clave de cuenta de servicio nueva.
• Usa restricciones de las políticas de la organización para evitar crear claves de cuentas de servicio nuevas y permite excepciones solo para los proyectos que demostraron que no pueden usar una alternativa más segura.

Usa restricciones de las políticas de la organización para limitar los proyectos que pueden crear claves de cuenta de servicio

Debido a que existen alternativas más seguras en lugar de las claves de cuenta de servicio, es mejor considerar su uso como una excepción en lugar de la norma.

Para evitar el uso innecesario de las claves de cuenta de servicio, usa las restricciones de las políticas de la organización:

• En la raíz de la jerarquía de recursos de tu organización, aplica las restricciones Inhabilita la creación de claves de cuentas de servicio y, también, Inhabilita la carga de claves de cuentas de servicio para establecer un valor predeterminado en el que las claves de cuenta de servicio no estén permitidas.

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

Para modificar las restricciones de las políticas de la organización, se requiere el permiso orgpolicy.policy.set. Debido a que ni la función de propietario (roles/owner) ni la función de editor (roles/editor) incluyen este permiso, las restricciones también pueden ser efectivas en entornos que no son de producción en los que algunas principales pueden tener acceso de propietario o editor a los proyectos

No dejes las claves de cuenta de servicio en ubicaciones temporales

Cuando creas una clave de cuenta de servicio con la consola de Google Cloud, la mayoría de los navegadores descargan la clave nueva de inmediato y la guardan en una carpeta de descarga en tu computadora. Debes mover la clave de inmediato a la ubicación donde quieras almacenarla. Asegúrate de no dejar accidentalmente una copia en la carpeta de descarga ni en la papelera de reciclaje de tu computadora.

Puedes reducir el riesgo de dejar accidentalmente copias de claves de cuenta de servicio en ubicaciones temporales mediante Google Cloud CLI de gcloud iam service-accounts keys create: el comando te permite escribir el archivo de claves de cuenta de servicio directamente en la ubicación en la que lo necesites. Además, en la mayoría de los sistemas operativos, la CLI de gcloud ajusta los permisos del archivo de forma automática para que solo tú puedas acceder al archivo.

No pases claves de cuenta de servicio entre usuarios

Cuando implementas una aplicación que requiere una clave de cuenta de servicio, es posible que no tengas el permiso para crearla. En cambio, es posible que debas solicitar a una persona diferente que cree una clave de cuenta de servicio por ti.

En situaciones en las que varios usuarios participan en la creación y la implementación de una clave de cuenta de servicio, hay un mayor riesgo de que las copias de la clave permanezcan en buzones, historiales de chat, o en otras ubicaciones. Cuando se necesita un traspaso 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 2,048 bits en la máquina de destino. Para crear el certificado, puedes usar openssl, certutil, New-SelfSignedCertificate, o cualquier otra herramienta del sistema operativo.
2. Pasa el archivo del certificado al usuario que tiene el permiso para subir el certificado y, al mismo tiempo, conserva la clave privada en la máquina de destino. Cuando pases el certificado, asegúrate de que no se pueda reemplazar ni alterar, pero no necesitas mantenerlo confidencial.
3. Como usuario que tiene los permisos necesarios para administrar las claves de cuenta de servicio, sube el certificado a fin de asociarlo con una cuenta de servicio.

Si sigues este proceso, evitas pasar la clave privada y, en su lugar, solo intercambias información pública entre los usuarios.

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

Las claves de cuenta de servicio son credenciales y deben protegerse del acceso no autorizado. Si envías una clave de cuenta de servicio a un repositorio de código fuente, hay un mayor riesgo de que los usuarios no autorizados y las personas/entidades que actúan de mala fe puedan acceder a la clave:

• Las personas/entidades que actúan de mala fe pueden analizar el código fuente de los repositorios de fuente pública en busca de claves filtradas.
• En el futuro, es posible que decidas convertir un repositorio de fuente privada en un repositorio público, sin verificar primero las claves.
• Otros miembros del equipo pueden almacenar copias del código fuente en su estación de trabajo.

Cuando trabajes en un código que use una clave de cuenta de servicio, almacena siempre la clave de cuenta de servicio separada del código fuente para reducir el riesgo de enviar accidentalmente la clave al repositorio de origen. En muchos casos, puedes reducir aún más este riesgo si no usas las claves de cuenta de servicio durante el desarrollo y usas tus credenciales personales en lugar de las claves de cuenta de servicio.

Además, configura tu sistema de control de fuente para que detecte envíos accidentales de claves de cuenta de servicio:

• Si usas Cloud Source Repositories, habilita la detección de claves para bloquear las operaciones de envío git que contienen claves privadas y notificar a los usuarios.
• Si usas GitHub, habilita el análisis de Secret para tus repositorios.
• Usa la detección de anomalías de Security Command Center para mostrar información sobre las credenciales filtradas.
• Si tu sistema de administración de control de fuente 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 Secrets mediante un hook de confirmación previa, la adición de un paso a la canalización de integración continua, o ambas opciones.

No incorpores claves de cuenta de servicio en objetos binarios del programa

Las claves de cuenta de servicio son strings que coinciden con un patrón determinado y se pueden identificar incluso si están incorporadas en otros archivos u objetos binarios. Si una persona/entidad que actúa de mala fe tiene acceso al objeto binario, puede extraer cualquier clave de cuenta de servicio que esté incorporada en el objeto binario.

Los objetos binarios del programa para aplicaciones del servidor pueden estar alojados en repositorios de artefactos o pueden copiarse en estaciones de trabajo para desarrolladores con fines de depuración. Mantener las claves de cuenta de servicio separadas de los objetos binarios del programa ayuda a garantizar que un usuario que puede acceder al objeto binario no obtenga acceso de forma implícita a las credenciales de la cuenta de servicio.

• Para las aplicaciones del cliente, como herramientas, programas de escritorio o apps para dispositivos móviles, no uses cuentas de servicio. En su lugar, permite que los usuarios se autentiquen con sus propias credenciales mediante el flujo de consentimiento de OAuth.
• Para las aplicaciones del servidor, no incorpores claves de cuenta de servicio en el objeto binario. En su lugar, mantén las claves separadas del objeto binario de la aplicación.

Usa estadísticas y métricas para identificar claves de cuenta de servicio sin usar

Para minimizar la cantidad de claves de cuenta de servicio válidas en circulación, es mejor inhabilitar las claves apenas dejen de ser necesarias y, luego, borrar las claves cuando estés seguro de que ya no son necesarias. Si no estás seguro acerca de si una clave aún se encuentra en uso o no, puedes usar las estadísticas de la cuenta de servicio y las métricas de autenticación:

• Las estadísticas de la cuenta de servicio te permiten identificar las cuentas de servicio que no se usaron en los últimos 90 días.
• Si supervisas la métrica Key Authentication Events, puedes descubrir cuándo se usó una clave de cuenta de servicio por última vez y con qué frecuencia se usó para autenticar una cuenta de servicio.

Debido a que las cuentas de servicio pertenecen a un proyecto de Google Cloud, se debe hacer un seguimiento individual a las estadísticas y las métricas para cada proyecto.

Rota las claves de la cuenta de servicio para reducir el riesgo de seguridad causado por claves filtradas

Aunque puedes reducir la probabilidad de filtrar accidentalmente una clave de cuenta de servicio, puede ser difícil eliminar el riesgo por completo.

La rotación de claves es el proceso de reemplazar tus claves existentes con claves nuevas y, luego, invalidar las reemplazadas. Te recomendamos que rotes todas las claves que administras de forma rutinaria, incluidas las claves de tu cuenta de servicio.

La rotación de las claves de cuenta de servicio puede ayudar a reducir el riesgo que presentan las claves filtradas o robadas. Si se filtra una clave, es posible que las personas que actúan de mala fe tarden días o semanas en descubrir la clave. Si rotas las claves de tu cuenta de servicio con regularidad, hay más probabilidades de que las claves filtradas no sean válidas en el momento que una persona/entidad que actúa de mala fe las obtiene.

Tener un proceso establecido para rotar las claves de cuenta de servicio también te ayuda a actuar con rapidez si sospechas que se vulneró una clave de cuenta de servicio.

Si generaste el par de clave pública/privada, almacenaste la clave privada en un módulo de seguridad de hardware (HSM) y subiste la clave pública a Google, entonces Es posible que no necesites rotar la clave de forma periódica. En cambio, puedes rotar la clave si crees que se vulneró.

Usa plazos de vencimiento para permitir que las claves caduquen automáticamente.

De forma predeterminada, las claves de cuenta de servicio que creas y descargas de IAM no tienen un plazo de vencimiento y permanecen válidas hasta que las borres. Establecer una fecha de vencimiento para las claves de cuenta de servicio puede limitar el riesgo de seguridad, ya que reduce la vida útil de la credencial persistente. Sin embargo, existen otros riesgos asociados con la configuración de los plazos de vencimiento; por ejemplo, establecer un plazo de vencimiento puede hacer que las cargas de trabajo fallen cuando vencen sus claves.

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

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

Evita usar plazos de vencimiento para estas situaciones:

• Cargas de trabajo de producción En producción, una clave de cuenta de servicio vencida podría causar una interrupción accidental. En su lugar, usa claves que no tengan vencimiento y administra su ciclo de vida con la rotación de claves.
• Cargas de trabajo que no son de producción y que necesitan acceso permanente, como una canalización de integración continua (CI)
• Sistemas de rotación de claves que evitan que una clave se use después de un período específico Para obtener información sobre las estrategias de rotación de claves recomendadas, consulta Rotación de claves de cuenta de servicio.

Para limitar la validez de las claves de cuenta de servicio, puedes configurar una fecha de vencimiento para las claves recién creadas en tu proyecto, organización o carpeta. El tiempo de vencimiento no se aplica a las claves existentes.

Como alternativa, puedes subir una clave de cuenta de servicio y especificar una fecha Válida para en el archivo del certificado X.509. Una vez que se pasa la fecha de vencimiento, la clave ya no se puede usar para la autenticación. Sin embargo, permanece asociado con la cuenta de servicio hasta que la borres.

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

Incluso si sigues todas las prácticas recomendadas para las claves de cuenta de servicio, es posible que se filtren.

Para ayudar a administrar las credenciales filtradas, asegúrate de que la restricción de respuesta de exposición de claves de cuenta de servicio esté configurada en DISABLE_KEY. Si estableces la restricción en este valor, Google Cloud inhabilitará automáticamente las claves filtradas que detecte.

Si se inhabilita una clave porque se filtró, se agregan los siguientes campos a los metadatos de la clave:

• "disable_reason": "SERVICE_ACCOUNT_KEY_DISABLE_REASON_EXPOSED": Indica que la clave se inhabilitó porque estaba expuesta.
• "extended_status": "SERVICE_ACCOUNT_KEY_EXTENDED_STATUS_KEY_EXPOSED"": Indica que la clave alguna vez se expuso públicamente. Este valor persiste incluso si vuelves a habilitar la clave.
• "extended_status_message": "LINK_TO_EXPOSURE": Si están disponibles, los metadatos contienen un vínculo al lugar donde se detectó la clave, que puedes usar para la solución.

Estas claves se pueden volver a habilitar si es necesario para mitigar una interrupción. Sin embargo, te recomendamos que las vuelvas a inhabilitar lo antes posible, ya que las claves expuestas públicamente representan un riesgo de seguridad, incluso si se quita la exposición inicial.

Para obtener información sobre otras prácticas recomendadas para administrar credenciales vulneradas, consulta Controla las credenciales vulneradas de Google Cloud.

Proporciona protección contra la elevación de privilegios

El uso de claves de cuenta de servicio puede exponerte a ataques de elevación de privilegios si las claves están menos protegidas que los recursos a los que otorgan acceso.

Como ejemplo, supongamos que una persona/entidad que actúa de mala fe ya se apoderó de tu entorno y ahora intenta acceder a ciertos recursos de Google Cloud. Es posible que aún no tenga los permisos para acceder a estos recursos, pero los privilegios podrían ser suficientes para acceder a una clave de cuenta de servicio que se almacena en una VM, un archivo compartido, o cualquier otra ubicación menos segura. Mediante la autenticación con la clave de cuenta de servicio, la persona/entidad que actúa de mala fe puede asumir la identidad de la cuenta de servicio. La cuenta de servicio puede permitir que la persona/entidad que actúa de mala fe acceda a recursos a los que antes no tenía acceso, lo que eleva los privilegios de esa persona/entidad que actúa de mala fe.

Debido a que una clave de cuenta de servicio otorga acceso de forma indirecta a los recursos en Google Cloud, debes considerar que la clave en sí es tan valiosa como los recursos y vale la pena protegerla tanto como a los recursos.

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

Evita almacenar claves en un sistema de archivos

Las claves de cuenta de servicio creadas con la consola de Google Cloud o la CLI de gcloud son archivos JSON, y puedes copiarlos en el sistema de archivos de la máquina en el que se necesitan. Sin embargo, almacenar las claves de cuenta de servicio como archivos en un sistema de archivos puede exponerte a varios riesgos, incluidos los siguientes:

• Algunos sistemas de archivos, como NTFS, usan permisos heredados de forma predeterminada. A menos que esté inhabilitado, un permiso agregado a una carpeta superior puede hacer que un archivo de claves sea involuntariamente más accesible y visible para los usuarios no autorizados.
• En un entorno virtualizado, las personas/entidades que actúan de mala fe pueden comprometer la seguridad del sistema de archivos mediante el acceso al disco virtual subyacente.
• Los cambios en el acceso al sistema de archivos y en los permisos del sistema de archivos a menudo no se registran en la auditoría. Si los permisos del archivo se cambian de forma inadvertida y la clave se hace visible para los usuarios no autorizados, puede ser difícil analizar cuándo y quién hizo estos cambios.
• Los archivos se pueden copiar con facilidad y, por lo tanto, robar de forma fácil si una persona/entidad que actúa de mala fe obtiene acceso.

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

Usa un HSM o TPM para almacenar claves

Cuando creas una clave de cuenta de servicio mediante la consola de Google Cloud o la CLI de gcloud, Google Cloud genera la clave privada y, luego, te la informa. Muchos riesgos de seguridad asociados con las claves de cuenta de servicio se deben a que la clave privada está disponible de forma temporal o permanente en textos no encriptados y, por lo tanto, puede resultar difícil protegerla.

En lugar de permitir que Google Cloud genere un par de claves, puedes usar un módulo de seguridad de hardware (HSM) o un módulo de plataforma segura (TPM) para crear y administrar claves:

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

Un HSM o TPM te permite usar una clave privada sin revelar la clave en el texto no encriptado. Por lo tanto, usar un HSM o TPM para administrar las claves de cuenta de servicio te ayuda a aplicar el control de acceso y, a la vez, a mitigar el riesgo de que las claves se copien en otros sistemas.

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

Las claves de cuenta de servicio administradas por un TPM son exclusivas de una máquina física o virtual. Aún puedes permitir que varias máquinas compartan una cuenta de servicio mediante la asociación de la clave de cada máquina con una cuenta de servicio común.

Usa un almacén de claves basado en software

En situaciones en las que no sea viable usar un almacén de claves basado en hardware, usa un almacén de claves basado en software para administrar claves de cuenta de servicio. Al igual que las opciones basadas en hardware, un almacén de claves basado en software permite a los usuarios o las aplicaciones usar claves de cuenta de servicio sin revelar la clave privada. Las soluciones del almacén de claves basadas en software pueden ayudarte a controlar el acceso a las claves de manera detallada y también pueden garantizar se registre que cada acceso a la clave.

Por lo general, la seguridad de un almacén de claves basado en software depende de cómo se protege su clave maestra. Antes de usar un almacén de claves basado en software, asegúrate de revisar lo siguiente:

• cómo se protege la clave maestra en reposo,
• cómo funciona el proceso para anulación de sellos y quién puede iniciarlo,
• cómo se protegen las claves ante su posible extracción de la memoria,
• cómo se protege el almacén de claves ante la posibilidad de que se lo socave si una persona/entidad que actúa de mala fe obtiene acceso de shell o de hipervisor al sistema subyacente.

No almacenes claves en Secret Manager ni en otros almacenes de Secret basados en la nube

No recomendamos usar Secret Manager de Google Cloud para almacenar y rotar las claves de cuenta de servicio. Esto se debe a que, para acceder a los Secrets de Secret Manager, la aplicación necesita una identidad que Google Cloud pueda reconocer. Si la aplicación ya tiene una identidad que Google Cloud puede reconocer, la aplicación puede usarla para autenticarse en Google Cloud en lugar de usar una clave de cuenta de servicio.

El mismo concepto se aplica a otros servicios de administración de secretos basados en la nube, como Azure KeyVault y AWS Secret Manager. Si una aplicación ya tiene una identidad que estos proveedores de servicios en la nube pueden reconocer, podría usar esa identidad para autenticarse en Google Cloud en lugar de usar una clave de cuenta de servicio.

No uses la función de editor en proyectos que permitan la creación o la carga de claves de cuenta de servicio

Una diferencia clave entre las funciones básicas de editor (roles/editor) y propietario (roles/owner) es que la función de editor no te permite cambiar las políticas de IAM ni las funciones. Por lo tanto, con la función de editor, no puedes extender con facilidad tu propio acceso ni otorgar a otros usuarios acceso a los recursos del proyecto.

Si un proyecto contiene cuentas de servicio, se pueden socavar las limitaciones de la función de editor. Debido a que las funciones de editor otorgan permiso para crear o subir claves de cuenta de servicio, una persona/entidad que actúa de mala fe puede crear claves nuevas para las cuentas de servicio existentes y usar estas claves a fin de escalar su propio acceso o entregar las claves a otros usuarios para obtener acceso a los recursos del proyecto.

En lugar de usar la función de editor o cualquier otra función básica, es mejor usar las funciones predefinidas más específicas o crear funciones personalizadas que solo otorguen los permisos necesarios.

Si necesitas usar el rol de editor, puedes inhabilitar la carga de claves de cuenta de servicio y la creación de claves mediante restricciones de las políticas de la organización para garantizar que no se pueda abusar del rol de editor para la elevación de privilegios.

Evita usar claves de cuenta de servicio para la delegación de todo el dominio

La delegación de todo el dominio te permite actuar en nombre de un usuario para que puedas acceder a los datos de un usuario sin necesidad de obtener una autorización manual de su parte. Si bien los ejemplos que ilustran el uso de la delegación de todo el dominio por lo general sugieren el uso de claves de cuentas de servicio, no es necesario usar claves de cuentas de servicio para realizar la delegación de todo el dominio.

Cuando uses la delegación de todo el dominio, evita las claves de cuenta de servicio y usa la API de signJwt en su lugar:

1. Primero autentica una cuenta de servicio mediante una cuenta de servicio adjunta, Workload Identity Federation for GKE o la federación de identidades para cargas de trabajo.
2. Construye un JWT y usa la reclamación sub para especificar la dirección de correo electrónico del usuario a la que solicitas acceso delegado.
3. Usa la API de signJwt para firmar el JWT.
4. Pasa el JWT firmado al recurso del token de OAuth2 para obtener un token de acceso.

Si sigues este enfoque, evitas tener que administrar una clave de cuenta de servicio, lo que da como resultado una configuración que se puede proteger con mayor facilidad.

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

Evita divulgar información confidencial en los certificados X.509 subidos

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

Para las claves administradas por Google y las claves administradas por el usuario que creaste mediante la consola de Google Cloud o gcloud CLI, los certificados X.509 se crean de forma automática y solo contienen metadatos básicos, como la dirección de correo electrónico y la fecha de vencimiento.

Para las claves de cuenta de servicio subidas, el certificado X.509 que proporciona el extremo público es el mismo certificado que subiste. Si el certificado que subiste contiene algún atributo opcional (como la información de la dirección o la ubicación incorporada en el nombre común), esta información también se volverá de acceso público. Una persona/entidad que actúa de mala fe puede usar esta información para obtener más detalles sobre tu entorno.

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

Cómo brindar protección contra amenazas no repudiantes

Cuando observas actividad sospechosa que afecta tus recursos de Google Cloud y deseas analizar sus orígenes, necesitas datos que te permitan reconstruir la cadena de eventos que generó la actividad sospechosa. La fuente principal de datos para realizar este análisis suelen ser los registros de auditoría.

Analizar los registros de auditoría puede ser más difícil cuando se incluyen cuentas de servicio: si una cuenta de servicio inició una actividad, la entrada de registro contiene la dirección de correo electrónico de la cuenta de servicio, pero también debes averiguar qué usuario o aplicación estaba usando la cuenta de servicio en ese momento.

Las siguientes secciones contienen prácticas recomendadas para usar claves de cuenta de servicio de una manera que te ayude a hacer un seguimiento de su uso.

Usa una cuenta de servicio dedicada para cada aplicación

Todos los registros de auditoría contienen un campo principalEmail que identifica la principal que inició la actividad. Si compartes una clave de cuenta de servicio en varias aplicaciones, puede ser difícil identificar qué aplicación realizó una actividad porque los registros de auditoría contienen el mismo valor principalEmail.

En lugar de compartir una clave entre varias aplicaciones, crea una cuenta de servicio dedicada para cada aplicación. De esta manera, el campo principalEmail te permite identificar la aplicación asociada con una cuenta de servicio, lo que puede ayudarte a reconstruir la cadena de eventos que generó una actividad sospechosa.

Usa una clave dedicada para cada máquina que ejecute una aplicación

Si ejecutas varias copias de la misma aplicación en diversas máquinas, entonces el campo principalEmail podría permitirte identificar la aplicación, pero no la máquina en la que se originó una actividad particular.

Para ayudarte a reducir las posibles fuentes de actividad sospechosa, crea claves individuales para cada copia de la aplicación. De esta manera, puedes usar el campo serviceAccountKeyName que muchos servicios agregan a los registros de auditoría para distinguir en qué máquina se originó una actividad.

¿Qué sigue?

• Obtén más información sobre las prácticas recomendadas para trabajar con cuentas de servicio.
• Revisa nuestras prácticas recomendadas para usar cuentas de servicio en las canalizaciones de implementación.