Ir al contenido principal

¿Cómo hacer una revisión real del modelo de acceso?: el proceso y las fricciones que nadie menciona

TÉCNICO-GERENCIAL · IDENTIDAD Y ACCESO · REVISIÓN DE ACCESOS

Revisión del modelo de acceso El proceso que convierte el inventario de cuentas en un modelo de acceso real y auditado PASO 01 Inventario completo PASO 02 Cruce con RRHH PASO 03 Revisión de privilegios PASO 04 Certificación por jefatura PASO 05 Remedia ción ¿Quién tiene el listado completo? RRHH no siempre actualiza en tiempo real ¿Contra qué perfil de rol se compara? Jefaturas no siempre tienen el contexto Fricción con el usuario CADENCIA RECOMENDADA Revisión completa Semestral Revisión de terceros Trimestral Por evento Baja, cambio de rol Una revisión de accesos no es un proyecto. Es un proceso con cadencia. La primera vez cuesta. La segunda vez cuesta menos. La tercera ya es rutina. LB · Luis Bolívar · Cybersecurity Insights
El proceso de revisión de accesos en cinco pasos, con las fricciones reales de cada uno. El proceso importa tanto como el resultado.

Ayer describí las cuatro categorías de brecha de identidad más frecuentes: cuentas huérfanas, privilege creep, accesos de terceros sin vencimiento y credenciales compartidas. Todas tienen en común que no generan alerta por sí solas y que solo una revisión periódica puede identificarlas antes de que alguien las explote. Hoy quiero ver cómo se hace esa revisión en la práctica, con sus pasos concretos y, sobre todo, con las fricciones que aparecen en cada uno de ellos y que son las que hacen que el proceso se postergue o se abandone a mitad de camino.

Porque la revisión de accesos es uno de esos procesos donde la dificultad real no es técnica. No requiere herramientas sofisticadas. Requiere coordinación entre áreas que no siempre hablan el mismo idioma, disposición a tomar decisiones que generan fricción con usuarios, y la disciplina de repetirlo con cadencia aunque el resultado del ejercicio anterior haya sido incómodo.

PASO 1: EL INVENTARIO QUE NADIE TIENE COMPLETO

El primer paso es obtener el inventario completo de cuentas activas con acceso a sistemas relevantes. Suena simple. No lo es.

El problema estructural es que en la mayoría de las organizaciones medianas el directorio principal, generalmente Active Directory o un equivalente en entornos cloud, no es la única fuente de identidad. Hay sistemas que tienen su propia gestión de usuarios independiente: el ERP, la plataforma de gestión de proyectos, los sistemas de monitoreo de red, la consola de administración del FortiManager o el sistema de gestión de la infraestructura Cisco. Cada uno de esos sistemas puede tener cuentas que no están sincronizadas con el directorio central.

El inventario completo requiere listar no solo las cuentas del directorio sino las cuentas de acceso en cada sistema relevante. Ese ejercicio, la primera vez que se hace, típicamente revela más cuentas de las que el equipo esperaba. Y algunos sistemas no tienen una forma simple de exportar la lista de usuarios activos, lo que agrega fricción técnica al proceso.

PASO 2: EL CRUCE CON RECURSOS HUMANOS

Una vez que existe el inventario de cuentas, el siguiente paso es cruzarlo con el listado de personas que tienen una relación vigente con la organización: empleados activos y contratistas con contrato vigente. Ese cruce identifica las cuentas huérfanas.

La fricción aquí es de coordinación. El listado de empleados activos vive en Recursos Humanos. El listado de cuentas vive en TI. Esas dos áreas no siempre tienen un canal de comunicación establecido para intercambiar esa información de forma sistemática. Y el listado de RRHH no siempre está actualizado en tiempo real: en algunas organizaciones, el proceso administrativo de baja de un empleado tiene un retraso de días o semanas respecto a la fecha efectiva de salida.

Establecer ese canal de comunicación, definir el formato del intercambio de información y acordar la frecuencia de actualización es trabajo de proceso, no de tecnología. Pero es el trabajo que hace que el cruce sea posible de forma sistemática y no solo como un ejercicio puntual cada vez que alguien lo pide.

