Altas, cambios y bajas: mantenga la responsabilidad sobre los accesos

Los cambios de acceso son un problema de coordinación además de un problema técnico. Una plataforma de identidad no puede eliminar la cuenta de un contratista si nadie avisa al responsable de que el contrato ha terminado. Del mismo modo, una notificación puntual de RR. HH. no demuestra que todas las aplicaciones hayan dejado de aceptar las credenciales de esa persona.

Las altas, los cambios de puesto y las bajas necesitan un proceso que vincule un evento de negocio con un estado de acceso aprobado, ejecute los cambios necesarios y verifique el resultado. Desde la perspectiva de la dirección técnica, la pregunta importante no es si existe una lista de comprobación de bajas. Es si el proceso cubre los sistemas que las personas utilizan realmente, gestiona los fallos y deja evidencias de qué cambió y cuándo.

Defina el ciclo de vida y sus traspasos

Trate cada evento del ciclo de vida como un cambio en los accesos autorizados de una persona, no simplemente como un ticket para crear o deshabilitar una cuenta. El registro del evento debe identificar a la persona, su situación laboral o de contratación, su responsable o patrocinador, la fecha y hora de efecto y el rol afectado. Utilice un identificador estable en lugar de basarse solo en nombres o direcciones de correo electrónico.

RR. HH. suele iniciar los eventos de los empleados. Los de los contratistas puede iniciarlos un responsable de compras, un jefe de proyecto o un patrocinador interno. Elija una fuente autorizada para cada colectivo y defina cómo llegan a TI las correcciones, las incorporaciones canceladas, las prórrogas de contratos y las salidas urgentes.

Separe cuatro responsabilidades, aunque un equipo pequeño asigne varias a la misma persona:

Designe suplentes y una vía de escalado. Una salida programada no debe depender de que un único administrador esté disponible. En los cambios sensibles, un revisor independiente aporta un control útil; cuando la plantilla no lo permita, documente la solución adoptada y utilice una revisión posterior.

Defina criterios de finalización para cada evento. Un alta está lista cuando se han verificado los accesos aprobados y los controles de dispositivo exigidos. Un cambio de puesto está completo cuando se han comprobado tanto las altas como las retiradas de permisos. Una baja está completa cuando se han revocado las vías de acceso y las cuestiones pendientes sobre activos, datos o credenciales tienen responsables explícitos.

Son recomendaciones prácticas de diseño de controles, no plazos legales universales. Dentro de un SGSI ISO 27001, los controles de acceso deben reflejar el alcance y el tratamiento de riesgos de la organización. Consulte El anexo A de ISO 27001 en la práctica para el contexto de controles más amplio.

Establezca la cobertura antes de automatizar los cambios

Empiece por el inventario de aplicaciones. Para cada sistema, registre su responsable, la fuente de identidad, el método de aprovisionamiento, el método de autenticación, las acciones de revocación admitidas y el método de verificación. Incluya tanto las aplicaciones gestionadas de forma centralizada como las que tienen cuentas locales.

El inicio de sesión único no significa necesariamente una gestión completa del ciclo de vida. Una aplicación puede autenticar a través del proveedor de identidad y mantener a la vez administradores locales, claves de API, sesiones activas u opciones de recuperación. Un conector de aprovisionamiento puede deshabilitar a un usuario sin retirar todos sus permisos. Documente lo que hace realmente cada mecanismo.

Incluya estas vías de acceso menos visibles:

• Cuentas privilegiadas separadas de la cuenta habitual de la persona.
• Acceso por VPN, certificados, claves SSH y herramientas de soporte remoto.
• Tokens de acceso personal, credenciales de API y contraseñas de aplicación.
• Credenciales compartidas que la persona conocía o podía obtener.
• Cuentas de invitado, espacios de colaboración externos y entornos gestionados por clientes.
• Identidades de servicio cuyo responsable o custodio de credenciales cambia.

No deshabilite automáticamente todas las identidades de servicio asociadas a un empleado que se marcha: puede que ejecuten una carga de trabajo de producción. En su lugar, transfiera su titularidad, revise los permisos y rote las credenciales expuestas cuando proceda. El objetivo es retirar el acceso de la persona sin provocar una interrupción evitable.

Concilie periódicamente el inventario con las exportaciones de identidades, los registros de dispositivos, los registros de compras y las declaraciones de los equipos. Ninguna fuente por sí sola revelará necesariamente todas las aplicaciones. Las aplicaciones no gestionadas que se descubran deben incorporarse al proceso del ciclo de vida en lugar de seguir siendo excepciones informales.

Altas: aprovisione un estado inicial controlado

Construya bases de rol con excepciones acotadas

