Database hardening workbook

Why databases deserve separate treatment

A database is where the consequence lives. Everything else in an estate is a path towards it, which changes what hardening is for: the objective is not to make compromise unlikely but to make a compromise of the application not automatically a compromise of the data.

That reframing produces different priorities. Network reachability, account separation, encryption of data at rest and in transit, and above all logging of who read what, matter more here than they do on a general purpose server.

It also produces the control organisations most often lack: knowing which application account can read which tables, and why.

The controls that matter most

• The database should not be reachable from anywhere the application does not need it to be
• Separate accounts per application and per function, with the minimum rights each genuinely needs
• No shared administrative accounts, and no standing administrative access
• Encryption at rest and in transit, with key management that is not on the same host
• Read access to personal data logged in a form that can answer who looked at what
• Backups encrypted, tested by restore, and not reachable from the network being protected

The failure modes we find most often

An application account with far more rights than the application uses, usually because the rights were granted during development and never narrowed. This turns an application vulnerability into a full data compromise.

Backups reachable from the production network. Ransomware operators look for backups first, and an encrypted backup you cannot restore because it was encrypted by somebody else is the worst outcome in this category.

Read access unlogged. Under the DPDP Act you may be asked who accessed a data principal's records. An estate that logs writes and not reads cannot answer.

Non-production copies of production data. This is extremely common, rarely governed, and frequently the actual source of a breach, because the same controls are not applied to a test environment.

How this maps to your obligations

DPDP Act: retention and deletion have to be enforceable at the database, which means knowing what personal data each table holds. The inventory work and this workbook are the same exercise approached from two directions.

PCI DSS: storage of account data is examined specifically, and the strongest control remains not storing it. Where it must be stored, the requirements around encryption, key management and access are detailed and tested.

ISO 27001:2022: information deletion and data masking are among the newer controls, and both land primarily at the database layer.

In each case the evidence auditors want is the same: the access matrix, the change record for it, and proof that the retention actually runs.