Tablas y esquema de Log Analytics

Un espacio de trabajo de Log Analytics es un almacén de registros organizado en tablas. Cada tabla guarda un tipo de registro y tiene columnas con nombre y tipo. Una consulta en KQL empieza por el nombre de una tabla y cada paso siguiente va detrás de una barra vertical |, de modo que los datos fluyen de izquierda a derecha, igual que en una tubería.

Para un defensor, cuatro tablas dan casi toda la primera vista de un incidente en Azure: SigninLogs (los intentos de inicio de sesión de Entra), AuditLogs (los cambios en el directorio de Entra, como altas de usuarios o de roles), AzureActivity (las operaciones de gestión sobre los recursos de la suscripción) y SecurityAlert (las alertas que escriben los productos de seguridad). Fíjate en el panel de la izquierda: están las cuatro, con sus columnas.

Dos operadores sirven para conocer una tabla sin leerla entera. take 5 devuelve cinco filas cualesquiera: sirve para ver cómo luce, no para concluir nada, porque no garantiza cuáles trae. count devuelve una sola fila con el número de filas que llegan hasta ese paso. Saber cuántas filas hay es lo primero que se pregunta antes de decidir si una consulta cabe o hay que acotarla.

Prueba en la consola SigninLogs | take 5 y luego SigninLogs | count. La columna TimeGenerated, de tipo datetime, es la hora (en UTC) en que se creó el registro y es la columna por la que casi siempre se acota el tiempo.

No hace falta memorizar las columnas de cada tabla. getschema no devuelve datos: devuelve una fila por columna, con su nombre (ColumnName), su posición contada desde cero (ColumnOrdinal) y su tipo (ColumnType). Es la forma de saber, antes de comparar, si una columna es texto, número, fecha u objeto.

El tipo importa porque KQL compara cada valor con su propio tipo. Una columna de texto se compara con texto entre comillas; una fecha con una fecha. Mirar el tipo antes de filtrar evita consultas que no devuelven nada por un detalle de forma.

Cada tabla responde a un tipo de pregunta. «Quién entró» está en SigninLogs; «quién cambió un rol o creó un usuario en el directorio» en AuditLogs; «quién creó, cambió o borró un recurso de Azure» en AzureActivity; «qué alertas se recibieron» en SecurityAlert. Por eso una investigación casi siempre toca varias tablas, y la siguiente sala empieza a filtrar una de ellas.

Un detalle de lectura: InitiatedBy y TargetResources de AuditLogs son de tipo dynamic, es decir, guardan un objeto con campos dentro, no un texto plano. Se leen entrando al objeto con un punto, y se verá más adelante.