Grundlegendes zur Sicherheit auf Spaltenebene¶

Was sind Maskierungsrichtlinien?¶

Snowflake unterstützt Maskierungsrichtlinien als Objekte auf Schemaebene, um vertrauliche Daten vor unbefugtem Zugriff zu schützen und autorisierten Benutzern den Zugriff auf vertrauliche Daten zur Laufzeit von Abfragen zu ermöglichen. Dies bedeutet, dass in Snowflake vertrauliche Daten in einer vorhandenen Tabelle nicht geändert werden (d. h. keine statische Maskierung). Wenn Benutzer eine Abfrage ausführen, für die eine Maskierungsrichtlinie gilt, bestimmen die Bedingungen der Maskierungsrichtlinie, ob nicht autorisierten Benutzern maskierte, teilweise maskierte, verborgene oder tokenisierte Daten angezeigt werden. Maskierungsrichtlinien als Objekt auf Schemaebene bieten auch Flexibilität bei der Auswahl eines zentralisierten, dezentralisierten oder hybriden Verwaltungsansatzes. Weitere Informationen dazu finden Sie unter Verwalten der Sicherheit auf Spaltenebene (unter diesem Thema).

Maskierungsrichtlinien können Bedingungen und Funktionen enthalten, um die Daten zur Laufzeit der Abfrage bei Erfüllung der Bedingungen zu transformieren. Der richtliniengesteuerte Ansatz unterstützt die Aufgabentrennung, damit Sicherheitsteams Richtlinien zum Schutz vertraulicher Daten definieren können, die selbst für den Eigentümer eines Objekts (d. h. der Rolle mit OWNERSHIP-Berechtigung für das Objekt, z. B. eine Tabelle oder eine Ansicht) gelten, welche normalerweise vollen Zugriff auf die zugrunde liegenden Daten haben.

Beispielsweise können Administratoren von Maskierungsrichtlinien eine Maskierungsrichtlinie implementieren, sodass Analysten (d. h. Benutzer mit der kundenspezifischen Rolle ANALYST) nur die letzten vier Ziffern einer Telefonnummer und keine Sozialversicherungsnummern angezeigt werden, während Vertretern des Kundensupports (d. h. Benutzer mit der kundenspezifischen Rolle SUPPORT) die gesamte Telefonnummer und die Sozialversicherungsnummer für Anwendungsfälle zur Kundenüberprüfung angezeigt werden.

Eine Maskierungsrichtlinie besteht aus einem einzelnen Datentyp, einer oder mehreren Bedingungen sowie einer oder mehreren Maskierungsfunktionen.

• Sie können die Maskierungsrichtlinie auf eine oder mehrere Tabellen- oder Ansichtsspalten mit passendem Datentyp anwenden. Beispielsweise können Sie eine Richtlinie für eine E-Mail-Adresse einmal definieren und auf Tausenden von E-Mail-Spalten in Datenbanken und Schemas anwenden.

• Die Bedingungen für die Maskierungsrichtlinie können mit Funktionen für bedingte Ausdrücke und Kontextfunktionen oder durch Abfragen einer kundenspezifischen Berechtigungstabelle ausgedrückt werden. Sie können die Kontextfunktionen INVOKER_ROLE und INVOKER_SHARE für Ansichten bzw. Freigaben verwenden.

• Maskierungsfunktionen können beliebige integrierte Funktionen (z. B. REGEXP_REPLACE, SHA2 , SHA2_HEX), Überblick über benutzerdefinierte Funktionen oder Schreiben von externen Funktionen (zum Detokenisieren mithilfe eines externen Tokenisierungsanbieters) sein.

Snowflake stellt sichere Ansichten bereit, um den Zugriff auf vertrauliche Daten einzuschränken. Allerdings stellen sichere Ansichten bei einer großen Anzahl von Ansichten und den aus jeder Ansicht abgeleiteten Business Intelligence-Dashboards (BI) Herausforderungen für das Management dar. Maskierungsrichtlinien lösen diese Verwaltungsherausforderung, indem sie die explosionsartige Zunahme von zu verwaltenden Ansichten und Dashboards vermeiden.

Maskierungsrichtlinien unterstützen die Aufgabentrennung (Segregation of Duty, SoD) durch die Rollentrennung zwischen Richtlinienadministratoren und Objekteigentümer. Sichere Ansichten haben keine SoD, was eine tiefgreifende Einschränkung für deren Nutzen darstellt. Diese Rollentrennung führt zu folgenden Standardeinstellungen:

• Objektbesitzer (d. h. die Rolle mit OWNERSHIP-Berechtigung für das Objekt) haben keine Berechtigung zum Deaktivieren von Maskierungsrichtlinien.

• Objektbesitzern werden keine Daten von Spalten angezeigt, für die eine Maskierungsrichtlinie gilt.

Weitere Informationen zur Verwaltung von Rollen und Berechtigungen finden Sie unter Verwalten der Sicherheit auf Spaltenebene (unter diesem Thema) und Zugriffssteuerungsrechte.

-- Dynamic Data Masking

CREATE MASKING POLICY employee_ssn_mask AS (val string) RETURNS string ->
  CASE
    WHEN CURRENT_ROLE() IN ('PAYROLL') THEN val
    ELSE '******'
  END;

-- External Tokenization

  CREATE MASKING POLICY employee_ssn_detokenize AS (val string) RETURNS string ->
  CASE
    WHEN CURRENT_ROLE() IN ('PAYROLL') THEN ssn_unprotect(VAL)
    ELSE val -- sees tokenized data
  END;

Vorteile¶

In der folgenden Tabelle werden die Vorteile der dynamischen Datenmaskierung und der externen Tokenisierung verglichen.

Einschränkungen¶

In der folgenden Tabelle werden die aktuellen Einschränkungen für die Sicherheit auf Spaltenebene beschrieben. Ein Häkchen (d. h. ✔) zeigt eine Einschränkung oder einen Mangel an aktueller Unterstützung für das Feature an.

Hinweise¶

• Seien Sie vorsichtig, wenn Sie Werte aus einer Quellspalte, die eine Maskierungsrichtlinie für die Quellspalte hat, in eine Zielspalte ohne Maskierungsrichtlinie für die Zielspalte einfügen. Da eine Maskierungsrichtlinie für die Quellspalte festgelegt ist, kann eine Rolle, die nicht maskierte Spaltendaten anzeigt, auch nicht maskierte Daten in eine andere Spalte einfügen, wo jede Rolle, die über die erforderlichen Berechtigungen für die Tabelle oder Ansicht verfügt, den Wert sehen kann.

