Data Security: Trust No One
Concept. Zero Trust assumes every layer (the network, users, admins, code, and backups) is already compromised, so the system verifies every request instead of trusting any boundary. The database holds the crown jewels (PII), so a single unverified path is a breach.
Intuition. The 2024 mega-breaches were not exotic. National Public Data left plaintext database passwords in an exposed file; Change Healthcare ran a remote portal with no MFA; Snowflake customers reused stolen credentials on accounts without MFA. Each is one trusted surface that should have been verified.
Three Breaches, Half a Billion Records
The vector is almost never a clever zero-day. It is an unpatched library, a plaintext password, or a missing MFA prompt.
| Breach | Year | Records | Root cause |
|---|---|---|---|
| Equifax | 2017 | 148M SSNs | unpatched Apache Struts bug, pivoted to root on the DB |
| National Public Data | 2024 | 170M people (2.9B records) | plaintext DB passwords in an exposed backend file |
| Change Healthcare | 2024 | 193M medical records | remote portal with no MFA, then ransomware |
| Snowflake / Ticketmaster | 2024 | terabytes exfiltrated | stolen credentials on cloud accounts without MFA |
The average breach cost $4.88M in 2024 (IBM), and the count rose sharply year over year. Every root cause above is a surface someone trusted instead of verifying.
Zero Trust: The Five Surfaces
Figure 1. Zero Trust treats every path to the data as hostile until verified. The network can be sniffed, a user can be phished, an admin can turn or be compromised, code can be injected, and backups can be encrypted by ransomware. The defense is not a stronger wall around one of them; it is verifying every request at every surface, plus least privilege, MFA, and immutable backups so no single failure reaches the data.
Zero Trust DB Checklist (Starter)
| Priority | Time | Action |
|---|---|---|
| CRITICAL | 5 min | Passwords. Change defaults, set expiry, enforce strong passwords. |
| CRITICAL | 1 hour | Network. Enable SSL/TLS, limit max connections, restrict connection sources. |
| CRITICAL | 10 min | Least privilege. REVOKE ALL ON users FROM public; then GRANT SELECT ON users TO analytics_role; and enable Row-Level Security. |
| HIGH | 5 min | Audit logging. Turn it on. |
| HIGH | 45 min | 3-2-1 backups. 3 copies, 2 storage types, 1 offsite; test restores; keep them immutable against ransomware. |
SQL Injection: The One Bug That Keeps Winning
Injection defense is the clearest case of "verify every input." The classic Bobby Tables attack still works wherever a query is built by string concatenation.
Figure 2. The same input, two outcomes. When the query is built by string concatenation (left), the attacker's quote closes the string and the rest of the input runs as a new command, so DROP TABLE users executes. A parameterized query (right) sends the input separately from the query text, so the database treats the whole string as one value to match, finds no such user, and drops nothing. The fix is mechanical: never concatenate input into SQL, always parameterize.
Module 6 Capstone: Power Cuts Both Ways
In Module 1 you saw that SQL is powerful: a few declarative SELECT and JOIN statements move enormous amounts of data. Here in Module 6 you see the other edge. That same power means one mistake, a single concatenated string, lets an attacker turn your query engine against you. SQL injection is just an attacker hijacking your syntax to run their own SELECT and DROP.
Do not trust the network. Do not trust the user. Verify every query.
Next
Data Privacy → Security keeps attackers out. Privacy is the harder problem: even data you release on purpose, "anonymized," can still betray the people in it.