Saltar al contenido principal

La guía empresarial de SCEP: Despliegue de Simple Certificate Enrollment Protocol para la seguridad automatizada de WiFi en campus

Esta guía de referencia técnica proporciona un diseño arquitectónico definitivo y una estrategia de implementación paso a paso para el despliegue de certificados WiFi empresariales mediante SCEP. Cubre las diferencias críticas entre SCEP y PKCS, la secuencia exacta de despliegue requerida para el éxito y estrategias reales de mitigación de riesgos para líderes de TI.

📖 6 min de lectura📝 1,270 palabras🔧 2 ejemplos prácticos3 preguntas de práctica📚 8 definiciones clave

Escuchar esta guía

Ver transcripción del podcast
Buenos días. Si gestiona la infraestructura WiFi en un grupo hotelero, una red de tiendas, un estadio o un campus universitario, esta sesión informativa es para usted. Vamos a hablar de SCEP (Simple Certificate Enrollment Protocol) y, específicamente, de cómo resuelve uno de los dolores de cabeza más persistentes en el WiFi empresarial: instalar certificados en miles de dispositivos de forma automática, sin que su servicio de soporte se ahogue en solicitudes. [short pause] Permítame ponerle en situación. Ha decidido, acertadamente, que las claves precompartidas ya no son aceptables para el WiFi del personal. Una sola contraseña comprometida expone todo su segmento de red. Ha migrado, o está migrando, a la autenticación 802.1X. Ese es el estándar IEEE que requiere que cada dispositivo demuestre su identidad antes de obtener acceso a la red. La variante más segura de 802.1X es EAP-TLS (Extensible Authentication Protocol con Transport Layer Security), que utiliza certificados digitales en lugar de contraseñas. Los certificados son criptográficamente únicos por dispositivo, no se pueden compartir y se pueden revocar instántaneamente si se pierde un dispositivo o un empleado se marcha. [short pause] Hasta ahí, todo bien. El problema es la distribución. ¿Cómo se consigue instalar un certificado único en cada portátil, cada teléfono, cada tableta de su propiedad (en Windows, iOS, Android, macOS) sin que un técnico tenga que tocar cada dispositivo? Eso es precisamente lo que resuelve SCEP. [medium pause] SCEP fue formalizado por el Internet Engineering Task Force en el RFC 8894 en 2020, aunque se utiliza en entornos empresariales desde principios de la década de 2000. Es un protocolo que permite a un dispositivo gestionado solicitar su propio certificado directamente a su Autoridad de Certificación, utilizando una URL preconfigurada y una contraseña de desafío. El punto de seguridad crítico aquí: la clave privada se genera en el propio dispositivo, se almacena en el enclave seguro del dispositivo (el chip TPM en dispositivos Windows o el Secure Enclave en el hardware de Apple) y nunca viaja por la red. El dispositivo genera una Solicitud de Firma de Certificado, la envía a la pasarela SCEP, la pasarela valida el desafío, reenvía la solicitud a su Autoridad de Certificación, la CA la firma y el certificado firmado vuelve al dispositivo. Todo el proceso es invisible para el usuario final. [short pause] Ahora bien, en un entorno de Microsoft, la pasarela SCEP suele ser NDES (Network Device Enrollment Service), un rol de Windows Server que actúa como intermediario entre su plataforma MDM y su CA. Microsoft Intune inserta el perfil SCEP en los dispositivos gestionados, indicándoles la URL de NDES y la contraseña de desafío. Los dispositivos hacen el resto automáticamente. [medium pause] Permítame guiarle a través de cómo es un despliegue real. Piense en un grupo hotelero con 150 propiedades, a escala de Premier Inn. Tienen una combinación de portátiles Windows para el personal de recepción, dispositivos iOS para los supervisores de limpieza y tabletas Android en el punto de venta del restaurante. Antes de SCEP, utilizaban WPA2-Personal con una contraseña compartida que se rotaba trimestralmente. Cada rotación generaba una oleada de llamadas al servicio de soporte. Con SCEP e Intune, despliegan tres perfiles en secuencia. Primero, el perfil de Certificado de Raíz de Confianza: este indica a cada dispositivo que confíe en la Autoridad de Certificación de la empresa. Segundo, el perfil de Certificado SCEP: este indica a los dispositivos que vayan a recoger su certificado de cliente único. Tercero, el perfil de WiFi: este configura el SSID, establece el tipo de seguridad en WPA2-Enterprise o WPA3-Enterprise y apunta al certificado SCEP para la autenticación. Despliegue esos tres perfiles en el mismo grupo de dispositivos en Intune, y cada dispositivo gestionado se conectará al SSID corporativo automáticamente, con un certificado único y sin necesidad de interacción por parte del usuario. [short pause] El servidor RADIUS (normalmente Microsoft NPS o un servicio RADIUS en la nube) recibe la solicitud de autenticación EAP-TLS, valida el certificado frente a la CA, comprueba la Lista de Revocación de Certificados y concede o deniega el acceso. Si se da de baja a un empleado, se revoca su certificado en la CA. Su dispositivo pierde el acceso a la WiFi en el siguiente ciclo de autenticación. Sin necesidad de restablecer contraseñas. Sin esperar a una rotación trimestral. [medium pause] Ahora, la gente suele preguntar sobre la diferencia entre SCEP y PKCS (Public Key Cryptography Standards). Ambos funcionan con Intune. La diferencia clave es dónde se genera la clave privada. Con SCEP, se genera en el dispositivo. Con PKCS, la CA genera ambas claves de forma centralizada y envía la clave privada al dispositivo. Eso significa que la clave privada viaja por la red, lo que introduce un riesgo teórico de interceptación. PKCS tiene su utilidad: se adapta mejor al cifrado de correo electrónico S/MIME, donde el depósito de claves es importante. Para la autenticación WiFi, SCEP es la opción correcta. Siempre. [short pause] Permítame plantearle un segundo escenario: una red de tiendas. Imagine un minorista de moda con 200 tiendas en todo el Reino Unido, cada una con puntos de acceso Cisco Meraki. Sus sistemas de punto de venta están basados en Windows y se gestionan a través de Intune. Necesitan la conformidad con PCI DSS, lo que significa segmentación de red y autenticación sólida para cualquier dispositivo que maneje datos de titulares de tarjetas. EAP-TLS basado en SCEP les proporciona autenticación a nivel de dispositivo en el SSID del personal, con una asignación de VLAN gestionada por la política RADIUS. Los terminales de punto de venta acceden automáticamente a la VLAN dentro del alcance de PCI. El WiFi para invitados, gestionado por separado a través de una plataforma como Purple, funciona en un SSID completamente aislado con su propio flujo de autenticación. Las dos redes nunca se tocan. Los auditores están contentos. El equipo de seguridad duerme mejor. [medium pause] Bien, hablemos de los errores comunes, porque hay algunos que suelen pillar desprevenidos a los equipos. [short pause] El modo de fallo más común son las discrepancias en la asignación de grupos en Intune. Su perfil de Raíz de Confianza, su perfil SCEP y su perfil de WiFi deben dirigirse todos al mismo grupo de Azure AD. Si el perfil SCEP se dirige a un grupo de Usuarios y el perfil de WiFi se dirige a un grupo de Dispositivos, Intune no puede resolver la dependencia y el perfil de WiFi se muestra como un error. Compruebe primero sus asignaciones; casi siempre es el culpable. [short pause] Segundo error común: la disponibilidad del servidor NDES. Su servidor NDES debe ser accesible desde internet para que los dispositivos remotos se registren antes de llegar a las instalaciones. La forma segura de hacerlo es a través de Azure AD Application Proxy, que le proporciona acceso remoto sin abrir puertos de entrada en el cortafuegos. No exponga NDES directamente a internet. [short pause] Tercero: la disponibilidad de la CRL. Su servidor RADIUS comprueba la Lista de Revocación de Certificados cada vez que un dispositivo se autentica. Si el punto de distribución de la CRL no está accesible (tal vez un servidor está caído o ha cambiado una regla del cortafuegos), la autenticación falla para todos. Haga que sus puntos finales de CRL sean altamente disponibles y pruébelos con regularidad. [short pause] Cuarto: los permisos de la plantilla de certificado. Si la cuenta de servicio del conector NDES no tiene permisos de Lectura e Inscripción (Read and Enroll) en la plantilla de certificado, los dispositivos reciben errores HTTP 403 cuando intentan recoger su certificado. Es una solución de permisos sencilla, pero es fácil pasarla por alto durante la configuración inicial. [medium pause] Y ahora, una ronda de preguntas rápidas. [short pause] ¿Puede SCEP funcionar con MDM que no sean de Microsoft? Sí, Jamf para flotas de dispositivos Apple, VMware Workspace ONE y la mayoría de las plataformas MDM empresariales admiten perfiles SCEP. El protocolo es independiente del proveedor. [short pause] ¿Funciona SCEP con PKI en la nube? Sí. La propia PKI en la nube de Microsoft en Intune Suite elimina por completo la necesidad de un servidor NDES local. Los proveedores de PKI en la nube de terceros como SecureW2 y Keyfactor también ofrecen puntos finales SCEP en la nube. [short pause] ¿Qué pasa con WPA3-Enterprise? WPA3-Enterprise utiliza la misma pila de autenticación 802.1X y EAP-TLS. Los certificados emitidos por SCEP funcionan de manera idéntica. La actualización se realiza en la capa del protocolo inalámbrico, no en la capa del certificado. [short pause] ¿Cuánto duran los certificados? Normalmente un año, aunque se pueden configurar periodos de validez más cortos. Intune gestiona la renovación automática antes del vencimiento, por lo que los usuarios nunca experimentan interrupciones. [medium pause] En resumen. SCEP automatiza la distribución de certificados a escala, eliminando la sobrecarga manual del despliegue de PKI en grandes flotas de dispositivos. La clave privada se queda en el dispositivo; esa es la base de seguridad de EAP-TLS. Despliegue en secuencia: primero la Raíz de Confianza, segundo el perfil SCEP, tercero el perfil de WiFi, todos dirigidos al mismo grupo. Publique su punto final NDES de forma segura a través de Application Proxy. Mantenga sus puntos finales de CRL altamente disponibles. Y si empieza de cero, evalúe la PKI en la nube para eliminar por completo la dependencia de NDES local. [short pause] Para el WiFi de invitados (la red independiente orientada a los visitantes), la autenticación basada en certificados no es el modelo adecuado. Los invitados no tienen dispositivos gestionados. Ahí es donde una plataforma como Purple gestiona el flujo de autenticación: Captive Portal, inicio de sesión social, captura de correo electrónico o verificación por SMS, todo ello alimentando una capa de datos de origen que su equipo de marketing realmente puede utilizar. Ambos enfoques se complementan: SCEP para su flota de personal gestionada, Purple para su red de invitados. Ambos funcionando en el mismo hardware, segmentados limpiamente por VLAN. [short pause] Esta ha sido su sesión informativa sobre la incorporación a WiFi empresarial con SCEP. La guía escrita completa, con diagramas de arquitectura, configuración paso a paso de Intune y ejemplos prácticos, está disponible en el sitio web de Purple. Gracias por escuchar.

