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;
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;
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;
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;
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;
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;
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
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: