Una Guía para la Gestión de Claves SSH en Entornos Multi-Cloud

A medida que más y más empresas trasladan sus operaciones y datos a entornos multinube, las preguntas en torno a la gestión de claves SSH aumentan. Mark Thompson, vicepresidente sénior de gestión de productos, y Ryan Sanders, gerente de marketing de productos, de Keyfactor, respondieron a estas preguntas durante su sesión conjunta en la Cumbre Virtual Critical Trust 2020.

En este blog, desglosaré los conceptos clave cubiertos en nuestra sesión y proporcionaré las mejores prácticas para la gestión de claves SSH en entornos multinube.

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

¿Por qué? Porque SSH es una forma conveniente de autenticar y asegurar conexiones, sin mencionar que viene integrado en los sistemas basados en Linux y Unix. SSH es ampliamente utilizado por los administradores de sistemas para acceder a sistemas de forma remota y, cada vez más, en procesos automatizados, como la copia de seguridad segura o las 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 de contraseñas y no requieren interacción del usuario para habilitar el acceso, lo que las hace ideales para procesos automatizados.

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

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

Si bien la mayoría de las organizaciones están familiarizadas con la PKI y la gestión de certificados X.509, los desafíos relacionados con las claves SSH son completamente diferentes.

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

A continuación, se presenta un desglose de las principales diferencias:

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

• 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íticas: A menudo se concede acceso de root incluso cuando no es necesario.
• Visibilidad limitada: No existe una visibilidad centralizada de las claves autorizadas y privadas.
• Remediación lenta: Los equipos de seguridad dudan en revocar o rotar claves.

Otra causa de la proliferación de claves SSH es la rotación de personal. Si bien existen procesos estandarizados para eliminar al personal saliente del Directorio Activo, estos 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 engorroso y propenso a riesgos.

Según los hallazgos del Estudio Global de Tendencias de Cifrado de 2020 de nCipher y Ponemon, el 57% de los equipos de seguridad admite que las claves SSH son difíciles o muy difíciles de gestionar.

Impulsadas por iniciativas empresariales para migrar operaciones y datos a la nube, las claves SSH se enfrentan a una nueva normalidad. Existen diversas razones para el aumento del uso de claves SSH en las plataformas en la nube:

• El 90% de todas las cargas de trabajo en la nube pública actuales se ejecutan en Linux (del cual SSH es un componente central).
• Múltiples equipos utilizan SSH en diferentes nubes y herramientas de gestión de 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 señal de los tiempos, GitHub anunció recientemente que están dejando de usar contraseñas, siendo las claves SSH una alternativa principal. A medida que los desarrolladores utilizan claves SSH en entornos altamente automatizados y distribuidos, los riesgos no hacen más que aumentar.

Estos desarrollos subrayan que la gestión y protección de las claves SSH en la nube es fundamental para las empresas actuales. Sin embargo, las diferencias entre proveedores de la nube aumentan la complejidad en la gestión de claves SSH, especialmente a medida que las empresas adoptan estrategias multinube.

• 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 a continuación).
• 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, incluso cuando algunas responsabilidades de seguridad se han trasladado del usuario al proveedor de la nube, siempre es responsabilidad del usuario gestionar y mantener sus claves SSH. Garantizar la coherencia del control, las políticas y la visibilidad en todas las plataformas en la nube es fundamental.

A pesar de su importancia, las claves SSH no se gestionan de forma adecuada. Esto, sumado a las configuraciones erróneas en la nube y las cargas de trabajo, amplía la superficie de ataque. Los ataques que implican el uso indebido de SSH y sus claves son ya una práctica habitual. Además, han ganado en sofisticación con cada día que pasa, a medida que el malware conocido se adapta para atacar las claves SSH.

Estos son solo algunos ejemplos:

• Microsoft Azure reveló un ataque basado en Linux que utiliza la fuerza bruta para comprometer máquinas virtuales (VM) a través de inicios de sesión SSH basados en contraseña.
• 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 de root.
• El malware GoLang es una campaña de criptominado que se dirige a servidores Linux y utiliza las claves SSH descubiertas para atacar hosts adicionales y propagarse.
• El malware TrickBot actualizó su capturador de contraseñas para dirigirse a OpenSSH y OpenVPN.
• La botnet 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 identificar máquinas que escuchan en el puerto 22 (SSH) y lanza ataques de fuerza bruta contra el usuario root y una lista de contraseñas predefinidas.

La cuestión que se plantea es cómo mitigar estos ataques basados en SSH. Afortunadamente, existen algunas recomendaciones de fácil implementación.

Deshabilitar el inicio de sesión de root

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

Utilizar autenticación por clave pública

Los inicios de sesión basados en contraseña son vulnerables a ataques de fuerza bruta. En cambio, la autenticación basada en claves es más rápida y segura (siempre y cuando los usuarios estén debidamente informados y las claves se gestionen de forma adecuada).

Utilizar una frase de contraseña robusta para las claves

Las claves privadas deben seguir protegiéndose con una frase de contraseña. Adopte las mejores prácticas para contraseñas y proteja el almacenamiento y uso de las claves privadas.

Establecer un puerto SSH personalizado

El puerto 22 es ampliamente conocido por los atacantes y el malware de escaneo de puertos. Oculte los servicios SSH configurando un puerto diferente, siempre que sea posible.

Mantener SSH actualizado

Mantenga sus paquetes de servidor actualizados (esto es de suma importancia). Esto incluye los parches de OpenSSH contra nuevas vulnerabilidades.

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

La clave (nunca mejor dicho) para reducir su exposición al riesgo reside en una gestión de claves sólida. Esto es fundamental, especialmente en entornos multinube. Como es lógico, el primer paso es realizar un inventario de las claves existentes.

Descubra los archivos authorized_keys en los servidores y mapee las relaciones de confianza de claves con usuarios y servidores. Esto solo puede lograrse de manera efectiva mediante su incorporación a un inventario centralizado y automatizado.

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

Para mitigar estos riesgos, elimine cualquier clave no utilizada y huérfana. Rote o reemplace las claves obsoletas/débiles y garantice niveles mínimos de acceso de usuario.

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

Manténgase atento a la rotación de claves SSH. Establezca reglas para la vida útil máxima de las claves y alerte a los usuarios para que las roten antes de su "vencimiento". Además, simplifique a los usuarios la rotación de claves para minimizar cualquier fricción.

Una vez que haya configurado un entorno controlado, es más fácil identificar claves no autorizadas creadas fuera de banda. Audite regularmente los tipos de claves, su rotación y su uso, y asegúrese de que la baja de empleados incluya la revocación y eliminación de las claves SSH correspondientes.

El SSH Key Manager de Keyfactor está diseñado para abordar los desafíos de la gestión de claves SSH en entornos modernos de multinube y DevOps. La herramienta permite una gestión escalable y automatizada del ciclo de vida de las claves SSH incluso en las implementaciones más complejas.

Consulte nuestro eBook sobre los 6 pasos para retomar el control de sus claves SSH.