Saltar al contenido principal
Español

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

Esta guía de referencia técnica proporciona a los directores de TI y arquitectos de red un análisis detallado de la automatización de la revocación de certificados en un entorno de control de acceso a la red (NAC). Explora los compromisos arquitectónicos entre OCSP y CRL, ofrece orientación de implementación independiente del proveedor y describe el impacto empresarial de la aplicación de políticas en tiempo real.

📖 6 min de lectura📝 1,437 palabras🔧 2 ejemplos prácticos❓ 3 preguntas de práctica📚 8 definiciones clave

Escuchar esta guía

Ver transcripción del podcast
Automatización de la revocación de certificados con OCSP y CRL en un entorno NAC Un informe técnico de Purple - Aproximadamente 10 minutos --- INTRODUCCIÓN Y CONTEXTO - aproximadamente 1 minuto Bienvenido a la serie de informes técnicos de Purple. Soy su anfitrión, y hoy nos adentraremos 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 Network Access Control y por qué hacer esto bien es una de las decisiones de seguridad que más se pasan por alto en los despliegues de WiFi corporativos. Si gestiona una cadena hotelera, un espacio 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 extra opcional. 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 haberse desconectado 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. --- INMERSIÓN TÉCNICA PROFUNDA - aproximadamente 5 minutos En primer lugar, definamos el problema que estamos resolviendo. En cualquier red autenticada mediante IEEE 802.1X (el estándar que sustenta el WiFi corporativo, el NAC por cable 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. Pero 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. 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, que no es más que 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 frente a ella durante el saludo 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 de la mañana 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, una oficina 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 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 un fallo abierto (permitiendo que el proceso de autenticación continúe) o un fallo cerrado (denegando el acceso hasta que el responder esté localizable)? El fallo abierto mantiene el tiempo de actividad pero crea una brecha de seguridad. El fallo cerrado mantiene el nivel de seguridad pero puede bloquear a usuarios legítimos durante una incidencia 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 (stapled) en lugar de realizar su propia consulta OCSP. Esto reduce la carga en el OCSP Responder, elimina el problema de privacidad que supone exponer los números de serie de los certificados a un servicio externo y mejora la resiliencia. El inconveniente es que no todos los suplicantes EAP admiten stapling, por lo que debe verificar la compatibilidad del cliente antes de confiar en este método. Ahora, ¿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 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, a continuación, emite un Access-Accept con una asignación de VLAN o un Access-Reject. La parte de la automatización entra en juego a 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 a 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 del NAC: su servidor RADIUS está configurado para consultar a OCSP o actualizar su caché de CRL según un programa definido, lo que garantiza 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 entre la CA y el NAC. En un despliegue bien diseñado, la revocación es una cadena completamente automatizada: el MDM retira el dispositivo, activa la revocación en 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 se deniega el acceso al dispositivo en su próximo intento de autenticación. --- RECOMENDACIONES DE IMPLEMENTACIÓN Y ERRORES COMUNES — aproximadamente 2 minutos Permítame ofrecerle la guía 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 de atención médica donde un dispositivo comprometido podría acceder a datos de pacientes, necesitará 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 al menos dos, detrás de un equilibrador de carga, con monitorización de estado. Una caída del respondedor OCSP que provoque un comportamiento de denegación por fallo generará incidencias de soporte técnico más rápido que casi cualquier otro fallo de infraestructura. Tercero: controle 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 el uso de 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 pura fachada. 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 el periodo de exposición para 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 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 RADIUS admiten una cadena de contingencia: intentar primero con OCSP y recurrir a CRL si el respondedor no está disponible. Esto le ofrece comprobaciones en tiempo real en condiciones normales y resiliencia sin conexión durante las caídas de servicio. 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 requiere 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 se ha probado. 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 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 respondedor OCSP o un punto de distribución 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 de su entorno, la topología de la red y la madurez operativa. Si está creando o revisando un despliegue de NAC y desea comprender cómo encaja la plataforma de WiFi de invitados y analítica de Purple en la arquitectura de red más amplia, los enlaces de las notas del programa le llevarán a las guías técnicas correspondientes. Gracias por escucharnos. Nos vemos en la próxima sesión informativa. --- FIN DEL GUION

header_image.png

Resumen Ejecutivo

Para los directores de TI de empresas y arquitectos de red que gestionan entornos de alta densidad - como establecimientos de hostelería , redes de retail y despliegues del sector público - la gestión del ciclo de vida de los certificados es una frontera de seguridad crítica. Aunque el estándar IEEE 802.1X proporciona una autenticación sólida para dispositivos corporativos y BYOD, el mecanismo para revocar la confianza a menudo se pasa por alto hasta que se produce una brecha de seguridad.

La automatización de la revocación de certificados dentro de un entorno de Control de Acceso a la Red (NAC) a través del Protocolo de Estado de Certificados en Línea (OCSP) y las Listas de Revocación de Certificados (CRL) acorta la distancia entre la baja de un dispositivo final y la aplicación de las políticas de red. Esta guía explora los mecanismos de arquitectura de la revocación automatizada, comparando las capacidades en tiempo real de OCSP con la resiliencia sin conexión de las CRL.

Al integrar plataformas de Gestión de Dispositivos Móviles (MDM), Autoridades de Certificación (CA) y motores de políticas NAC, las organizaciones pueden lograr un Acceso de Red de Confianza Cero donde los dispositivos comprometidos o retirados del servicio son bloqueados de inmediato. Esta referencia técnica proporciona orientación práctica para el despliegue, estrategias de mitigación de riesgos y explora cómo esta postura de seguridad orientada al personal complementa las infraestructuras de cara al público, como las plataformas de Guest WiFi y WiFi Analytics de Purple.

Análisis Técnico Detallado

En cualquier red empresarial que utilice IEEE 802.1X con EAP-TLS, los dispositivos se autentican mediante certificados digitales en lugar de credenciales compartidas. Este enfoque es fundamental para las arquitecturas de seguridad modernas, ya que proporciona identidades vinculadas al dispositivo y se integra a la perfección con plataformas MDM a través de protocolos como SCEP (para más información, consulte El papel de SCEP y NAC en la infraestructura MDM moderna ). Sin embargo, los certificados tienen un ciclo de vida definido. Cuando se pierde un dispositivo, un empleado se marcha o una clave privada se ve comprometida, la infraestructura de red debe recibir instrucciones explícitas para dejar de confiar en ese certificado.

Esta instrucción de revocación se entrega a través de dos mecanismos principales: CRL y OCSP.

Arquitectura de Lista de Revocación de Certificados (CRL)

Una CRL es un archivo firmado digitalmente y publicado por la Autoridad de Certificación que contiene los números de serie de todos los certificados que han sido revocados pero que aún no han caducado. El motor de políticas NAC (que actúa como servidor RADIUS) descarga periódicamente esta lista desde un Punto de Distribución de CRL (CDP) a través de HTTP o LDAP.

Durante el intercambio EAP-TLS, el servidor RADIUS verifica el número de serie del certificado del cliente entrante con respecto a su CRL guardada en caché localmente. Si el número de serie está presente, la autenticación se rechaza.

Características de la Arquitectura:

  • Resiliencia offline: Dado que el servidor RADIUS almacena en caché la CRL, la verificación de revocación continúa incluso si la CA o el CDP no están accesibles.
  • Latencia: La principal desventaja es la latencia entre la revocación y la aplicación. Si un certificado se revoca a las 09:00 AM y el intervalo de actualización de la CRL es de 24 horas, el dispositivo comprometido mantiene el acceso a la red hasta la siguiente descarga.
  • Sobrecarga de rendimiento: En entornos con miles de certificados, los archivos CRL pueden crecer hasta varios megabytes, lo que genera una gran demanda de ancho de banda durante los ciclos de actualización.

Arquitectura del Online Certificate Status Protocol (OCSP)

OCSP aborda las limitaciones de latencia de la CRL al permitir la verificación de revocación en tiempo real. En lugar de descargar la lista completa, el servidor RADIUS envía una consulta dirigida que contiene el número de serie del certificado a un respondedor OCSP. El respondedor devuelve un estado firmado: Good, Revoked o Unknown.

Características de la arquitectura:

  • Aplicación en tiempo real: Las decisiones de revocación surten efecto de manera instantánea. Una vez que la CA actualiza el respondedor OCSP, el siguiente intento de autenticación del dispositivo comprometido fallará.
  • Dependencia de la disponibilidad: El motor de políticas NAC depende de la alta disponibilidad del respondedor OCSP. Si el respondedor no está accesible, el administrador de red debe definir una política de fallos: "fail open" (autorizar el acceso, comprometiendo la seguridad) o "fail closed" (denegar el acceso, comprometiendo la disponibilidad).
  • OCSP Stapling: Para mitigar los problemas de carga y privacidad, el OCSP stapling permite al dispositivo cliente obtener la respuesta OCSP firmada y adjuntarla al intercambio de TLS, aunque el soporte del suplicante puede variar.

ocsp_crl_architecture_overview.png

Integración con plataformas de invitados y analíticas

Allí donde OCSP y CRL gestionan los estrictos requisitos de seguridad del personal y los dispositivos corporativos, las redes de cara al público requieren una arquitectura diferente. Para los recintos públicos, la integración de un NAC de personal robusto con una plataforma pública dedicada como Purple garantiza una cobertura integral. La plataforma de Purple gestiona la autenticación del Captive Portal, la aceptación de los términos de servicio y la captura de datos para el segmento público, mientras que la infraestructura de red subyacente (a menudo los mismos puntos de acceso físicos y conmutadores) aplica 802.1X y OCSP para los SSIDs corporativos. Comprender el entorno de radio es crucial para ambos segmentos; consulte Wi Fi Frequencies: A Guide to Wi-Fi Frequencies in 2026 para la planificación del espectro.

Guía de implementación

El despliegue de la revocación automática de certificados requiere la coordinación entre los dominios PKI, MDM y NAC. Siga estos pasos de implementación independientes del proveedor para establecer un flujo de revocación resiliente.

Paso 1: Definir los desencadenantes de la revocación

La automatización comienza en la capa de gestión de endpoints. Configure su plataforma MDM (por ejemplo, Microsoft Intune, Jamf Pro) para activar una llamada API de revocación a su entidad de certificación cuando se cumplan condiciones específicas:

  • Cuando un dispositivo se da de baja del MDM
  • Cuando un dispositivo se marca como no conforme
  • Cuando se deshabilita una cuenta de usuario en el servicio de directorio

Paso 2: Configurar la infraestructura de revocación

Para el despliegue de CRL:

  1. Configure la CA para publicar la CRL en un CDP de alta disponibilidad (por ejemplo, un servidor web interno con balanceo de carga).
  2. Establezca el intervalo de publicación de la CRL en función de su tolerancia al riesgo (por ejemplo, cada 4 horas).
  3. Configure el servidor RADIUS para recuperar la CRL a intervalos ligeramente inferiores al intervalo de publicación para garantizar que la caché esté siempre fresca.

Para el despliegue de OCSP:

  1. Despliegue al menos dos servidores de respuesta OCSP detrás de un balanceador de carga para garantizar la alta disponibilidad.
  2. Configure la CA para enviar las actualizaciones de revocación a los servidores de respuesta OCSP de forma inmediata.
  3. Configure el servidor RADIUS para consultar la IP virtual de OCSP con balanceo de carga durante la autenticación EAP-TLS.

Paso 3: Establecer políticas de contingencia

No dependa de un único mecanismo. Configure su servidor RADIUS para utilizar OCSP como comprobación de revocación principal y recurrir a una CRL almacenada en caché localmente si el servidor de respuesta OCSP no está accesible. Esto proporciona una aplicación en tiempo real en condiciones normales y resiliencia sin conexión durante las interrupciones de la infraestructura.

Paso 4: Definir el comportamiento ante fallos

Si tanto OCSP como la CRL almacenada en caché no están disponibles, el servidor RADIUS debe decidir cómo gestionar la solicitud de autenticación.

  • Entornos de alta seguridad (por ejemplo, salud ): Configure "fail closed" (fallo con cierre). Deniegue el acceso para evitar que se conecten dispositivos potencialmente comprometidos.
  • Entornos estándar (por ejemplo, nodos de transporte ): Configure "fail open" (fallo con apertura) con alertas. Permita el acceso para mantener la continuidad operativa, pero genere una alerta de alta prioridad para el SOC.

ocsp_vs_crl_comparison_chart.png

Buenas prácticas

  1. Implementar CRL delta: Si depende de las CRL en un entorno grande, implemente CRL delta. Estos archivos contienen únicamente los cambios de revocación desde la última publicación de la CRL base completa, lo que reduce significativamente el tamaño de la descarga y el consumo de ancho de banda.
  2. Monitorizar la latencia de OCSP: Las consultas OCSP se producen en línea durante el saludo EAP-TLS. Si el servidor de respuesta OCSP tarda 500 ms en responder, la autenticación se retrasa 500 ms. Monitorice la latencia del servidor de respuesta y escale horizontalmente si los tiempos de respuesta empeoran.
  3. Certificados de corta duración: Considere la posibilidad de reducir los períodos de validez de los certificados (por ejemplo, de 1 año a 7 días) mediante la renovación automatizada de SCEP/EST. Los certificados de corta duración caducan rápidamente de forma natural, lo que reduce la dependencia de una infraestructura de revocación sólida.4. Alineación con la estrategia de red general: Asegúrese de que su despliegue de NAC esté alineado con su arquitectura de red de área amplia. Para obtener información sobre el diseño de redes WAN modernas, consulte SD WAN vs MPLS: The 2026 Enterprise Network Guide .

Resolución de problemas y mitigación de riesgos

El fallo más común de la revocación automatizada es una interrupción en el canal entre la CA y el NAC, lo que provoca un evento de "cierre por fallo" que bloquea a los usuarios legítimos.

Riesgo: Caída del servidor de respuestas OCSP Mitigación: Despliegue servidores de respuestas en un clúster activo-activo a través de múltiples dominios de fallo. Implemente comprobaciones de estado exhaustivas en el equilibrador de carga que verifiquen no solo la disponibilidad del puerto TCP 80, sino también la capacidad del servidor de respuestas para consultar la base de datos de la CA.

Riesgo: Caché de CRL desactualizada Mitigación: Los servidores RADIUS pueden fallar al descargar la CRL más reciente debido a particiones de red o caídas de CDP. Implemente una monitorización que alerte cuando la CRL guardada localmente en caché sea más antigua que el intervalo de publicación definido.

Riesgo: Revocación incompleta de MDM Mitigación: Si el MDM no logra activar una llamada de revocación a la CA, el certificado seguirá siendo válido. Implemente un script de reconciliación que compare periódicamente la lista de dispositivos activos del MDM con la lista de certificados válidos de la CA y revoque automáticamente cualquier discrepancia.

ROI e impacto empresarial

La automatización de la revocación de certificados transforma la seguridad de un proceso reactivo y manual en un mecanismo de defensa proactivo y automatizado.

  • Mitigación de riesgos: Al eliminar el tiempo de exposición entre el compromiso de un dispositivo y el aislamiento de la red, las organizaciones reducen significativamente el riesgo de movimiento lateral y exfiltración de datos. Esto es crucial para mantener el cumplimiento con marcos como PCI-DSS y GDPR.
  • Eficiencia operativa: Automatizar el canal de revocación elimina la necesidad de que el personal de soporte actualice manualmente las configuraciones de RADIUS o las bases de datos de la CA cuando los empleados dejan la empresa, lo que ahorra cientos de horas anuales en las grandes empresas.
  • Estrategia de acceso unificado: Un entorno NAC robusto para dispositivos corporativos permite a los equipos de TI desplegar con confianza servicios paralelos, como el WiFi para invitados basado en análisis de Purple o los servicios basados en la ubicación (consulte BLE Low Energy Explained for Enterprise ), sabiendo que la infraestructura central sigue estando segura.

Escuche nuestro informe técnico sobre este tema a continuación:

Definiciones clave

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)

