Database security review: SQL Server, MongoDB and PostgreSQL
A database security review checks how a database is configured to let people and applications in: who can log in, from where, with which privileges, and what is recorded when they do. We review Microsoft SQL Server, MongoDB and PostgreSQL, and the application accounts that talk to them, from configuration and read access you provide.
What a database security review covers
Authentication and roles
On SQL Server we check the mix of Windows and SQL logins, members of sysadmin, and whether the sa account is disabled. On PostgreSQL, the rules in pg_hba.conf, superuser roles and default privileges on new schemas. On MongoDB it starts with a blunt question: is access control switched on at all.
Network exposure
Which addresses the server listens on and who can reach them. A database answering on a public address is about as serious as a finding gets.
Encryption at rest and in transit
Whether connections require TLS or merely allow it, whether data files and backups are encrypted, and who holds the keys.
Logging who did what
Whether failed logins, privilege changes and reads of sensitive tables are recorded, and whether those audit logs land somewhere the database administrator cannot edit.
Backups
Where copies go, who can read them, and whether a restore has actually been tried. A dump file on a shared drive is a full copy of the database with none of its access controls.
How applications should connect to a database
A web application that reads and writes orders does not need to drop tables or read the payroll schema. It often can, because its account was set up once with owner rights and never narrowed.
We look for one account per application, rights limited to the objects it uses, separate accounts for migrations, and credentials held in a secrets store rather than a configuration file. Parameterized queries resist injection. SQL built by joining strings of user input does not, and neither does a MongoDB query object assembled from raw request data. The coding side of this sits in secure development.
How the review is done
We work from configuration files, system catalogue queries and exports you run, or from a read-only login you grant for the period of the work. Each engine is checked against its vendor’s own security guidance, so every finding points to a documented setting.
Where the databases run in a cloud account, pair this with a cloud security review of the surrounding network and identity settings.
What you receive
| Deliverable | What it is for |
|---|---|
| Findings report, per engine | Each finding tied to the setting, the risk and the vendor guidance behind it |
| Role and privilege map | Who and what can reach each database, and with which rights |
| Remediation plan | Ordered by risk and by how likely a change is to break an application |
| Re-review | Checks the fixes against the original findings |
How the work is bounded
The scope is agreed in writing before work starts, and the engagement is quoted in writing with it.
SecHB does not issue certifications, attestations or audit opinions: those come from accredited certification bodies, CPA firms and QSAs. The work here is what an organization does to be ready for them.
Nothing here is legal advice. Where a question turns on the law, the work is done alongside the client’s counsel, not instead of them.
Questions we are asked
What access do you need for a database review?
Read access to configuration and system catalogues, or exports of them, is enough. We do not need to read the data your tables or collections hold, and nothing is changed on the server during the review.
Can you review production databases?
Yes, and production is usually where the findings that matter are. The review reads configuration and metadata only, so the load it adds is a small number of catalogue queries, which we schedule with you.
Do you review managed databases like Azure SQL or MongoDB Atlas?
Yes. Managed services such as Azure SQL, Amazon RDS or MongoDB Atlas move some controls to the provider, and the review says which settings are still yours. Those are usually network exposure, roles and audit logs.
Does the review find SQL injection?
Partly. We read how the application connects and queries, and flag string-built SQL or unfiltered query objects where we see them. Proving that an injection works is testing, which is scoped separately. See penetration testing.
Start with the databases that hold the most
Tell us which engines you run, roughly how many instances, and what they hold. The reply sets out what a review would cover. Regulated lenders and insurers may also want security for credit unions and insurers, and every service is listed on security services.