Tag-basierte Maskierungsrichtlinien¶

Berechtigung¶

Je nachdem, ob Sie die Tag-basierte Maskierungsrichtlinie für eine Datenbank, ein Schema oder eine Tabelle festlegen, gelten unterschiedliche Berechtigungsanforderungen.

Bei der Tag-basierten Maskierung einer Datenbank oder eines Schemas muss die aktuelle Rolle oder eine Rolle in der aktuellen Rollenhierarchie die Berechtigungen gemäß einer der beiden folgenden Optionen erben.

Option 1

Die Rolle muss die beiden globalen Berechtigungen APPLY MASKING POLICY und APPLY TAG haben. Weisen Sie beispielsweise der kundenspezifischen Rolle data_engineer die folgenden globalen Berechtigungen zu:

USE ROLE ACCOUNTADMIN;

GRANT APPLY MASKING POLICY ON ACCOUNT TO ROLE data_engineer;

GRANT APPLY TAG ON ACCOUNT TO ROLE data_engineer;

Copy

Dies ist der zentrale Ansatz zum Schutz von Spalten mit einer Tag-basierten Maskierungsrichtlinie in einem Schema oder einer Datenbank.

Option 2

Ein Schemaeigentümer (d. h. eine Rolle mit der Berechtigung OWNERSHIP für das Schema) kann die globale Berechtigung APPLY MASKING POLICY und die Berechtigung APPLY für das Tag haben. Wenn das Tag beispielsweise governance.tags.schema_mask heißt und die kundenspezifische Rolle, die Eigentümer des Schemas ist, schema_owner ist:

USE ROLE ACCOUNTADMIN;

GRANT APPLY MASKING POLICY ON ACCOUNT TO ROLE schema_owner;

GRANT APPLY ON TAG governance.tags.schema_mask TO ROLE schema_owner;

Copy

Dieser Ansatz bietet mehr Flexibilität, da der Spaltenschutz an die Schemaeigentümer delegiert wird.

Bei der Tag-basierten Maskierung von Tabellen und Ansichten kann eine Rolle mit der globalen Berechtigung APPLY MASKING POLICY Maskierungsrichtlinien für Tags zuweisen und ersetzen.

Weisen Sie beispielsweise der kundenspezifischen Rolle tag_admin die globale Berechtigung APPLY MASKING POLICY zu:

USE ROLE SECURITYADMIN;

GRANT APPLY MASKING POLICY ON ACCOUNT TO ROLE tag_admin;

Copy

Maskierungsrichtlinie einem Tag zuweisen¶

Das Zuweisen einer Tag-basierten Maskierungsrichtlinie für ein Schema oder eine Datenbank erfolgt nach demselben Verfahren wie das Festlegen einer Tag-basierten Maskierungsrichtlinie für eine Tabelle:

1. Erstellen Sie ein Tag mit dem Befehl CREATE TAG.

2. Erstellen Sie eine Maskierungsrichtlinie mit dem Befehl CREATE MASKING POLICY.

   Sie können optional die Systemfunktionen SYSTEM$GET_TAG_ON_CURRENT_COLUMN und SYSTEM$GET_TAG_ON_CURRENT_TABLE in den Bedingungen der Maskierungsrichtlinie verwenden.

3. Legen Sie die Maskierungsrichtlinie für das Tag mit dem Befehl ALTER TAG fest.

4. Legen Sie das Tag für das Objekt mit einem der folgenden Befehle so fest, wie Sie Ihre Daten schützen möchten:

   • ALTER DATABASE

   • ALTER SCHEMA

   • ALTER TABLE

Zusätzlich zu den Nutzungshinweisen für ALTER TAG ist Folgendes zu beachten:

• Ein Tag kann nur eine Maskierungsrichtlinie pro Datentyp haben. Zum Beispiel eine Richtlinie für den Datentyp STRING, eine Richtlinie für den Datentyp NUMBER usw.

• Wenn eine Spalte bereits durch eine Maskierungsrichtlinie geschützt ist und ein Tag mit einer Maskierungsrichtlinie derselben Spalte zugeordnet wird, hat die der Spalte direkt zugewiesene Maskierungsrichtlinie Vorrang vor der dem Tag zugewiesenen Maskierungsrichtlinie.

• Ein Tag kann nicht gelöscht werden, wenn es einer Maskierungsrichtlinie zugewiesen ist.

• Eine Maskierungsrichtlinie kann nicht gelöscht werden, wenn sie einem Tag zugewiesen ist.

Weitere Informationen zum Verwalten von Maskierungsrichtlinien und Tags finden Sie unter:

• Verwalten der Sicherheit auf Spaltenebene

• Tags verwalten

Maskierungsrichtlinie auf einem Tag ersetzen¶

Nach dem Festlegen einer Maskierungsrichtlinie für ein Tag gibt es zwei Möglichkeiten, die Maskierungsrichtlinie für das Tag durch eine andere Maskierungsrichtlinie zu ersetzen. Die Anweisung ALTER TAG muss den Namen der Maskierungsrichtlinie angeben, wie in den folgenden Optionen gezeigt.

Option 1

Heben Sie mit einer Anweisung die Richtlinie für ein Tag auf, und legen Sie dann mit einer anderen Anweisung eine neue Richtlinie für das Tag fest:

ALTER TAG security UNSET MASKING POLICY ssn_mask;