El estándar más seguro para la autenticación de red 802.1X, que requiere que tanto el cliente como el servidor presenten certificados digitales para demostrar su identidad.

Los equipos de TI implementan EAP-TLS para eliminar los riesgos asociados con la autenticación basada en contraseñas, garantizando que solo los dispositivos gestionados que dispongan de certificados puedan conectarse a la red corporativa.

OCSP (Online Certificate Status Protocol)

Un protocolo de internet utilizado para obtener el estado de revocación de un certificado digital X.509 en tiempo real.

Crucial para entornos que requieren la aplicación inmediata de políticas de acceso, como cuando se rescinde el contrato de un empleado y su dispositivo debe desconectarse instantáneamente.

CRL (Lista de Revocación de Certificados)

Una lista firmada digitalmente y publicada periódicamente de números de serie de certificados que han sido revocados por la Autoridad de Certificación emisora.

Utilizado como mecanismo de revocación principal en redes sin conexión o aisladas, o como mecanismo de respaldo de alta resistencia para OCSP.

Grampado OCSP (OCSP Stapling)

Un mecanismo en el que el dispositivo cliente obtiene su propia respuesta OCSP y la "grampa" al saludo TLS, presentándola al servidor RADIUS.

Reduce la carga en el servidor RADIUS y en el OCSP Responder, y mejora la privacidad al evitar que la CA vea exactamente cuándo y dónde se está autenticando un dispositivo.

