Grundlegendes zur Sicherheit auf Spaltenebene

Unter diesem Thema wird ein allgemeiner Überblick zur Sicherheit auf Spaltenebene gegeben, und es werden die Features und die Verwendung von dynamischer Datenmaskierung und externer Tokenisierung beschrieben.

Weitere Informationen zur Verwendung einer Maskierungsrichtlinie bei einem Tag finden Sie unter Tag-basierte Maskierungsrichtlinien.

Was ist Sicherheit auf Spaltenebene?

Das Snowflake-Feature Sicherheit auf Spaltenebene erlaubt die Anwendung von Maskierungsrichtlinien auf Spalten einer Tabelle oder Ansicht zum Schutz der darin gespeicherten Daten. Derzeit stehen für Sicherheit auf Spaltenebene zwei Features zur Verfügung:

  1. Dynamische Datenmaskierung

  2. Externe Tokenisierung

Die dynamische Datenmaskierung ist ein Feature für Sicherheit auf Spaltenebene, das Maskierungsrichtlinien verwendet, um Klartextdaten in Tabellen- und Ansichtsspalten zur Abfragezeit selektiv zu maskieren.

Die externe Tokenisierung ermöglicht Konten, Daten vor dem Laden in Snowflake zu tokenisieren und zur Laufzeit der Abfrage zu detokenisieren. Bei der Tokenisierung werden vertrauliche Daten entfernt, indem sie durch ein nicht entschlüsselbares Token ersetzt werden. Bei der externen Tokenisierung werden Maskierungsrichtlinien mit externen Funktionen verwendet.

Was sind Maskierungsrichtlinien?

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

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

The masking policy admin can apply masking policies to tables and views.

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

Masking policy results for authorized and unauthorized roles.

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

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

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

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

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

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

Wie funktioniert eine Maskierungsrichtlinie?

Maskierungsrichtlinien für die dynamische Datenmaskierung und die externe Tokenisierung haben dieselbe Struktur und dasselbe Format mit einer Ausnahme: Maskierungsrichtlinien für die externe Tokenisierung erfordern die Verwendung von Schreiben von externen Funktionen im Maskierungsrichtlinientext.

Der Grund für diese Ausnahme ist, dass für die externe Tokenisierung ein externer Tokenisierungsanbieter erforderlich ist, um Daten vor dem Laden in Snowflake zu tokenisieren. Zur Laufzeit der Abfrage verwendet Snowflake die externe Funktion, um einen REST-API-Aufruf an den Tokenisierungsanbieter zu senden, der dann eine Tokenisierungsrichtlinie (die außerhalb von Snowflake erstellt wurde) auswertet, um basierend auf den Bedingungen der Maskierungsrichtlinie entweder tokenisierte oder detokenisierte Daten zurückzugeben. Beachten Sie, dass in Snowflake und beim Tokenisierungsanbieter die Rollenzuordnung vorhanden sein muss, um sicherzustellen, dass von einer bestimmten Abfrage die richtigen Daten zurückgegeben werden.

Snowflake unterstützt das Erstellen von Maskierungsrichtlinien mit CREATE MASKING POLICY. Beispiel:

-- Dynamic Data Masking

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

-- External Tokenization

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

Wobei:

employee_ssn_mask

Der Name der Richtlinie für die dynamische Datenmaskierung.

employee_ssn_detokenize

Der Name der Richtlinie für die externe Tokenisierung.

AS (val string) RETURNS string

Gibt die Eingabe- und Ausgabedatentypen an. Die Datentypen müssen übereinstimmen.

->

Trennt die Signatur der Richtlinie von ihrem Textteil.

case ... end;

Gibt die Bedingungen im Maskierungsrichtlinientext (d. h. im SQL-Ausdruck) an.

Wenn in den beiden folgenden Beispielen der Abfrageausführende die kundenspezifische Rolle PAYROLL in der aktuellen Sitzung verwendet, werden dem Ausführenden die nicht maskierten bzw. detokenisierten Werte angezeigt. Andernfalls wird ein fester maskierter bzw. tokenisierter Wert angezeigt.

ssn_unprotect

Die externe Funktion zum Bearbeiten der tokenisierten Daten.

Tipp

Wenn Sie eine bestehende Maskierungsrichtlinie aktualisieren möchten und dazu die aktuelle Definition der Richtlinie anzeigen müssen, können Sie die Funktion GET_DDL aufrufen oder den Befehl DESCRIBE MASKING POLICY ausführen.

Die Definition der Maskierungsrichtlinie kann dann mit dem Befehl ALTER MASKING POLICY aktualisiert werden. Für diesen Befehl muss die für eine Spalte festgelegte Maskierungsrichtlinie nicht aufgehoben werden. Eine Spalte, die durch eine Richtlinie geschützt ist, bleibt also geschützt, während die Definition der Richtlinie aktualisiert wird.

Weitere Informationen zur Verwendung von Maskierungsrichtlinien finden Sie unter:

Bedingte Spalten verwenden

Bei der bedingten Maskierung wird eine Maskierungsrichtlinie verwendet, um die Spaltendaten in einer Tabelle oder Ansicht basierend auf den Werten in einer oder mehreren verschiedenen Spalten selektiv zu schützen.

Die Verwendung einer anderen Spalte zur Bestimmung, ob Daten in einer bestimmten Spalte geschützt werden sollen, bietet Richtlinienadministratoren (d. h. Benutzern mit der kundenspezifischen Rolle POLICY_ADMIN) mehr Freiheit bei der Erstellung von Richtlinienbedingungen.

Beachten Sie den Unterschied zwischen den beiden repräsentativen Beispielen zu Richtlinien:

Maskierungsrichtlinie

Diese Richtlinie kann für die dynamische Datenmaskierung verwendet werden.

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

Diese Richtlinie gibt nur das Argument val an, das für jede Spalte steht, die Zeichenfolgendaten enthält. Diese Richtlinie kann einmal erstellt und auf jede Spalte mit Zeichenfolgendaten angewendet werden. Nur Benutzer, deren CURRENT_ROLE die kundenspezifische Rolle PAYROLL ist, können die Spaltendaten sehen. Andernfalls gibt Snowflake im Abfrageergebnis einen festen, maskierten Wert zurück.

Weitere Informationen dazu finden Sie unter CREATE MASKING POLICY.

Bedingte Maskierungsrichtlinie

Beachten Sie die Argumente (email varchar, visibility string) in diesem Beispiel.

CREATE MASKING POLICY email_visibility AS
(email varchar, visibility string) RETURNS varchar ->
  CASE
    WHEN CURRENT_ROLE() = 'ADMIN' THEN email
    WHEN VISIBILITY = 'PUBLIC' THEN email
    ELSE '***MASKED***'
  END;
Copy

Diese Richtlinie gibt zwei Argumente an, email und visibility, bei denen es sich um Spaltennamen handelt. Die erste Spalte gibt immer die zu maskierende Spalte an. Die zweite Spalte ist eine bedingte Spalte, anhand der bestimmt wird, ob die erste Spalte maskiert werden soll. Es können mehrere bedingte Spalten angegeben werden. In dieser Richtlinie wird Benutzern, deren CURRENT_ROLE die kundenspezifische Rolle ADMIN ist, die E-Mail-Adresse angezeigt. Wenn die E-Mail-Adresse auch einen Sichtbarkeitsspaltenwert Public hat, dann ist die E-Mail-Adresse im Abfrageergebnis sichtbar. Andernfalls gibt Snowflake ein Abfrageergebnis mit einem festen, maskierten Wert für die E-Mail-Spalte zurück.

Diese Richtlinie kann auf mehreren Tabellen und Ansichten angewendet werden, sofern die Spaltenstruktur in der Tabelle oder Ansicht mit den in der Richtlinie angegebenen Spalten übereinstimmt. Weitere Informationen dazu finden Sie unter CREATE MASKING POLICY.

Da für jedes repräsentative Beispiel derselbe Objekttyp verwendet wird, sollte das Gesamtverhalten der Richtlinien ähnlich sein, einschließlich, aber nicht beschränkt auf:

  • Auswertung der Laufzeit von Abfragen

  • Nützlichkeit (z. B. Schutz sensibler Daten mithilfe von Kontextfunktionen)

  • Berechtigungsstruktur

  • Nutzung mit verschiedenen Managementkonzepten zur Unterstützung der Funktionstrennung (Segregation of Duties, SoD).

Einschränkungen

Zusätzlich zu den bestehenden Maskierungsrichtlinieneinschränkungen haben die bedingten Maskierungsrichtlinien die folgenden Einschränkungen:

  • Zeilenzugriffsrichtlinien. Weitere Details dazu finden Sie unter Zeilenzugriffsrichtlinien (unter diesem Thema).

  • Externe Tabellen. Weitere Details dazu finden Sie unter Externe Tabellen (unter diesem Thema).

Hinweise

Zusätzlich zu den bestehenden Überlegungen zu normalen Maskierungsrichtlinien sollten Sie vor der Verwendung bedingter Maskierungsrichtlinien die folgenden Punkte prüfen:

  • Vergewissern Sie sich, dass sich alle in der CREATE MASKING POLICY-Anweisung angegebenen Spalten in derselben Tabelle oder derselben Ansicht befinden.

  • Minimieren Sie die Anzahl der Spaltenargumente in der Richtliniendefinition. Snowflake muss jede Spalte zur Laufzeit der Abfrage auswerten. Die Angabe von weniger Spalten führt insgesamt zu einer höheren Performance.

  • Verfolgen Sie die Verwendung bedingter Spalten in einer Maskierungsrichtlinie, indem Sie die Information Schema-Tabellenfunktion POLICY_REFERENCES aufrufen.

