Prácticas recomendadas para proteger las credenciales SSH

En este documento, se describen las prácticas recomendadas para proteger las credenciales SSH.

De forma predeterminada, Compute Engine usa la autenticación SSH basada en claves públicas: Los usuarios se autentican con algo que tienen, que es una clave privada SSH. Si las claves privadas de los usuarios no están protegidas de forma correcta, es posible que caigan en manos de agentes maliciosos que podrían usar estas claves para acceder a tus instancias de VM.

En las siguientes secciones, se incluyen prácticas recomendadas que pueden ayudarte a evitar la filtración de claves y reducir el posible impacto de las claves privadas filtradas:

En este documento, nos enfocamos en las prácticas que son específicas de Google Cloud o de particular relevancia cuando se usa SSH en Google Cloud. En el documento, no se abarcan las prácticas recomendadas para implementaciones específicas de clientes o servidores SSH.

Trata las claves privadas SSH de manera similar a las claves de cuenta de servicio

Es posible que algunas de tus instancias de VM tengan una cuenta de servicio adjunta. Si adjuntas una cuenta de servicio a una VM, las cargas de trabajo que se ejecutan en estas VMs pueden solicitar tokens de acceso de corta duración al servidor de metadatos para acceder a las APIs y los recursos de Google Cloud.

Cuando te conectas a una VM con una cuenta de servicio adjunta a través de SSH, también puedes solicitar tokens de acceso de corta duración al servidor de metadatos. Por lo tanto, otorgarle a un usuario acceso SSH a una VM es similar a otorgarle permiso para actuar como la cuenta de servicio adjunta. Debido a esa similitud, trata las claves privadas SSH, en especial cuando no están protegidas con frases de contraseña, como claves de cuenta de servicio: Ambos tipos de las claves, si se filtran, puede otorgar a un agente malicioso acceso a los recursos de Google Cloud.

Usa claves SSH efímeras para los usuarios de máquinas

Las canalizaciones de implementación o los procesos de automatización pueden requerir acceso SSH a las instancias de VM para realizar implementaciones o aplicar cambios de configuración. En lugar de permitir que estas cargas de trabajo usen un par de claves SSH de larga duración, permíteles usar una clave SSH nueva y efímera cada vez que se ejecuten.

Para usar claves SSH efímeras, permite que tus canalización de implementación o procesos de automatización realicen los siguientes pasos:

  1. Autentícate como una cuenta de servicio de una manera que no implique una clave o un objeto Secret, por ejemplo, con una cuenta de servicio adjunta o la federación de identidades para cargas de trabajo.
  2. Genera un par de claves SSH temporal; para ello, usa una herramienta como ssh-keygen.

  3. Publica la clave pública en Google Cloud y especifica una fecha de vencimiento próxima (por ejemplo, 1 hora en el futuro).

    El Acceso al SO te permite especificar una fecha de vencimiento de la clave cuando publicas una clave. Del mismo modo, puedes especificar una fecha de vencimiento cuando publicas una clave SSH pública en los metadatos del proyecto o la VM.

  4. Usa la clave privada para establecer conexiones SSH con instancias de VM.

  5. De manera opcional, puedes anular la publicación de la clave pública y borrar la clave privada.

Por ejemplo:

# Generate RSA2048 key pair without passphrase
ssh-keygen -b 2048 -t rsa -f ephemeral_key -q -N "" -V 30m

# Publish key to the service account's OS Login profile, with 30 min expiry
gcloud compute os-login ssh-keys add --key-file ephemeral_key.pub --ttl 30m

# Look up the service account's UNIX username
USERNAME=$(gcloud compute os-login describe-profile --format "value(posixAccounts[0].username)")

# Authenticate using the service account's UNIX user and public key
ssh $USERNAME@VM whoami

# Remove key
gcloud compute os-login ssh-keys remove --key-file ephemeral_key.pub

Si bien es posible que se filtre una clave privada SSH efímera, solo se puede usar durante un período breve. Por lo tanto, el uso de claves SSH efímeras puede reducir el riesgo de filtración de credenciales y te permite usar Cloud IAM como el medio principal de autenticación y autorización.

Usa IAP para complementar la autenticación con clave pública SSH

