Certificación de accesos: campañas de revisión que no sean un clic a ciegas

Cuatrocientos elementos en noventa segundos

El último día de una campaña de revisión trimestral, una directora de ventas abre el enlace que lleva dos semanas ignorando. Sus doce reportes directos tienen unos 400 entitlements entre todos. La pantalla muestra nombres, códigos como SFDC_PS_EXP_02 y un botón de “Aprobar todo”. Lo pulsa, la campaña aparece completada al 100% y ella vuelve a su pronóstico de ventas. Dos de sus reportes cambiaron de equipo en primavera y siguen teniendo acceso de sus puestos anteriores, que nadie quitó porque el cambio ocurrió entre dos campañas. Uno de los códigos que aprobó le permite a quien lo tiene exportar toda la lista de clientes.

Esa es la forma más común en que falla la certificación de accesos, y falla pareciendo un éxito completo en todos los reportes. El artículo anterior trató la puerta de entrada, cómo entra el acceso caso por caso mediante una solicitud gobernada con aprobaciones, verificaciones y fecha de fin. Junto con el proceso de altas, traslados y bajas, las solicitudes deciden qué acceso debería recibir la gente. Ninguno de los dos puede prometer qué acceso sigue teniendo la gente seis meses después.

Esa brecha existe en toda organización, por buena que sea su puerta de entrada. El acceso viejo de alguien que se trasladó sobrevivió porque el paso de retiro falló en silencio en un sistema heredado. Nunca se puso una fecha de fin porque el entitlement es anterior al proceso de solicitudes. Un administrador otorgó algo directamente durante una caída. Un rol sumó sin ruido un entitlement que la mitad de sus miembros no necesita. Nada de eso aparece si nadie lo busca, y cuanto más tiempo pasa sin que nadie lo busque, más hay.

La certificación de accesos, también llamada recertificación, atestación o revisión de accesos de usuarios, es esa búsqueda. Una persona responsable revisa un conjunto de accesos existentes y confirma, elemento por elemento, si cada uno sigue siendo apropiado. Lo que se confirma se queda; lo que no, se quita. Bien hecha, es la principal defensa contra la acumulación de privilegios, ese acceso que se va juntando, que cada otorgamiento justificó y que nadie devolvió. Mal hecha, son los noventa segundos de la directora de ventas, repetidos en toda la empresa cada trimestre. Los auditores la prueban más que casi cualquier otro control de IGA, porque es la que muestra si los demás funcionan, y la diferencia entre los dos resultados es casi por completo de diseño.

Qué es una campaña

La certificación suele organizarse en campañas: una revisión definida, con un alcance, un grupo de revisores, una fecha límite y un paso de remediación. Toda campaña responde cuatro preguntas de diseño, y casi todos los fallos se remontan a haber respondido una de ellas a la ligera. ¿Qué entra en el alcance: qué personas, aplicaciones y entitlements? ¿Quién revisa cada elemento, y está en condiciones de saber? ¿Qué ve quien revisa junto a cada elemento? ¿Y qué pasa con una decisión de revocar, y cómo sabemos que ocurrió?

flowchart TD
  accTitle: La vida de una campaña de certificación de accesos
  accDescr: Una campaña empieza armando su alcance a partir del estado actual del acceso, filtrado por nivel de riesgo y aplicación. Cada elemento va a un revisor, una jefatura o el owner de un entitlement, que ve contexto como el último uso, la fecha en que se otorgó y la comparación con sus pares. Quien revisa aprueba o revoca cada elemento. Las revocaciones se ejecutan en los sistemas destino mediante conectores o tareas manuales. Después, la reconciliación confirma que el acceso ya no está, y solo entonces la campaña se cierra y se guarda como evidencia de auditoría.
  SC[Armar el alcance<br/>desde el acceso actual] --> RV[Enviar elementos<br/>a quien revisa]
  RV --> DC[Quien revisa decide<br/>con contexto]
  DC -->|Aprobar| EV[Registrar la decisión]
  DC -->|Revocar| RM[Ejecutar el retiro]
  RM --> RC[La reconciliación<br/>confirma el retiro]
  RC --> EV
  EV --> CL[Cerrar la campaña<br/>guardar la evidencia]

