Cómo configurar SCEP para el aprovisionamiento de WiFi corporativo seguro y BYOD

Bienvenido a este informe técnico de Purple. Soy su anfitrión y hoy profundizaremos en la configuración de SCEP para el aprovisionamiento seguro de WiFi empresarial y BYOD. Para los directores de TI, arquitectos de red y Directores de Tecnología (CTO) que operan en los sectores de hospitalidad, retail y público, administrar el acceso a la red es un acto de equilibrio constante entre la seguridad y la eficiencia operativa. Tienen que lidiar con cientos, a veces miles de dispositivos que se conectan a su red todos los días: smartphones del personal, laptops de contratistas, tabletas de punto de venta. Y las formas tradicionales de manejar esto ya no son suficientes. Depender de claves precompartidas o PSK para el WiFi del personal y BYOD es una vulnerabilidad de seguridad latente. Una contraseña compartida, una vez comprometida, le da a cualquiera acceso a su red. Y el bypass de autenticación de direcciones MAC o MAB no es mejor. Los smartphones modernos utilizan direcciones MAC aleatorias por defecto, lo que rompe el MAB por completo, y las direcciones MAC se pueden suplantar en segundos. La arquitectura de red moderna exige la autenticación 802.1X utilizando 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 departamento de soporte técnico? 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 RFC 8894. Ha existido desde 1999, creado originalmente por VeriSign, y ha resistido la prueba del tiempo porque resuelve de manera elegante un problema genuinamente difícil. En un flujo de trabajo de SCEP, el dispositivo genera su propio par de claves pública y privada localmente. Crea una Solicitud de Firma de Certificado o CSR y la envía a través de un Servicio de Registro 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 laptop 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 infinitamente 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 verdaderamente interesante desde el punto de vista operativo. Quiere que el personal pueda usar sus dispositivos personales para acceder a las herramientas internas, pero no quiere obligarlos a registrarse en el MDM corporativo. Eso representa 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 jardín amurallado, 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 una integración SAML con Microsoft Entra ID, Okta o Google Workspace. Una vez autenticado correctamente, 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 los ajustes de red. A continuación, el dispositivo se conecta automáticamente al SSID corporativo seguro mediante EAP-TLS. Es un proceso transparente para el usuario y seguro para la empresa. No necesitan saber nada sobre certificados ni 802.1X. Solo inician sesión una vez y ya están conectados. Ahora, analicemos la implementación en detalle. La secuencia de despliegue es fundamental, y hacerla de forma incorrecta es la causa más común de fallas. Paso uno: desplegar el Certificado de Raíz de Confianza. 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. Para la autenticación dirigida por 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 en firma digital y cifrado de clave. En el uso de clave extendido, especifique Autenticación de Cliente con el OID 1.3.6.1.5.5.7.3.2. Vincule este perfil al perfil de certificado de Raíz de Confianza del paso uno. Y proporcione la URL externa de su servidor NDES. Paso tres: desplegar el Perfil 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 o WPA3. Establezca el tipo de EAP en EAP-TLS. Seleccione el perfil de certificado SCEP como el certificado de autenticación del cliente. Y especifique el certificado de Raíz de Confianza para la validación del servidor. Esta secuencia es lo más importante que debe recordar de toda esta sesión. Confianza, luego certificado, luego WiFi. En ese orden, siempre. Ahora permítame presentarle algunas de las mejores prácticas que le ahorrarán problemas significativos en producción. Primero, publique su servidor NDES a través de Azure AD Application Proxy. El servidor NDES debe estar accesible desde internet para permitir que los dispositivos remotos aprovisionen certificados antes de que lleguen a las instalaciones. Pero exponer un servidor interno directamente a internet es un riesgo de seguridad importante. 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 expire, el usuario debe volver a autenticarse a través del portal de incorporación. Esto elimina de forma natural los dispositivos obsoletos 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 podría 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 estén altamente disponibles. Si el servidor RADIUS no puede comunicarse con la CRL, la autenticación fallará para todos. Eso es una interrupción generalizada. Ahora analicemos 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 estén dirigidos exactamente al mismo grupo. El segundo problema común son los errores NDES 403 Prohibido. Los dispositivos no logran recuperar el certificado SCEP y los registros de NDES IIS muestran errores HTTP 403. Por lo general, esto se debe a que la cuenta de servicio del conector no tiene 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 que utiliza SCEP. Verifique que la cuenta del conector tenga permisos de Lectura e Inscripción 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 equals 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 smartphones personales para acceder a la aplicación de programación. El gerente de TI quiere evitar la inscripción completa 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 de la WiFi del personal utilizando 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 niega el acceso a la red de forma instantánea. Escenario dos: una cadena minorista nacional con 500 tiendas que implementa WiFi segura para tabletas de punto de venta propiedad de la empresa. El arquitecto de red debe asegurarse de que, incluso si roban 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 Root de confianza, seguido de un perfil SCEP que indica a la tableta que genere su propia clave privada en su enclave de seguridad de hardware. La tableta envía una solicitud CSR al servidor NDES, recibe el certificado de cliente y se conecta al SSID de POS minorista 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 usar 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. La WiFi basada en contraseñas genera un volumen significativo de tickets de soporte técnico. 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 suele reducir el volumen de soporte técnico 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. Y para las organizaciones que ya ejecutan la plataforma de análisis y Guest WiFi de Purple, extender la incorporación segura a los dispositivos BYOD del personal proporciona una estrategia de gestión de red unificada. La plataforma en la nube agnóstica de 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 ubicaciones activas 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 WiFi. La clave privada permanece en el dispositivo. Use PKCS solo para el cifrado de correo electrónico donde se requiere el depósito de claves. ¿Cuánto tiempo deben ser válidos los certificados? 90 días para BYOD. Uno a dos años para dispositivos administrados por la empresa. ¿Debería usar la segmentación por usuario o por dispositivo en su MDM? Use la segmentación por dispositivo para los dispositivos corporativos que necesitan conectarse antes de que el usuario inicie sesión. Use la segmentación por usuario para BYOD, donde el certificado debe 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 fabricantes de Android. Y por último, ¿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 el reporte de hoy. Si desea profundizar en alguno 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 de Purple en purple.ai. Gracias por escuchar.