Inicio de sesión en la nube — el registro de actividad y el de identidad

Las nubes que se usan en una empresa llevan un registro de actividad: una bitácora, activada a nivel de cuenta, que anota cada acción realizada contra la plataforma, venga de la consola web, de la línea de comandos o de un programa. Cada proveedor le pone su propio nombre —rastro de auditoría, registro de actividad, bitácora de la organización— y el papel es el mismo en todos.

Los campos se repiten de un proveedor a otro, y son los que hay que saber leer: cuándo ocurrió, qué acción fue (el nombre del evento, por ejemplo un inicio de sesión en la consola), quién la hizo (la identidad, su tipo y la cuenta a la que pertenece), desde dónde (dirección de origen y programa cliente), sobre qué recurso y con qué resultado, incluido el motivo si fue denegada.

Con eso basta para la mayoría de las preguntas del turno, y hay una que se hace siempre: un evento que cambia la propia vigilancia —detener el registro, borrar un rastro, cambiar dónde se guarda— se mira antes que cualquier otro, acabe en éxito o en denegación. En ATT&CK es deterioro de las defensas (T1562.008).

El segundo registro es el del proveedor de identidad: el servicio que autentica a las personas antes de dejarlas entrar a nada. Anota cada inicio de sesión con la identidad, la aplicación a la que se accedía, la dirección y el país de origen, el método usado, si hubo segundo factor y con qué resultado. Muchos proveedores añaden además una señal de riesgo calculada por ellos: viaje imposible, dirección asociada a anonimizadores, patrón inusual.

La distinción práctica entre los dos registros vale un turno entero: el de identidad responde «¿quién consiguió autenticarse y cómo?», el de actividad responde «¿qué hizo después dentro de la plataforma?». Un caso de nube casi siempre se arma cruzándolos, y empieza en el de identidad porque es donde aparece la primera entrada aceptada.

Y conviene recordar una asimetría del oficio: en la nube no hay perímetro que ayude. Una credencial válida usada desde cualquier parte del mundo entra igual que desde la oficina, y el registro dirá «correcto». Por eso el dato que convierte un inicio de sesión correcto en un hallazgo es el contexto: la hora, el origen, el cliente usado y si pasó o no por segundo factor.

El error de lectura más común con los registros de nube es tratar «resultado: correcto» como «todo en orden». Tres patrones desmienten eso cada semana en cualquier SOC.

Sin segundo factor. Una identidad que siempre entra con doble factor y una noche entra sin él, o desde un método que no usa nunca, está diciendo que la credencial viajó a alguien más o que alguien registró su propio método.

Credencial de larga vida desde fuera. Las claves de acceso programático no caducan solas y acaban copiadas en servidores, repositorios y portátiles. Una clave que llevaba meses usándose solo desde la dirección de salida de la empresa y aparece de pronto desde otra parte vale lo mismo que una contraseña filtrada.

Horario y cliente. La misma identidad que trabaja desde el navegador de nueve a seis aparece a las tres de la madrugada con un cliente de línea de comandos descargando datos. Ninguno de los tres hechos es una alerta por separado; juntos son el caso.

En la consola tienes el registro de actividad de la cuenta de nube de Delta Cargo y los inicios de sesión de su proveedor de identidad, del 1 y el 2 de octubre. Entre las sesiones normales de la oficina hay una de madrugada que entró sin segundo factor y siguió con una descarga de datos. Encuentra la dirección desde la que se abrió.