Verwenden der externen Tokenisierung

Dieses Thema enthält eine Anleitung für das Verwenden der externen Tokenisierung in Snowflake mit Partnerintegrationen und zum Erstellen einer kundenspezifischen Integration für die externe Tokenisierung.

Snowflake unterstützt die externe Tokenisierung auf AWS, Microsoft Azure und Google Cloud Platform.

Beachten Sie, dass eine Maskierungsrichtlinie für externe Tokenisierung einem Tag zugewiesen werden kann, um eine Tag-basierte externe Tokenisierung zu ermöglichen. Weitere Informationen zur Zuweisung einer Maskierungsrichtlinie zu einem Tag finden Sie unter Tag-basierte Maskierungsrichtlinien.

Wichtig

Für die externe Tokenisierung sind Schreiben von externen Funktionen erforderlich, die in der Snowflake Standard Edition enthalten sind, und Sie können externe Funktionen mit einem Tokenisierungsanbieter verwenden.

Wenn Sie jedoch Ihren Tokenisierungsanbieter in die externe Tokenisierung von Snowflake integrieren möchten, müssen Sie ein Upgrade auf Enterprise Edition oder höher durchführen.

Wenden Sie sich für ein Upgrade direkt an den Snowflake-Support.

Partnerintegrationen für die externe Tokenisierung

Die folgenden Partner ermöglichen die externe Tokenisierung in Snowflake. Um diese Partnerintegrationen zu nutzen, befolgen Sie die Anweisungen in der Partnerdokumentation, oder wenden Sie sich an den Partner, um den Konfigurationsprozess auszuführen:

Erstellen einer kundenspezifischen Integration für die externe Tokenisierung

Führen Sie die folgenden Schritte aus, um eine kundenspezifische Integration für die externe Tokenisierung zu erstellen:

Schritt 1: Externe Funktion erstellen

Erstellen Sie eine externe Funktion in Snowflake, und konfigurieren Sie Ihre Cloudanbieter-Umgebung für die Kommunikation mit der externen Funktion. Weitere Details dazu finden Sie unter:

Schritt 2: Kundenspezifischer Rolle Maskierungsrichtlinienberechtigungen erteilen

Ein Sicherheits- oder Datenschutzbeauftragter sollte als Administrator der Maskierungsrichtlinie (d. h. kundenspezifische Rolle: MASKING_ADMIN) fungieren und über Berechtigungen zum Definieren, Verwalten und Anwenden von Maskierungsrichtlinien auf Spalten verfügen.

Snowflake stellt die folgenden Berechtigungen zur Verfügung, die einem Sicherheits- oder Datenschutzbeauftragten erteilt werden können, um Maskierungsrichtlinien für Sicherheit auf Spaltenebene zu verwalten:

Berechtigung

Beschreibung

CREATE MASKING POLICY

Diese Berechtigung auf Schemaebene steuert, wer Maskierungsrichtlinien erstellen kann.

APPLY MASKING POLICY

Diese Berechtigung auf Kontoebene steuert, wer Maskierungsrichtlinien für Spalten festlegen/aufheben kann. Sie wird standardmäßig der Rolle ACCOUNTADMIN erteilt. . Diese Berechtigung ermöglicht nur das Anwenden einer Maskierungsrichtlinie auf eine Spalte und bietet keine der zusätzlichen Tabellenberechtigungen, die in Zugriffssteuerungsrechte beschrieben sind.

APPLY ON MASKING POLICY

Optional. Diese Berechtigung auf Richtlinienebene kann von einem Richtlinieneigentümer verwendet werden, um die Operationen zum Festlegen/Aufheben einer bestimmten Maskierungsrichtlinie für bestimmte Spalten an die Objekteigentümer (d. h. der Rolle mit der OWNERSHIP-Berechtigung für das Objekt) zu übergeben. . Snowflake unterstützt die besitzverwaltete Zugriffssteuerung, bei der Objekteigentümer auch als Dateneigentümer gelten. . Wenn der Richtlinienadministrator den Objekteigentümern hinsichtlich der Dateneigentümerschaft für geschützte Spalten vertraut, kann der Richtlinienadministrator diese Berechtigung verwenden, um die Operationen zum Festlegen/Aufheben von Richtlinien zu dezentralisieren.

Im folgenden Beispiel wird die Rolle MASKING_ADMIN erstellt, und dieser Rolle werden Maskierungsrichtlinienberechtigungen erteilt.

Erstellen einer kundenspezifischen Rolle für den Administrator einer Maskierungsrichtlinie:

use role useradmin;
CREATE ROLE masking_admin;
Copy

Zuweisen von Berechtigungen zur Rolle masking_admin:

use role securityadmin;
GRANT CREATE MASKING POLICY on SCHEMA <db_name.schema_name> to ROLE masking_admin;
GRANT APPLY MASKING POLICY on ACCOUNT to ROLE masking_admin;
Copy

Zulassen des Setzens/Aufhebens der Maskierungsrichtlinie ssn_mask für die Rolle table_owner (optional):

GRANT APPLY ON MASKING POLICY ssn_mask to ROLE table_owner;
Copy

Wobei:

  • db_name.schema_name

    Gibt den Bezeichner des Schemas an, dem die Berechtigung erteilt werden soll.

Weitere Informationen dazu finden Sie unter:

Schritt 3: Kundenspezifische Rolle einem Benutzer zuweisen

Weisen Sie einem Benutzer, der als Sicherheits- oder Datenschutzbeauftragter fungiert, die kundenspezifische Rolle MASKING_ADMIN zu.

use role useradmin;
grant role masking_admin to user jsmith;
Copy

Schritt 4: Maskierungsrichtlinie erstellen

In diesem typischen Beispiel werden Benutzern mit der benutzerdefinierten Rolle ANALYST die detokenisierten E-Mail-Werte angezeigt. Benutzern ohne die benutzerdefiniere Rolle ANALYST werden tokenisierte Werte angezeigt.

Die externe Funktion zum Detokenisieren der E-Mail-Werte ist de_email().

-- create masking policy

create or replace masking policy email_de_token as (val string) returns string ->
  case
    when current_role() in ('ANALYST') then de_email(val)
    else val
  end;
Copy

Tipp

Wenn Sie eine bestehende Maskierungsrichtlinie aktualisieren möchten und dazu die aktuelle Definition der Richtlinie anzeigen müssen, können Sie die Funktion GET_DDL aufrufen oder den Befehl DESCRIBE MASKING POLICY ausführen.

Schritt 5: Maskierungsrichtlinie auf Tabellen- oder Ansichtsspalte anwenden

In diesen Beispielen wird davon ausgegangen, dass bei der Erstellung der Tabelle auf die Tabellenspalte und bei der Erstellung der Ansicht auf die Ansichtsspalte keine Maskierungsrichtlinie angewendet wird. Sie können optional eine Maskierungsrichtlinie auf eine Tabellenspalte anwenden, wenn Sie die Tabelle mit einer CREATE TABLE-Anweisung oder eine Ansichtsspalte mit einer CREATE VIEW-Anweisung erstellen.

Führen Sie die folgenden Anweisungen aus, um die Richtlinie auf eine Tabellenspalte oder eine Ansichtsspalte anzuwenden.

-- apply masking policy to a table column

alter table if exists user_info modify column email set masking policy email_de_token;

-- apply the masking policy to a view column

alter view user_info_v modify column email set masking policy email_de_token;
Copy

Schritt 6: Daten in Snowflake abfragen

Führen Sie in Snowflake zwei verschiedene Abfragen aus, eine Abfrage mit der kundenspezifische Rolle ANALYST und eine andere Abfrage mit einer anderen Rolle, um zu überprüfen, ob Benutzern ohne kundenspezifischer ANALYST-Rolle die tokenisierten Werte angezeigt werden.

-- using the ANALYST custom role

use role ANALYST;
select email from user_info; -- should see plain text value

-- using the PUBLIC system role

use role public;
select email from user_info; -- should see tokenized value
Copy

Best Practices für externe Tokenisierung

  • Systeme synchronisieren. Auf AWS ist es hilfreich, Benutzer und Rollen im Identitätsanbieter (IdP) Ihres Unternehmens mit Snowflake und Protegrity zu synchronisieren. Wenn Benutzer und Rollen nicht synchronisiert sind, können unerwartete Verhaltensweisen, Fehlermeldungen und komplexe Problembehandlungen in Bezug auf externe Funktionen, API-Integrationen, Maskierungsrichtlinien und Tokenisierungsrichtlinien auftreten. Eine Möglichkeit besteht darin, SCIM zu verwenden, um Benutzer und Rollen mit IdP und Snowflake synchron zu halten.

  • Grundursache für Fehler. Da für die externe Tokenisierung die Koordination mehrerer Systeme erforderlich ist (z. B. IdP, Snowflake, Protegrity, AWS, Azure, GCP), sollten Sie immer die Berechtigungen, aktuellen Einschränkungen, externen Funktionen, API-Integration, Maskierungsrichtlinien und die Spalten mit Maskierungsrichtlinien für externe Tokenisierung in Snowflake überprüfen. Informationen zur Ermittlung der Grundursache finden Sie unter:

Nächste Themen: