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. Sie können eine Tag-basierte Maskierungsrichtlinie für eine Datenbank, ein Schema oder eine Tabelle festlegen.

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.

Datenbank, Schema oder Tabelle für Zuweisung der Richtlinie auswählen

Data Engineers und Datenverwalter können die Tag-basierte Maskierungsrichtlinie wahlweise einer Datenbank, einem Schema, einer Tabelle oder einer Spalte zuweisen.

Datenbank und Schema:

Wenn Sie eine Tag-basierte Maskierungsrichtlinie für eine Datenbank oder ein Schema festlegen, nutzen Sie die Tag-Herkunft, um die Tabellen- und Ansichtsspalten in dem Schema oder der Datenbank zu schützen. Das Festlegen einer Tag-basierten Maskierungsrichtlinie für die Datenbank oder das Schema schützt die Spalten in dieser Datenbank bzw. diesem Schema nur, wenn der Datentyp der Spalte mit dem Datentyp der Maskierungsrichtlinie übereinstimmt, die auf dem Tag gesetzt ist.

Der wichtigste Vorteil des Festlegens einer Tag-basierten Maskierungsrichtlinie für die Datenbank oder das Schema besteht darin, dass die Spalten in allen neu hinzugefügten Tabellen und Ansichten automatisch geschützt werden, wenn der Datentyp der Spalte mit dem Datentyp der Maskierungsrichtlinie übereinstimmt. Dieser Ansatz vereinfacht die Verwaltung des Datenschutzes, da es nicht mehr notwendig ist, auf jede Tabelle Tags zu setzen. Das Ergebnis ist, dass die Richtlinie neue Daten in Snowflake so lange schützt, bis ein Datenschutzbeauftragter beschließt, entweder direkt eine Maskierungsrichtlinie auf die Spalte zu setzen oder der Tabelle oder Ansicht eine Zeilenzugriffsrichtlinie zuzuweisen.

Tabellen:

Wenn Sie eine Tag-basierte Maskierungsrichtlinie für eine Tabelle festlegen, ist das Tag für alle Spalten in der Tabelle festgelegt. Die Maskierungsrichtlinie schützt die Daten der Spalte, wenn der Datentyp der Spalte mit dem Datentyp der Maskierungsrichtlinie übereinstimmt.

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.

Beispiele für Tag-basierte Maskierungsrichtlinien finden Sie im Abschnitt Tag-basierte Maskierungsrichtlinien verwenden (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.

    Wenn die Tabelle geklont oder in ein anderes Schema oder eine andere Datenbank verschoben wird und ursprünglich durch eine Tag-basierte Maskierungsrichtlinie auf dem Schema oder der Datenbank geschützt war, wird die Tabelle nicht durch die Tag-basierte Maskierungsrichtlinie auf Quellschema oder Quelldatenbank geschützt. Die Tabelle ist durch die auf dem Zielschema oder der Zieldatenbank festgelegte Tag-basierte Maskierungsrichtlinie geschützt, wenn auf Zielschema oder Zieldatenbank eine Tag-basierte Maskierungsrichtlinie festgelegt ist.

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

  • Weitere Informationen zu Secure Data Sharing und dieses 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 Maskierungsrichtlinie einem Tag zuweisen (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.

Snowflake Native App Framework:

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

Tag-basierte Maskierungsrichtlinien verwalten

Die bestehenden Berechtigungen für Maskierungsrichtlinien und Tags sowie die Befehle zum Verwalten von Maskierungsrichtlinien und Tags gelten auch für 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:

Tipp

Um beim Festlegen einer Tag-basierten Maskierungsrichtlinie für ein Schema oder eine Datenbank Konflikte mit anderen Tags und Maskierungsrichtlinien zu vermeiden, prüfen sie vorher Folgendes:

  • Fragen Sie die Account Usage-Ansicht TAG_REFERENCES ab, um zu prüfen, welche Tags bereits auf einer Tabelle oder der Spalte einer Tabelle vorhanden sind.

  • Fragen Sie die Account Usage-Ansicht POLICY_REFERENCES ab, um festzustellen, ob für eine Tabelle oder eine Spalte eine Tag-basierte Maskierungsrichtlinie festgelegt ist. Weitere Informationen dazu finden Sie unter Tags und Richtlinien untersuchen.

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:

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:

Tag-basierte Maskierungsrichtlinien verwenden

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:

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.

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

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.