La redacción de logs no es un checkbox

Casi todos los proyectos en los que trabajé tienen redacción de logs configurada. Y en casi todos, en algún momento, descubrí que estaba incompleta. No rota: incompleta, que es peor, porque parece que estás protegido.

El problema arranca con un supuesto inocente. Agregás un campo que puede llevar datos sensibles, ves que en la config de redacción hay un patrón tipo *.password, y asumís que estás cubierto. Pero ese patrón tiene una semántica de profundidad específica: puede cubrir un solo nivel de anidamiento y no los de más abajo, o puede no cubrir el campo cuando aparece “pelado”, sin objeto que lo envuelva. El mismo valor, logueado en dos formas distintas, necesita dos rutas de redacción distintas. Y es facilísimo proteger la forma que estás mirando y dejar pasar la que no.

Primero: verificá la semántica de tu librería

Antes de confiar en cualquier patrón con wildcard, confirmá cómo funciona tu librería de logging: ¿el comodín cubre un nivel o es recursivo? Esto no se adivina leyendo el nombre del patrón. Se verifica en la documentación de la versión que estás usando, o con una prueba rápida que loguea el objeto y mira qué sale. Yo aprendí a no dar por sentado que *.campo cubre a.b.campo. A veces sí, a veces no.

Segundo: buscá todas las formas del campo

Cuando agrego un campo sensible, hago un grep por las dos formas: la anidada (objeto.campo) y la pelada (campo). Cada forma en la que ese valor puede aparecer en un log necesita su propia entrada de redacción. No alcanza con cubrir la forma que introdujo tu cambio; el mismo dato puede terminar logueado desde otro lugar con otra estructura.

Tercero, y más importante: no loguees el dato

La redacción es defensa en profundidad, no el control principal. El control principal es no mandar el dato al log en primer lugar. En el punto donde se escribe el log, logueo IDs y metadata acotada, no el objeto sensible entero. Si el valor nunca llega a la sentencia de log, ningún patrón mal configurado lo puede filtrar. La redacción es la red por si algo se me escapa, no el piso sobre el que camino.

Cuarto: clasificá antes de asumir

No todo campo “sensible” necesita el mismo tratamiento. Antes de asumir que algo va encriptado o redactado, lo clasifico contra la guía de datos sensibles del proyecto. Y cuando agrego una ruta de redacción, copio exactamente la forma que usan los campos hermanos en vez de inventar un patrón nuevo. La consistencia con el precedente vale más que mi creatividad ahí.

El test que cierra el círculo

Lo que hago ahora, y ojalá hubiera hecho antes: un test que serializa la salida del log y afirma que un valor sensible conocido no aparece. Así una redacción incompleta falla en CI, en vez de aparecer en una review tres meses después o, peor, en un incidente.

La lección general: “tenemos redacción configurada” y “los datos sensibles están fuera de los logs” son dos afirmaciones distintas. La primera es una config. La segunda hay que probarla.