Cómo configurar SCEP para BYOD seguro y autenticación de red 802.1X

Hola y bienvenidos a esta sesión técnica de Purple. Soy su anfitrión y hoy entraremos en detalle sobre SCEP (Simple Certificate Enrollment Protocol) y cómo configurarlo correctamente para una autenticación de red segura en BYOD y 802.1X. Si usted es gerente de TI, arquitecto de redes o CTO responsable de la infraestructura de WiFi en un grupo hotelero, una cadena de tiendas, un estadio o una organización del sector público, esto le interesa directamente. Hoy no hablaremos de teoría. Hablaremos de arquitectura y toma de decisiones. Comencemos. [SECTION: Introduction and Context - approximately 1 minute] Este es el problema al que probablemente se enfrenta. Tiene dispositivos de empleados, laptops de contratistas y teléfonos personales que necesitan acceso a la red. Probablemente tenga una mezcla de dispositivos administrados y no administrados. Y en algún lugar de su infraestructura, todavía hay una clave compartida WPA2 que conocen doce personas, tres de las cuales dejaron la empresa el año pasado. Eso no es una postura de seguridad. Eso es un riesgo. La respuesta es 802.1X, el estándar IEEE para el control de acceso a la red basado en puertos. Este garantiza que ningún dispositivo transmita tráfico hasta que haya sido autenticado explícitamente. Pero 802.1X es solo el marco de trabajo. La verdadera pregunta es qué método de autenticación se utiliza dentro de él. Y para BYOD a gran escala, la respuesta es EAP-TLS con certificados provistos a través de SCEP. Eso es lo que analizaremos hoy. [SECTION: Technical Deep-Dive - approximately 5 minutes] Comencemos con lo que realmente hace SCEP. SCEP (Simple Certificate Enrollment Protocol) fue publicado originalmente como un borrador de Internet por la IETF en 1999, creado por VeriSign. Se formalizó como RFC 8894. Su función es sencilla: automatizar el proceso de emisión de certificados digitales X.509 a dispositivos a gran escala, sin necesidad de que una persona genere e instale cada uno de forma manual. Este es el flujo de cuatro pasos. Paso uno: el dispositivo se conecta a un endpoint de SCEP, una URL alojada de forma local a través de un rol de Windows Server llamado NDES (Network Device Enrollment Service) o mediante un proveedor de PKI en la nube. Esta URL es la puerta de enlace a su Autoridad de Certificación (CA). Paso dos: el dispositivo presenta un desafío SCEP, un secreto compartido que demuestra que está autorizado para solicitar un certificado. En un entorno administrado por MDM como Microsoft Intune, este desafío se entrega de forma dinámica y única por dispositivo, lo cual es mucho más seguro que una contraseña estática compartida en todos los dispositivos. Paso tres: el dispositivo genera su propio par de claves pública y privada de forma local. Crea una Solicitud de Firma de Certificado (CSR) utilizando la clave pública y la envía al servidor SCEP. Aquí está el punto crítico de seguridad: la clave privada nunca sale del dispositivo. Se genera localmente, se almacena en el enclave seguro del dispositivo (el TPM en Windows o el Secure Enclave en iOS) y nunca se transmite. Es por esto que SCEP es la opción correcta para la autenticación de red, a diferencia de PKCS, donde la CA genera la clave de forma centralizada y tiene que enviarla al dispositivo. Paso cuatro: la Autoridad de Certificación valida la CSR, la firma con la clave privada de la CA y devuelve el certificado X.509 firmado al dispositivo. El dispositivo ahora tiene una identidad criptográfica única. Ahora, ¿cómo se utiliza ese certificado para la autenticación 802.1X? Cuando el dispositivo se conecta a su SSID de WiFi, el punto de acceso (ya sea Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist o Ubiquiti UniFi) actúa como el autenticador. No toma la decisión de autenticación por sí mismo. Reenvía el intercambio EAP a su servidor RADIUS. Este podría ser Microsoft NPS, Cisco ISE o Aruba ClearPass. El servidor RADIUS inicia un saludo EAP-TLS. El dispositivo presenta su certificado de cliente provisto por SCEP. El servidor RADIUS valida tres cosas: la cadena de certificados de regreso a la CA raíz de confianza, la fecha de vencimiento del certificado y si el certificado ha sido revocado (verificado contra una Lista de Revocación de Certificados, o CRL, o mediante OCSP, el Protocolo de Estado de Certificados en Línea). Si se aprueban las tres verificaciones, el servidor RADIUS envía un mensaje EAP-Success y el punto de acceso abre el puerto. El dispositivo está en la red. Esta es una autenticación mutua. El dispositivo también valida el certificado del servidor RADIUS. Si alguien configura un punto de acceso no autorizado, el dispositivo lo rechazará porque el certificado del servidor no se validará contra la CA de confianza. Esa es su protección contra los ataques de gemelo malvado. Ahora hablemos de la secuencia de implementación en Microsoft Intune, porque es la plataforma MDM más común que vemos en entornos empresariales. Usted implementa tres perfiles de configuración de Intune, en orden estricto. Primero, el perfil de Certificado de Raíz de Confianza: este envía el certificado de su CA raíz a cada dispositivo para que confíen en su PKI. Segundo, el perfil de Certificado SCEP: este le indica a los dispositivos la URL de SCEP, el formato del nombre del sujeto, el uso de la clave y el uso extendido de la clave para la autenticación del cliente. El OID para la autenticación del cliente es 1.3.6.1.5.5.7.3.2. Tercero, el perfil de WiFi: este especifica el SSID, establece el tipo de seguridad en WPA2-Enterprise o WPA3-Enterprise, establece el tipo de EAP en EAP-TLS y se vincula al perfil de certificado SCEP. El orden importa. El perfil de WiFi tiene una dependencia del perfil SCEP, el cual tiene una dependencia del perfil de Raíz de Confianza. Si los implementa fuera de secuencia, obtendrá errores. Una decisión de arquitectura que debe tomar es dónde alojar el servidor NDES. Debe ser accesible desde internet para que los dispositivos puedan registrarse antes de llegar a las instalaciones. La forma segura de hacer esto es publicar la URL de NDES a través de Microsoft Entra ID Application Proxy. Esto evita abrir puertos de firewall entrantes y le permite aplicar políticas de Acceso Condicional al flujo de registro. Para las organizaciones que desean eliminar por completo la infraestructura local, los proveedores de PKI en la nube (el propio Cloud PKI de Microsoft en Intune u opciones de terceros) eliminan por completo la dependencia de NDES. [SECTION: Implementation Recommendations and Pitfalls - approximately 2 minutes] Permítame presentarle los tres modos de falla más comunes que observamos. Modo de falla uno: discrepancia en la asignación de grupos. Esta es la causa más frecuente de fallas en el despliegue de perfiles de WiFi en Intune. Si su perfil de Raíz de Confianza está asignado a un grupo de Usuarios, su perfil SCEP a un grupo de Dispositivos y su perfil de WiFi a un grupo de Usuarios diferente, Intune no podrá resolver la cadena de dependencia. Los tres perfiles deben dirigirse exactamente al mismo grupo de Azure AD, ya sea todo de Usuarios o todo de Dispositivos. Elija uno y sea consistente. Modo de falla dos: disponibilidad de la CRL. Su servidor RADIUS verifica la CRL para confirmar que los certificados no hayan sido revocados. Si el Punto de Distribución de la CRL (la URL de CDP incrustada en el certificado) no está accesible, la autenticación fallará para todos los dispositivos. Esta es una causa común de interrupciones masivas después de realizar cambios en la red. Asegúrese de que sus CDP tengan una alta disponibilidad, idealmente publicados tanto en una URL interna como en una URL externa para dispositivos remotos. Considere OCSP como una alternativa más resiliente a la verificación de CRL. Modo de falla tres: no exigir la validación del certificado del servidor en los clientes. Esta es la configuración incorrecta con mayor impacto en los despliegues de 802.1X. Si su perfil de WiFi desplegado por MDM no especifica la CA de confianza y el nombre del servidor RADIUS esperado, los dispositivos se conectarán a cualquier servidor que presente cualquier certificado. Eso anula por completo el propósito de EAP-TLS. Configure siempre la validación del servidor en su perfil de WiFi. [SECTION: Rapid-Fire Q and A - approximately 1 minute] Pasemos a unas preguntas rápidas. Pregunta: ¿Necesitamos WPA3? Sí. Migre a WPA3-Enterprise. Este exige Tramas de Administración Protegidas, lo que bloquea los ataques de desautenticación. Todo el hardware de Cisco Meraki, HPE Aruba, Ruckus y Juniper Mist lo soporta. Pregunta: ¿Qué pasa con los dispositivos que no soportan 802.1X, como los sensores IoT o las impresoras heredadas? Utilice la Omisión de Autenticación MAC como alternativa, pero coloque esos dispositivos en una VLAN fuertemente restringida sin acceso a los recursos corporativos. Pregunta: ¿Cómo encaja Purple en esto? La plataforma de Guest WiFi de Purple gestiona la capa de acceso de visitantes y huéspedes: el Captive Portal, la captura de datos y la analítica. Su infraestructura 802.1X y SCEP gestiona el acceso del personal y de los dispositivos administrados. Funcionan en SSIDs y VLANs independientes. Purple se integra con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet, por lo que su inversión en hardware está protegida. [SECTION: Summary and Next Steps - approximately 1 minute] Para resumir. SCEP automatiza la emisión de certificados a escala. La clave privada permanece en el dispositivo; esa es la ventaja de seguridad sobre PKCS. Despliegue a través de MDM en una secuencia estricta: Raíz de Confianza, luego el perfil SCEP y después el perfil de WiFi, todos dirigidos al mismo grupo. Publique NDES a través de Application Proxy o migre a una PKI en la nube. Exija la verificación de CRL u OCSP en su servidor RADIUS. Y configure siempre la validación del certificado del servidor en los suplicantes del cliente. Si todavía utiliza una clave precompartida para el WiFi del personal, ese es el cambio que debe realizar este trimestre. La infraestructura de certificados requiere más trabajo inicial, pero elimina por completo una categoría entera de ataques basados en credenciales y, por lo general, reduce los tickets de soporte técnico relacionados con WiFi entre un 70 y un 80 por ciento una vez implementada. Para obtener la guía técnica completa, los diagramas de arquitectura y ejemplos prácticos, visite purple dot ai. Gracias por escuchar.