De forma predeterminada, las claves privadas SSH se pueden usar independientemente de las credenciales de Google: Si se filtra la clave SSH privada de un usuario, un agente malicioso puede usarla para conectarse y autenticarse en cualquier instancia de VM a la que la clave esté autorizada para acceder. No es necesario que el agente malicioso conozca el nombre de usuario o la contraseña del usuario, ni que tenga una credencial de Google.

Los controles de seguridad, como la verificación en dos pasos y limitar la duración de la sesión para los servicios de Google Cloud, pueden ser formas eficaces de reducir el riesgo de robo de credenciales, pero estos controles solo se aplican a los recursos que requieren credenciales de Google.

Para asegurarte de que las claves SSH no se puedan usar sin credenciales de Google válidas, usa IAP para administrar el acceso SSH y usa políticas de firewall para garantizar que todo el acceso SSH se realice a través de IAP.

IAP actúa como un proxy inverso y solo permite a los usuarios establecer conexiones SSH con instancias de VM si se autenticaron de forma correcta con sus credenciales de Google. Además, IAP te permite restringir las VMs a las que se pueden conectar los usuarios y aplicar el acceso adaptado al contexto.

Usa la autenticación de varios factores

El uso de IAP para administrar el acceso SSH dificulta que un agente malicioso acceda a instancias de VM con credenciales filtradas, pero no lo hace imposible. Por ejemplo, un agente malicioso podría vulnerar una estación de trabajo y encontrar una clave SSH privada y credenciales de gcloud CLI almacenadas en caché, lo que es suficiente para pasar las verificaciones de autenticación y autorización de IAP y conectarse a las instancias de VM del usuario.

Puedes reducir el posible impacto de esos ataques de robo de credenciales; para ello, configura Cloud Identity o Google Workspace para que requieran autenticación de varios factores (MFA).

Si Cloud Identity o Google Workspace es tu proveedor de identidad principal, sigue estos pasos para aplicar la MFA:

  1. Configura Cloud Identity o Google Workspace para aplicar la verificación en 2 pasos.
  2. Limita la duración de la sesión de los servicios de Google Cloud para que las credenciales almacenadas en caché se invaliden automáticamente y los usuarios deban volver a autenticarse y realizar la MFA de forma periódica.

Si usas el inicio de sesión único con un IdP externo, haz lo siguiente:

  1. Configura Cloud Identity o Google Workspace para limitar la duración de la sesión de los servicios de Google Cloud, de modo que las credenciales almacenadas en caché se invaliden automáticamente y los usuarios deban volver a autenticarse con el IdP externo de forma periódica.
  2. Configura tu IdP externo para que requiera la MFA y limita la duración de la sesión para que los usuarios tengan que realizar la MFA cada vez que venza su sesión de Google Cloud.

Para garantizar que la MFA también se aplique al acceso SSH, debes realizar al menos una de las siguientes acciones:

  1. Usa IAP para controlar el acceso de red, de modo que los usuarios tengan que realizar el MFA de forma periódica para actualizar sus credenciales de Google.
  2. Habilita la 2FA del Acceso al SO para las instancias de VM individuales o los proyectos completos, de modo que los usuarios deban realizar la MFA cada vez que establezcan una conexión SSH.

Los usuarios que tienen el rol de administrador de instancias de Compute o un rol equivalente para una instancia de VM o un proyecto pueden inhabilitar la 2FA del Acceso al SO; para ello, deben modificar los metadatos de la instancia. Por lo tanto, la eficacia de la 2FA del Acceso al SO es limitada si no aplicas la MFA en Cloud Identity o en tu IdP externo.

Usa claves privadas no exportables o protegidas por una frase de contraseña

Muchos clientes SSH almacenan de forma predeterminada claves privadas SSH como archivos en el disco. Por ejemplo, gcloud compute ssh genera un par de claves SSH en el primer uso y lo almacena en tu directorio principal. Es posible que el sistema operativo proteja tus archivos del acceso de otros usuarios, pero si un agente malicioso puede superar los permisos del sistema de archivos (por ejemplo, copiando y activando el disco en otra máquina), puede copiar la clave en otro lugar y usarla sin que lo sepas.

Algunos clientes SSH te permiten evitar el uso de claves basadas en archivos y ofrecen opciones alternativas para administrar claves privadas SSH, como las siguientes:

  • Con una clave guardada en hardware: Las versiones modernas de OpenSSH te permiten usar llaves de seguridad FIDO2 para la autenticación y puedes configurar el Acceso al SO para que solo permita llaves de seguridad que estén inscritas en Cloud Identity o Google Workspace. El uso de claves guardadas en hardware te ayuda a evitar almacenar material de claves privadas en el sistema de archivos de tu computadora.
  • Usar las instalaciones de almacenamiento de claves de tu sistema operativo: Por ejemplo, IAP Desktop evita usar claves basadas en archivos y, en su lugar, usa CNG de Windows para proteger tus claves SSH.

Si no puedes usar claves guardadas en hardware o administradas por el sistema operativo, puedes usar una frase de contraseña para proteger tu clave privada SSH: Para usar una clave SSH protegida con frase de contraseña, un agente malicioso no solo necesita una copia de la clave privada, sino también conocer la frase de contraseña de la clave.

Usa claves de host para autenticar el host

Cuando creas una conexión SSH a una instancia de VM, se identifica la instancia de VM por su nombre o dirección IP. Los nombres y las direcciones IP se pueden reasignar y volver a usar, y el nombre que hace referencia a una instancia de VM determinada ayer puede no hacer referencia a la misma instancia de VM en la actualidad. Los agentes maliciosos pueden reasignar o volver a usar de forma deliberada nombres o direcciones IP para falsificar las instancias de VM y atraer a los usuarios a una VM comprometida.

Los clientes SSH pueden detectar situaciones en las que una instancia de VM de confianza previamente se reemplazó por una instancia de VM diferente a través de claves de host SSH: La clave de host SSH de una VM se genera en el primer inicio y se usa para identificar la instancia. Por lo general, los clientes SSH solicitan y almacenan la clave de host de una VM en la primera conexión y verifican que no haya cambiado en las conexiones posteriores.

Las claves de host SSH funcionan según el esquema de confianza en el primer uso. La eficacia de las claves de host SSH puede verse afectada si un agente malicioso usa un ataque de intermediario (MITM) para permitir que un cliente se conecte a la VM incorrecta y confíe en ella durante el primer uso. Una forma mejor de obtener una clave de host es obtenerla a través de un canal lateral de confianza antes de conectarte a una VM por primera vez.

Puedes permitir que gcloud CLI obtenga claves de host a través de un canal de respaldo; para ello, habilita los atributos de invitado en tu proyecto. Luego, gcloud CLI lee la clave de host de una VM antes de que te conectes a ella y la guarda en tu computadora local.

No dejes credenciales personales en las VMs

Cuando autorizas gcloud CLI, la herramienta obtiene un token de actualización de OAuth y lo almacena en el directorio principal local. Cuando ejecutas posteriormente un comando de gcloud CLI, gcloud CLI usa el token de actualización para autenticarte automáticamente.

Es posible que otros usuarios no puedan acceder a tu computadora local, pero en una instancia de VM, otros usuarios que tengan privilegios sudo en la VM también pueden acceder a tu directorio principal.

Si un agente malicioso logra obtener privilegios sudo en una VM, es posible que busque tokens de actualización y otras credenciales en los directorios principales de otros usuarios y use estas credenciales para aumentar sus privilegios o extender su acceso a otros recursos (movimiento lateral).

Cuando te conectes a una instancia de VM a través de SSH, evita autorizar gcloud CLI o las credenciales predeterminadas de la aplicación (ADC) con tus credenciales personales y permite que gcloud CLI use la cuenta de servicio adjunta de la VM. Del mismo modo, evita ejecutar otras herramientas que puedan almacenar credenciales personales en tu directorio principal.

Para reducir aún más los riesgos, puedes limitar la duración de la sesión para los servicios de Google Cloud, de modo que los tokens de actualización de OAuth almacenados caduquen automáticamente después de un período determinado.

No envíes claves privadas SSH a los repositorios de código fuente

Algunas herramientas de automatización, como Ansible, usan SSH para acceder a instancias de VM y administrarlas. Debido a que estas herramientas pueden tener acceso a muchas instancias de VM (y sus cuentas de servicio adjuntas), las claves privadas SSH que usan esas herramientas pueden ser especialmente sensibles.

Si envías una clave privada SSH a un repositorio de código fuente, hay un mayor riesgo de que los usuarios no autorizados y los agentes maliciosos 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.

Para mitigar estos riesgos, almacena la clave privada SSH en una ubicación segura independiente del código fuente y usa claves SSH efímeras cuando sea posible.

¿Qué sigue?