Cómo revocar el acceso a WiFi cuando un empleado se va

Bienvenidos al Purple Technical Briefing. Soy su anfitrión, y hoy abordaremos una de las brechas más comunes en la salida de empleados en las empresas: ¿qué pasa realmente con el acceso a WiFi cuando un empleado se va? Suena sencillo. Alguien entrega su credencial, Recursos Humanos cierra su cuenta y listo. Pero si tu red aún funciona con una contraseña WPA2 compartida, esa persona salió por la puerta sabiendo todavía la contraseña. Y a menos que la cambies para todos, pueden volver a conectarse desde el estacionamiento. Ese es el problema que resolveremos hoy. Cubriremos los tres modelos viables para la revocación de WiFi por usuario, repasaremos una lista de verificación de revocación para el mismo día y explicaremos exactamente qué espera ver un auditor de ISO 27001 o SOC 2 en tus registros. Comencemos. Sección uno: por qué las contraseñas compartidas son la herramienta incorrecta para el trabajo. WPA2-Personal, la configuración estándar de un router doméstico, utiliza una única clave precompartida. Todos en la red conocen la misma contraseña. Cuando una persona se va, esa contraseña sigue siendo válida en su teléfono, su laptop y cualquier dispositivo que haya conectado. La única forma de revocar su acceso es cambiar la contraseña para toda la red y redistribuirla a cada usuario y dispositivo restante. En un hotel con 200 empleados, eso significa actualizar cada terminal de punto de venta, cada computadora de la oficina administrativa y el teléfono de cada gerente. En una cadena de tiendas de retail con 50 sucursales, significa un despliegue coordinado en cada sitio. El costo operativo es alto, la interrupción es real y la ventana entre el último día del empleado y la rotación completada es una brecha de seguridad real. PCI DSS, el estándar de la industria de tarjetas de pago, exige que cambies las credenciales compartidas cada vez que se vaya el personal que las conoce. Por lo tanto, si tus cajas registradoras están en la misma red que el WiFi de tu personal, la salida de un empleado activa una obligación de cumplimiento, no solo una recomendación de mejores prácticas. La causa raíz es simple: una contraseña compartida no tiene una identidad asociada. La red no puede distinguir entre un empleado actual y uno anterior. Para solucionar eso, necesitas credenciales por usuario. Sección dos: los tres modelos que realmente funcionan. El modelo uno es 802.1X con autenticación basada en certificados EAP-TLS. Este es el estándar de oro para la seguridad de WiFi empresarial. En este modelo, cada usuario o dispositivo posee un certificado digital único emitido por tu Autoridad de Certificación, o CA. Cuando se conectan al WiFi, el servidor RADIUS valida ese certificado criptográficamente. El certificado está vinculado a una identidad, no a una contraseña. Para revocar el acceso, revocas el certificado a nivel de la CA. El servidor RADIUS verifica el estado de revocación en tiempo real utilizando OCSP, el Protocolo de Estado de Certificados en Línea. Cuando marcas un certificado como revocado, la próxima vez que ese dispositivo intente autenticarse, el servidor RADIUS consulta al respondedor OCSP, recibe una respuesta de revocado y envía un Access-Reject al punto de acceso. El dispositivo queda fuera de la red a los pocos segundos del siguiente intento de autenticación. Para las sesiones activas, utilizas el Cambio de Autorización de RADIUS, o CoA, para terminar la sesión existente de inmediato. Combinados, OCSP y CoA significan que puedes revocar el acceso a WiFi de un empleado que se va en menos de un minuto, con una pista de auditoría completa en tus registros de RADIUS. El desafío con EAP-TLS es la sobrecarga de la infraestructura de clave pública (PKI). Necesitas una Autoridad de Certificación, un mecanismo para emitir certificados a los dispositivos, típicamente a través de un MDM como Microsoft Intune, y un proceso para revocarlos. Para organizaciones con un MDM e infraestructura de identidad maduros, esta es la respuesta correcta. Para equipos más pequeños o entornos con dispositivos IoT que no pueden soportar la autenticación por certificado, necesitas un enfoque diferente. El modelo dos es iPSK, Clave Precompartida de Identidad. Cisco lo llama iPSK, Ruckus lo llama DPSK, Aruba lo llama MPSK, pero el concepto es el mismo: cada usuario o dispositivo obtiene una contraseña única, aunque todos se conecten al mismo SSID. El servidor RADIUS asocia cada clave única a una identidad específica y, opcionalmente, a una VLAN específica. Cuando eliminas esa clave de la base de datos de RADIUS, el dispositivo ya no puede autenticarse. El radio de impacto de la salida de un empleado se limita exactamente a una persona. Las claves de todos los demás siguen siendo válidas. iPSK se adapta especialmente bien a entornos con tipos de dispositivos mixtos. Los dispositivos IoT, las terminales de punto de venta y el hardware heredado que no puede soportar certificados 802.1X pueden usar iPSK. También es más sencillo de operar que un despliegue completo de PKI, lo que lo convierte en la opción adecuada para organizaciones del mercado medio que necesitan revocación por usuario sin la sobrecarga de infraestructura. El tiempo de revocación para iPSK suele ser de unos minutos, no de segundos. La eliminación de la clave se propaga al servidor RADIUS, pero las sesiones activas pueden persistir hasta que el dispositivo se vuelva a autenticar o hasta que envíes un paquete CoA para forzar la desconexión. El modelo tres es el desaprovisionamiento impulsado por SCIM. SCIM significa Sistema para la Gestión de Identidades entre Dominios. Es un estándar abierto, definido en RFC 7643 and RFC 7644, que permite a tu proveedor de identidad enviar eventos del ciclo de vida del usuario a los sistemas secundarios en tiempo real. Así es como funciona en la práctica. Tu proveedor de identidad, ya sea Microsoft Entra ID, Okta o Google Workspace, es la fuente autoritativa de verdad para las cuentas de usuario. Cuando Recursos Humanos deshabilita la cuenta de un empleado que se va en el proveedor de identidad, SCIM envía una solicitud a cada sistema conectado, incluyendo tu plataforma de gestión de WiFi. Purple se conecta a tu proveedor de identidad a través de SCIM. En el momento en que deshabilitas a un usuario en Entra ID, Okta o Google Workspace, Purple recibe el evento SCIM y revoca sus credenciales de WiFi en la siguiente autenticación. El evento se registra con una marca de tiempo, la identidad del usuario y la acción realizada. Esa entrada de registro es exactamente lo que un auditor de ISO 27001 necesita ver. SCIM no reemplaza a 802.1X ni a iPSK. Se sitúa por encima de ellos. SCIM maneja el ciclo de vida de la identidad; el protocolo de autenticación se encarga de la aplicación en la red. La combinación de SCIM más 802.1X te brinda una revocación automática en tiempo real con una pista de auditoría completa y cero pasos manuales. Sección tres: la lista de verificación de revocación para el mismo día. Cuando llega el último día de un empleado que se va, esta es la secuencia que tu equipo de TI debe seguir. Paso uno: deshabilita la cuenta en tu proveedor de identidad. Este es el detonante para todo lo demás. En Microsoft Entra ID, establece la cuenta como deshabilitada. En Okta, desactiva al usuario. En Google Workspace, suspende la cuenta. Paso dos: si estás ejecutando SCIM, verifica que se haya activado el evento de desaprovisionamiento. Revisa tus registros de SCIM o tu plataforma de gestión de WiFi para encontrar el evento correspondiente. Si SCIM no está implementado, revoca manualmente el certificado en tu CA o elimina la clave iPSK de tu base de datos de RADIUS. Paso tres: envía un CoA de RADIUS para terminar cualquier sesión de WiFi activa. La mayoría de los servidores RADIUS empresariales, y plataformas como Purple, pueden hacer esto automáticamente ante un evento de desaprovisionamiento. Si lo estás haciendo manualmente, utiliza la interfaz CoA de tu servidor RADIUS para desconectar el dispositivo del usuario por dirección MAC o ID de sesión. Paso cuatro: confirma que no queden sesiones activas. Revisa el tablero de tu controlador de WiFi. En Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme o Fortinet, deberías poder buscar por nombre de usuario o dispositivo y confirmar que hay cero asociaciones activas. Paso cinco: archiva la entrada del registro de auditoría. Exporta o marca el registro de autenticación de RADIUS, el registro de eventos de SCIM y el registro de CoA para el usuario y la fecha correspondientes. Almacénalos en tu plataforma de ITSM o de gestión de eventos e información de seguridad (SIEM). El control A.9.2.6 del Anexo A de ISO 27001 requiere que elimines o ajustes los derechos de acceso de todos los empleados y contratistas al finalizar la relación laboral. Tu registro es la evidencia. Paso seis: si estás ejecutando WPA2 PSK compartido y nada de lo anterior aplica, rota la contraseña. Coordina el despliegue en todos los sitios y dispositivos antes del último día del empleado si es posible, o inmediatamente después. Sección cuatro: lo que espera el auditor. Tanto ISO 27001 como SOC 2 requieren que demuestres que el acceso se elimina de inmediato cuando finaliza la relación laboral. Específicamente para WiFi, los auditores buscan cuatro cosas. Primero, un procedimiento de salida documentado que incluya explícitamente el acceso a la red. Segundo, evidencia de que se siguió el procedimiento para una muestra de empleados que se fueron, típicamente de diez a veinticinco personas seleccionadas de los últimos doce meses. Tercero, un registro que muestre la marca de tiempo de la inhabilitación de la cuenta y la marca de tiempo de la revocación del acceso a WiFi, con la brecha entre ambas claramente visible. Cuarto, la confirmación de que ninguna cuenta de ex-empleado muestre sesiones de WiFi activas. Si estás ejecutando WPA2 PSK compartido, no puedes presentar evidencia para los puntos tres y cuatro. No existe un registro por usuario. Lo mejor que puedes hacer es mostrar la fecha de rotación de la contraseña y argumentar que se completó antes o durante el último día del empleado. Los auditores rechazan cada vez más este argumento. Si estás ejecutando 802.1X con SCIM, el registro es automático. Purple registra cada evento de desaprovisionamiento de SCIM con una marca de tiempo UTC, la fuente del proveedor de identidad, el identificador único del usuario y la acción resultante. Ese es un registro limpio y auditable. Sección cinco: errores comunes de implementación y cómo evitarlos. El error más común es asumir que deshabilitar una cuenta en el proveedor de identidad es suficiente. No lo es, a menos que tu plataforma de WiFi esté conectada a ese proveedor de identidad a través de SCIM o una integración similar en tiempo real. Sin esa conexión, el sistema WiFi no tiene forma de saber que la cuenta fue deshabilitada. El segundo error es el almacenamiento en caché de certificados. Incluso con OCSP, los servidores RADIUS almacenan en caché las respuestas buenas durante un período configurable, típicamente de 15 a 60 minutos. Si revocas un certificado y el servidor RADIUS tiene una respuesta buena almacenada en caché, el dispositivo puede continuar autenticándose hasta que la caché expire. Establece el TTL de la caché de OCSP en 15 minutos o menos para entornos de alta seguridad. El tercer error es olvidar las sesiones activas. Revocar las credenciales evita nuevas autenticaciones, pero no termina una sesión de WiFi existente. Siempre envía un CoA de RADIUS después de revocar las credenciales para desconectar el dispositivo de inmediato. El cuarto error son los dispositivos IoT y compartidos. Un dispositivo registrado bajo la identidad de un empleado que se va puede ser una estación de trabajo compartida o una pieza de hardware operativo. Antes de revocar, confirma si el dispositivo es personal o compartido. Si es compartido, vuelve a registrarlo bajo una cuenta de servicio antes de revocar las credenciales del empleado que se va. Sección seis: preguntas rápidas. Pregunta: ¿qué tan rápido se puede revocar el acceso a WiFi basado en certificados? Con OCSP y CoA de RADIUS, en menos de 60 segundos desde el momento en que revocas el certificado en la CA. La verificación de OCSP ocurre en el siguiente intento de autenticación. El CoA termina la sesión activa de inmediato. Pregunta: ¿funciona SCIM con todo el hardware de WiFi? SCIM opera en la capa de gestión de identidades, no en la capa de hardware. Purple es agnóstico al hardware y funciona con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. La integración de SCIM es con Purple, no directamente con los puntos de acceso. Pregunta: ¿qué pasa si no tenemos MDM y no podemos implementar certificados? iPSK es tu respuesta. Te brinda revocación por usuario sin requerir infraestructura de certificados. Purple puede gestionar claves iPSK y conectarse a tu proveedor de identidad para automatizar el ciclo de vida. Resumen y próximos pasos. El mensaje central es este: si no puedes revocar el acceso a WiFi para una persona sin afectar a todos los demás, tienes un problema de credenciales compartidas. La solución son las credenciales por usuario, ya sean certificados a través de 802.1X EAP-TLS o claves únicas a través de iPSK, combinados con el desaprovisionamiento impulsado por SCIM para automatizar la revocación en el momento en que Recursos Humanos actúe. Purple se conecta a Microsoft Entra ID, Okta y Google Workspace a través de SCIM, opera en más de 80,000 establecimientos activos y registra cada evento de desaprovisionamiento para auditorías. Si te estás preparando para ISO 27001 o SOC 2, o simplemente deseas cerrar la brecha de salida de empleados antes de que se convierta en un incidente, ahí es donde debes comenzar. Para obtener el desglose técnico completo de la revocación de certificados y OCSP, consulta nuestra guía sobre OCSP y revocación de certificados para la autenticación de WiFi. Para obtener una visión más amplia de la automatización de ingresos, movimientos y salidas de personal, consulta nuestra guía de seguridad de WiFi empresarial. Gracias por escuchar el Purple Technical Briefing.