Chapter 48 — Database security in depth

How it works

Dynamic data masking — controlling what's seen, not what's stored:

   Different from encryption: the underlying data is stored normally
   (encrypted at rest per Ch 42 if warranted), but the DATABASE ENGINE
   masks it AT QUERY TIME based on the caller's role -- a support analyst
   role sees `j***.d**@***.com` where an authorized service sees the real
   value, with NO application code changes needed for the masking itself.
   Available natively in SQL Server (Dynamic Data Masking), Snowflake
   (masking policies), and via extensions/proxies for Postgres/MySQL.
   USE FOR: giving broad internal visibility (support, debugging,
   analytics dashboards) without broad DATA EXPOSURE -- a middle ground
   between "full access" and "no access", cheaper to operate than
   building a bespoke masking API for every internal tool.
   NOT A SUBSTITUTE for Ch 42's field-level encryption where the threat
   model includes a privileged/root DB account or the DBA role itself --
   masking is enforced BY the engine, so an account with masking-bypass
   privilege (often granted broadly by default) sees everything.

Database Activity Monitoring (DAM) — catching bulk exfiltration:

   The threat masking and RLS don't catch: a LEGITIMATELY authorized
   account (a compromised support engineer's credentials, an insider)
   running `SELECT * FROM users` with no WHERE clause and exporting the
   result -- every individual row access was "authorized"; the PATTERN is
   the anomaly.
   DAM tools (Imperva, IBM Guardium, or NATIVE options: AWS RDS/Aurora
   Activity Streams, Google Cloud SQL audit logs, PostgreSQL's pgAudit
   extension) watch and can ALERT on:
     - queries returning unusually large result sets for that role/user's
       normal pattern.
     - a `SELECT *` / broad export pattern from an account that normally
       does narrow, parameterised lookups.
     - access outside normal hours / from a new source IP for that
       credential.
     - schema/permission changes outside a change window.
   Pair with QUERY RESULT SIZE CAPS and paginated-by-default APIs at the
   application layer (G1 Ch 45/this guide's Ch 28) as a structural
   backstop, not just a detection rule.

Authentication — IAM-based over static passwords:

   STATIC DB PASSWORDS (even rotated ones, G1 Ch 49) are a standing
   secret that can leak, get committed, or get shared between environments.
   IAM DATABASE AUTHENTICATION (AWS RDS/Aurora IAM auth, GCP Cloud SQL
     IAM auth, Azure AD authentication for SQL) issues SHORT-LIVED AUTH
     TOKENS derived from the calling workload's IAM/cloud identity
     (Part 2 Ch 5, Part 4 Ch 20's workload identity) instead of a
     password -- the same short-lived-credential principle applied to the
     database connection itself. No password to leak, rotate, or store;
     access is governed by the SAME IAM policy graph as everything else
     (Part 2 Ch 6), so revoking a compromised workload's IAM access also
     revokes its DB access immediately.
   Where IAM auth isn't available: DYNAMIC SECRETS from a vault (G1 Ch 49)
     -- a short-lived DB credential minted per session and auto-expired --
     is the next-best option, strictly better than a long-lived static
     password.

Least privilege and account hygiene:

   [ ] a SEPARATE DB account per SERVICE (not one shared "app" account
       for everything) -- so a compromised service's blast radius is
       exactly its own grants, and query-pattern anomalies (DAM, above)
       are attributable to a specific service, not "the app" generically.
   [ ] NO service account is a superuser, the table owner (unless FORCE
       RLS is relied on, Part 5 Ch 27), or has BYPASSRLS.
   [ ] STORED PROCEDURES built with dynamic SQL are just as
       injection-prone as application code (G1 Ch 42) -- parameterise
       inside procedures too; a proc that concatenates a caller-supplied
       string isn't safer for being server-side.
   [ ] REVIEW extensions/plugins: some (Postgres `dblink`, untrusted
       procedural languages) can be privilege-escalation vectors if
       available to non-superuser roles -- audit what's installed and
       who can invoke it.
   [ ] PATCH the engine on a defined cadence; database CVEs are as real
       as application CVEs (G1 Ch 47) and often more severe given the
       blast radius.

The exposed-database problem — still a leading mass-breach cause:

   A recurring, entirely preventable pattern: a MongoDB/Elasticsearch/
   Redis instance bound to 0.0.0.0 and exposed directly to the internet
   with NO AUTHENTICATION -- automated scanners (Shodan-driven) find and
   exfiltrate/ransom these within HOURS of exposure. This traces back to
   defaults: pre-2.6 MongoDB shipped with NO auth enabled by default,
   causing a wave of mass exposures that continues to recur as new
   instances get spun up from old images/tutorials/defaults.
   THE FIX IS BASIC AND NON-NEGOTIABLE: authentication ALWAYS enabled
   (never rely on "it's only reachable internally" as the sole control --
   G1 Ch 39/this guide's Part 2 Ch 8's network layer is defence IN DEPTH,
   not a substitute); bind to private interfaces only; use the engine's
   real access-control layer (Elasticsearch/OpenSearch security
   plugin/X-Pack, Redis AUTH + ACLs since Redis 6, MongoDB's role-based
   access control) -- and CONTINUOUSLY SCAN your own external attack
   surface (an internal Shodan-equivalent check, or your cloud's exposed-
   resource finder) so you find an accidental exposure before an
   attacker's scanner does.