Elegir quién revisa

La decisión con más consecuencias es quién revisa qué, porque quien no está en condiciones de saber aprueba por defecto. Hay cuatro tipos de campaña habituales, y cada uno pone un tipo distinto de conocimiento frente a la decisión.

Las jefaturas conocen a las personas. La directora de ventas sabe que dos de sus reportes cambiaron de equipo en primavera, que una ahora lleva las cuentas clave, que el contrato de un contratista terminó el mes pasado. Lo que muchas veces no sabe es qué permite SFDC_PS_EXP_02, ni si es riesgoso. Las revisiones por jefatura dan una cobertura amplia y son más débiles justo donde el acceso es más técnico.

Los owners conocen el acceso. El owner del CRM sabe con exactitud qué otorga cada conjunto de permisos y cuáles permiten exportar datos de clientes, pero probablemente no sabe si un vendedor concreto de una región lejana los sigue necesitando. Las revisiones por owner son más fuertes en los entitlements de alto riesgo, donde entender el acceso importa más que conocer a la persona, y son el lugar natural de los niveles de riesgo y de la titularidad del artículo del catálogo de entitlements.

Las revisiones del contenido de un rol certifican la definición, no a los miembros. Todos los miembros de un rol pueden necesitar el rol de verdad mientras el rol mismo sumó en silencio un entitlement que nadie dentro debería tener. Revisar la pertenencia nunca lo detectará; solo preguntarle al owner del rol si sigue siendo el paquete correcto lo hará. El próximo artículo, sobre ingeniería de roles, trata esa revisión en detalle.

Las revisiones de cuentas cubren lo que no corresponde a una persona con jefatura: cuentas de servicio, claves de API registradas como identidades, buzones compartidos, cuentas técnicas de administración. En un programa que solo hace revisiones por jefatura, se quedan completamente fuera, porque no hay jefatura a la que enviarlas. Además aparecen de más en los análisis posteriores a una brecha. Toda cuenta no humana necesita un owner humano con nombre, como sostuvo el artículo del modelo de datos, y ese owner es quien la revisa.

Los programas maduros combinan los cuatro según el riesgo: revisiones por jefatura para el acceso estándar, por owner (a veces además de la jefatura) para el elevado y el privilegiado, revisiones del contenido de los roles con su propio calendario y revisiones de cuentas para cada identidad no humana. La pregunta nunca es qué tipo es mejor, sino quién sabe lo suficiente para tomar esta decisión concreta. Y en todos los tipos, nadie revisa su propio acceso, ni un acceso del que depende su propio trabajo. Una jefatura que revisa sus propios entitlements, o un administrador que certifica el grupo de administración al que pertenece, no es una revisión; esos elementos deberían ir solos al nivel de arriba o a un owner independiente.

Alcance y frecuencia según el riesgo

La razón más común por la que la certificación se vuelve un sello de goma no es la pereza. Es el volumen. A la directora de ventas le pidieron 400 decisiones; una jefatura con doce reportes que tienen ochenta entitlements cada uno se enfrenta a casi mil. Nadie toma mil decisiones cuidadosas en una tarde. Toma unas pocas y aprueba el resto.

Reducir ese volumen sin reducir el control es la palanca principal del diseño de una campaña, y los niveles de riesgo son la forma de accionarla.

La última fila importa. El acceso que recibe toda una población de forma automática, el correo, la intranet, la herramienta de gastos, no necesita que una jefatura lo confirme para cada persona cada año; si la persona sigue en la población, el acceso es correcto por definición. Dejarlo fuera de la revisión por elemento quita una buena parte del volumen sin costo real, y lleva el gobierno de ese acceso a donde corresponde: revisar las propias reglas de birthright y asegurarse de que se retire a quienes se van.

