Wie Dynamic Data Masking in Amazon Redshift Datenschutz und Compliance fördert

• Definieren von Masking-Richtlinien, die benutzerdefinierte Verschleierungsverfahren anwenden (z. B. Masking-Richtlinien zur Behandlung von Kreditkarten, PII-Einträgen, HIPAA- oder GDPR-Anforderungen und mehr)
• Transformieren Sie die Daten zur Abfragezeit, um Masking-Richtlinien anzuwenden.
• Zuordnen von Masking-Richtlinien zu Rollen oder Benutzern
• Verknüpfen Sie mehrere Masking-Richtlinien mit unterschiedlichen Verschleierungsgraden mit derselben Spalte in einer Tabelle und weisen Sie sie verschiedenen Rollen Prioritäten zu, um Konflikte zu vermeiden.
• Implementieren Sie Masking auf Zellebene, indem Sie beim Erstellen Ihrer Masking-Richtlinie bedingte Spalten verwenden.
• Verwendung von Masking-Richtlinien zur teilweisen oder vollständigen Unkenntlichmachung von Daten oder zum Hashing mit Hilfe von benutzerdefinierten Funktionen (UDFs)

Das sagen AWS-Kunden über die DDM Unterstützung (private beta) in Amazon Redshift:

“Baffle bietet datenzentrierten Schutz für Unternehmen über eine Datensicherheitsplattform, die in Bezug auf Anwendungen transparent und im Bereich der Datensicherheit einzigartig ist. Unser Ziel ist es, Datensicherheit nahtlos in jede Datenpipeline zu integrieren. Bisher mussten wir, um Data Masking auf eine Amazon Redshift-Datenquelle anzuwenden, die Daten in einem Amazon S3-Bucket bereitstellen. Durch die Nutzung der dynamischen Data Masking-Funktion von Amazon Redshift können unsere Kunden nun sensible Daten in der gesamten Analyse-Pipeline schützen, von der sicheren Aufnahme bis zur verantwortungsvollen Nutzung, was das Risiko von Verstößen reduziert.”

-Ameesh Divatia, CEO & Co-founder von Baffle

“EnergyAustralia ist ein führender australischer Energieeinzelhändler und -erzeuger, der es sich zur Aufgabe gemacht hat, den Wechsel zu sauberer Energie für seine Kunden so zu gestalten, dass er für alle zuverlässig, erschwinglich und nachhaltig ist. Wir unterstützen alle Bereiche unseres Unternehmens mit Daten- und Analysefunktionen, die zur Optimierung von Geschäftsprozessen und zur Verbesserung der Kundenerfahrung eingesetzt werden. Der Schutz der Daten unserer Kunden hat für unsere Teams oberste Priorität. Früher waren dazu mehrere Schichten von benutzerdefinierten Sicherheitsrichtlinien erforderlich, die es für Analysten erschwerten, die benötigten Daten zu finden. Die neue dynamische AWS Data Masking-Funktion wird unsere Sicherheitsprozesse erheblich vereinfachen, sodass wir die Kundendaten weiterhin schützen und gleichzeitig den Verwaltungsaufwand reduzieren können.”

-William Robson, Data Solutions Design Lead, EnergyAustralia

Use case

Im vorliegenden Anwendungsfall möchte ein Einzelhandelsunternehmen steuern, wie Kreditkartennummern Nutzern je nach deren Berechtigung angezeigt werden. Außerdem sollen die Daten dafür nicht dupliziert werden. Das Unternehmen hat folgende Anforderungen:

• Benutzer aus dem Kundenservice sollen die ersten sechs Ziffern und die letzten vier Ziffern der Kreditkarte zur Kundenüberprüfung einsehen können.
• Benutzer aus der Betrugsbekämpfung sollten die rohe Kreditkartennummer nur dann einsehen können, wenn sie als betrügerisch eingestuft wurde.
• Benutzer aus der Rechnungsprüfung sollten die rohe Kreditkartennummer einsehen können.
• Andere Benutzer sollten die Kreditkartennummer nicht einsehen können.

