Database Hardening: PostgreSQL, MySQL, and SQL Server Essentials

Database hardening is not an encryption project. It is the removal of every unnecessary path to production data, followed by proof that the needed paths still work.

Teams get this wrong by treating the database as a box with a port and a password. The real surface includes service accounts, administrators, network routes, extensions, backup systems, replication, maintenance jobs, cloud roles, client drivers, and application code. Encrypting the file does not repair an open login or a role that can read every customer record.

The CISA Known Exploited Vulnerabilities catalog snapshot released September 2, 2026 contains 1,694 entries. A direct product filter returns two Microsoft SQL Server entries, including CVE-2019-1068 added on August 26, 2026. It returns no entries named PostgreSQL or MySQL. That absence is not a safety claim. KEV is a focused list of confirmed exploitation, not a database vulnerability inventory.

What does database hardening include?

Database hardening reduces reachability, authenticates every actor, grants the minimum required authority, protects data in transit and at rest, removes unused capability, records material actions, and proves recovery. Each control needs an effective state check. Configuration intent is not enough.

The work fits inside the system hardening pillar. Operating system and cloud controls protect the database process, while the engine controls protect schemas, roles, functions, and data. The CIS Benchmarks guide explains how to select a maintained source and document tailoring. This guide handles the common decisions across PostgreSQL, MySQL, and SQL Server.

What must you know before changing a database?

Name the engine, edition, exact version, support date, host, service owner, data owner, recovery owner, and business role. Inventory listeners, allowed sources, accounts, roles, extensions, linked servers, replication, backup destinations, encryption keys, audit targets, maintenance jobs, and client versions. A connection diagram should show applications, administrators, reporting tools, migration jobs, and emergency access.

Preserve rollback before touching authentication or transport. Confirm console or private administrative access, export the current configuration, back up role grants, verify a recent restore, and keep a tested client for the new protocol. Authentication changes fail at the client boundary more often than the server boundary.

Public database reachability should be rare and explicit. Limit inbound traffic to application nodes, approved administration paths, and required replication peers. Then test denial from an unauthorized network. A private address does not prove isolation if routing and security group rules still permit broad access.

How should database identities and privileges be designed?

Separate human administration, application runtime, migration, reporting, backup, and monitoring identities. Each has a different job. An application account should not own its schema, create new administrators, read other databases, or execute operating system commands unless the application has a documented reason.

Grant permissions to roles, then assign identities to those roles. Avoid direct grants that disappear into a thousand account records. Remove dormant logins, default accounts, shared administrator credentials, wildcard source hosts, and permanent emergency access. Make temporary elevation expire.

Review default privileges as carefully as existing objects. A carefully restricted role can become broad again when a migration creates new tables under a permissive owner. Test what the application can do against current objects and one newly created object.

How do you harden PostgreSQL authentication and transport?

PostgreSQL reads pg_hba.conf from top to bottom and uses the first matching rule. Put narrow allowed networks before explicit rejection. Use hostssl for remote connections that must use TLS, prefer SCRAM for password authentication, and restrict listen_addresses to intended interfaces.

Test client certificate validation as well as server encryption. A client that requests TLS but does not verify the server identity can still trust the wrong endpoint. Inspect pg_hba_file_rules for parse errors, then connect as the application role from an allowed source and a blocked source. The reload command applies the access file and reloadable settings. A changed listen_addresses value requires a planned server restart.

PostgreSQL 18 is the recent change older hardening pages often miss. The project's September 25, 2025 release notice added OAuth 2.0 authentication, added a server setting for TLS 1.3 cipher suites, and deprecated MD5 password authentication. Migration still needs client testing. Set SCRAM for newly changed passwords, rotate existing passwords, then change the matching access rules after old clients are gone.

How do you harden MySQL network access?

Bind MySQL to the intended service address, require secure transport, disable local file loading unless the application proves it needs it, and define accounts with narrow source hosts. The server's transport control rejects plain TCP connections while still allowing secure local socket access.

Oracle's MySQL 8.4 encrypted connection documentation confirms that require_secure_transport permits encrypted TCP, Unix sockets, or shared memory and rejects plain TCP. It also warns clients to verify host identity for protection against a sophisticated interception attack. Encryption without identity validation solves only half the transport problem.

Review powerful MySQL privileges such as FILE, PROCESS, SUPER, role administration, and plugin administration. Protect the plugin directory and option files at the operating system layer. A database grant model cannot defend files that a privileged service account can replace.

Which SQL Server settings deserve early attention?

Prefer Windows or Microsoft Entra integrated identity where the environment supports it. Disable unused SQL logins, separate server and database roles, and use CONTROL SERVER only where its ability to respect explicit denial is understood. Keep the service account out of broad operating system groups.