CRL Delta

Una lista de revocación más pequeña que contiene únicamente los certificados revocados desde que se publicó la última CRL Base completa.

Esencial para despliegues grandes con el fin de evitar la congestión de la red, ya que las CRL completas pueden llegar a ser masivas y consumir un ancho de banda considerable durante los ciclos de actualización.

CDP (Punto de Distribución de CRL)

La ubicación, normalmente una URL HTTP o LDAP, donde la Autoridad de Certificación publica la CRL para que la descarguen los clientes y los servidores RADIUS.

Los equipos de TI deben asegurarse de que el CDP esté altamente disponible y sea accesible desde todos los motores de políticas de NAC; si el CDP deja de funcionar, los servidores RADIUS no podrán actualizar sus cachés.

Fail Open / Fail Closed

La decisión de política que dicta qué sucede cuando la infraestructura de revocación (OCSP o CDP) no está accesible. Fail Open permite el acceso; Fail Closed deniega el acceso.

Una decisión empresarial crítica que equilibra la postura de seguridad frente al tiempo de actividad operativa. Requiere la aprobación tanto de las operaciones de TI como del CISO.

SCEP (Protocolo Simple de Inscripción de Certificados)

Un protocolo utilizado por las plataformas MDM para automatizar la emisión de certificados digitales a dispositivos gestionados sin la intervención del usuario.

