Database security and hardening
Databases hold the records an attacker actually wants, yet they are often installed with defaults and left alone. Hardening a database means limiting who can connect, giving each application only the rights it needs, encrypting data where it lives and in transit, logging who did what, and proving the backups restore.
What we do
- Database configuration review against a hardening baseline
- Role and privilege cleanup
- Audit logging design and retention
- Encryption at rest and in transit
- Backup and restore testing
- Tenant isolation with row-level security
- Migration and upgrade planning
On PostgreSQL our team works with host-based authentication rules in pg_hba.conf, TLS for connections, roles with least privilege, row-level security for multi-tenant data, the pgAudit extension for audit logging and pgBackRest for backups with point-in-time recovery. On Microsoft SQL Server we work with Transparent Data Encryption, Always Encrypted for columns the database administrator should not read, and Always On availability groups.
This group links to our Cybersecurity and Tailored Software practices. Encryption at rest protects stolen disks and backups, not a compromised application account, so we pair it with access control and monitoring. These are tools our team has experience with, not partnerships.
Leading platforms we work with
- PostgreSQL
- Microsoft SQL Server
- pgAudit
- pgBackRest
Platforms and practices
- PostgreSQL pg_hba.conf and TLS
- Least-privilege database roles
- Row-level security for multi-tenant data
- pgAudit session and object logging
- pgBackRest backups and point-in-time recovery
- SQL Server Transparent Data Encryption
- SQL Server Always Encrypted
- Connection secrets kept out of application code
References
- PostgreSQL documentation: pg_hba.conf
- PostgreSQL documentation: row security policies
- pgAudit
- pgBackRest
- Microsoft Learn: Always Encrypted
- Microsoft Learn: Transparent Data Encryption
Sources last checked .
Product names are trademarks of their owners and are listed to describe our experience; they do not imply endorsement or partnership.
How we use Database security and hardening for clients
Cybersecurity
We find out whether everything you run is safe from attackers, then we fix it.
Learn moreTailored Software
Software built around your business in weeks, and you own the code.
Learn moreDisaster Recovery Planning
Know how long you can be down, and prove you can come back before the day you must.
Learn moreFrequently asked questions
Direct answers to the questions we hear most. Something else on your mind?
Send us a messageDoes encrypting the database mean it is safe from attackers?
No. Encryption at rest, such as Transparent Data Encryption on SQL Server, protects stolen disks, snapshots and backup files. An attacker who signs in as an application account or an administrator sees the data decrypted. That is why we pair encryption with least-privilege roles, network restrictions and audit logging. Always Encrypted is the option for columns that even the database administrator should not read.
How do you harden a database without breaking the application?
We start by recording what the application actually connects as and what it actually runs, then give it a role with only those rights, move connections to TLS, and tighten network access rules such as pg_hba.conf on PostgreSQL. Changes go through a test copy first, with a rollback plan. The riskiest change, removing broad rights from an existing account, is staged and monitored.
Is a backup the same as being able to recover?
No. A backup you have never restored is a hope. We test restores on a schedule, including point-in-time recovery with a tool such as pgBackRest on PostgreSQL, and we time them so you know how long recovery really takes. Keeping at least one copy where an attacker with your admin credentials cannot delete it is part of the design.
What does audit logging record, and who reads it?
Logging such as the pgAudit extension on PostgreSQL records who ran which statements against which objects. It is only useful if someone looks, so we choose what to log to keep the volume manageable, send the logs to a system the database administrators cannot edit, and set alerts for things like a new administrator account or a bulk export.