ALTER TAG security SET MASKING POLICY ssn_mask_2;

Copy

Option 2

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

Wenn für das Tag bereits eine Richtlinie desselben Datentyps festgelegt ist, müssen Sie beachten, dass bei Verwendung des Schlüsselworts FORCE die Richtlinie ersetzt wird.

ALTER TAG security SET MASKING POLICY ssn_mask_2 FORCE;

Copy

Die Option, die Sie im Abschnitt Berechtigung auswählen, und die Reihenfolge der Operationen im Abschnitt Maskierungsrichtlinie einem Tag zuweisen können sich auf die Tag-Verwaltung auswirken, wenn Sie ein Tag in einer Datenbank oder einem Schema ersetzen oder zurücksetzen müssen.

Wenn ein Schemaeigentümer ein Tag auf ein Schema setzt und dann eine andere Rolle eine Maskierungsrichtlinie auf dasselbe Tag setzt, kann der Schemaeigentümer das Tag nur dann aus dem Schema entfernen, wenn er die globale Berechtigung APPLY MASKING POLICY hat. Snowflake sorgt dafür, dass die Operation ALTER SCHEMA… UNSET TAG für den Schemaeigentümer fehlschlägt. Dieses Szenario stellt sicher, dass die Daten einer Spalte, die durch eine Tag-basierte Maskierungsrichtlinie geschützt ist, auch geschützt bleiben. Um dieses Szenario zu vermeiden, verwenden Sie Option 1 aus Abschnitt Berechtigung.

Wichtig

Seien Sie vorsichtig, wenn Sie die Maskierungsrichtlinie auf einem Tag ersetzen.

Je nach Zeitpunkt der Ersetzung und der Abfrage der Spalte könnte die Ersetzung der Richtlinie in zwei getrennten Anweisungen zu einem Datenleck führen, da die Spaltendaten in dem Zeitraum zwischen den Operationen UNSET und SET ungeschützt sind.

Wenn jedoch die Richtlinienbedingungen in der Ersetzungsrichtlinie anders lauten, könnte die Angabe des Schlüsselworts FORCE zu einem fehlenden Zugang für den Fall führen, dass die Benutzer (zuvor) auf die Daten zugreifen konnten, die neue Richtlinie dies aber unterbindet.

Bevor Sie eine Richtlinie ersetzen, sollten Sie sich mit Ihren internen Datenadministratoren beraten, um den besten Ansatz für den Schutz von Daten mit Tag-basierten Maskierungsrichtlinien zu koordinieren und Maskierungsrichtlinien nach Bedarf zu ersetzen.

Tag-Wert aktualisieren¶

Wenn ein Schemaeigentümer (d. h. sch_role) ein Tag auf ein Schema setzt und dann eine andere Rolle eine Maskierungsrichtlinie auf dasselbe Tag setzt (d. h. masking_admin_role), kann der Schemaeigentümer den Tag-Wert nicht ändern. Snowflake sorgt dafür, dass die Operation ALTER SCHEMA … SET TAG für den Schemaeigentümer fehlschlägt.

So ändern Sie den Tag-Wert:

1. Verwenden Sie die Rolle masking_admin_role, um die Maskierungsrichtlinie für das Tag zu deaktivieren.

2. Verwenden Sie die Rolle sch_role, um den Tag-Wert zu ändern.

3. Verwenden Sie die Rolle masking_admin_role, um dem Tag die Maskierungsrichtlinie neu zuzuweisen.

Übergeordnete Datenbanken und Schemas¶

Sie können DROP- und REPLACE-Operationen in folgenden Fällen nicht auf Datenbank und Schema ausführen:

• Das Tag und die Maskierungsrichtlinie befinden sich in demselben Schema.

• Die Tabelle oder die Ansicht befindet sich in einem anderen Schema.

• Die geschützte Spalte der Tabelle oder Ansicht befindet sich nicht in dem Schema, das die Maskierungsrichtlinie und das Tag enthält.

Diese vier Befehle beziehen sich auf DROP und ersetzen folgende Operationen auf Datenbank und Schema:

• DROP DATABASE

• DROP SCHEMA

• CREATE OR REPLACE DATABASE

• CREATE OR REPLACE SCHEMA

Bedingte Argumente¶

Einem Tag kann eine bedingte Maskierungsrichtlinie zugewiesen werden. Nach dem Zuweisen des Tags zu einer Spalte werden die bedingten Argumente einer Spalte in der Tabelle namentlich zugeordnet, vorausgesetzt, der Datentyp des Arguments stimmt mit dem Datentyp der Spalte überein.

Eine Abfrage schlägt fehl, wenn einer Spalte in den folgenden Fällen eine bedingte Maskierungsrichtlinie zugewiesen ist:

• In der Tabelle gibt es keine Spalte, die denselben Namen hat wie ein bedingtes Argument der Richtlinie.

• Die Tabelle hat eine Spalte, die mit dem Namen des bedingten Arguments der Richtlinie übereinstimmt, aber der Datentyp stimmt nicht überein.

Weitere Informationen zu diesen Fehlern finden Sie unter Problembehandlung bei Tag-basierten Maskierungsrichtlinien (unter diesem Thema).

Tag-Herkunft¶

