En los entornos de TI, algunos secretos se gestionan bien y otros pasan desapercibidos. A continuación, se incluye una lista rápida de los tipos de secretos que suelen gestionar las empresas, incluido un tipo que deberían gestionar: Contraseñas [x]
Certificados TLS [x]
Cuentas [x]
Claves SSH ??? Los secretos enumerados anteriormente suelen estar protegidos con soluciones de gestión de acceso privilegiado (PAM) o similares. Sin embargo, la mayoría de los proveedores de PAM tradicionales apenas hablan de la gestión de claves SSH. La razón es sencilla: no tienen la tecnología para hacerlo correctamente. Podemos demostrarlo. Todos nuestros clientes de gestión de claves SSH han implementado un PAM tradicional, pero se dieron cuenta de que no podían gestionar claves SSH con él. En el mejor de los casos, los PAM tradicionales pueden descubrir, y mucho menos gestionar, el 20% de todas las claves. Entonces, ¿a qué se debe todo el alboroto sobre las claves SSH? Las claves SSH son credenciales de acceso en el protocolo Secure Shell (SSH). En muchos sentidos, son como contraseñas, pero funcionalmente diferentes. Además de eso, las claves tienden a superar en número a las contraseñas, especialmente en entornos de TI de larga data, en una proporción de 10:1. Si bien solo algunas contraseñas son privilegiadas, casi todas las claves SSH abren puertas a algo valioso. Una clave también puede abrir puertas a varios servidores, como una llave maestra en las mansiones antiguas. Una clave raíz permite el acceso de administrador a un solo servidor o a varios. Después de realizar una evaluación de riesgos con nosotros, uno de nuestros clientes descubrió una clave raíz que permitía el acceso a TODOS sus servidores. Otro riesgo es que cualquiera puede autoabastecerse claves SSH. No se administran de forma centralizada y es por diseño. Es por eso que la proliferación de claves es un problema persistente en los entornos de TI a gran escala. Hay aún más: las claves no vienen con una identidad de forma predeterminada, por lo que compartirlas o duplicarlas es muy fácil. Además, con terceros. De forma predeterminada, las claves nunca caducan. Además de todo esto, existen conexiones interactivas y automatizadas, las últimas de las cuales son más frecuentes. Se ejecutan millones de conexiones automatizadas de aplicación a aplicación, servidor a servidor y máquina a máquina utilizando SSH todos los días, pero no hay suficientes organizaciones (la mayoría de ellas nuestros clientes) que tengan control sobre las credenciales SSH de la máquina. Estoy seguro de que has entendido el punto: tu entorno de TI puede estar plagado de claves para tu reino, pero no sabes cuántas hay, quién las está usando, cuáles son legítimas y cuáles deberían eliminarse, las claves no tienen fecha de caducidad y se pueden crear más a voluntad sin una supervisión adecuada. El problema clave es tu problema clave. ¿Por qué los PAM tradicionales no pueden manejar claves SSH? Debido a que las claves SSH son funcionalmente diferentes a las contraseñas, los PAM tradicionales no las gestionan muy bien. Los PAM tradicionales se crearon para almacenar contraseñas, e intentan hacer lo mismo con las claves. Sin entrar en demasiados detalles sobre la funcionalidad de las claves (como las claves públicas y privadas), almacenar claves privadas y entregarlas cuando se solicita simplemente no funciona. Las claves deben estar protegidas en el lado del servidor, de lo contrario, mantenerlas bajo control es un esfuerzo inútil. Además, tu solución necesita descubrir claves primero para gestionarlas. La mayoría de los PAM no pueden. También hay archivos de configuración de claves y otros elementos clave (!) involucrados que los PAM tradicionales pasan por alto. Lea más en el siguiente documento: Su PAM no está completo sin la administración de claves SSH Incluso si su organización administra el 100% de sus contraseñas, lo más probable es que aún le falte el 80% de sus credenciales críticas si no administra claves SSH. Como inventores del protocolo Secure Shell (SSH), en SSH Communications Security somos la fuente original de la credencial de acceso llamada clave SSH. Conocemos los entresijos de su administración. Su PAM no está a prueba de futuro sin acceso sin credenciales Volvamos al tema de las contraseñas. Incluso si las tiene en bóveda, no las está administrando de la mejor manera posible. Los entornos modernos y dinámicos (que utilizan servidores en la nube internos o alojados, contenedores u orquestación de Kubernetes) no funcionan bien con bóvedas o con PAM que se crearon hace 20 años. Por eso ofrecemos un acceso efímero moderno, en el que los secretos necesarios para acceder a un objetivo se otorgan justo a tiempo para la sesión y caducan automáticamente una vez que se realiza la autenticación. Esto no deja contraseñas ni claves que administrar, en absoluto. Nuestra solución también es no intrusiva: implementarla requiere cambios mínimos en su entorno de producción. ¿Qué le parece esto para reducir la superficie de ataque, eliminar la complejidad, ahorrar costos y minimizar el riesgo? Lea más aquí: Entonces, la mejor manera de administrar contraseñas Y claves es no tener que administrarlas en absoluto y pasar a la administración de secretos efímeros en su lugar. Así: «Ojalá todavía estuviera rotando contraseñas y claves». ¡Ningún cliente lo ha dicho nunca! Una vez que se deja de usar credenciales, no se vuelve atrás. Escuche el ejemplo de nuestros clientes que han calificado nuestra solución con una puntuación NPS de 71, lo cual es astronómico en el campo de la ciberseguridad. Los PAM tradicionales han funcionado bien hasta ahora, pero es hora de preparar su entorno para el futuro con una solución moderna que le permita dejar de usar contraseñas y claves. A un ritmo que le resulte cómodo. Consulta nuestra suite PrivX Zero Trust para aprender a gestionar el acceso y los secretos de forma integral. ¿Te ha parecido interesante este artículo? Este artículo es una contribución de uno de nuestros valiosos socios. Síguenos en Twitter y LinkedIn para leer más contenido exclusivo que publicamos.
Deja una respuesta