La baja de un usuario no termina cuando Recursos Humanos registra la salida. Una misma persona puede conservar correo, VPN, aplicaciones SaaS, repositorios, accesos a clientes, tokens, credenciales locales y cuentas administradas por proveedores distintos. Si la empresa revoca solo el directorio principal, deja abiertas rutas que ya no tienen una necesidad laboral.
El objetivo tampoco es desconfiar de quien se retira. Es ejecutar una decisión de negocio de forma completa, oportuna y demostrable. El proceso debe conectar la salida o cambio de función con cada identidad, privilegio, equipo y secreto que la persona utilizaba. Así se protege a la empresa y se evita que una cuenta huérfana termine en manos de terceros.
La baja de usuarios comienza antes del último día
Recursos Humanos conoce la fecha y condición de la salida; la jefatura sabe qué funciones deben transferirse; TI administra parte de las cuentas; y los dueños de aplicaciones autorizan accesos específicos. Si la notificación aparece solo como un ticket genérico al final de la jornada, cada área interpreta el alcance y los tiempos por separado.
Conviene definir un evento formal que active el flujo, con fecha efectiva, responsable y tratamiento según riesgo. Una salida planificada permite inventariar accesos y transferir información. Una desvinculación inmediata puede exigir revocar sesiones y credenciales en un momento acordado, antes de recuperar el equipo. La urgencia no elimina la coordinación: hace más importante que el orden esté decidido de antemano.
Qué accesos deben entrar en el alcance
La cuenta corporativa es solo el punto de partida. El inventario debe considerar identidades en aplicaciones de negocio, nubes, VPN, repositorios, plataformas de proveedores, herramientas de colaboración, accesos físicos y cuentas locales. También debe incluir llaves de API, certificados, tokens y secretos compartidos que podrían seguir funcionando aunque la cuenta personal quede deshabilitada.
Por eso, la baja depende de un inventario de activos tecnológicos y de dueños de aplicación identificados. Si nadie puede relacionar a una persona con los sistemas que usa, el equipo de TI buscará a ciegas. Centralizar identidades mediante un directorio o inicio de sesión único reduce dispersión, pero no reemplaza el control de aplicaciones que quedan fuera de esa integración.
Deshabilitar primero, eliminar después
CIS Control 6.2 propone revocar el acceso mediante la deshabilitación inmediata de cuentas ante una terminación, pérdida de derechos o cambio de rol. Deshabilitar conserva trazabilidad y permite revisar acciones anteriores; eliminar de inmediato puede destruir relaciones necesarias para una auditoría o para recuperar información de negocio. La retención posterior debe responder a reglas definidas, no transformarse en una excusa para mantener la cuenta activa.
La revocación debe abarcar sesiones vigentes, factores de autenticación, contraseñas de aplicación, certificados y tokens. Cuando existan secretos compartidos, la salida exige rotarlos y comprobar qué integraciones dependen de ellos. Para cuentas con mayor impacto, la empresa puede incorporar una revisión específica de accesos privilegiados, credenciales de emergencia y cuentas técnicas conocidas por la persona.
Los cambios de rol crean el mismo riesgo
Mover a alguien de área suele parecer menos riesgoso que una salida, pero puede acumular permisos incompatibles. La persona recibe nuevos accesos y conserva los anteriores porque nadie define qué debe retirarse. NIST SP 800-53, en AC-2 Account Management, pide alinear la administración de cuentas con procesos de terminación y transferencia. El control se completa cuando el nuevo rol tiene solo lo necesario y los permisos anteriores dejan de estar activos.
Las revisiones periódicas ayudan a encontrar acumulaciones, aunque no sustituyen una baja a tiempo. NIST CSF 2.0 ubica la gestión de identidades y credenciales en PR.AA-01. CISA también recomienda conectar los sistemas de gobierno de identidades con los procesos de personal para automatizar la deshabilitación y mantener un registro de cuentas y privilegios asociados a cada individuo.
Qué evidencia demuestra que la revocación funcionó
Un ticket cerrado no prueba que todos los accesos hayan desaparecido. La evidencia puede incluir la identidad de la persona, fecha efectiva, sistemas revisados, hora de deshabilitación, sesiones revocadas, activos recuperados, secretos rotados, excepciones y validación del dueño. Una muestra de bajas recientes permite comparar la lista esperada con el estado real de las cuentas.
La medición debe centrarse en brechas útiles: cuentas aún activas después de la salida, aplicaciones sin responsable, revocaciones fuera de plazo y excepciones sin vencimiento. Una Auditoría de Seguridad de AllDefense puede revisar el flujo completo, desde el evento de personal hasta la evidencia técnica, para identificar dónde se pierde el alcance sin inventar una cobertura que la organización no posee.
Una baja confiable no depende de recordar todas las cuentas el último día. Depende de un proceso compartido entre personas, jefaturas, TI y dueños de sistemas, con inventario, tiempos y comprobación. Ese diseño también mejora altas y cambios de rol: cada acceso nace con un responsable y puede retirarse cuando deja de existir su justificación.
Fuentes consultadas
- NIST SP 800-53 Rev. 5: AC-2 Account Management.
- NIST Cybersecurity Framework 2.0: PR.AA.
- CIS Control 6.2: Establish an Access Revoking Process.
- CISA: Identity and Access Management Recommended Best Practices.