Das Tag mit der Maskierungsrichtlinie kann allen Objekten der Basistabelle zugewiesen werden, oder das Tag kann einer Spalte in einer Basistabelle zugewiesen werden. Wenn die Tag-basierte Maskierungsrichtlinie einer Basistabelle zugewiesen wird, sind die Spalten durch die Richtlinie geschützt, sofern der Datentyp der Spalte mit dem Datentyp in der Signatur der Maskierungsrichtlinie übereinstimmt.

Da die Maskierungsrichtlinie die Basistabellenspalten schützt, sind Ansichtsspalten, die von den zugrundeliegenden Basistabellenspalten abgeleitet sind, ebenfalls geschützt, basierend auf den aktuellen Einschränkungen, Hinweisen und Verhaltensweisen bezüglich Maskierungsrichtlinien mit Tabellen und Ansichten.

Datenfreigabe (Data Sharing)¶

Tag-basierte Maskierungsrichtlinien, die für ein freigegebenes Schema oder eine freigegebene Datenbank im Anbieterkonto festgelegt wurden, werden im Verbraucherkonto erzwungen. Dieses Szenario stellt sicher, dass geschützte Daten, die freigegeben werden, geschützt bleiben, auch wenn ein Verbraucher eine neue Datenbank aus der Freigabe erstellt.

Beachten Sie außerdem Folgendes:

• Die Tag-Herkunft bleibt im Verbraucherkonto erhalten.

  Wenn der Anbieter eine Tag-basierte Maskierungsrichtlinie für seine Datenbank festlegt und diese Datenbank freigibt, referenziert Snowflake die freigegebene Anbieterdatenbank im Verbraucherkonto auf Grundlage der Datenbank, die das Tag enthält.

• Wenn Tags und Tag-basierten Maskierungsrichtlinien aus dem Verbraucherkonto stammen, berücksichtigt Snowflake die Tag-Herkunft der freigegebenen Objekten nicht.

  Tags und Tag-basierte Maskierungsrichtlinien aus dem Verbraucherkonto werden bei den freigegebenen Objekten nicht erzwungen.

Snowsight¶

Sie können Tag-basierte Maskierungsrichtlinien in Snowsight überwachen und zuweisen. Weitere Details dazu finden Sie unter:

• Tags mit Snowsight überwachen

• Maskierungsrichtlinien mit Snowsight überwachen

Tags und Richtlinien untersuchen¶

Mithilfe der Information Schema-Tabellenfunktion POLICY_REFERENCES und der Account Usage-Ansicht POLICY_REFERENCES kann anhand der folgenden Spalten festgestellt werden, ob eine Maskierungsrichtlinie und ein Tag aufeinander verweisen:

• TAG_DATABASE

• TAG_SCHEMA

• TAG_NAME

• POLICY_STATUS

Die Spalte POLICY_STATUS kann vier mögliche Werte haben:

ACTIVE

Gibt an, dass die Spalte (d. h. REF_COLUMN_NAME) mit nur einer einzigen Richtlinie durch ein Tag verbunden ist.

MULTIPLE_MASKING_POLICY_ASSIGNED_TO_THE_COLUMN

Gibt an, dass der gleichen Spalte mehrere Maskierungsrichtlinien zugewiesen sind.

COLUMN_IS_MISSING_FOR_SECONDARY_ARG

Gibt an, dass die Richtlinie (d. h. POLICY_NAME) eine bedingte Maskierungsrichtlinie ist und die Tabelle (d. h. REF_ENTITY_NAME) keine Spalte mit demselben Namen hat.

COLUMN_DATATYPE_MISMATCH_FOR_SECONDARY_ARG

Gibt an, dass es sich bei der Richtlinie um eine bedingte Maskierungsrichtlinie handelt und die Tabelle eine Spalte mit demselben Namen, aber einem anderen Datentyp als dem Datentyp in der Signatur der Maskierungsrichtlinie hat.

Weitere Informationen zu den entsprechenden Fehlermeldungen mit den möglichen Werten in der Spalte POLICY_STATUS finden Sie unter Problembehandlung bei Tag-basierten Maskierungsrichtlinien (unter diesem Thema).

Datenschutz und Validierungsschritte¶

Im Allgemeinen empfiehlt Snowflake bei der Verwendung von Tag-basierten Maskierungsrichtlinien die folgende Vorgehensweise:

1. Erstellen Sie alle Tags, die für Tag-basierte Maskierungsrichtlinien benötigt werden.

2. Erstellen Sie eine Maskierungsrichtlinie für jeden Datentyp auf der Grundlage der Tabellenspalten, die Sie mit den Tag-basierten Maskierungsrichtlinien schützen möchten.

3. Weisen Sie die Maskierungsrichtlinien dem Tag zu.

4. Weisen Sie das Tag mit den Maskierungsrichtlinien direkt der Tabellenspalte oder der Tabelle zu.

5. Überprüfen Sie das Information Schema, um sicherzustellen, dass die Tag-basierte Richtlinie den Spalten zugewiesen ist.

6. Fragen Sie die Daten ab, um zu überprüfen, ob die Tag-basierte Maskierungsrichtlinie die Daten wie vorgesehen schützt.

Vorbereitende Schritte¶