Las regulaciones a veces fijan mínimos. Los sistemas con impacto financiero dentro del alcance de SOX suelen revisarse cada trimestre, y PCI DSS exige revisar las cuentas de usuario y sus privilegios al menos cada seis meses. Son pisos para sistemas concretos, no una razón para revisarlo todo con la frecuencia más alta.

Lo que ve quien revisa

Si le das a quien revisa nombres y códigos, diseñaste una campaña que solo puede aprobarse como sello de goma, porque no hay con qué decidir. La mayor mejora que puede hacer casi cualquier programa no es un tipo de campaña nuevo ni una frecuencia nueva. Es poner el contexto adecuado junto a cada decisión.

Lo primero es una descripción legible: el nombre en lenguaje claro del catálogo en lugar de SFDC_PS_EXP_02. Si el trabajo de catálogo del primer módulo no se hizo, quien revisa está revisando cadenas de texto. Lo siguiente es el último uso, cuando el sistema puede informarlo; un entitlement sin usar en 200 días es una decisión mucho más fácil que uno usado esta mañana. También importa cómo y cuándo se otorgó el acceso: por un rol, por birthright, por una solicitud aprobada con su justificación o sin ningún registro. El acceso sin un origen gobernado merece la mirada más dura.

El nivel de riesgo y las alertas de conflicto muestran si un elemento es privilegiado y si forma una combinación peligrosa conocida con algo más que tiene la persona. La comparación con los pares muestra si la gente con el mismo puesto y la misma área tiene el mismo entitlement; algo que tiene una persona de cuarenta no está necesariamente mal, pero es lo primero que hay que mirar. Y resaltar lo que cambió desde la última revisión permite concentrarse en la diferencia en lugar de releer cada trimestre el mismo acceso estable.

El orden importa tanto como el contenido. Arriba van las decisiones que importan: acceso privilegiado, conflictos, acceso sin uso, acceso sin origen gobernado, casos atípicos frente a los pares. El acceso estándar estable, usado hace poco y basado en roles va abajo. Así, quien se quede sin atención se quedará sin ella en los elementos de bajo riesgo y no en los importantes. Si la pantalla de la directora de ventas hubiera empezado con “Exportar todos los contactos de clientes, sin uso hace 140 días, lo tiene 1 de 31 pares”, bien podría haberse detenido.

Las decisiones que puede tomar quien revisa

En su forma más simple, cada elemento recibe una de dos respuestas: aprobar, el acceso sigue siendo apropiado, o revocar, ya no lo es. Las campañas reales necesitan algunas opciones más, cada una diseñada con intención.

Reasignar envía el elemento a otra persona cuando quien revisa de verdad no puede juzgarlo, por ejemplo una jefatura que heredó el equipo la semana pasada. Debería exigir un motivo y no debería servir para pasarse los elementos difíciles hasta que venza el plazo. Aprobar con fecha de fin mantiene el acceso por ahora pero lo convierte de permanente en temporal, a menudo la respuesta más honesta para un acceso que “seguramente hace falta hasta que termine el proyecto”; conecta la revisión con la disciplina de fechas de fin del artículo de solicitud de acceso. Y “no lo sé” debería existir, y nunca debería convertirse en silencio en aprobar. Un elemento que quien revisa no puede juzgar sube un nivel o va al owner del entitlement.

Algunos programas suman revocar por defecto para categorías concretas: si un entitlement privilegiado no se usó en 90 días y quien revisa no lo aprueba de forma explícita, se quita al cerrar la campaña. Eso invierte la carga de la prueba para el acceso más riesgoso. Funciona mejor cuando se avisa con claridad a los revisores de antemano y cuando el retiro es fácil de revertir con una solicitud normal, para que un retiro equivocado cueste una demora corta y no una caída del servicio.