El punto de partida del ciclo de vida automatizado. SCEP emite el certificado y el MDM posteriormente solicita a la CA que lo revoque cuando el dispositivo se retira.

Ejemplos prácticos

La red de un hospital de 500 camas está migrando de un sistema 802.1X basado en credenciales a EAP-TLS basado en certificados para todos los dispositivos IoT médicos y portátiles del personal. El CISO exige que si se denuncia el robo de un dispositivo, su acceso a la red debe cancelarse en un plazo de 5 minutos. El equipo de red está preocupado por la carga del servidor RADIUS si tiene que consultar constantemente servicios externos. ¿Cómo debe diseñarse la arquitectura de revocación?

El hospital debe implementar OCSP para cumplir con el SLA de revocación de 5 minutos, ya que los intervalos de actualización de CRL no pueden cumplir este objetivo de manera fiable sin causar una sobrecarga de red grave. Para abordar las preocupaciones de carga del equipo de red, la arquitectura debe implementar OCSP Responders localmente dentro del centro de datos del hospital, situados cerca de los servidores RADIUS para minimizar la latencia. Los servidores RADIUS deben configurarse para consultar la VIP de OCSP local. Para garantizar la resiliencia, los servidores RADIUS deben configurarse con una alternativa de retorno a una CRL almacenada en caché localmente, actualizada cada hora. La política de fallos debe establecerse en "bloqueo por fallo" debido a los estrictos requisitos de cumplimiento del entorno sanitario.