header_image.png

Resumen ejecutivo

Para los establecimientos empresariales, ya sea un entorno hotelero con gran actividad, una operación minorista con múltiples sedes o un campus corporativo moderno, confiar en claves precompartidas o en Captive Portals básicos para el WiFi del personal es una vulnerabilidad de seguridad y un cuello de botella operativo. La arquitectura de red moderna exige la autenticación 802.1X mediante EAP-TLS, lo que garantiza que cada dispositivo se verifique criptográficamente antes de acceder a la red.

El desafío radica en la distribución: ¿cómo se despliegan certificados de cliente únicos en miles de dispositivos Windows, iOS y Android sin saturar a su servicio de soporte con solicitudes de asistencia? Microsoft Intune y otras plataformas MDM resuelven esto mediante la gestión automatizada del ciclo de vida de los certificados. Al desplegar perfiles de Simple Certificate Enrollment Protocol (SCEP), los equipos de TI envían certificados raíz y de cliente de confianza de forma silenciosa a los dispositivos finales gestionados.

Esta guía proporciona un diseño arquitectónico definitivo y una estrategia de implementación paso a paso para el despliegue de certificados WiFi empresariales. Exploramos las diferencias críticas entre SCEP y PKCS, detallamos la secuencia exacta de despliegue requerida para el éxito y esbozamos estrategias reales de mitigación de riesgos para garantizar que su WiFi para invitados y sus redes corporativas sigan siendo seguras y eficientes.