• Wenn eine Rolle, der maskierte Daten in der Quellspalte angezeigt werden, diese Werte in eine Zielspalte einfügt, bleiben die eingefügten Werte maskiert. Wenn in der Zielspalte keine Maskierungsrichtlinie festgelegt ist, wird Benutzern, die über die erforderlichen Berechtigungen für die Tabelle oder Ansicht verfügen, in der Zielspalte möglicherweise eine Kombination aus maskierten und nicht maskierten Werten angezeigt. Deshalb gilt Folgendes als bewährte Praxis:

  • Gehen Sie bei der Anwendung von Maskierungsrichtlinien auf Spalten besonders sorgfältig vor.

  • Überprüfen Sie Abfragen mithilfe von Spalten, die über Maskierungsrichtlinien verfügen, bevor Sie den Benutzern Tabellen und Ansichten zur Verfügung stellen.

  • Bestimmen Sie zusätzliche Tabellen und Ansichten (d. h. Zielspalten), in denen die Daten in der Quellspalte angezeigt werden können.

  • Weitere Informationen dazu finden Sie unter Spalten mit einer Maskierungsrichtlinie erhalten (unter diesem Thema).

• Seien Sie vorsichtig, wenn Sie das Setup-Skript für eine Snowflake Native App erstellen und die Maskierungsrichtlinie in einem versionierten Schema vorliegt. Weitere Informationen dazu finden Sie unter Hinweise zum Versionsschema.

Aktive Rollenhierarchie und Zuordnungstabellen¶

Die Richtlinienbedingungen können die aktiven Primär- und Sekundärrollen des Benutzers in einer Sitzung direkt auswerten, aktive Rollen in einer Zuordnungstabelle suchen oder beides tun, je nachdem, wie der Richtlinienadministrator die Richtlinie schreiben möchte. Wenn die Richtlinie ein Lookup auf einer Zuordnungstabelle enthält, erstellen Sie eine zentralisierte Zuordnungstabelle und speichern Sie die Zuordnungstabelle in derselben Datenbank wie die geschützte Tabelle. Dies ist besonders wichtig, wenn die Richtlinie die Funktion IS_DATABASE_ROLE_IN_SESSION aufruft. Weitere Informationen dazu finden Sie in den Nutzungshinweisen.

Für diese Anwendungsfälle empfiehlt Snowflake, die Richtlinienbedingungen so zu schreiben, dass sie die Funktion IS_ROLE_IN_SESSION oder die Funktion IS_DATABASE_ROLE_IN_SESSION aufrufen, je nachdem, ob Sie eine Kontorolle oder eine Datenbankrolle angeben möchten. Weitere Beispiele finden Sie unter:

• Abschnitt Beispiele der Funktion IS_ROLE_IN_SESSION.

• IS_DATABASE_ROLE_IN_SESSION

• Freigeben von Daten, die durch eine Richtlinie geschützt sind

Weitere Beispiele für die Verwendung von Kontextfunktionen und Maskierungsrichtlinien finden Sie unter Erweiterte Sicherheit auf Spaltenebene.

Maskierungsrichtlinien auf Spalten anwenden¶

Wenn eine Spalte nicht durch eine Maskierungsrichtlinie geschützt ist, gibt es zwei Optionen, um eine Maskierungsrichtlinie auf eine Spalte in einer Tabelle oder Ansicht anzuwenden:

1. Bei einer neuen Tabelle oder Ansicht wenden Sie die Richtlinie mit einer CREATE TABLE-Anweisung auf eine Tabellenspalte bzw. mit einer CREATE VIEW-Anweisung auf eine Ansichtsspalte an.

2. Bei einer neuen Tabelle oder Ansicht wenden Sie die Richtlinie mit einer ALTER TABLE … ALTER COLUMN-Anweisung auf eine Tabellenspalte bzw. mit einer ALTER VIEW-Anweisung auf eine Ansichtsspalte an.

Führen Sie für eine neue Tabelle oder Ansicht die folgenden Anweisungen aus:

-- table
CREATE OR REPLACE TABLE user_info (ssn string masking policy ssn_mask);

-- view
CREATE OR REPLACE VIEW user_info_v (ssn masking policy ssn_mask_v) AS SELECT * FROM user_info;

Copy

Führen Sie für eine bestehende Tabelle oder Ansicht die folgenden Anweisungen aus:

-- table
ALTER TABLE IF EXISTS user_info MODIFY COLUMN ssn_number SET MASKING POLICY ssn_mask;

-- view
ALTER VIEW user_info_v MODIFY COLUMN ssn_number SET MASKING POLICY ssn_mask_v;

Copy

Weitere Informationen zu Syntax und Verwendung finden Sie unter ALTER TABLE … ALTER COLUMN und ALTER VIEW.

Weitere Informationen zur Verwendung von UDFs in Maskierungsrichtlinien finden Sie unter Benutzerdefinierte Funktionen in einer Maskierungsrichtlinie (unter diesem Thema).

Bedingte Maskierungsrichtlinie auf eine Spalte anwenden¶

Nach dem Erstellen einer Maskierungsrichtlinie mit bedingten Spalten gibt es zwei Möglichkeiten, eine bedingte Maskierungsrichtlinie für eine Spalte festzulegen, die noch nicht durch eine Maskierungsrichtlinie geschützt ist:

1. Bei einer neuen Tabelle oder Ansicht wenden Sie die Richtlinie auf eine Tabellen- oder Ansichtsspalte mit der entsprechenden CREATE-Anweisung an.

   Weitere Informationen zu Syntax und Nutzung finden Sie unter:

   • CREATE TABLE

   • CREATE VIEW

   • CREATE MATERIALIZED VIEW

   Führen Sie für eine neue Tabelle oder Ansicht die folgenden Anweisungen aus:

   -- table
   CREATE OR REPLACE TABLE user_info (email string masking policy email_visibility) USING (email, visibility);
   
   --view
   CREATE OR REPLACE VIEW user_info_v (email masking policy email_visibility) USING (email, visibility) AS SELECT * FROM user_info;
   

   Copy