Weitere Informationen zum Festlegen von Maskierungsrichtlinien mit bedingten Spalten finden Sie unter Bedingte Maskierungsrichtlinie auf eine Spalte anwenden (unter diesem Thema).

Maskierungsrichtlinien zur Laufzeit von Abfragen

Zur Laufzeit schreibt Snowflake die Abfrage neu, um den Maskierungsrichtlinienausdruck auf die in der Maskierungsrichtlinie angegebenen Spalten anzuwenden. Die Maskierungsrichtlinie wird auf die Spalte angewendet, unabhängig davon, wo in einem SQL-Ausdruck auf die Spalte verwiesen wird, einschließlich:

  • Projektionen

  • JOIN-Prädikate

  • WHERE-Klausel-Prädikate

  • ORDER BY- und GROUP BY-Klauseln

Wichtig

Eine Maskierungsrichtlinie wird bewusst überall dort angewendet, wo immer in einem SQL-Konstrukt auf die relevante Spalte verwiesen wird, um so die Deanonymisierung von Daten durch kreative Abfragen zu verhindern, die maskierte Spaltendaten enthalten.

Wenn die Ausführung einer Abfrage zu maskierten Daten in einer oder mehreren Spalten führt, liefert die Abfrageausgabe möglicherweise nicht den erwarteten Wert, da die maskierten Daten die Auswertung aller Abfrageausgabedaten im gewünschten Kontext verhindern.

Maskierungsrichtlinien mit verschachtelten Objekten:

Snowflake unterstützt verschachtelte Maskierungsrichtlinien, z. B. eine Maskierungsrichtlinie für eine Tabelle und eine Maskierungsrichtlinie für eine Ansicht derselben Tabelle. Zur Laufzeit der Abfrage wertet Snowflake alle für eine bestimmte Abfrage relevanten Maskierungsrichtlinien in der folgenden Reihenfolge aus:

  1. Die für die Tabelle geltende Maskierungsrichtlinie wird immer zuerst ausgeführt.

  2. Die Richtlinie für die Ansicht wird ausgeführt, nachdem die Richtlinie für die Tabelle ausgewertet wurde.

  3. Wenn verschachtelte Ansichten vorhanden sind (z. B. table_1 » view_1 » view_2 » … view_n), werden die Richtlinien in der Reihenfolge von links nach rechts angewendet.

Dieses Muster setzt sich fort, egal wie viele Maskierungsrichtlinien hinsichtlich der Daten in der Abfrage vorhanden sind. Die folgende Abbildung zeigt die Beziehung zwischen einem Abfrageausführenden, Tabellen, Ansichten und Richtlinien.

Masking policies with tables and views.

Benutzerabfragen:

Das folgende Beispiel zeigt eine vom Benutzer übermittelte Abfrage, gefolgt von der Neufassung der Snowflake-Abfrage zur Laufzeit, bei der die Maskierungsrichtlinie (d. h. sql_expression) nur für die Spalte email gilt.

SELECT email, city
FROM customers
WHERE city = 'San Mateo';

SELECT <SQL_expression>(email), city
FROM customers
WHERE city = 'San Mateo';
Copy

Abfrage mit einer geschützten Spalte im WHERE-Klausel-Prädikat (Anti-Pattern):

Die folgenden Beispiele zeigen eine vom Benutzer übermittelte Abfrage, gefolgt von der Neufassung der Snowflake-Abfrage zur Laufzeit, bei der die Maskierungsrichtlinie (d. h. sql_expression) nur für eine Seite eines Vergleichs gilt (z. B. die E-Mail-Spalte, jedoch nicht die Zeichenfolge, mit der die E-Mail-Spalte verglichen wird). Die Ergebnisse der Abfrage entsprechen nicht dem, was der Benutzer beabsichtigt hat. Das Maskieren nur einer Seite eines Vergleichs ist ein übliches Anti-Pattern (Antimuster).

SELECT email
FROM customers
WHERE email = 'user@example.com';

SELECT <SQL_expression>(email)
FROM customers
WHERE <SQL_expression>(email) = 'user@example.com';
Copy

Abfrage mit einer geschützten Spalte im JOIN-Prädikat (Anti-Pattern):

SELECT b.email, d.city
FROM
  sf_tuts.public.emp_basic AS b
  JOIN sf_tuts.public.emp_details AS d ON b.email = d.email;

SELECT
  <SQL_expression>(b.email),
  d.city
FROM
  sf_tuts.public.emp_basic AS b
  JOIN sf_tuts.public.emp_details AS d ON <SQL_expression>(b.email) = <SQL_expression>(d.email);