Comentario del examinador: Este enfoque equilibra correctamente el estricto requisito de seguridad (SLA de 5 minutos) con la estabilidad operativa. Al localizar los OCSP Responders, el diseño mitiga la latencia y la dependencia de la WAN. La inclusión de una alternativa de retorno a CRL demuestra una comprensión madura del diseño de alta disponibilidad, garantizando que una interrupción temporal de OCSP no desencadene inmediatamente la política de "bloqueo por fallo" y afecte a las operaciones clínicas.

Una cadena de tiendas global con 1200 establecimientos utiliza SCEP para aprovisionar certificados en tabletas de punto de venta (POS). Las tiendas tienen un ancho de banda WAN limitado. El director de TI desea implementar la revocación de certificados, pero le preocupa que la descarga de archivos CRL de gran tamaño en 1200 servidores RADIUS de sucursales sature los enlaces WAN. ¿Cuál es la estrategia de implementación óptima?

La cadena de tiendas debe implementar un enfoque híbrido utilizando CRL Delta y OCSP Stapling. En primer lugar, la CA debe configurarse para publicar una CRL base semanalmente y una CRL Delta (que contenga solo las revocaciones recientes) cada 4 horas. Los servidores RADIUS de las sucursales solo descargarán las pequeñas CRL Delta durante el día, minimizando el impacto en la WAN. Alternativamente, si los suplicantes EAP de las tabletas de punto de venta lo admiten, se debe habilitar OCSP Stapling. Esto traslada la carga de obtener la respuesta OCSP del servidor RADIUS de la sucursal a la propia tableta, que puede obtener la respuesta directamente de la CA central a través de HTTPS estándar, evitando por completo la sobrecarga de procesamiento del servidor RADIUS.

