Database attack surface defense

A database can be encrypted and still lose data. A stolen login, an app role that can read too much, or a bulk export that nobody tracks can all look like normal work until the damage is done.

This guide is for DBAs, application owners, and security teams. It maps common ways data leaves or gets changed, what each control actually stops, and how to test recovery when production admin access is no longer trustworthy. The ideas apply across engines; examples lean on SQL Server where that helps.

Scope: defensive planning only — no exploit recipes. Study attack paths so you can harden systems you are allowed to touch.

The idea in simple terms

Think of the database as a vault with several doors. Each door is a normal business path — not a Hollywood exploit. Teams in Nepal facing residency or privacy rules can also read the Nepal: policy vs proof sidebar for local examples.

The database is a vault with many doors

Disk encryption locks the floor safe — not the person with a badge

Front doorListener / VPN

Public or poorlyfirewalled ports

Harden

Private onlyNo internet DB

Staff badgeIdentity

Stolen password,missing MFA

Harden

Named adminsPhish-resistant MFA

Loading dockExports / ETL

BCP, dumps,analytics sync

Harden

Dual-controlCopy register

Master keysPrivilege

DBA, cloud IAM,KMS, backup console

Harden

Separate planesHSM / key custody

Side alleySupply chain

Vendor support,CI/CD identity

Harden

Time-boxed PAMRecorded sessions

---

1. Typical database estates

In many production environments — public sector, finance, SaaS — the layout looks like this. The picture is familiar worldwide.

Typical database estate

Disk encryption is common. Proof of who can copy, decrypt, or delete recovery is less common.

Edge pathInternet, VPN, firewall

Coverage is unevenSome paths skip controls

Watch for

Know every entry pathTest from outside

ApplicationsBusiness systems

App role can readalmost every table

Watch for

Least privilegePer-tenant checks

Admins / vendorsPeople with power

Shared loginsStanding privilege

Watch for

Named accountsTime-boxed access

IdentityLogin system

Password onlyor weak MFA

Watch for

Phish-resistant MFAShort-lived sessions

Primary databaseSystem of record

Trusted by apps,ETL, and backup tools

Watch for

Private listenerScoped DB roles

Replicas / HAStandby copies

Copy bad writesas well as good ones

Watch for

Use for uptimeNot sole recovery

Warehouse / BIAnalytics copies

Weaker controlson second copies

Watch for

Track every copySame privacy rules

BackupsRecovery store

Same admin domainas production

Watch for

Separate adminsTested restore

KeysCrypto custody

One admin pathor provider-only KMS

Watch for

Key recovery testedDenial tested too

Patterns to keep in mind (same themes as the table):

• Encryption at rest (TDE or volume encryption) is often already on.
• TLS is improving, but some app servers still skip certificate checks.
• Monitoring still hunts malware more than odd but legitimate data access.

---

2. Common gaps

---

3. Risk factors

Weakness is not one CVSS number. Use the scorecard to prioritize work — not to predict breach odds.

Prioritization order (illustrative): privileged identity or recovery compromise → app paths that allow mass disclosure → backups sharing prod authority → unknown copies → silent row changes → unpatched engines → shared DR dependencies → lost or untested keys.

---

4. Attack paths (defensive catalog)

Attackers usually want one of a few outcomes: copy data, alter records, deny service, or control recovery. The paths below are categories for control design — not instructions.

Path A — Valid session, normal features

Stolen credential → VPN or app login → Over-broad role
→ Query or export → Data leaves

Storage encryption does not help if the principal is allowed to read the data. Mandiant’s 2024 write-up of UNC5537 is a useful example for this path only: stolen customer credentials and missing customer-side controls on certain Snowflake deployments — not a claim that every cloud platform was breached.

Path B — Application abuse (injection or weak object checks)

Reach app → Inject or skip authorization → Unauthorized READ/UPDATE
→ Fraudulent change replicated everywhere

Fix SQL injection and per-record authorization. A “clean” query can still exfiltrate if the app role is too wide.

Path C — Admin, vendor, or pipeline compromise

Phish DBA / steal cloud IAM / poison update → Privileged access
→ Disable audit or retention → Dump or encrypt

IdP, orchestration, backup consoles, and KMS often beat a single table CVE in impact.

Path D — Recovery targeted first

Backup-admin rights → Shorten retention / delete copies / break keys
→ Ransomware or wipe → No clean restore

Test which admin can change retention, delete protected versions, or reach encryption keys — not just whether a checkbox says “immutable.”

Path E — Living off the land

Ordinary admin tools → Native dump, replication, PowerShell, cloud CLI
→ Slow exfil to “approved” storage

