Episode 32 · Module 7 · Data Protection

Database Security Hardening

19 May 2026 · 7:57 · Security for Legal SaaS

7:57 7:57

Every security control we have discussed in this series — authentication, encryption, input validation, access control — exists to protect the data that ultimately lives in your database. Client communications, case strategy, financial records, privileged documents — they all converge in one place. If an attacker reaches your database with unrestricted access, every other defence has failed. This episode covers the layers of protection that surround a production database: network isolation, connection security, access control, audit logging, and backup protection.

Today’s Lesson

Security for Legal SaaS — Episode 32: Database Security Hardening

Your Database Is the Crown Jewels

This episode covers the layers of protection that surround a production database: network isolation, connection security, access control, audit logging, and backup protection. We will use PostgreSQL as the primary example because it is the most common database in modern legal SaaS, but the principles apply to any relational database.

Network Isolation: Databases Should Never Face the Internet

The most fundamental database security rule is also the most frequently violated: your database should not be reachable from the public internet. It should sit in a private subnet — a network segment that has no public IP address and no route to the internet. The only systems that can connect to it are your application servers, which sit in a separate subnet with controlled ingress.

Architecture	Risk Level	Description
Database with public IP	Critical	Directly attackable from anywhere on the internet
Database in private subnet, app in public subnet	Moderate	Only reachable via the application; but app compromise = DB access
Database in private subnet, app in private subnet, load balancer public	Recommended	Database is two network hops from the internet
Database in private subnet with VPC peering / Private Link	Strongest	No internet path exists; accessed only via private cloud network¹

On AWS, this means placing your RDS instance in a VPC (Virtual Private Cloud — an isolated private network, as we covered in Episode 11) with no public accessibility. On GCP, Cloud SQL instances should use private IP only. Security groups (AWS) or firewall rules (GCP) should restrict inbound connections to only the IP addresses or security groups of your application servers — not `0.0.0.0/0`, which means "anywhere."²

Legal SaaS reality check: Halcyon tracked over 200 ransomware incidents targeting law firms between 2025 and early 2026. The INC Ransom group specifically exploits known vulnerabilities in remote access tools to reach internal databases. Network isolation is not theoretical — it is the primary barrier against these attacks.³

Connection Security: TLS Required, Always

Every connection between your application and the database must be encrypted using TLS (Transport Layer Security, which we covered in Episode 13). PostgreSQL supports TLS natively, but it is not enabled by default in many configurations.

Configuration requirements:

Set `sslmode=verify-full` on the client. This ensures the client verifies the server's TLS certificate and checks that the hostname matches. Weaker modes like `sslmode=prefer` will silently fall back to unencrypted connections if TLS negotiation fails — which is exactly what a man-in-the-middle attacker causes.⁴
Use certificates from your internal CA or cloud provider. AWS RDS provides managed certificates. For self-hosted PostgreSQL, generate certificates through your PKI (public key infrastructure, from Episode 15) or HashiCorp Vault's PKI secrets engine.
Reject unencrypted connections. In `pg_hba.conf`, use `hostssl` instead of `host` to require TLS for all connections.

Connection Pooling Credentials

Most production applications use a connection pool — a set of pre-established database connections shared across request threads. The pool itself authenticates to the database using a service account. This creates a credential management challenge:

The pooler (e.g., PgBouncer, built-in pool in your ORM) needs database credentials.
Those credentials must be rotated without dropping active connections.
Dynamic secrets from a secrets manager (as covered in Episode 30) are ideal: the pool authenticates with short-lived credentials that are automatically rotated.

Principle of Least Privilege: Minimal Permissions

Your application's database account should have the minimum permissions necessary for its function. In Episode 8, we introduced this concept in the context of SQL injection. Here it applies to the database account itself:

Permission	Your Application Needs	Your Application Does NOT Need
SELECT, INSERT, UPDATE, DELETE on application tables	Yes	—
CREATE TABLE, ALTER TABLE, DROP TABLE	No (run migrations with a separate admin account)	Yes — your app should never restructure the schema at runtime
SUPERUSER / rds_superuser	Never	Yes — this bypasses all access controls
Access to `pg_catalog` system tables	Rarely	Attackers use these to map the database structure

Create separate database roles for different application functions. Your read-only reporting service should not have write access to the case management tables. Your search indexer should not have access to billing data. If your application has a background job that sends email notifications, it needs access to the notification queue — not to client documents.⁵

Row-Level Security Revisited

In Episode 8, we covered PostgreSQL's Row-Level Security (RLS) as a defence against SQL injection escalation. RLS is equally critical for multi-tenant legal SaaS: every query is automatically filtered by the current tenant's identifier, enforced by the database engine — not by application code that might have a bug.

sql

