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

Le damos la bienvenida a esta sesión técnica informativa sobre cómo revocar el acceso a WiFi cuando un empleado deja la empresa. El problema suele parecer menor de lo que realmente es. Alguien se va el viernes. Su gerente desactiva su correo electrónico y retira su laptop. Sin embargo, su teléfono o dispositivo personal aún puede conectarse al WiFi para el personal el lunes. En un hotel, esto puede ubicar a un exempleado cerca de los sistemas operativos. En una tienda minorista, puede dar acceso a una red de personal en múltiples tiendas. En un estadio o centro de conferencias, puede hacer que un día de evento concurrido sea más difícil de gestionar. La pregunta inmediata no es si la persona que se va conoce una contraseña. Es si su WiFi puede identificar a esa persona como una identidad distinta y denegar esa identidad sin interrumpir a todos los demás. Una sola frase de contraseña WPA2 compartida no puede hacer eso. Cada persona tiene la misma credencial. Una vez que esa frase de contraseña se ha compartido con alguien que se va, la red no tiene una forma limpia de distinguir a ese exempleado de cada empleado autorizado que también la conoce. La respuesta práctica es una rotación de frases 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 complejo de recintos distribuidos. Existen tres patrones creíbles. El primero es 802.1X por persona 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. Puede 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 administrado, y luego hacer que la eliminación sea un evento controlado y registrado. Comencemos con 802.1X y EAP-TLS. IEEE 802.1X es el marco de control de acceso a la red. Separa el dispositivo que solicita unirse, el autenticador en el borde de la red y el servicio de autenticación de back-end. EAP-TLS es un método de Protocolo de Autenticación Extensible que utiliza certificados para la autenticación mutua y la derivación de claves. En lenguaje sencillo, el dispositivo demuestra la posesión de un certificado y la red demuestra su propia identidad en el mismo intercambio de autenticación. Este modelo se adapta a los dispositivos administrados 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 deshabilitar la identidad y revocar, denegar o eliminar de otro modo el derecho del certificado a autenticarse. Su diseño de validación de certificados y RADIUS debe ser capaz de reconocer ese cambio cuando un dispositivo se autentica. No confunda la expiración del certificado con la revocación del certificado. La expiración está programada. La revocación es la acción de baja que se toma antes de la fecha de finalización programada. El momento oportuno es clave. El acceso a WiFi basado en certificados se verifica en el momento de la autenticación. Por lo tanto, su objetivo práctico es 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 una desconexión de la sesión. Esa es una elección de operaciones de red, no un sustituto de la revocación de la identidad. Considere también 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 como se esperaba. La lista de verificación operativa para EAP-TLS es sencilla. Primero, confirme el registro de identidad de la persona y su último horario laboral. Segundo, deshabilite la identidad de origen. Tercero, revoque o deniegue el certificado correspondiente de acuerdo con su autoridad de certificación y proceso RADIUS. Cuarto, elimine o termine una sesión activa si su política lo requiere. Quinto, intente una nueva conexión con el dispositivo administrado del excolaborador o un equivalente controlado. Finalmente, conserve la solicitud, el cambio, el resultado, la hora y el responsable. El segundo patrón es iPSK. En lugar de una frase de contraseña compartida por todo el personal, cada persona o dispositivo tiene una clave única en la misma red WiFi para el personal. Eso hace que la eliminación sea selectiva. Elimine la clave asociada con la persona que se retira, confirme que falle un nuevo intento de conexión y deje intactas todas las demás claves. iPSK puede funcionar bien cuando tiene dispositivos que no pueden usar certificados, cuando un programa de dispositivos administrados aún está en desarrollo o cuando necesita una transición práctica para dejar de usar una frase de contraseña compartida. iPSK no es lo mismo que una contraseña de personal genérica con un nombre diferente. La clave debe estar vinculada a un registro de identidad o dispositivo. Mantenga un inventario del propietario de la clave, la fecha de emisión, la asociación del dispositivo o la persona, el rol de red y el estado de eliminación. Haga que la clave sea lo suficientemente distintiva como para que un evento de eliminación pueda rastrearse hasta la persona que se retira. 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 impulsado 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 altas, bajas y cambios, recursos humanos o TI deshabilitan la cuenta en su proveedor de identidad, el estado deshabilitado fluye al servicio de acceso WiFi y se deniega una autenticación de WiFi posterior. Purple vincula el acceso WiFi al proveedor de identidad a través de SCIM. Los proveedores de identidad relevantes son Microsoft Entra ID, Okta y Google Workspace. El beneficio operativo no es magia. Es una única fuente de verdad: el evento que finaliza la relación laboral también inicia la eliminación de WiFi. Trate SCIM como una vía 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 monitoreo detecta esa falla. Ahora pase del diseño a la implementación. Comience con un inventario de acceso. Enumere cada red WiFi del personal, su modo de seguridad, la fuente de identidad, la ruta RADIUS si existe, la autoridad de certificación si existe, el registro del propietario de iPSK si existe, la capacidad de desconexión de sesión y el destino del registro. Haga esto por grupo de puntos de venta, no como una lista de empresa unificada. Un hotel, una tienda física y un estadio pueden compartir políticas utilizando diferentes equipos operativos y hardware. Luego, elija el control que elimine la mayor cantidad de trabajo manual del proceso de baja. Para dispositivos corporativos administrados, use 802.1X con EAP-TLS cuando su autoridad de certificación, diseño de RADIUS y administración de dispositivos puedan admitirlo. Para entornos mixtos y dispositivos que no pueden usar certificados, use iPSK solo cuando cada clave sea de propiedad única y se pueda eliminar. Para un entorno que ya utiliza Microsoft Entra ID, Okta o Google Workspace, use el desaprovisionamiento basado en SCIM para que la desactivación de la cuenta sea el detonante para la eliminación de la red WiFi. Purple puede conectar ese evento de identidad con el estado de acceso WiFi. No agregue un segundo ticket manual a menos que sea una vía de excepción. Cree un manual de ejecución para bajas el mismo día. Recursos Humanos 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 una sesión activa necesita desconectarse. Un evaluador designado realiza un nuevo intento de autenticación. El caso se cierra solo cuando se registra el resultado. Esto es deliberadamente poco glamoroso. También es la parte que un auditor puede reconstruir. Para evidencia 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 ser datos personales, así que inclúyalos en sus decisiones de retención y control de acceso. Si la red WiFi del personal puede afectar 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 requisito de cumplimiento independiente. Esté atento a cuatro modos de falla. Primero, una contraseña compartida sigue en uso en un SSID que se pasó por alto. Segundo, el registro de WiFi está asociado a una dirección de correo electrónico mutable en lugar de a una identidad duradera. Tercero, un evento de desactivación llega al proveedor de identidad pero no al servicio de acceso WiFi. Cuarto, solo prueba el estado del panel de control y no un intento de acceso real de un nuevo miembro. Cada modo de falla se puede prevenir si inventaría, monitorea y prueba el control. Preguntas rápidas. ¿Se puede revocar una contraseña WPA2 compartida para una sola persona que se va de la empresa? No. Hay que rotarla para todos o reemplazarla con un control por identidad. ¿Qué tan rápido se puede revocar el acceso EAP-TLS? En la siguiente autenticación, siempre que su diseño de validación de certificados y RADIUS reconozca la revocación. ¿SCIM elimina una sesión activa? No por sí solo. Gestione 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 donde la autenticación por certificado no es adecuada. El siguiente paso es una breve revisión de diseño. Elija una red WiFi para el personal. Siga el evento de salida de un empleado desde la notificación de recursos humanos hasta la denegación de la autenticación. Identifique el paso manual. Luego, elimínelo. Las credenciales de WiFi deben cancelarse al mismo tiempo que el empleado se va, no en el siguiente proyecto de rotación de contraseñas.