Überblick über die Lösung

Die Lösung umfasst die Erstellung von Masking-Richtlinien mit unterschiedlichen Masking-Regeln und die Zuordnung einer oder mehrerer Richtlinien zu derselben Rolle und Tabelle mit einer zugewiesenen Priorität, um potenzielle Konflikte zu beseitigen. Diese Richtlinien können Ergebnisse pseudonymisieren oder selektiv annullieren, um die Sicherheitsanforderungen der Einzelhändler zu erfüllen. Wir bezeichnen mehrere Masking-Richtlinien, die mit einer Tabelle verbunden sind, als multimodale Masking-Richtlinie. Eine multimodale Masking-Richtlinie besteht aus drei Teilen:

1. Eine Data Masking-Richtlinie, die die Regeln für die Verschleierung der Daten festlegt
2. Rollen mit unterschiedlichen Zugriffsebenen, je nach Geschäftsvorfall
3. Die Möglichkeit, einem Benutzer oder einer Rolle mehrere Masking-Richtlinien und Tabellenkombinationen mit Priorität zur Konfliktlösung zuzuordnen

Das folgende Diagramm zeigt, wie die DDM-Unterstützung (Preview) in Amazon Redshift-Richtlinien mit Rollen und Benutzern für unseren Anwendungsfall im Einzelhandel funktioniert:

Bei einem Benutzer mit mehreren Rollen wird die Masking-Richtlinie mit der höchsten Anordnungspriorität verwendet. Im folgenden Beispiel ist Ken Teil der Rollen Public und FrdPrvnt. Da die FrdPrvnt-Rolle eine höhere Anordnungspriorität hat, wird card_number_conditional_mask angewendet.

Voraussetzungen

Um diese Lösung zu implementieren, müssen Sie die folgenden Voraussetzungen erfüllen:

1. Sie haben ein AWS-Konto.
2. Sie verfügen über einen bereitgestellten Amazon Redshift-Cluster mit DDM-Unterstützung (Preview) oder eine serverlose Workgroup mit DDM-Unterstützung (Preview).
   • Rufen Sie die bereitgestellte oder serverlose Amazon Redshift-Konsole auf und wählen Sie Create preview cluster.

• • Wählen Sie im Assistenten zum Erstellen von Clustern die Preview-Spur.

3. Sie haben Superuser-Rechte oder die Rolle sys:secadmin auf dem in
Schritt 2 erstellten Amazon Redshift Data Warehouse.

Vorbereitung der Daten

Um unseren Anwendungsfall einzurichten, führen Sie die folgenden Schritte aus:

1. Wählen Sie in der Amazon Redshift-Konsole im Explorer die Option Query editor v2.
   Wenn Sie mit SQL Notebooks vertraut sind, können Sie das Jupyter-Notebook für die Demonstration herunterladen und importieren, um schnell loszulegen.
2. Erstellen Sie die Tabelle und füllen Sie den Inhalt auf.
3. Benutzer erstellen.

   -- 1- Create the credit cards table
   CREATE TABLE credit_cards (
   customer_id INT,
   is_fraud BOOLEAN,
   credit_card TEXT
   );
   -- 2- Populate the table with sample values
   INSERT INTO credit_cards
   VALUES
   (100,'n', '453299ABCDEF4842'),
   (100,'y', '471600ABCDEF5888'),
   (102,'n', '524311ABCDEF2649'),
   (102,'y', '601172ABCDEF4675'),
   (102,'n', '601137ABCDEF9710'),
   (103,'n', '373611ABCDEF6352')
   ;
   --run GRANT to grant SELECT permission on the table
   GRANT SELECT ON credit_cards TO PUBLIC;
   --create four users
   CREATE USER Kate WITH PASSWORD '1234Test!';
   CREATE USER Ken  WITH PASSWORD '1234Test!';
   CREATE USER Bob  WITH PASSWORD '1234Test!';
   CREATE USER Jane WITH PASSWORD '1234Test!';

