Cómo configurar SCEP para un acceso WiFi corporativo seguro y aprovisionamiento BYOD

Le damos la bienvenida a esta sesión técnica de Purple. Soy su anfitrión, y hoy profundizaremos en la configuración de SCEP para el aprovisionamiento seguro de WiFi corporativo y BYOD. Para los responsables de TI, arquitectos de red y CTO que operan en los sectores de la hostelería, el comercio minorista y el sector público, la gestión del acceso a la red es un 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: smartphones del personal, portátiles de contratistas, tabletas de puntos de venta... Y los métodos tradicionales para gestionar esto ya no son suficientes. Depender de claves precompartidas (PSK) para el WiFi del personal y BYOD es una vulnerabilidad de seguridad que tarde o temprano se explotará. Una contraseña compartida, una vez comprometida, da acceso a cualquiera a su red. Y el bypass de autenticación MAC (MAB) no es mejor. Los smartphones modernos utilizan direcciones MAC aleatorias por defecto, lo que rompe por completo el funcionamiento de MAB, y las direcciones MAC se pueden suplantar en cuestión de 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 acceder a la red. Pero aquí está el reto: ¿cómo se distribuyen certificados de cliente únicos a miles de dispositivos no gestionados sin saturar al servicio de soporte? La respuesta es el Protocolo de Inscripción de Certificados Simple, o SCEP. Comencemos con la arquitectura. SCEP es el estándar del sector para la inscripción de dispositivos corporativos, definido en la norma RFC 8894. Existe desde 1999, creado originalmente por VeriSign, y ha resistido el paso del tiempo porque resuelve un problema realmente complejo de forma elegante. En un flujo de trabajo de SCEP, el dispositivo genera su propio par de claves pública y privada de forma local. Crea una solicitud de firma de certificado (CSR) y la envía a través de un Servicio de Inscripción de Dispositivos de Red (NDES) a su Entidad de Certificación (CA). La CA valida la solicitud y devuelve el certificado público firmado al dispositivo. La ventaja de seguridad crítica 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 un portátil Windows, se trata del Módulo de Plataforma Segura (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 enormemente 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 la situación se vuelve realmente interesante desde el punto de vista operativo. Quiere que el personal pueda utilizar sus dispositivos personales para acceder a las herramientas internas, pero no quiere obligarles a registrarse en el MDM corporativo. Eso supone un problema de privacidad y genera una fuerte resistencia por parte de los empleados. 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 mediante la integración de SAML con Microsoft Entra ID, Okta o Google Workspace. Tras una autenticación correcta, 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 fluido para el usuario y seguro para la empresa. No necesitan saber nada sobre certificados o 802.1X. Solo tienen que iniciar sesión una vez y ya están conectados. Ahora, analicemos la implementación en detalle. La secuencia de despliegue es fundamental, y equivocarse en ella es la causa más común de fallo. Paso uno: desplegar el Certificado 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 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 clave para firma digital y cifrado de clave. En el uso extendido de clave, especifique Autenticación de Cliente con el OID 1.3.6.1.5.5.7.3.2. Vincule este perfil al perfil de certificado 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. Introduzca 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 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 informativa. Confianza, luego certificado, luego WiFi. En ese orden, siempre. Ahora permítame guiarle a través de algunas de las mejores prácticas que le ahorrarán importantes problemas 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 a las instalaciones. Pero exponer un servidor interno directamente a Internet es un riesgo de seguridad importante. Application Proxy le ofrece un acceso remoto seguro sin necesidad de abrir puertos de entrada en el cortafuegos. En segundo lugar, implemente certificados de corta duración para los 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 deberá 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. En tercer lugar, y esto es absolutamente crítico, configure su servidor RADIUS para aplicar una comprobació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 inmediatamente su acceso a la WiFi si su certificado de cliente sigue siendo válido. Su servidor RADIUS debe comprobar la CRL antes de conceder el acceso. Asegúrese de que sus puntos de distribución de CRL tengan una alta disponibilidad. Si el servidor RADIUS no puede acceder a la CRL, la autenticación fallará para todos. Eso se traduce en una interrupción generalizada del servicio. Ahora analicemos algunos de los fallos más comunes y cómo evitarlos. El problema más frecuente es que el perfil de WiFi no se aplique. El dispositivo recibe los certificados de raíz de confianza y SCEP, pero el perfil de WiFi se muestra como Error en la consola 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. Por lo general, esto se debe a que la cuenta de servicio del conector carece de los permisos necesarios en la plantilla de certificado, o a que un cortafuegos 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 e inscripción (Read y Enroll) en la plantilla de la CA. Revise los registros de su cortafuegos 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 sus smartphones personales para acceder a la aplicación de gestión de turnos. El responsable de TI quiere evitar el registro completo en el 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 mediante EAP-TLS. El servidor RADIUS asigna estos dispositivos a una VLAN restringida que solo permite el acceso a la aplicación de gestión de turnos. Cuando un miembro del personal dimite, su cuenta de Entra ID se deshabilita y el servidor RADIUS deniega el acceso a la red de forma instantánea. Escenario dos: una cadena minorista nacional con 500 tiendas que despliega WiFi seguro para tabletas de punto de venta propiedad de la empresa. El arquitecto de red debe garantizar que, incluso si se roba una tableta, las credenciales no se puedan extraer. La solución es Microsoft Intune desplegando certificados a través de SCEP. Intune envía el certificado raíz de confianza, 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 de POS minorista mediante EAP-TLS. Dado 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 conformidad de PCI DSS. Ahora, hablemos del caso de negocio. La transición al despliegue 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. Caducidad de contraseñas, bloqueos, errores tipográficos. La autenticación basada en certificados es invisible para el usuario. Los dispositivos se conectan automáticamente. Esto suele reducir el volumen de soporte relacionado con WiFi en un 70%. Se trata de una reducción material de los costes operativos. EAP-TLS elimina el riesgo de robo de credenciales y de ataques Man-in-the-Middle. Esto es fundamental para el cumplimiento de PCI DSS en entornos minoristas y de GDPR en todos los sectores. El coste de una brecha de datos supera con creces el coste de desplegar una infraestructura PKI adecuada. Y para las organizaciones que ya utilizan la plataforma de análisis y Guest WiFi de Purple, ampliar la incorporación segura a los dispositivos BYOD del personal proporciona una estrategia de gestión de red unificada. La capa en la nube de Purple, independiente del hardware, se integra con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet, por lo que no estará cautivo de un único proveedor de hardware. Purple opera en 80.000 sedes 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 concluir con un resumen rápido de las decisiones clave que debe tomar. ¿Debería utilizar SCEP o PKCS? Utilice SCEP para la autenticación WiFi. La clave privada permanece en el dispositivo. Utilice 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 gestionados por la empresa. ¿Debería utilizar la segmentación por usuario o por dispositivo en su MDM? Utilice la segmentación por dispositivo para los dispositivos corporativos que necesitan conectarse antes de que el usuario inicie sesión. Utilice la segmentación por usuario para BYOD, donde el certificado debe estar vinculado al individuo. ¿Cómo se gestiona la fragmentación de Android? Utilice Passpoint, también conocido como Hotspot 2.0, siempre que sea posible. Ofrece una experiencia de conexión uniforme en todos los fabricantes de Android. Y por último, ¿qué es lo más importante que hay que hacer bien? La comprobación de CRL en su servidor RADIUS. Sin ella, un certificado revocado aún puede conceder acceso a la red. Con esto concluye el informe de hoy. Si desea profundizar en alguno de estos temas, las guías técnicas de Purple sobre seguridad WiFi empresarial y autenticación de certificados EAP-TLS están disponibles en el sitio web de Purple en purple.ai. Gracias por su atención.