¿Sabías que, según un estudio de 2017 de la Universidad de Maryland, un ataque de ciberseguridad ocurre cada 39 segundos ? Y eso fue en 2017; ese número solo se ha reducido y se ha vuelto más alarmante en los años posteriores, destacando la necesidad crítica de que las organizaciones prioricen el refuerzo de sus estrategias de defensa. Los métodos de seguridad tradicionales como firewalls, VPN y políticas de contraseñas, aunque son facetas esenciales de un plan de seguridad, no abordan los riesgos de seguridad inherentes presentes en los niveles de código o infraestructura dentro de las organizaciones. Esta brecha podría explicar el cambio hacia dominios de seguridad menos convencionales, como el cumplimiento, el desarrollo y la ingeniería.
Hablando con devops, la atención se centra cada vez más en salvaguardar la infraestructura. A menudo, esta protección gira principalmente en torno al protocolo de red SSH. SSH es crucial para el acceso remoto seguro, la autenticación y las transferencias de datos cifrados. En configuraciones SSH estándar de servidor-cliente, el servidor acepta un cliente si su clave pública coincide con las autorizadas, y los clientes confían en la clave pública de un servidor durante su interacción inicial; sin embargo, esta configuración no es necesariamente tan buena como parece.
Definitivamente hay algunas cosas a tener en cuenta con una configuración SSH básica de servidor-cliente. En primer lugar, los archivos authorized_keys pueden crecer demasiado y resultar difíciles de administrar. En segundo lugar, muchos clientes SSH siguen una política de “confianza en el primer uso” (TOFU), que impone al usuario la carga de decidir en qué confiar; esto puede llevar a que los usuarios ignoren las advertencias y se conecten inadvertidamente a hosts que no son de confianza, exponiendo sus máquinas a posibles amenazas ataques de intermediario (MITM).
¿Una posible solución? Pasar de claves públicas a certificados SSH y CA para establecer confianza. Los certificados SSH permiten a los administradores implementar reglas específicas para su emisión y establecer pautas de vencimiento. Consulte nuestro blog sobre cómo configurar certificados SSH para obtener más información sobre cómo configurarlos usted mismo.
A nivel mundial, algunas de las empresas más grandes están abordando las vulnerabilidades SSH adoptando cambios significativos, como no emitir claves o implementar una confianza cero modelo para autenticación y autorización de usuarios o dispositivos de red. El concepto de confianza cero desafía los supuestos de confianza tradicionales sobre el tráfico de la red interna y el acceso otorgado a empleados y terceros.
El modelo BeyondCorp de Google es un ejemplo destacado de implementación de confianza cero. A diferencia de otras empresas que han agregado múltiples capas de firewalls, restricciones y VPN para el acceso al sistema, Google ha adoptado un enfoque diferente: en lugar de depender de un perímetro de red, ¡ha hecho que sus sistemas internos sean accesibles a través de la Internet pública! Este enfoque requiere que todos los sistemas dentro del marco de BeyondCorp estén construidos y fortalecidos tan sólidamente como los destinados a la Internet pública.
Ahora que ya hemos aclarado los antecedentes, echemos un vistazo a tres de las empresas más destacadas del mundo y cómo abordan SSH:
El equipo de seguridad de Facebook prefiere usar certificados en lugar de autenticación de clave pública por varias razones:
1) La gestión de cuentas locales se vuelve cada vez más compleja a medida que la empresa se expande.
2) Depender de la autenticación central crea un único punto de falla riesgoso.
3) Aumentar la confianza de los pares de claves individuales es prácticamente inviable.
Al diseñar una solución que se adapta a sus necesidades, Facebook adoptó un concepto comúnmente utilizado en la gestión del tráfico HTTPS: configuraron sus servidores SSH para confiar en su CA y en cualquier certificado que autentique. El paso siguiente implica la autorización; el certificado incluye derechos y privilegios de acceso específicos para empleados individuales. Esto garantiza que cada persona tenga precisamente el nivel de acceso necesario para su función.
El equipo de seguridad de Netflix creó su CA BLESS (Bastion’s Lambda Ephemeral SSH Service), integrándola con el espíritu de ingeniería de “libertad y responsabilidad” de la empresa. Este enfoque espera que los ingenieros:
1) Compartir información de forma activa y transparente.
2) Explique todas las razones detrás de sus acciones.
3) Gestionar todos los servicios desarrollados por su equipo.
En consecuencia, casi todos los ingenieros de Netflix requieren acceso SSH a sus servicios, con el objetivo de minimizar las barreras a este acceso.
BLESS opera en AWS Lambda y emplea el servicio de administración de claves de Amazon para el cifrado. La arquitectura bastión SSH en Netflix agiliza el proceso al utilizar SSO para la autenticación de usuarios y emitir certificados que son válidos solo por un período breve. Además, la empresa mejora su seguridad mediante el monitoreo automatizado de las actividades de SSH y la activación de alertas ante cualquier comportamiento anormal o sospechoso.
El equipo de seguridad de Uber identificó varios problemas con el modelo tradicional de par de claves pública/privada SSH. La gestión de claves era problemática y no existía un sistema automatizado para establecer fechas de vencimiento para las claves. Cuanto más tiempo permanezca válida una clave, mayor será el riesgo de que se pierda o se vea comprometida.
Otra preocupación era la abrumadora frecuencia de solicitudes 2FA que enfrentaban los empleados. Las indicaciones constantes de 2FA podrían generar fatiga en las alertas, lo que podría provocar que los empleados aprueben indiscriminadamente cualquier notificación 2FA anterior, un gran no-no en materia de seguridad.
Aunque la mayoría de estos desafíos se abordaron cuando Uber pasó a utilizar certificados SSH con OpenSSH 5.4, necesitaban un sistema que pudiera emitir certificados tanto de usuario como de host y autenticar usuarios continuamente, en lugar de hacerlo solo en un solo momento. Para satisfacer estas necesidades, Uber desarrolló la Uber SSH Certificate Authority (USSHCA) y un PAM módulo para garantizar la validez continua del usuario. La USSHCA emite certificados SSH, cada uno con una vida útil determinada y configurable según el rol o grupo del empleado, a los empleados de Uber.
Si está leyendo este artículo, entonces la gestión SSH es, como mínimo, algo que le interesa e incluso podría ser algo que esté intentando facilitar dentro de su organización. Si bien puedes crear tu propia Autoridad de Certificación SSH en Linux en minutos, si quieres hacer SSH mejor que Algunas de las empresas más grandes del mundo y por una fracción del costo, considere usar EZSSH. EZSSH simplifica el proceso al eliminar la necesidad de administrar, actualizar y eliminar claves SSH en todos los usuarios y hosts; esto se logra mediante el uso de certificados SSH que operan detrás de escena. Para el usuario, el proceso se siente como la experiencia SSO habitual, utilizando su identidad Azure AD (o Entra ID). Este enfoque elimina eficazmente el riesgo de que los malos actores comprometan las claves SSH en los escritorios de los ingenieros.
Si esto es algo de su interés, o si simplemente desea obtener más información, no dude en programar una consulta GRATUITA con uno de nuestros ex expertos en identidad de Microsoft para analizar cómo EZSSH puede ayudar a su organización a SSH como nadie más puede hacerlo sin necesidad de obtener una segunda hipoteca para costearlo.
