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 correctamente, podrían caer en manos de agentes maliciosos que podrían usarlas para acceder a tus instancias de VM.

En las siguientes secciones se incluyen prácticas recomendadas que pueden ayudarte a evitar que se filtren claves y a reducir el impacto potencial de las claves privadas filtradas:

El documento se centra en las prácticas que son específicas de Google Cloud o de especial relevancia cuando se usa SSH en Google Cloud. El documento no abarca las prácticas recomendadas para implementaciones específicas de clientes o servidores SSH.

Tratar las claves privadas SSH de forma similar a las claves de cuentas de servicio

Es posible que algunas de tus instancias de VM tengan una cuenta de servicio asociada. Al asociar 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 mediante SSH, también puedes solicitar tokens de acceso de corta duración al servidor de metadatos. Por lo tanto, conceder a un usuario acceso SSH a una VM es similar a concederle permiso para actuar como la cuenta de servicio vinculada. Debido a esta similitud, trata las claves privadas de SSH, sobre todo cuando no estén protegidas con una contraseña, como las claves de cuentas de servicio: si se filtran ambos tipos de claves, un agente malintencionado podría acceder a los recursos de Google Cloud.

Usar claves SSH efímeras para usuarios de máquinas

Las pipelines 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, haz que usen una clave SSH efímera nueva cada vez que se ejecuten.

Para usar claves SSH efímeras, deje que sus pipelines de implementación o procesos de automatización sigan estos pasos:

  1. Autentícate como cuenta de servicio sin usar una clave ni un secreto. Por ejemplo, puedes usar una cuenta de servicio adjunta o la federación de identidades de cargas de trabajo.
  2. Genera un par de claves SSH temporal con una herramienta como ssh-keygen.

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

    OS Login te permite especificar una fecha de vencimiento de la clave cuando publicas una clave. Del mismo modo, puedes especificar una fecha de vencimiento cuando publiques una clave pública SSH en los metadatos de un proyecto o de una VM.

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

  5. De forma opcional, deja de publicar la clave pública y elimina la clave privada.

Por ejemplo:

# Generate RSA key pair without passphrase
ssh-keygen -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

Aunque una clave privada SSH efímera se filtre, solo se puede usar durante un breve periodo. Por lo tanto, usar claves SSH efímeras puede reducir el riesgo de que se filtren credenciales y te permite usar Cloud IAM como medio principal de autenticación y autorización.

Usar IAP para complementar la autenticación de 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 privada SSH de un usuario, un agente malintencionado puede usarla para conectarse y autenticarse en cualquier instancia de VM a la que la clave tenga acceso autorizado. No es necesario que el agente malintencionado conozca el nombre de usuario o la contraseña del usuario, ni que tenga ninguna credencial de Google.

Los controles de seguridad, como la verificación en dos pasos y la limitación de la duración de la sesión de los Google Cloud servicios, 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 controlar el acceso SSH y políticas de cortafuegos para obligar a que todo el acceso SSH se realice a través de IAP.

IAP actúa como proxy inverso y solo permite a los usuarios establecer conexiones SSH con instancias de VM si se han autenticado correctamente con sus credenciales de Google. Además, IAP te permite restringir a qué máquinas virtuales pueden conectarse los usuarios y aplicar el acceso contextual.

Usar la autenticación multifactor

Usar IAP para controlar el acceso SSH dificulta que un agente malintencionado acceda a instancias de VM con credenciales filtradas, pero no lo imposibilita. Por ejemplo, un agente malintencionado podría vulnerar una estación de trabajo y encontrar tanto una clave SSH privada como credenciales de la CLI de gcloud almacenadas en caché, lo que sería suficiente para superar las comprobaciones de autenticación y autorización de IAP y conectarse a las instancias de VM del usuario.

Puedes reducir el posible impacto de estos ataques de robo de credenciales configurando Cloud Identity o Google Workspace para que requieran la autenticación multifactor (MFA).

Si Cloud Identity o Google Workspace es tu proveedor de identidades principal, haz lo siguiente para aplicar la MFA:

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

Si utilizas el inicio de sesión único con un proveedor de identidades externo, sigue estos pasos:

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

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

  1. Usa IAP para controlar el acceso a la red para que los usuarios tengan que realizar la MFA periódicamente para actualizar sus credenciales de Google.
  2. Habilita la autenticación de dos factores de OS Login en instancias de VM concretas o en proyectos completos para que los usuarios tengan que realizar la MFA cada vez que establezcan una conexión SSH.

