Registros de auditoría de administración y de datos

Los registros de Admin Activity anotan las operaciones que cambian la configuración o los metadatos de un recurso: crear una máquina, cambiar una política, crear una llave. Siempre se escriben, no se pueden desactivar ni excluir, y viven en el depósito _Required, que conserva 400 días sin posibilidad de cambiarlo. Los de System Event son parecidos, pero los genera Google y no una persona.

Los registros de Data Access anotan quién leyó o escribió datos de usuario. Vienen apagados por defecto (salvo en BigQuery), porque generan mucho volumen, y caen en el depósito _Default, de 30 días en un proyecto salvo que alguien lo cambie. Policy Denied anota las denegaciones por política, también en _Default.

Una entrada de auditoría dice quién (principal), qué (metodo), sobre qué (recurso), desde dónde (ip) y con qué resultado. El principal puede ser una persona o una cuenta de servicio, y estas últimas terminan en iam.gserviceaccount.com.

Empieza por las entradas del sábado 14 de agosto y busca el método que crea instancias.

No toda entrada es una máquina creada. Un intento puede fallar por cuota, y una política de la organización puede denegarlo: ambos quedan escritos, pero no dejan ninguna máquina. Contar entradas sin mirar el resultado infla la cifra que se le dará a la gerencia.

Cuenta las creaciones correctas de instancias hechas por esa cuenta el 14 de agosto. Otra cuenta crea una máquina cada noche desde la oficina y no cuenta.

El bucket mqb-lotes-molienda guarda datos de molienda. Si alguien lo leyó, la huella estaría en Data Access, pero esos registros solo existen donde alguien los activó. La tabla de configuración dice, servicio por servicio, qué está activado.

Con Data Access apagado en Storage, el registro no contiene lecturas de objetos del bucket. Eso no equivale a que nadie leyera: equivale a que, si alguien lo hizo, no hay forma de verlo en esta fuente. Hay que escribirlo con esa precisión y recomendar activar el registro desde ahora.