¿Cuánto detalle de las peticiones debería registrar un servicio pequeño para análisis forense de seguridad sin acumular datos personales?

Pregunta abierta

La hoja de referencia de Logging de OWASP (Logging cheat sheet) indica que los logs de la aplicación deben registrar "when, where, who and what" (cuándo, dónde, quién y qué) para cada evento. Enumera los eventos que conviene registrar siempre que sea posible (fallos de validación de entrada, autenticaciones correctas y fallidas, fallos de control de acceso, fallos de gestión de sesión, errores de la aplicación, arranques y apagados) y también los datos que deben eliminarse, enmascararse o convertirse en hash en lugar de registrarse (identificadores de sesión, tokens de acceso, contraseñas, claves, datos de pago, datos personales sensibles). Además afirma que no existe un nivel único válido para todos los casos y advierte de que una lista de comprobación aplicada a ciegas produce "alarm fog" (una niebla de alarmas). Lo que la hoja no puede resolver es dónde debería trazar la línea, en el terreno intermedio, un equipo de dos personas que mantiene un único servicio web: rutas completas de petición y query strings (que a menudo contienen identificadores y a veces tokens), cuerpos de petición cuando falla la validación, direcciones IP de cliente y user agents (con frecuencia tratados como datos personales, pero también la principal pista para reconstruir la sesión de un atacante) y cuánto tiempo conservar cada uno. Si se guarda todo durante un año, el almacén de logs pasa a ser el conjunto de datos más sensible del equipo; si solo se guardan los errores durante una semana, un incidente descubierto un mes después no se puede reconstruir. En concreto: ¿qué conjuntos de campos, reglas de enmascaramiento (direcciones de cliente con hash y sal diaria, query strings truncadas, parámetros de token conocidos censurados) y niveles de retención (detalle completo durante poco tiempo, datos agregados durante más) han usado equipos pequeños, y fueron suficientes cuando hubo que reconstruir un incidente de verdad?

Qué contiene una respuesta útil

La escala del servicio y la sensibilidad de sus datos; los campos exactos que se registran y los que se enmascaran; la retención de cada nivel y el almacenamiento utilizado; si se reconstruyó algún incidente a partir de estos logs y qué faltaba; los formatos de log del servidor web y del proxy implicados, para que los lectores puedan compararlos con sus valores por defecto; y la fecha. Las afirmaciones sobre si algo es suficiente desde el punto de vista legal deben indicarse como la interpretación del autor y no como asesoramiento.