Database Hardening: PostgreSQL and MySQL in Production

A production database is where the crown jewels live, which makes database hardening one of the highest-leverage activities a defensive team can invest in. PostgreSQL and MySQL are both robust and both, in default or hastily configured states, expose more than they should. This guide takes the blue-team view: it explains the exposure surface of a production database, how attacks against data stores tend to unfold at a high level, and — the heart of the matter — the concrete controls, telemetry, and detections that keep the data confidential, intact, and available. The framing throughout is understand in order to defend, not to exploit.

Why database hardening matters#

Applications get patched, firewalls get rules, and endpoints get EDR, yet the database often sits behind all of that with a trusted-by-default posture. That is exactly why it is targeted: a single weak credential, an over-privileged application account, or an unencrypted backup can hand an adversary the entire dataset at once. Hardening the database reduces the value of every other foothold, because even an attacker who reaches the network segment still faces authentication, least privilege, encryption, and monitoring. Think of it as defence in depth applied to the one asset whose compromise is usually the actual objective of the intrusion.

The exposure surface of a production database#

The exposure surface has several faces. There is the network face — the port the engine listens on and who can reach it. There is the authentication face — how identities prove themselves and how strong those proofs are. There is the authorisation face — what each role can read, write, or administer. There is the data-at-rest face — files, tablespaces, and backups on disk. And there is the observability face — whether anyone would notice abnormal access. A hardened database narrows every one of these; a default install leaves several wide open, most commonly by listening on all interfaces and trusting local connections implicitly.

How attacks against databases unfold at a high level#

Conceptually, an intrusion that targets data tends to follow a recognisable arc. The adversary first reaches a position from which the database is addressable — an application server, a jump host, or an exposed port. They then attempt to authenticate, whether through reused credentials found elsewhere, a weak or default password, or an application account with more rights than it needs. Once connected, they enumerate schemas and privileges, looking for the shortest path to sensitive tables or to administrative capability. Finally they attempt bulk extraction or persistence. Every stage maps to a defensive control, which is why hardening is best planned as a set of barriers along that arc rather than a single wall.

Authentication and access control#

Start by eliminating trust-by-default. In PostgreSQL, review pg_hba.conf so that no rule uses the trust method on anything but tightly controlled local sockets, and prefer scram-sha-256 for password authentication. In MySQL, remove anonymous accounts and any account with a blank or default password, and prefer strong authentication plugins. Give every human and every application its own named role — never a shared superuser. Where the platform supports it, integrate with a central identity provider or short-lived certificate-based authentication so that credentials are rotated and revocable. Enforce strong password policies and, for administrative access, require multi-factor authentication at the jump host or bastion in front of the database.

Network exposure and encryption in transit#

Bind the engine to the specific interfaces it must serve, not to all addresses, and place it in a private network segment reachable only from the application tier and administrative bastions. Use host firewalls and network security groups as a second barrier so that even a misconfiguration does not expose the port to the wider network. Require TLS for every connection and disable unencrypted fallback: in PostgreSQL enforce hostssl rules and set ssl = on; in MySQL require secure transport. Validate certificates on the client side so that a man-in-the-middle cannot silently downgrade or intercept the session. Treat any plaintext database connection in production as an incident to be fixed, not a convenience to be tolerated.

Least privilege and schema permissions#

Over-privileged accounts are the single most common finding in database reviews. Application accounts frequently run as owners or superusers when they only need select, insert, update, and delete on a handful of tables. Grant the minimum, revoke the rest, and use role inheritance to keep it manageable. In PostgreSQL, be deliberate about the public schema and default privileges, and consider row-level security for multi-tenant data. In MySQL, scope grants to specific databases and tables rather than using wildcard grants. Separate the account that runs migrations from the account that serves traffic, so that day-to-day application compromise does not automatically confer schema-altering power.

Encryption at rest and secrets management#

