AWS Certified Data Engineer – AssociateData Governance and SecurityHard
A data engineering team is migrating a legacy on-premises data warehouse to Amazon Redshift. The legacy system used a custom data masking solution for sensitive columns (e.g., Social Security Numbers, credit card numbers) to prevent unauthorized users from viewing actual data while still allowing analytics. The team needs to replicate this masking functionality in Redshift, ensuring that only authorized users can see unmasked data. Which approach should the data engineer implement?
- AUse AWS KMS to encrypt sensitive columns and decrypt them for authorized users.
- BImplement AWS Lake Formation for Redshift data masking.
- CUtilize Redshift's native column-level security features with views.
- DCreate separate masked and unmasked tables and grant access based on user roles.
Show answer & explanationAnswer & explanation
Correct answer: C. Utilize Redshift's native column-level security features with views.
Redshift's native column-level security, typically implemented using views, allows defining views that mask sensitive columns (e.g., by replacing them with asterisks or hashes) for most users, while granting access to the underlying unmasked table only to highly privileged users. This is a common and efficient way to implement data masking in Redshift.
Why the other options are wrong
- A. Using AWS KMS for column-level encryption/decryption within Redshift is complex and would require custom application logic, impacting query performance significantly for analytics workloads, and is not a native data masking solution.
- B. AWS Lake Formation primarily manages access to S3 data lakes and Redshift Spectrum external tables, not directly for data masking inside a Redshift managed cluster's internal tables.
- D. Creating separate tables duplicates data and adds significant management overhead, making it inefficient for a data warehouse.
Redshift Data Masking with Views
Data masking in Amazon Redshift can be implemented by creating SQL views that transform or hide sensitive data in specific columns, granting access to these views for most users, while restricting direct table access to privileged users.
- Uses SQL views to mask data.
- Prevents unauthorized access to sensitive data.
- Allows analytics on masked data.
- Efficient for column-level masking in Redshift.
Memory trick: Views Veil Valuable Values