Automatización de la revocación de certificados con OCSP y CRL en un entorno NAC

Automatización de la revocación de certificados con OCSP y CRL en un entorno NAC Una sesión técnica de Purple — Aproximadamente 10 minutos --- INTRODUCCIÓN Y CONTEXTO — aproximadamente 1 minuto Le damos la bienvenida a la serie de sesiones técnicas de Purple. Soy su anfitrión, y hoy vamos a profundizar en la mecánica de la automatización de la revocación de certificados; concretamente, en cómo funcionan OCSP y CRL dentro de un entorno de control de acceso a la red (NAC), y por qué configurar esto correctamente es una de las decisiones de seguridad que más se pasan por alto en los despliegues de WiFi empresariales. Si gestiona una cadena hotelera, un complejo comercial, un estadio o una red del sector público con cientos o miles de dispositivos conectados, la gestión del ciclo de vida de los certificados no es un capricho. Es la diferencia entre una red que aplica las políticas en tiempo real y otra que alberga silenciosamente credenciales revocadas de dispositivos que deberían haber sido desconectados hace semanas. Analizaremos la arquitectura técnica, repasaremos dos escenarios reales de despliegue y terminaremos con las preguntas que su equipo debería hacerse antes de acercarse a un lanzamiento en producción. Comencemos. --- ANÁLISIS TÉCNICO DETALLADO — aproximadamente 5 minutos En primer lugar, definamos el problema que estamos resolviendo. En cualquier red autenticada mediante IEEE 802.1X —que es el estándar que sustenta el WiFi empresarial, el NAC cableado y la mayoría de las arquitecturas modernas de acceso de invitados—, los dispositivos se autentican mediante credenciales o certificados. Los certificados son preferibles porque no dependen de secretos compartidos, están vinculados al dispositivo y se integran perfectamente con las plataformas MDM a través de protocolos como SCEP. Sin embargo, los certificados tienen un ciclo de vida. Caducan, se ven comprometidos y los dispositivos se retiran del servicio. Cuando ocurre cualquiera de estas cosas, se necesita un mecanismo para indicar a la infraestructura de red: este certificado ya no es válido, deje de confiar en él. Ese mecanismo se presenta en dos variantes: CRL, que significa Lista de Revocación de Certificados, y OCSP, que significa Protocolo de Estado de Certificados en Línea. Empecemos con CRL. Una Lista de Revocación de Certificados es exactamente lo que parece: una lista firmada, publicada por su Autoridad de Certificación (CA), con todos los números de serie de los certificados que han sido revocados. Su infraestructura NAC —normalmente un servidor RADIUS como FreeRADIUS, Cisco ISE o Aruba ClearPass— descarga esta lista periódicamente desde un punto de distribución de CRL, que es simplemente un endpoint HTTP o LDAP. El servidor RADIUS almacena la lista localmente en caché y comprueba los números de serie de los certificados entrantes con ella durante el protocolo de enlace EAP-TLS. La ventaja operativa de CRL es la sencillez y la resiliencia sin conexión. Una vez descargada la lista, la comprobación de revocación funciona incluso si su CA no está accesible. La desventaja es la latencia. Si revoca un certificado a las 9:00 y su intervalo de actualización de CRL es de 24 horas, ese dispositivo podría seguir autenticándose hasta la siguiente descarga programada. En un entorno de alta seguridad —un hospital, la oficina de soporte de servicios financieros, una red gubernamental—, ese margen de tiempo es inaceptable. OCSP resuelve el problema de la latencia. En lugar de mantener una lista local en caché, su servidor RADIUS envía una consulta en tiempo real a un OCSP Responder (un servicio que se sitúa por delante de su CA) para cada certificado que necesita validar. El responder devuelve una de tres respuestas: Good, Revoked o Unknown. Todo el intercambio ocurre en línea, durante el saludo EAP-TLS, normalmente en menos de 100 milisegundos en una infraestructura bien dimensionada. La contrapartida con OCSP es la dependencia de la disponibilidad. Si su OCSP Responder se cae, o si su servidor RADIUS no puede comunicarse con él debido a una partición de red, debe tomar una decisión de política: ¿aplica un fallo permisivo (fail open), permitiendo que la autenticación continúe, o un fallo restrictivo (fail closed), denegando el acceso hasta que el responder esté accesible? El fallo permisivo mantiene el tiempo de actividad pero genera una brecha de seguridad. El fallo restrictivo mantiene la postura de seguridad pero puede bloquear a usuarios legítimos durante una incidencia en la infraestructura. Existe una tercera opción que vale la pena conocer: OCSP Stapling. En este modelo, el titular del certificado (el dispositivo cliente) obtiene periódicamente una respuesta OCSP firmada del responder y la adjunta al saludo TLS. El servidor RADIUS valida la respuesta grapada en lugar de realizar su propia consulta OCSP. Esto reduce la carga en el OCSP Responder, elimina la preocupación de privacidad al no exponer los números de serie de los certificados a un servicio externo y mejora la resiliencia. La desventaja es que no todos los suplicantes EAP admiten el grapado, por lo que debe verificar la compatibilidad del cliente antes de confiar en él. Ahora bien, ¿cómo encaja esto en una arquitectura NAC? Su motor de políticas NAC (ya sea Cisco ISE, Aruba ClearPass, Juniper Mist o una pila de código abierto basada en FreeRADIUS y PacketFence) se sitúa entre el suplicante y la red. Cuando un dispositivo intenta conectarse, el servidor RADIUS recibe el Access-Request, realiza la negociación EAP-TLS, valida la cadena de certificados del cliente, comprueba el estado de revocación a través de OCSP o CRL y, a continuación, emite un Access-Accept con una asignación de VLAN o un Access-Reject. La parte de la automatización interviene en dos niveles. Primero, en la capa de emisión de certificados: su plataforma MDM (Jamf, Intune, Workspace ONE) utiliza SCEP para aprovisionar automáticamente certificados en los dispositivos gestionados. Cuando un dispositivo se desvincula o se retira del servicio, el MDM activa una llamada de revocación a la CA, que actualiza la CRL y notifica al OCSP Responder. Segundo, en la capa de aplicación de NAC: su servidor RADIUS está configurado para consultar OCSP o actualizar su caché de CRL según una programación definida, garantizando que las decisiones de revocación se propaguen a la política de acceso sin intervención manual. El punto de integración crítico aquí es el canal de comunicación de la CA al NAC. En un despliegue bien diseñado, la revocación es una cadena totalmente automatizada: el MDM retira el dispositivo, activa la revocación de la CA, la CA actualiza el respondedor OCSP y publica una nueva CRL, el servidor RADIUS detecta el cambio —ya sea inmediatamente a través de OCSP o dentro de la siguiente ventana de actualización de la CRL— y al dispositivo se le deniega el acceso en su siguiente intento de autenticación. --- RECOMENDACIONES DE IMPLEMENTACIÓN Y ERRORES COMUNES — aproximadamente 2 minutos Permítame ofrecerle la orientación práctica que evita que los despliegues salgan mal. Primero: defina su tolerancia a la latencia de revocación antes de elegir su mecanismo. Si gestiona una red WiFi para huéspedes de un hotel donde el riesgo principal es un dispositivo del personal retirado, un intervalo de actualización de CRL de 4 horas probablemente sea adecuado. Si gestiona una red sanitaria donde un dispositivo comprometido podría acceder a los datos de los pacientes, querrá OCSP con una política de denegación por fallo (fail-closed) y un clúster de respondedores de alta disponibilidad. Segundo: no ejecute un único respondedor OCSP en producción. Despliegue como mínimo dos, detrás de un equilibrador de carga, con monitorización de estado. Una interrupción del respondedor OCSP que provoque un comportamiento de denegación por fallo generará tickets de soporte más rápido que casi cualquier otro fallo de infraestructura. Tercero: vigile el tamaño de su CRL. En despliegues grandes —hablamos de decenas de miles de certificados— los archivos CRL pueden crecer hasta varios megabytes. Un servidor RADIUS que descarga una CRL de 5 MB cada hora a través de un enlace WAN es un problema de rendimiento asegurado. Considere las CRL delta, que solo contienen los cambios desde la última CRL completa, o migre a OCSP para entornos de gran volumen. Cuarto: pruebe su canal de revocación con regularidad. No basta con configurar OCSP y asumir que funciona. Automatice una prueba mensual: emita un certificado, revóquelo, intente la autenticación y verifique el rechazo. Si su monitorización no detecta un respondedor OCSP caído, su mecanismo de revocación es puro teatro. Quinto: alinee los periodos de validez de sus certificados con su estrategia de revocación. Los certificados de corta duración —de 24 a 72 horas— reducen la ventana de exposición para las credenciales comprometidas y pueden reducir por completo su dependencia de la infraestructura de revocación. Esta es la dirección en la que se mueve el sector y vale la pena evaluarla para nuevos despliegues. --- PREGUNTAS Y RESPUESTAS RÁPIDAS — aproximadamente 1 minuto Pregunta: ¿Puedo utilizar tanto OCSP como CRL simultáneamente? Sí. La mayoría de las implementaciones de RADIUS admiten una cadena de contingencia: intentar primero con OCSP y recurrir a la CRL si el respondedor no está accesible. Esto le ofrece una comprobación en tiempo real en condiciones normales y resiliencia sin conexión durante las interrupciones. Pregunta: ¿Se integra la plataforma de WiFi para huéspedes de Purple con un NAC basado en certificados? La plataforma de Purple opera en la capa de acceso de invitados, gestionando la autenticación del Captive Portal, la captura de datos y la analítica. Para las redes de personal corporativo que ejecutan 802.1X con autenticación mediante certificados, Purple se integra con la infraestructura de red subyacente (los puntos de acceso, controladores y servidores RADIUS) en lugar de reemplazar la pila de gestión de certificados. Las redes de invitados y de personal suelen estar segmentadas, con diferentes mecanismos de autenticación adecuados para cada una. Pregunta: ¿Cuál es el enfoque de cumplimiento? PCI DSS 4.0 exige que el acceso a los entornos de datos de titulares de tarjetas utilice una autenticación sólida. El GDPR exige medidas técnicas adecuadas para proteger los datos personales. Ambos marcos se cumplen mediante 802.1X basado en certificados con revocación automatizada, siempre que se pueda demostrar que la revocación es oportuna y está probada. Su pista de auditoría debe mostrar cuándo se revocaron los certificados y cuándo se propagó dicha revocación a la aplicación de la red. --- RESUMEN Y PRÓXIMOS PASOS: aproximadamente 1 minuto En resumen: automatizar la revocación de certificados en un entorno NAC es un problema de tres capas. Necesita una CA que admita activadores de revocación automatizados, un respondedor OCSP o un punto de distribución de CRL que sea altamente disponible y tenga el tamaño adecuado, y un servidor RADIUS configurado para aplicar el estado de revocación como parte de su política de acceso. La elección entre OCSP y CRL no es binaria: es una decisión de tolerancia al riesgo que debe tomarse en el contexto de los requisitos de seguridad, la topología de red y la madurez operativa de su entorno. Si está creando o revisando un despliegue de NAC y desea comprender cómo encaja la plataforma de analítica y WiFi de invitados de Purple en la arquitectura de red más amplia, los enlaces en las notas del programa le llevarán a las guías técnicas pertinentes. Gracias por escucharnos. Nos vemos en la próxima sesión informativa. --- FIN DEL GUION