Defenders hunt binaries; attackers use your sqlcmd, bcp, SSMS, pg_dump, and sync jobs.

Path F — Integrity without outage

Insider or stolen DBA → Change registry / ledger fields
→ Replication spreads the lie → Backups preserve false state

Checksums prove bytes; they do not prove a land transfer is legitimate.

Path G — Availability without engine exploit

Saturate upstream links / expensive authenticated queries / key service outage
→ App cannot connect or decrypt

Private DB listeners do not fix saturated ISP paths or KMS dependencies.

Path H — Copies and supply chain

Contractor laptop → VPN → Prod read role
  or  Analytics sink / ticket attachment / foreign SaaS sync
→ Rows leave the intended boundary

Path I — Direct exposure and patch debt

Internet-facing SQL or RDP → Credential guess or known CVE
→ foothold → lateral move toward data

Shodan-style exposure and missed engine, driver, and extension patches belong in the same program as identity work.

---

5. Tool categories attackers reuse

Defenders should know these classes. Legitimate staff use the same tools daily.

---

6. Why suspicious activity goes unnoticed

Signals worth operationalizing — pick what your stack can actually emit; assign an owner and a test:

Workload identities (services, CI jobs) do not get interactive MFA prompts. Scope their credentials, rotate often, and monitor what they can read — the same as human admins.

CISA and others document living-off-the-land persistence: hunt unusual use of legitimate admin tools, not only new malware files. See CISA advisory AA24-038A (PRC state actors, critical infrastructure) as one public example.

---

7. Principles that change outcomes

1. Assume stolen identity — design for compromised IdP and sessions.
2. Least privilege — separate app, migration, analytics, replication, backup, and security roles.
3. Private data paths — authenticate every hop; no Internet-facing DB listener.
4. Encrypt for the right threat — TDE is not a column trust boundary (Always Encrypted when DBAs must not see values).
5. Govern copies — dumps, replicas, and warehouses are in scope.
6. Recovery independence — prod compromise must not easily admin backups, keys, or offline copies (separate IdP is one pattern; test federation and shared break-glass).
7. Prove restore — clean-room plus business reconciliation, not only “files restored.”
8. Detect behavior — exports, grants, retention, missing audit.
9. Minimize retention — less stored data means less to steal later.
10. Evidence over badges — denied cross-tenant tests beat questionnaire rows.

---

8. Controls, detection, and recovery

8.1 First hardening moves (days, not years)

Bulk export and “dual control”: approving an export workflow does not stop someone with broad SELECT from copying data row by row. A workable design combines:

• Application identities scoped to records/columns they need
• A separate export service or role for large extracts
• Approval tied to dataset, purpose, and destination
• Time-limited grants where possible
• Monitoring of cumulative read volume per identity

Dual approval is one layer in that stack — not a magic database permission.

8.2 Encryption — pick the layer

Practical SQL Server pairing: TDE for files/backups at rest; Always Encrypted for national IDs, cards, salaries; app authorization + MFA so the client is not a firehose.

8.3 Buying tools (against a failure scenario)

Pass/fail on restore proof, key recovery, and no shared default admins before feature scoring.

8.4 Target architecture (trust boundaries)

In words:

• Users and apps terminate TLS at the app tier; apps use scoped DB identities — not admin shared logins.
• Administrators reach databases only through PAM/jump hosts with session recording; MFA is enforced at the IdP/gateway for humans.
• The database listener sits on a private network segment — not the public Internet.
• Keys live in a service the DBA cannot arbitrarily export; app and DBA key use are separated.
• Backups and object-lock storage use different admin credentials and runbooks than production; offline or compliance-mode retention is tested against a simulated prod admin.
• Audit and alerts land in a SIEM the database team cannot silently delete; heartbeats are monitored.
• SOC owns playbooks for export spikes, grant changes, retention edits, and forwarder loss.

8.5 Detection use-cases (summary)

Use the signal table in section 6. Add correlation: a KMS spike plus a new linked server plus a backup retention change on the same timeline is more interesting than any one event alone.

8.6 Recovery that matches the harm

Example recovery drill (illustrative RPO 4 hours, RTO 8 hours — set your own):

1. Charter: name the business service, owners, RPO/RTO, and the ledger/registry/source used to reconcile truth.
2. Assume prod admin is untrusted: stand up a clean-room host/network; use recovery runbooks and keys that prod admin cannot reach.
3. Pick a recovery point from evidence — last green backup job is a candidate, not proof of good data.
4. Restore full/diff/log chain (or platform equivalent), keys, and app config; confirm retention covers the scenario.
5. Validate twice: DB consistency checks and business reconciliation against independent records.
6. Re-enter safely: remove the abuse path, rotate secrets, confirm monitoring, get business sign-off before cutover.
7. Retrospective: record actual RTO/RPO, blockers, and owners for fixes.

