Cada vez que una organización se prepara para una auditoría de ISO 27001, hay una semana en la que alguien descubre que nadie sabe exactamente quién tiene acceso a qué. Las políticas están escritas, el SGSI tiene su documentación, pero cuando el auditor pide "mostrame las bajas del último trimestre y cuándo se les quitaron los accesos", empiezan las planillas, los mails cruzados y las consultas a mano en Active Directory.
Trabajo todos los días en gestión y gobernanza de identidades, y buena parte de ese trabajo es justamente esto: dejar los accesos de una organización en un estado que se pueda defender frente a una auditoría. Acá va lo que aprendí sobre qué se revisa, qué evidencia conviene tener lista y dónde suelen aparecer los problemas.
Qué controles tocan identidades y accesos
En la versión 2022 de la norma, los controles del Anexo A que más pegan sobre identidades son pocos pero muy concretos:
- 5.15 Control de acceso: que existan reglas de acceso definidas según las necesidades del negocio y de seguridad.
- 5.16 Gestión de identidades: el ciclo de vida completo de cada identidad, desde que se crea hasta que se da de baja.
- 5.17 Información de autenticación: cómo se entregan y gestionan contraseñas y otros secretos.
- 5.18 Derechos de acceso: el alta, la modificación, la revisión periódica y la remoción de accesos.
- 8.2 Derechos de acceso privilegiado: las cuentas con privilegios, restringidas y controladas aparte.
- 8.5 Autenticación segura: los mecanismos de autenticación acordes al riesgo, incluido MFA donde corresponda.
La norma no te dice qué herramienta usar ni cómo implementar cada cosa. Te pide que tengas un criterio, que lo apliques y que lo puedas demostrar. Esa última parte es la que suele fallar.
Lo que el auditor realmente pide
Un auditor no va a leer tu política de accesos y quedarse tranquilo. Va a tomar muestras y va a intentar seguir el rastro. Las preguntas típicas son de este estilo:
- Elegí cinco altas del período: ¿quién pidió el acceso, quién lo aprobó y qué se le dio?
- Elegí cinco bajas: ¿en qué fecha se fue la persona y en qué fecha se deshabilitaron sus cuentas?
- Elegí cinco cambios de puesto: ¿se le quitaron los accesos del puesto anterior?
- Mostrame la última revisión de accesos de tal aplicación crítica y qué se hizo con lo que se rechazó.
- ¿Quiénes son administradores de dominio hoy y por qué?
Si para contestar cada una de esas preguntas hay que reconstruir la historia a partir de tickets y mails, el problema no es la auditoría: es que el proceso no deja rastro.
La evidencia que conviene tener armada antes
Lo que recomiendo preparar, con tiempo y no la semana anterior:
- Una fuente de verdad de personas. Normalmente RR.HH. Si no hay un listado confiable de quién trabaja hoy en la organización, no hay forma de saber qué cuentas sobran.
- Un cruce entre esa fuente y los sistemas. Cuentas activas en Active Directory, Entra ID y las aplicaciones críticas contra el listado de personas. Lo que no matchea es tu primer lote de hallazgos, mejor encontrarlo vos que el auditor.
- El registro de altas, bajas y cambios del período con fechas, solicitante y aprobador.
- Las revisiones de acceso (recertificaciones) del período, con el resultado y la evidencia de que lo rechazado efectivamente se quitó.
- El inventario de cuentas privilegiadas y de cuentas de servicio, cada una con un responsable.
Una revisión de accesos sin evidencia de remediación no es una revisión: es una encuesta.
Los hallazgos que más se repiten
Más allá de la organización o del rubro, hay hallazgos que aparecen casi siempre:
Cuentas de gente que ya no está
La baja se procesó en RR.HH., se deshabilitó la cuenta de dominio, pero quedó viva la cuenta local de la aplicación que no está integrada con nada. Es el hallazgo más común y el más fácil de explicar en un informe, por eso duele.
Acumulación de privilegios
Alguien pasó por tres áreas en cinco años y conserva los accesos de las tres. Nadie se los dio mal: simplemente nunca se le quitaron. Acá es donde un proceso de cambios de puesto (el "mover" del joiner/mover/leaver) hace la diferencia.
Cuentas de servicio sin dueño
Cuentas creadas para una integración hace años, con contraseña que nunca expira y permisos amplios, que nadie se anima a tocar porque "algo se puede romper". Si no tienen un responsable asignado, no hay a quién preguntarle si siguen haciendo falta.
Revisiones que se aprueban en bloque
La campaña de revisión existe, pero el responsable aprueba todo con un clic porque tiene cientos de ítems y no entiende qué significa cada permiso. Técnicamente hay evidencia; en la práctica no se revisó nada. Un buen auditor lo detecta mirando cuánto tardó cada revisor y cuántos rechazos hubo.
Por dónde empezar si la auditoría está cerca
Si la auditoría es en pocas semanas, no es momento de implementar una herramienta nueva. Lo que sí se puede hacer:
- Hacer el cruce RR.HH. contra directorios y aplicaciones críticas, y limpiar lo que sobra.
- Revisar a mano los grupos privilegiados y documentar quién está y por qué.
- Asignar un responsable a cada cuenta de servicio.
- Correr una revisión de accesos acotada a las aplicaciones críticas y guardar la evidencia de lo que se quitó.
- Documentar lo que todavía no está resuelto con un plan de acción y fechas. Un hallazgo con plan se defiende mucho mejor que uno escondido.
Si la auditoría es dentro de un año, la conversación es otra: ahí sí vale la pena pensar en centralizar la gestión de identidades, automatizar altas y bajas desde RR.HH. y dejar que la evidencia se genere sola como parte del proceso.
La auditoría como consecuencia
Lo que más me gusta de este trabajo es cuando una organización deja de "prepararse para la auditoría" y la auditoría pasa a ser una consecuencia de cómo trabaja. Cuando los accesos tienen una razón de ser, las bajas se procesan solas y las revisiones se hacen en serio, la evidencia ya está. El auditor pide una muestra y se la das.
Y lo más importante: la organización queda más segura de verdad, no solo certificada.