Full Auditability
You achieve full auditability by tying every database query and server command to a real person. You must also record what the system returns during that session. Most engineering teams start by turning on native database logs and host history files. When teams share broad admin roles, those logs only show a generic user name. You cannot tell which engineer ran a bad write query or read sensitive rows. How to set up native logs for full auditability To build an audit trail, you first map each
Auditability: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You achieve full auditability by tying every database query and server command to a real person. You must also record what the system returns during that session. Most engineering teams start by turning on native database logs and host history files. When teams share broad admin roles, those logs only show a generic user name. You cannot tell which engineer ran a bad write query or read sensitive rows.
How to set up native logs for full auditability
To build an audit trail, you first map each human user to an identity provider. You stop giving out shared admin keys to your team. Instead, you create unique database roles or host accounts for each person. When someone logs in, the target server checks their role and starts a log file.
Next, you turn on statement logging inside each database and server. The database engine writes every read and write command to a local disk file. On Linux hosts, the shell writes command history to a local log file. You then run a log shipper agent on every single server and database host. This agent reads the local log files and sends them to a central log store.
In the central log store, you set strict retention rules so no one deletes records. Security teams then search those logs during a check or after an incident. They match the local role name back to the central identity directory. This step shows who logged in and when the session started.
What native logging solves and where gaps remain
Native logging proves that a user logged in at a specific time. It also shows the basic text of commands sent to a single server. If you manage five databases, you must set up five separate log pipelines. Each database engine uses a different log format and tracks different details.
Still, native setup only controls who logs in and records raw text on disk. It does not inspect or control what individual commands do in flight. If an engineer has a root role on a host, they can pause the log agent. They can also edit local history files before the agent sends them out.
Auditability: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Native logs also miss the data that comes back from a query. You might see that a user ran a broad read query on a customer table. You will not know if the result included emails, phone numbers, or card numbers. Also, native roles cannot require a second person to approve a single risky command. Once a user logs in with a write role, every write command runs right away.
Why teams must redact sensitive fields in logs
Recording every query and result creates a new risk inside your log store. Engineers often pass real emails, phone numbers, or national IDs inside query filters. If your audit system writes raw queries to disk, your logs now hold sensitive data. Anyone who can read the central log store can now see those private fields.
To fix this, teams must rewrite matched fields in results and logs before storage. Masking replaces card numbers and phone numbers with safe placeholder text in flight. The audit log still proves which table and row the engineer touched. At the same time, raw private data does not spill into your log storage.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What is the difference between system monitoring and full auditability?
Monitoring tracks server health metrics like CPU load, memory use, and disk space. Auditability tracks human and machine actions by recording who ran which command and when.
Why do shared database accounts break audit trails?
When five engineers share one admin login, every query shows the same account name. You cannot prove which person on the team ran a specific delete statement.
Should audit logs record query results as well as query text?
Recording query text shows intent, while audit ssh sessions output shows the exact rows returned. You should mask emails, phone numbers, and card numbers before saving any output logs.