Escuche la sesión informativa

Análisis técnico profundo: Arquitectura SCEP

Al diseñar su estrategia de despliegue de certificados WiFi empresariales, la primera decisión arquitectónica es seleccionar el mecanismo de entrega de certificados. Las plataformas de gestión de dispositivos móviles admiten tanto SCEP como PKCS, pero funcionan de manera fundamentalmente diferente.

Simple Certificate Enrollment Protocol (SCEP)

SCEP es el estándar del sector para el registro de dispositivos empresariales. En un flujo de trabajo SCEP, el servicio de gestión indica al dispositivo final que genere su propio par de claves privada y pública. El dispositivo crea una Solicitud de Firma de Certificado (CSR) y la envía a través de un servidor de Network Device Enrollment Service (NDES) a su Autoridad de Certificación (CA). La CA firma la solicitud y devuelve el certificado público al dispositivo.

La ventaja de seguridad crítica de SCEP es que la clave privada nunca sale del dispositivo. Se genera localmente, se almacena en el enclave seguro del dispositivo (como el TPM en Windows o el Secure Enclave en iOS) y nunca se transmite a través de la red. Esto hace que SCEP sea el enfoque firmemente recomendado para la autenticación 802.1X.

scep_architecture_overview.png

Public Key Cryptography Standards (PKCS)

