Database Security: Protecting Your Most Valuable Data Assets

Considerable effort goes into securing applications, and the database behind them frequently runs with a service account holding far more privilege than it needs, reachable from more of the network than it should be, with auditing switched off because of a performance concern from a decade ago.

The service account is the crown jewel

An application connects with a single account, and that account usually has far more than it needs — frequently db_owner or equivalent, because that is what the installer asked for and it worked.

The consequence: any SQL injection or application compromise inherits those rights in full. Scoping the account is one of the highest-value database controls and is usually straightforward:

• Grant on specific objects, not schema-wide
• No DDL rights for an application that does not create tables at runtime
• Separate accounts for read-heavy and write paths where the application supports it
• No shared account between applications
• Rotate the credential and store it in a secret manager rather than a configuration file

Reduce who can reach it

Databases are frequently reachable from the whole internal network because the firewall rule was written broadly during a migration.

Auditing, scoped so it is affordable

Auditing everything is expensive and produces noise nobody reads. Audit the things that matter:

• Privileged actions — schema changes, permission grants, account creation
• Direct access outside the application — a human querying the production database is either maintenance or an incident
• Bulk reads — a SELECT returning far more rows than the application ever does
• Failed authentication, which should be near zero for a service account
• Access to the most sensitive tables, specifically

That second one is the highest-signal detection available at the data layer. Application traffic is predictable; a person connecting with a query tool is not, and correlating those sessions against change tickets finds real problems.

Encryption: what it does and does not do

Transparent data encryption protects the files. It does nothing against a query issued through the application's own connection — which is the realistic attack. It is worth enabling, and it should not substitute for access control in a risk assessment. This is covered in more depth in encryption everywhere.

Column-level encryption or tokenisation of the most sensitive fields is what limits the value of a bulk extract, at the cost of application complexity.

The copies nobody governs

The production database usually has the best controls of any copy of that data.

• Reporting replicas — same data, broader access, frequently no auditing
• Non-production refreshes — real PHI in an environment where developers hold administrative rights
• Ad-hoc extracts — a spreadsheet on a share, produced for a legitimate purpose two years ago
• Backups — see immutable backups

Non-production is the one to address first. Either mask or synthesise on refresh, or apply production-grade controls. Choosing neither is the default and it is how PHI ends up in an environment with no audit trail at all.

Where to start

Check two things: does your main clinical database have a public endpoint, and what privileges does its application service account actually hold? Both take minutes to answer and both are commonly wrong.

GuardsArm reviews database security posture including privilege scoping, network exposure and non-production data handling. Book a scoping call.