Copy

Hinweise zu Laufzeitabfragen

Snowflake empfiehlt, die folgenden Faktoren zu berücksichtigen, wenn Sie versuchen, die Auswirkung einer Maskierungsrichtlinie für eine Spalte vorherzusagen und festzustellen, ob der Abfrageausführende maskierte Daten sieht:

Kontextfunktionen

Maskierungsrichtlinienbedingungen mit CURRENT_ROLE.

Wenn die Richtlinie die Funktion CURRENT_DATABASE oder CURRENT_SCHEMA aufruft, ergibt die Funktion die Datenbank oder das Schema, in der/dem die geschützte Tabelle oder Ansicht enthalten ist, und nicht die Datenbank oder das Schema für die Sitzung, die Sie mit einem USE <Objekt>-Befehl angeben oder mit der Kontextauswahl in Snowsight auswählen.

Die ausführende Rolle

Maskierungsrichtlinienbedingungen mit INVOKER_ROLE.

Rollenhierarchie

Maskierungsrichtlinienbedingungen mit IS_ROLE_IN_SESSION oder IS_GRANTED_TO_INVOKER_ROLE.

Datenfreigabe (Data Sharing)

Ob die Daten mit Secure Data Sharing freigegeben werden. Weitere Details dazu finden Sie unter Data Sharing (Datenfreigabe) (unter diesem Thema).

Replikation

Weitere Informationen dazu finden Sie unter Replikation (unter diesem Thema).

Unterabfragen

Eine Maskierungsrichtlinie kann in der Richtliniendefinition auf eine Unterabfrage verweisen, allerdings gibt es Grenzen für die Unterstützung von Unterabfragen in Snowflake. Weitere Informationen dazu finden Sie unter Verwenden von Unterabfragen.

UDFs in einer Maskierungsrichtlinie

Stellen Sie sicher, dass der Datentyp der Spalte UDF-Spalte und der Maskierungsrichtlinie übereinstimmen. Weitere Informationen dazu finden Sie unter Benutzerdefinierte Funktionen in einer Maskierungsrichtlinie (unter diesem Thema).

Suchoptimierungsdienst

Der Suchoptimierungsdienst kann die Performance von Abfragen auf Tabellen verbessern, die Maskierungsrichtlinien und Zeilenzugriffsrichtlinien verwenden.

Weitere Informationen dazu finden Sie unter Unterstützung von Tabellen mit Maskierungsrichtlinien und Zeilenzugriffsrichtlinien im Suchoptimierungsdienst.

Die ersten drei Faktoren werden unter Erweiterte Sicherheit auf Spaltenebene genauer erläutert. Data Sharing gilt nur für die dynamische Datenmaskierung, da externe Funktionen im Kontext einer Freigabe nicht aufgerufen werden können.

Letztendlich bestimmt der spezifische Anwendungsfall, ob die dynamische Datenmaskierung oder die externe Tokenisierung besser geeignet ist.

Auswählen zwischen dynamischer Datenmaskierung und externer Tokenisierung

Um das Feature auszuwählen, das den Anforderungen Ihres Unternehmens am besten entspricht, bewerten Sie die wichtigsten Anwendungsfälle für Ihre Daten sowie relevante Überlegungen und Einschränkungen. In den folgenden beiden Abschnitten werden die Vor- und Nachteile der beiden Features zusammengefasst.

Vorteile

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

Faktor

Dynamische Datenmaskierung

Externe Tokenisierung

Anmerkungen

Behalten Sie den analytischen Wert nach der Entidentifikation bei.

Da die Tokenisierung einen eindeutigen Wert für einen gegebenen Satz von Zeichen liefert, ist es möglich, Datensätze nach einem tokenisierten Wert zu gruppieren, ohne die sensiblen Informationen preiszugeben.

Gruppieren Sie z. B. Krankenakten nach dem Diagnosecode, wobei der Patientendiagnosecode tokenisiert wird. Datenanalysten können dann eine Ansicht des Diagnosecodes abfragen, um eine Zählung der Anzahl der Patienten mit einem eindeutigen Diagnosecode zu erhalten.

Tokenisierte Daten vorladen.

Nicht autorisierten Benutzern wird niemals der tatsächliche Datenwert angezeigt. Benötigt einen externen Tokenisierungsanbieter.

Führt Vorladen von nicht maskierten Daten aus.

Benötigt nur integrierte Snowflake-Funktionalität, keine Dritten erforderlich.

Data Sharing.

Weitere Details dazu finden Sie unter Data Sharing (Datenfreigabe) (unter diesem Thema).

Benutzerfreundlichkeit und Änderungsmanagement.

Einmal Schreiben einer Richtlinie und dann Anwendung auf Tausende von Spalten in Datenbanken und Schemas.

Datenverwaltung und Aufgabentrennung (SoD).