2. Bei einer vorhandenen Tabelle oder Ansicht legen Sie die Richtlinie für eine Tabellen- oder Ansichtsspalte mit der entsprechenden ALTER-Anweisung fest.

   Weitere Informationen zu Syntax und Nutzung finden Sie unter:

   • ALTER TABLE

   • ALTER TABLE … ALTER COLUMN

   • ALTER VIEW

   • ALTER MATERIALIZED VIEW

   Führen Sie für eine bestehende Tabelle oder Ansicht die folgenden Anweisungen aus:

   -- table
   ALTER TABLE IF EXISTS user_info MODIFY COLUMN email
   SET MASKING POLICY email_visibility USING (EMAIL, VISIBILITY);
   
   -- VIEW
   ALTER VIEW user_info_v MODIFY COLUMN email
   SET MASKING POLICY email_visibility USING (email, visibility);
   

   Copy

Maskierungsrichtlinie auf einer Spalte ersetzen¶

Sobald eine Maskierungsrichtlinie für eine Spalte festgelegt wurde, gibt es zwei verschiedene Möglichkeiten, die Maskierungsrichtlinie für die Spalte durch eine andere Maskierungsrichtlinie zu ersetzen, ohne die gesamte Tabelle oder Ansicht ersetzen zu müssen.

In diesen Beispielen werden ALTER TABLE-Befehle verwendet. Die gleiche Vorgehensweise gilt für Ansichten mit dem Befehl ALTER VIEW:

• Heben Sie mit einer Anweisung die Richtlinie für eine Tabellenspalte auf, und legen Sie dann mit einer anderen Anweisung eine neue Richtlinie für die Spalte fest:

  ALTER TABLE t1 MODIFY COLUMN c1 UNSET MASKING POLICY;
  
  ALTER TABLE t1 MODIFY COLUMN c1 SET MASKING POLICY p2;
  

  Copy

• Verwenden Sie das Schlüsselwort FORCE, um die Richtlinie mit nur einer einzigen Anweisung zu ersetzen:

  ALTER TABLE t1 MODIFY COLUMN c1 SET MASKING POLICY p2 FORCE;
  

  Copy

  Hinweis:

  • Die Verwendung des Schlüsselworts FORCE setzt voraussetzt, dass der Datentyp der Richtlinie in der ALTER TABLE-Anweisung (d. h. STRING) mit dem Datentyp der aktuell für die Spalte festgelegten Maskierungsrichtlinie (d. h. STRING) übereinstimmt.

  • Das Schlüsselwort FORCE kann mit der USING-Klausel kombiniert werden, um eine bedingte Maskierungsrichtlinie für eine Spalte festzulegen:

    ALTER TABLE t1 MODIFY COLUMN c1 SET MASKING POLICY policy1 USING (c1, c3, c4) FORCE;
    

    Copy

Zeilenzugriffsrichtlinien¶

Eine bestimmte Tabellen- oder Ansichtsspalte kann entweder in der Signatur einer Maskierungsrichtlinie oder in der Signatur einer Zeilenzugriffsrichtlinie angegeben werden. Oder anders ausgedrückt, dieselbe Spalte kann nicht gleichzeitig in einer Maskierungsrichtliniensignatur und in einer Zeilenzugriffsrichtliniensignatur angegeben werden.

Dieses Verhalten gilt auch für Spalten, die als bedingte Spalten in einer Maskierungsrichtlinie verwendet werden.

Weitere Informationen dazu finden Sie unter CREATE MASKING POLICY und CREATE ROW ACCESS POLICY.

Funktionieren von Richtlinien simulieren¶

Rufen Sie die Funktion POLICY_CONTEXT auf, um eine Abfrage auf einer Spalte, die durch eine Maskierungsrichtlinie geschützt ist, auf einer Tabelle oder Ansicht, die durch eine Zeilenzugriffsrichtlinie geschützt ist, oder beides, wenn die Tabelle oder Ansicht durch beide Richtlinientypen geschützt ist.

Materialisierte Ansichten¶

Mit Snowflake können Sie eine Maskierungsrichtlinie für eine Spalte der materialisierten Ansicht festlegen. Zur Abfragelaufzeit führt der Abfrageplan alle Maskierungsrichtlinien aus, die vor dem Umschreiben der materialisierten Ansicht vorhanden sind. Sobald die materialisierte Ansicht umgeschrieben wird, können keine Maskierungsrichtlinien mehr für Spalten der materialisierten Ansicht festgelegt werden.

Es gibt zwei Optionen zum Festlegen einer Maskierungsrichtlinie für eine Spalte der materialisierten Ansicht:

1. Führen Sie für eine neue materialisierte Ansicht eine CREATE MATERIALIZED VIEW-Anweisung aus:

   CREATE OR REPLACE MATERIALIZED VIEW user_info_mv
     (ssn_number masking policy ssn_mask)
   AS SELECT ssn_number FROM user_info;
   

   Copy

2. Für eine vorhandene materialisierte Ansicht führen Sie eine ALTER VIEW … MODIFY COLUMN-Anweisung auf der materialisierten Ansicht aus, wie im Abschnitt Maskierungsrichtlinien auf Spalten anwenden (unter diesem Thema) beschrieben.

Zusätzlich gibt es die beiden folgenden Einschränkungen in Bezug auf Maskierungsrichtlinien und materialisierte Ansichten:

1. Eine Maskierungsrichtlinie kann nicht für eine Tabellenspalte festgelegt werden, wenn bereits eine materialisierte Ansicht aus der zugrunde liegenden Tabelle erstellt wurde. Snowflake gibt die folgende Fehlermeldung zurück, wenn dieser Versuch unternommen wird:

   SQL execution error: One or more materialized views exist on the table. number of mvs=<number>, table name=<table_name>.
   

   Copy

2. Wenn eine Maskierungsrichtlinie für eine zugrunde liegende Tabellenspalte festgelegt ist und eine materialisierte Ansicht auf Basis dieser Tabelle erstellt wird, enthält die materialisierte Ansicht nur Spalten, die nicht durch eine Maskierungsrichtlinie geschützt sind. Snowflake gibt auch die folgende Fehlermeldung zurück, wenn versucht wird, eine oder mehrere Spalten einzuschließen, die durch eine Maskierungsrichtlinie geschützt sind:

   Unsupported feature 'CREATE ON MASKING POLICY COLUMN'.
   

   Copy

