Guía para la gestión de claves SSH en varias nubes

A medida que aumenta el número de empresas que trasladan sus operaciones y datos en entornos multicloud, crecen las preguntas en torno a la gestión de claves SSH. Mark Thompson, Vicepresidente Senior de Gestión de Producto, y Ryan Sanders, Director de Marketing de Producto, en Keyfactor, respondieron a estas preguntas durante su sesión conjunta en la Cumbre Virtual de Confianza Crítica 2020.

En este blog, voy a desglosar los conceptos básicos tratados en nuestra sesión y proporcionar las mejores prácticas para la gestión de claves SSH multi-nube.

SSH parece estar en todas partes. El 84% de las empresas actuales utilizan el protocolo SSH en alguna medida de su infraestructura.

¿Por qué? Porque SSH es una forma cómoda de autenticar y proteger las conexiones, por no mencionar que viene integrado en los sistemas basados en Linux y Unix. SSH es muy utilizado por los administradores de sistemas para acceder remotamente a los sistemas y, cada vez más, en procesos automatizados, como copias y backups seguros o transferencias seguras de archivos.

La autenticación de clave pública es la opción de facto para el acceso SSH. A diferencia de las contraseñas, las claves SSH no son vulnerables a los ataques de fuerza bruta y no requieren la interacción del usuario para habilitar el acceso, por lo que son ideales para procesos automatizados.

Debido a sus ventajas, la proliferación de claves SSH no tiene parangón. No es raro descubrir de 50 a 200 claves por servidor, o ver 1 millón de claves en una organización.

A pesar del acceso de alto privilegio que proporcionan, no están estrictamente controlados en muchas situaciones. Esto está creando una situación de alto riesgo. A falta de un marco de gestión, cada vez más claves han pasado desapercibidas para los auditores y los equipos de seguridad y gestión de riesgos.

Mientras que la mayoría de las organizaciones están familiarizadas con PKI y la gestión de certificados X.509, los retos relacionados con las claves SSH son totalmente diferentes.

Por ejemplo, la mayor parte de la atención en torno a los certificados se centra en la renovación antes de su caducidad (para evitar interrupciones). Sin embargo, las claves SSH no caducan, lo que crea el riesgo inverso de credenciales obsoletas y acceso no autorizado.

A continuación se desglosan las principales diferencias:

El mayor riesgo al que se enfrentan las empresas es la proliferación de claves SSH. La causa principal de la proliferación de claves SSH es la falta de una gestión centralizada de claves y accesos:

• Falta de control: Los administradores autoaprovisionan, copian y comparten claves sin restricciones.
• Sin caducidad: Las claves SSH no caducan y se dejan sin gestionar en los sistemas durante años
• Falta de política: A menudo se concede acceso root incluso cuando no es necesario
• Visibilidad limitada: No hay visibilidad centralizada de las claves autorizadas y privadas
• Reparación lenta: Los equipos de seguridad dudan en revocar o rotar las claves.

Otra causa de la proliferación de claves SSH es la rotación de personal. Aunque existen procesos estandarizados para eliminar al personal que se marcha del Directorio Activo, estos procesos a menudo no incluyen sus claves SSH asociadas. La compleja red de relaciones de confianza entre claves, usuarios y máquinas, hace que el proceso de eliminar o rotar claves sea increíblemente doloroso y propenso a riesgos.

Según las conclusiones del Estudio de Tendencias Globales de Cifrado 2020 de nCipher y Ponemon, el 57% de los equipos de seguridad admite que las claves SSH son dolorosas o muy dolorosas de gestionar.

Impulsadas por las iniciativas empresariales de migración de operaciones y datos a la nube, las claves SSH se enfrentan a una nueva norma. Hay varias razones que explican el aumento del uso de claves SSH en todas las plataformas en la nube:

• El 90% de todas las cargas de trabajo de la nube pública se ejecutan actualmente en Linux (del que SSH es un componente básico).
• Varios equipos utilizan SSH en nubes y herramientas de gestión de la configuración (es decir, nodos de control de Ansible, servidores de infraestructura de Chef, etc.).
• Los ingenieros de DevOps utilizan SSH para conectarse a repositorios Git, cargas de trabajo remotas, etc.

Como signo de los tiempos, GitHub anunció recientemente que están dejando de utilizar contraseñas, siendo las claves SSH la principal alternativa. A medida que los desarrolladores hacen uso de claves SSH en entornos altamente automatizados y distribuidos, los riesgos no hacen más que aumentar.

Estos avances subrayan que la gestión y protección de las claves SSH en la nube es fundamental para las empresas de hoy en día. Sin embargo, las diferencias de un proveedor de nube a otro aumentan la complejidad en la gestión de claves SSH, especialmente a medida que las empresas adoptan estrategias multicloud.

• Google Cloud, AWS y Azure permiten a los usuarios generar nuevas claves o utilizar claves ssh existentes.
• El acceso SSH se configura y gestiona de forma diferente en cada entorno de nube (véase más abajo)
• Las claves SSH son fáciles de generar, pero es difícil mantener un inventario actualizado de claves y relaciones de confianza.

