Unir inicios de sesión con cambios con join

En AuditLogs, quién hizo el cambio está en InitiatedBy, una columna dynamic que guarda un objeto: {"user":{"userPrincipalName":"...","ipAddress":"..."}}. Para compararla con otra tabla hay que sacar los campos: InitiatedBy.user.userPrincipalName entra al objeto con puntos y tostring(...) lo convierte en texto, que es lo que join necesita para comparar. extend Actor = tostring(InitiatedBy.user.userPrincipalName) crea una columna con la cuenta.

Prueba la consulta que filtra OperationName == "Add member to role" (agregar a alguien a un rol) y deja la hora, la operación, la cuenta y la dirección. Es la mitad izquierda del cruce.

join une las filas de dos tablas que comparten un valor, la clave. Se escribe join kind=inner (tabla2) on $left.ColumnaA == $right.ColumnaB, donde $left es la tabla que viene de la izquierda del join y $right la del paréntesis. Para unir por más de una columna se separan las condiciones con and.

Si no escribes kind=, KQL usa por defecto innerunique: antes de unir, deduplica la tabla izquierda por la clave, y solo queda una fila por cada valor distinto. Con kind=inner se conservan todas las filas que tienen pareja. Compara dos consultas que cuentan las operaciones hechas desde la dirección que inició sesión desde otro país. Sin kind=: AzureActivity | join (SigninLogs | where ResultType == "0" and Location != "CO" | project IPAddress, Location) on $left.CallerIpAddress == $right.IPAddress | count. Con kind=inner: la misma, escribiendo join kind=inner ( en lugar de join (.

Unir solo por la cuenta trae todos los inicios de sesión de esa cuenta durante el día, no el que corresponde al cambio. En el extracto la cuenta tiene tres entradas correctas; unir por cuenta devuelve tres filas para un solo cambio y obliga a adivinar cuál era. Con la cuenta y la dirección como clave (on $left.Actor == $right.UserPrincipalName and $left.IP == $right.IPAddress) la unión señala la entrada que corresponde.

Una clave de unión demasiado floja produce filas de más que parecen evidencia y no lo son. Una clave demasiado estricta pierde las coincidencias. La lectura honesta dice con qué claves se unió y qué no prueba esa unión.

kind=leftanti devuelve las filas de la tabla izquierda que NO tienen pareja en la derecha, y solo con las columnas de la izquierda. Aplicado a AzureActivity contra los inicios de sesión correctos, por dirección, muestra operaciones de gestión hechas desde direcciones sin ninguna entrada correcta registrada en SigninLogs.

Que una operación no tenga inicio de sesión en esa tabla no significa que sea ilegítima, y menos que sea un ataque. Antes de concluir hay que preguntarse qué puede explicarlo. Lee el resultado y fíjate en el nombre de la cuenta.

La cuenta del resultado anterior es de servicio: hace copias programadas y no entra a una consola. SigninLogs recoge los inicios de sesión interactivos de personas; los inicios no interactivos y los de entidades de servicio se guardan en otras tablas de inicios de sesión del espacio. Por eso la ausencia en una tabla es una pregunta, no un hallazgo: falta mirar las otras tablas y comprobar con el responsable de la cuenta que esas copias son las esperadas.