Una decisión no es un retiro

Una decisión de revocar es una decisión. Mientras el acceso no desaparezca de verdad del sistema destino, nada cambió. La remediación es el paso que la mayoría de las campañas trata como un detalle y el que más duramente prueban los auditores.

Las revocaciones pasan por los mismos caminos que la ejecución de las solicitudes, de forma automática con un conector o manual con una tarea para un administrador, y fallan de las mismas maneras. Los conectores dan error, las tareas se cierran sin hacerse, el acceso se quita de un sistema pero no del permiso idéntico en otro. El control que cierra la brecha también es el mismo: la reconciliación lee el sistema destino después de la remediación y confirma que el acceso ya no está.

Una campaña no debería contar como completa cuando el último revisor pulsa enviar. Está completa cuando cada decisión de revocar está confirmada por la reconciliación, y su registro debería mostrar decidido, ejecutado y confirmado como tres estados distintos. Fija un plazo explícito para ejecutar las revocaciones, como cinco días hábiles para el acceso estándar y uno para el privilegiado, y repórtalo. Una decisión de revocar que pasa dos meses sin ejecutarse significa que el acceso siguió ahí dos meses después de que alguien decidiera que no debía estar, y un auditor lo tratará, con razón, como un fallo del control.

Llevar adelante la campaña

Una campaña bien diseñada puede fallar igual al ejecutarse, casi siempre porque se pasa de la fecha límite mientras los revisores la ignoran, como hizo la directora de ventas durante dos semanas. La mecánica merece tanto diseño como el alcance.

Avísala antes de empezar. Quien recibe de improviso un correo con 300 elementos lo trata como ruido. Una nota corta una semana antes, qué cubre, por qué importa, cuánto debería llevar, dónde pedir ayuda, mejora de forma medible la finalización y la calidad de las decisiones. A quien revisa por primera vez, cinco minutos recorriendo la pantalla de revisión le quitan el motivo más común para aprobar en bloque: no saber qué significan los botones.

Ajusta la ventana al trabajo. Dos semanas es un valor habitual para las revisiones por jefatura; las revisiones por owner de poblaciones grandes pueden necesitar más. Una ventana demasiado corta empuja a aprobar todo para terminar a tiempo; una demasiado larga deja que la campaña se caiga de la lista de todos.

Recuerda, luego escala, luego decide. Un ritmo habitual es un recordatorio a mitad de plazo y otro dos días antes de la fecha límite, escalar a la jefatura de quien revisa al vencer el plazo y un resultado definido para lo que siga sin decidir después de eso. Elige ese resultado de forma explícita y déjalo por escrito. En el acceso privilegiado, sin decidir suele significar revocar; en el estándar, algunos programas extienden una vez y luego revocan. Nunca debería significar mantener, porque eso convierte no participar en aprobar, el equivalente en revisión a una solicitud que se aprueba sola cuando nadie responde.

Míralo mientras corre. Quien es dueño de la campaña necesita una vista en vivo del avance por revisor y por nivel de riesgo, para ir detrás de los pocos que no empezaron en lugar de descubrir en la fecha límite que la parte privilegiada está a un tercio.

Eliminar por diseño el sello de goma

Aprobar todo sin una evaluación real es el fallo característico de la certificación, y casi nunca es un defecto de carácter de quien revisa. Es el resultado previsible de pedirle a la gente demasiadas decisiones con muy poca información, y las soluciones son estructurales.

Achica el volumen dejando fuera el acceso birthright, revisando por excepción el acceso estándar estable y concentrando la revisión por elemento en el acceso elevado y privilegiado; aquí rinde el trabajo de granularidad del catálogo, cuando doscientos casi duplicados se convierten en veinte entitlements con sentido. Suma el contexto descrito antes, que convierte una decisión imposible en una obvia para la mayoría de los elementos. Mira el patrón: los tiempos de decisión y las tasas de aprobación por revisor muestran quién aprobó 400 elementos en noventa segundos, o quién no revocó nada en cuatro campañas. Algunos programas llegan a insertar un elemento claramente inapropiado, un acceso que una identidad de prueba no debería tener, para ver si quien revisa está leyendo; es polémico, pero mide la atención de forma directa.