1. Identifizieren Sie die vorhandenen Tags und deren Zeichenfolgenwerte in Ihrem Snowflake-Konto.

   • Fragen Sie die Account Usage-Ansicht TAG REFERENCES ab, um alle Tags und die ihnen zugeordneten Zeichenfolgenwerte zu erhalten.

   • Optional:

     • Fragen Sie die Account Usage-Ansicht TAGS (d. h. den Tag-Katalog) ab, um eine Liste von Tags zu erhalten und sicherzustellen, dass später bei der Verwendung von Tag-basierten Maskierungsrichtlinien keine doppelten Tag-Namen auftreten.

     • Vergleichen Sie die Ausgaben der TAG_REFERENCES- und TAGS-Abfragen, um festzustellen, ob es noch nicht zugewiesene Tags gibt, die später verwendet werden können.

     • Erstellen Sie mit dem Befehl CREATE TAG alle Tags, die später benötigt werden. Erstellen Sie ansonsten die Tags nach Bedarf.

2. Identifizieren Sie die in Ihrem Snowflake-Konto vorhandenen Richtlinien und deren Definitionen.

   • Führen Sie den Befehl SHOW MASKING POLICIES aus, um eine Liste der vorhandenen Maskierungsrichtlinien zu erhalten.

   • Entscheiden Sie, ob diese Richtlinien in ihrer derzeitigen Form Tags zugewiesen werden können. Führen Sie bei Bedarf den Befehl DESCRIBE MASKING POLICY aus, um die Richtliniendefinition zu erhalten. Andernfalls müssen Sie neue Richtlinien erstellen, die Sie den Tags zuweisen.

3. Legen Sie fest, wie die Spaltendaten mit der Maskierungsrichtlinie geschützt werden sollen, und zwar in Bezug darauf, ob die Richtlinienbedingungen den Tag-Zeichenfolgenwert auswerten sollen, der in der Tabellenspalte festgelegt ist.

Gemeinsame Annahmen mit den Beispielen¶

Die Beispiele gehen von den folgenden Annahmen aus:

• Die erforderlichen Schritte wurden abgeschlossen.

• Die kundenspezifische Rolle tag_admin hat die folgenden Berechtigungen:

  • Die Berechtigung CREATE TAG auf Schemaebene

  • Die globale Berechtigung APPLY TAG

  Weitere Informationen dazu finden Sie unter Tag-Berechtigungen.

• Die kundenspezifische Rolle masking_admin hat die folgenden Berechtigungen:

  • Die Berechtigung CREATE MASKING POLICY auf Schemaebene.

  • Die USAGE-Berechtigung für die Datenbank governance und das Schema governance.masking_policies.

  • Die globale Berechtigung APPLY MASKING POLICY für die Zuweisung von Maskierungsrichtlinien zu Tags (siehe Berechtigung unter diesem Thema).

  • Die globale Berechtigung APPLY TAG, um den Tag (mit den Maskierungsrichtlinien) zu den Objekten zuzuweisen.

  Weitere Informationen dazu finden Sie unter Tag-Berechtigungen.

• Die kundenspezifische Rolle row_access_admin hat die folgenden Berechtigungen:

  • Die Berechtigung CREATE ROW ACCESSPOLICY auf Schemaebene.

  • Die USAGE-Berechtigung für die Datenbank governance und das Schema governance.row_access_policies.

  • Die globale Berechtigung APPLY ROW ACCESS POLICY.

  Weitere Informationen dazu finden Sie unter Berechtigungen von Zeilenzugriffsrichtlinien.

• Die kundenspezifische Rolle accounting_admin hat die folgenden Berechtigungen:

  • Die USAGE-Berechtigung für die Datenbank finance und das Schema finance.accounting.

  • Die SELECT-Berechtigung für Tabellen im Schema finance.accounting.

• Die kundenspezifische Rolle analyst hat die folgenden Berechtigungen:

  • Die USAGE-Berechtigung für die Datenbank finance und das Schema finance.accounting.

  • Die SELECT-Berechtigungen für die Tabelle finance.accounting.name_number.

• Die oben beschriebenen kundenspezifischen Rollen werden den entsprechenden Benutzern zugewiesen.

  Weitere Details dazu finden Sie unter Konfigurieren der Zugriffssteuerung.

Beispiel 1: Schutz von Spaltendaten basierend auf der Maskierungsrichtlinie, die dem Tag direkt zugewiesen ist¶

In diesem Beispiel werden einem Tag zwei Maskierungsrichtlinien zugewiesen, und anschließend wird derselbe Tag einer Tabelle zugewiesen. Das Ergebnis ist, dass die Maskierungsrichtlinien alle Tabellenspalten schützen, deren Datentypen mit den Datentypen in den Richtlinien übereinstimmen.

Mit den folgenden Schritten erstellen Sie eine Tag-basierte Maskierungsrichtlinie zur Maskierung von Abrechnungsdaten. Nehmen wir zum Beispiel die Tabelle finance.accounting.name_number, die zwei Spalten ACCOUNT_NAME und ACCOUNT_NUMBER hat. Die Datentypen in diesen Spalten sind STRING bzw. NUMBER.

---------------+----------------+
  ACCOUNT_NAME | ACCOUNT_NUMBER |
---------------+----------------+
  ACME         | 1000           |
---------------+----------------+

Erstellen Sie eine Tag-basierte Maskierungsrichtlinie zum Schutz der Spalten ACCOUNT_NAME und ACCOUNT_NUMBER wie folgt:

1. Erstellen Sie ein Tag mit dem Namen accounting im Schema mit dem Namen governance.tags.

   USE ROLE tag_admin;
   USE SCHEMA governance.tags;
   CREATE OR REPLACE TAG accounting;
   

   Copy

