Database Security

Database security keeps data confidential, correct, and available to authorized work. It also makes actions traceable when you need to investigate a mistake or attack.

The database is only one part of that job. Data moves through applications, drivers, networks, database processes, storage, logs, backups, and administrator tools. A weakness at any boundary can undermine controls elsewhere.

This course gives you a practical way to reason about those boundaries. You will learn to reduce exposure, separate identities, limit privileges, prevent injection, protect data, and preserve useful evidence.

Start with data and paths

Begin with the data, not a product setting.

Identify what the database holds. Classify the harm from unauthorized disclosure, modification, deletion, or loss of access. Include replicas, exports, logs, temporary files, snapshots, and backups.

Then map every path to that data:

• application and service connections;
• administrator and support access;
• replication and backup channels;
• monitoring, analytics, and export jobs;
• database management interfaces;
• storage and key-management systems.

Each path creates a trust boundary. Record who or what crosses it, how identity is checked, what access follows, and what evidence remains.

Use layers with different jobs

Database security works as a set of independent controls.

• Network controls limit which systems can reach a database endpoint.
• Authentication establishes the identity of a user, service, or administrator.
• Authorization determines what that identity can do.
• Safe query construction keeps untrusted input in the data part of a query.
• Encryption protects selected data in transit or at rest.
• Audit logging records security-relevant events for detection and investigation.
• Backup protection preserves recoverable copies without creating an easier route to the data.

No single layer proves the others. A private network does not correct excessive privileges. Encryption does not prevent an authorized account from making a harmful change. Logging does not block an attack that is already in progress.

Reduce network exposure

A database should accept connections only from the systems that need them. OWASP recommends local connections where practical, restricted firewall paths, or a dedicated internal network segment.

Do not expose a database port or management interface to a broad network by default. Route untrusted clients through an application or API that enforces access rules.

Encrypt database traffic when it crosses a network. The client must also verify the server certificate. Encryption without identity verification can protect a connection to the wrong endpoint.

Separate identities by purpose

Give people, applications, automation, and administrators distinct identities. Shared identities make revocation and investigation harder because several actors produce the same trail.

Authentication answers, "Who is connecting?" Authorization answers, "What may that identity do?" Keep those questions separate.

PostgreSQL uses roles for access control. A role with login capability can connect, and its role identity determines its initial privileges. Other database systems use different names, but the design question stays the same.

Store application credentials outside source code and deployment artifacts. Control access to the secret store. Rotate credentials when exposure is suspected and on the schedule your risk model requires.

Apply least privilege

Least privilege gives each identity enough access for its required work and no more. Start from no access, then grant the smallest useful set.

Separate read, write, schema-change, backup, monitoring, and administrative duties. An application that reads a catalog does not need permission to create users. A reporting job does not need to delete rows.

Use roles to group stable duties. Grant identities membership in those roles. Review privileges after job changes, application changes, and service retirement.

Views, stored interfaces, column permissions, and row-level policies can narrow access below a whole table. These controls need testing. Their behavior depends on the database engine, object ownership, and execution context.

Keep code and data separate

Injection occurs when untrusted input changes the structure or meaning of a database operation.

For SQL, use prepared statements with bound parameters for values. The query structure is defined first, and each input value is supplied separately. Do not build a query by concatenating untrusted strings.

Parameters usually cannot replace structural elements such as table names, column names, or sort direction. Map those choices from an allow-list in code or redesign the query.

Stored procedures and object-relational mappers do not remove injection risk by themselves. Unsafe dynamic query construction can still occur inside either layer.

NoSQL systems have the same boundary problem in a different form. Do not accept raw query objects or operators from a client. Build the query with a safe driver interface and validate the permitted fields and operators.

Protect data in transit and at rest

Transport encryption protects data while it moves between endpoints. At-rest protection covers stored database files, logs, exports, snapshots, and backups selected by your risk assessment.

Encryption changes the problem into data plus key protection. Keep keys separate from the protected data when the design requires that separation. Restrict key administration, record key use, and test recovery before a key is needed during an incident.

Encryption has limits. It does not correct an overprivileged account, a vulnerable query, or a compromised application that can ask the database for plaintext.

Harden and maintain the platform

Remove default accounts, sample databases, unused extensions, and unneeded services. Run the database service under a low-privilege operating-system account. Install supported security updates through a tested change process.

Treat the configuration as controlled code. Record the approved baseline. Review changes. Test that the deployed state matches the intended state.

Managed database services move some operating duties to a provider. They do not remove your responsibility for identities, privileges, network paths, data classification, query safety, logging choices, and client configuration.

Build evidence you can use

Choose audit events from investigation needs. Useful records identify the event type, time, source, outcome, and associated identity or object.

Prioritize authentication attempts, privilege and role changes, schema changes, administrative actions, changes to logging, and access to sensitive data where risk requires it.

Protect logs from unauthorized change or deletion. Send critical records to a separate system when compromise of the database host could also destroy local evidence.

Do not log secrets or unnecessary sensitive values. Logging every query parameter can create a second sensitive database with weaker controls.

Protect recovery paths

Backups, snapshots, replicas, and exports contain data outside the primary database controls. Apply access restrictions, encryption where required, retention rules, deletion protection, and monitoring.

Test restoration with the required keys and credentials. A protected backup that nobody can decrypt during recovery is not useful recovery material.

Security and recovery plans must work together. During an incident, preserve evidence, choose a trusted recovery point, restore into an isolated target, validate permissions, and rotate exposed credentials before return to service.

Know the limits

Database controls cannot decide which business actions a user should be allowed to perform. The application must enforce those rules before it reaches the database.

Database security also cannot guarantee that upstream data is accurate. It can constrain changes and record events, but business validation belongs at the right application boundary.

Compliance requirements can define minimum controls, retention, or evidence. They do not replace threat modeling, testing, or operational review.

The durable approach is a cycle: map the data, reduce paths, separate identities, narrow privileges, protect each boundary, collect evidence, test recovery, and review change.