Die Entscheidung, welche Spalten geschützt werden sollen, wird nicht vom Objekteigentümer sondern vom Sicherheits- oder Datenschutzbeauftragten getroffen.

Maskierungsrichtlinien sind einfach zu verwalten und unterstützen zentralisierte und dezentralisierte Administrationsmodelle.

Datenautorisierung und Data Governance.

Kontextueller Datenzugriff nach Rollen- oder kundenspezifischen Berechtigungen.

Unterstützt die von Sicherheits- oder Datenschutzbeauftragten implementierte Data Governance und kann berechtigten Benutzern mit der Rolle ACCOUNTADMIN oder SECURITYADMIN das unnötige Anzeigen von Daten untersagen.

Datenbankreplikation und Kontoobjektreplikation.

Weitere Informationen dazu finden Sie unter Replikation (unter diesem Thema).

Einschränkungen

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

Einschränkungen

Dynamische Datenmaskierung

Externe Tokenisierung

Anmerkungen

Materialisierte Ansichten (MV).

Eine vollständige Zusammenfassung finden Sie unter Materialisierte Ansichten (unter diesem Thema).

DROP MASKING POLICY

Bevor Sie eine Richtlinie löschen, müssen Sie die Richtlinie mit ALTER TABLE … ALTER COLUMN oder ALTER VIEW für die Tabellen- oder Ansichtsspalte deaktivieren.

DROP DATABASE und DROP SCHEMA

Für das Löschen einer Datenbank oder eines Schemas ist es erforderlich, dass die Maskierungsrichtlinie und deren Zuordnungen in einer Datenbank und einem Schema in sich abgeschlossen sind.

Beispielsweise enthält database_1 policy_1, und policy_1 wird nur in database_1 verwendet.

Externe Tabellen.

Eine externe Tabelle kann nicht als Lookup-Tabelle (d. h. in einer Unterabfrage) referenziert werden, um zu bestimmen, ob Spaltenwerte maskiert werden sollen. Weitere Informationen dazu finden Sie unter Externe Tabellen (unter diesem Thema).

Unterschiedliche Datentypen in der Ein- und Ausgabe einer Richtliniendefinition.

Bei einer Maskierungsrichtliniendefinition müssen Ein- und Ausgabe den gleichen Datentyp haben. Sie können also beispielsweise nicht den Zeitstempel als Eingabedatentyp definieren und eine Zeichenfolge zurückgeben.

Änderungsmanagement für Maskierungsrichtlinien.

Sie können Änderungen an Maskierungsrichtlinien optional in einem Versionskontrollsystem Ihrer Wahl speichern und verfolgen.

Zukünftige Berechtigungszuweisungen.

Zukünftige Berechtigungszuweisungen zu Maskierungsrichtlinien werden nicht unterstützt.

Als Problemumgehung können Sie einer kundenspezifischen Rolle die Berechtigung APPLY MASKING POLICY zuweisen, damit diese Rolle Maskierungsrichtlinien auf Tabellen- oder Ansichtsspalten anwenden kann.

Hinweise

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

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

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

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

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

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

Verwenden von Sicherheit auf Spaltenebene für Tabellen und Ansichten

Snowflake unterstützt Maskierungsrichtlinien mit Tabellen und Ansichten. Im Folgenden wird beschrieben, wie sich Maskierungsrichtlinien auf Tabellen und Ansichten in Snowflake auswirken.

Tipp

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

Aktive Rollenhierarchie und Zuordnungstabellen

Die Richtlinienbedingungen können die aktiven Primär- und Sekundärrollen des Benutzers in einer Sitzung direkt auswerten, aktive Rollen in einer Zuordnungstabelle suchen oder beides tun, je nachdem, wie der Richtlinienadministrator die Richtlinie schreiben möchte.

Für diese Anwendungsfälle empfiehlt Snowflake, die Richtlinienbedingungen so zu schreiben, dass sie die Kontextfunktion IS_ROLE_IN_SESSION aufrufen. Beispiele für Richtlinien finden Sie im Abschnitt Beispiele der Funktion IS_ROLE_IN_SESSION.

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

Maskierungsrichtlinien auf Spalten anwenden

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

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

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

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

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

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

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

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

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

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

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

Bedingte Maskierungsrichtlinie auf eine Spalte anwenden

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

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

    Weitere Informationen zu Syntax und Nutzung finden Sie unter:

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

    -- table
    CREATE OR REPLACE TABLE user_info (email string masking policy email_visibility) USING (email, visibility);
    
    --view
    CREATE OR REPLACE VIEW user_info_v (email masking policy email_visibility) USING (email, visibility) AS SELECT * FROM user_info;
    
    Copy
  2. Bei einer vorhandenen Tabelle oder Ansicht legen Sie die Richtlinie für eine Tabellen- oder Ansichtsspalte mit der entsprechenden ALTER-Anweisung fest.

    Weitere Informationen zu Syntax und Nutzung finden Sie unter:

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

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

Maskierungsrichtlinie auf einer Spalte ersetzen

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

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

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

    ALTER TABLE t1 MODIFY COLUMN c1 UNSET MASKING POLICY;
    
    ALTER TABLE t1 MODIFY COLUMN c1 SET MASKING POLICY p2;
    
    Copy
  • Verwenden Sie das Schlüsselwort FORCE, um die Richtlinie mit nur einer einzigen Anweisung zu ersetzen:

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

    Hinweis:

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

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

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

Wichtig

Seien Sie vorsichtig, wenn Sie eine Maskierungsrichtlinie für eine Spalte 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 Maskierungsrichtlinien zu koordinieren und Maskierungsrichtlinien nach Bedarf zu ersetzen.

Zeilenzugriffsrichtlinien

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

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

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

Funktionieren von Richtlinien simulieren

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

Materialisierte Ansichten

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

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

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

  2. Führen Sie für eine vorhandene materialisierte Ansicht eine ALTER VIEW … MODIFY COLUMN-Anweisung auf der materialisierten Sicht aus.

Führen Sie für eine neue materialisierte Ansicht die folgende Anweisung aus:

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

Ein Ansichtsbeispiel für eine vorhandene materialisierte Ansicht finden Sie im Abschnitt Maskierungsrichtlinien auf Spalten anwenden (unter diesem Thema).

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

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

    SQL execution error: One or more materialized views exist on the table. number of mvs=<number>, table name=<table_name>.
    
    Copy
  2. Wenn eine Maskierungsrichtlinie für eine zugrunde liegende Tabellenspalte festgelegt ist und eine materialisierte Ansicht auf Basis dieser Tabelle erstellt wird, enthält die materialisierte Ansicht nur Spalten, die nicht durch eine Maskierungsrichtlinie geschützt sind. Snowflake gibt auch die folgende Fehlermeldung zurück, wenn versucht wird, eine oder mehrere Spalten einzuschließen, die durch eine Maskierungsrichtlinie geschützt sind:

    Unsupported feature 'CREATE ON MASKING POLICY COLUMN'.
    
    Copy

Spalten mit Maskierungsrichtlinie abrufen

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

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

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

Objekt-Tagging und Maskierungsrichtlinien

Weitere Details dazu finden Sie unter Tag-basierte Maskierungsrichtlinien.

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

Hashing-, Kryptographie- und Verschlüsselungsfunktionen in Maskierungsrichtlinien

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

Weitere Informationen dazu finden Sie unter Erweiterte Sicherheit auf Spaltenebene.

Externe Tabellen

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

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

ALTER TABLE t1 MODIFY COLUMN VALUE SET MASKING POLICY p1;
Copy

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

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

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

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

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

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

Weitere Informationen dazu finden Sie unter CREATE MASKING POLICY.

Wichtig

Snowflake unterstützt nicht die Verwendung einer externen Tabelle als Lookup-Tabelle (d. h. in einer Unterabfrage) in einer Maskierungsrichtlinie. Beim Klonen einer Datenbank klont Snowflake die Maskierungsrichtlinie, aber nicht die externe Tabelle. Daher bezieht sich die Richtlinie in der geklonten Datenbank auf eine Tabelle, die in der geklonten Datenbank nicht vorhanden ist.

Wenn die Daten in der externen Tabelle für die Richtlinie erforderlich sind, sollten Sie in Erwägung ziehen, vor Durchführung einer Klonoperation die Daten der externen Tabelle in ein dediziertes Schema innerhalb der Datenbank zu verschieben, für die die Maskierungsrichtlinie vorliegt. Aktualisieren Sie die Maskierungsrichtlinie so, dass sie auf den voll qualifizierten Tabellennamen verweist, um sicherzustellen, dass sich die Richtlinie auf eine Tabelle in der geklonten Datenbank bezieht.

Streams

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

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

Geklonte Objekte

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

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

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

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

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

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

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

CREATE TABLE … AS SELECT (CTAS)-Anweisungen

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

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

Weitere Informationen dazu finden Sie unter CREATE TABLE.

Abfragen mit Aggregatfunktionen und maskierten Spalten

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

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

So erzielen Sie dieses Ergebnis:

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

    CREATE VIEW ssn_count AS SELECT DISTINCT(ssn) FROM table1;
    
    Copy
  2. Der Rolle ANALYST werden umfassende Berechtigungen für die Ansicht erteilt. Erteilen Sie dem Datenanalysten keine Berechtigungen für die Tabelle.

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

    CASE
      WHEN CURRENT_ROLE() IN ('PAYROLL') THEN val
      ELSE '***MASKED***'
    END;
    
    Copy
  4. Führen Sie eine Abfrage auf der Ansichtsspalte aus.

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

Benutzerdefinierte Funktionen in einer Maskierungsrichtlinie

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

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

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

Data Sharing (Datenfreigabe)

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

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

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

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

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

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

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

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

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

    • Der Anbieter von t1 dagegen kann t1 abfragen.

  • Externe Funktionen:

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

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

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

Bemerkung

Bei der externen Tokenisierung ist Secure Data Sharing nicht anwendbar, da externe Funktionen nicht im Kontext einer Freigabe aufgerufen werden können.

Replikation

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

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

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

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

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

Bemerkung

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

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

Query Profile

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

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

Die Spalte mit den Sozialversicherungsnummern enthält eine Maskierungsrichtlinie.

EXPLAIN USING JSON SELECT * FROM mydb.public.ssn_record;
Copy
{
  "GlobalStats": {
    "partitionsTotal": 0,
    "partitionsAssigned": 0,
    "bytesAssigned": 0
  },
  "Operations": [
    [
      {
        "id": 0,
        "operation": "Result",
        "expressions": [
          "1",
          "'**MASKED**'"
        ]
      },
      {
        "id": 1,
        "parent": 0,
        "operation": "Generator",
        "expressions": [
          "1"
        ]
      }
    ]
  ]
}
Copy

Daten entladen

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

Verwalten der Sicherheit auf Spaltenebene

Dieser Abschnitt enthält Informationen, die zum Ermitteln des passenden allgemeinen Verwaltungsansatzes für Ihre Maskierungsrichtlinien hilfreich sind. Es werden die Berechtigungen beschrieben, die zum Verwalten der Sicherheit auf Spaltenebene erforderlich sind, und die unterstützten DDL-Befehle aufgelistet.

Auswahl eines zentralen, hybriden oder dezentralen Ansatzes

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

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

Richtlinienaktion

Zentrales Management

Hybrides Management

Dezentrales Management

Richtlinien erstellen

Sicherheitsbeauftragter

Sicherheitsbeauftragter

Einzelne Teams

Richtlinien auf Spalten anwenden

Sicherheitsbeauftragter

Einzelne Teams

Einzelne Teams

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

Berechtigungen für Maskierungsrichtlinien

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

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

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

Berechtigung

Verwendung

CREATE

Ermöglicht das Erstellen einer neuen Maskierungsrichtlinie in einem Schema.

APPLY

Ermöglicht das Ausführen der Aktivierungs-/Deaktivierungsoperation für eine Maskierungsrichtlinie auf einer Spalte.

Beachten Sie, dass durch Erteilen der globalen Berechtigung APPLY MASKING POLICY (d. h. APPLY MASKING POLICY On ACCOUNT) das Ausführen der DESCRIBE-Operation auf Tabellen und Ansichten ermöglicht wird.

Beispiele für die Syntax finden Sie unter Berechtigungen für Maskierungsrichtlinien.

OWNERSHIP

Gewährt volle Kontrolle über die Maskierungsrichtlinie. Erforderlich, um die meisten Eigenschaften einer Maskierungsrichtlinie zu ändern. Diese Berechtigung kann für ein bestimmtes Objekt immer nur einer Rolle erteilt sein.

Bemerkung

Für das Ausführen von Operationen auf einer Maskierungsrichtlinie ist auch die USAGE-Berechtigung für die übergeordnete Datenbank und das übergeordnete Schema erforderlich.

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

Zentrale Verwaltung

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

-- create a security_officer custom role

USE ROLE ACCOUNTADMIN;
CREATE ROLE security_officer;

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

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

GRANT APPLY MASKING POLICY ON ACCOUNT TO ROLE security_officer;
Copy

Wobei:

  • schema_name

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

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

    Weitere Details dazu finden Sie unter Anforderungen an Bezeichner.

Hybride Verwaltung

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

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

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

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

Wobei:

  • grant apply on masking policy policy_name to role role_name;

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

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

Dezentrale Verwaltung

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

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

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

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

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

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

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

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

DDL für Maskierungsrichtlinien

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

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

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

Operation

Berechtigung

Maskierungsrichtlinie erstellen

Eine Rolle mit der Berechtigung CREATE MASKING POLICY on SCHEMA.

Maskierungsrichtlinie ändern

Der Eigentümer der Maskierungsrichtlinie (d. h. die Rolle mit der Berechtigung OWNERSHIP für die Maskierungsrichtlinie).

Maskierungsrichtlinie löschen

Der Eigentümer der Maskierungsrichtlinie (d. h. die Rolle mit der Berechtigung OWNERSHIP für die Maskierungsrichtlinie).

Maskierungsrichtlinien anzeigen

Eine der folgenden Optionen: . Eine Rolle mit der globalen Berechtigung APPLY MASKING POLICY oder . Der Eigentümer der Maskierungsrichtlinie (d. h. die Rolle mit der Berechtigung OWNERSHIP für die Maskierungsrichtlinie) oder . Eine Rolle mit der Berechtigung APPLY für die Maskierungsrichtlinie.

Maskierungsrichtlinie beschreiben

Eine der folgenden Optionen: . Eine Rolle mit der globalen Berechtigung APPLY MASKING POLICY oder . Der Eigentümer der Maskierungsrichtlinie (d. h. die Rolle mit der Berechtigung OWNERSHIP für die Maskierungsrichtlinie) oder . Eine Rolle mit der Berechtigung APPLY für die Maskierungsrichtlinie.

Liste der Spalten mit einer Maskierungsrichtlinie

Eine der folgenden Optionen: . Die Rolle mit den Berechtigungen APPLY MASKING POLICY oder . Die Rolle mit der Berechtigungen APPLY MASKING POLICY für eine bestimmte Maskierungsrichtlinie und Berechtigung OWNERSHIP für das Zielobjekt.

Verwenden von UDFs in einer Maskierungsrichtlinie

Wenn Sie eine neue Maskierungsrichtlinie erstellen oder eine vorhandene Maskierungsrichtlinie ändern, muss die Richtlinienadministratorrolle Nutzungsberechtigung für die UDF haben, alle skalaren UDFs im Richtlinienausdruck müssen denselben Datentyp haben, und die UDF muss vorhanden sein.

Zur Laufzeit der Abfrage prüft Snowflake, ob die UDF vorhanden ist. Wenn nicht, wird der SQL-Ausdruck nicht aufgelöst und die Abfrage schlägt fehl.

Maskierungsrichtlinien mit SQL überwachen

Sie können die Nutzung von Maskierungsrichtlinien über zwei verschiedene Account Usage-Ansichten und eine Information Schema-Tabelle verfolgen.

Es kann hilfreich sein, sich zwei allgemeine Ansätze vorzustellen, um zu bestimmen, wie die Nutzung der Maskierungsrichtlinien überwacht werden soll:

Maskierungsrichtlinien ermitteln

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

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

Zuweisungen identifizieren

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

  • Abfrage auf Kontoebene:

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

    SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.POLICY_REFERENCES
    ORDER BY POLICY_NAME, REF_COLUMN_NAME;
    
    Copy
  • Abfrage auf Datenbankebene:

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

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

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

Maskierungsrichtlinien mit Snowsight überwachen

Sie können den Snowsight-Bereich Data » Governance verwenden, um die Nutzung von Richtlinien und Tags auf Tabellen, Ansichten und Spalten zu überwachen und zu berichten. Es gibt zwei verschiedene Schnittstellen: Dashboard und Tagged Objects.

Bei Verwendung der Dashboard- und der Tagged Objects-Schnittstelle sind die folgenden Details zu beachten.

  • Die Schnittstellen Dashboard und Tagged Objects erfordern ein aktives Warehouse.

  • Snowsight aktualisiert das Dashboard alle 12 Stunden.

  • Die Latenz der Tagged Objects-Informationen kann bis zu zwei Stunden betragen, und die Schnittstelle gibt bis zu 1.000 Objekte zurück.

Zugriff auf den Governance-Bereich in Snowsight

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

  • Sie verwenden die Rolle ACCOUNTADMIN.

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

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

    SHOW GRANTS TO ROLE data_engineer;
    
    Copy

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

Dashboard

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

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

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

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

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

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

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

Getaggte Objekte

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

  • Wählen Sie Tables oder Columns aus.

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

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

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

Tipp

Sie können Snowsight verwenden, um Probleme mit Zuweisungen von Maskierungsrichtlinien zu beheben. Auf der Registerkarte Columns wird in der Spalte MASKING POLICY der Wert Policy Error (Richtlinienfehler) angezeigt, wenn ein Konflikt mit der Zuweisung einer Maskierungsrichtlinie zu der Spalte besteht. Sie können Policy Error auswählen, um weitere Informationen zu erhalten.

Außerdem wird auf der Registerkarte Data Preview keine Datenvorschau angezeigt, wenn ein Fehler bei der Zuweisung einer Maskierungsrichtlinie zu einer Spalte vorliegt. Stattdessen gibt die Registerkarte Data Preview die Fehlermeldung SQL zurück. Diese Meldung entspricht einem der Fehlerwerte in der Spalte POLICY_STATUS der Account Usage-Ansicht POLICY_REFERENCES und der Information Schema-Tabellenfunktion POLICY_REFERENCES.

Um den Fehler zu beheben, verwenden Sie die SQL-Fehlermeldung und die Policy Error-Meldung, um die Tag- oder Richtlinienzuweisung zu ändern.

Weitere Informationen dazu finden Sie unter Tags und Richtlinien untersuchen