Los usuarios que tengan el rol Administrador de instancias de Compute o un rol equivalente para una instancia de VM o un proyecto pueden inhabilitar la autenticación de dos factores de inicio de sesión del SO modificando los metadatos de la instancia. Por lo tanto, la eficacia de la autenticación de dos factores de inicio de sesión en el SO es limitada si no aplicas también la MFA en Cloud Identity o en tu IdP externo.

Usar claves privadas no exportables o protegidas con una contraseña

Muchos clientes SSH almacenan las claves privadas SSH de forma predeterminada como archivos en el disco. Por ejemplo, gcloud compute ssh genera un par de claves SSH la primera vez que se usa y lo almacena en tu directorio principal. Es posible que tu sistema operativo proteja tus archivos para que otros usuarios no puedan acceder a ellos, pero si un agente malintencionado puede eludir los permisos del sistema de archivos (por ejemplo, copiando y montando el disco en otro ordenador), podrá 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 gestionar las claves privadas SSH, como las siguientes:

  • Usar una llave respaldada por hardware: las versiones modernas de OpenSSH te permiten usar llaves de seguridad FIDO2 para la autenticación. Además, puedes configurar el inicio de sesión en el SO para que solo permita llaves de seguridad registradas en Cloud Identity o Google Workspace. Si usas claves respaldadas por hardware, no tendrás que almacenar ningún material de clave privada en el sistema de archivos de tu ordenador.
  • Usar las funciones de almacenamiento de claves de tu sistema operativo: por ejemplo, IAP Desktop evita usar claves basadas en archivos y, en su lugar, usa Windows CNG para proteger tus claves SSH.

Si no puedes usar claves protegidas por hardware o gestionadas por el sistema operativo, puedes usar una contraseña para proteger tu clave privada SSH. Para usar una clave SSH protegida por contraseña, un agente malintencionado no solo necesita una copia de la clave privada, sino que también debe conocer la contraseña de la clave.

Usar claves de host para autenticar el host

Cuando creas una conexión SSH a una instancia de VM, la identificas por su nombre o dirección IP. Los nombres y las direcciones IP se pueden reasignar y reutilizar, y el nombre que hacía referencia a una instancia de VM ayer puede que no haga referencia a la misma instancia de VM hoy. Los agentes malintencionados pueden reasignar o reutilizar nombres o direcciones IP deliberadamente para suplantar instancias de VM y atraer a los usuarios para que se conecten a una VM vulnerable.

Los clientes SSH pueden detectar situaciones en las que una instancia de VM de confianza se ha sustituido por otra instancia de VM mediante claves de host SSH. La clave de host SSH de una VM se genera en el primer arranque y se usa para identificar la instancia. Los clientes SSH suelen solicitar y almacenar la clave de host de una VM en la primera conexión y verificar 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 malintencionado usa un ataque man-in-the-middle (MITM) para permitir que un cliente se conecte y confíe en la máquina virtual incorrecta la primera vez que la usa. Una forma mejor de obtener una clave de host es hacerlo a través de un canal lateral de confianza antes de conectarse a una VM por primera vez.

Puedes permitir que la CLI de gcloud obtenga claves de host a través de un canal secundario habilitando los atributos de invitado en tu proyecto. A continuación, la CLI de gcloud lee la clave de host de una VM antes de que te conectes a ella por primera vez y la guarda en tu ordenador local.

No dejes credenciales personales en las máquinas virtuales

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

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

Si un agente malintencionado consigue obtener privilegios de sudo en una VM, puede buscar tokens de actualización y otras credenciales en los directorios de inicio de otros usuarios y usar estas credenciales para aumentar sus privilegios o ampliar su acceso a otros recursos (movimiento lateral).

Cuando te conectes a una instancia de VM a través de SSH, no autorices la CLI de gcloud ni las credenciales predeterminadas de la aplicación (ADC) con tus credenciales personales. En su lugar, deja que la CLI de gcloud use la cuenta de servicio asociada a la VM. Del mismo modo, evita ejecutar otras herramientas que puedan almacenar credenciales personales en tu directorio principal.

Puedes reducir aún más los riesgos limitando la duración de la sesión de los Google Cloud servicios para que los tokens de actualización de OAuth almacenados caduquen automáticamente después de un tiempo determinado.

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

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

Si envías una clave privada SSH a un repositorio de código fuente, aumenta el riesgo de que usuarios no autorizados y agentes malintencionados puedan acceder a la clave:

  • 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 si contiene 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 que esté separada del código fuente y usa claves SSH efímeras siempre que sea posible.

Siguientes pasos