2. Erstellen Sie verschiedene Maskierungsrichtlinien zum Schutz der Spalten ACCOUNT_NAME und ACCOUNT_NUMBER. Bei jeder dieser Richtlinien können die Rohdaten nur von der kundenspezifischen Rolle ACCOUNTING_ADMIN eingesehen werden.

   Richtlinie für Kontonamen:

   USE ROLE masking_admin;
   USE SCHEMA governance.masking_policies;
   
   CREATE OR REPLACE MASKING POLICY account_name_mask
   AS (val string) RETURNS string ->
     CASE
       WHEN CURRENT_ROLE() IN ('ACCOUNTING_ADMIN') THEN val
       ELSE '***MASKED***'
     END;
   

   Copy

   Richtlinie für Kontonummer:

   CREATE OR REPLACE MASKING POLICY account_number_mask
   AS (val number) RETURNS number ->
     CASE
       WHEN CURRENT_ROLE() IN ('ACCOUNTING_ADMIN') THEN val
       ELSE -1
     END;
   

   Copy

3. Weisen Sie dem Tag accounting beide Maskierungsrichtlinien zu. Beachten Sie, dass beide Richtlinien dem Tag in einer einzigen Anweisung zugewiesen werden können.

   ALTER TAG governance.tags.accounting SET
     MASKING POLICY account_name_mask,
     MASKING POLICY account_number_mask;
   

   Copy

4. Weisen Sie das Tag accounting der Tabelle finance.accounting.name_number zu.

   ALTER TABLE finance.accounting.name_number
     SET TAG governance.tags.accounting = 'tag-based policies';
   

   Copy

5. Vergewissern Sie sich, dass die Tabellenspalten ACCOUNT_NAME und ACCOUNT_NUMBER durch die Tag-basierte Maskierungsrichtlinie geschützt sind, indem Sie die Information Schema-Tabellenfunktion POLICY_REFERENCES aufrufen.

   Für jede geschützte Spalte muss die Zeile im Abfrageergebnis die entsprechenden Werte für den Spaltennamen, den Richtliniennamen und den Tag-Namen angeben:

   USE ROLE masking_admin;
   SELECT *
   FROM TABLE (governance.INFORMATION_SCHEMA.POLICY_REFERENCES(
     REF_ENTITY_DOMAIN => 'TABLE',
     REF_ENTITY_NAME => 'governance.accounting.name_number' )
   );
   

   Copy

   Rückgabe (beachten Sie die aktualisierten Spalten):

   -------------+------------------+---------------------+----------------+-------------------+-----------------+-----------------+-------------------+-----------------+----------------------+--------------+------------+------------+---------------+
     POLICY_DB  | POLICY_SCHEMA    | POLICY_NAME         | POLICY_KIND    | REF_DATABASE_NAME | REF_SCHEMA_NAME | REF_ENTITY_NAME | REF_ENTITY_DOMAIN | REF_COLUMN_NAME | REF_ARG_COLUMN_NAMES | TAG_DATABASE | TAG_SCHEMA | TAG_NAME   | POLICY_STATUS |
   -------------+------------------+---------------------+----------------+-------------------+-----------------+-----------------+-------------------+-----------------+----------------------+--------------+------------+------------+---------------+
     GOVERNANCE | MASKING_POLICIES | ACCOUNT_NAME_MASK   | MASKING_POLICY | FINANCE           | ACCOUNTING      | NAME_NUMBER     | TABLE             | ACCOUNT_NAME    | NULL                 | GOVERNANCE   | TAGS       | ACCOUNTING | ACTIVE        |
     GOVERNANCE | MASKING_POLICIES | ACCOUNT_NUMBER_MASK | MASKING_POLICY | FINANCE           | ACCOUNTING      | NAME_NUMBER     | TABLE             | ACCOUNT_NUMBER  | NULL                 | GOVERNANCE   | TAGS       | ACCOUNTING | ACTIVE        |
   -------------+------------------+---------------------+----------------+-------------------+-----------------+-----------------+-------------------+-----------------+----------------------+--------------+------------+------------+---------------+
   

6. Fragen Sie die Tabellenspalten mit autorisierten und nicht autorisierten Rollen ab, um sicherzustellen, dass Snowflake das korrekte Abfrageergebnis liefert.

   Autorisiert:

   USE ROLE accounting_admin;
   SELECT * FROM finance.accounting.name_number;
   

   Copy

   Rückgabewerte:

   ---------------+----------------+
     ACCOUNT_NAME | ACCOUNT_NUMBER |
   ---------------+----------------+
     ACME         | 1000           |
   ---------------+----------------+
   

   Nicht autorisiert:

   USE ROLE analyst;
   SELECT * FROM finance.accounting.name_number;
   

   Copy

   Rückgabewerte:

   ---------------+----------------+
     ACCOUNT_NAME | ACCOUNT_NUMBER |
   ---------------+----------------+
     ***MASKED*** | -1             |
   ---------------+----------------+
   

Beispiel 2: Schutz von Spaltendaten basierend auf dem Spalten-Tag-Zeichenfolgenwert¶

