What the Blackbox proves to an auditor, and what it does not

Sooner or later someone asks three questions about a production database. Who changed it? Who approved the change? And how do you know the answers were not edited afterwards? This is what FoxByte’s Blackbox answers, the commands that show it, and, just as plainly, where it stops.

Who changed it

Every change to a table, view, index, function, type, trigger, policy or privilege is written down by event triggers inside the database, in the same transaction as the change itself. If the change rolls back, so does its entry; if it commits, the entry is there.

Each entry names the login role that made it. The gateway logs every person in as their own Postgres role and every agent as an agent role, and a client cannot change its login, so that part cannot be forged. The tool, application_name, is whatever the client says it is: useful for reading, not proof. An application that shares one login between many people is recorded as that login.

• Also recorded: TRUNCATE from anyone, an agent’s UPDATE and DELETE, once per statement, and every change the guardrails refused, as BLOCKED.
• Not recorded: reads, and a person’s INSERT, UPDATE and DELETE.

$ fox blackbox
$ fox blackbox entries --limit 20

How you know it was not edited

The record is an append-only table, and each entry carries a hash of the one before it. Edit or delete an entry and every hash after it stops matching, which fox blackbox verify finds in every edition.

A database superuser could rewrite the rows and recompute every hash after them. That is what anchors are for. On a schedule, the engine signs a checkpoint of the chain with an Ed25519 key the database cannot read and writes it outside the database. fox blackbox integrity, or the standalone fox-verify with the public key, checks the record against them. Writing anchors is part of Enterprise; checking them is free, so an auditor never needs a licence to verify you.

Anchors prove something only if they live where the people being audited cannot change them. With a remote backup target, every anchor is copied to the bucket too; make it a bucket in Object Lock compliance mode, controlled by someone other than the database administrators.

$ fox blackbox verify
$ fox blackbox integrity
$ fox blackbox anchor-key

Who approved it

Schema changes can reach main through a change request: prepared on a branch, reviewed statement by statement, and applied in one transaction by someone allowed to manage main. An agent can ask and never approve. The request keeps who asked, who approved and what was applied, and the Blackbox keeps each statement attributed to whoever wrote it.

One limit to state to your auditor today: FoxByte stops an agent approving its own request, but not a person. Someone who can manage main can ask and approve the same change, and the record shows they did both. Put the two-person rule in your process until the product enforces it.

Where it stops

A record is only as trustworthy as the account of its gaps. These are the Blackbox’s today.

• A database superuser can stop the event triggers, for one session with SET event_triggers = off or SET session_replication_role = replica, or for everyone by disabling them, and what they change meanwhile is not recorded. Anchors still prove the recorded history was not rewritten; they cannot show what was never written.
• Roles, role memberships, databases, tablespaces and settings live outside any one database, so event triggers never see them. Nor do they record dropping a trigger, a policy, a procedure, an aggregate or a foreign table.
• The next release closes most of this: every five minutes a catalog scan compares the schema with what it saw last, and records what the triggers missed, and those global objects, with who made the change marked unknown.
• Someone with root on the machine can read the disk and the anchor key there. For them, anchors kept elsewhere are the proof, and nothing on the machine itself can be.

What to hand over

The Blackbox page sets out the full scope, entry by entry, and the regulated teams page maps it to what auditors ask.