Database Encryption in Transit

TLS for DB connections.

Overview

Database encryption in transit enforces TLS for every database connection. Encryption at rest protects the data on disk; encryption in transit protects it on the wire between the application and the database. Without it, a network-position attacker (compromised host on the same VPC, sniffer on a misconfigured switch, MITM at the cloud edge) reads queries and results in plaintext. The discipline is making TLS the only acceptable connection mode and verifying it with verify-full to prevent MITM attacks.

• TLS for DB connections. Per-connection TLS required; the database refuses non-TLS connections at the engine level.
• Server certificate verification. Per-client verify-full mode; client validates the server certificate against a trusted CA, preventing MITM.
• Client certificate (mTLS). Per-client certificate for high-sensitivity workloads; mutual TLS authenticates both ends.
• Per-cluster CA management plus enforced policy. Per-cluster CA managed alongside the database; per-database TLS-required policy at the engine level.

The approach

The practical approach is to enforce TLS at the database engine (refuse non-TLS connections), require verify-full mode on all clients (sslmode=verify-full in libpq, equivalent in other drivers), add mTLS for high-sensitivity workloads, manage the CA per cluster as part of the database operational surface, and document the per-database TLS policy in the security handbook so the rules are auditable.

• verify-full mode. Per-client certificate verification; sslmode=verify-full in libpq prevents MITM by validating the server cert.
• mTLS where needed. Per-client certificate for high-sensitivity workloads; mutual TLS authenticates both ends.
• Per-cluster CA management. Per-cluster CA managed alongside the database; rotation aligned with database major-version upgrades.
• Connection rejection without TLS plus documented policy. Per-database engine refuses non-TLS connections; per-database rationale committed to the security handbook.

Why this compounds

Encryption-in-transit discipline compounds across services. Each protected connection reduces the attack surface for network-position attackers; each verify-full client prevents MITM at the connection layer; the team builds a security posture that survives perimeter compromise. The opposite, where TLS is "available" but not enforced, lets the next misconfigured client open a hole nobody notices.

• Security. verify-full protects against MITM; the network-position attacker reads ciphertext rather than queries.
• Compliance. Per-database TLS audit satisfies enterprise security requirements; opens markets that require encrypted database traffic.
• Operational fit. Right policy matches workload; high-sensitivity data gets mTLS, general-purpose workloads get TLS plus verify-full.
• Institutional knowledge. Each protection teaches database security patterns; the team learns where defence-in-depth matters.

Encryption-in-transit discipline is a security discipline that pays off across years. Nova AI Ops integrates with database telemetry, surfaces TLS patterns, and supports the team’s database security discipline.