PASO 3: LA REVISIÓN DE PRIVILEGIOS

Identificar las cuentas activas cuyos titulares siguen en la organización es necesario pero no suficiente. El siguiente paso es revisar que los privilegios asignados a cada cuenta correspondan al rol actual de la persona, no a la acumulación histórica de roles anteriores.

Aquí aparece la fricción más difícil de resolver sin un trabajo previo: para comparar los privilegios actuales con el perfil de rol correspondiente, tiene que existir una definición de qué accesos corresponde a cada rol. Si la organización no tiene esa matriz de roles y accesos documentada, la revisión de privilegios no tiene un referente contra el cual comparar. El técnico que tiene acceso a doce sistemas distintos, ¿cuántos de esos accesos son necesarios para su rol actual? Sin la matriz, esa pregunta no tiene respuesta objetiva.

Construir esa matriz de roles y accesos es, en sí mismo, un proyecto de cierta envergadura. Pero no tiene que ser perfecta para ser útil. Una versión básica que defina los accesos mínimos necesarios para los roles más críticos de la organización, administradores de sistemas, accesos a datos financieros, accesos a infraestructura de red, es suficiente para empezar a identificar las desviaciones más evidentes.

ERROR COMÚN

Intentar hacer la revisión completa de todos los accesos de toda la organización en un solo ejercicio la primera vez. Ese alcance genera una carga de trabajo que el equipo no puede absorber, produce resultados tan voluminosos que nadie los procesa completamente, y lleva a que el ejercicio se abandone antes de completarse. La primera revisión debe ser acotada: los accesos a sistemas críticos, los usuarios con privilegios elevados, las cuentas de terceros. Un alcance manejable que produzca resultados accionables es más valioso que un inventario exhaustivo que nadie termina de revisar.

PASO 4: LA CERTIFICACIÓN POR JEFATURA

La revisión técnica de accesos puede identificar anomalías, pero la decisión de si un acceso específico está justificado para una persona específica en su rol actual no es siempre una decisión técnica. Es una decisión de negocio que tiene que tomar quien conoce las responsabilidades actuales de esa persona: la jefatura directa.

El proceso de certificación consiste en presentar a cada jefatura la lista de accesos activos de las personas bajo su responsabilidad y pedirle que confirme cuáles están justificados y cuáles no. Ese paso es el que distribuye la responsabilidad de la revisión más allá de TI y la convierte en un proceso organizacional.

La fricción aquí es de tiempo y contexto. Las jefaturas tienen sus propias prioridades. Revisar una lista de accesos de diez personas con quince sistemas cada una requiere atención que compite con otras demandas. Y en algunos casos, la jefatura no tiene el contexto técnico para evaluar si un acceso específico está justificado. El proceso tiene que facilitar ese trabajo: listas pre-filtradas, preguntas simples, plazos claros y un escalamiento definido para los casos donde la jefatura no puede determinar si el acceso es necesario.

PASO 5: LA REMEDIACIÓN Y LA FRICCIÓN CON EL USUARIO

El último paso es actuar sobre lo que la revisión encontró: desactivar cuentas huérfanas, retirar privilegios excesivos, revocar accesos de terceros vencidos, separar y personalizar credenciales compartidas. Cada una de esas acciones tiene el potencial de generar una fricción con el usuario o el sistema afectado.

La persona cuya cuenta huérfana se desactiva puede haber estado usando esas credenciales para acceder ocasionalmente a sistemas después de su salida, algo que no debería ocurrir pero que en la práctica a veces ocurre. El técnico al que se le retiran privilegios acumulados puede descubrir que los usaba de forma informal para hacer tareas que en teoría ya no le corresponden. El proveedor cuyo acceso se revoca puede argumentar que todavía tiene trabajo pendiente.

Anticipar esa fricción, tener un proceso claro para gestionar las excepciones justificadas y ser firme con las que no lo son, requiere respaldo explícito de la gerencia. Sin ese respaldo, la presión de los casos individuales tiende a erosionar el resultado de la revisión antes de que se consolide.

DECISIÓN QUE DEBE TOMAR EL CIO

Definir la cadencia del proceso antes de hacer la primera revisión: revisión completa semestral, revisión de accesos de terceros trimestral, y revisión por evento ante cualquier baja o cambio de rol significativo. Sin esa cadencia definida, la revisión es un proyecto puntual que se hace una vez y no se repite. Con la cadencia definida, es un proceso que mejora con cada ciclo porque el equipo ya sabe qué hacer, dónde están las fricciones y cómo gestionarlas.

La revisión de accesos no es un proyecto de seguridad. Es un proceso de higiene organizacional que tiene que repetirse con cadencia. La primera vez cuesta porque hay que construir el proceso, coordinar las áreas y gestionar la fricción de los resultados. La segunda vez cuesta menos. La tercera ya es rutina. El problema es que la mayoría de las organizaciones nunca llegan a la segunda.

Artículo núcleo de la semana: Identidad y acceso: el perímetro que nadie administra. Mañana: el caso TechCorp Latam.

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

Comentarios

Entradas más populares de este blog

¿Por qué CIS Controls antes que cualquier otra cosa? Serie: CIS Controls — Post 1 de 5

SERIE CIS CONTROLS · POST 1 DE 5 Estrategia · Liderazgo en TI ¿Por qué CIS Controls antes que cualquier otra cosa? El argumento estratégico para empezar por donde el riesgo es mayor, no por donde el proceso es más visible. Priorización por riesgo No todos los controles valen lo mismo Lenguaje de negocio Traduce técnica en riesgo medible Complementa ISO 27001 Donde la norma dice qué, CIS dice cómo LB Luis Bolívar IT Manager · Cybersecurity Insights #CISControls #Ciberseguridad Serie CIS Controls — Post 1 de 5: el argumento estratégico para empezar por donde el riesgo es mayor. Cuando TechCorp Latam implementó CIS Controls por primera vez, lo hizo después de un ransomware que comprometió el 65% de sus servidores. No fue una decisión estratégica planificada; fue un...

NIST CSF 2.0 — IDENTIFY: Conoce tus activos antes de protegerlos

NIST CSF 2.0 — IDENTIFY: Conoce tus activos antes de protegerlos Serie · Post 2 de 6 🔍 Función ID — IDENTIFY NIST CSF 2.0 — IDENTIFY: Conoce tus activos antes de protegerlos No puedes proteger lo que no sabes que tienes. IDENTIFY es el mapa que toda organización necesita antes de implementar cualquier control de seguridad. Analizamos sus 3 categorías y construimos el inventario de TechCorp Latam. 📅 Publicación 2 de 6 ⏱ Lectura: ~10 min 🏢 TechCorp Latam · Inventario desde cero El error más costoso en ciberseguridad: proteger sin saber qué tienes Imagina contratar una empresa de seguridad para custodiar tu edificio, pero nadie te da el plano del edificio. ¿Cuántas entradas hay? ¿Dónde están los archivos más valiosos? ¿Qué puertas dan al exterior? Sin ese plano, la seguridad es aleatoria. Exactamente eso ocurre cuando una organización invierte en firewalls, antivirus y monitoreo sin haber hecho antes un trabajo sistemático de identif...

NIST CSF 2.0 — RESPOND: Actuar cuando el incidente ya ocurrió

NIST CSF 2.0 — RESPOND: Actuar cuando el incidente ya ocurrió Serie · Post 5 de 6 🚨 Función RS — RESPOND NIST CSF 2.0 — RESPOND: Actuar cuando el incidente ya ocurrió Todo lo que TechCorp Latam construyó en GOVERN, IDENTIFY, PROTECT y DETECT llegó a su momento de verdad: un ataque de ransomware real. Esta es la historia de cómo respondieron, qué salió bien y qué lección pagaron caro. 📅 Publicación 5 de 6 ⏱ Lectura: ~12 min 🏢 TechCorp Latam · El momento de la verdad El momento para el que todo lo anterior te prepara Llevan cuatro funciones construyendo su programa. Tienen gobernanza, inventario de activos, controles activos y visibilidad de red. Y aun así, el incidente ocurre. Porque esa es la realidad del riesgo cibernético: los controles reducen la probabilidad, no la eliminan . El objetivo de un programa maduro de ciberseguridad no es hacer que los incidentes sean imposibles — es hacer que sean contenibles, detectables y recuper...