Tag-basierte Maskierungsrichtlinien

Unter diesem Thema werden Konzepte zu Tag-basierten Maskierungsrichtlinien und Beispiele für Tag-basierte Maskierungsrichtlinien zum Schutz von Spaltendaten bereitgestellt.

Unter diesem Thema:

Übersicht

Eine Tag-basierte Maskierungsrichtlinie kombiniert die Features Objekt-Tagging und Maskierungsrichtlinien, sodass mit dem ALTER TAG-Befehl eine Maskierungsrichtlinie für ein Tag festgelegt werden kann. Wenn der Datentyp in der Signatur der Maskierungsrichtlinie und der Datentyp der Spalte übereinstimmen, wird die getaggte Spalte automatisch durch die Bedingungen der Maskierungsrichtlinie geschützt. Dies vereinfacht den Datenschutz, da für zu schützende Spaltendaten keine Maskierungsrichtlinie mehr manuell auf die Spalte angewendet werden muss. Eine Spalte kann durch eine Maskierungsrichtlinie, die einer Spalte direkt zugewiesen ist, und durch eine Tag-basierte Maskierungsrichtlinie geschützt werden. Wenn eine Spalte auf beide Maskierungsrichtlinien verweist, hat die Maskierungsrichtlinie, die der Spalte direkt zugewiesen ist, Vorrang vor der Tag-basierten Maskierungsrichtlinie.

Das Tag kann genau eine Maskierungsrichtlinie für jeden von Snowflake unterstützten Datentyp unterstützen. Um den anfänglichen Aufwand für den Schutz von Spaltendaten zu vereinfachen, erstellen Sie eine allgemeine Maskierungsrichtlinie für jeden Datentyp (z. B. STRING, NUMBER, TIMESTAMP_LTZ), die es autorisierten Rollen ermöglicht, die Rohdaten anzuzeigen, während nicht autorisierte Rollen nur einen festen maskierten Wert sehen können.

Die Bedingungen der Maskierungsrichtlinie können so definiert werden, dass sie die Spaltendaten auf der Grundlage der dem Tag zugewiesenen Richtlinie oder die Spaltendaten auf der Grundlage des Tag-Zeichenfolgenwerts des der Spalte zugewiesenen Tags schützen, je nach den Entscheidungen von Richtlinienadministrator, Tag-Administrator und Datenverwalter.

Beispiele für Tag-basierte Maskierungsrichtlinien finden Sie im Abschnitt Verwenden von Tag-basierten Maskierungsrichtlinien (unter diesem Thema).

Vorteile

Benutzerfreundlichkeit

Die Zuweisung einer oder mehrerer Maskierungsrichtlinien zu einem Tag ist einfach. Richtlinienadministratoren können Richtlinien hinzufügen oder ersetzen, ohne bestehende Arbeitsabläufe zu unterbrechen.

Skalierbar

Mit Tag-basierten Richtlinien können Richtlinienadministratoren einmal eine Richtlinie definieren, die Richtlinie einmal einem Tag zuweisen und dann, je nach Ebene, auf der das Tag gesetzt wird, die Richtlinie auf viele Objekte anwenden lassen. Dadurch wird der Aufwand für das manuelle Zuweisen einer einzelnen Richtlinie zu einer einzelnen Spalte bei jeder Erstellung oder Ersetzung einer neuen Spalte erheblich reduziert.

Umfassend

Richtlinienadministratoren können für jeden Datentyp eine Richtlinie erstellen und alle diese Richtlinien einem einzigen Tag zuordnen. Sobald das Tag auf Tabellenebene angewendet wird, sind alle Spalten der Tabelle geschützt, vorausgesetzt, der Datentyp der Spalte stimmt mit dem in der Richtlinie angegebenen Datentyp überein.

Zukünftige Objekte schützen

Wenn Sie einer Tabelle eine Tag-basierte Maskierungsrichtlinie zuweisen, wird die Maskierungsrichtlinie automatisch auf alle neuen Tabellenspalten angewendet. Dieses Verhalten ist analog dem von zukünftige Zuweisungen.

