Masking a Column That Feeds a Downstream Model
A healthcare analytics team stores member records in MEMBER.PII with columns MEMBER_ID, SSN, DOB, ZIP, and DIAGNOSIS_CODE. A masking policy on SSN shows full value to role PII_ADMIN and a masked value to everyone else. Analysts in ANALYST build a churn model using DOB and ZIP. The privacy officer notes that DOB + ZIP is effectively a quasi-identifier and can re-identify individuals even though SSN is masked. Separately, a data engineer reports that a view owned by PII_ADMIN (using owner's rights) exposes unmasked SSN to ANALYST because the view runs with the owner's privileges. The team wants to keep the model working while reducing re-identification risk.
1. The engineer says 'the masking policy is broken because the view leaks SSN.' Is the policy broken? Explain the mechanism and the correct remediation.
Read the worked answer
The policy is not broken; the privilege context is. A view created with owner's rights executes with the owner's role, so masking policies evaluate against PII_ADMIN rather than the querying ANALYST. That is expected Snowflake behavior, not a policy defect. Remediation options, in order of preference: (1) Recreate the view as a secure view and ensure the underlying table access is granted to the querying role so policies evaluate in the caller's context - but note secure views do not by themselves change masking evaluation; the real fix is to avoid granting the owner role broad PII access for a view meant for analysts. (2) Better: have the view owned by a low-privilege role and grant only the needed columns, so even owner's-rights evaluation sees masked data. (3) Audit all owner's-rights views over masked columns and convert the risky ones. The lesson: masking is only as strong as the role context in which it is evaluated.
2. Propose a defensible approach to the DOB/ZIP re-identification concern that preserves model utility.
Read the worked answer
SSN masking addresses direct identifiers; DOB + ZIP are quasi-identifiers and need generalization or aggregation, not simple masking. Options: (1) Apply a masking policy that returns year of birth (or 5-year bands) for non-privileged roles, and truncate ZIP to the 3-digit prefix - this preserves cohort signal while reducing uniqueness. (2) If the model needs finer granularity, expose it only through an aggregated feature table (e.g., counts per ZIP3/birth-year band) rather than row-level values. (3) Document the residual risk and validate with a k-anonymity check: confirm each combination of generalized DOB and ZIP3 covers at least k members before releasing. (4) Keep raw values restricted to PII_ADMIN with access logging. The key judgment: masking a direct identifier does not address re-identification via combinations, so the control must operate on the quasi-identifier set as a whole.