Database Configuration & Security Audit Guide

This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.

An audit is a file you may open

A configuration audit reads a file you are allowed to read: my.cnf, postgresql.conf, pg_hba.conf, a SQL Server configuration, an Oracle parameter file, or mongod.conf. The auditors on this site flag patterns. A flag is a question. You do not fetch a server you do not administer, and you do not treat the tool as a certification.

One finding. A listen address on every interface, a password in the file, a trust rule that is wider than the lab, or a superuser the application uses: pick the one you can explain. The configuration guide is how the line changes. The security guide is the account. This page is the review.

pg_hba and its cousins decide who may connect. A line that trusts everyone is a line you do not copy forward. Replace it with the narrow rule you can say aloud, on the lab first.

The previous file is the rollback. A review that edits the live file and leaves no copy is a review you cannot undo. Secrets you find are rotated, not pasted into the ticket.

One lab file, one finding, one reread

Copy a lab config. Run the matching auditor. Choose one finding you understand. Fix it. Run the auditor again and see that finding gone. Other findings stay on the list.

If the finding is a password, rotate it and remove it from the file and the ticket. prompt-for-this is the mark you leave in notes. If the finding is a world-open listen address, bind localhost on the lab and record that production still needs the firewall story.

Do not apply a fix you cannot explain because the tool ranked it first. An unexplained change is how a database stops accepting the application.

A second person reads the diff. The diff is the review. A score is not the review.

A change you can finish

The lab file changes by one finding. Production changes only if this window was already the canary and the same finding was confirmed there.

Rollback is the copied file.

Confirm you may read the file.
Copy it.
Run the matching auditor.
Fix one finding you can explain.
Rerun and see that finding clear.
Rotate a secret if the finding was a secret.
Leave the other findings listed.

Mistakes that outlive the command

a database configuration audit fails in the same few ways. Each one looks finished on the day you type it. The list is here so the ticket can forbid them before the window, not so you can recognise them in an incident review.

Auditing a host you do not administer.
Fixing every finding in one reload.
A password copied into the ticket.
A trust-everyone rule kept because the app broke once.
No previous file.
Calling the auditor a certification.
A listen-on-every-address line left in the lab.
Two config files edited so the cause is unclear.
A production reload from the only session.
Ignoring the engine version.

Decisions to write down before the window

One decision for a database configuration audit: The file is one you may read. The version is written. The previous file is saved. One finding is fixed and rechecked. Other findings remain listed. Secrets are rotated and not printed. The lab does not listen on every address. A trust-everyone rule is absent or scheduled for removal with a reason. The configuration guide owns the reload method. The security guide owns account changes. The tool is not a certification. And a second person read the diff.

The hour you stop

Write the database name, the host, and the clock time before you change anything for a database configuration audit. If this database is serving people and you do not have a copy, this hour is a plan. A plan you can read tomorrow is a success. A change you cannot undo is not.

Use a lab or a restored copy. The rows you read are rows you are allowed to hold. You do not point a client at a database, a cluster, or an account you do not administer. The tools on this site run in the browser. They do not log in, and they do not scan.

prompt-for-this is a reminder that a secret is missing. It is not a password, a token, or a key you save. The real secret stays in the password store. If a connection string, a log, or a ticket still contains a live secret, stop and rotate it. Then delete the copy.

One change. A config line, an index, a grant, and a restore do not share a window. If two things move and the outcome is wrong, you will not know which one did it. The rollback is the previous file or the backup you already tested.

A second person reads the scope aloud: which host, which database, which account. If they cannot find it in the ticket, the ticket is not ready. Silence is not agreement.

The lab listens on localhost. 127.0.0.1 is the address you bind until a firewall story exists. example.com is not your host. A generated file that listens on every address is a file you edit before it runs.

Do not run a statement you cannot undo. A delete or a drop without a backup and a where-clause you have read is the mistake this page is here to prevent. Read the statement. Count the rows it will touch. Then decide.

Keep the previous config and the previous dump. A generator draft is not the previous file. The previous file is what you put back if the new one is wrong. You practised the reload with a second session open when the change can lock you out.

If a step fails twice, stop. The failure is the result. Adding a command from a forum beside a half-applied config produces a database nobody can explain. Rebuild the lab from the copy you kept.

When the checks pass, the next database waits until someone else can repeat the proof from the notes. a database configuration audit is done for this window when the proof is written, not when the client printed a prompt.

This page is a planning guide. It is not a vendor manual, not an official standard, and not legal advice. If an auditor must see the decision, they see the ticket and the evidence, not this paragraph.

Hand the finished note to the neighbouring guide that owns the next step, and leave this database alone until that guide has its own window.

Audit checks before the fix is the new baseline

Confirm this before you call the change done: You administer the instance. The previous file restores. One finding is explained. The rerun is clear for that finding. Other findings are still written down. No secret is in the diff or the ticket. The listen address is localhost on the lab. The version is in the ticket. A second session was open if you reloaded. A second person read the diff. The ticket does not say certified. The next finding has a date or is parked. The hostname in the prompt matches the hostname in the ticket for a database configuration audit. The result line includes the time and the person, not only the command. You can point at the rollback value without searching a chat history. And done is a sentence a second person can repeat: the proof for a database configuration audit happened, and the next host is not started early. If one of those fails, stop.

Tools for this guide

These tools run in the browser on this site. They do not log into your machines.

Guides in this cluster

These supporting pages belong to this pillar.

Companion: Security: Server Hardening Guide.