Flexibilität

Tag-basierte Maskierungsrichtlinien bieten eine Alternative zum Angeben von Maskierungsrichtlinien in CREATE TABLE-Anweisungen, wodurch sich die Tabellenverwaltungs-DDL vereinfachen lässt. Administratoren können die Maskierungsrichtlinie entweder bei der Tabellenerstellung zuweisen oder indem sie die Richtlinie dem Tag zuweisen, das die Tag-Herkunft verwendet.

Hinweise

  • Bei einer Tag-basierten Maskierungsrichtlinie, bei der das Tag in einem anderen Schema als Maskierungsrichtlinie und Tabelle gespeichert ist, führt das Klonen des Schemas, das die Maskierungsrichtlinie und die Tabelle enthält, dazu, dass die geklonte Tabelle durch die Maskierungsrichtlinie im Quellschema und nicht durch das geklonte Schema geschützt wird.

    Bei einer Tag-basierten Maskierungsrichtlinie, bei der das Tag, die Maskierungsrichtlinie und die Tabelle alle in demselben Schema vorhanden sind, führt das Klonen des Schemas jedoch dazu, dass die Tabelle durch die Maskierungsrichtlinie im geklonten Schema und nicht im Quellschema geschützt wird.

  • Weitere Informationen zur Replikation und zu Tag-basierten Maskierungsrichtlinien finden Sie unter Hinweise zur Richtlinienreplikation.

  • Weitere Informationen zu Sicheres Freigeben von Daten in Snowflake und diesem Feature finden Sie unter:

Einschränkungen

Alle bestehenden Maskierungsrichtlinieneinschränkungen gelten für Tag-basierte Maskierungsrichtlinien.

Beachten Sie die folgenden zusätzlichen Einschränkungen bei der Verwendung von Tag-basierten Maskierungsrichtlinien:

Datentypen

Ein Tag kann eine Maskierungsrichtlinie für jeden Datentyp unterstützen. Wenn zum Beispiel ein Tag bereits eine Maskierungsrichtlinie für den Datentyp NUMBER hat, können Sie demselben Tag keine weitere Maskierungsrichtlinie mit dem Datentyp NUMBER zuweisen.

System-Tags

Einem System-Tag kann keine Maskierungsrichtlinie zugewiesen werden.

Löschen von Objekten

Weder die Maskierungsrichtlinie noch das Tag können gelöscht werden, wenn die Maskierungsrichtlinie einem Tag zugewiesen ist. Ebenso können das übergeordnete Schema und die Datenbank, die das Tag und die Maskierungsrichtlinie enthalten, nicht gelöscht werden, wenn die Richtlinie einem Tag zugewiesen ist. Weitere Informationen dazu finden Sie unter Zuweisung (unter diesem Thema).

Materialisierte Ansichten

Eine materialisierte Ansicht kann nicht erstellt werden, wenn die zugrunde liegende Tabelle durch eine Tag-basierte Maskierungsrichtlinie geschützt ist. Weitere Informationen dazu finden Sie unter Maskierungsrichtlinien und materialisierte Ansichten.

Wenn eine materialisierte Ansicht vorhanden ist und später eine Tag-basierte Maskierungsrichtlinie zu der zugrunde liegenden Tabelle hinzugefügt wird, kann die materialisierte Ansicht nicht abgefragt werden; die materialisierte Ansicht ist dann ungültig. Um die materialisierte Ansicht weiter zu verwenden, entziehen Sie die Tag-basierte Maskierungsrichtlinie, erstellen Sie diese neu oder setzen Sie sie fort, und fragen Sie dann die materialisierte Ansicht ab.

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.

Bedingte Spalten

Eine maskierte Spalte kann nicht als bedingte Spalte in einer Maskierungsrichtlinie verwendet werden.

Zuordnungstabellen

