Observabilidad de seguridad distribuida

Cuando una petición pasa por varios servicios, cada uno escribe su propia línea. El identificador de traza (o de correlación) lo crea el primer servicio de la cadena y viaja en una cabecera hasta el último: todos lo copian a su registro. Con él se reconstruye qué pasó de punta a punta; sin él, el analista tiene cuatro archivos y tiene que adivinar qué línea corresponde a cuál por la hora.

Una serie de rechazos 401 seguidos desde la misma dirección, seguida de una respuesta 200, es el patrón clásico de un intento de adivinar credenciales que terminó funcionando. En el registro de un solo servicio ya se ve; el valor de la observabilidad distribuida es seguir después qué hizo esa sesión en los demás.

Abre registros/svc-carrito.log.

Con la traza t-90417 se sigue la sesión sospechosa: el carrito aceptó la compra, el servicio de pedidos creó el pedido y alguien después rechazó el pago. El motivo del rechazo ya es información de seguridad: dice que la identidad de quien pagaba no pudo comprobarse.

Abre los registros de los cuatro servicios y filtra por esa traza.

Basta un servicio que no copie la traza para dejar un hueco en la cadena. En esa línea no hay forma de asociar la petición con las demás, y es justo el servicio donde, si algo pasara, el analista no podría seguir el hilo. Las convenciones de registro de Tienda Yopo piden que la traza pase de servicio a servicio en una cabecera.

Abre notas/convenciones-de-registro.txt y revisa el campo traza de cada registro.

Los registros viajan a un almacén central y los lee más gente que la que opera el servicio. Si en ellos queda el token completo de una persona, quien lea el registro puede usarlo mientras no caduque. Registrar cabeceras de autorización es un error común al depurar. Corregirlo exige dos cosas: dejar de escribirlas y tratar lo ya escrito como expuesto.