Auditar la automatización

Un registro de auditoría responde a cuatro preguntas: quién hizo qué, sobre qué, y por qué. En una automatización el «quién» es la identidad con la que corre el playbook, el «qué» es la acción, el «sobre qué» es el objetivo y el «por qué» es el ticket del caso. Si el playbook trabajaba con aprobación, hace falta una quinta pieza: el identificador de la solicitud aprobada, que une la acción con la persona que la autorizó.

Sin ese registro, cuando algo sale mal no se puede reconstruir si fue una orden humana, un disparador defectuoso o un playbook olvidado.

Abre permisos-de-identidades.csv. La política exige que cada playbook corra con los permisos mínimos que necesita. Una identidad de enriquecimiento solo necesita leer; una de contención solo necesita modificar los grupos de seguridad de una cuenta. Si el playbook se equivoca, o si alguien consigue que ejecute lo que no debía, el daño posible lo marca esa lista de permisos.

El playbook de aislamiento está marcado en el inventario como «con aprobacion», y su política dice que cada acción debe llevar el identificador de la solicitud aprobada. Abre registro-de-auditoria.csv y filtra por la identidad de ese playbook. Una acción de contención sin solicitud es una de dos cosas: un fallo de registro o una contención que se saltó la aprobación.

La segunda regla de la política pide un dueño nombrado para cada playbook y una revisión al menos cada 180 días. Un playbook sin dueño no se actualiza, no se retira y, cuando falla, nadie responde. En el inventario, la columna dueno vacía es la señal; la fecha de la última revisión agrava el caso si además pasaron meses.

La tercera regla pide que toda acción que modifique algo deje el ticket del caso. Cada fila del registro sin ticket es una acción sin motivo documentado. Puede ser legítima y estar mal anotada, o puede ser una acción que nadie pidió. Cuéntalas todas, sea cual sea la identidad que las hizo.