LEARN. PRACTICE. GROW.Concept and mechanism
Dynamic data masking changes value presentation for certain users but is not encryption and does not prevent every inference through ad hoc queries. An RLS policy can filter rows according to identity or session context. If it uses middleware-supplied tenant_id, that value must derive from validated identity and be correctly established before operations. A form must not freely choose another customer scope. Test relevant access paths, including privileged accounts and data extraction, instead of assuming an interface filter is sufficient. Least privilege remains necessary even with masking and RLS. Document which component is trusted to establish identity and how incorrect or missing context is handled.
Guided application
In a fictional external analysis, provide only authorized attributes and operations and record relevant access. Security auditing, change tracking, and performance history answer different questions: row changes do not automatically provide a trail of who executed SELECT. SQL ledger adds tamper evidence supported by digests stored in a trusted destination outside the database. If the same account can alter data and reference hashes, verification loses independence. Ledger also does not turn incorrect input into business truth. Define retention, owners, and verification procedure, and use reconciliation to connect technical events to their functional source. Ensure the evidence remains accessible to authorized reviewers after a regional recovery.
A context-based RLS policy is unsafe if a client can supply another organization tenant_id without validation.
Common pitfalls
Masking as secrecy; unvalidated context; change tracking as read auditing; digest writable by the same attacker.
Related topics: Platform, capacity, and migration · Identity, networking, and encryption · Query Store and concurrency
Protect access, context, and evidence references separately.
Reference: Masking limitations · DP-300 English objectives effective 2026-04-24