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 informativa técnica de Purple — Aproximadamente 10 minutos --- INTRODUCCIÓN Y CONTEXTO — aproximadamente 1 minuto Bienvenidos a la serie de sesiones informativas técnicas de Purple. Soy su anfitrión, y hoy analizaremos a fondo la mecánica de la automatización de la revocación de certificados, específicamente cómo funcionan OCSP y CRL dentro de un entorno de Control de Acceso a la Red (NAC), y por qué hacer esto bien es una de las decisiones de seguridad más ignoradas en las implementaciones de WiFi empresariales. Si administra 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 lujo. Es la diferencia entre una red que aplica políticas en tiempo real y otra que alberga silenciosamente credenciales revocadas de dispositivos que debieron ser desconectados hace semanas. Cubriremos la arquitectura técnica, analizaremos dos escenarios reales de implementación y finalizaremos con las preguntas que su equipo debería hacerse antes de acercarse a un despliegue en producción. Comencemos. --- ANÁLISIS TÉCNICO DETALLADO — aproximadamente 5 minutos Primero, establezcamos 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 para 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. Pero los certificados tienen un ciclo de vida. Expiran, se ven comprometidos y los dispositivos se retiran de servicio. Cuando ocurre cualquiera de estas cosas, se necesita un mecanismo para indicarle a la infraestructura de red: este certificado ya no es válido, deja 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. Comencemos con CRL. Una Lista de Revocación de Certificados es exactamente lo que parece: una lista firmada, publicada por su Autoridad de Certificación, de cada número de serie de certificado que ha sido revocado. 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 (CDP), 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 contra ella durante el saludo EAP-TLS. La ventaja operativa de la CRL es la simplicidad y la resiliencia fuera de línea. Una vez descargada la lista, la comprobación de revocación funciona incluso si la CA no está accesible. La desventaja es la la latencia. Si revoca un certificado a las 9:00 a. m. y su intervalo de actualización de CRL es de 24 horas, ese dispositivo aún podría autenticarse hasta la siguiente descarga programada. En un entorno de alta seguridad —un hospital, una oficina administrativa 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 almacenada en caché, su servidor RADIUS envía una consulta en tiempo real a un OCSP Responder —un servicio que se encuentra frente a su CA— para cada certificado que necesita validar. El responder devuelve una de tres respuestas: Good (Bueno), Revoked (Revocado) o Unknown (Desconocido). Todo el intercambio ocurre en línea, durante el saludo EAP-TLS, normalmente en menos de 100 milisegundos en una infraestructura bien aprovisionada. La desventaja de 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, tiene que tomar una decisión de política: ¿aplica 'fail open' (permitiendo que continúe la autenticación) o 'fail closed' (denegando el acceso hasta que el responder esté accesible)? 'Fail open' mantiene el tiempo de actividad pero crea una brecha de seguridad. 'Fail closed' mantiene la postura de seguridad pero puede bloquear a usuarios legítimos durante un incidente de 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 adjunta en lugar de realizar su propia consulta OCSP. Esto reduce la carga en el OCSP Responder, elimina la preocupación de privacidad de 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 stapling, por lo que debe verificar la compatibilidad del cliente antes de depender de él. Ahora, ¿cómo encaja esto en una arquitectura NAC? Su motor de políticas NAC —ya sea Cisco ISE, Aruba ClearPass, Juniper Mist o un stack de código abierto basado en FreeRADIUS y PacketFence— se ubica entre el suplicante y la red. Cuando un dispositivo intenta conectarse, el servidor RADIUS recibe la solicitud 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 luego emite un Access-Accept con una asignación de VLAN o un Access-Reject. La parte de 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 administrados. Cuando un dispositivo se desvincula o se retira de 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 un programa definido, 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 CA a NAC. En una implementación bien diseñada, la revocación es una cadena totalmente automatizada: el MDM retira el dispositivo, activa la revocación de la CA, la CA updates el OCSP Responder y publica la nueva CRL, el servidor RADIUS detecta el cambio —ya sea de inmediato a través de OCSP o dentro del siguiente intervalo de actualización de CRL— y al dispositivo se le deniega el acceso en su próximo intento de autenticación. --- RECOMENDACIONES DE IMPLEMENTACIÓN Y ERRORES COMUNES — aproximadamente 2 minutos Permítanme darles la orientación práctica que evita que las implementaciones salgan mal. Primero: defina su tolerancia a la latencia de revocación antes de elegir su mecanismo. Si administra una red WiFi de invitados en un hotel donde el riesgo principal es un dispositivo del personal retirado de servicio, un intervalo de actualización de CRL de 4 horas probablemente sea suficiente. Si administra una red de atención médica donde un dispositivo comprometido podría acceder a los datos de los pacientes, querrá OCSP con una política 'fail closed' y un clúster de responder de alta disponibilidad. Segundo: no ejecute un solo OCSP Responder en producción. Implemente al menos dos, detrás de un balanceador de carga, con monitoreo de estado. Una interrupción del OCSP Responder que cause un comportamiento 'fail closed' generará tickets de soporte más rápido que casi cualquier otra falla de infraestructura. Terc: vigile el tamaño de su CRL. En implementaciones 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 garantizado. Considere las delta CRLs, 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, verifique el rechazo. Si su monitoreo no detecta un OCSP Responder roto, su mecanismo de revocación es pura simulación. Quinto: alinee los períodos de validez de sus certificados con su estrategia de revocación. Los certificados de corta duración —de 24 a 72 horas— reducen el margen de exposición de 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 la industria y vale la pena evaluarla para nuevas implementaciones. --- PREGUNTAS Y RESPUESTAS RÁPIDAS — aproximadamente 1 minuto Pregunta: ¿Puedo usar OCSP y CRL simultáneamente? Sí. La mayoría de las implementaciones de RADIUS admiten una cadena de alternativa (fallback): probar primero con OCSP y recurrir a CRL si el responder no está accesible. Esto le brinda comprobación en tiempo real en condiciones normales y resiliencia fuera de línea durante las interrupciones. Pregunta: ¿La plataforma de WiFi de invitados de Purple se integra con 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 las analíticas. Para las redes de personal empresarial que ejecutan 802.1X con autenticación de certificados, Purple se integra con la infraestructura de red subyacente —los puntos de acceso, controladores y servidores RADIUS— en lugar de reemplazar el stack 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 pueda demostrar que la revocación es oportuna y está probada. Su registro de auditoría debe mostrar cuándo se revocaron los certificados y cuándo se propagó esa revocación a la aplicación de la red. --- RESUMEN Y PRÓXIMOS PASOS — aproximadamente 1 minuto Para resumir: la automatización de 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 OCSP Responder o Punto de Distribución de CRL que sea de alta disponibilidad y del 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 de su entorno, la topología de la red y la madurez operativa. Si está creando o revisando una implementación de NAC y desea comprender cómo encaja la plataforma de WiFi de invitados y analíticas de Purple en la arquitectura de red más amplia, los enlaces en las notas del programa lo llevarán a las guías técnicas correspondientes. Gracias por escuchar. Nos vemos en la próxima sesión informativa. --- FIN DEL LIBRETO