These are observation queries. Investigate before changing a login or database option. The TRUSTWORTHYflag, cross database ownership chaining, and xp_cmdshell can expand authority far beyond one schema, but applications sometimes depend on them. Replace the dependency, test, then disable the capability.

Microsoft's SQL Server security best practices recommend Force Strict Encryption with TDS 8.0 for SQL Server 2022 and later, minimum permissions, protected service accounts, auditing, and encryption at rest. Confirm every client driver supports the chosen transport before enforcement.

How should encryption, secrets, and nonproduction data work?

Encrypt network traffic, database files, transaction logs, backups, and temporary storage according to data class. Keep keys outside the data they protect, restrict key administration, rotate on a defined schedule, and test recovery when the primary key service is unavailable. Encryption that nobody can restore is data loss.

Do not copy production data into development by habit. Mask or synthesize sensitive values before they cross the boundary, limit extract tools, and log bulk exports. The same rule applies to support snapshots and analyst notebooks. Data tends to leave the hardened server through an approved workflow that nobody revisited.

Secrets should arrive through an approved secret service or workload identity, not source code, command lines, shell history, image layers, or shared configuration repositories. Rotate a database credential only after you know every client that uses it. Dual credential support or staged role replacement can prevent a rushed outage.

What must database audit and recovery prove?

Record authentication failures, administrator access, role and grant changes, schema changes, audit policy changes, backup operations, and bulk data access. Send material events away from the database host. Alert when the expected source stops reporting, because silence can mean collection failure rather than good behavior.

Keep query logging proportional. Logging every statement can capture secrets, personal data, and enough volume to impair the service. Start with decisions and privilege events, then add query detail for sensitive roles or investigations. Protect the logs from database administrators who should not be able to erase their own trail.

A backup job success message proves a write occurred. It does not prove recovery. Restore into an isolated environment, recover keys, validate integrity, exercise application reads, confirm current roles and hardening, and measure the time. The restore target should not inherit public routes or production credentials.

How do you roll out database hardening safely?

1. Capture effective state. Export listeners, roles, grants, transport, options, extensions, audit policy, and recovery results.
2. Close public reachability. Preserve approved application, administration, replication, identity, backup, and monitoring paths.
3. Separate identities. Move applications, migrations, people, and monitoring into roles with different authority.
4. Upgrade transport. Test client libraries and certificate validation before rejecting old connections.
5. Remove dangerous capability. Disable unused extensions, functions, linked services, and broad grants one dependency at a time.
6. Prove recovery and monitoring. Restore, run application checks, inspect audit events, and store timestamped evidence.

Use the hardening automation workflow for canaries, approval, and rollback. Pair configuration findings with the vulnerability exploitability framework so a reachable production database outranks an isolated test system with the same version finding.

What does weak database privilege review cost?

Suppose 80 databases each have 45 login and role relationships. That creates 3,600 relationships. At three minutes of manual review per relationship, the first pass costs 180 hours. Group by application role, shared grant pattern, and owner instead. If one migration template created 1,200 excessive grants, fix the template and verify its databases as a cohort.

Queue order should reflect reachability, data value, privilege, exploitation, and recovery. A disabled account with an old hash is not the same problem as an internet reachable administrator. Context turns a flat checklist into a work plan.

Which database hardening mistakes cause outages or false confidence?

The biggest mistake is changing authentication before testing every client. Others include enabling encryption without certificate validation, removing a role that owns objects, logging sensitive query values, storing keys beside backups, disabling a feature before replacing its dependency, and scanning configuration without reading the live engine state.

Another failure is reporting one percentage across unlike databases. A missing audit setting on a development instance and an open administrator on a payment database should not become two equal red cells. Report the path, consequence, owner, and evidence age.

Frequently asked questions

What is the first database hardening step?

Map every connection and owner, preserve recovery access, then remove public or unnecessary reachability. You need to know which applications, people, and services will fail before changing authentication or transport.

Is encryption at rest enough to protect a database?

No. It protects files and backups when implemented correctly, but an authorized session can still read data. Reachability, identity, privilege, transport, audit, masking, key management, and recovery remain separate controls.

Should PostgreSQL, MySQL, and SQL Server use one baseline?

Use one set of outcomes, then map each outcome to engine specific settings and evidence. The engines differ in authentication, privilege, audit, encryption, extensions, and operational failure modes.

How often should database hardening be verified?

Verify after engine upgrades, configuration deployment, role or schema change, network change, restore, and on a fixed cadence based on data sensitivity. Track missing and stale evidence as unknown, not passed.

The executive takeaway

Choose one important database. Map its connections, remove one unnecessary route, split the application from administrative authority, enforce verified transport, and restore a backup into isolation. Then read the live state again. Deep endpoint context with AI driven analysis can help connect host and engine evidence, but the database owner must approve the path that remains. Protect the routes to the data, not just the file that stores it.