Defina paquetes de acceso en torno a responsabilidades, no solo a denominaciones de puesto. Un analista de soporte podría necesitar acceso a los tickets de clientes, pero no a las exportaciones de facturación. Un ingeniero de software podría necesitar los repositorios de código y los entornos de desarrollo sin recibir por defecto la administración de producción.

Cada base debe tener un responsable, una versión, los grupos o permisos incluidos y una fecha de revisión. Registre qué versión se aplicó a cada alta. De lo contrario, una actualización posterior del rol dificulta reconstruir las decisiones de acceso históricas.

Solicite por separado los accesos adicionales. La solicitud debe indicar la finalidad de negocio, el responsable del sistema o de los datos que lo aprueba, el nivel de permiso y, cuando proceda, la fecha de caducidad. Evite copiar el conjunto completo de permisos de un empleado existente: puede reproducir excepciones acumuladas y privilegios de puestos anteriores.

Prepare las cuentas antes de la fecha de incorporación cuando sea útil, pero controle su activación. Una contratación cancelada debe desencadenar la limpieza de las cuentas preparadas, los dispositivos enviados y las invitaciones. Los contratistas deben tener un patrocinador interno y una fecha de finalización o de revisión; las prórrogas deben exigir una decisión expresa en lugar de convertirse discretamente en accesos permanentes.

Establezca la base de dispositivo y de autenticación

Registre el identificador del dispositivo, la persona asignada, la fecha de entrega y la inscripción en la gestión de dispositivos. Compruebe la base pertinente antes de conceder accesos sensibles: sistema operativo con soporte, estado de los parches, cifrado de disco, bloqueo de pantalla, protección de endpoints y una configuración de autenticación aprobada.

Son decisiones de implantación basadas en el riesgo, no la afirmación de que todas las organizaciones deban usar configuraciones idénticas. En el caso de los dispositivos personales, defina de forma explícita los accesos permitidos y el tratamiento de los datos en lugar de tratarlos como equivalentes a los portátiles gestionados.

Utilice observaciones fechadas de los sistemas de gestión de dispositivos cuando estén disponibles. Un inventario manual puede seguir siendo útil si se concilia y se respalda con evidencias; un inventario en tiempo real también necesita examen cuando un dispositivo ha dejado de reportar. Conserve las horas de observación para que un estado correcto antiguo no se confunda con una garantía actual.

Verifique la inscripción en la autenticación y la entrega inicial de credenciales. Cuando su política exija autenticación multifactor, confirme que está activa antes de que empiece el acceso, en lugar de registrar solo que se envió una invitación de inscripción. Mantenga las credenciales y los códigos de recuperación fuera de los tickets del ciclo de vida.

Cambios de puesto: retire el rol anterior, no se limite a añadir el nuevo

Los traslados suelen ser los eventos más difíciles del ciclo de vida porque la persona sigue en la plantilla y su cuenta existente sigue funcionando. Los nuevos accesos reciben atención porque la falta de permisos interrumpe el trabajo. Los accesos antiguos pueden persistir sin ningún síntoma visible.

Trate el cambio de puesto como una comparación entre tres estados: los accesos actuales, la nueva base aprobada y las excepciones que se mantienen con aprobación. Determine qué permisos deben añadirse, conservarse, reducirse o retirarse. Compruebe las asignaciones directas además de los grupos, las pertenencias anidadas, los roles administrativos y los permisos locales de las aplicaciones.

El responsable anterior debe ayudar a identificar las responsabilidades que han terminado. El responsable que recibe a la persona confirma las nuevas funciones, mientras que los responsables de los sistemas o de los datos aprueban los accesos sensibles. Así se evita que un nuevo responsable autorice implícitamente que se conserve el acceso a la información de otro departamento.

Un periodo de transición puede ser legítimo. Alguien que deja el área financiera puede necesitar un acceso limitado para completar un traspaso. Registre el permiso concreto, la justificación, el responsable que lo aprueba y la fecha de caducidad. Cuando sea posible, sustituya los accesos amplios de escritura por accesos más limitados o de solo lectura. Plasme la caducidad en una tarea ejecutable o en una configuración del sistema, no solo en un comentario.

Los cambios también pueden afectar a dispositivos, buzones compartidos, titularidad de datos y funciones privilegiadas. Pasar a un rol administrativo no debe convertir automáticamente la cuenta habitual en una identidad privilegiada.

Tras la ejecución, compare el conjunto real de accesos con el resultado previsto. En un traslado de departamento, conceder el nuevo rol puede ser fácil. La comprobación importante es si siguen existiendo accesos antiguos a finanzas, a clientes o administrativos. Una muestra de cambios de puesto que solo comprueba el nuevo aprovisionamiento pasa por alto ese riesgo.

Bajas: coordine la revocación, los activos y la continuidad del negocio

Fije los plazos según el riesgo y las circunstancias

Registre una hora de efecto de la revocación, incluida la zona horaria. «Último día» es demasiado ambiguo para equipos distribuidos y automatizaciones programadas. Distinga una salida planificada de un despido urgente, de un compromiso sospechado o de una ausencia imprevista que requiera una suspensión temporal.

Acuerde los plazos con RR. HH. y la dirección correspondiente. Limite los detalles sensibles de la extinción a quienes los necesiten, garantizando al mismo tiempo que los ejecutores reciben información suficiente para actuar. Las salidas de alto riesgo pueden requerir una actuación inmediata coordinada; las salidas rutinarias pueden permitir un traspaso planificado antes de que termine el acceso.

No permita que la transferencia de datos o el envío de dispositivos retrasen la revocación. Estas actividades pueden tener fechas de finalización y responsables propios. Si un aviso llega tarde, registre la hora de corte prevista, la ejecución real y el intervalo de exposición en lugar de modificar la documentación para que el evento parezca puntual.

Cierre todas las vías de acceso pertinentes

Deshabilite la identidad principal y ejecute las acciones específicas de cada aplicación según el inventario. Ocúpese, según corresponda, de las sesiones activas, los tokens de actualización, las cuentas locales, las cuentas privilegiadas, el acceso remoto, los certificados y las credenciales personales. Deshabilitar la cuenta central no demuestra que todas las sesiones existentes o las credenciales emitidas de forma independiente hayan quedado inutilizables.

Rote según el riesgo los secretos compartidos a los que la persona podía acceder y compruebe que la rotación no interrumpirá los sistemas dependientes. Elimine los métodos de recuperación o los permisos delegados que podrían restablecer el acceso. Cuando haya entornos de clientes o proveedores implicados, solicite la revocación a su responsable y conserve la confirmación.

Recoja los resultados individuales. Un tiempo de espera agotado de un conector no es un cierre correcto solo porque la tarea en su conjunto haya finalizado. Dirija los fallos a un responsable designado, utilice una alternativa aprobada y verifique el estado final. Los accesos urgentes sin resolver deben entrar en el proceso de escalado de seguridad.

Recupere los dispositivos sin dar por hecho que los comandos remotos funcionaron

Haga el seguimiento de cada activo asignado a través de la devolución, la inspección y el restablecimiento o la eliminación aprobados. En el caso de los trabajadores a distancia, registre las condiciones de envío y la custodia pendiente. Retire el acceso físico y recupere tokens o llaves cuando proceda.

Si la devolución se retrasa, utilice los controles de bloqueo o borrado disponibles según la política y el riesgo. Distinga la emisión de un comando de la confirmación por parte del dispositivo de que lo ha completado. Un portátil sin conexión puede no recibir el comando. Evalúe la exposición residual teniendo en cuenta el estado del cifrado, las credenciales locales, los datos en caché y las restricciones de red disponibles, en lugar de tratar «borrado en cola» como prueba de que se ha borrado.

Conserve los datos necesarios y recupere las licencias

Asigne un sucesor para los documentos de negocio, los repositorios, los flujos de trabajo compartidos y la titularidad de servicios. Utilice mecanismos administrativos de transferencia autorizados en lugar de pedir a alguien que se haga pasar por el antiguo empleado. Acote el acceso al buzón o a los archivos, registre la finalidad y limite las personas que lo reciben.

Separe la revocación de accesos, la recuperación de licencias, la conservación y el borrado. Retirar una licencia puede afectar de forma distinta a la disponibilidad de los datos según la aplicación. Compruebe los requisitos de conservación y cualquier retención por motivos legales antes de una limpieza irreversible.

En el caso de los datos personales, el artículo 5 del RGPD establece la limitación del plazo de conservación; no crea un plazo universal para borrar las cuentas de los empleados. Defina periodos de conservación justificados y responsabilidades de limpieza. El artículo 32 exige medidas de seguridad adecuadas al riesgo, por lo que debe documentar el razonamiento de los controles de baja en lugar de tratar una lista de comprobación como cumplimiento legal por sí misma.

Conserve evidencias del cambio real

El registro útil vincula la decisión autorizada con el resultado observado. Conserve el evento, la aprobación, los sistemas afectados, las horas de ejecución, los resultados de la verificación y la gestión de las excepciones. Incluya la hora de efecto prevista para que los revisores puedan evaluar la puntualidad.

Un paquete de evidencias práctico contiene:

• Un identificador estable de la persona y del evento, con la fuente que lo inició.
• La base aprobada y cualquier permiso conservado o adicional.
• Acciones, resultados, marcas de tiempo y referencias de registros pertinentes por sistema.
• Una verificación que muestre el estado de acceso resultante.
• Los resultados relativos a activos, transferencia de datos y licencias cuando proceda.
• Las acciones fallidas y las excepciones con un responsable, una fecha límite y evidencias de cierre.

