Aplicaciones con consentimiento y registro de auditoría

Cuando una persona hace clic en «permitir» ante una aplicación, concede un consentimiento: la aplicación recibe permisos (por ejemplo, leer y modificar el correo) y, si pide acceso sin conexión, un token que le permite seguir actuando aunque la persona no esté conectada. Ese permiso es de la aplicación: no se cae al cambiar la contraseña ni al cerrar sesión.

El engaño típico es una página de «permitir acceso» de una aplicación de aspecto útil. Nadie roba la contraseña: la persona entrega el permiso con sus propias manos, y por eso muchas defensas centradas en credenciales no lo ven.

Una aplicación sospechosa se reconoce por rasgos sumados: publicador sin organización detrás, sin verificar, permisos más amplios de lo que su función necesita (leer y escribir correo para «resumir facturas») y acceso sin conexión. Las otras aplicaciones del tenant tienen publicador identificado, uso amplio entre muchas cuentas y permisos que corresponden a su propósito.

El número de cuentas que consintieron es una pista: una aplicación legítima suele tener decenas; una que acaba de aparecer y ya tiene permisos de correo, muy pocas.

El consentimiento queda ligado a la cuenta que lo dio. La tabla de consentimientos dice quién, cuándo y desde qué dirección. Si la dirección de un consentimiento coincide con la del acceso que ya se conoce, esa segunda cuenta también está comprometida, aunque nadie la haya reportado ni su dueño haya notado nada.

El alcance de un incidente de identidad se mide así: pivotando de un indicador (la dirección, la aplicación) a las demás cuentas donde aparece.

El registro de auditoría es la fuente que ordena los hechos por hora, pero no se conserva para siempre: el proveedor lo guarda un número de días y luego lo borra. Por eso exportarlo es de las primeras tareas de la respuesta, igual que la memoria en un equipo. La configuración del tenant dice cuántos días se conserva, y el primer evento sospechoso dice desde cuándo corre el reloj.

El cálculo es simple pero se hace con la fecha y no a ojo: el último día en que todavía existe el primer evento sospechoso es su fecha más la retención.

Para contener esta puerta hay que actuar sobre la aplicación: revocar los consentimientos concedidos, invalidar los tokens que ya se emitieron, bloquear la aplicación en el tenant para que nadie más la autorice y cambiar la configuración que permitía consentir aplicaciones no verificadas. Restablecer contraseñas no sirve aquí, como muestra la política del tenant del caso, que no revoca nada al restablecer.

Se conserva antes la lista de consentimientos y el registro de auditoría, y se busca la misma aplicación en otras cuentas.