Hablemos de SSH, claves SSH y certificados SSH. SSH ha sido la forma de facto de obtener acceso y administrar sistemas Linux durante las últimas tres décadas. Si bien es robusto, capaz y útil, lamentablemente no fue diseñado para satisfacer las necesidades de las organizaciones actuales que se centran en la eficiencia, la seguridad y la escala. Aunque SSH facilita la administración de máquinas a través de una línea de comando interactiva, la administración de identidades en SSH es una molestia. Uno de los problemas centrales es que no podemos federar nuestras preciosas identidades corporativas y gastamos mucho tiempo y dinero; agregando MFA, acceso condicional y auditoría/ciclo de vida activo. En cambio, debemos confiar mucho para administrar identidades y credenciales descentralizadas, como claves SSH o incluso peores contraseñas. Estas técnicas de identidad de la “vieja escuela” no se adaptan a las necesidades de las empresas modernas que operan a escala.
Uno de los principios fundamentales de la gestión del ciclo de vida de la identidad es tener un sólido proceso de incorporación y baja. Con SSH independiente y tradicional, la incorporación de un nuevo usuario es una molestia, debe ir a cada uno de los puntos finales y agregar la clave de usuario al archivo autorizado_keys. Si bien esto (con suerte) lo hace un equipo de seguridad central, (con suerte) mantiene un inventario de quién posee cada clave y (con suerte) realiza auditorías de cada clave para asegurarse de que todavía sean necesarias.
Lo que hemos visto es que en la práctica esto (con suerte) es la excepción a la norma y, si se hace correctamente, es una operación muy costosa. Además, incluso si se siguen las mejores prácticas técnicas, todavía se producen fallas operativas; por ejemplo, un nuevo solicitante simplemente le pregunta a otro ingeniero que ya tiene acceso a la máquina y simplemente agrega la nueva clave. Esto crea un enorme agujero de seguridad, ya que no existe una administración central de claves y miedo. También hemos tenido clientes que han expresado su temor de romper algo cuando quitar una clave ha creado un entorno en el que se agregan claves pero nunca se eliminan. Tatu Ylonen, el inventor de SSH, mencionó que en su experiencia ha visto entre 50-200 claves por servidor y el 90% de ellas no se utilizan. Esto abre la puerta para que los atacantes encuentren una de esas claves y puedan acceder a los puntos finales, como un ex empleado que obtiene acceso a sus puntos finales e interrumpe sus servicios como en un ataque similar al que sufrió Cisco en 2018.
En pocas palabras, las claves SSH son difíciles de administrar y la mayoría de los ingenieros no reciben la capacitación adecuada en seguridad sobre las mejores prácticas para mantener seguras sus claves privadas. Tener una clave pública y privada, agregarlas al punto final, tener problemas, tratar de depurar esto y todo para seguir haciendo su “trabajo real” hace que los ingenieros tomen atajos, como proponer una clave para que todo el equipo pueda usar en la wiki del equipo, o dejar sus claves sin contraseña en sus escritorios, y muchas otras prácticas horribles que nuestros clientes han compartido con nosotros de forma confidencial.
La buena noticia es que existe una solución para esto: Certificados SSH. Se pueden emitir con una fecha de vencimiento y los puntos finales de Linux los admiten desde el primer momento. Desde un punto de vista operativo, sólo tiene que agregar la CA (Autoridad de certificación) al archivo de CA confiable y luego de eso; todos los certificados emitidos por esa CA que coincidan con los requisitos de la máquina le otorgarán acceso a esa máquina. Eliminando la necesidad de agregar y eliminar cada usuario en cada uno de sus puntos finales.
Este es un enfoque probado adoptado por líderes de la industria que se toman en serio la seguridad. Facebook publicó un documento técnico que explica cómo implementar certificados SSH, pero no abordó el desafío de que el proceso es muy manual y un administrador tiene que firmar cada certificado de usuario. Si bien es una mejora, nuevamente es solo una mejora iterativa. Facebook mencionó que tenían una herramienta que automatizaba ese proceso pero desafortunadamente es sólo para sus propios sistemas. Todo esto quiere decir que lo que sucede es que la mayoría de las organizaciones sin un equipo de ingeniería de seguridad de clase mundial usan claves SSH o certificados SSH, pero realmente tienen dificultades para administrar ambos operativamente y se dejan vulnerables.
Para obtener más detalles sobre los certificados SSH, consulte nuestra publicación de blog “cómo funcionan los certificados SSH”.
En Keytos no creemos en el status quo, fuimos fundados por la necesidad de hacerlo mejor que “suficientemente bueno”. Creemos que SSH merece el “tratamiento Keytos” y a partir de hoy estamos lanzando EZSSH, basado en certificados SSH y una automatización confiable y segura. Creamos una solución de cliente SSH que:
Por lo general, los sistemas de gestión de identidades necesitan tener un agente con privilegios de administrador ejecutándose en sus puntos finales para agregar y eliminar usuarios. En ataques recientes como el ataque de Solar Winds se recordó a la comunidad de seguridad la riesgos y desafíos asociados con el uso de herramientas e infraestructura de terceros. Dado que OpenSSH admite de forma nativa los certificados SSH y solo se debe agregar la clave CA al punto final, EZSSH no necesita ejecutar un agente. El único paso para lograr que su punto final confíe en el certificado es ejecutar un script que agregue la clave de CA a las CA confiables y luego el punto final confiará en los certificados emitidos con esa CA.
Aquí hay un guión de muestra:
#!/bin/bash
authkeys=$(awk '$1 ~ /^TrustedUserCAKeys/' /etc/ssh/sshd_config)
if [ ! -z "$authkeys" ]
then
echo "TrustedUserCAKeys found removing from file"
awk '$1 !~ /^TrustedUserCAKeys/' /etc/ssh/sshd_config > tmp.txt
cat tmp.txt > /etc/ssh/sshd_config
rm tmp.txt
fi
authPrincipals=$(awk '$1 ~ /^AuthorizedPrincipalsFile/' /etc/ssh/sshd_config)
if [ ! -z "$authPrincipals" ]
then
echo "AuthorizedPrincipalsFile found removing from file"
awk '$1 !~ /^AuthorizedPrincipalsFile/' /etc/ssh/sshd_config > tmp.txt
cat tmp.txt > /etc/ssh/sshd_config
rm tmp.txt
fi
echo "Adding trusted CA file to /etc/ssh/sshd_config"
echo "TrustedUserCAKeys /etc/ssh/trusted_ca_keys.pub" >> /etc/ssh/sshd_config
echo "Adding Authorized Principals file to /etc/ssh/sshd_config"
echo "AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u" >> /etc/ssh/sshd_config
echo "Adding CA Public Key"
echo "YOUR_CA_PUBLIC_KEY" >> /etc/ssh/trusted_ca_keys.pub
EZSSH corrige lo que está roto con las claves SSH y los certificados SSH, y tiene que ver con la escala, la administración y el error humano (desafíos operativos), todas estas mejoras conducen a una mejor seguridad que está directamente relacionada con la reducción de los costos operativos y una mejor postura de gestión de riesgos. . Hemos mejorado SSH implementando automatización y ayudando a los líderes de TI a implementar las mejores prácticas de operaciones de seguridad.
Desafortunadamente, los usuarios típicos no siguen las mejores prácticas y, dado que las claves SSH no tienen fechas de vencimiento, es muy fácil para su equipo de seguridad pasar por alto una clave comprometida/una clave de un ex empleado o no eliminar ninguna. claves porque podrían tener miedo de romper algo en producción.
Los certificados SSH solucionan todos esos problemas al tener certificados con límite de tiempo que solo se usan durante unas pocas horas, con menos claves para administrar en el punto final (solo la clave CA) y EZSSH que administra las claves privadas efímeras para el usuario, lo que deja poco espacio para las malas prácticas para exponer a su organización a un compromiso.
EZSSH no solo dificulta la entrada de los atacantes, sino que también ayuda a su equipo de seguridad a detectar accesos no autorizados al proporcionar registros de auditoría fáciles de consumir. Las capacidades de registro integradas en EZSSH se pueden correlacionar con sus registros de autenticación de Azure AD y sus registros de acceso SSH, reuniendo las dos tecnologías en un “único panel” para que las analicen.
¿La mejor parte de todo esto? ¡Mejoras en la experiencia del usuario! Como ingeniero, siempre odié tener que esperar para acceder a un nuevo servidor. Primero tuve que crear una nueva clave, enviar la clave pública al administrador, esperar a que la agregaran y luego, una vez me cansé de esperar y comencé a trabajar en otra cosa. Recibí un correo electrónico diciendo que se agregó la clave.
¡Con EZSSH, este proceso agotador se acabó! Ahora, para ser justos, dependiendo de sus políticas de acceso, es posible que deba unirse a un grupo AAD o solicitar aprobación en EZSSH. Sin embargo, una vez agregado, todo lo que tienes que hacer es ejecutar:
ezssh ssh -e username@endpoint
Nos haremos cargo del resto. ¡No más gestión de claves SSH! ¿Su gerente le dio una lista de puntos finales a los que debe conectarse y cambiar algo? Utilice nuestro comando ssh por lotes
ezssh batchSSH -f endpoints.csv
O mejor aún, pasa el comando que quieras usar:
ezssh batchSSH -f endpoints.csv -c “echo ezssh rocks!”
En resumen, EZSSH mejora las bases de SSH al utilizar certificados SSH que se administran de forma centralizada y automatizan la administración de claves SSH sin agente, de una manera fácil de usar, segura y escalable.
¿Entonces, Qué esperas? Haga que sus ingenieros trabajen menos y su organización sea más segura hablando con un experto en identidad hoy.