Comentario del examinador: Esta solución aborda eficazmente la limitación específica: el ancho de banda WAN en el extremo. Recomendar CRL Delta es la práctica estándar de la industria para este escenario. La recomendación secundaria de OCSP Stapling muestra un conocimiento avanzado de la mecánica de EAP-TLS, aunque la advertencia sobre la compatibilidad del suplicante es crucial, ya que muchos dispositivos IoT o puntos de venta heredados no admiten el grapado.

Preguntas de práctica

Q1. Su organización está desplegando 802.1X en 50 oficinas sucursales remotas. Los enlaces WAN con el centro de datos central están muy congestionados y pierden paquetes con frecuencia. Debe implementar la revocación de certificados para los portátiles corporativos de las sucursales. ¿Qué arquitectura debería elegir?

Sugerencia: Considere el impacto de la pérdida de paquetes en los protocolos en tiempo real frente a la resiliencia de los datos almacenados en caché.

Ver respuesta modelo

Debería implementar una arquitectura basada en CRL, específicamente utilizando CRL Base y Delta. Dado que los enlaces WAN están congestionados y no son fiables, las consultas OCSP en tiempo real experimentarán frecuentes tiempos de espera agotados, lo que provocará retrasos o fallos en la autenticación. Al configurar los servidores RADIUS de las sucursales para que descarguen y almacenen en caché las CRL Delta durante las horas de menor actividad, el servidor RADIUS local puede realizar comprobaciones de revocación de forma instantánea contra su caché, incluso si el enlace WAN se cae por completo durante el intento de autenticación.

