Recertificación de acceso AWS: VIGIL ejecuta
La mayoría de las recertificaciones de acceso en AWS mienten. No a propósito, pero mienten. El 28 de mayo de 2026, Paramanand Mallik publicó en dev.to un artículo donde confiesa lo que muchos sabemos y pocos dicen en voz alta: el acceso que revocaste en tu última revisión probablemente sigue activo. Su respuesta al problema es VIGIL, un motor open-source de recertificación de acceso AWS que no solo registra la decisión, también la ejecuta sobre los recursos reales. Sin ticket pendiente, sin sprint futuro, sin brecha entre lo que decís que hiciste y lo que realmente pasa en tu cuenta de AWS.
La recertificación de acceso AWS es el proceso periódico por el cual los dueños de recursos revisan y validan quién debería tener permisos sobre buckets S3, roles IAM y otros servicios. VIGIL automatiza este ciclo completo: descubre recursos etiquetados, consulta al propietario, aplica los cambios directamente sobre las políticas y deja un registro de auditoría verificable. El proyecto está disponible en el repositorio aws-samples de GitHub, con licencia open-source.
Resumen
- El problema es masivo: las herramientas tradicionales de recertificación solo generan un registro de la decisión, sin tocar los permisos reales en AWS. El acceso “revocado” sigue vivo durante meses.
- VIGIL cierra la brecha: automatiza el ciclo completo: descubre, consulta, aplica y audita. La revocación se ejecuta en el mismo paso, no en un ticket aparte.
- Revocación quirúrgica: no despega políticas enteras. Si el acceso viene de una bucket policy, borra solo ese principal o esas acciones específicas. El resto sigue intacto.
- Open-source en aws-samples: el código está disponible en GitHub bajo la organización oficial de AWS, publicado el 28 de mayo de 2026.
- Registro de auditoría completo: cada acción queda documentada para demostrar cumplimiento en auditorías SOX, GDPR o las que te toquen.
¿Por qué las recertificaciones tradicionales no revocan realmente el acceso?
Ponele que tenés un bucket S3 con datos financieros. Hacés la revisión trimestral, el dueño marca “revocar” para tres usuarios que ya no deberían ver esos datos, la herramienta te da un check verde y cerrás el ciclo. Lindo. Dos meses después, esos tres usuarios siguen descargando los reportes como si nada.
El problema es estructural. Según explica Mallik en su artículo, las herramientas de recertificación estándar producen un registro, un PDF, una evidencia de que alguien tomó una decisión. Pero entre esa decisión y el cambio real sobre el recurso hay un abismo: un ticket que alguien tiene que agarrar, priorizar, ejecutar y verificar. Mientras tanto, el riesgo está ahí, vivito y coleando. La herramienta te dijo que hiciste la tarea. La realidad de tu cuenta de AWS dice otra cosa.
¿Y qué pasa con ese ticket? Quizás se ejecuta el próximo trimestre, quizás se pierde en un backlog infinito, quizás el que lo agarra no tiene contexto y prefiere no tocar nada por miedo a romper producción. En cualquiera de esos escenarios, el resultado es el mismo: atestiguaste un estado de acceso que nunca se hizo realidad. Esto se conecta con lo que analizamos en en nuestra comparativa de CI/CD para 2026.
¿Qué hace VIGIL de manera diferente?
VIGIL parte de una premisa simple pero ambiciosa: la decisión y el cambio tienen que ser el mismo paso. Nada de “se aprobó, ahora viene el sprint de implementación”. Si el dueño dice “revocar”, el cambio se aplica en ese momento sobre el recurso vivo, y queda registrado.
Según la documentación del proyecto y fuentes relacionadas, el motor hace cuatro cosas:
- Descubrir recursos por etiqueta: escanea tu cuenta de AWS buscando recursos que tengan ciertos tags y arma un mapa de quién tiene acceso a cada uno. No asume nada, lo resuelve en tiempo real.
- Consultar al dueño del recurso: le presenta la lista de accesos detectados y le da tres opciones: mantener, recortar o eliminar.
- Aplicar la decisión sobre el recurso vivo: esta es la parte que nadie más hace. Si el dueño dice “sacá a tal principal de este bucket”, VIGIL edita la bucket policy y borra solo esa entrada.
- Registrar todo para auditoría: quién decidió qué, cuándo se aplicó, qué cambio se hizo exactamente. Todo trazable.
El proyecto se publicó en el repositorio aws-samples de GitHub, un detalle importante: está bajo el paraguas oficial de AWS, revisado por sus ingenieros, con todo lo que eso implica para la confianza en el código y la mantenibilidad a largo plazo (aunque ojo, es un sample, no un servicio administrado).
¿Cómo descubre VIGIL los recursos y accesos en AWS?
El mecanismo de descubrimiento se apoya en una práctica que muchos equipos ya tienen implementada pero subutilizada: el etiquetado. VIGIL recorre los recursos que coinciden con determinados tags (vos definís cuáles), analiza sus políticas y arma una matriz de accesos efectivos. No consulta un inventario preexistente ni una base secundaria, va directo a IAM, a las bucket policies, a las resource-based policies del servicio que sea.
Imaginá un bucket S3 etiquetado como env=prod y data-classification=confidencial. VIGIL lo encuentra, analiza la bucket policy, identifica que el principal arn:aws:iam::123456789012:user/analista-externo tiene s3:GetObject sobre ese bucket, y se lo muestra al dueño: “¿Este tipo sigue necesitando leer estos datos?”. Si la respuesta es no, se va a producción en el acto. Si es sí, queda registrado que fue revisado y aprobado. Sin grises.
¿Cómo VIGIL aplica las decisiones sin romper otros accesos?
Acá está la parte que más me gusta del diseño. El enfoque vago para revocar el acceso de alguien a un bucket es detacharle las políticas IAM. Chau, perdiste acceso a todo. Eso es como sacarle la llave del edificio a un empleado porque ya no necesita entrar a la cocina: técnicamente funciona, pero el tipo tampoco puede entrar a su oficina, al baño ni a la sala de reuniones. Y ahí armaste un incidente autogenerado mientras intentabas mejorar la seguridad (sí, en serio, pasa más seguido de lo que creés). Más contexto en al elegir entre Jenkins y GitHub Actions.
VIGIL no hace eso. Mallik diseñó lo que él llama scoped enforcement: si el acceso proviene de una bucket policy, edita solo esa política, solo ese principal, solo esas acciones. El resto de los permisos del usuario, los que vienen de otros lados y no fueron cuestionados en la revisión, quedan intactos. Si el acceso viene de un rol asumido, trabaja sobre la trust policy de ese rol. Siempre quirúrgico, nunca con una motosierra.
Este approach es lo que diferencia un proyecto que podés usar en producción de un script que corre solo en entornos de prueba controlados. Si alguna vez tuviste que restaurar accesos a las 3 AM porque alguien ejecutó un aws iam detach-user-policy sin pensar, sabés exactamente de qué estoy hablando.
¿Cómo se audita y demuestra la efectividad de VIGIL?
La mayoría de las recertificaciones que pasan auditoría lo hacen mostrando un Excel o un PDF que dice “el dueño aprobó esto en tal fecha”. El auditor mira el papel, todo bien. Pero si por esas casualidades alguien pide evidencia de que el cambio se aplicó en el recurso, ahí se arma el baile.
VIGIL registra cada acción con cuatro datos: qué decisión se tomó (keep, trim, remove), quién la tomó, cuándo se aplicó el cambio y sobre qué recurso. Ese rastro de auditoría es verificable porque podés ir al recurso, inspeccionar la política y confirmar que efectivamente el principal ya no está. No hay diferencia entre lo que dice el registro y lo que muestra el recurso, porque el mismo motor que registra es el que aplica. Para cumplimiento normativo (SOX, GDPR, regulaciones financieras locales), esto es un golazo: atestiguás un estado que es verdadero en el mismo momento en que lo firmás. Relacionado: implementando hreflang correctamente.
¿Dónde conseguir e implementar VIGIL?
El código está en GitHub, en el repositorio aws-samples/vigil, publicado el 28 de mayo de 2026. Necesitás tener la AWS CLI configurada, permisos IAM para descubrir recursos (lectura sobre las APIs de S3, IAM, y lo que quieras cubrir) y permisos para modificar políticas (esto es lo delicado, obvio).
Para probarlo sin riesgo:
- Arrancá en un entorno de pruebas o en una cuenta sandbox con recursos etiquetados que imiten los de producción. No hagas la gran “bueno, total parece sencillo” y lo tires directo contra prod.
- Definí los tags que va a usar el motor para descubrir recursos. Sin etiquetas consistentes, VIGIL no sabe qué mirar. Si tu estrategia de tagging es un desorden, arreglala antes.
- Limitá los permisos del rol que ejecuta VIGIL para que solo pueda tocar los recursos que querés auditar. Principio de menor privilegio, justamente.
- Revisá las decisiones antes de ejecutarlas en automático las primeras veces. El motor tiene modo de revisión manual antes de aplicar cambios.
| Característica | Recertificación tradicional | VIGIL |
|---|---|---|
| Ejecución de la decisión | Ticket manual post-revisión | Automática en el mismo paso |
| Alcance de la revocación | Generalmente detach de políticas | Quirúrgico: solo el principal/acción específica |
| Registro de auditoría | PDF o Excel desconectado del recurso | Registro verificable contra el recurso vivo |
| Descubrimiento de accesos | Lista estática pregenerada | Escaneo en tiempo real por tags |
| Licencia y despliegue | Herramientas SaaS propietarias | Open-source en aws-samples |
Errores comunes al implementar recertificación de acceso AWS
- Asumir que “marcar como revocado” alcanza. Es el error más frecuente. La herramienta te dio un tilde verde, vos cerrás el ciclo, pero la política del bucket sigue igual. Verificá siempre que el cambio se haya aplicado en el recurso. Con VIGIL no hay que verificar nada porque el mismo motor lo hace, pero si usás otra cosa, auditá el recurso, no el dashboard de la herramienta.
- Revocar accesos despegando políticas completas. Si el usuario pierde acceso al bucket que auditaste pero también pierde acceso a otros 15 recursos que necesita para laburar, armaste un problemón. El scoped enforcement de VIGIL justamente evita esto, pero si estás haciendo recertificación manual, revisá caso por caso.
- No tener una estrategia de tagging coherente. VIGIL depende de tags para descubrir recursos. Si etiquetás unos buckets como
environment=prody otros comoenv=produccion, el motor no los va a agrupar bien. Definí un estándar antes de implementar. Esto aplica a cualquier tooling de automatización en AWS, no solo a VIGIL.
Preguntas Frecuentes
¿Qué es VIGIL y cómo se relaciona con la recertificación de acceso AWS?
VIGIL es un motor open-source de recertificación de acceso AWS que automatiza el ciclo completo: descubre recursos por etiquetas, consulta al dueño del recurso, aplica la decisión directamente sobre las políticas y registra todo para auditoría. El proyecto fue publicado el 28 de mayo de 2026 en el repositorio aws-samples de GitHub por Paramanand Mallik.
¿Cómo saber si mi recertificación de acceso realmente revocó los permisos?
No alcanza con el reporte de la herramienta de recertificación. Tenés que ir al recurso (bucket S3, rol IAM, lo que sea) e inspeccionar la política para confirmar que el principal o las acciones que revocaste ya no figuran. VIGIL elimina esta verificación manual porque el mismo motor que registra la decisión aplica el cambio en el recurso vivo, por lo que el estado real siempre coincide con el registro de auditoría.
¿Cómo revocar accesos AWS automáticamente sin romper otros permisos?
Usando scoped enforcement en lugar de detach de políticas. VIGIL edita únicamente la política donde está el acceso que querés revocar (por ejemplo, una bucket policy) y borra solo ese principal o esas acciones, sin tocar el resto de los permisos del usuario. Esto evita el efecto dominó de sacarle acceso a recursos no auditados y previene incidentes en producción. Tema relacionado: también puedes ejecutar agentes sin API.
¿Dónde está el código de VIGIL y cómo se implementa?
El repositorio está en GitHub bajo la organización aws-samples, con el nombre VIGIL. Para implementarlo necesitás AWS CLI configurada, permisos IAM de lectura sobre los servicios a auditar y permisos de escritura sobre las políticas que querés modificar. Se recomienda probar primero en una cuenta sandbox con recursos etiquetados que reflejen tu entorno real.
¿Cómo auditar la recertificación de accesos en AWS para cumplimiento normativo?
El auditor necesita dos evidencias: la decisión del dueño del recurso y la prueba de que el cambio se aplicó en el recurso vivo. VIGIL produce ambas en el mismo paso, con timestamps, identidad del decisor y detalle del cambio aplicado. Como el motor escribe directamente sobre las políticas, podés contrastar el registro de auditoría con la configuración real del recurso y confirmar que coinciden. Esto cumple con los requisitos de SOX, GDPR y regulaciones similares sobre controles de acceso.
Conclusión
VIGIL resuelve un problema que la industria normalizó por años: la recertificación de acceso como un ejercicio de papeleo que no modifica la realidad de las cuentas AWS. Lo preocupante no es que exista ese gap, lo preocupante es que lo hayamos aceptado como práctica estándar.
El proyecto de Mallik tiene tres aciertos grandes: el scoped enforcement que evita incidentes, la integración de decisión y ejecución en un solo paso, y el hecho de ser open-source bajo el paraguas de AWS. Para equipos que manejan entornos AWS con requisitos de cumplimiento o simplemente con la necesidad de saber quién accede a qué sin mentirse a sí mismos, VIGIL es una herramienta que vale la pena probar. Si tenés los tags en orden y los permisos bien acotados, lo ponés a andar en una tarde.