Umsetzung der Lösung

Um die Sicherheitsanforderungen zu erfüllen, müssen wir sicherstellen, dass jeder Benutzer dieselben Daten auf unterschiedliche Weise sieht, je nach den ihm gewährten Privilegien. Zu diesem Zweck verwenden wir Benutzerrollen in Kombination mit Masking-Richtlinien wie folgt:

1. Erstellen Sie Benutzerrollen und weisen Sie verschiedenen Benutzern unterschiedliche Rollen zu:

   -- 1. Create User Roles
   CREATE ROLE cust_srvc_role;
   CREATE ROLE frdprvnt_role;
   CREATE ROLE auditor_role;
   -- note that public role exist by default.
   
   -- Grant Roles to Users
   GRANT ROLE cust_srvc_role to Kate;
   GRANT ROLE frdprvnt_role  to Ken;
   GRANT ROLE auditor_role   to Bob;
   -- note that regualr_user is attached to public role by default.

2. Erstellen Sie Masking-Richtlinien:

   -- 2. Create Masking policies
   
   -- 2.1 create a masking policy that fully masks the credit card number
   CREATE MASKING POLICY Mask_CC_Full
   WITH (credit_card VARCHAR(256))
   USING ('XXXXXXXXXXXXXXXX');
   
   --2.2- Create a scalar SQL user-defined function(UDF) that partially obfuscates credit card number, only showing the first 6 digits and the last 4 digits
   CREATE FUNCTION REDACT_CREDIT_CARD (text)
     returns text
   immutable
   as $$
     select left($1,6)||'XXXXXX'||right($1,4)
   $$ language sql;
   
   
   --2.3- create a masking policy that applies the REDACT_CREDIT_CARD function
   CREATE MASKING POLICY Mask_CC_Partial
   WITH (credit_card VARCHAR(256))
   USING (REDACT_CREDIT_CARD(credit_card));
   
   -- 2.4- create a masking policy that will display raw credit card number only if it is flagged for fraud 
   CREATE MASKING POLICY Mask_CC_Conditional
   WITH (is_fraud BOOLEAN, credit_card VARCHAR(256))
   USING (CASE WHEN is_fraud 
                    THEN credit_card 
                    ELSE Null 
          END);
   
   -- 2.5- Create masking policy that will show raw credit card number.
   CREATE MASKING POLICY Mask_CC_Raw
   WITH (credit_card varchar(256))
   USING (credit_card);

3. Verknüpfen Sie die Masking-Richtlinien der Tabelle oder Spalte mit dem Benutzer oder der Rolle:

   -- 3. ATTACHING MASKING POLICY
   -- 3.1- make the Mask_CC_Full the default policy for all users
   --    all users will see this masking policy unless a higher priority masking policy is attached to them or their role
   
   ATTACH MASKING POLICY Mask_CC_Full
   ON credit_cards(credit_card)
   TO PUBLIC;
   
   -- 3.2- attach Mask_CC_Partial to the cust_srvc_role role
   --users with the cust_srvc_role role can see partial credit card information
   ATTACH MASKING POLICY Mask_CC_Partial
   ON credit_cards(credit_card)
   TO ROLE cust_srvc_role
   PRIORITY 10;
   
   -- 3.3- Attach Mask_CC_Conditional masking policy to frdprvnt_role role
   --    users with frdprvnt_role role can only see raw credit card if it is fraud
   ATTACH MASKING POLICY Mask_CC_Conditional
   ON credit_cards(credit_card)
   USING (is_fraud, credit_card)
   TO ROLE frdprvnt_role
   PRIORITY 20;
   
   -- 3.4- Attach Mask_CC_Raw masking policy to auditor_role role
   --    users with auditor_role role can see raw credit card numbers
   ATTACH MASKING POLICY Mask_CC_Raw
   ON credit_cards(credit_card)
   TO ROLE auditor_role
   PRIORITY 30;

Testen Sie die Lösung

Bestätigen Sie, dass die Masking-Richtlinien erstellt und hinzugefügt wurden.

1. Prüfen Sie, ob die Masking-Richtlinien mit dem folgenden Code erstellt wurden:

   -- 1.1- Confirm the masking policies are created
   SELECT * FROM svv_masking_policy;

   

2. Prüfen Sie, ob die Masking-Richtlinien angebracht sind:

   -- 1.2- Verify attached masking policy on table/column to user/role.
   SELECT * FROM svv_attached_masking_policy;

   
   Jetzt können wir testen, ob verschiedene Benutzer dieselben Daten je nach ihrer Rolle unterschiedlich maskiert sehen können.

3. Testen Sie, ob die Kundendienstmitarbeiter nur die ersten sechs Ziffern und die letzten vier Ziffern der Kreditkartennummer sehen können:

   -- 1- Confirm that customer service agent can only view the first 6 digits and the last 4 digits of the credit card number
   SET SESSION AUTHORIZATION Kate;
   SELECT * FROM credit_cards;

   

4. Testen Sie, dass die Benutzer der Betrugsbekämpfung die rohe Kreditkartennummer nur dann sehen können, wenn sie als betrügerisch gekennzeichnet ist:

   -- 2- Confirm that Fraud Prevention users can only view fraudulent credit card number
   SET SESSION AUTHORIZATION Ken;
   SELECT * FROM credit_cards;

   

5. Testen Sie, ob die Benutzer von Auditor die rohe Kreditkartennummer sehen können:

   -- 3- Confirm the auditor can view RAW credit card number
   SET SESSION AUTHORIZATION Bob;
   SELECT * FROM credit_cards;

   

6. Testen Sie, dass normale Benutzer keine Ziffern der Kreditkartennummer sehen können:

   -- 4- Confirm that regular users can not view any digit of the credit card number
   SET SESSION AUTHORIZATION Jane;
   SELECT * FROM credit_cards;

   

Anpassung der Masking-Richtlinie

Um eine vorhandene Masking-Richtlinie zu ändern, müssen Sie sie zunächst von der Rolle lösen und dann löschen und neu erstellen.

In unserem Anwendungsfall änderte das Unternehmen die Richtung und beschloss, dass die Kundendienstmitarbeiter nur die letzten vier Ziffern der Kreditkartennummer sehen dürfen sollten.

1. Lösen Sie die Richtlinie und lassen Sie sie fallen:

   --reset session authorization to the default
   RESET SESSION AUTHORIZATION;
   --detach masking policy from the credit_cards table
   DETACH MASKING POLICY Mask_CC_Partial
   ON                    credit_cards(credit_card)
   FROM ROLE             cust_srvc_role;
   -- Drop the masking policy
   DROP MASKING POLICY Mask_CC_Partial;
   -- Drop the function used in masking
   DROP FUNCTION REDACT_CREDIT_CARD (TEXT);

2. Erstellen Sie die Richtlinie erneut und ordnen Sie die Richtlinie der Tabelle oder Spalte dem gewünschten Benutzer oder der gewünschten Rolle zu. Beachten Sie, dass wir diesmal eine skalare Python-UDF erstellt haben. Es ist möglich, je nach Anwendungsfall eine SQL-, Python- und Lambda-UDF zu erstellen.

   -- Re-create the policy and re-attach it to role
   
   -- Create a user-defined function that partially obfuscates credit card number, only showing the last 4 digits
   CREATE FUNCTION REDACT_CREDIT_CARD (credit_card TEXT) RETURNS TEXT IMMUTABLE AS $$
       import re
       regexp = re.compile("^([0-9A-F]{6})[0-9A-F]{5,6}([0-9A-F]{4})")
       match = regexp.search(credit_card)
       if match != None:
           last = match.group(2)
       else:
           last = "0000"
       return "XXXXXXXXXXXX{}".format(last)
   $$ LANGUAGE plpythonu;
   
   --Create a masking policy that applies the REDACT_CREDIT_CARD function
   CREATE MASKING POLICY Mask_CC_Partial
   WITH (credit_card VARCHAR(256))
   USING (REDACT_CREDIT_CARD(credit_card));
   
   -- attach Mask_CC_Partial to the cust_srvc_role role
   -- users with the cust_srvc_role role can see partial credit card information
   ATTACH MASKING POLICY Mask_CC_Partial
   ON credit_cards(credit_card)
   TO ROLE cust_srvc_role
   PRIORITY 10;

