Dane klientów zawierające PII są przechowywane w Amazon Redshift. Różne zespoły wymagają różnych poziomów dostępu: marketing potrzebuje zanonimizowanych szczegółów roszczeń, ale pełnych danych kontaktowych; dział roszczeń potrzebuje informacji o klientach dla każdego przetwarzanego roszczenia; analityka potrzebuje tylko zanonimizowanych PII. Które podejście wymusza te zasady dostępu przy najmniejszym nakładzie pracy administracyjnej?

Prawidłowa odpowiedź to utworzenie odrębnej roli bazy danych Amazon Redshift dla każdego zespołu, zdefiniowanie zasad maskowania dla każdego zespołu i dołączenie odpowiednich zasad maskowania do każdej roli. To podejście, wykorzystujące maskowanie danych w Redshift, pozwala na dynamiczne ukrywanie lub anonimizowanie danych PII na poziomie kolumn lub wierszy, w zależności od roli użytkownika. Minimalizuje to nakład pracy administracyjnej, ponieważ dane są przechowywane w jednym miejscu, a dostęp jest kontrolowany centralnie poprzez role i zasady maskowania. Pozostałe opcje są mniej efektywne: Tworzenie oddzielnych klastrów Redshift dla każdego zespołu jest kosztowne i zwiększa złożoność zarządzania danymi (duplikacja danych, synchronizacja). Tworzenie widoków bazy danych jest możliwe, ale może być mniej elastyczne niż maskowanie danych, szczególnie w przypadku złożonych wymagań anonimizacji, i nadal wymaga zarządzania wieloma widokami. Przeniesienie danych do S3 i użycie AWS Lake Formation jest dobrym rozwiązaniem dla jezior danych, ale w tym scenariuszu dane są już w Redshift, a migracja i budowa jeziora danych to znacznie większy nakład pracy niż wykorzystanie wbudowanych funkcji Redshift.