¿Quién es responsable del modelo de acceso?: el limbo que ningún incidente debería resolver

REFLEXIVO · LIDERAZGO · CIERRE DE SERIE

TI gestiona el sistema pero no decide quién accede. RRHH sabe quién trabaja pero no gestiona accesos. Las jefaturas saben qué hace su equipo pero no piensan en términos de acceso TI. El modelo de acceso cae en el medio.

La semana pasada terminé el jueves con una pregunta que quedó abierta: si TechCorp Latam sabía que las credenciales de administrador llevaban 11 meses sin rotar, que había un acceso de proveedor activo post-contrato, que una cuenta de ex-empleado seguía activa, ¿por qué ese respaldo organizacional para actuar sobre esas brechas llegó después del incidente y no antes?

La respuesta no es simple, pero hay un elemento que aparece con consistencia en los casos que he analizado: la responsabilidad del modelo de acceso tiende a quedar en un limbo entre tres áreas que tienen información parcial y autoridad parcial, y ninguna de las cuales tiene la responsabilidad completa de que el modelo funcione. Ese limbo no es accidental ni producto de mala fe. Es el resultado predecible de cómo se distribuye la información y la autoridad en organizaciones medianas que no han definido explícitamente quién es dueño del proceso.

TRES ÁREAS, TRES PIEZAS DEL ROMPECABEZAS, NINGÚN DUEÑO

TI tiene la información técnica: sabe cuántas cuentas existen, qué privilegios tienen asignados, cuándo fue el último acceso registrado. TI también tiene la capacidad técnica de ejecutar los cambios: desactivar cuentas, retirar privilegios, configurar fechas de vencimiento. Lo que TI no tiene, en la mayoría de las organizaciones, es la autoridad unilateral para decidir quién debería o no tener acceso a un sistema de negocio. Esa decisión requiere información sobre roles y responsabilidades que vive fuera de TI.

RRHH tiene la información sobre personas: sabe quién está activo en la organización, cuándo alguien sale, cuándo alguien cambia de rol. Es la fuente de verdad sobre el estado de la relación laboral. Lo que RRHH generalmente no tiene es la visión sobre qué sistemas usa cada persona ni la capacidad técnica para gestionar accesos de TI. Su proceso de offboarding contempla las dimensiones laborales y administrativas de la salida; la revocación de accesos digitales puede estar mencionada en la política pero raramente tiene un mecanismo de verificación activo vinculado al proceso de RRHH.

Las jefaturas de área tienen la información de negocio: saben qué hace cada persona de su equipo, qué sistemas necesita para sus responsabilidades actuales, qué cambió cuando alguien rotó de rol. Esa información es la que permite determinar si un acceso específico está justificado para una persona específica. Lo que las jefaturas típicamente no tienen es el hábito de pensar en términos de acceso TI como parte de su responsabilidad de gestión. Para ellas, el acceso a los sistemas es algo que TI gestiona, no algo que ellas tienen que certificar periódicamente.

Cuando la responsabilidad se distribuye entre tres áreas sin un proceso explícito que defina quién hace qué, cuándo y con qué mecanismo de verificación, el resultado predecible es que cada área asume que alguna de las otras dos está cubriendo lo que falta. TI asume que RRHH le notificará cuando alguien sale. RRHH asume que TI gestiona los accesos como parte de su rol. Las jefaturas asumen que alguien en TI o en RRHH se encarga de mantener el modelo actualizado. Nadie está equivocado en su comprensión parcial del problema. Pero el sistema como conjunto falla.

LO QUE CAMBIA CUANDO ALGUIEN NOMBRA AL DUEÑO

La diferencia entre organizaciones que tienen un modelo de acceso razonablemente administrado y las que no casi nunca está en la tecnología. Está en si alguien, con nombre y cargo, tiene la responsabilidad explícita de que el proceso funcione.