Una política demuestra la intención. Un ticket demuestra la coordinación. El resultado de una aplicación o una exportación de accesos ayuda a demostrar la implantación. Ninguno debe sustituir a los demás. Las capturas de pantalla pueden ser útiles cuando no hay exportaciones más sólidas, pero deben incluir contexto suficiente para identificar el sistema, la persona y la hora de la observación.

Proteja estos registros: contienen información laboral y detalles sensibles desde el punto de vista de la seguridad. Aplique restricciones de acceso y un calendario de conservación, y evite recopilar como evidencia contraseñas, relatos innecesarios sobre la extinción o buzones completos. Los registros históricos deben seguir siendo comprensibles incluso después de que se hayan borrado las cuentas operativas.

Ejemplo práctico: un traslado seguido de una baja

Consideremos una empresa ilustrativa con un proveedor de identidad central, portátiles gestionados y una aplicación financiera con permisos locales. Supongamos que una empleada pasa de operaciones financieras a éxito del cliente el 1 de junio, necesita un traspaso de cinco días laborables y más tarde se marcha el 30 de septiembre. Estas fechas y disposiciones son supuestos del ejemplo, no plazos prescritos.

Para el cambio de puesto, TI recoge los permisos actuales. Se aprueba el acceso de éxito del cliente, se retira el acceso de escritura a finanzas en la hora de efecto y se conserva un acceso restringido de lectura a finanzas hasta que caduque el traspaso. El responsable de finanzas aprueba esa excepción. Como la aplicación financiera mantiene permisos locales, su administrador ejecuta y verifica el cambio por separado de la actualización de grupos en el proveedor de identidad.

Al caducar la excepción, la verificación detecta que sigue existiendo un permiso local de exportación. El registro del cambio de puesto permanece abierto, el administrador lo retira y el revisor registra el estado final. La lección es concreta: el cambio de rol funcionó a nivel central, pero el modelo de permisos de la aplicación exigía una acción adicional.

Para la baja posterior, el proceso fija una hora de corte precisa, transfiere los archivos de negocio a un sucesor aprobado, deshabilita las identidades, revoca las sesiones y tokens aplicables y comprueba directamente la cuenta financiera. El portátil todavía no ha llegado por mensajería. Su devolución sigue siendo una excepción de activos, con las acciones de contención y las observaciones del dispositivo registradas por separado de la revocación de la cuenta.

Las evidencias resultantes muestran tanto los cambios correctos como el fallo inicial en la retirada. Ocultar el fallo haría perder la información necesaria para mejorar el flujo de trabajo.

Pruebe la cobertura y concrete la siguiente mejora

Contraste una muestra de eventos reales del ciclo de vida con el inventario de aplicaciones. Incluya contratistas, usuarios privilegiados, trabajadores a distancia, cambios de puesto con solapamiento temporal y aplicaciones fuera del proveedor de identidad. Las revisiones de accesos también deben examinar si los permisos actuales siguen correspondiéndose con las responsabilidades de cada persona; complementan los cambios basados en eventos, no los sustituyen.

Pruebe tanto las rutas de fallo como la ejecución normal: un evento de RR. HH. que no llega, un conector que falla, un administrador no disponible, una devolución de dispositivo que se retrasa o una incorporación cancelada. Compruebe que las alertas llegan a un responsable y que los reintentos o las acciones manuales producen resultados verificables.

Algunas medidas útiles son el retraso de la revocación respecto a la hora de corte acordada, las acciones fallidas pendientes de resolución, los accesos temporales vencidos y los eventos cerrados sin verificación. Defina qué cuenta cada medida. Una buena media puede ocultar una excepción privilegiada de larga duración. Utilice los hallazgos para actualizar las bases de rol, el comportamiento de los conectores, la titularidad y las reglas de escalado.

Secani puede respaldar el registro de controles revisable vinculando los requisitos con sistemas, responsables, evidencias y decisiones. Mantenga los cambios de cuentas en los sistemas operativos de identidad y de dispositivos; utilice el espacio de trabajo de cumplimiento para conservar el alcance, los resultados subidos, las excepciones y las decisiones de revisión. Los revisores humanos deben validar cualquier conclusión sobre evidencias asistida por IA antes de basarse en ella.

Empiece con un equipo representativo y con un alta, un cambio de puesto y una baja recientes. Siga cada evento desde la notificación hasta el estado real de los sistemas. Corrija el primer traspaso o la primera vía de acceso sin cubrir que detecte, asígnele un responsable y vuelva a probarlo antes de ampliar el proceso.