Home / Databases

DatabasesChecklistIntermediate

Database security baseline: identity, network, encryption, auditing and secrets

A security baseline for any production database. Covers named and federated identities, least privilege, network isolation, TLS, encryption at rest, auditing, secret rotation and regular access reviews.

Deepak Bhardwaj3 min read

Applies toSQL Server, PostgreSQL, Oracle, MySQL; Azure SQL, Amazon RDS, OCI Database (concepts)

Identity and access

  • Use central identity where possible: Windows/Entra ID authentication for SQL Server, Kerberos/LDAP or IAM authentication for PostgreSQL and MySQL, and centrally managed users for Oracle.
  • No shared admin accounts. DBAs use named accounts with elevation, through a PAM tool or just-in-time access.
  • Built-in superusers (sa, postgres, SYS, root) are disabled or renamed where possible, with strong vaulted passwords and alerts on use.
  • Application accounts have only the rights they need: no db_owner, SUPERUSER or DBA roles for apps.
  • Separate accounts for read-only reporting, the app, migrations (DDL) and backups.
-- PostgreSQL: least-privilege app role
CREATE ROLE app_rw LOGIN PASSWORD '...';
GRANT CONNECT ON DATABASE sales TO app_rw;
GRANT USAGE ON SCHEMA app TO app_rw;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA app TO app_rw;
ALTER DEFAULT PRIVILEGES IN SCHEMA app GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO app_rw;

Network

  • Databases sit in private subnets with no public IPs. In PaaS, use private endpoints with public access disabled.
  • Firewall rules allow only app servers and admin jump hosts on the database port.
  • Host firewalls are enabled.

Encryption

  • TLS required for client connections (ssl = on plus hostssl in pg_hba.conf, Force Encryption in SQL Server, require_secure_transport=ON in MySQL, native network encryption or TLS for Oracle).
  • Encryption at rest: TDE (SQL Server, Oracle) or volume and disk encryption. Keys in a KMS or HSM, with rotation.
  • Backups are encrypted.

Auditing

  • Audit logins (failed and successful privileged ones), permission changes, DDL, and access to sensitive tables.
  • Ship audit logs off the server to the SIEM, where DBAs can't change them.
  • Tools: SQL Server Audit, pgaudit, Oracle Unified Auditing, the MySQL Enterprise Audit or Percona audit plugins.

Secrets

  • App connection strings come from a vault (Key Vault, Secrets Manager, OCI Vault, HashiCorp Vault), never from source code.
  • Rotate passwords on a schedule; prefer managed identities or IAM authentication with no password at all.

Hardening

  • Unused features off (xp_cmdshell, OLE automation, untrusted PostgreSQL extensions).
  • Engine patched within the policy window (see the patching policy post).
  • CIS Benchmark scan per engine, with exceptions documented.

Reviews

  • Quarterly access review: the app owner confirms who has access.
  • Sensitive data classified, with masking or row-level security where needed.
  • Non-production gets masked copies of data, not raw production.

Tip

The quickest win in most estates: find application accounts with admin or owner rights and reduce them. In audits, this is the finding that comes up most often.

Related fixes