In diesem Beispiel wird eine Tag-basierte Maskierungsrichtlinie verwendet, um zu bestimmen, ob Daten auf der Grundlage des Tag-Zeichenfolgenwertes des einer Spalte zugewiesenen Tags maskiert werden sollen. Die Maskierungsrichtlinie wertet den Tag-Zeichenfolgenwert dynamisch aus, indem sie die Funktion SYSTEM$GET_TAG_ON_CURRENT_COLUMN in den Maskierungsrichtlinienbedingungen aufruft und die Maskierungsrichtlinienbedingungen so schreibt, dass sie mit dem Tag-Zeichenfolgenwert übereinstimmen.

Mit den folgenden Schritten erstellen Sie eine Tag-basierte Maskierungsrichtlinie zur Maskierung von Abrechnungsdaten. Der Einfachheit halber haben die Tabellenspalten zwei Datentypen, STRING bzw. NUMBER. Zum Beispiel eine Tabelle mit dem Namen finance.accounting.name_number:

---------------+----------------+
  ACCOUNT_NAME | ACCOUNT_NUMBER |
---------------+----------------+
  ACME         | 1000           |
---------------+----------------+

Erstellen Sie eine Tag-basierte Maskierungsrichtlinie zum Schutz der Spalten ACCOUNT_NAME und ACCOUNT_NUMBER wie folgt:

1. Erstellen Sie ein Tag mit dem Namen accounting_col_string im Schema mit dem Namen governance.tags.

   USE ROLE tag_admin;
   USE SCHEMA governance.tags;
   CREATE TAG accounting_col_string;
   

   Copy

2. Erstellen Sie verschiedene Maskierungsrichtlinien zum Schutz der Spalten ACCOUNT_NAME und ACCOUNT_NUMBER. In jeder dieser Richtlinien sind die Rohdaten nur sichtbar, wenn der aktuelle Tag-Zeichenfolgenwert in der Spalte auf 'visible' gesetzt ist.

   Richtlinie für Kontonamen:

   USE ROLE masking_admin;
   USE SCHEMA governance.masking_policies;
   
   CREATE MASKING POLICY account_name_mask_tag_string
   AS (val string) RETURNS string ->
     CASE
       WHEN SYSTEM$GET_TAG_ON_CURRENT_COLUMN('tags.accounting_col_string') = 'visible' THEN val
       ELSE '***MASKED***'
     END;
   

   Copy

   Richtlinie für Kontonummer:

   CREATE MASKING POLICY account_number_mask_tag_string
   AS (val number) RETURNS number ->
     CASE
       WHEN SYSTEM$GET_TAG_ON_CURRENT_COLUMN('tags.accounting_col_string') = 'visible' THEN val
       ELSE -1
     END;
   

   Copy

   Bemerkung

   Diese Richtlinien verwenden das Objektnamesformat schema_name.tag_name im Funktionsargument, weil das Schema tags und das Schema masking_policies beide in der Datenbank governance vorhanden sind. Alternativ können Sie auch den vollqualifizierten Namen für das Tag im Funktionsargument verwenden.

   Snowflake gibt zur Laufzeit der Abfrage auf einer Spalte, die durch eine Tag-basierte Maskierungsrichtlinie geschützt ist, einen Fehler zurück, wenn das Systemfunktionsargument in den Richtlinienbedingungen einen Tag-Namen enthält, der nicht ausreichend qualifiziert ist. Das Argument verwendet zum Beispiel nur den Tag-Namen als accounting_col_string (Buchhaltungsspalten_Zeichenfolge), ohne den Schemanamen oder den Datenbanknamen anzugeben.

   Weitere Informationen dazu finden Sie unter Auflösung des Objektnamens.

3. Weisen Sie dem Tag accounting_col_string beide Maskierungsrichtlinien zu. Beachten Sie, dass beide Richtlinien dem Tag in einer einzigen Anweisung zugewiesen werden können.

   ALTER TAG accounting_col_string SET
     MASKING POLICY account_name_mask_tag_string,
     MASKING POLICY account_number_mask_tag_string;
   

   Copy

4. Weisen Sie jeder Tabellenspalte das Tag accounting_col_string zu. In diesem Beispiel hat die Tag-Zeichenfolge in der Spalte ACCOUNT_NAME den Wert 'visible', der Tag-Zeichenfolgenwert in der Spalte ACCOUNT_NUMBER ist jedoch 'protect'.

   ALTER TABLE finance.accounting.name_number MODIFY COLUMN
     account_name SET TAG governance.tags.accounting_col_string = 'visible',
     account_number SET TAG governance.tags.accounting_col_string = 'protect';
   

   Copy