Es importante recordar que, aunque algunas responsabilidades de seguridad han pasado del usuario al proveedor de la nube, siempre es responsabilidad del usuario gestionar y mantener sus claves SSH. Es fundamental garantizar la coherencia del control, las políticas y la visibilidad en todas las plataformas en la nube.

A pesar de su importancia, las personas no manejan las claves SSH de forma adecuada. En combinación con la nube y las cargas de trabajo mal configuradas, se crea una mayor superficie de amenaza. Los ataques que implican un uso indebido de SSH y de las claves SSH se han convertido en algo habitual. Se han vuelto más sofisticados cada día que pasa, a medida que el malware conocido se modifica para dirigirse a las claves SSH.

He aquí algunos ejemplos:

• Microsoft Azure reveló un ataque basado en Linux que utiliza fuerza bruta para inicios de sesión SSH basados en contraseña para comprometer máquinas virtuales.
• Un ataque contra servidores Exim (servidores de correo electrónico Linux) descarga un script de shell que añade una clave SSH a la cuenta root
• El malware GoLang es una campaña de mineros criptográficos que ataca servidores Linux y utiliza claves SSH descubiertas para atacar otros hosts y propagarse.
• El malware TrickBot actualiza su capturador de contraseñas para atacar OpenSSH y OpenVPN
• La red de bots FritzFrog fuerza el acceso a millones de direcciones IP SSH e inserta una clave ssh pública propiedad del atacante en el archivo de claves autorizadas para un acceso persistente.
• El malware Lemon_Duck utiliza el escaneo de puertos para encontrar máquinas que escuchen en el puerto 22 (SSH) y lanza ataques de fuerza bruta contra el nombre de usuario root y una lista de contraseñas codificadas.

La pregunta que surge es cómo mitigar estos ataques basados en SSH. Por suerte, existen algunas recomendaciones fáciles de aplicar.

Desactivar el inicio de sesión root

El inicio de sesión root está permitido en la mayoría de los sistemas Linux/Unix. Aunque esta recomendación parece contraintuitiva, si la autenticación por contraseña y la contraseña de root están habilitadas, el riesgo de ataque es alto.

Utilizar autenticación de clave pública

Los inicios de sesión basados en contraseñas son vulnerables a los ataques de fuerza bruta. En cambio, la autenticación basada en claves es más rápida y segura (siempre que se eduque a los usuarios y las claves se gestionen adecuadamente).

Utilice una frase de contraseña segura para las claves

Las claves privadas deben protegerse con una frase de contraseña. Utiliza las mejores prácticas para contraseñas y protege el almacenamiento y uso de claves privadas.

Establecer un puerto SSH personalizado

El puerto 22 es ampliamente conocido por los atacantes y el malware de escaneo de puertos. Cuando sea posible, oculte los servicios SSH configurando un nuevo puerto.

Mantener SSH actualizado

Mantén actualizados los paquetes de tu servidor (esto no se puede recalcar lo suficiente). Esto incluye parches de OpenSSH contra nuevas vulnerabilidades.

Además, una buena recomendación es limitar el número de pares de claves SSH por usuario. Esto también es crítico ya que la mayoría de los usuarios tienden a reutilizar las frases de contraseña en su clave SSH privada. Una sola clave comprometida puede ser la puerta de entrada a todos los recursos críticos corporativos.

La clave (valga el juego de palabras) para reducir su exposición al riesgo es una sólida gestión de claves. Esto es fundamental, especialmente en entornos multicloud. Como es lógico, empieza por hacer un inventario de lo que tienes.

Descubrir los archivos authorized_keys de los servidores y asignar las relaciones clave-confianza a usuarios y servidores. Esto sólo puede hacerse eficazmente mediante un inventario centralizado y automatizado.

Basándose en el inventario de claves, puede detectar y analizar los riesgos que surgen debido a servidores SSH y accesos de usuarios no autorizados, claves con acceso root y claves débiles o obsoletas. Las claves no utilizadas, desconocidas y huérfanas podrían ser claves de puerta trasera a la espera de ser explotadas por los adversarios.

Para mitigar estos riesgos, elimine las claves huérfanas y sin usar. Rote o sustituya las claves obsoletas o débiles, y garantice niveles mínimos de acceso de los usuarios.

Despliegue claves nuevas en un proceso controlado. Habilite el autoservicio para administradores y desarrolladores. Automatice el despliegue de claves. Almacene las claves privadas en una ubicación centralizada.

Esté atento a la rotación de claves ssh. Establece reglas para la duración máxima de las claves y avisa a los usuarios para que las roten antes de su "caducidad". Además, facilite a los usuarios la rotación de claves para minimizar cualquier fricción.

Una vez que haya establecido un entorno controlado, será más fácil identificar las claves falsas creadas fuera de banda. Audite periódicamente los tipos de claves, su rotación y su uso, y asegúrese de que el cese de un empleado incluya la revocación y eliminación de sus respectivas claves SSH.

Keyfactor SSH Key Manager está diseñado para hacer frente a los retos de la gestión de claves SSH en entornos modernos de múltiples nubes y DevOps. La herramienta permite una gestión escalable y automatizada del ciclo de vida de las claves SSH incluso en las implantaciones más complejas.

Eche un vistazo a nuestro eBook sobre 6 pasos para recuperar el control de sus claves SSH.