Hace algunos años, la arquitectura de seguridad de Cloudflare era una arquitectura clásica de VPN perimetral. Para realizar su trabajo, nuestros empleados utilizaban nuestra VPN corporativa para conectarse a todo el conjunto de aplicaciones y recursos internos. Aplicábamos una autenticación en dos fases con contraseñas de un solo uso de duración definida (TOTP). Para ello, utilizábamos un sistema de autenticación, como Google Authenticator o Authy, al iniciar sesión en la VPN. Sin embargo, solo algunas aplicaciones internas contaban con una segunda capa de autenticación. Externamente, esta arquitectura parece sólida, pero el modelo de seguridad es débil. Hace poco analizábamos en detalle la mecánica de un ataque de phishing que impedimos, que explica cómo los ciberdelincuentes pueden lanzar ataques de phishing contra aplicaciones "protegidas" con métodos de autenticación en dos fases, como las TOTP. Afortunadamente, hace tiempo que dejamos atrás las TOTP y las sustituimos por claves de seguridad de hardware y Cloudflare Access. En esta publicación explicamos cómo lo hicimos.
La solución al problema del phishing es un protocolo de autenticación multifactor (MFA) denominado FIDO2/WebAuthn. Actualmente, todos los empleados de Cloudflare inician sesión con FIDO2 como su multifactor seguro y se autentican en nuestros sistemas utilizando nuestros propios productos Zero Trust. Nuestra nueva arquitectura es a prueba de phishing y nos permite aplicar más fácilmente el control de acceso de privilegio mínimo.
Una breve explicación sobre la terminología de las claves de seguridad y lo que utilizamos
En 2018, sabíamos que queríamos migrar a MFA a prueba de phishing. Habíamos observado evilginx2 y constatado la madurez de las TOTP y de los sistemas de autenticación móviles antiphishing basados en el envío push. La única MFA a prueba de phishing que resistía los ataques de ingeniería social y de robo de credenciales eran las claves de seguridad que implementaban estándares FIDO. La MFA basada en FIDO añade nueva terminología, como, por ejemplo, FIDO2, WebAuthn, claves de hardware, claves de seguridad y, específicamente, la YubiKey (el nombre de un reconocido fabricante de claves de hardware), a la que haremos referencia durante esta publicación.
WebAuthn hace referencia al estándar de autenticación web. Explicamos detalladamente el funcionamiento de este protocolo cuando anunciamos la compatibilidad con las claves de seguridad en el panel de control de Cloudflare.
CTAP1(U2F) y CTAP2 hacen referencia al protocolo entre el cliente y el sistema de autenticación que detalla cómo interactúan los dispositivos de software o hardware con la plataforma que ejecuta el protocolo WebAuthn.
FIDO2 es el conjunto formado por estos dos protocolos que se utilizan para la autenticación. Las diferencias no importan, pero la nomenclatura puede generar confusión.
Lo más importante que debemos saber es que todos estos protocolos y estándares se han desarrollado para crear protocolos de autenticación abiertos a prueba de phishing, y que se pueden implementar con un dispositivo de hardware. En software, se implementan con Face ID, Touch ID, Windows Assistant o aplicaciones similares. En hardware, se utiliza una YubiKey u otro dispositivo físico aparte para la autenticación con USB, Lightning o NFC.
FIDO2 es a prueba de phishing porque implementa un sistema de desafío/respuesta que está protegido criptográficamente, y el protocolo del desafío incorpora el dominio o el sitio web específico en el que se está autenticando el usuario. Al iniciar sesión, la clave de seguridad generará una respuesta distinta en el sitio example.net que cuando el usuario intenta legítimamente iniciar sesión en el sitio example.com.
A lo largo de los años, en Cloudflare hemos facilitado a nuestros empleados varios tipos de claves de seguridad, pero hoy en día facilitamos a todos ellos dos tipos de claves de seguridad distintas, validadas según el estándar FIPS. La primera es una YubiKey 5 Nano o YubiKey 5C Nano, que nuestros empleados deben mantener siempre en la ranura USB de sus portátiles. La segunda es la YubiKey 5 NFC o YubiKey 5C NFC, que funciona tanto en los equipos de escritorio como en los dispositivos móviles mediante NFC o USB-C.
A finales de 2018, distribuimos las claves de seguridad en un evento para toda la empresa. Pedimos a todos nuestros empleados que inscribieran sus claves, se autenticaran con ellas y realizaran sus preguntas sobre los dispositivos en un breve taller. El programa tuvo un gran éxito, pero aún había aspectos a mejorar y aplicaciones que no funcionaban con WebAuthn. No estábamos listos para la implementación integral de las claves de seguridad. Necesitábamos alguna solución intermedia mientras acabábamos de resolver algunos problemas.
El comienzo: implementación selectiva de las claves de seguridad con Cloudflare Zero Trust
Somos responsables del mantenimiento de miles de aplicaciones y servidores, que estaban protegidos mediante nuestra VPN. Empezamos a migrar todas estas aplicaciones a nuestro proxy de acceso Zero Trust al mismo tiempo que facilitábamos a nuestros empleados su conjunto de claves de seguridad.
Cloudflare Access permitió que nuestros empleados accedieran de forma segura a los sitios que anteriormente estaban protegidos mediante la VPN. Cada servicio interno validaba una credencial firmada para autenticar un usuario y garantizaba que el usuario había iniciado sesión con nuestro proveedor de identidad. Cloudflare Access era necesario para nuestro despliegue de las claves de seguridad, ya que nos proporcionaba una herramienta para implementar selectivamente las primeras aplicaciones internas que requerirían la autenticación con una clave de seguridad.
Para incorporar nuestras aplicaciones a nuestros productos Zero Trust utilizamos Terraform. Esta es la política de Cloudflare Access donde implementamos por primera vez las claves de seguridad. Configuramos Cloudflare Access para utilizar OAuth2 al realizar la integración con nuestro proveedor de identidad. El proveedor de identidad notifica a Access el tipo de segundo factor utilizado como parte del flujo OAuth.
En nuestro caso, swk es una prueba de posesión de una clave de seguridad. Si un usuario ha iniciado sesión y no ha utilizado su clave de seguridad, verá un útil mensaje de error que le pedirá que vuelva a iniciar sesión y entre su clave de seguridad cuando se le solicite.
La implementación selectiva cambió de inmediato la trayectoria de nuestra implementación de las claves de seguridad. Iniciamos la implementación en un único servicio el 29 de julio de 2020, y la autenticación con las claves de seguridad se amplió enormemente durante los dos meses siguientes. Esto paso fue crucial para brindar a nuestros empleados la oportunidad de familiarizarse con la nueva tecnología. Un periodo de implementación selectiva debería durar como mínimo un mes, para que también puedan beneficiarse aquellos empleados que estén de vacaciones. No obstante, en retrospectiva, no es necesario que dure mucho más.
¿Qué otras ventajas de seguridad nos ha aportado la migración de nuestras aplicaciones a nuestros productos Zero Trust y fuera de la VPN? Con las aplicaciones heredadas, o las aplicaciones que no implementan SAML, esta migración era necesaria para la aplicación del control de acceso basado en roles (RBAC) y el principio del privilegio mínimo. Una VPN autenticará el tráfico de tu red, pero tus aplicaciones no sabrán a quién pertenece este tráfico de red. Nuestras aplicaciones tenían dificultades para aplicar varios niveles de permisos. Cada una de ellas tenía que reinventar su propio esquema de autenticación.
Cuando incorporamos Cloudflare Access, creamos grupos para aplicar RBAC e indicar a nuestras aplicaciones qué nivel de permiso debía tener cada persona.
En este sitio, solo los miembros del grupo ACL-CFA-CFDATA-argo-config-admin-svc tienen acceso. Este sitio garantiza que el usuario ha utilizado su clave de seguridad al iniciar sesión, sin que se requiera ninguna complicada integración de SAML o OAuth. Tenemos más de 600 sitios internos que utilizan este mismo patrón, y todos ellos aplican claves de seguridad.
Fin del uso opcional: el día en que Cloudflare abandonó por completo el uso de las TOTP
En febrero de 2021, nuestros empleados empezaron a informar a nuestro equipo de seguridad acerca de intentos de ataque de ingeniería social. Estaban recibiendo llamadas telefónicas de personas que afirmaban pertenecer a nuestro departamento informático. Y nos preocupamos. Decidimos empezar a exigir el uso de las claves de seguridad para todas las autenticaciones, para evitar así que los empleados pudieran ser víctimas del ataque de ingeniería social.
Una vez desactivadas todas las otras formas de MFA (SMS, TOTP etc.), con la excepción de WebAuthn, utilizábamos oficialmente solo FIDO2. En este gráfico, sin embargo, el "token de software" (TOTP) no se muestra completamente a cero. Esto se debe a que las personas que pierden sus claves de seguridad y sus cuentas quedan bloqueadas deben realizar un proceso de recuperación protegido fuera de linea, donde se facilita el inicio de sesión mediante un método alternativo. La práctica recomendada es distribuir varias claves de seguridad a los empleados para que dispongan de una clave de reserva en caso de que se encuentren en esta situación.
Ahora que todos los empleados utilizan sus YubiKeys para MFA a prueba de phishing, ¿hemos terminado? ¿Qué pasa con los protocolos SSH y no HTTP? Queríamos un único enfoque unificado de la gestión de la identidad y el acceso. Por lo tanto, lo siguiente que consideramos fue llevar las claves de seguridad a otros protocolos distintos.
Utilización de las claves de seguridad con SSH
Para poder llevar las claves de seguridad a las conexiones SSH, implementamos Cloudflare Tunnel en toda nuestra infraestructura de producción. Cloudflare Tunnel se integra perfectamente con Cloudflare Access, sea cual sea el protocolo que pase por el túnel, y la ejecución de un túnel requiere el cliente de túnel cloudflared. Esto significa que podríamos implementar el archivo binario cloudflared en toda nuestra infraestructura y crear un túnel a cada máquina, crear políticas de Cloudflare Access donde las claves de seguridad fueran necesarias, y conexiones ssh que empezaran a exigir las claves de seguridad mediante Cloudflare Access.
En la práctica, estos pasos son menos complicados de lo que parece, y la documentación para desarrolladores de Zero Trust incluye un a fantástico tutorial sobre cómo hacerlo. Cada uno de nuestros servidores tiene un archivo de configuración necesario para iniciar el túnel. Systemd invoca cloudflared, que utiliza este archivo de configuración (o uno similar) al iniciar el túnel.
Cuando un operador necesita ejecutar SSH en nuestra infraestructura, utiliza la directiva SSH ProxyCommand para invocar cloudflared, realizar la autenticación mediante Cloudflare Access y, a continuación, reenviar la conexión SSH mediante Cloudflare. Las configuraciones SSH de nuestros empleados tienen una entrada similar a esta, y se puede generar con un comando de ayuda en cloudflared:
tunnel: 37b50fe2-a52a-5611-a9b1-ear382bd12a6
credentials-file: /root/.cloudflared/37b50fe2-a52a-5611-a9b1-ear382bd12a6.json
ingress:
- hostname: <identifier>.ssh.cloudflare.com
service: ssh://localhost:22
- service: http_status:404Cabe señalar que OpenSSH ha sido compatible con FIDO2 desde la versión 8.2. Sin embargo, creemos que un enfoque unificado al control de acceso donde todas las listas de control de acceso se mantienen en un único panel presenta algunas ventajas.
Host *.ssh.cloudflare.com
ProxyCommand /usr/local/bin/cloudflared access ssh –hostname %h.ssh.cloudflare.comQué hemos aprendido y cómo puede ayudarte nuestra experiencia
Tras los últimos meses, es indudable que el futuro de la autenticación es FIDO2 y WebAuthn. Nos ha llevado unos años llegar hasta aquí, y esperamos que nuestras conclusiones sean útiles a otras organizaciones que deseen modernizarse con la autenticación basada en FIDO.
Si te interesa implementar las claves de seguridad en tu organización, o te interesan los productos Zero Trust de Cloudflare, escríbenos a [email protected]. Aunque nos complace que nuestros esfuerzos preventivos nos hayan ayudado a resistir la última ola de ataques de phishing y de ingeniería social, nuestro equipo de seguridad sigue creciendo para ayudar a detener cualquier ataque futuro.