-- Enable RLS on the documents table
ALTER TABLE documents ENABLE ROW LEVEL SECURITY;

-- Policy: users can only see documents belonging to their tenant
CREATE POLICY tenant_isolation ON documents
  USING (tenant_id = current_setting('app.current_tenant')::uuid);

Even if application code fails to include a `WHERE tenant_id = ?` clause, the database rejects cross-tenant access.⁶

Audit Logging: Who Queried What, When

Database-level audit logging records every operation — who connected, what they queried, and when. This is distinct from application-level logging (which records what the application did) and is critical because it captures direct database access that bypasses the application.

For PostgreSQL, the pgAudit extension provides detailed session and object-level audit logging:⁷

Log Type	What It Captures	Use Case
Connection logging (`log_connections`, `log_disconnections`)	Every connection attempt and disconnection	Detecting unauthorised access attempts
Statement logging (pgAudit)	SQL statements executed, with parameters	Forensic investigation; compliance audits
Object-level audit (pgAudit)	Access to specific tables or columns	Monitoring access to privileged client data

The CIS PostgreSQL Benchmark — a prescriptive collection of security controls from the Center for Internet Security — mandates enabling `log_connections` as a baseline requirement. It also recommends configuring `log_statement = 'ddl'` at minimum to capture schema changes.⁸

Storage and retention: Audit logs must be shipped to a separate system (a SIEM — Security Information and Event Management, as we introduced in Episode 7) where they cannot be tampered with by someone who compromises the database server. If the attacker can delete the logs, the audit trail is worthless.

Backup Encryption and Access Controls

Database backups are copies of your crown jewels. They deserve the same protection as the production database — possibly more, because backups are often stored in less-monitored locations.

Requirements:

Encrypt backups at rest. AWS RDS supports automated encrypted backups using KMS keys (from Episode 29). For self-hosted databases, use `pg_basebackup` with output piped through encryption.⁹
Restrict backup access. The IAM roles or accounts that can access backup storage should be separate from those that access the production database.
Test restore procedures. An encrypted backup you cannot restore is not a backup. Regularly test that you can decrypt and restore from backups — including with rotated keys.
Apply the same network isolation to backup storage. S3 buckets (or equivalent) holding database backups should not be publicly accessible. Enable S3 Block Public Access and use VPC endpoints for access.¹⁰

The Hardening Checklist

Control	Default State	Hardened State
Public accessibility	Often enabled	Disabled; private subnet only
TLS for connections	Optional	Required (`hostssl` in pg_hba.conf)
Default `postgres` superuser	Exists with password	Renamed or disabled; no direct login
Application account permissions	Often SUPERUSER for convenience	Minimal: DML only, no DDL, no superuser
Audit logging	Disabled	pgAudit enabled; logs shipped to SIEM
Backup encryption	Depends on provider	Always on; KMS-managed keys
pg_hba.conf	Permissive defaults	Strict IP allowlist per role

What's Next

Episode 33 begins Module 8: AI-Specific Security with Prompt Injection Attacks — why the most dangerous vulnerability in AI-powered legal tools is fundamentally different from SQL injection, and why there is no parameterised query equivalent to fix it.

Sources & Further Reading

Sources & references

AWS, Amazon VPC — Private Subnets.
AWS, Security Best Practices for Amazon RDS.
Halcyon, INC Ransom Group Mounts Rapid Campaign Against Law Firms.
PostgreSQL, SSL Support — Client Verification.
CIS, CIS PostgreSQL Benchmarks.
PostgreSQL, Row Security Policies.
pgAudit, PostgreSQL Audit Extension.
SOCFortress, PostgreSQL Hardening Guide Aligned with CIS Benchmark.
Crunchy Data, Secure PostgreSQL 14 with the CIS Benchmark.
Embroker, Law Firm Cyberattacks: Stats and Trends for 2025.
HexaCluster, PGDSAT — PostgreSQL Database Security Assessment Tool.
CodeOps Trek, Secure Your PostgreSQL Database: Dockerized & Hardened with CIS Benchmarks.

Alice: Welcome back to Security for Legal SaaS. I'm Alice.

Dan: And I'm Dan. Episode 32 — database security hardening. Alice, we've spent the last few episodes on encryption, key management, secrets, and PII. This feels like the episode where all of that converges — because the database is where everything actually lives.

Alice: That's exactly right. Every security control we've discussed — authentication, encryption, input validation, access control — exists to protect data that ultimately lives in a database. Client communications, case strategy, privileged documents, financial records. If an attacker reaches your database with unrestricted access, every other defence has failed. So this episode is about the last line of defence — and ideally the first line too.

Dan: Mm. Let's start with the most basic question. Where should the database sit in your infrastructure?