5. Vergewissern Sie sich, dass die Tabellenspalten ACCOUNT_NAME und ACCOUNT_NUMBER durch die Tag-basierte Maskierungsrichtlinie geschützt sind, indem Sie die Information Schema-Tabellenfunktion POLICY_REFERENCES aufrufen.

   Für jede geschützte Spalte muss die Zeile im Abfrageergebnis die entsprechenden Werte für den Spaltennamen, den Richtliniennamen und den Tag-Namen angeben.

   SELECT *
   FROM TABLE(
    governance.INFORMATION_SCHEMA.POLICY_REFERENCES(
      REF_ENTITY_DOMAIN => 'TABLE',
      REF_ENTITY_NAME => 'finance.accounting.name_number'
      )
   );
   

   Copy

   Rückgabe (beachten Sie die aktualisierten Spalten):

   ------------+----------------+--------------------------------+----------------+-------------------+-----------------+-----------------+-------------------+-----------------+----------------------+--------------+------------+-----------------------+---------------+
    POLICY_DB  | POLICY_SCHEMA  | POLICY_NAME                    |  POLICY_KIND   | REF_DATABASE_NAME | REF_SCHEMA_NAME | REF_ENTITY_NAME | REF_ENTITY_DOMAIN | REF_COLUMN_NAME | REF_ARG_COLUMN_NAMES | TAG_DATABASE | TAG_SCHEMA | TAG_NAME              | POLICY_STATUS |
   ------------+----------------+--------------------------------+----------------+-------------------+-----------------+-----------------+-------------------+-----------------+----------------------+--------------+------------+-----------------------+---------------+
    GOVERNANCE | MASKING_POLICY | ACCOUNT_NAME_MASK_TAG_STRING   | MASKING_POLICY | FINANCE           | ACCOUNTING      | NAME_NUMBER     | TABLE             | ACCOUNT_NAME    | NULL                 | GOVERNANCE   | TAGS       | ACCOUNTING_COL_STRING | ACTIVE        |
    GOVERNANCE | MASKING_POLICY | ACCOUNT_NUMBER_MASK_TAG_STRING | MASKING_POLICY | FINANCE           | ACCOUNTING      | NAME_NUMBER     | TABLE             | ACCOUNT_NUMBER  | NULL                 | GOVERNANCE   | TAGS       | ACCOUNTING_COL_STRING | ACTIVE        |
   ------------+----------------+--------------------------------+----------------+-------------------+-----------------+-----------------+-------------------+-----------------+----------------------+--------------+------------+-----------------------+---------------+
   

6. Fragen Sie die Tabellenspalten ab, um sicherzustellen, dass Snowflake das korrekte Abfrageergebnis liefert, das nur den Wert in der Spalte ACCOUNT_NUMBER maskieren soll.

   USE ROLE accounting_admin;
   SELECT * FROM finance.accounting.name_number;
   

   Copy

   Rückgabewerte:

   ---------------+----------------+
     ACCOUNT_NAME | ACCOUNT_NUMBER |
   ---------------+----------------+
     ACME         | -1             |
   ---------------+----------------+
   

Beispiel 3: Schutz einer Tabelle basierend auf dem Tag-Zeichenfolgenwert¶

In diesem Beispiel wird eine Zeilenzugriffsrichtlinie verwendet, um eine Tabelle auf der Grundlage eines der Tabelle zugewiesenen Tag-Zeichenfolgenwerts zu schützen, und eine Tag-basierte Maskierungsrichtlinie, um die Spalten in der Tabelle zu schützen. Der Einfachheit halber wird in diesem Beispiel ein Tag verwendet, dem die Maskierungsrichtlinien zugewiesen werden, und das Tag wird der Tabelle zugewiesen. Die Spalten in der Tabelle haben aufgrund der Tag-Herkunft automatisch denselben Tag und seinen Zeichenfolgenwert.

Die Zeilenzugriffsrichtlinie wertet dynamisch den Tag-Zeichenfolgenwert des Tags aus, das der Tabelle zugewiesen ist, indem die Funktion SYSTEM$GET_TAG_ON_CURRENT_TABLE in den Bedingungen der Zeilenzugriffsrichtlinie aufgerufen wird. Wie im vorherigen Beispiel rufen die Bedingungen der Maskierungsrichtlinie die Funktion SYSTEM$GET_TAG_ON_CURRENT_COLUMN auf, um den Tag-Zeichenfolgenwert in den Tabellenspalten auszuwerten.

Die Tabelle finance.accounting.name_number hat zwei Spalten, die die Datentypen STRING bzw. NUMBER haben:

---------------+----------------+
  ACCOUNT_NAME | ACCOUNT_NUMBER |
---------------+----------------+
  ACME         | 1000           |
---------------+----------------+

Schützen Sie die Tabelle und deren Spalten mit einer Zeilenzugriffsrichtlinie und einer Tag-basierten Maskierungsrichtlinie wie folgt:

1. Erstellen Sie eine Zeilenzugriffsrichtlinie, die die Funktion SYSTEM$GET_TAG_ON_CURRENT_TABLE in den Richtlinienbedingungen aufruft:

   USE ROLE row_access_admin;
   USE SCHEMA governance.row_access_policies;
   
   CREATE ROW ACCESS POLICY rap_tag_value
   AS (account_number number)
   RETURNS BOOLEAN ->
   SYSTEM$GET_TAG_ON_CURRENT_TABLE('tags.accounting_row_string') = 'visible'
   AND
   'accounting_admin' = CURRENT_ROLE();
   

   Copy

   Die Richtlinie gibt an, dass Snowflake im Abfrageergebnis nur dann Zeilen zurückgibt, wenn das Tag accounting_row_string der Tabelle mit einem Zeichenfolgenwert 'visible' zugewiesen ist und wenn die Rolle, die die Abfrage auf der Tabelle oder deren Spalten ausführt, die kundenspezifische Rolle accounting_admin ist.

   Snowflake gibt keine Zeilen im Abfrageergebnis zurück, wenn eine der folgenden Bedingungen erfüllt ist:

   • Das Tag accounting_row_string ist der Tabelle nicht zugeordnet.

   • Das Tag accounting_row_string ist der Tabelle zugeordnet, weist aber einen anderen Zeichenfolgenwert auf.

   • Die Rolle, die eine Abfrage auf der Tabelle oder deren Spalten ausführt, ist nicht die kundenspezifische Rolle accounting_admin.

