What does this guide solve?
Database security is more than password policy. Network, identity, least privilege, encryption, auditing, OS hardening, patching, secret management and backup security must work together.
Network isolation
Do not expose database ports directly to the internet; use application subnets/VLANs, firewalls/security groups and VPN/bastion layers.
Separate management access from application traffic where practical.
Authentication and authorization
Use named identities, role-based permissions and least privilege instead of shared administrator accounts.
Store service credentials in vault/secret-management systems rather than source code or configuration repositories.
TLS and encryption at rest
Protect client-server traffic with TLS and evaluate engine-supported TDE/tablespace/storage encryption for sensitive data.
Keep encryption keys in a separate security domain and test key rotation and recovery procedures.
Auditing and monitoring
Audit failed logins, privilege changes, schema changes, administrative activity and sensitive-data access according to risk.
Forward audit logs to independent central logging/SIEM.
Patching and backup security
Manage database engine, OS, drivers/clients and backup agents as one patch surface.
Separate backup-repository credentials, use immutable/offsite copies and perform restore tests.
Frequently Asked Questions
Is changing the database port enough?
No. Port changes are not a primary security control; use network isolation, firewalls and strong authentication.
Does TDE make a database completely secure?
No. TDE reduces storage-theft risk; application compromise, credential theft and authorized misuse require other controls.
Why should backup use separate credentials?
Separating privilege domains reduces the chance that a production compromise can also delete or encrypt backups.
Official technical sources
- https://www.postgresql.org/docs/current/security.html
- https://dev.mysql.com/doc/refman/8.4/en/security.html
- https://learn.microsoft.com/sql/relational-databases/security/
- https://docs.oracle.com/en/database/oracle/oracle-database/23/dbseg/
- https://www.mongodb.com/docs/manual/security/
- https://mariadb.com/docs/server/security/
Evaluate Your Database Infrastructure
We can review workload, security, hardware, HA and backup requirements together.
Architecture and operating model
Database security covers networking, identity, roles, object permissions, audit and encryption. TLS protects transport; disk encryption/TDE does not automatically prevent authorized SQL reads. Test whether application identities actually need schema changes or administrator privileges. Protect backup and key access similarly.
- 1Network/TLS access
- 2Identities and roles
- 3Object/audit policies
- 4Backup and key recovery
Design parameters
- Role and schema
- Separate runtime permissions from migrations/DDL; avoid shared administrator accounts.
- Encryption boundary
- TLS, disk/TDE and column encryption cover different threats; record key recovery and plaintext paths.
- Workload and query mix
- Measure read/write ratio, connection count, transaction duration and expensive queries. Database size alone does not explain hardware needs.
- Memory and storage
- Examine working set, log writes, temporary space and checkpoint behavior separately. Reliable write guarantees matter alongside speed.
- Recovery chain
- Test recovery of the starting backup, required logs, configuration and keys together.
- Access and change
- Separate application, administrator and schema-change permissions. Control production index and parameter changes.
Worked example
Allow an application role only its required table reads/writes. Reject unrelated schemas, backups and administration for a test identity. Attribute audit records to real identities and verify recovery of older encrypted backups after key changes.
Troubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| Encrypted backup cannot be restored | Certificates or key access may be missing. | Validate isolated restoration with required keys without the main server. |
| CPU is low but queries are slow | Locks, I/O or client waits may dominate. | Inspect the execution plan and wait type for the same query. |
| Replica is connected but stale | Sending, replay or transaction waits can create lag. | Compare the last applied operation with source commit time. |
| Storage keeps growing | Log retention, open transactions, replication slots or maintenance may be involved. | Inspect supported product statistics; do not delete logs manually. |
Acceptance checks
- Demonstrate encryption, authorization and audit using separate tests.
- Test representative transactions and queries using realistic data distributions.
- Restore to a separate target and validate application records.
- Reject unauthorized reads and schema changes using a controlled identity.
- Verify one authorized writer and the correct connection target after failover.
- Measure locks, log volume and latency during maintenance.
Related concepts
Least privilege and separation of duties
Least privilege limits the permissions needed for a task to specific resources and time periods. Giving everyone the same administrator role complicates access reviews and investigations. Separate daily-use identities from privileged accounts, and restrict interactive use and unnecessary network access for service identities. An access matrix should show which operation an identity may perform on each resource. Test whether an application keeps working after a permission is removed: unnecessary privileges sometimes become visible only during controlled reduction.
Authentication and sessions
Authentication proves who a user or workload is; authorization determines what that identity may do. Successful sign-in does not grant access to every resource. User sessions, service identities, API tokens and device certificates have different lifecycles. Design session duration, token renewal, employee departure, lost-device handling and emergency access alongside initial sign-in. Measure which existing sessions remain usable and which new access attempts are denied when the identity provider becomes unavailable.
TLS and certificate validation
TLS protects confidentiality and integrity in transit; certificate validation helps verify the peer’s identity. Evaluate names, chains, validity periods and trusted roots together. Encryption does not prove correct application authorization. If a reverse proxy or inspection device is used, show where TLS terminates. Disabling validation is not a permanent troubleshooting solution: investigate hostname mismatch, missing intermediate certificates and incorrect device clocks separately.
Encryption and key lifecycle
Encryption makes data difficult to read without its key; access control, deletion protection and backup address different needs. Identify which layer protects data in transit and data at rest. Key generation, protection, rotation and emergency recovery are part of the design. A key needed to restore a backup must not exist only on the server that could be lost in the incident. Test decryption and key-access recovery using a separate administrator in a lab, and keep real keys out of documentation and support messages.
Telemetry and time correlation
Telemetry combines logs, metrics and events that explain system behavior. A log describes an event, a metric shows behavior over time, and a distributed trace follows a request across components. Clock differences can make one event appear to occur at several times. Use synchronized clocks, reliable source identifiers and consistent time-zone handling. Alarm design should consider duration and user impact alongside thresholds. Monitor gaps in collection separately: absence of logs must not be interpreted as absence of incidents.
Policy lifecycle
A policy needs management as its scope changes, not just when it is enabled. Separate drafting, observation, pilot deployment, enforcement and periodic review. Every exception needs an owner, reason, scope and expiry date. A successful pilot can still cause production false positives if test data does not represent real user behavior. Identify affected users and applications before deploying with measurable acceptance criteria. A rollback path should identify who may reverse the change and under which conditions, rather than merely locating an interface button.