Ese alguien no tiene que hacer todo el trabajo solo. Tiene que asegurarse de que el proceso se ejecute: que TI tenga el listado de empleados vigentes cuando lo necesita, que RRHH active la notificación de bajas y cambios de rol hacia TI, que las jefaturas respondan las certificaciones en el plazo comprometido, que las excepciones se documenten y se revisen. Es un rol de coordinación y seguimiento, no de ejecución técnica.

En organizaciones medianas, ese rol puede recaer en el responsable de TI o en el CIO, pero requiere que la gerencia general valide que esa responsabilidad incluye la autoridad para exigir colaboración de RRHH y de las jefaturas de área cuando el proceso lo requiere. Sin esa autoridad explícita, el responsable de TI puede proponer, puede documentar, puede insistir, pero no puede garantizar que el proceso funcione cuando los demás actores no priorizan su parte.

¿POR QUÉ EL RESPALDO LLEGA DESPUÉS DEL INCIDENTE?

Volviendo a la pregunta de ayer: el respaldo llega después del incidente porque antes del incidente el costo de no tenerlo es abstracto y futuro, y el costo de construirlo es concreto y presente.

Construir el proceso de gestión de accesos requiere tiempo de TI, coordinación con RRHH, colaboración de las jefaturas y respaldo de la gerencia general. Cada uno de esos elementos tiene un costo visible en el corto plazo: reuniones, definición de procesos, fricción con usuarios, excepciones que gestionar. El beneficio, la reducción del riesgo de un incidente que todavía no ocurrió, es invisible.

Después del incidente, ese cálculo se invierte. El costo de no haber tenido el proceso es ahora concreto, documentado en horas de recuperación, en pérdida de datos, en costo de remediación, en impacto reputacional. Frente a ese número real, el costo de implementar el proceso parece razonable. Y el respaldo de la gerencia, que antes era difícil de obtener, llega de forma casi automática.

El trabajo de quien gestiona TI, antes del incidente, es acortar esa distancia. Construir el argumento que hace que el costo del incidente potencial sea tan concreto como el costo del proceso de prevención. Eso requiere estimaciones, números propios de la organización, y la disposición de la gerencia a escuchar ese argumento antes de que la urgencia lo haga inevitable.

No siempre funciona. Pero es el único camino que no pasa por el incidente primero.

LO QUE ESTA SEMANA DEJA SOBRE LA MESA

Esta semana analicé la identidad y el acceso desde cinco ángulos: el lunes, el encuadre del problema y por qué es el perímetro más importante en el contexto actual. El martes, las cuatro brechas concretas más frecuentes. El miércoles, el proceso de revisión con sus cinco pasos y sus fricciones reales. El jueves, el caso TechCorp Latam. Hoy, quién es responsable y por qué el respaldo llega tarde.

El patrón que conecta esta semana con las anteriores sobre continuidad y vulnerabilidades es el mismo: la organización sabe lo que tiene que hacer, tiene los recursos para hacerlo, y no lo hace porque la cadena de responsabilidad y autoridad que necesita el proceso no está claramente definida ni respaldada desde arriba.

Resolver eso no es un problema técnico. Es un problema de gobernanza. Y la gobernanza no se resuelve con herramientas. Se resuelve con decisiones.

Si esta semana alguien con autoridad en tu organización te preguntara quién es responsable de que el modelo de acceso esté actualizado, ¿habría una respuesta clara con un nombre? Si la respuesta es "entre varios" o "no está definido", ya sabes cuál es la decisión que está pendiente. No es tecnológica. Es de gobernanza.

Artículo núcleo de la semana: Identidad y acceso: el perímetro que nadie administra.

#IdentidadYAcceso #IAM #Ciberseguridad #CIO #ITManager #GestiónDeRiesgos #Fortinet #Cisco #WatchGuard #TechCorpLatam #CyberLeadership #Liderazgo #Chile #ZeroTrust #GobernanzaTI #NISTCSF #ISO27001