Protecting data on disk closes the path where an attacker or a lost backup yields the dataset directly. Enable storage-level or filesystem encryption for the data directory and, critically, encrypt backups with keys that are managed separately from the database host. Never embed database passwords in application source or configuration files committed to version control; retrieve them at runtime from a secret manager with access logging. Rotate credentials on a schedule and immediately after any suspected exposure. The guiding rule is that possession of a disk, a snapshot, or a backup archive should not be sufficient to read the data without also possessing keys held under separate control.

Detection: logging and monitoring#

Hardening without detection leaves you blind to the attempts that get through. In PostgreSQL, enable connection and disconnection logging, log failed authentications, and consider the pgaudit extension for statement-level auditing of sensitive objects. In MySQL, enable the audit log plugin and the general or slow query logs as appropriate, and capture failed-login events. Ship these logs to a central SIEM and alert on the meaningful signals: a spike in authentication failures, a login from an unexpected host or at an unusual hour, privilege grants, large or unusual result-set volumes suggestive of bulk extraction, and any change to auditing configuration. Monitor the health of the log pipeline itself, because silenced logging is a common precursor to data theft.

Backup, recovery and integrity#

Availability and integrity are part of security, not separate from it. Maintain tested, encrypted backups with a defined retention, and store at least one copy in a location an attacker who compromises the primary cannot reach or delete. Rehearse recovery regularly; a backup that has never been restored is a hope, not a control. Protect backups with the same least-privilege and monitoring discipline as the live database, because an unguarded backup repository is simply a second, quieter copy of everything. For ransomware resilience specifically, immutable or write-once backup storage ensures that an intruder with database access cannot also destroy the means of recovery.

Common pitfalls#

Recurring mistakes include leaving the engine listening on all interfaces, keeping default or shared administrative accounts, granting application users far more than they need, and storing connection strings with embedded passwords in repositories. Teams often enable encryption in transit but never enforce it, so clients silently fall back to plaintext. Others encrypt the live volume but leave backups in the clear. A frequent detection gap is logging that exists but is never forwarded or reviewed, so it helps only during a post-incident autopsy. Finally, beware performance-driven shortcuts that disable authentication or auditing for a batch job and are never re-enabled.

Hardening checklist#

A defensive starting point: (1) remove trust-by-default, anonymous, and default accounts; (2) enforce strong, rotated, per-identity credentials with MFA on administrative paths; (3) bind to specific interfaces inside a private segment behind host and network firewalls; (4) require and validate TLS for every connection; (5) apply least privilege to every role and separate migration from runtime accounts; (6) encrypt data at rest and encrypt backups with separately managed keys; (7) pull secrets from a manager, never from source control; (8) enable connection, failed-login, and statement auditing and forward it to a SIEM; (9) alert on authentication anomalies, privilege changes, and bulk extraction; (10) keep tested, immutable, off-primary backups and rehearse recovery.

FAQ: Is encryption in transit enough on a private network?#

No. A private network reduces exposure but does not eliminate lateral movement, misconfiguration, or an insider on the same segment. Encryption in transit protects the session from interception and downgrade regardless of where the network boundary sits, and it should be combined with least privilege, at-rest encryption, and monitoring. Defence in depth assumes any single layer, including the network perimeter, can fail.

FAQ: Should the application use a superuser for convenience?#

Never in production. An application account should hold only the data-manipulation rights it genuinely needs on the specific objects it touches. Running as a superuser means that any application-layer compromise — an injection flaw, a stolen token — immediately becomes total database compromise. Separate accounts for runtime, migrations, and administration so that the blast radius of any single credential is contained.

Conclusion#

Hardening PostgreSQL and MySQL in production is about placing barriers along the whole path an adversary would travel toward the data: authentication that resists reuse, network isolation that limits reach, least privilege that contains any single foothold, encryption that neutralises stolen disks and backups, and detection that turns quiet abnormal access into a loud alert. None of these is exotic, and together they turn the most valuable asset in the estate from a soft target into a monitored, defensible one. Treat the checklist as living, review it after every change and every incident, and verify the live configuration rather than trusting the intended one.