Dynamische Tabellen¶

Sie können eine dynamische Tabelle mit einer Zeilenzugriffsrichtlinie, einer Maskierungsrichtlinie und einem Tag erstellen. Weitere Informationen dazu finden Sie unter:

• CREATE DYNAMIC TABLE

• Zusätzliche Einschränkungen bei inkrementellen Aktualisierungen

Spalten mit Maskierungsrichtlinie abrufen¶

Führen Sie die folgende Anweisung aus, um eine Liste der Spalten mit Maskierungsrichtlinien abzurufen. Weitere Informationen dazu finden Sie unter POLICY_REFERENCES.

SELECT * from table(
  INFORMATION_SCHEMA.POLICY_REFERENCES(
    policy_name=>'<policy_name>'
  )
);

Copy

Führen Sie eine DESCRIBE TABLE- oder DESCRIBE VIEW-Anweisung aus, um die Maskierungsrichtlinie für eine Spalte in einer Tabelle oder Ansicht anzuzeigen.

Objekt-Tagging und Maskierungsrichtlinien¶

Weitere Details dazu finden Sie unter Tag-basierte Maskierungsrichtlinien.

Beachten Sie, dass eine Maskierungsrichtlinie, die einer Spalte direkt zugewiesen ist, Vorrang vor einer Tag-basierten Maskierungsrichtlinie hat.

Hashing-, Kryptographie- und Verschlüsselungsfunktionen in Maskierungsrichtlinien¶

Hashing und Kryptografie/Prüfsumme können in Maskierungsrichtlinien verwendet werden, um sensible Daten zu maskieren.

Weitere Informationen dazu finden Sie unter Erweiterte Sicherheit auf Spaltenebene.

Externe Tabellen¶

Sie können der Spalte VALUE der externen Tabelle keine Maskierungsrichtlinie zuweisen, wenn Sie die externe Tabelle mit einer CREATE EXTERNAL TABLE-Anweisung erstellen, da diese Spalte standardmäßig automatisch erstellt wird.

Sie können der Spalte VALUE der externen Tabelle keine Maskierungsrichtlinie zuweisen, indem Sie eine ALTER TABLE … ALTER COLUMN-Anweisung auf der externen Tabelle ausführen. Der Datentyp der Maskierungsrichtlinie, die die Spalte VALUE schützt, muss VARIANT sein.

ALTER TABLE t1 MODIFY COLUMN VALUE SET MASKING POLICY p1;

Copy

Sie können einer virtuellen Spalte in einer externen Tabelle wie folgt eine Maskierungsrichtlinie zuweisen:

• Setzen Sie die Eigenschaft EXEMPT_OTHER_POLICIES von Maskierungsrichtlinien auf TRUE für die Maskierungsrichtlinie, die die Spalte VALUE in der externen Tabelle schützt.

  Wenn diese Eigenschaft noch nicht festgelegt ist, führen Sie eine CREATE OR REPLACE-Anweisung für die Maskierungsrichtlinie aus, die die Spalte VALUE schützt, und geben Sie die Eigenschaft EXEMPT_OTHER_POLICIES an. Die virtuelle Spalte erbt die Richtlinie, die die VALUE-Spalte schützt, und diese Eigenschaft ermöglicht es der Richtlinie auf der virtuellen Spalte, die geerbte Richtlinie zu überschreiben. Weitere Details dazu finden Sie unter CREATE MASKING POLICY.

• Weisen Sie der virtuellen Spalte mit einem ALTER TABLE-Befehl eine andere Maskierungsrichtlinie zu. Diese Richtlinie kann weniger streng sein als die Richtlinie auf der Spalte VALUE, da die virtuelle Spalte weniger sensibel ist. Die virtuelle Spalte enthält eine geringere Datenmenge als die Spalte VALUE, und die Spalte VALUE enthält alle Daten für jede Zeile der externen Tabelle.

  Der Datentyp in der Richtlinie, die die virtuelle Spalte schützt, hängt vom Datentyp der virtuellen Spalte ab.

Bezüglich der bedingten Spalten in einer Maskierungsrichtlinie kann eine virtuelle Spalte als bedingtes Spaltenargument angegeben werden, um zu bestimmen, ob das erste Spaltenargument maskiert oder tokenisiert werden soll. Eine virtuelle Spalte kann jedoch nicht als erste zu maskierende oder tokenisierende Spalte angegeben werden.

Weitere Informationen dazu finden Sie unter CREATE MASKING POLICY.

Streams¶

Maskierungsrichtlinien auf Spalten einer Tabelle werden auf einen Stream derselben Tabelle übertragen.

Im Ergebnis werden nicht autorisierten Benutzern maskierte Daten angezeigt werden. Die Daten in von autorisierten Benutzern erstellten Streams werden gemäß der Maskierungsrichtlinie angezeigt.

Geklonte Objekte¶

Der folgende Ansatz hilft, Daten vor Benutzern mit SELECT-Berechtigung für die Tabelle oder Ansicht zu schützen, wenn diese auf ein geklontes Objekt zugreifen:

• Das Klonen eines einzelnen Richtlinienobjekts wird nicht unterstützt.

• Das Klonen eines Schemas führt zum Klonen aller Richtlinien innerhalb des Schemas.

• Einer geklonten Tabelle sind dieselben Richtlinien zugeordnet wie der Quelltabelle. Das heißt, wenn eine Richtlinie für die Basistabelle oder deren Spalten festgelegt ist, wird die Richtlinie an die geklonte Tabelle oder deren Spalten angehängt.

  • Wenn eine Tabelle im Kontext des Klonens ihres übergeordneten Schemas geklont wird und die Quelltabelle einen Verweis auf eine Richtlinie im selben übergeordneten Schema enthält (d. h. eine lokale Referenz), dann enthält auch die geklonte Tabelle einen Verweis auf die geklonte Richtlinie.

  • Wenn die Quelltabelle auf eine Richtlinie in einem anderen Schema verweist (d. h. eine Fremdreferenz), dann behält die geklonte Tabelle die Fremdreferenz bei.

Weitere Informationen dazu finden Sie unter CREATE <Objekt> … CLONE.

CREATE TABLE … AS SELECT (CTAS)-Anweisungen¶

