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

Bienvenido a esta sesión técnica sobre cómo revocar el acceso a WiFi cuando un empleado deja la empresa. El problema suele parecer más pequeño de lo que realmente es. Alguien se marcha un viernes. Su responsable desactiva el correo electrónico y retira el portátil. Sin embargo, su teléfono o dispositivo personal aún puede conectarse al WiFi del personal el lunes. En un hotel, eso puede situar a un antiguo trabajador cerca de los sistemas operativos. En un entorno de retail, puede dar acceso a la red de empleados en muchas tiendas. En un estadio o centro de conferencias, puede hacer que un día de evento con gran afluencia sea más difícil de gestionar. La pregunta inmediata no es si la persona que se marcha conoce una contraseña. Es si su WiFi puede identificar a esa persona como una identidad distinta y denegar el acceso a esa identidad sin interrumpir a todos los demás. Una única frase de contraseña compartida WPA2 no puede lograr eso. Cada persona tiene la misma credencial. Una vez que esa frase de contraseña se ha compartido con alguien que se marcha, la red no tiene una forma limpia de distinguir a esa persona del resto de empleados autorizados que también la conocen. La respuesta práctica es una rotación de la frase de contraseña en toda la empresa, seguida de una actualización en cada dispositivo aprobado. Eso es operativamente costoso, genera tickets de soporte y a menudo se retrasa. No es un control de baja creíble para el mismo día en un entorno de recintos distribuidos. Existen tres patrones creíbles. El primero es el acceso por persona 802.1X con EAP-TLS. El segundo es iPSK, a veces llamado clave precompartida individual. El tercero es el desaprovisionamiento impulsado por el proveedor de identidad mediante SCIM. Se pueden combinar estos patrones. La elección de diseño central sigue siendo la misma: hacer que la credencial de acceso sea atribuible a una persona o a un dispositivo gestionado, y luego hacer que la eliminación sea un evento controlado y registrado. Comencemos con 802.1X y EAP-TLS. El estándar IEEE 802.1X es el marco de control de acceso a la red. Separa el dispositivo que solicita unirse, el autenticador en el extremo de la red y el servicio de autenticación back-end. EAP-TLS es un método del Protocolo de Autenticación Extensible que utiliza certificados para la autenticación mutua y la derivación de claves. En términos sencillos, el dispositivo demuestra que posee un certificado y la red demuestra su propia identidad en el mismo intercambio de autenticación. Este modelo se adapta a los dispositivos gestionados del personal y a las redes de alta seguridad. La acción ante la salida de un empleado no es cambiar una contraseña compartida. Consiste en desactivar la identidad y revocar, denegar o eliminar de otro modo el derecho del certificado a autenticarse. Su diseño de RADIUS y de validación de certificados debe ser capaz de reconocer ese cambio cuando un dispositivo se autentica. No confunda la caducidad del certificado con la revocación del certificado. La caducidad está programada. La revocación es la acción de baja que se realiza antes de la fecha de finalización programada. El factor tiempo es crucial. El acceso a WiFi basado en certificados se verifica en el momento de la autenticación. Por tanto, su objetivo práctico está claro: evitar que el certificado tenga éxito en el siguiente intento de autenticación y probar ese resultado. Si el empleado ya tiene una sesión activa, decida por separado si su política requiere la desconexión de la sesión. Se trata de una decisión de operaciones de red, no de un sustituto de la revocación de la identidad. Tenga también en cuenta el comportamiento de reconexión rápida y las sesiones almacenadas en caché durante su proceso de diseño y prueba. Un diseño que parece correcto en un laboratorio puede crear un punto ciego si su ruta de autenticación de producción no valida el cambio de la forma prevista. La lista de comprobación operativa para EAP-TLS es sencilla. En primer lugar, confirme el registro de identidad de la persona y la última hora de trabajo. En segundo lugar, deshabilite la identidad de origen. En tercer lugar, revoque o deniegue el certificado correspondiente de acuerdo con su autoridad de certificación y el proceso de RADIUS. En cuarto lugar, elimine o finalice una sesión activa si su política lo requiere. En quinto lugar, intente realizar una nueva conexión con el dispositivo gestionado del antiguo empleado o un equivalente controlado. Por último, conserve la solicitud, el cambio, el resultado, la hora y el propietario responsable. El segundo patrón es iPSK. En lugar de una frase de paso compartida por toda la plantilla, cada persona o dispositivo tiene una clave distinta en la misma red WiFi del personal. Esto hace que la eliminación sea selectiva. Elimine la clave asociada a la persona que se marcha, confirme que falla el nuevo intento de conexión y deje intactas todas las demás claves. iPSK puede funcionar bien cuando dispone de dispositivos que no pueden utilizar certificados, cuando el programa de dispositivos gestionados está aún en desarrollo o cuando necesita una transición práctica para abandonar una frase de paso compartida. iPSK no es lo mismo que una contraseña genérica de personal con otro nombre. La clave debe estar vinculada a un registro de identidad o de dispositivo. Mantenga un inventario del propietario de la clave, la fecha de emisión, la asociación con el dispositivo o la persona, el rol de red y el estado de eliminación. Haga que la clave sea lo suficientemente distinta como para que un evento de eliminación pueda rastrearse hasta la persona que se marcha. Si el mismo iPSK es reutilizado por un equipo, grupo de contratistas o turno, habrá recreado el problema del secreto compartido en un contenedor más pequeño. El tercer patrón es el desaprovisionamiento controlado por SCIM. SCIM es un protocolo estándar basado en HTTP para aprovisionar y gestionar datos de identidad en todos los sistemas. En un buen proceso de incorporación, cambio y salida de empleados, el departamento de Recursos Humanos o TI deshabilita la cuenta en su proveedor de identidad, el estado deshabilitado se transmite al servicio de acceso WiFi y se deniega una autenticación WiFi posterior. Purple vincula el acceso WiFi al proveedor de identidad a través de SCIM. Los proveedores de identidad compatibles son Microsoft Entra ID, Okta y Google Workspace. El beneficio operativo no es magia. Es una única fuente de verdad: el evento que pone fin al empleo también inicia la eliminación de la conexión. Trate SCIM como una ruta de control, no como un eslogan. Necesita un identificador único que asocie la cuenta del proveedor de identidad con el registro de acceso WiFi. Necesita un evento de desactivación acordado. Necesita saber qué error genera el servicio receptor cuando falla una solicitud de desactivación. Y necesita una identidad de prueba que demuestre que su monitorización detecta ese fallo. Ahora pase del diseño a la implementación. Comience con un inventario de accesos. Elabore una lista de cada red WiFi para empleados, su modo de seguridad, la fuente de identidad, la ruta RADIUS si está presente, la autoridad de certificación si está presente, el registro del propietario de iPSK si existe, la capacidad de desconexión de sesión y el destino de los registros de depuración (logs). Haga esto por grupo de puntos de venta o sedes, no como una lista de empresa unificada. Un hotel, una tienda de calle y un estadio pueden compartir políticas y, al mismo tiempo, utilizar diferentes equipos operativos y hardware. A continuación, elija el control que elimine la mayor cantidad de trabajo manual del proceso de salida de empleados. Para dispositivos corporativos gestionados, utilice 802.1X con EAP-TLS siempre que su autoridad de certificación, diseño de RADIUS y gestión de dispositivos puedan soportarlo. Para entornos mixtos y dispositivos que no puedan utilizar certificados, utilice iPSK únicamente cuando cada clave sea de propiedad exclusiva y eliminable. Para un entorno que ya utilice Microsoft Entra ID, Okta o Google Workspace, utilice el desaprovisionamiento basado en SCIM para que la desactivación de la cuenta sea el detonante de la eliminación del acceso WiFi. Purple puede conectar ese evento de identidad con el estado de acceso WiFi. No añada un segundo ticket manual a menos que se trate de una ruta de excepción. Cree un manual de ejecución para bajas en el mismo día. El departamento de RR. HH. confirma la hora de finalización. El propietario de la identidad desactiva la cuenta. El propietario de la red confirma que el certificado, iPSK o registro de acceso WiFi correspondiente ya no es válido. Operaciones decide si es necesario desconectar una sesión activa. Un evaluador designado realiza un nuevo intento de autenticación. El caso se cierra únicamente cuando se registra el resultado. Esto es deliberadamente poco glamuroso. También es la parte que un auditor puede reconstruir. Para presentar pruebas de ISO 27001 o SOC 2, conserve una cadena pequeña pero completa: la solicitud de baja autorizada, el cambio en el proveedor de identidad, el cambio en la red WiFi, el resultado de la verificación, las marcas de tiempo y el responsable de cada paso. Evite recopilar más datos personales de los que requiere el control. Los registros de acceso pueden considerarse datos personales, por lo que debe incluirlos en sus decisiones de retención y control de acceso. Si la WiFi para empleados puede afectar a los sistemas de pago, analice el alcance y la segmentación con el equipo responsable de PCI-DSS en lugar de tratar la revocación de WiFi como un argumento de cumplimiento independiente. Esté atento a cuatro modos de fallo. Primero, que se siga utilizando una contraseña compartida en un SSID que se ha pasado por alto. Segundo, que el registro de WiFi se asocie a una dirección de correo electrónico mutable en lugar de a una identidad duradera. Tercero, que un evento de desactivación llegue al proveedor de identidad pero no al servicio de acceso WiFi. Cuarto, que solo se pruebe el estado del panel de control y no un intento real de nueva incorporación. Cada modo de fallo es evitable si realiza un inventario, monitoriza y prueba el control. Preguntas rápidas. ¿Se puede revocar una contraseña WPA2 compartida para una sola persona que se va? No. Tienes que cambiarla para todo el mundo o sustituirla por un control por identidad. ¿Qué tan rápido se puede revocar el acceso EAP-TLS? En la siguiente autenticación, siempre que el diseño de validación de certificados y RADIUS reconozca la revocación. ¿Elimina SCIM una sesión activa? No por sí solo. Trata el control de sesiones como una decisión operativa independiente. ¿Es iPSK adecuado para todos los dispositivos? No. Es un modelo práctico de clave vinculada a la identidad para casos en los que la autenticación por certificado no es la adecuada. El siguiente paso es una breve revisión del diseño. Elige una red WiFi para empleados. Sigue un evento de baja laboral desde la notificación de RR. HH. hasta la denegación de la autenticación. Encuentra el paso manual. Después, elimínalo. Una credencial WiFi debería desaparecer al mismo tiempo que el empleado, no en el siguiente proyecto de rotación de contraseñas.