El registro de inicios de sesión, campo a campo

Todos los proveedores de identidad de empresa escriben un evento por cada inicio de sesión, y los campos se repiten de uno a otro aunque cambien de nombre. Como referencia de mercado, el más extendido en las vacantes es Entra ID, el proveedor de identidad de Microsoft; lo que aprendes aquí vale para cualquiera. Los campos que se leen en el turno son estos. Resultado y motivo: no basta con «fallido», el motivo dice qué falló. Método y requisito: cómo se demostró la identidad (contraseña, aplicación de verificación, llave de seguridad, una sesión que ya estaba abierta) y si eso cuenta como un factor o como varios. Aplicación y cliente: a qué se entraba y con qué programa, porque un navegador y una aplicación de escritorio no siempre pasan por las mismas reglas. Dispositivo: si el equipo es de la empresa, si está registrado y si cumple sus reglas, lo que se llama estar conforme.

Y el campo que más se malinterpreta: el acceso condicional. Es el conjunto de directivas que la empresa escribe en el proveedor —«a tesorería, en el portal de pagos, solo desde equipos de la empresa», «a todo el mundo, segundo factor»— y el evento dice si alguna se evaluó y qué decidió. Tiene tres valores que no son lo mismo: aplicado con éxito (una directiva miró la entrada y la dejó pasar), aplicado con fallo (una directiva la cortó) y no aplicado (ninguna directiva cubría esa entrada).

En el laboratorio, el registro del día está partido en dos tablas unidas por el id del evento, como cuando abres el detalle de una fila en la consola del proveedor.

Un fallo de inicio de sesión no es un dato: es una categoría. «Contraseña incorrecta» quiere decir que la primera puerta no se abrió, y casi siempre es alguien que teclea mal y lo corrige en el mismo minuto. «Bloqueado por acceso condicional» quiere decir lo contrario: la contraseña era buena, y lo que paró la entrada fue una regla de la empresa que miró algo más —el equipo, el país, la aplicación—. Contar los dos como «fallos» en la misma columna esconde lo único que importa de cada uno.

Cuando el motivo es una directiva, el evento dice cuál, y esa es la primera pregunta que hay que contestar: qué regla actuó, para saber qué exigía y por qué esta entrada no lo cumplía. La persona de tesorería del laboratorio no intentaba nada raro: quería trabajar desde casa. Pero el bloqueo te dice algo de la cuenta —su contraseña funciona desde un equipo que la empresa no conoce— y algo de la directiva —hizo su trabajo—.

Busca el fallo de las 12:40 y abre su evento.

Cuatro minutos después del bloqueo, desde la misma dirección de casa y el mismo portátil personal, esa cuenta entra a otra aplicación. Entra con la contraseña sola, y el evento no dice que alguna directiva lo permitiera: dice que ninguna se aplicó. Ese es el hueco que el acceso condicional deja cuando una aplicación queda fuera de las directivas, casi siempre por una razón razonable el día que se decidió —un cliente de escritorio viejo que no sabía pedir el segundo factor, una exclusión «temporal» mientras se migraba—.

El cliente importa por lo mismo. Muchas directivas se escriben pensando en el navegador, y una aplicación de escritorio o un protocolo antiguo de correo puede no pasar por ellas. Por eso, ante un «correcto» con un solo factor, hay que mirar a qué aplicación y con qué cliente se entró, y después buscar en la lista de directivas si esa aplicación está excluida.

Encuentra el único evento del día en el que ninguna directiva se aplicó y escribe a qué aplicación se entró.

En la primera sala del módulo, el viaje imposible delató dos manos con la misma credencial. Aquí ves la otra cara: la ubicación de un inicio de sesión no es la de la persona, es la de la dirección por la que sale a internet, y la geolocalización solo sabe dónde está registrada esa dirección. Tres cosas mueven esa dirección sin que nadie se mueva. La VPN corporativa, si su concentrador está alojado en una nube de otro país: todo el que se conecta sale por allí. Un servicio de navegación segura en la nube, que saca el tráfico por el nodo que tenga disponible, y un día de mantenimiento ese nodo está en otro país. Y los operadores móviles, que a menudo geolocalizan todas sus direcciones en la capital.

Por eso, ante una alerta de viaje imposible, lo primero no es la distancia ni el riesgo que le pone el proveedor —el riesgo alto puede ser el más inocente—: es de quién es la dirección de llegada. Esa respuesta no la tiene el proveedor, la tiene la empresa, en su lista de salidas conocidas. Después se confirma con lo que el evento trae: el mismo equipo de la empresa, conforme, y la misma sesión que siguió trabajando.

De las tres alertas de viaje imposible de la mañana, dos se explican con una dirección de la empresa y un equipo de la empresa. Una no: su dirección de llegada no está en ninguna lista, y el evento de esa entrada no trae equipo de la empresa. Esa cuenta es la que pasa a la sala siguiente.