Durch Ausführen einer CREATE TABLE … AS SELECT (CTAS)-Anweisung werden alle Maskierungsrichtlinien auf Spalten angewendet, die in der Anweisung enthalten sind, bevor die Daten in die neue Tabelle eingetragen werden (d. h. die entsprechenden Spaltendaten sind in der neuen Tabelle maskiert). Dieser Ablauf wird eingehalten, da eine mit einer CTAS-Anweisung erstellte Tabelle möglicherweise andere Spalten als die Quellobjekte enthält und Snowflake Maskierungsrichtlinien nicht implizit auf die neuen Tabellenspalten anwenden kann.

Wenn Sie nicht maskierte Daten kopieren müssen, verwenden Sie zur Ausführung der CTAS-Anweisung eine für geschützte Daten autorisierte Rolle. Übertragen Sie nach dem Erstellen der neuen Tabelle die Eigentümerschaft an der neuen Tabelle auf eine andere Rolle, und bitten Sie den Administrator der Maskierungsrichtlinie, die Maskierungsrichtlinien auf die Spalten der neuen Tabelle anzuwenden.

Weitere Informationen dazu finden Sie unter CREATE TABLE.

Abfragen mit Aggregatfunktionen und maskierten Spalten¶

Es ist möglich, Aggregatfunktionen auf Spalten mit maskierten Daten zu verwenden.

Ein typischer Anwendungsfall betrifft die Analyse eines Datenanalysten, bei der COUNT für eine Spalte mit Sozialversicherungsnummern angefordert wird, ohne dass die eigentlichen Daten angezeigt werden. Wenn der Datenanalyst jedoch eine Abfrage mit SELECT für eine maskierte Tabellenspalte ausführt, gibt die Abfrage einen festen maskierten Wert zurück. Benutzern mit der kundenspezifischen Rolle PAYROLL in der aktuellen Sitzung werden die nicht maskierten Daten angezeigt, während allen anderen Benutzern maskierte Daten angezeigt werden.

So erzielen Sie dieses Ergebnis:

1. Der Tabelleneigentümer erstellt eine Ansicht für die Spalte, die die Aggregatfunktion enthält.

   CREATE VIEW ssn_count AS SELECT DISTINCT(ssn) FROM table1;
   

   Copy

2. Der Rolle ANALYST werden umfassende Berechtigungen für die Ansicht erteilt. Erteilen Sie dem Datenanalysten keine Berechtigungen für die Tabelle.

3. Wenden Sie eine Maskierungsrichtlinie auf die Tabellenspalte an. Beachten Sie, dass die Tabellenrichtlinie immer vor der Ansichtsrichtlinie angewendet wird, wenn auf einer Ansichtsspalte eine Richtlinie vorliegt.

   CASE
     WHEN CURRENT_ROLE() IN ('PAYROLL') THEN val
     ELSE '***MASKED***'
   END;
   

   Copy

4. Führen Sie eine Abfrage auf der Ansichtsspalte aus.

   USE ROLE analyst;
   SELECT COUNT(DISTINCT ssn) FROM v1;
   

   Copy

Benutzerdefinierte Funktionen in einer Maskierungsrichtlinie¶

Eine UDF kann an die Bedingungen für die Maskierungsrichtlinie übergegeben werden.

Es ist wichtig, dass der Datentyp der Tabellen- oder Ansichtspalte, der UDF und der Maskierungsrichtlinie übereinstimmen. Wenn die Datentypen unterschiedlich sind, wenn z. B. eine Tabellenspalte und die UDF den Datentyp VARIANT aufweisen und die Maskierungsrichtlinie (mit dieser UDF in den Richtlinienbedingungen) den Datentyp VARCHAR zurückgibt, gibt Snowflake bei einer Abfrage auf der Tabellenspalte, für die diese Maskierungsrichtlinie gesetzt ist, einen Fehler zurück.

Ein repräsentatives Beispiel für den Abgleich der Datentypen einer Tabellenspalte, einer UDF und einer Maskierungsrichtlinie finden Sie im Beispiel Verwendung von JavaScript-UDFs auf JSON (Variant) unter CREATE MASKING POLICY.

Datenfreigabe¶

Verwendung:

• Wenn der Anbieter einer freigegebenen Tabelle oder Ansicht eine Richtlinie zuweist und die Richtlinienbedingungen die Funktion CURRENT_ROLE oder CURRENT_USER aufrufen oder die Richtlinienbedingungen eine sichere UDF aufrufen, gibt Snowflake einen NULL-Wert für die Funktion oder die UDF im Verbraucherkonto zurück.

  Der Grund dafür ist, dass der Eigentümer der freigegebenen Daten in der Regel nicht die Kontrolle über die Benutzer oder Rollen in dem Konto hat, für das die Tabelle oder Ansicht freigegeben ist. Als Problemumgehung können Sie in den Richtlinienbedingungen die Funktion CURRENT_ACCOUNT verwenden.

  Alternativ können Sie als Anbieter die Richtlinienbedingungen schreiben, um die Funktion IS_DATABASE_ROLE_IN_SESSION aufzurufen und die Datenbankrolle freizugeben. Weisen Sie als Verbraucher einer Kontorolle die Datenbankrolle der freigegebenen Datenbank zu. Weitere Details dazu finden Sie unter Freigeben von Daten, die durch eine Richtlinie geschützt sind.

Einschränkungen:

• Ein Data Sharing-Anbieter kann keine Richtlinie in einem Leserkonto erstellen.

• Data Sharing-Verbraucher können keine Richtlinie auf freigegebene Tabellen oder Ansichten anwenden. Als Problemumgehung können Sie die freigegebene Datenbank importieren und eine lokale Ansicht aus der freigegebenen Tabelle oder Ansicht erstellen.

• Data Sharing-Verbraucher können freigegebene Tabellen oder Ansichten, die zwei verschiedene Anbieter referenzieren, nicht abfragen. Beispiel:

  • rap1 ist eine Zeilenzugriffsrichtlinie, die die Tabelle mit dem Namen t1 schützt, wobei sich t1 in der Freigabe mit dem Namen share1 eines Anbieters befindet.

  • Die Richtlinienbedingungen von rap1 referenzieren eine Zuordnungstabelle namens t2, wobei sich t2 in Freigabe share2 eines anderen Anbieters befindet.

  • Die Abfrage des Verbrauchers auf t1 schlägt fehl.

  • Der Anbieter von t1 dagegen kann t1 abfragen.

