A medida que las organizaciones pasan a un modelo de confianza cero, SSH sin contraseña se convierte en la única forma de proteger sus puntos finales SSH. Lo primero que me viene a la mente es utilizar llaves SSH. Son criptográficamente seguros y nativos de Linux, por lo que no se debe ejecutar ningún PAM o agente personalizado en el terminal; sin embargo, las llaves SSH son difíciles de administrar:
1) Las llaves SSH no caducan.
2) Es una tarea muy manual y tediosa realizar un seguimiento de quién posee cada llave.
3) Cada llave debe agregarse y eliminarse manualmente en cada servidor.
Debido a esas complicaciones, las llaves SSH tradicionales no pueden escalarse para satisfacer las necesidades actuales de la nube. Como resultado, muchas organizaciones buscan una solución de administración de llaves SSH donde las llaves se administren de manera centralizada y el servicio pueda rotarlas.
Si bien la administración centralizada de las llaves SSH parece una excelente manera de resolver el problema del acceso SSH, solo pone una curita en la herida en lugar de resolver el problema con una solución moderna. Estos son algunos de los muchos inconvenientes de centralizar la gestión de llaves SSH:
La solución de administración de llaves SSH requiere acceso a sus puntos finales: Para administrar el acceso a sus puntos finales, la mayoría de las soluciones de administración de llaves SSH necesitan acceso a sus puntos finales para crear las credenciales justo a tiempo (JIT) o para rotar las llaves SSH para cumplir con sus requisitos de cumplimiento. Esto limita el uso de estas herramientas a dispositivos a los que se puede acceder desde donde está alojada la solución, además abre la puerta a ataques como el ataque SolarWinds donde el agente se ve comprometido dando acceso al atacante a todos los dispositivos administrados por la aplicación.
Las llaves SSH se comparten: La mayoría de las soluciones de administración de llaves SSH configuran una llave para acceder al dispositivo (generalmente la misma llave se comparte entre muchos dispositivos) y luego esa llave se distribuye a los usuarios que tienen acceso a la bóveda. Esto crea un problema de seguridad en el que no se sabe quién fue la persona que usó la llave para realizar la acción y, dado que las llaves se comparten, se deben rotar cada vez que una persona abandona el equipo.
Sin control sobre cómo el usuario usa la llave: Dado que estas soluciones aún dependen de la descarga de una llave SSH en la computadora del usuario, usted no tiene control sobre lo que el usuario hace con esa llave. ¿Lo están protegiendo con una contraseña segura? ¿Lo están copiando a su computadora personal? ¿Lo están compartiendo con otros usuarios? Debemos recordar que la mayoría de los ingenieros no están completamente capacitados en las mejores prácticas para administrar llaves criptográficas y pueden cometer un error que podría comprometer la infraestructura; nuestro trabajo como profesionales de la seguridad es garantizar que eso no suceda.
Sin acceso condicional: Dado que la autenticación en el punto final todavía utiliza llaves SSH en lugar de SSO usando su identidad corporativa, no hay forma de implementar medidas de seguridad como el acceso condicional, lo que hace que su infraestructura más crítica sea la más vulnerable.
Después de que me llovió en el desfile de llaves SSH administradas, debo tener una solución, ¿verdad? Bueno, la respuesta es certificados SSH, y aunque me encantaría atribuirme el mérito de la idea, escuché sobre ellos por primera vez, gracias. al documento técnico de Facebook. Lo sé, ¿quién iba a pensar que alguien aprendería algo gracias a Facebook?. Los certificados SSH, al igual que las llaves SSH, son credenciales criptográficamente seguras y usted puede crear fácilmente certificados SSH usted mismo con ssh-keygen en Linux. Si bien los certificados SSH son similares a las llaves SSH, solucionan la mayoría de los problemas que tienen las llaves SSH; caducan, tienen información sobre el usuario y solo se debe agregar la CA (autoridad de certificación) a los puntos finales, lo que elimina la necesidad de agregar y eliminar manualmente cada usuario de cada punto final. ¿La mejor parte? A diferencia de AD uniéndose a puntos finales SSH, esto es nativo de Linux y no requiere que el punto final tenga conectividad.
Como probablemente vio en el documento técnico de Facebook o nuestra guía sobre cómo crear Certificados SSH, mientras que los certificados SSH son excelentes, a menos que quieras sentarte todo el día creando certificados SSH para tus ingenieros. Necesita una solución para convertir su identidad de Entra ID en un certificado SSH. ¡Ahí es donde entra EZSSH!
EZSSH es una Autoridad de Certificación SSH que le permite crear políticas de acceso basadas en sus grupos de Entra ID o Azure RBAC y otorgar acceso JIT a sus puntos finales SSH, lo que le permite transferir toda la seguridad de su identidad corporativa, como políticas de acceso condicional y membresías de grupo a Linux sin tener que ejecutar agentes con privilegios elevados en sus dispositivos.