Q2. Una auditoría de seguridad revela que cuando su OCSP Responder principal se desconecta por mantenimiento, todos los usuarios corporativos quedan completamente bloqueados de la red WiFi. La empresa exige que el mantenimiento no afecte a la conectividad de los usuarios, pero el CISO se niega a cambiar la política a "Fail Open". ¿Cómo resuelve esto?

Sugerencia: Si no puede cambiar la política de fallos, debe cambiar la disponibilidad del servicio.

Ver respuesta modelo

Debe implementar una alta disponibilidad para el servicio OCSP. Despliegue al menos un OCSP Responder adicional y coloque ambos detrás de un equilibrador de carga. Configure el servidor RADIUS para realizar consultas a la IP virtual (VIP) del equilibrador de carga. Durante el mantenimiento, puede vaciar las conexiones del respondedor principal, desconectarlo y el equilibrador de carga redirigirá de forma transparente todas las consultas OCSP al respondedor secundario, satisfaciendo tanto el requisito de tiempo de actividad de la empresa como el mandato de "Fail Closed" del CISO.

Q3. Ha configurado su MDM para revocar automáticamente los certificados cuando un dispositivo se marca como "perdido". Prueba el sistema marcando un iPad de prueba como perdido. El MDM confirma la revocación, pero 10 minutos después, el iPad se conecta con éxito a la WiFi corporativa. El servidor RADIUS está configurado para utilizar una CRL publicada cada 24 horas. ¿Cuál es la causa raíz y cómo se soluciona?

Sugerencia: Siga la cronología de los datos de revocación desde la CA hasta el motor de aplicación del servidor RADIUS.

Ver respuesta modelo

La causa raíz es la latencia en el ciclo de publicación y actualización de la CRL. Aunque el MDM indicó con éxito a la CA que revocara el certificado, la CA no publicará ese estado actualizado en el punto de distribución de la CRL hasta el siguiente ciclo de 24 horas, y el servidor RADIUS no lo descargará hasta que expire su propia caché. Para solucionarlo, debe migrar a OCSP para la verificación en tiempo real, o bien reducir drásticamente los intervalos de publicación y descarga de la CRL (por ejemplo, a 1 hora) para cumplir con el plazo de aplicación requerido.

Continúe leyendo esta serie

Staff WiFi vs. Guest WiFi: mejores prácticas para la segmentación de redes corporativas

Una guía técnica completa para líderes de TI sobre cómo segmentar las redes de staff y guest WiFi. Cubre la arquitectura VLAN, la autenticación 802.1X, las políticas de firewall y el impacto empresarial de un diseño de red seguro.

Leer la guía →

Soluciones de WiFi para apartamentos: una guía completa para empresas

Esta guía cubre la arquitectura, el despliegue y el caso de negocio de las soluciones de WiFi para apartamentos en propiedades de Build to Rent y de múltiples viviendas. Explica cómo la tecnología Identity Pre-Shared Key (iPSK) crea burbujas de red seguras y aisladas para cada residente, a la vez que admite dispositivos inteligentes e IoT. Los promotores inmobiliarios, propietarios y operadores de BTR encontrarán orientación práctica de despliegue, datos de ROI y escenarios de implementación resueltos.

Leer la guía →

Cox business managed WiFi: a comprehensive guide for businesses

Esta guía detalla cómo los promotores inmobiliarios y los operadores de BTR pueden implementar redes escalables y seguras utilizando Cox Business managed WiFi. Cubre la arquitectura de red, la implementación de hardware independiente del proveedor y el impacto comercial de transformar la conectividad de un dolor de cabeza operativo a una infraestructura confiable.

Leer la guía →