Por el contrario, con PKCS, la Autoridad de Certificación genera tanto la clave pública como la privada de forma centralizada. El conector de certificados exporta de forma segura este par de claves y lo envía al dispositivo de destino.

Aunque PKCS elimina la necesidad de desplegar y mantener un servidor NDES, simplificando la infraestructura, introduce un riesgo de seguridad teórico porque la clave privada se transmite a través de la red. PKCS suele adaptarse mejor a los casos de uso en los que se requiere el depósito de claves, como el cifrado de correo electrónico S/MIME, en lugar de la autenticación de red.

scep_vs_pkcs_comparison.png

Guía de implementación: La secuencia de despliegue

Configurar correctamente un perfil de WiFi gestionado para 802.1X requiere el cumplimiento estricto de una secuencia de despliegue específica. Las dependencias de los perfiles dictan que se debe establecer la confianza antes de poder configurar la autenticación.

Paso 1: Desplegar el perfil de 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.

  1. Exporte su certificado de CA raíz y cualquier certificado de CA intermedia como archivos .cer.
  2. En su consola de MDM, cree un nuevo perfil de configuración.
  3. Seleccione la plataforma de destino y elija el tipo de perfil de certificado de confianza.
  4. Suba el archivo .cer y despliegue este perfil en sus grupos de dispositivos de destino.

Paso 2: Configurar el perfil de Certificado SCEP

Una vez establecida la confianza, configure el perfil SCEP para indicar a los dispositivos cómo obtener su certificado de cliente.

  1. Cree un nuevo perfil de configuración y seleccione certificado SCEP.
  2. Configure el formato del nombre del sujeto. Para la autenticación basada en el usuario, CN={{UserPrincipalName}} es el estándar. Para la autenticación de dispositivos, utilice CN={{AAD_Device_ID}}.
  3. Establezca el uso de la clave para firma digital y cifrado de clave (digital signature y key encipherment).
  4. En el uso extendido de la clave, especifique la autenticación del cliente (OID: 1.3.6.1.5.5.7.3.2).
  5. Vincule este perfil al perfil de certificado de raíz de confianza creado en el Paso 1.
  6. Proporcione la URL externa de su pasarela SCEP o servidor NDES.

Paso 3: Desplegar el perfil de WiFi 802.1X

El paso final es enviar la configuración de WiFi que vincula los certificados al SSID de la red.

  1. Cree un perfil de configuración de WiFi.
  2. Introduzca el nombre de la red exactamente como lo transmiten sus puntos de acceso inalámbricos.
  3. Seleccione WPA2-Enterprise o WPA3-Enterprise como tipo de seguridad.
  4. Establezca el tipo de EAP en EAP-TLS.
  5. En la configuración de autenticacigs, seleccione el perfil de certificado SCEP creado en el Paso 2 como certificado de autenticación de cliente.
  6. Especifique el certificado raíz de confianza para la validación del servidor para garantizar que el dispositivo solo se conecte a su servidor RADIUS legítimo.

Mejores prácticas y estándares del sector

Al implementar el despliegue de certificados SCEP, siga las siguientes mejores prácticas independientes del proveedor para garantizar el cumplimiento y la fiabilidad.

Ubicación y seguridad de la pasarela SCEP