Alice: As far from the internet as physically possible. The most fundamental database security rule — and the most frequently violated — is that your database should not be reachable from the public internet. Period. It should sit in a private subnet, which is a network segment with no public IP address and no direct route to the internet. The only things that can talk to it are your application servers, which sit in a different subnet. Think of it like a vault inside a building. The public walks into the lobby. Employees can reach the offices. But the vault is behind a locked corridor that only authorised staff can access — and there's no window to the street.

Dan: And in practice, on a cloud provider like AWS?

Alice: On AWS, your RDS database instance goes in a VPC — a Virtual Private Cloud, which we covered back in Episode 11 — with public accessibility explicitly turned off. Then you set up security groups — essentially firewall rules — that only allow inbound connections from your application servers' security group. Not from 0.0.0.0/0, which means "anywhere on the internet." That's the single most dangerous misconfiguration in cloud databases, and I've seen it in production.

Dan: Hmm. That's a scary default. What about the connections themselves?

Alice: <sigh> TLS. Every connection between your application and the database must be encrypted with TLS — which we covered in Episode 13. PostgreSQL supports it natively, but here's the catch — it is not enforced by default in many configurations. You have to explicitly set your client's connection mode to "verify-full," which means the client checks the server's certificate and verifies the hostname. Weaker modes like "prefer" will silently fall back to an unencrypted connection if TLS negotiation fails. And that silent fallback is exactly what a man-in-the-middle attacker exploits.

Dan: Mm-hmm. So encrypt the connection and verify you're talking to the right server. What about the account the application uses to connect?

Alice: This is where the principle of least privilege — which we first discussed in Episode 8 — becomes critical. Your application's database account should have the absolute minimum permissions it needs. It needs to read, write, update, and delete records in the application tables. It does not need the ability to create or drop tables — that's for database migrations, which should run under a separate admin account. And it absolutely should never have superuser access. Superuser bypasses every access control PostgreSQL has.

Dan: Yeah. And I imagine this matters even more for multi-tenant legal SaaS — where one database holds data for many different law firm clients?

Alice: Exactly. And that's where Row-Level Security comes back — we introduced it in Episode 8 in the context of SQL injection. RLS is a PostgreSQL feature that automatically filters every query based on the current user's tenant identifier. You define a policy that says "this user can only see rows where the tenant ID matches their own." Even if the application code has a bug — a missing WHERE clause, a broken filter — the database engine itself blocks cross-tenant access. It's defence in depth at the data layer. Your application code should filter by tenant. RLS guarantees it.

Dan: Mm. That's a powerful safety net. What about logging — knowing who accessed what?

Alice: Database audit logging is your forensic record. It captures every connection, every query, every schema change — at the database level, not the application level. This matters because it catches direct database access that bypasses your application entirely. For PostgreSQL, the pgAudit extension is the standard. It provides detailed session and object-level logging. The CIS PostgreSQL Benchmark — a security hardening guide from the Center for Internet Security — mandates enabling connection logging as a baseline and recommends statement logging for all data definition changes at minimum.

Dan: And where do those logs go?

Alice: Critically — not on the database server itself. If an attacker compromises the database and the audit logs are stored on the same machine, the first thing they'll do is delete the logs. Your audit trail disappears. The logs need to be shipped to a separate system — a SIEM, which we introduced back in Episode 7 — where they're stored immutably. The attacker would need to compromise two independent systems to cover their tracks.

Dan: Yeah, that makes sense. Now, backups — those seem like an obvious target too.

Alice: Backups are copies of your crown jewels. An unencrypted database backup stored in a misconfigured cloud storage bucket is every attacker's dream — all the data, none of the access controls. Requirements are straightforward: encrypt backups at rest using KMS keys from Episode 29. Restrict access so the accounts that can reach backup storage are separate from production database accounts. And test your restores — regularly. An encrypted backup you can't actually decrypt and restore is not a backup. It's a false sense of security.

Dan: Mm. Any real-world context on why this matters for law firms specifically?

Alice: Halcyon tracked over 200 ransomware incidents targeting law firms between 2025 and early 2026. The INC Ransom group specifically exploits vulnerabilities in remote access tools — Citrix, Fortinet, SimpleHelp — to reach internal networks, and from there, the database. The average cost of a data breach for law firms in 2024 was 5.08 million dollars. Network isolation, encrypted connections, least-privilege accounts, audit logging, encrypted backups — these aren't theoretical best practices. They're the controls that determine whether a breach costs you five million dollars or whether the attacker hits a wall and moves on to an easier target.

Dan: Next episode — we start Module 8, AI-Specific Security, with Prompt Injection Attacks. Why the biggest vulnerability in AI-powered legal tools is fundamentally different from anything we've covered so far.

Alice: Until then, I'm Alice.

Dan: And I'm Dan.

Alice: Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.

Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.