Tuần 7 - Ngày 4: Data Privacy và Masking

Mục tiêu học tập

• Phân biệt các kỹ thuật: masking, hashing, tokenization, anonymization
• Biết công cụ masking theo từng lớp: Glue, Redshift, Lake Formation, Firehose/AppFlow
• Thiết kế pipeline xử lý PII đúng chuẩn (phát hiện → xử lý → kiểm soát truy cập)
• Nắm các khái niệm quy định (GDPR-style) ở mức đề thi

1. Các kỹ thuật bảo vệ PII

Điểm phân biệt hay thi: masking/hash = một chiều; tokenization/encryption = khôi phục được có kiểm soát.

2. Công cụ theo từng lớp trên AWS

Khi ingest / transform

• Glue "Detect PII" transform: quét DynamicFrame, phát hiện loại PII (email, SSN...), và hành động: redact, hash, hoặc gắn nhãn — masking ngay trong ETL trước khi vào curated
• Firehose + Lambda transform: mask trường trong record streaming
• AppFlow masking: mask field ngay trong flow từ SaaS
• DataBrew: transformation REDACT/HASH cho analyst

Khi lưu trữ / truy vấn

• Lake Formation: không mask giá trị, nhưng ẩn cột/hàng/cell theo principal (data filters — hôm qua). "User khác nhau thấy cột khác nhau" → LF
• Redshift Dynamic Data Masking (DDM): masking policy theo role tại thời điểm query — cùng bảng, admin thấy số thẻ đầy đủ, analyst thấy XXXX-XXXX-XXXX-1234; không đổi dữ liệu lưu trữ
• Athena: view che cột (SELECT bỏ cột nhạy cảm / hàm mask trong view) + LF quyền trên view

Nguyên tắc chọn nhanh

• Cần không bao giờ lưu giá trị thật ở downstream → mask/hash lúc ingest/ETL (Glue Detect PII, Lambda)
• Dữ liệu thật phải giữ nhưng ai thấy gì tùy quyền → Redshift DDM / Lake Formation filters
• Cần khôi phục được → tokenization/field-level encryption (tự thiết kế với KMS/DynamoDB vault)

3. Pipeline PII chuẩn (kiến trúc mẫu)

Tầng phòng thủ: phát hiện (Macie) → giảm thiểu (mask/hash tại ETL) → kiểm soát (LF/DDM) → audit (CloudTrail — ngày mai).

4. Khái niệm quy định (mức nhận biết cho đề)

• Data residency: dữ liệu phải ở region/quốc gia nhất định → chọn region, chặn replicate ra ngoài (SCP/bucket policy điều kiện region)
• Right to be forgotten: xóa dữ liệu một cá nhân — thiết kế lake có khả năng xóa theo khóa (Iceberg DELETE là lợi thế so với Parquet thuần)
• Data retention: giữ đúng hạn — S3 lifecycle/Object Lock; log retention
• Purpose limitation / least privilege: quyền theo nhu cầu — LF fine-grained

Câu hỏi ôn tập

1. Yêu cầu: analytics vẫn đếm được user duy nhất và join theo user giữa các bảng, nhưng không ai thấy email thật. Kỹ thuật nào?

   Xem đáp án

   Hashing (một chiều, có salt): thay email bằng SHA-256(salt + email) ngay trong ETL — giá trị nhất quán nên join/COUNT DISTINCT vẫn đúng, nhưng không khôi phục được email. Masking bằng *** phá khả năng join; tokenization thừa (không cần khôi phục) và thêm vault phải bảo vệ.

2. Bảng Redshift chứa số thẻ; support agent chỉ được thấy 4 số cuối, team fraud thấy đầy đủ — cùng một bảng. Tính năng nào?

   Xem đáp án

   Redshift Dynamic Data Masking: tạo masking policy (vd hiện XXXX... + 4 cuối) attach vào cột, gán theo role — fraud role được policy pass-through, support role bị mask. Áp lúc query, dữ liệu lưu trữ không đổi, không cần hai bảng.

3. Muốn mask PII ngay trong Glue ETL trước khi ghi curated mà không tự viết regex cho từng loại. Tính năng nào?

   Xem đáp án

   Glue Detect PII transform (Glue Studio/API): tự phát hiện các loại PII phổ biến (email, phone, SSN, credit card...) trong DynamicFrame và chọn hành động redact/hash từng cột hoặc cả ô phát hiện được. Đây là "managed" thay cho Lambda/regex tự chế.

4. Phân biệt vai trò của Lake Formation và masking trong bảo vệ PII — vì sao thường dùng cả hai?

   Xem đáp án

   Masking/hash (ETL) thay đổi dữ liệu lưu trữ — giá trị thật không tồn tại ở downstream, an toàn tuyệt đối nhưng mất thông tin vĩnh viễn. Lake Formation giữ dữ liệu thật, kiểm soát ai thấy cột/hàng nào — linh hoạt nhưng dữ liệu thật vẫn nằm đó (rủi ro nếu quyền cấu hình sai). Thực tế: mask những gì không bao giờ cần (số thẻ đầy đủ), LF bảo vệ phần còn lại cần cho một số role.

5. Yêu cầu GDPR-style "xóa mọi dữ liệu của user X" trên data lake Parquet thuần rất khó. Thiết kế nào giúp?

   Xem đáp án

   Parquet thuần: xóa một user = đọc-lọc-ghi lại mọi file chứa user đó — đắt. Giải pháp: (1) dùng Iceberg — DELETE FROM table WHERE user_id='X' với ACID, engine tự rewrite; (2) hoặc thiết kế hash/tokenize PII từ đầu — "xóa" = hủy token/salt mapping (crypto-shredding), dữ liệu còn lại vô nghĩa; (3) partition/bucket theo user chỉ khả thi khi cardinality phù hợp. Đây là lý do lakehouse format thắng thế với dữ liệu có yêu cầu privacy.

Bài tập thực hành

• Thêm Detect PII transform vào Glue Studio job với hành động hash cột email
• Viết masking policy Redshift DDM cho cột phone (giả lập bằng SQL nếu không có cluster)
• Vẽ lại pipeline PII 4 tầng (phát hiện → giảm thiểu → kiểm soát → audit) từ trí nhớ
• Đọc Redshift dynamic data masking

Tài liệu tham khảo chính thức

• Glue — Detect and process PII
• Redshift dynamic data masking
• Lake Formation data filters
• Data protection reference (AWS whitepaper)

---

Tiếp theo: Audit và Governance tổng hợp