Logs de integración: qué registrar para resolver una incidencia

Para qué existe un log de integración

Cuando un inventario no cuadra o una etiqueta muestra un precio equivocado, alguien preguntará: ¿llegó el evento?, ¿se rechazó?, ¿cuándo y por qué? Si la respuesta exige revisar tres sistemas a mano y cruzar horas, la incidencia durará días. Un log pensado para esa pregunta la reduce a minutos.

La hoja de OWASP sobre logging distingue usos operativos (depuración, monitoreo de procesos de negocio, problemas y condiciones inusuales) y usos de seguridad (incidentes, auditoría de cambios), y advierte que a menudo conviene mantenerlos separados porque difieren en contenido y propósito. También recuerda que los registros deben diseñarse según el riesgo: ni demasiados ni demasiados pocos.

Campos mínimos recomendados

La hoja de OWASP resume los atributos de un evento en cuándo, dónde, quién y qué. Traducido a una integración de inventario:

Cómo se relacionan ID de evento, clave de idempotencia y correlación

Son tres identificadores con funciones distintas y conviene documentar su mapeo en el contrato. El ID del evento identifica el hecho de negocio (una recepción, un conteo). La clave de idempotencia identifica una operación de envío para reconocer reintentos. El ID de correlación sigue una operación a través de sistemas, incluidos los reintentos.

• Caso simple: una operación emite un solo evento. Entonces el mismo valor puede servir de ID del evento y de clave; regístralo en ambos campos.
• Una operación con varios eventos (por ejemplo, un cierre de sesión que genera un evento por línea): una clave de operación y varios IDs de evento; el log debe permitir pasar de uno a otros.
• Corrección de un evento ya enviado: en EPCIS, la declaración de error repite el eventID del original porque es una copia con ErrorDeclaration, y los eventos correctivos llevan su propio eventID. La clave de idempotencia del envío de esa corrección es otra, distinta de la del envío original.

Ejemplo hipotético: la operación K-77 envía un evento E-1. La PDA reintenta con K-77 y el log registra dos intentos del mismo evento. Más tarde se descubre un error: se envía con la clave K-78 una declaración de error con el eventID E-1 y un evento correctivo con eventID E-2. En el log debe verse que K-78 produjo ambos y que E-1 aparece en dos registros por diseño, no por duplicado.

Qué no debe quedar en el log

OWASP indica que, por lo general, no deben registrarse en claro los valores de sesión, tokens de acceso, contraseñas, cadenas de conexión a bases de datos, claves de cifrado, datos de tarjetas ni información personal sensible; deben eliminarse, enmascararse, aplicar hash o cifrarse. En una integración de inventario esto incluye encabezados de autorización, cuerpos completos de solicitudes con nombres de personas y credenciales de PDA o de lectores.

• Registra un identificador de operador, no su nombre completo, y solo si es necesario para auditoría.
• Si necesitas depurar un cuerpo completo, hazlo temporalmente, con acceso restringido y con fecha de borrado.
• Limita el tamaño de los valores registrados y trata los datos externos como no confiables, por ejemplo para evitar inyección de líneas falsas en el log.

Este punto conecta con la privacidad: si un registro contiene datos de personas, aplica a él los mismos criterios de acceso y retención que al sistema original.

Acceso, integridad y retención

Los registros son valiosos para quien investiga y para quien quiere ocultar rastros. La hoja de OWASP recomienda restringir y revisar periódicamente quién puede leerlos, registrar los accesos, detectar alteraciones o borrados y copiarlos pronto a un almacenamiento de solo lectura cuando sea posible. También indica no conservarlos más allá del periodo requerido y no destruirlos antes de él; ese periodo lo determinan obligaciones legales, contractuales y de negocio que debes definir con tu área jurídica.

Como referencia general sobre organización de la gestión de registros, existe la guía NIST SP 800-92, que presenta la gestión de registros desde un nivel alto, no como manual de implementación.

Ejemplo hipotético: una recepción que no aparece en el WMS

Ejemplo ilustrativo. Un supervisor reporta que una recepción de 40 cajas hecha a las 18:55 no aparece en el WMS. Soporte busca por el ID de correlación que el operador ve en la pantalla de la PDA. Encuentra tres registros: el middleware armó el evento, el primer envío expiró a las 18:56 y el reintento del mismo evento recibió un rechazo por “orden cerrada” a las 19:03. La causa no era la red sino que la orden de compra se cerró administrativamente a las 19:00.

Con el ID del evento y el motivo de rechazo, el WMS pudo reabrir la orden y aplicar el evento. Sin esos campos, la investigación habría sido una comparación manual de horas entre sistemas.

Cómo probar que tus logs sirven

Haz un simulacro: elige tres eventos de prueba, uno aceptado, uno rechazado y uno perdido por una caída, y pide a alguien que no participó en el diseño que reconstruya su historia usando solo los registros. Mide cuánto tarda y qué le faltó. Revisa también que el log no contenga ningún secreto y que un usuario sin permiso no pueda leerlo. Repite tras cada cambio importante de versión.

Verifica además el comportamiento del propio registro: qué pasa si el almacenamiento se llena o si el destino de logs no responde. La integración no debería detenerse por eso, ni filtrar información en el intento.

Siguiente paso

Define el conjunto mínimo de campos y la lista de datos prohibidos en una página, y valídalos con el simulacro de tres eventos. Para conversar sobre cómo documentar la captura de datos en tu operación, puedes escribir a ARKCOM en garkcom.com/contact.