Registros de acceso y de cambios de políticas

Los cambios sobre identidades y permisos quedan como eventos de gestión con nombres reconocibles: CreatePolicyVersion (una política administrada tiene versiones y crear una nueva con el parámetro setAsDefault=true la hace efectiva de inmediato), AttachRolePolicy (adjuntar una política a un rol), UpdateAssumeRolePolicy (cambiar quién puede asumir el rol). Poner un límite de permisos y quitarlo también tienen cada uno su propio evento.

Abre el extracto y la guía de lectura.

ls registros
cat registros/como-leer-el-registro.txt
cat registros/eventos-iam.log

Un límite de permisos se pone y se quita con eventos distintos. Quitarlo no cambia ninguna política: solo elimina el techo, y todo lo que sus políticas ya concedían queda efectivo. Por eso un evento de quitar un límite, seguido de otro de adjuntar una política amplia, es una secuencia que merece mirarse.

Busca en el registro el evento que quitó el límite del rol de análisis de datos.

grep -i boundary registros/eventos-iam.log

El registro prueba que un cambio ocurrió, no que estuviera autorizado. Para eso está la lista de cambios aprobados: cada cambio de permisos debería tener un ticket con su responsable y su fecha. Se cruzan las dos fuentes por usuario y por fecha: los cambios sin ticket son los que hay que preguntar.

Cruza los usuarios del registro que cambiaron permisos con los responsables de los tickets.

cat registros/cambios-aprobados.csv
grep -E "Policy|Boundary|AccessKey" registros/eventos-iam.log

El tiempo entre eventos cuenta una historia. Una secuencia de pocos minutos, de madrugada y desde una dirección nueva, no se parece a un cambio planificado en horas de oficina. Las horas del registro están en UTC y con segundos; se restan sin convertir nada, porque los dos eventos usan la misma referencia.

Calcula los minutos entre el evento que quitó el límite y el que adjuntó la política de administración total.

El registro dice qué cambió, quién lo hizo con qué credencial y desde qué dirección. No dice por qué, ni si quien aparece es de verdad la persona: pudo ser su cuenta con una sesión robada, un descuido o una tarea legítima mal documentada. La conducta de quien revisa es contrastar con la persona y con el ticket, con autorización, antes de afirmar nada, y proponer contención si hay riesgo: sesión en revisión, llaves desactivadas, límite restituido.