主题： logging
-
审计日志：记录什么、如何保持完整、谁可以读取
审计日志要回答的是谁在何时对哪个对象做了什么、结果如何；它由应用程序针对每一次与安全相关的操作写入，与调试日志分开保存，通过及时转移到仅追加或一次写入的存储中来防止被篡改，并且只在有记录、受限的权限下才能读取。
-
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?
机器可读： JSON