Azure en dos libros, el registro de actividad y los inicios de sesión

El registro de actividad de una suscripción recoge las operaciones de gestión: crear, cambiar y eliminar recursos, asignar roles, pedir las claves de una cuenta de almacenamiento. Normalmente no recoge lecturas. Cada entrada lleva caller, la identidad que la inició, la operación, su estado, la dirección en httpRequest y un correlationId. Es el único sitio donde queda el autor de la creación de un recurso.

Los registros de inicio de sesión de Entra anotan los intentos de autenticación, los buenos y los malos: el usuario, la dirección, la aplicación a la que entró, el resultado, si se aplicó acceso condicional y qué requisito de autenticación hizo falta. Lo que un libro no dice, lo dice el otro; por eso casi toda investigación en Azure abre los dos.

En la tabla de inicios de sesión de Entra el campo ResultType vale 0 cuando el intento salió bien, y cualquier otro valor es el código del error. Microsoft publica la lista de códigos y la descripción de cada uno, y la propia entrada trae un ResultDescription con el texto. Algunos fallos son de lo más normal: una persona se equivoca de contraseña, o no responde al segundo factor.

Lo que llama la atención no es un fallo suelto sino su forma: varios fallos seguidos con el mismo código, desde una dirección que no es la habitual de esa persona, y poco después un acierto desde esa misma dirección. Fíjate además en dos columnas, ConditionalAccessStatus y AuthenticationRequirement, que dicen si algún acceso condicional se aplicó y si hizo falta un solo factor o varios.

El registro de actividad no escribe una sola línea por operación. Una misma operación deja varias entradas que comparten el correlationId: una primera con estado Started cuando empieza y otra al terminar, con estado Succeeded o Failed. El campo subStatus suele traer el código HTTP de la llamada o su nombre.

La consecuencia práctica es que una entrada Started no prueba que la operación saliera bien. Antes de afirmar que alguien cambió algo, hay que mirar la última entrada de ese correlationId. Y para listar todas las entradas de una operación basta buscar su identificador de correlación.

Una asignación de rol queda en el registro de actividad como una operación roleAssignments/write. Dentro de las propiedades de la entrada, el cuerpo de la petición lleva el identificador de la definición de rol, un GUID, y no el nombre. Para saber qué permisos se concedieron hay que traducir ese identificador.

Microsoft publica los identificadores de todos los roles integrados. En el laboratorio tienes una tabla con cuatro. El hábito sano es el mismo que con las cuentas de servicio: no fiarse del nombre que uno cree recordar, sino leer el identificador que el registro trae y buscarlo en la tabla.

Un hecho aislado en un libro es una sospecha; el mismo hecho en dos libros es una línea de tiempo. El inicio de sesión de Entra dice que una cuenta entró a una hora desde una dirección. El registro de actividad dice, a partir de esa hora, qué operaciones hizo esa misma cuenta, y su campo caller trae el mismo nombre de usuario. Si además la dirección de httpRequest coincide con la del inicio de sesión, la secuencia queda atada: entró, y desde ahí hizo esto.

Comprueba que ocurra eso con los datos de Arrayán: compara las direcciones de los fallos y del acierto de la madrugada con las de las operaciones que siguieron.