Cómo configurar SCEP para un aprovisionamiento seguro de WiFi empresarial y BYOD

Le damos la bienvenida a esta sesión informativa técnica de Purple. Soy su anfitrión, y hoy profundizaremos en la configuración de SCEP para un aprovisionamiento seguro de WiFi empresarial y BYOD. Para los gerentes de TI, arquitectos de redes y CTO que operan en los sectores de hotelería, comercio minorista y público, la gestión del acceso a la red es un acto de equilibrio constante entre la seguridad y la eficiencia operativa. Se enfrentan a cientos, a veces miles de dispositivos que se conectan a su red todos los días. Teléfonos inteligentes del personal, computadoras portátiles de contratistas, tabletas de puntos de venta. Y las viejas formas de manejar esto simplemente ya no son suficientes. Depender de claves precompartidas, o PSK, para el WiFi del personal y BYOD es una vulnerabilidad de seguridad que espera ser explotada. Una contraseña compartida, una vez comprometida, le da a cualquiera acceso a su red. Y el MAC Authentication Bypass, o MAB, no es mejor. Los teléfonos inteligentes modernos utilizan direcciones MAC aleatorias de forma predeterminada, lo que rompe por completo el funcionamiento de MAB, y las direcciones MAC se pueden suplantar en segundos. La arquitectura de red moderna exige una autenticación 802.1X mediante EAP-TLS. Esto garantiza que cada dispositivo se verifique criptográficamente antes de tocar la red. Pero aquí está el desafío: ¿cómo distribuir certificados de cliente únicos a miles de dispositivos no administrados sin saturar a su mesa de ayuda? La respuesta es el Protocolo de Inscripción de Certificados Simple, o SCEP. Comencemos con la arquitectura. SCEP es el estándar de la industria para el registro de dispositivos empresariales, definido en la norma RFC 8894. Existe desde 1999, creado originalmente por VeriSign, y ha resistido la prueba del tiempo porque resuelve un problema genuinamente difícil de manera elegante. En un flujo de trabajo de SCEP, el dispositivo genera su propio par de claves privada y pública de forma local. Crea una solicitud de firma de certificado, o CSR, y la envía a través de un Servicio de Inscripción de Dispositivos de Red, conocido como NDES, a su Autoridad de Certificación, o CA. La CA valida la solicitud y devuelve el certificado público firmado al dispositivo. La ventaja crítica de seguridad aquí es que la clave privada nunca sale del dispositivo. Se genera localmente y se almacena en el enclave seguro de hardware del dispositivo. En una computadora portátil Windows, ese es el Módulo de Plataforma de Confianza, o TPM. En un iPhone, es el Secure Enclave. La clave privada nunca se transmite a través de la red. Esto es lo que hace que SCEP sea muy superior a alternativas como PKCS para la autenticación de red, donde la CA genera el par de claves de forma centralizada y lo transmite al dispositivo. Ahora, hablemos de BYOD. Aquí es donde se pone realmente interesante desde el punto de vista operativo. Usted desea que el personal pueda usar sus dispositivos personales para acceder a las herramientas internas, pero no quiere obligarlos a registrarse en su MDM corporativo. Esa es una preocupación de privacidad y genera una fuerte resistencia por parte del personal. La solución es un portal de incorporación de autoservicio. Así es como funciona. El usuario conecta su dispositivo personal a un SSID de aprovisionamiento dedicado. Esta red es un entorno cerrado (walled garden) que restringe el acceso a todo excepto al portal de incorporación y a su proveedor de identidad. El usuario se autentica con sus credenciales corporativas, normalmente a través de la integración de SAML con Microsoft Entra ID, Okta o Google Workspace. Tras una autenticación exitosa, el sistema genera un certificado de cliente único y específico para el dispositivo a través de SCEP. Se envía un perfil de configuración al dispositivo que contiene el certificado, el certificado de la CA raíz y la configuración de red. Luego, el dispositivo se conecta automáticamente al SSID corporativo seguro mediante EAP-TLS. Es transparente para el usuario y seguro para la empresa. No necesitan saber nada sobre certificados o 802.1X. Solo inician sesión una vez y ya están conectados. Ahora, analicemos la implementación en detalle. La secuencia de implementación es crítica, y equivocarse es la causa más común de falla. Paso uno: implementar el certificado Trusted Root. Antes de que cualquier dispositivo pueda solicitar un certificado de cliente o confiar en su servidor RADIUS, debe confiar en la Autoridad de Certificación emisora. Exporte su certificado de CA raíz como un archivo .cer y despliéguelo en sus grupos de dispositivos de destino. Este paso no es negociable. Sin él, toda la cadena falla. Paso dos: configurar el perfil de certificado SCEP. Esto indica a los dispositivos cómo obtener su certificado de cliente. Debe configurar el formato del nombre del sujeto (subject name). Para la autenticación basada en el usuario, el estándar es CN igual a UserPrincipalName. Para la autenticación de dispositivos, use CN igual al ID de dispositivo de Azure AD. Establezca el uso de la clave para firma digital y cifrado de clave (key encipherment). En el uso extendido de la clave, especifique Autenticación de Cliente (Client Authentication) con el OID 1.3.6.1.5.5.7.3.2. Vincule este perfil al perfil de certificado Trusted Root del paso uno. Y proporcione la URL externa de su servidor NDES. Paso tres: implementar el perfil de WiFi 802.1X. Esto vincula los certificados al SSID de la red. Ingrese el nombre de la red exactamente como lo transmiten sus puntos de acceso. Establezca el tipo de seguridad en WPA2-Enterprise o WPA3-Enterprise. Establezca el tipo de EAP en EAP-TLS. Seleccione el perfil de certificado SCEP como el certificado de autenticación de cliente. Y especifique el certificado Trusted Root para la validación del servidor. Esta secuencia es lo más importante que debe recordar de toda esta sesión informativa. Confianza, luego certificado, luego WiFi. En ese orden, siempre. Ahora permítame guiarlo a través de algunas de las mejores prácticas que le ahorrarán dolores de cabeza significativos en producción. Primero, publique su servidor NDES a través de Azure AD Application Proxy. El servidor NDES debe ser accesible desde internet para permitir que los dispositivos remotos aprovisionen certificados antes de llegar al sitio. Pero exponer un servidor interno directamente a internet es un riesgo de seguridad significativo. Application Proxy le brinda acceso remoto seguro sin abrir puertos de firewall entrantes. Segundo, implemente certificados de corta duración para dispositivos BYOD. En lugar de un certificado válido por tres años, emita certificados válidos por 90 días. Cuando el certificado expira, el usuario debe volver a autenticarse a través del portal de incorporación. Esto depura de forma natural los dispositivos inactivos de la red. Un dispositivo que no se ha utilizado en 90 días simplemente se desconecta. No se requiere limpieza manual. Tercero, y esto es absolutamente crítico, configure su servidor RADIUS para aplicar una verificación estricta de la Lista de Revocación de Certificados (CRL). Cuando un empleado deja la organización, deshabilitar su cuenta de Active Directory puede no revocar de inmediato su acceso a WiFi si su certificado de cliente sigue siendo válido. Su servidor RADIUS debe verificar la CRL antes de otorgar el acceso. Asegúrese de que sus puntos de distribución de CRL tengan una alta disponibilidad. Si el servidor RADIUS no puede comunicarse con la CRL, la autenticación fallará para todos. Eso representa una interrupción generalizada del servicio. Ahora veamos algunos modos de falla comunes y cómo evitarlos. El problema más frecuente es que el perfil de WiFi no se aplica. El dispositivo recibe los certificados Trusted Root y SCEP, pero el perfil de WiFi se muestra como Error en la consola de MDM. Nueve de cada diez veces, esto se debe a una discrepancia en la asignación de grupos. Si el perfil SCEP está asignado a un grupo de usuarios, pero el perfil de WiFi está asignado a un grupo de dispositivos, el MDM no puede resolver la dependencia. Audite sus asignaciones. Asegúrese de que los tres perfiles se dirijan exactamente al mismo grupo. El segundo problema común son los errores NDES 403 Forbidden. Los dispositivos no logran recuperar el certificado SCEP y los registros de IIS de NDES muestran errores HTTP 403. Esto suele deberse a que la cuenta de servicio del conector carece de los permisos necesarios en la plantilla de certificado, o a que un firewall está bloqueando los parámetros específicos de la cadena de consulta utilizados por SCEP. Verifique que la cuenta del conector tenga permisos de lectura (Read) e inscripción (Enroll) en la plantilla de la CA. Revise los registros de su firewall para asegurarse de que no se estén bloqueando las URL que contienen el parámetro 'operation=GetCACaps'. Permítame presentarle dos escenarios del mundo real para ilustrar cómo funciona esto en la práctica. Escenario uno: un hotel de 200 habitaciones con 50 empleados de limpieza que utilizan teléfonos inteligentes personales para acceder a la aplicación de programación. El gerente de TI quiere evitar el registro completo en MDM para respetar la privacidad del personal. La solución es un portal de autoservicio integrado con Microsoft Entra ID. El personal se conecta al SSID de aprovisionamiento, inicia sesión con sus credenciales de Entra ID y descarga un perfil SCEP. El servidor SCEP emite un certificado de cliente de 30 días directamente al dispositivo. El dispositivo se conecta al SSID Staff WiFi mediante EAP-TLS. El servidor RADIUS asigna estos dispositivos a una VLAN restringida que solo permite el acceso a la aplicación de programación. Cuando un miembro del personal renuncia, su cuenta de Entra ID se deshabilita y el servidor RADIUS deniega instantáneamente el acceso a la red. Escenario dos: una cadena minorista nacional con 500 tiendas que implementa WiFi seguro para tabletas de punto de venta propiedad de la empresa. El arquitecto de redes debe garantizar que, incluso si se roba una tableta, las credenciales no se puedan extraer. La solución es Microsoft Intune implementando certificados a través de SCEP. Intune envía el certificado Trusted Root, seguido de un perfil SCEP que indica a la tableta que genere su propia clave privada en su enclave seguro de hardware. La tableta envía una CSR al servidor NDES, recibe el certificado de cliente y se conecta al SSID Retail POS mediante EAP-TLS. Debido a que la clave privada se genera localmente y nunca se transmite, las credenciales de una tableta robada no se pueden utilizar en ningún otro lugar. Esto cumple con los requisitos de cumplimiento de PCI DSS. Ahora, hablemos del caso de negocio. La transición a la implementación de certificados SCEP 802.1X ofrece retornos medibles en seguridad y operaciones. El WiFi basado en contraseñas genera un volumen significativo de tickets de soporte. Vencimientos de contraseñas, bloqueos, errores de escritura. La autenticación basada en certificados es invisible para el usuario. Los dispositivos se conectan automáticamente. Esto normalmente reduce el volumen de soporte relacionado con WiFi en un 70%. Esa es una reducción material en el costo operativo. EAP-TLS elimina el riesgo de robo de credenciales y ataques de intermediario (Man-in-the-Middle). Esto es fundamental para el cumplimiento de PCI DSS en entornos minoristas y de GDPR en todos los sectores. El costo de una filtración de datos supera con creces el costo de implementar una infraestructura PKI adecuada. And for organisations already running Purple's Guest WiFi and analytics platform, extending secure onboarding to staff BYOD devices provides a unified network management strategy. La capa de nube independiente del hardware de Purple se integra con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet, por lo que no está limitado a un solo proveedor de hardware. Purple opera en 80,000 establecimientos activos y ha procesado 440 millones de inicios de sesión en 2024, contando con las certificaciones ISO 27001, GDPR, CCPA y Cyber Essentials. Permítame cerrar con un resumen rápido de las decisiones clave que debe tomar. ¿Debería usar SCEP o PKCS? Use SCEP para la autenticación de WiFi. La clave privada permanece en el dispositivo. Use PKCS solo para el cifrado de correo electrónico donde se requiera el depósito de claves. ¿Cuánto tiempo deben ser válidos los certificados? 90 días para BYOD. De uno a dos años para dispositivos administrados por la empresa. ¿Debería usar la asignación por usuario o por dispositivo en su MDM? Use la asignación por dispositivo para los dispositivos corporativos que necesitan conectarse antes del inicio de sesión del usuario. Use la asignación por usuario para BYOD donde el certificado deba estar vinculado al individuo. ¿Cómo se maneja la fragmentación de Android? Use Passpoint, también conocido como Hotspot 2.0, siempre que sea posible. Proporciona una experiencia de conexión constante entre los diferentes fabricantes de Android. Y finalmente, ¿qué es lo más importante que debe hacer bien? La verificación de CRL en su servidor RADIUS. Sin ella, un certificado revocado aún puede otorgar acceso a la red. Con esto concluye la sesión informativa de hoy. Si desea profundizar en cualquiera de estos temas, las guías técnicas de Purple sobre seguridad de WiFi empresarial y autenticación de certificados EAP-TLS están disponibles en el sitio web de Purple en purple.ai. Gracias por escuchar.