• Externe Funktionen:

  Snowflake gibt in folgenden Fällen einen Fehler zurück:

  • Die einer freigegebenen Tabelle oder Ansicht zugewiesene Richtlinie wird aktualisiert, um eine externe Funktion aufzurufen.

  • Die Richtlinie ruft eine externe Funktion auf, und Sie versuchen, die Richtlinie einer freigegebenen Tabelle oder Ansicht zuzuweisen.

Replikation¶

Maskierungsrichtlinien und deren Zuweisungen können mithilfe von Datenbankreplikation und Replikationsgruppen repliziert werden.

Bei der Datenbankreplikation kann die Replikationsoperation fehlschlagen, wenn eine der folgenden Bedingungen erfüllt ist:

• Die Primärdatenbank befindet sich in einem Enterprise-Konto (oder höher) und enthält eine Richtlinie, aber mindestens eines der zur Replikation genehmigten Konten befindet sich in einer niedrigeren Edition.

• Eine in der Primärdatenbank enthaltene Tabelle oder Ansicht hat eine verwaiste Referenz auf eine Maskierungsrichtlinie in einer anderen Datenbank.

Das Verhalten von verwaisten Referenzen bei der Datenbankreplikation kann umgangen werden, wenn mehrere Datenbanken in einer Replikationsgruppe repliziert werden.

Bemerkung

Bei Verwendung von Failover- oder Failback-Aktionen muss das Snowflake-Konto Business Critical Edition oder höher sein.

Weitere Informationen dazu finden Sie unter Einführung in Replikation und Failover über mehrere Konten.

Query Profile¶

Bei Verwendung in einer Spalte mit einer Maskierungsrichtlinie enthält die EXPLAIN-Befehlsausgabe die maskierten Daten und nicht den Maskierungsrichtlinientext.

Im folgenden Beispiel wird der EXPLAIN-Plan für eine Abfrage in einer Tabelle mit Mitarbeiteridentifikationsnummern und Sozialversicherungsnummern generiert. Der Befehl in diesem Beispiel generiert das Beispiel im JSON-Format.

Die Spalte mit den Sozialversicherungsnummern enthält eine Maskierungsrichtlinie.

EXPLAIN USING JSON SELECT * FROM mydb.public.ssn_record;

{
  "GlobalStats": {
    "partitionsTotal": 0,
    "partitionsAssigned": 0,
    "bytesAssigned": 0
  },
  "Operations": [
    [
      {
        "id": 0,
        "operation": "Result",
        "expressions": [
          "1",
          "'**MASKED**'"
        ]
      },
      {
        "id": 1,
        "parent": 0,
        "operation": "Generator",
        "expressions": [
          "1"
        ]
      }
    ]
  ]
}

Daten entladen¶

Die Verwendung des Befehls COPY INTO <Speicherort> für eine Spalte, für die eine Maskierungsrichtlinie gilt, führt dazu, dass die Maskierungsrichtlinie auf die Daten angewendet wird. Daher werden nicht autorisierten Benutzern nach Ausführung des Befehls die Daten in maskierter Form angezeigt.

Snowflake Native App Framework¶

Weitere Informationen zur Verwendung von Maskierungsrichtlinien mit einer Snowflake Native App finden Sie unter:

• Einschränkungen für die Freigabe von Dateninhalten, die Richtlinien enthalten.

• Richtlinien für Proxy-Ansichten definieren.

• Blockierte Kontextfunktionen.

Auswahl eines zentralen, hybriden oder dezentralen Ansatzes¶

Um Richtlinien für die dynamische Datenmaskierung und die externe Tokenisierung effektiv zu verwalten, muss vorab bestimmt werden, ob das Maskieren von Daten in Spalten einem zentralen Sicherheitsansatz, einem dezentralen Ansatz oder einer Mischung aus beiden Ansätzen folgen soll.

Die folgende Tabelle fasst einige der Überlegungen zu jedem dieser beiden Ansätze zusammen.

Als bewährte Methode empfiehlt Snowflake, dass Ihre Organisation alle relevanten Interessensvertreter zusammenbringt, um den besten Managementansatz für die Implementierung der Sicherheit auf Spaltenebene in Ihrer Umgebung zu ermitteln.

Berechtigungen für Maskierungsrichtlinien¶

In diesem Abschnitt werden die Berechtigungen für Maskierungsrichtlinien für Sicherheit auf Spaltenebene sowie deren Anwendung bei einem zentralisierten, dezentralisierten oder hybriden Verwaltungsansatz beschrieben.

Snowflake bietet die folgenden Berechtigungen für Maskierungsrichtlinien für Sicherheit auf Spaltenebene.

Beachten Sie, dass für die Bearbeitung eines Objekts in einem Schema auch die Berechtigung USAGE für die übergeordnete Datenbank und das Schema erforderlich ist.

In den folgenden Beispielen wird gezeigt, wie das Erteilen von Berechtigungen für die verschiedenen Verwaltungsansätze erfolgt. Nachdem einer Rolle die APPLY-Berechtigung erteilt wurde, kann die Maskierungsrichtlinie mit einer ALTER TABLE … ALTER COLUMN-Anweisung für eine Tabellenspalte oder mithilfe einer ALTER VIEW-Anweisung für eine Ansichtsspalte festgelegt werden (von einem Mitglied der Rolle mit der APPLY-Berechtigung für die Maskierungsrichtlinie).

Zentrale Verwaltung

Bei einem zentralisierten Verwaltungsansatz erstellt nur die kundenspezifische Rolle des Sicherheitsbeauftragten (z. B. security_officer) Maskierungsrichtlinien und wendet diese auf Spalten in Tabellen oder Ansichten an. Dieser Ansatz bietet die größtmögliche Konsistenz hinsichtlich der Verwaltung der Maskierungsrichtlinien und der Maskierung vertraulicher Daten.

-- create a security_officer custom role

USE ROLE ACCOUNTADMIN;
CREATE ROLE security_officer;

-- grant CREATE AND APPLY masking policy privileges to the SECURITY_OFFICER custom role.

GRANT CREATE MASKING POLICY ON SCHEMA mydb.mysch TO ROLE security_officer;

GRANT APPLY MASKING POLICY ON ACCOUNT TO ROLE security_officer;

Copy

Wobei:

• schema_name

  Gibt den Bezeichner für das Schema an. Dieser muss für die Datenbank, in der das Schema erstellt wird, eindeutig sein.

  Darüber hinaus muss der Bezeichner mit einem alphabetischen Zeichen beginnen und darf keine Leer- oder Sonderzeichen enthalten, es sei denn, die gesamte Bezeichnerzeichenfolge wird in doppelte Anführungszeichen gesetzt (z. B. „Mein Objekt“). Bei Bezeichnern, die in doppelte Anführungszeichen eingeschlossen sind, ist auch die Groß-/Kleinschreibung zu beachten.

  Weitere Details dazu finden Sie unter Anforderungen an Bezeichner.

Hybride Verwaltung

Bei einem hybriden Verwaltungsansatz erstellt die kundenspezifische Rolle des Sicherheitsbeauftragten (z. B. security_officer) Maskierungsrichtlinien, und einzelne Abteilungen (z. B. Finanzen, Gehaltsabrechnung, Personal) wenden die Maskierungsrichtlinien auf Spalten in Tabellen oder Ansichten an, deren Eigentümer die jeweiligen Abteilungen sind. Dieser Ansatz kann zu einer konsistenten Erstellung und Pflege von Richtlinien führen, erfordert jedoch, dass die einzelnen Abteilungen eine höhere Verantwortung für die Maskierung sensibler Daten tragen.

USE ROLE ACCOUNTADMIN;
CREATE ROLE security_officer;
GRANT CREATE MASKING POLICY ON SCHEMA mydb.mysch TO ROLE security_officer;

Copy

Die kundenspezifische Rolle SECURITY_OFFICER erteilt der Personalabteilung (d. h. Benutzern mit der kundenspezifischen Rolle HUMAN_RESOURCES) die APPLY-Berechtigung, um Sozialversicherungsnummern (z. B. Maskierungsrichtlinie ssn_mask) in Spalten für Objekte zu maskieren, die Eigentum der kundenspezifischen Rolle HUMAN_RESOURCES sind.

USE ROLE security_officer;
GRANT APPLY ON MASKING POLICY ssn_mask TO ROLE human_resources;

Copy

Wobei:

• grant apply on masking policy policy_name to role role_name;

  Wird von einem Richtlinieneigentümer verwendet, um die Aktivierungs-/Deaktivierungsoperation einer Maskierungsrichtlinie auf bestimmten Spalten für die entsprechenden Objekteigentümer zu dezentralisieren.

  Diese Berechtigung unterstützt die diskretionäre Zugriffssteuerung, bei der Objektbesitzer auch als Datenverwalter gelten.

Dezentrale Verwaltung

Bei einem dezentralen Verwaltungsansatz erstellen einzelne Abteilungen Maskierungsrichtlinien und wenden diese auf Spalten in Tabellen oder Ansichten an. Dieser Ansatz kann zu einer inkonsistenten Richtlinienverwaltung führen, mit der Gefahr, dass vertrauliche Daten nicht ordnungsgemäß maskiert werden, da die gesamte Verantwortung für die Verwaltung von Maskierungsrichtlinien und die Maskierung vertraulicher Daten von den einzelnen Abteilungen getragen werden muss.

In diesem repräsentativen Beispiel können die Supportabteilung (d. h. Benutzer mit der kundenspezifischen Rolle SUPPORT) und die Finanzabteilung (d. h. Benutzer mit der kundenspezifischen Rolle FINANCE) Maskierungsrichtlinien erstellen. Beachten Sie, dass diese kundenspezifischen Rollen möglicherweise nicht die kundenspezifische Rolle SECURITY_OFFICER enthalten.

USE ROLE ACCOUNTADMIN;
GRANT CREATE MASKING POLICY ON SCHEMA mydb.mysch TO ROLE support;
GRANT CREATE MASKING POLICY ON SCHEMA <DB_NAME.SCHEMA_NAME> TO ROLE FINANCE;

Copy

Die Supportabteilung erteilt der Personalabteilung (d. h. Benutzern mit der kundenspezifischen Rolle HUMAN_RESOURCES) die APPLY-Berechtigung, um Sozialversicherungsnummern (z. B. Maskierungsrichtlinie ssn_mask) in Spalten für Objekte zu maskieren, die Eigentum der kundenspezifischen Rolle HUMAN_RESOURCES sind.

USE ROLE support;
GRANT APPLY ON MASKING POLICY ssn_mask TO ROLE human_resources;

Copy

Die Finanzabteilung erteilt der internen Revision (d. h. Benutzern mit der kundenspezifischen Rolle AUDIT_INTERNAL) die APPLY-Berechtigung, um Cashflow-Daten (z. B. Maskierungsrichtlinie cash_flow_mask) in Spalten zu maskieren, die Eigentum der kundenspezifischen Rolle AUDIT_INTERNAL sind.

USE ROLE finance;
GRANT APPLY ON MASKING POLICY cash_flow_mask TO ROLE audit_internal;

Copy

Weitere Informationen zu Berechtigungen für Maskierungsrichtlinien finden Sie unter:

• Verwenden der dynamischen Datenmaskierung

• Verwenden der externen Tokenisierung

DDL für Maskierungsrichtlinien¶

Snowflake bietet die folgenden Befehle zum Verwalten von Maskierungsrichtlinien für Sicherheit auf Spaltenebene.

• CREATE MASKING POLICY

• ALTER MASKING POLICY (siehe auch ALTER TABLE, ALTER TABLE … ALTER COLUMN und ALTER VIEW)

• DROP MASKING POLICY

• SHOW MASKING POLICIES

• DESCRIBE MASKING POLICY

In der folgenden Tabelle wird die Beziehung zwischen den DDL-Operationen für Maskierungsrichtlinien für Sicherheit auf Spaltenebene und den dafür erforderlichen Berechtigungen zusammengefasst.

Beachten Sie, dass für die Bearbeitung eines Objekts in einem Schema auch die Berechtigung USAGE für die übergeordnete Datenbank und das Schema erforderlich ist.

Maskierungsrichtlinien ermitteln¶

Sie können die Ansicht MASKING_POLICIES im Account Usage-Schema der freigegebenen SNOWFLAKE-Datenbank verwenden. Diese Ansicht ist ein Katalog aller Maskierungsrichtlinien in Ihrem Snowflake-Konto. Beispiel:

SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.MASKING_POLICIES
ORDER BY POLICY_NAME;