Haz que aprobar todo sea más difícil que revisar. Desactivar la aprobación en bloque para los elementos privilegiados, o pedir un comentario al aprobar un acceso sin uso hace meses, suma un poco de fricción justo donde una decisión descuidada cuesta más. Y divide la revisión. Las revisiones chicas y concentradas, de diez o veinte elementos, enviadas cerca de un hecho relevante, reciben mucha más atención por elemento que una campaña enorme cada trimestre. Esa es la idea detrás de la certificación disparada por eventos.

De las campañas trimestrales a las revisiones disparadas por eventos

El modelo tradicional, en el que cada jefatura revisa todo el acceso de sus reportes cada trimestre, tiene una debilidad estructural: está desconectado del momento en que el acceso se vuelve realmente inapropiado. El acceso viejo de alguien que se traslada se vuelve sospechoso el día del traslado, no el primer día del trimestre siguiente, y mientras tanto sigue ahí hasta tres meses. Los dos vendedores que cambiaron de equipo en primavera son exactamente ese caso.

La certificación disparada por eventos, a menudo llamada certificación continua, cierra la brecha disparando revisiones chicas y dirigidas cuando pasa algo que pone en duda un acceso concreto. Un cambio de jefatura o de área le envía a la nueva jefatura solo el acceso que la persona arrastró. Un periodo largo sin uso envía un entitlement elevado a su owner para que lo confirme o lo quite. Un caso atípico frente a los pares dispara la revisión de ese único elemento. Una alerta de seguridad, una violación de política o un conflicto detectado después disparan la revisión inmediata del acceso relacionado. Y si sube el nivel de riesgo de un entitlement, todos sus titulares se revisan con el estándar más estricto.

sequenceDiagram
  accTitle: Una revisión disparada por el traslado de alguien a otro equipo
  accDescr: El sistema de RR. HH. registra que una persona pasó a otra área. La plataforma de IGA detecta el traslado e identifica el acceso que la persona arrastró de su puesto anterior. Le envía a la nueva jefatura una revisión chica y dirigida solo de ese acceso. La nueva jefatura mantiene lo que sigue haciendo falta y revoca el resto. La plataforma ejecuta las revocaciones en los sistemas destino y la reconciliación confirma que el acceso se quitó, días después del traslado y no en la siguiente campaña trimestral.
  participant HR as Sistema de RR. HH.
  participant IGA as Plataforma de IGA
  participant NM as Nueva jefatura
  participant T as Sistemas destino
  HR->>IGA: Traslado a otra área
  IGA->>IGA: Buscar el acceso arrastrado del puesto anterior
  IGA->>NM: Revisar 12 elementos arrastrados
  NM-->>IGA: Mantener 3, revocar 9
  IGA->>T: Ejecutar 9 revocaciones
  T-->>IGA: La reconciliación confirma el retiro

Las revisiones por eventos no suelen reemplazar del todo a las campañas programadas; auditores y regulaciones siguen esperando una revisión periódica y completa de los sistemas dentro del alcance. Lo que cambia es el papel de la campaña programada. En lugar de ser el único mecanismo que atrapa el acceso inapropiado, pasa a ser el respaldo que comprueba que no se escapó nada. Como casi todos los problemas ya se resolvieron cerca del hecho, la campaña programada es más chica y quienes revisan tienen más atención para lo que queda. La analítica detrás de disparadores como los casos atípicos frente a los pares y las puntuaciones de riesgo tiene su propio artículo más adelante en este dominio.

Lo que prueba un auditor

