Tema: logging
-
Registros de auditoría: qué registrar, cómo mantenerlos íntegros y quién puede leerlos
Un registro de auditoría responde a quién hizo qué a qué objeto, cuándo y con qué resultado; lo escribe la propia aplicación para cada acción relevante para la seguridad, se mantiene separado de los logs de depuración, se protege contra alteraciones trasladándolo con prontitud a un almacenamiento de solo anexado o de escritura única, y se lee solo bajo un acceso restringido y registrado.
-
Log sampling for high-volume events: keep every error, sample the repetitive lines
Sampling drops a fraction of similar log events on purpose; the useful forms are one-in-N, burst-then-rate per period, per-level rules that leave warnings and errors untouched, and pipeline sampling keyed on a request ID so a whole request is kept or dropped together, with the applied rate written into the surviving events.
-
Access logs for personal data: recording who read which record
An access log for personal data records reads, not only writes: actor, subject, object, reason and time, emitted at the application read path and reconciled with database-level statement logging for paths that bypass it; it must answer subject-centric questions such as who looked at this person's record in the last year.
-
Minimize personal data in evidence
Retain the smallest evidence record needed to reproduce a decision, excluding unrelated identity and payload data.
-
Data minimisation as a schema and logging discipline
Store only the personal data a feature needs, at the coarsest precision that serves it, and keep identifiers out of logs by allowlisting fields; every column, log field and derived store that carries personal data is a design decision with a purpose, an owner and an expiry, not a default.
-
Redact secrets before writing logs
Log an allowlisted diagnostic record rather than raw tool requests, and verify redaction at every output sink.
-
JSON Lines: one value per line for logs, datasets and streamed responses
JSON Lines (also called NDJSON) puts one complete JSON value per line, UTF-8 without a byte order mark and newline-terminated; files can be appended, split, grepped and compressed, and a truncated stream loses only its last line. RFC 7464 JSON text sequences add a record-separator byte for recovery. Use either instead of one large JSON array whenever records are produced or consumed one at a time.
-
Carrying a request ID end to end: edge, logs, downstream calls and the response
Generate a request identifier at the edge (nginx offers $request_id, 16 random bytes in hex), pass it to the application in a header, keep it in request-scoped context so every log line and every outbound call carries it, and return it in the response so that a user's report can be matched to the logs of every service it touched; where tracing exists, the W3C trace ID is that identifier.
-
How much request detail should a small service log for security forensics without hoarding personal data?
Open question: the OWASP Logging cheat sheet lists events that should be logged and data that should not be, but between them lie query strings, request bodies, client addresses and user agents, which incident reconstruction wants and data minimisation argues against; which field sets, masking rules and retention tiers have small teams found workable?
Legible por máquina: JSON