2. Weisen Sie der Tabelle die Zeilenzugriffsrichtlinie zu:

   ALTER TABLE finance.accounting.name_number
     ADD ROW ACCESS POLICY rap_tag_value ON (account_number);
   

   Copy

   Beachten Sie, dass zu diesem Zeitpunkt in der Prozedur eine Abfrage auf die Tabelle keine Zeilen im Abfrageergebnis für irgendeine Rolle in Snowflake zurückgeben sollte, weil das Tag accounting_row_string der Tabelle nicht zugeordnet ist. Das erwartete Ergebnis einer Abfrage der Tabelle sollte also wie folgt sein:

   USE ROLE accounting_admin;
   SELECT * FROM finance.accounting.name_number;
   

   Copy

   Rückgabewerte:

   ---------------+----------------+
     ACCOUNT_NAME | ACCOUNT_NUMBER |
   ---------------+----------------+
                  |                |
   ---------------+----------------+
   

   Durch die Entscheidung, der Tabelle erst die Zeilenzugriffsrichtlinie zuzuweisen und erst danach die Tag-basierte Maskierungsrichtlinie, werden alle Tabellendaten so früh wie möglich geschützt.

3. Erstellen Sie ein Tag mit dem Namen accounting_row_string im Schema mit dem Namen governance.tags.

   USE ROLE tag_admin;
   USE SCHEMA governance.tags;
   CREATE TAG accounting_row_string;
   

   Copy

4. Erstellen Sie verschiedene Maskierungsrichtlinien zum Schutz der Spalten ACCOUNT_NAME und ACCOUNT_NUMBER. In jeder dieser Richtlinien sind die Rohdaten nur sichtbar, wenn der aktuelle Tag-Zeichenfolgenwert in der Spalte auf 'visible' gesetzt ist.

   Richtlinie für Kontonamen:

   USE ROLE masking_admin;
   USE SCHEMA governance.masking_policies;
   
   CREATE MASKING POLICY account_name_mask AS (val string) RETURNS string ->
     CASE
       WHEN SYSTEM$GET_TAG_ON_CURRENT_COLUMN('tags.accounting_row_string') = 'visible' THEN val
       ELSE '***MASKED***'
     END;
   

   Copy

   Richtlinie für Kontonummer:

   CREATE MASKING POLICY account_number_mask AS (val number) RETURNS number ->
     CASE
       WHEN SYSTEM$GET_TAG_ON_CURRENT_COLUMN('tags.accounting_row_string') = 'visible' THEN val
       ELSE -1
     END;
   

   Copy

5. Weisen Sie dem Tag accounting_row_string beide Maskierungsrichtlinien zu. Beachten Sie, dass beide Richtlinien dem Tag in einer einzigen Anweisung zugewiesen werden können.

   ALTER TAG governance.tags.accounting_row_string SET
     MASKING POLICY account_name_mask,
     MASKING POLICY account_number_mask;
   

   Copy

6. Weisen Sie das Tag accounting_row_string der Tabelle mit dem Tag-Zeichenfolgenwert 'visible' zu:

   ALTER TABLE finance.accounting.name_number
     SET TAG governance.tags.accounting_row_string = 'visible';
   

   Copy

   Da das Tag der Tabelle nun mit dem Zeichenfolgenwert visible zugewiesen ist, können die Tabellendaten nur von der kundenspezifischen Rolle accounting_admin eingesehen werden. Eine Abfrage durch einen Benutzer mit einer anderen Rolle sollte dazu führen, dass keine Zeilen zurückgegeben werden, wie zuvor in diesem Beispiel gezeigt. Mit anderen Worten: Die Bedingungen der Zeilenzugriffsrichtlinie werden jetzt als wahr bewertet.

   Ebenso haben die Tabellenspalten den Tag-Zeichenfolgenwert des visible-Tags, da die Spalten das Tag und dessen Zeichenfolgenwert durch die Tag-Herkunft erben. Das Ergebnis ist, dass Snowflake nicht maskierte Daten zurückgibt, wenn ein Benutzer mit der kundenspezifischen Rolle accounting_admin die Tabelle abfragt:

   USE ROLE accounting_admin;
   SELECT * FROM finance.accounting.name_number;
   

   Copy

   Rückgabewerte:

   ---------------+----------------+
     ACCOUNT_NAME | ACCOUNT_NUMBER |
   ---------------+----------------+
     ACME         | 1000           |
   ---------------+----------------+
   

7. Um Daten in einer der beiden Spalten zu maskieren, müssen Sie den Tag-Zeichenfolgenwert für die Spalte direkt aktualisieren. So maskieren Sie beispielsweise die Daten in der Spalte ACCOUNT_NUMBER:

   ALTER TABLE finance.accounting.name_number MODIFY COLUMN
     account_number SET TAG governance.tags.accounting_row_string = 'protect';
   

   Copy

   Wenn nun ein Benutzer mit der kundenspezifischen Rolle accounting_admin die Tabelle oder die Spalte ACCOUNT_NUMBER abfragt, gibt Snowflake maskierte Daten zurück:

   USE ROLE accounting_admin;
   SELECT * FROM finance.accounting.name_number;
   

   Copy

   Rückgabewerte:

   ---------------+----------------+
     ACCOUNT_NAME | ACCOUNT_NUMBER |
   ---------------+----------------+
     ACME         | -1             |
   ---------------+----------------+