La pasarela SCEP debe ser accesible desde internet para permitir que los dispositivos remotos aprovisionen certificados antes de llegar a las instalaciones. Exponer un servidor interno directamente a internet representa un riesgo de seguridad significativo. Publique la URL de SCEP utilizando un proxy de aplicación o un proxy inverso. Esto proporciona un acceso remoto seguro sin abrir puertos de entrada en el cortafuegos y le permite aplicar políticas de acceso condicional al flujo de registro.

Comprobación de RADIUS y CRL

El despliegue de certificados es solo la mitad de la ecuación de seguridad; la revocación es igual de crítica. Si se rescinde el contrato de un empleado, es posible que la desactivación de su cuenta de directorio no revoque de inmediato su acceso a la WiFi si su certificado de cliente sigue siendo válido y el servidor RADIUS no está comprobando estrictamente la Lista de Revocación de Certificados (CRL).

Configure su servidor RADIUS para exigir una comprobación estricta de la CRL. 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á, lo que provocará una interrupción generalizada del servicio.

Para consideraciones más amplias sobre la conectividad moderna, revise nuestra guía sobre Gestión del ancho de banda: una guía práctica para 2026 .

Resolución de problemas y mitigación de riesgos

Incluso con una planificación meticulosa, el despliegue de certificados puede presentar problemas. A continuación se detallan los fallos más comunes y las estrategias de mitigación.

Error al aplicar el perfil WiFi

El dispositivo recibe los certificados raíz de confianza y SCEP, pero el perfil WiFi se muestra como un error o como no aplicable en la consola MDM. Esto casi siempre 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 WiFi está asignado a un grupo de dispositivos, el MDM no puede resolver la dependencia. Audite sus asignaciones. Asegúrese de que los perfiles raíz de confianza, SCEP y WiFi se desplieguen exactamente en el mismo grupo.

Errores 403 Forbidden de la pasarela

Los dispositivos no logran recuperar el certificado SCEP y los registros de la pasarela muestran errores HTTP 403. La cuenta de servicio del conector carece de los permisos necesarios en la plantilla de certificado, o el filtrado de URL en su cortafuegos está bloqueando los parámetros de cadena de consulta específicos utilizados por SCEP. Verifique que la cuenta del conector tenga permisos de lectura e inscripción en la plantilla de la CA. Compruebe los registros del cortafuegos para asegurarse de que no se estén bloqueando las URL que contienen ?operation=GetCACaps.

ROI e impacto empresarial

La transición al despliegue de certificados 802.1X basado en SCEP ofrece un retorno medible tanto en seguridad como en operaciones.

  1. Reducción de tickets de soporte: La WiFi basada en contraseñas genera un volumen significativo de tickets de soporte relacionados con la expiración de contraseñas, bloqueos de cuentas y errores de escritura. La autenticación basada en certificados es invisible para el usuario, lo que suele reducir el volumen de soporte relacionado con la WiFi en un 70%.
  2. Mejora de la postura de seguridad: EAP-TLS elimina el riesgo de robo de credenciales y ataques de intermediario (Man-in-the-Middle). Esto es fundamental para el cumplimiento de marcos normativos como PCI DSS y GDPR, especialmente en entornos de Comercio minorista y Sanidad .
  3. Incorporación fluida: La integración del despliegue de certificados con los flujos de trabajo de MDM existentes garantiza una experiencia de aprovisionamiento unificada y sin intervención (zero-touch) desde el primer día.

Mientras que SCEP protege sus dispositivos corporativos gestionados, las redes de invitados y visitantes requieren un enfoque diferente. Para dispositivos no gestionados, un Captive Portal con inicio de sesión social o verificación por SMS alimenta una capa de datos de origen (first-party data), lo que le proporciona información útil. Explore nuestra plataforma de WiFi Analytics para ver cómo estos datos impulsan los ingresos.

Definiciones clave

SCEP (Simple Certificate Enrollment Protocol)

Un protocolo que permite a los dispositivos solicitar certificados digitales a una Autoridad de Certificación, donde la clave privada se genera y se almacena de forma segura en el propio dispositivo.

El método recomendado para desplegar certificados de autenticación WiFi debido a su alta seguridad y escalabilidad en flotas empresariales.

PKCS (Public Key Cryptography Standards)

Un conjunto de estándares donde tanto la clave pública como la privada son generadas por la Autoridad de Certificación y luego se entregan de forma segura al dispositivo final.

A menudo utilizado para el cifrado de correo electrónico S/MIME, pero menos ideal para la autenticación WiFi debido a la transmisión de la clave privada a través de la red.

NDES (Network Device Enrollment Service)

Un rol de Microsoft Windows Server que actúa como puente, permitiendo que los dispositivos sin credenciales de dominio obtengan certificados a través de SCEP.

Un componente de infraestructura requerido al implementar el despliegue de certificados SCEP con PKI de Microsoft local.

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

El método de autenticación 802.1X más seguro, que requiere que tanto el servidor como el cliente presenten certificados digitales válidos.

El protocolo de autenticación de destino que los perfiles de WiFi y certificados de MDM están diseñados para habilitar, eliminando el acceso basado en contraseñas.

CRL (Certificate Revocation List)

Una lista publicada por la Autoridad de Certificación que contiene los números de serie de los certificados que han sido revocados antes de su fecha de vencimiento programada.

Los servidores RADIUS deben verificar la CRL durante la autenticación para garantizar que los empleados dados de baja no puedan acceder a la red utilizando un certificado previamente válido.

CSR (Certificate Signing Request)

Un bloque de texto codificado que se entrega a una Autoridad de Certificación al solicitar un certificado SSL/TLS, que contiene la clave pública y la información de identidad.

Generada localmente por el dispositivo gestionado durante el flujo SCEP para solicitar su credencial de identidad única.

802.1X

Un estándar IEEE para el control de acceso a la red basado en puertos que proporciona un mecanismo de autenticación a los dispositivos que desean conectarse a una LAN o WLAN.

El marco fundamental que impone el requisito de validación de certificados EAP-TLS antes de conceder acceso a la red.

RADIUS (Remote Authentication Dial-In User Service)

Un protocolo de red que proporciona gestión centralizada de autenticación, autorización y contabilidad para los usuarios que se conectan y utilizan un servicio de red.

El servidor que evalúa el certificado del cliente frente a la CA y la CRL para tomar la decisión final de permitir o denegar el acceso a la WiFi.

Ejemplos prácticos

Un grupo hotelero con 150 propiedades necesita proteger la red de su personal en una combinación de portátiles Windows para recepción, dispositivos iOS para el servicio de limpieza y tabletas Android para el punto de venta del restaurante. Actualmente utilizan WPA2-Personal con una contraseña compartida que se rota trimestralmente, lo que genera un volumen masivo de solicitudes de soporte.

El grupo hotelero despliega tres perfiles de Intune en secuencia en un grupo de dispositivos unificado. Primero, un perfil de Certificado de Raíz de Confianza establece la confianza con la CA corporativa. Segundo, un perfil de Certificado SCEP indica a los dispositivos que soliciten un certificado de cliente único. Tercero, un perfil de WiFi configura el SSID corporativo con WPA3-Enterprise y EAP-TLS, apuntando al certificado SCEP para la autenticación. El servidor RADIUS aplica una verificación estricta de CRL para revocar el acceso de forma instantánea tras la baja de un empleado.

Comentario del examinador: Este enfoque elimina la sobrecarga de la rotación trimestral de contraseñas y protege la red contra el uso compartido de credenciales. Se elige SCEP en lugar de PKCS para garantizar que la clave privada nunca salga de los dispositivos individuales, manteniendo una postura de confianza cero (zero-trust) en todo tipo de hardware.

Un minorista de moda con 200 tiendas requiere la conformidad con PCI DSS para sus sistemas de punto de venta basados en Windows gestionados a través de Intune. Deben garantizar una autenticación sólida y una segmentación de red estricta para cualquier dispositivo que maneje datos de titulares de tarjetas.

El minorista implementa EAP-TLS basado en SCEP para la autenticación a nivel de dispositivo en el SSID del personal. La política RADIUS gestiona la asignación de VLAN, colocando automáticamente los terminales de punto de venta autenticados en una VLAN estrictamente aislada dentro del alcance de PCI. El WiFi para invitados se gestiona en un SSID completamente independiente con su propio flujo de autenticación de Captive Portal, garantizando que las dos redes nunca se crucen.

Comentario del examinador: Al vincular la segmentación de red directamente a la autenticación basada en certificados, el minorista cumple con los requisitos de PCI DSS sin necesidad de configuración de red manual por tienda. La separación física de la red de invitados utilizando una plataforma como Purple evita que se amplíe el alcance de la auditoría PCI.

Preguntas de práctica

Q1. Su despliegue de Intune muestra que los perfiles de Raíz de Confianza y SCEP se han aplicado correctamente al portátil de un usuario, pero el perfil de WiFi muestra un estado de 'Error'. El usuario no puede conectarse al SSID corporativo. ¿Cuál es la causa arquitectónica más probable?

Sugerencia: Considere cómo las plataformas MDM resuelven las dependencias entre perfiles de configuración relacionados.

Ver respuesta modelo

Una discrepancia en la asignación de grupos. Es probable que el perfil SCEP esté asignado a un grupo de Usuarios, mientras que el perfil de WiFi esté asignado a un grupo de Dispositivos (o viceversa). Intune no puede resolver la dependencia entre diferentes tipos de grupos, lo que provoca que falle el despliegue del perfil de WiFi. Audite las asignaciones y asegúrese de que los tres perfiles se dirijan exactamente al mismo grupo de Azure AD.

Q2. Una filial recién adquirida requiere autenticación 802.1X para los dispositivos de su personal. Su equipo de seguridad exige que las claves privadas nunca viajen por la red y que se generen dentro del TPM de hardware del dispositivo final. ¿Qué método de despliegue de certificados debe utilizar?

Sugerencia: Compare dónde se genera la clave privada en el flujo de trabajo SCEP frente al flujo de trabajo PKCS.

Ver respuesta modelo

Debe utilizar SCEP (Simple Certificate Enrollment Protocol). En un flujo de trabajo SCEP, el dispositivo genera su propio par de claves privada y pública localmente dentro de su enclave seguro (TPM) y solo envía una Solicitud de Firma de Certificado (CSR) a través de la red. PKCS genera la clave privada de forma centralizada en la CA y la transmite por la red, lo que infringe el mandato del equipo de seguridad.

Q3. Se despide a un empleado y se deshabilita su cuenta de Active Directory. Sin embargo, su portátil permanece conectado a la red WiFi corporativa durante varias horas antes de perder el acceso. ¿Cómo se resuelve esta brecha de seguridad?

Sugerencia: Deshabilitar una cuenta no invalida un certificado existente. ¿Qué mecanismo utiliza el servidor RADIUS para comprobar la validez del certificado?

Ver respuesta modelo

Debe configurar el servidor RADIUS para que aplique una verificación estricta de la Lista de Revocación de Certificados (CRL). Cuando se da de baja a un empleado, su certificado debe ser revocado explícitamente en la Autoridad de Certificación. El servidor RADIUS comprobará la CRL durante el siguiente ciclo de autenticación y denegará el acceso de inmediato, independientemente del estado de la cuenta de Active Directory.

Continúe leyendo esta serie

Cómo configurar un Captive Portal en Starlink: guía para establecimientos remotos y marítimos

Esta guía detalla cómo omitir el hardware nativo de Starlink e integrar un Captive Portal gestionado en la nube utilizando equipos de enrutamiento empresariales. Aprenderá a superar la limitación de CGNAT, aplicar la segmentación de VLAN, gestionar las limitaciones de ancho de banda satelital y garantizar el cumplimiento normativo.

Leer la guía →

Hotel Guest WiFi Management: Integrating PMS, Portals, and Brand Standards

Esta guía técnica detalla cómo diseñar redes WiFi hoteleras de nivel empresarial, centrándose en la segmentación de VLAN, la integración de PMS para la gestión automatizada de sesiones y la optimización del Captive Portal para la captura de datos de conformidad con el GDPR.

Leer la guía →

Cómo optimizar los captive portals para una máxima seguridad de red y conversión de usuarios

Esta guía proporciona un esquema técnico completo para optimizar los captive portals en entornos empresariales, abarcando la arquitectura de segmentación de red, la selección del método de autenticación, el diseño de consentimiento conforme a la GDPR y la optimización de la conversión. Está dirigida a responsables de TI, arquitectos de red y CTO de hoteles, cadenas de tiendas, estadios y organizaciones del sector público que necesitan equilibrar la seguridad de la red con la captura de datos de primera mano. Purple opera la infraestructura de captive portals en más de 80.000 establecimientos con 440 millones de inicios de sesión en 2024, y los marcos de trabajo aquí presentados reflejan esa experiencia operativa.

Leer la guía →