What an audit line must never contain

What an audit line must never contain

An access log that records headers, bodies or query strings is a second copy of the secrets it was meant to protect. What to log instead.

The purpose of an audit log on a credential broker is to answer three questions after the fact: who called what, was it allowed, and what did it cost. A log that answers those and nothing else is safe to ship to any log pipeline. A log that answers them and also happens to record the request is a second copy of every secret that ever passed through.

Never a body

Request and response bodies are the payloads of someone else's API. Some carry the caller's data, some carry the provider's answer, and neither belongs in a file that lives on disk for months. The broker parses no payloads, so it has no reason to keep them.

Never a header — not "every header except ours"

The tempting rule is to log all headers except the one the broker added. That is the same enumeration mistake as a blocklist of ways to print an environment, one layer down. Which other headers carry secrets? Cookies. Proxy credentials. A custom header some provider decided to use. A header a caller set by mistake. The list is not knowable in advance, so the rule is that no request header reaches the log at all. The record is built from primitive fields only — strings, numbers, a timestamp — so there is nowhere to put a header map even by accident.

Never a query string

Several live API conventions put the credential in the query string, and a broker that supports those services puts its own credential there. The path is recorded up to the first question mark and no further.

What is recorded

A timestamp. The caller's name and numeric identity, as the kernel reported them. The upstream, by label, so the line names which of a provider's keys served the call. The method, the path, the status. Bytes in, bytes out, duration. The per-call cost from the catalogue, when the catalogue states one. A policy identifier carrying the version of the key block that was in force. And the outcome — forwarded, or which of the refusals.

Refusals are logged with exactly the same fields as successes. A broker that logged only successes would make a caller probing the allowlist invisible, which is precisely the traffic worth seeing.

Comments

Leave a comment

Ready when you are.

Tell us about your setup and a person will write back.