PII가 포함된 고객 데이터는 Amazon Redshift에 저장됩니다. 여러 팀에서 다양한 수준의 액세스가 필요합니다. 마케팅 팀은 클레임 세부 정보를 난독화해야 하지만 전체 연락처 정보가 필요하고, 클레임 팀은 처리하는 각 클레임에 대한 고객 정보가 필요하며, 분석 팀은 난독화된 PII만 필요합니다. 관리 오버헤드가 가장 적은 방식으로 이러한 액세스 규칙을 적용하는 접근 방식은 무엇입니까?

정답은 각 팀에 대해 고유한 Amazon Redshift 데이터베이스 역할을 생성하고, 팀별로 마스킹 정책을 정의하고, 적절한 마스킹 정책을 각 역할에 연결하는 것입니다. 이 접근 방식은 Amazon Redshift의 기본 데이터 마스킹 기능을 활용하여 PII를 보호하면서도 각 팀의 특정 요구 사항에 따라 세분화된 액세스를 제공합니다. 관리 오버헤드가 가장 적은 이유는 데이터 복제나 별도의 인프라 없이 단일 Redshift 클러스터 내에서 데이터 보안 및 액세스 제어를 중앙 집중화할 수 있기 때문입니다. 별도의 Redshift 클러스터를 프로비저닝하는 것은 데이터 복제 및 인프라 관리로 인해 관리 오버헤드가 매우 높습니다. 데이터베이스 뷰를 생성하는 것은 마스킹 기능이 없어 PII를 난독화해야 하는 요구 사항을 충족하지 못합니다. 데이터를 S3로 이동하고 Lake Formation을 사용하는 것은 데이터 레이크 솔루션으로 유효하지만, 이미 Redshift에 데이터가 있고 Redshift 내에서 직접 세분화된 제어가 가능하므로 문제에서 요구하는 '가장 적은 관리 오버헤드'에는 미치지 못합니다.