Copy

Zuweisungen identifizieren¶

Snowflake unterstützt verschiedene Optionen zum Identifizieren von Zuweisungen von Maskierungsrichtlinien, je nachdem, ob die Abfrage auf das Konto oder eine bestimmte Datenbank abzielen soll.

• Abfrage auf Kontoebene:

  Verwenden Sie die Account Usage-Ansicht POLICY_REFERENCES, um alle Spalten zu ermitteln, die über eine Maskierungsrichtlinie verfügen. Beispiel:

  SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.POLICY_REFERENCES
  ORDER BY POLICY_NAME, REF_COLUMN_NAME;
  

  Copy

• Abfrage auf Datenbankebene:

  Jede Snowflake-Datenbank enthält ein Snowflake Information Schema. Verwenden Sie die Information Schema-Tabellenfunktion POLICY_REFERENCES, um alle Maskierungsrichtlinien auf Spalten einer bestimmten Tabelle zu ermitteln:

  SELECT *
  FROM TABLE(
    my_db.INFORMATION_SCHEMA.POLICY_REFERENCES(
      'my_table',
      'table'
    )
  );
  

  Copy

  Sie können mit dieser Funktion auch den Namen der Maskierungsrichtlinie abfragen, um die Objekte zu finden, die mit einer bestimmten Maskierungsrichtlinie verknüpft sind.

Zugriff auf den Governance-Bereich in Snowsight¶

Für den Zugriff auf den Bereich Governance muss Ihr Snowflake-Konto die Enterprise Edition oder höher verwenden. Außerdem müssen Sie einen der folgenden Punkte erfüllen:

• Sie verwenden die Rolle ACCOUNTADMIN.

• Sie verwenden eine Kontorolle, der die Datenbankrollen GOVERNANCE_VIEWER und OBJECT_VIEWER direkt zugewiesen sind.

  Sie müssen eine Kontorolle mit diesen Datenbankrollenzuweisungen verwenden. Derzeit wertet Snowsight keine Rollenhierarchien und benutzerdefinierten Datenbankrollen aus, die Zugriff auf Tabellen, Ansichten, Datenzugriffsrichtlinien und Tags haben.

  Um festzustellen, ob Ihre Kontorolle über diese Datenbankrollen verfügt, verwenden Sie den Befehl SHOW GRANTS:

  SHOW GRANTS LIKE '%VIEWER%' TO ROLE data_engineer;
  

  Copy

  |-------------------------------+-----------+---------------+-----------------------------+------------+-----------------+--------------+------------|
  | created_on                    | privilege | granted_on    | name                        | granted_to | grantee_name    | grant_option | granted_by |
  |-------------------------------+-----------+---------------+-----------------------------+------------+-----------------+--------------+------------|
  | 2024-01-24 17:12:26.984 +0000 | USAGE     | DATABASE_ROLE | SNOWFLAKE.GOVERNANCE_VIEWER | ROLE       | DATA_ENGINEER   | false        |            |
  | 2024-01-24 17:12:47.967 +0000 | USAGE     | DATABASE_ROLE | SNOWFLAKE.OBJECT_VIEWER     | ROLE       | DATA_ENGINEER   | false        |            |
  |-------------------------------+-----------+---------------+-----------------------------+------------+-----------------+--------------+------------|
  

  
  

  Wenn Ihrer Kontorolle keine dieser beiden Datenbankrollen zugewiesen ist, verwenden Sie den Befehl GRANT DATABASE ROLE, und führen Sie den Befehl SHOW GRANTS erneut aus, um die Berechtigungszuweisungen zu bestätigen:

  USE ROLE ACCOUNTADMIN;
  GRANT DATABASE ROLE SNOWFLAKE.GOVERNANCE_VIEWER TO ROLE data_engineer;
  GRANT DATABASE ROLE SNOWFLAKE.OBJECT_VIEWER TO ROLE data_engineer;
  SHOW GRANTS LIKE '%VIEWER%' TO ROLE data_engineer;
  

  Copy

  Weitere Informationen zu diesen Datenbankrollen finden Sie unter SNOWFLAKE-Datenbankrollen.

Dashboard¶

Als Datenadministrator können Sie die Dashboard-Schnittstelle verwenden, um die Nutzung von Tags und Richtlinien auf folgende Weise zu überwachen.

• Coverage (Abdeckung): Gibt die Anzahl und den Prozentsatz an, je nachdem, ob eine Tabelle, Ansicht oder Spalte eine Richtlinie oder ein Tag hat.

• Prevalence (Verbreitung): Listet die am häufigsten genutzten Richtlinien und Tags auf und zählt sie.

Die Abdeckung und die Verbreitung liefern eine Momentaufnahme darüber, wie gut die Daten geschützt und getaggt sind.

Wenn Sie eine Zählernummer, einen Prozentsatz, einen Richtliniennamen oder einen Tag-Namen auswählen, wird die Tagged Objects-Schnittstelle geöffnet. Die Tagged Objects-Schnittstelle aktualisiert die Filter automatisch auf der Grundlage Ihrer Auswahl im Feld Dashboard.

Die Überwachungsinformationen sind eine Alternative oder Ergänzung zur Ausführung komplexer und abfrageintensiver Operationen auf mehreren Account Usage-Ansichten.

Zu diesen Ansichten können unter anderem die Ansichten COLUMNS, POLICY_REFERENCES, TABLES, TAG_REFERENCES und VIEWS zählen.

Getaggte Objekte¶

Als Datenadministrator können Sie diese Tabelle verwenden, um den Abdeckung und die Verbreitung im Dashboard schnell mit einer Liste bestimmter Tabellen, Ansichten oder Spalten zu verknüpfen. Sie können die Tabellenergebnisse auch wie folgt manuell filtern.

• Wählen Sie Tables oder Columns aus.

• Bei Tags können Sie mit Tags, ohne Tags oder nach einem bestimmten Tag filtern.

• Bei Richtlinien können Sie mit Richtlinien, ohne Richtlinien oder nach einer bestimmten Richtlinie filtern.

Wenn Sie eine Zeile in der Tabelle auswählen, wird in Data » Databases die Registerkarte Table Details oder Columns geöffnet. Sie können die Tag- und Richtlinienzuweisungen nach Bedarf bearbeiten.

Weitere Informationen dazu finden Sie unter Tags und Richtlinien untersuchen