En muchas organizaciones la certificación existe primero porque la exige un auditor, por los controles generales de TI de SOX, SOC 2, PCI DSS o HIPAA. Es una razón perfectamente válida, siempre que las campañas se diseñen para producir evidencia que aguante y no solo una tasa de finalización.

Cuando los auditores prueban la certificación, suelen muestrear campañas y elementos sueltos. Quieren ver que el alcance fue completo, armado a partir del estado real de los sistemas dentro del alcance y no de una lista que alguien mantiene a mano. Quieren que quien revisó tuviera la autoridad y el conocimiento para decidir, y que no estuviera revisando su propio acceso. Quieren que la campaña corriera según lo previsto y terminara dentro de su plazo. Quieren el rastro de las decisiones, quién decidió qué, cuándo, con qué comentario. Y en las revocaciones de la muestra, quieren evidencia de que el acceso se quitó de verdad, y cuándo.

Ese último punto es donde más fallan los programas. Una campaña con cincuenta decisiones de revocar y ninguna prueba de que se ejecutaran es, para un auditor, una campaña que encontró cincuenta problemas y no arregló ninguno. El estado confirmado descrito antes es lo que convierte un registro de decisiones en evidencia. Y el 100% de finalización de la directora de ventas, con cero revocaciones y noventa segundos de aprobación, es justo el patrón del que un auditor con experiencia sacará una muestra.

Ejemplo trabajado: la primera campaña de verdad de una fintech regulada

Una fintech de unas 600 personas procesa pagos con tarjeta, lo que la pone dentro del alcance de PCI DSS, y se prepara para su primera auditoría SOC 2 Tipo II. Las revisiones de acceso han sido un ejercicio anual con hojas de cálculo: TI exporta listas de usuarios, las envía por correo a las jefaturas y recoge las respuestas. Al programa de IGA le piden reemplazarlo con una campaña de verdad.

La primera campaña cubre los seis sistemas dentro del alcance de PCI DSS y SOC 2: la plataforma de pagos, el entorno cloud de producción, la consola de atención al cliente, el data warehouse con datos de transacciones, el proveedor de identidad y el repositorio de código. Se deja fuera el acceso birthright, y quedan unas 9.000 asignaciones. El acceso privilegiado de los seis sistemas, unas 400 asignaciones, va a los owners de los entitlements; todo lo demás va a las jefaturas. Las 140 cuentas de servicio van a sus owners técnicos registrados, y la revisión descubre que 31 no tienen ningún owner registrado, lo que se convierte en una línea de trabajo propia. Cada elemento muestra el último uso, el origen del otorgamiento, el nivel de riesgo y una alerta de pares, ordenado con los privilegiados primero, después los sin uso y después los que no tienen origen gobernado.

La campaña dura dos semanas. Los owners revocan el 18% de las asignaciones privilegiadas, la mayoría sin uso desde hacía más de 90 días. Las jefaturas revocan el 6% del resto. La analítica de revisores señala a cuatro jefaturas que aprobaron todo en menos de dos minutos; sus elementos pasan a los owners de los entitlements para una segunda mirada, y los owners revocan otras 70 asignaciones.

Las revocaciones de los cuatro sistemas conectados se completan solas en un día. El data warehouse y la consola de atención necesitan tareas manuales, y la reconciliación de una semana después encuentra que 22 no se hicieron; se escalan y se completan. El registro de la campaña muestra el alcance generado a partir del estado de los sistemas, cada decisión con su revisor y su hora y la confirmación por reconciliación de cada revocación, el paquete que muestreará el auditor de SOC 2. Las 31 cuentas de servicio sin owner y las 22 revocaciones manuales fallidas se convierten en hallazgos documentados con planes de remediación, que los auditores suelen mirar con mucha más benevolencia que los problemas que nadie encontró.

Un segundo ejemplo: cuentas de servicio sin jefatura

Un caso más chico aísla la población más difícil. Una empresa de logística solo hace revisiones por jefatura, y una comprobación previa a la auditoría revela que sus 260 cuentas de servicio nunca se revisaron, porque ninguna tiene jefatura en los datos de RR. HH.

La solución empieza por la titularidad, no por una campaña. Cada cuenta de servicio se asocia al equipo de aplicación que la usa y se registra un owner técnico con nombre. Las cuentas que nadie reclama después de dos rondas de consultas se deshabilitan durante 30 días, sin borrarse, y solo se reactivan si algo se rompe y aparece un owner. Se reactivan once; el resto se borra al cerrar el plazo.

Desde entonces corre una revisión de cuentas cada seis meses, enviada a cada owner con la última autenticación y la antigüedad de la credencial como contexto. La primera quita permisos de más a 40 cuentas, casi todas creadas con amplios derechos de administrador “para que funcione” y nunca recortadas. La misma revisión encuentra además nueve cuentas cuyas credenciales no se rotaban desde hacía más de tres años, que van a seguridad como hallazgo aparte, porque una revisión de cuentas suele ser la primera vez que alguien mira las credenciales de una cuenta de servicio.

Cómo falla la certificación

Revisar todo, siempre, con la misma frecuencia garantiza el cansancio y el sello de goma; define el alcance según el riesgo. Pedirle a la gente que revise lo que no puede entender convierte cada decisión en una suposición, y las suposiciones tienden a aprobar, así que arregla el catálogo antes de culpar a quien revisa. Tratar la finalización como éxito esconde el fallo: un 100% a tiempo sin ninguna revocación, como en la campaña de la directora de ventas, sugiere con fuerza que no se revisó nada. Detenerse en la decisión, con revocaciones que nunca se ejecutan o nunca se confirman, deja la campaña sin valor como evidencia y como control. Olvidar las cuentas sin jefatura deja las cuentas de servicio y compartidas fuera de toda revisión. Y armar el alcance a mano, con una lista que alguien mantiene en lugar de con los propios sistemas, garantiza que la campaña se pierda justo el acceso otorgado por fuera del proceso, que es el que más necesita revisión.

Medir si funciona

Unas pocas medidas muestran si la certificación es un control de verdad. La tasa de finalización a tiempo muestra si las revisiones ocurren según lo previsto, aunque por sí sola prueba poco. La tasa de revocación, por campaña y por nivel de riesgo, muestra si las revisiones encuentran algo; cerca de cero durante varios ciclos sugiere un sello de goma. El tiempo mediano por decisión muestra si quien revisa está leyendo. El tiempo de remediación y la proporción de revocaciones confirmadas muestran si las decisiones se convierten en retiros. Los hallazgos repetidos, un acceso revocado en una campaña que vuelve a aparecer en la siguiente, muestran si la puerta de entrada pierde. Y la proporción de acceso revisado por eventos muestra el avance hacia la certificación continua.

Una tendencia sana suele verse como una tasa de revocación alta en las primeras campañas, mientras se limpia lo acumulado, que se estabiliza en un nivel más bajo pero distinto de cero a medida que las solicitudes, las fechas de fin y las revisiones por eventos frenan la acumulación desde el origen. Una tasa de revocación de cero desde el primer día no significa que la organización tuviera un acceso perfecto. Significa que nadie miró.

Cómo se relaciona con los estándares

La certificación es de los controles de IGA exigidos de forma más explícita:

• NIST SP 800-53 Rev. 5, control AC-2 (Account Management), exige revisar las cuentas con una frecuencia definida por la organización, y AC-6(7) exige revisar los privilegios asignados a roles y usuarios para confirmar que siguen haciendo falta.
• PCI DSS v4.0, Requisito 7.2.4, exige revisar todas las cuentas de usuario y sus privilegios al menos cada seis meses, actuando sobre los resultados y documentándolos.
• Criterios de SOC 2 (Trust Services Criteria), CC6.2 y CC6.3, esperan que el acceso se revise de forma periódica y se quite cuando deja de ser apropiado; los auditores lo prueban muestreando campañas.
• La regla de seguridad de HIPAA, §164.308(a)(4), exige la gestión del acceso a la información, incluida la revisión y modificación del derecho de acceso de un usuario.
• Los controles generales de TI de SOX, evaluados bajo los estándares de auditoría del PCAOB, incluyen de forma habitual revisiones periódicas del acceso a los sistemas con impacto financiero.
• ISO/IEC 27001:2022, control del Anexo A 5.18 (Derechos de acceso), exige revisar los derechos de acceso a intervalos regulares.

Cerrando el ciclo

Las solicitudes y JML deciden qué acceso debería tener la gente. La certificación comprueba si la realidad sigue coincidiendo con esa decisión y la corrige cuando no. Eso la convierte en el lugar donde cada pieza anterior de este dominio aparece como dependencia: el registro de identidad para saber a quién está mirando quien revisa, el catálogo para que cada entitlement sea legible y tenga owner, JML y la solicitud de acceso para registrar de dónde salió cada asignación, y los roles del programa para saber quién responde cuando una campaña falla. Con todo eso en su sitio, la pantalla de la directora de ventas le habría mostrado una docena de elementos que merecían su atención en lugar de 400 que no podía leer.

Resumen

• La certificación de accesos es un control detectivo: personas responsables confirman de forma periódica que el acceso existente sigue siendo apropiado, y lo que no lo es se quita.
• Elige a quien revisa según lo que sabe: las jefaturas conocen a las personas, los owners conocen el acceso, los owners de roles conocen el contenido de un rol y cada cuenta no humana necesita un owner con nombre que la revise. Nadie revisa su propio acceso.
• El alcance y la frecuencia siguen al riesgo: el acceso privilegiado cada trimestre más eventos, el elevado dos veces al año, el estándar una vez al año o por excepción y el birthright gobernado con sus reglas.
• El contexto es el control: entitlements legibles, último uso, origen del otorgamiento, alertas de riesgo y comparación con los pares, ordenados para que lo importante vaya primero.
• Una decisión de revocar no es un retiro hasta que la reconciliación lo confirma, y esa confirmación es lo que prueba un auditor.
• Las revisiones por eventos atrapan el acceso cerca del momento en que se vuelve sospechoso; la campaña programada pasa a ser el respaldo.
• Lleva las campañas con intención: avísalas, ajusta la ventana, recuerda y escala, y decide de antemano que lo que quede sin decidir nunca se mantiene sin más.

Tres preguntas para ponerte a prueba

1. Una campaña de revisión por jefatura termina con un 100% de finalización a tiempo y una tasa de revocación del 0,2%. Enumera tres cosas que comprobarías antes de concluir que el acceso de la organización está en buen estado.
2. ¿Por qué el owner de un entitlement revisa mejor que una jefatura el acceso de administrador de producción, y por qué la jefatura podría seguir siendo útil en la misma revisión?
3. Explica por qué una campaña cuyo alcance sale de una lista que mantiene el equipo de IAM, y no del estado real de los sistemas destino, se perderá de forma sistemática el acceso más riesgoso.

Ejercicio práctico

Diseña un programa de certificación para un sistema que conozcas, o para la fintech del ejemplo.

1. Divide su acceso en niveles de riesgo y asigna a cada nivel un tipo de campaña, quién revisa y una frecuencia. Decide qué acceso dejarás fuera de la revisión por elemento y por qué.
2. Enumera el contexto que mostrarías junto a cada elemento y el orden en que los ordenarías.
3. Define dos hechos que deberían disparar una revisión dirigida fuera de la campaña programada.
4. Fija plazos para ejecutar las revocaciones y describe cómo le demostrarías a un auditor que una revocación de la muestra ocurrió de verdad.