Eine Tabelle, die eine Spalte enthält, die durch eine Tag-basierte Maskierungsrichtlinie geschützt ist, kann nicht als Zuordnungstabelle verwendet werden.

Virtuelle Spalten

Während einer virtuellen Spalte ein Tag zugewiesen werden kann, kann der virtuellen Spalte keine Tag-basierte Maskierungsrichtlinie zugewiesen werden. Wenn einer virtuellen Spalte eine Tag-basierte Richtlinie zugewiesen ist, schlägt die Abfrage der Spalte zur Laufzeit fehl.

Verwalten von Tag-basierten Maskierungsrichtlinien

Die bestehenden Berechtigungen für Maskierungsrichtlinien und Tags sowie die DDL zum Verwalten von Maskierungsrichtlinien und Tags gelten auch für Tag-basierte Maskierungsrichtlinien.

Es gibt jedoch zusätzliche Aktualisierungen für die Berechtigung APPLY MASKING POLICY, den Befehl ALTER TAG und die Operation DROP/REPLACE, wenn sich die Richtlinie und das Tag in derselben übergeordneten Datenbank bzw. demselben Schema befinden.

Berechtigung

Eine Rolle mit der globalen Berechtigung APPLY MASKING POLICY kann eine Maskierungsrichtlinie einem Tag zuordnen und eine Maskierungsrichtlinie einem Tag entziehen.

Weisen Sie zum Beispiel der benutzerdefinierten Rolle TAG_ADMIN die globale Berechtigung APPLY MASKING POLICY zu:

use role securityadmin;

grant apply masking policy on account to role tag_admin;

Zuweisung

Verwenden Sie einen ALTER TAG-Befehl, um eine Maskierungsrichtlinie einem Tag zuzuordnen oder um eine Maskierungsrichtlinie einem Tag zu entziehen. Beachten Sie, dass die Syntax für den ALTER TAG-Befehl die Zuweisung mehrerer Maskierungsrichtlinien zu einem Tag in einer einzigen Anweisung ermöglicht:

ALTER TAG <tag_name> SET MASKING POLICY <masking_policy_name> [ , MASKING POLICY <masking_policy_2_name> , ... ]

ALTER TAG <tag_name> UNSET MASKING POLICY <masking_policy_name> [ , MASKING POLICY <masking_policy_2_name> , ... ]

Weisen Sie zum Beispiel die Maskierungsrichtlinie mit dem Namen ssn_mask dem Tag mit dem Namen security zu:

-- set
alter tag security set masking policy ssn_mask;

-- unset

alter tag security unset masking policy ssn_mask;

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:

Übergeordnete Datenbank und übergeordnetes Schema

Durch Aktivieren des Verhaltensänderungs-Bundles 2022_07 werden DROP/REPLACE-Operationen auf Datenbank und Schema verhindert, wenn Folgendes gilt:

  • 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.

Das Aktivieren des Bundles wirkt sich auf die folgenden vier Befehle aus:

  • DROP DATABASE

  • DROP SCHEMA

  • CREATE OR REPLACE DATABASE

  • CREATE OR REPLACE SCHEMA

Weitere Informationen dazu finden Sie in der Ankündigung.

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.

Verwenden von Tag-basierten Maskierungsrichtlinien

Die nachstehenden Unterabschnitte enthalten die folgenden Informationen:

  • Ein gemeinsames Verfahren zur Verwendung mit Tag-basierten Maskierungsrichtlinien zum Schutz und zur Validierung von Daten.

  • Schritte, die vor der Implementierung von Tag-basierten Maskierungsrichtlinien ausgeführt werden müssen.

  • Eine Liste der gemeinsamen Annahmen für die Beispiele.

  • Repräsentative Beispiele für die Verwendung von Tag-basierten Maskierungsrichtlinien, einschließlich der Verwendung der folgenden Systemfunktionen:

Ermitteln von Tags und Richtlinien

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 benutzerdefinierte 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 benutzerdefinierte 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 benutzerdefinierte 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 benutzerdefinierte 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 benutzerdefinierte 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 benutzerdefinierten 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;
    
  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 benutzerdefinierten 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;
    

    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;
    
  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;
    
  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';
    
  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' )
    );
    

    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;
    

    Rückgabewerte:

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

    Nicht autorisiert:

    use role analyst;
    select* from finance.accounting.name_number;
    

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

    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;
    

    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;
    
  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';
    
  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' )
    );
    

    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;
    

    Rückgabewerte:

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

Beispiel 3: Schützen einer Tabelle auf Basis des Tag-Zeichenfolgenwerts

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.

Wichtig

Beachten Sie, dass Sie dem Tag keine Zeilenzugriffsrichtlinie zuweisen können.

Weisen Sie der Tabelle stattdessen die Zeilenzugriffsrichtlinie direkt mit einem ALTER TABLE-Befehl zu.

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();
    

    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 benutzerdefinierte 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 benutzerdefinierte 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);
    

    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;
    

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

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

    Da das Tag der Tabelle nun mit dem Zeichenfolgenwert visible zugewiesen ist, können die Tabellendaten nur von der benutzerdefinierten 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 benutzerdefinierten Rolle accounting_admin die Tabelle abfragt:

    use role accounting_admin;
    select * from finance.accounting.name_number;
    

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

    Wenn nun ein Benutzer mit der benutzerdefinierten 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;
    

    Rückgabewerte:

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

Problembehandlung bei Tag-basierten Maskierungsrichtlinien

In der folgenden Tabelle sind einige Fehlermeldungen aufgeführt, die Snowflake bei der Verwendung von Tag-basierten Maskierungsrichtlinien zurückgeben kann:

Verhalten

Fehlermeldung

Problembehandlung

Abfrage einer Spalte nicht möglich: zu viele Richtlinien.

SQL execution error: Column <Name_der_Spalte> is mapped to multiple masking policies by tags. Please contact your local administrator to fix the issue.

Eine bestimmte Spalte kann nur durch genau eine Maskierungsrichtlinie geschützt werden.

Rufen Sie die Funktion POLICY_REFERENCES auf, um die für die Spalte festgelegten Maskierungsrichtlinien zu ermitteln. Ändern Sie die Tags, indem Sie die Maskierungsrichtlinie dem Tag entziehen, sodass die Spalte nur durch genau eine Richtlinie geschützt ist.

Abfrage einer Spalte nicht möglich: keine bedingte Spalte.

SQL execution error: Column <Name_der_Spalte> is mapped to a masking policy where the table doesnt have acolumn for a secondary argument name of the policy. Please contact your local administrator to fix the issue.

Bei einer Maskierungsrichtlinie, die bedingte Argumente verwendet, müssen sich alle angegebenen Spalten in derselben Tabelle oder Ansicht befinden. Führen Sie einen der folgenden Schritte aus, um die Daten der Spalte zu schützen:

  • Weisen Sie der Spalte direkt eine andere Richtlinie zu.

  • Ändern Sie das Tag, indem Sie ihm eine andere Maskierungsrichtlinie zuweisen.

Spaltendaten werden nicht maskiert, weil die Datentypen von Spalte und Richtlinie nicht übereinstimmen.

SQL execution error: Column <Name_der_Spalte> is mapped to a masking policy where the table has a column with different data-type for a secondary argument name.Please contact your local administrator to fix the issue.

Um die Spaltendaten zu maskieren, müssen der Datentyp der Spalte und der Datentyp in der Signatur der Maskierungsrichtlinie übereinstimmen. Führen Sie einen der folgenden Schritte aus, um die Daten der Spalte zu schützen:

  • Weisen Sie der Spalte direkt eine andere Richtlinie zu.

  • Weisen Sie dem Tag eine Maskierungsrichtlinie zu, und achten Sie darauf, dass der Datentyp für die Richtlinie und der Datentyp für die Spalte übereinstimmen.

Zurück zum Anfang