3. Testen Sie, ob die Mitarbeiter des Kundendienstes nur die letzten vier Ziffern der Kreditkartennummer einsehen können:

   -- Confirm that customer service agent can only view the last 4 digits of the credit card number
   SET SESSION AUTHORIZATION Kate;
   SELECT * FROM credit_cards;

   

Aufräumen

Wenn Sie mit der Lösung fertig sind, räumen Sie Ihre Ressourcen auf:

1. Lösen Sie die Masking-Richtlinien vom Bildschirm:

   -- Cleanup
   --reset session authorization to the default
   RESET SESSION AUTHORIZATION;
   
   --1.	Detach the masking policies from table
   DETACH MASKING POLICY Mask_CC_Full
   ON credit_cards(credit_card)
   FROM PUBLIC;
   DETACH MASKING POLICY Mask_CC_Partial
   ON credit_cards(credit_card)
   FROM ROLE cust_srvc_role;
   DETACH MASKING POLICY Mask_CC_Conditional
   ON credit_cards(credit_card)
   FROM ROLE frdprvnt_role;
   DETACH MASKING POLICY Mask_CC_Raw
   ON credit_cards(credit_card)
   FROM ROLE auditor_role;

2. Lassen Sie die Masking-Maßnahmen fallen:

   -- 2.	Drop the masking policies 
   DROP MASKING POLICY Mask_CC_Full;
   DROP MASKING POLICY Mask_CC_Partial;
   DROP MASKING POLICY Mask_CC_Conditional;
   DROP MASKING POLICY Mask_CC_Raw;

3. Widerrufen und löschen Sie jeden Benutzer und jede Rolle:

   -- 3.	Revoke/Drop - role/user 
   REVOKE ROLE cust_srvc_role from Kate;
   REVOKE ROLE frdprvnt_role  from Ken;
   REVOKE ROLE auditor_role   from Bob;
   
   DROP ROLE cust_srvc_role;
   DROP ROLE frdprvnt_role;
   DROP ROLE auditor_role;
   
   DROP USER Kate;
   DROP USER Ken;
   DROP USER Bob;
   DROP USER Jane;

4. Verwerfen Sie die Funktion und die Tabelle:

   -- 4.	Drop function and table 
   DROP FUNCTION REDACT_CREDIT_CARD (credit_card TEXT);
   DROP TABLE credit_cards;

Hinweise und Best Practices

Beachten Sie Folgendes:

• Erstellen Sie immer eine Standardrichtlinie für den öffentlichen Benutzer. Wenn Sie einen neuen Benutzer erstellen, wird diesem immer eine Mindestrichtlinie zugewiesen. Sie wird die beabsichtigte Sicherheitslage durchsetzen.
• Denken Sie daran, dass DDM-Richtlinien in Amazon Redshift immer der Konvention für Aufruferberechtigungen folgen, nicht für Definer (weitere Informationen finden Sie unter Sicherheit und Berechtigungen für gespeicherte Prozeduren). Das bedeutet, dass die Masking-Richtlinien auf der Grundlage des Benutzers oder der Rolle, die sie ausführt, anwendbar sind.
• Um die beste Leistung zu erzielen, sollten Sie die Masking-Funktionen nach Möglichkeit mit einer skalaren SQL UDF erstellen. Die Leistung skalarer UDFs ist in der Regel in der Reihenfolge SQL – Python – Lambda. Im Allgemeinen sind SQL-UDFs leistungsfähiger als Python-UDFs und letztere leistungsfähiger als skalare Lambda-UDFs.
• DDM-Richtlinien in Amazon Redshift werden vor allen Prädikat- oder Verknüpfungsoperationen angewendet. Wenn Sie zum Beispiel eine Verknüpfung einer maskierten Spalte (gemäß Ihrer Zugriffsrichtlinie) mit einer unmaskierten Spalte durchführen, führt die Verknüpfung zu einer Fehlanpassung. Das ist ein erwartetes Verhalten.
• Lösen Sie eine Masking-Richtlinie immer von allen Benutzern oder Rollen, bevor Sie sie aufheben.
• Zum jetzigen Zeitpunkt hat die Lösung die folgenden Einschränkungen:
  • Sie können eine Masking-Richtlinie auf Tabellen und Spalten anwenden und sie einem Benutzer oder einer Rolle zuordnen, aber Gruppen werden nicht unterstützt.
  • Sie können keine Masking-Richtlinie für Ansichten, materialisierte Ansichten und externe Tabellen erstellen.
  • Die DDM-Unterstützung (Preview) in Amazon Redshift ist in den folgenden Regionen verfügbar: US East (Ohio), US East (N. Virginia), US West (Oregon), Asia Pacific (Tokio), Europa (Irland) und Europa (Stockholm).

Leistungskriterien

Auf der Grundlage verschiedener Tests mit TPC-H-Datensätzen haben wir festgestellt, dass integrierte Funktionen leistungsfähiger sind als extern mit skalaren Python- oder Lambda-UDFs erstellte Funktionen.

Erweitern Sie die Lösung

Sie können diese Lösung weiter ausbauen und eine Masking-Richtlinie einrichten, die den Zugriff auf SSN und E-Mail-Adressen wie folgt einschränkt:

• Kundendienstmitarbeiter, die auf vorgefertigte Dashboards zugreifen, dürfen nur die letzten vier Ziffern der SSN und vollständige E-Mail-Adressen für die Korrespondenz anzeigen.
• Analysten können keine SSNs oder E-Mail-Adressen einsehen.
  Prüfdienste können auf Rohwerte für SSNs sowie auf E-Mail-Adressen zugreifen.

Weitere Informationen finden Sie unter Verwendung der DDM-Unterstützung (Preview) in Amazon Redshift für E-Mail- und SSN-Maskierung.

Zusammenfassung

In diesem Beitrag haben wir besprochen, wie Sie die DDM-Unterstützung (Preview) in Amazon Redshift nutzen können, um konfigurationsgesteuerte, konsistente, formatbewahrende und irreversible maskierte Datenwerte zu definieren. Mit der DDM-Unterstützung (Preview) in Amazon Redshift können Sie Ihren Data Masking-Ansatz mithilfe der vertrauten SQL-Sprache steuern. Sie können die Vorteile der rollenbasierten Zugriffskontrollfunktion von Amazon Redshift nutzen, um verschiedene Ebenen des Data Masking zu implementieren. Sie können eine Masking-Richtlinie erstellen, um zu bestimmen, welche Spalte maskiert werden muss, und Sie haben die Flexibilität zu wählen, wie die maskierten Daten angezeigt werden sollen. Sie können z. B. alle Informationen der Daten vollständig ausblenden, teilweise reale Werte durch Platzhalterzeichen ersetzen oder Ihre eigene Methode zur Maskierung der Daten mithilfe von SQL-Ausdrücken, Python oder Lambda UDFs definieren. Außerdem können Sie eine bedingte Maskierung auf der Grundlage anderer Spalten anwenden, die die Spaltendaten in einer Tabelle selektiv auf der Grundlage der Werte in einer oder mehreren Spalten schützt.