Preserve forensic artifacts where you can before destructive steps. For ransomware, follow your incident plan (CISA ransomware guide, NIST SP 800-61 Rev. 3).

GitLab’s 2017 database outage postmortem is a sobering reminder: backup existence ≠ tested restore path — worth reading before you trust a green dashboard (GitLab incident).

---

9. Example 90-day plan

Ninety days is a sample cadence. Critical services may need faster gates; lower tiers can stretch. If you already have active compromise, exposed break-glass passwords, broken backups, or a wormable CVE — treat that as day zero, not “week four.”

Plan IdP and network changes with dependency checks and a rollback path — security work should not cause avoidable outages.

Large rebuilds, new SOC platforms, or engine migrations can still be right — after exposure, MFA, backup separation, and a restore drill show where the real gaps are. An unsupported database version may force migration; sequence by risk, not by slide deck.

---

10. Myths

---

Closing checklist

Use this as a short pass/fail list. For Nepal-specific evidence language (residency, citizen data, procurement), see Nepal: policy vs proof.

Strong database defense is identity + authorization + crypto boundaries + governed copies + independent recovery + behavior detection, checked with exercises — so data stays with the people and institutions it belongs to, not whoever holds the next valid-looking session.

Related: Always Encrypted in SQL Server · SQL Server ransomware defense · Nepal: policy vs proof

---

Nepal: policy vs proof

This sidebar is for operators and procurement teams in Nepal. The rest of the article is global; use this section when privacy, cybersecurity, data residency, or financial resilience expectations apply locally.

Policies on paper are a start. Auditors and citizens care about proof: an up-to-date copy inventory, independent backup access, control of encryption keys, and a restore that worked in a clean room. The same doors in The idea in simple terms and the same estate parts in Typical database estates still apply — location alone does not close them.

Practical checks for operators and procurement:

1. Location is not custody. A server in Kathmandu still leaks if a vendor session or shared DBA password can export or delete recovery.
2. Outages erode trust quickly. Trading or citizen-facing downtime becomes a confidence problem — restore success alone does not answer whether rows were copied or altered.
3. Questionnaire rows ≠ denied export. ISO-style checklists do not replace a test where tenant A cannot read tenant B.
4. Spend follows evidence. National platform rebuilds, engine swaps “for security,” or new SOC tools wait behind public listener removal, MFA, backup separation, and a restore drill — unless law or unsupported software forces a faster migration.
5. Privacy is concrete. National IDs, tax and land fields, and health-adjacent data belong in scoped apps — not on contractor laptops or untracked BI dumps.

When you write acceptance criteria for a Nepal-hosted system, reuse the closing checklist and ask for the same evidence: denied cross-tenant reads, admin-delete denial on locked backups, and a signed restore drill.

---

Learning resources (defenders)

Use ethical-hacking and secure-development material to build detection and authorization tests in environments you own or have written permission to test.

---

Sources

Each link supports specific claims in this article:

Source	Date	Supports
Google Cloud / Mandiant — UNC5537 Snowflake-related customer credential theft	June 2024	Path A credential theft pattern (customer-side controls)
GitLab — postmortem of January 2017 database outage	Feb 2017	Backup/restore assumptions vs tested recovery
OWASP SQL Injection Prevention Cheat Sheet	ongoing	Path B secure coding
OWASP Database Security Cheat Sheet	ongoing	Hardening checklist themes
Microsoft — Always Encrypted	ongoing	Section 8.2 crypto boundaries
Microsoft — TDE	ongoing	TDE scope and backup encryption
Microsoft — dynamic data masking	ongoing	DDM limitations
Microsoft — SQL Server audit records (response_rows scope)	ongoing	Detection table prerequisites
Microsoft — SqlClient connection security (TrustServerCertificate)	ongoing	TLS validation warning
AWS — external key stores	ongoing	BYOK / external key plaintext boundary
AWS — S3 Object Lock	ongoing	Retention vs readability
CISA — AA24-038A (living off the land, critical infrastructure)	2024	Section 6 detection framing
CISA — Stop Ransomware guide	ongoing	Section 8.6 response
NIST SP 800-61 Rev. 3	2025	Incident response integration
Microsoft — Azure Data Studio retirement notice	Feb 2026	Legacy client mention in section 5