Grundlegendes zur Sicherheit auf Spaltenebene

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

Was ist Sicherheit auf Spaltenebene?

Die Funktion Sicherheit auf Spaltenebene in Snowflake 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 Funktionen zur Verfügung:

  1. Dynamische Datenmaskierung

  2. Externe Tokenisierung

Die dynamische Datenmaskierung ist eine Funktion für Sicherheit auf Spaltenebene, die 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 benutzerdefinierten ANALYST-Rolle) nur die letzten vier Ziffern einer Telefonnummer und keine Sozialversicherungsnummern angezeigt werden, während Vertretern des Kundensupports (d. h. Benutzer mit der benutzerdefinierten SUPPORT-Rolle) 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 und einer oder mehreren Maskierungsfunktionen.

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

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

  • Maskierungsfunktionen können beliebige integrierte Funktionen (z. B. REGEXP_REPLACE, SHA2 , SHA2_HEX), UDFs (Benutzerdefinierte Funktionen) oder Externe Funktionen (zum Detokenisieren mithilfe eines externen Tokenisierungsanbieters) sein.

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

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

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

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

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

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

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 benutzerdefinierte 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:

Verwenden bedingter Spalten

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

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

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 benutzerdefinierte 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:

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

  • Unterabfragen. Weitere Details dazu finden Sie in der Zeile, in der Unterabfragen in der Einschränkungstabelle angegeben wird (unter diesem Thema).

  • 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 Anwenden einer bedingten Maskierungsrichtlinie auf eine Spalte (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';

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

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

Überlegungen 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:

Die aktuelle Sitzung

Maskierungsrichtlinienbedingungen mit CURRENT_ROLE.

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 Snowflake Secure Data Sharing freigegeben werden. Siehe Einschränkungen (unter diesem Thema).

Replikation

Siehe Replizierte Datenbankobjekte.

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

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 die Funktion auszuwählen, die 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 Funktionen 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.

Externe Funktionen können nicht für Datenfreigaben verwendet werden, daher keine externe Tokenisierung.

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

Siehe Replizierte Datenbankobjekte.

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 die Funktion an.

Einschränkungen

Dynamische Datenmaskierung

Externe Tokenisierung

Anmerkungen

Freigegebene Objekte.

Wenn bei der dynamischen Datenmaskierung die Maskierungsrichtlinie für eine Tabellen- oder Ansichtsspalte auf eine externe Funktion verweist, kann die Tabelle oder die Ansicht nicht freigegeben werden. . Für die externe Tokenisierung ist Secure Data Sharing nicht anwendbar, da externe Funktionen im Kontext einer Freigabe nicht aufgerufen werden können.

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

Ein Data Sharing-Verbraucher kann keine Maskierungsrichtlinie auf freigegebene Datenbanken oder Tabellen anwenden. Importieren Sie zur Umgehung des Problems die freigegebene Datenbank oder Tabelle, und wenden Sie die Maskierungsrichtlinie auf eine lokale Ansicht dieser freigegebenen Tabellenspalte an.

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.

Virtuelle Spalten.

Maskierungsrichtlinien können nicht auf virtuelle Spalten angewendet werden. Wenden Sie die Richtlinie auf die Spalte der Quelltabelle oder die Ansichtsspalte an.

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

Zukünftige Zuweisungen von Berechtigungen zu Maskierungsrichtlinien werden nicht unterstützt.

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

Unterabfragen.

Eine Unterabfrage im Richtlinientext, die eine Spalte aus einer anderen Tabelle oder Ansicht verknüpft, wird nicht unterstützt.

Bestimmte Unterabfragen mit bedingten Maskierungsrichtlinien können zu Fehlern führen. Zwei typische Beispiele sind:

  • Maskieren oder Tokenisieren einer Spalte in einer Tabelle auf Basis des Spaltenwerts in einer anderen Tabelle oder Ansicht (d. h. Zuordnungstabelle).

  • Maskieren oder Tokenisieren einer Spalte in einer Tabelle auf Basis der Verknüpfung einer zweiten Spalte mit einer anderen Spalte in einer anderen Tabelle oder Ansicht.

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.

Maskierungsrichtlinien auf Spalten anwenden

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

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;

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

Anwenden einer bedingten Maskierungsrichtlinie auf eine Spalte

Nach der Erstellung einer Maskierungsrichtlinie mit bedingten Spalten gibt es zwei Möglichkeiten, eine bedingte Maskierungsrichtlinie für eine Spalte festzulegen:

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

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.

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;

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 Tabelle oder Ansicht festgelegt werden, wenn bereits eine materialisierte Ansicht aus der zugrunde liegenden Tabelle oder Ansicht 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>.
    
  2. Wenn eine Maskierungsrichtlinie für eine zugrunde liegende Tabellen- oder Ansichtsspalte festgelegt ist und eine materialisierte Ansicht aus dieser Tabelle oder Ansicht 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'.
    

Spalten mit einer Maskierungsrichtlinie erhalten

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

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

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 eine Maskierungsrichtlinie nicht auf die Spalte VALUE der externen Tabelle anwenden, wenn Sie die externe Tabelle mit einer CREATE EXTERNAL TABLE-Anweisung erstellen, da diese Spalte standardmäßig automatisch erstellt wird.

Sie können die Maskierungsrichtlinie auf die Spalte VALUE der externen Tabelle anwenden, indem Sie eine ALTER TABLE … ALTER COLUMN-Anweisung für die externe Tabelle ausführen.

ALTER TABLE <name> MODIFY COLUMN VALUE SET MASKING POLICY <policy_name> ;

Eine Richtlinie kann für keine andere Spalte der externen Tabelle festgelegt werden, auch nicht für vom Benutzer hinzugefügte virtuelle Spalten. Wenn diese Spalten geschützt werden müssen, erstellen Sie eine Ansicht auf der externen Tabelle, und wenden Sie eine Richtlinie auf die Ansichtsspalte an.

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 beim Zugriff auf ein geklontes Objekt zu schützen.

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

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

  • Einer geklonten Tabelle sind dieselben Maskierungsrichtlinien zugeordnet wie der Quelltabelle.

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

    • Wenn die Quelltabelle auf eine Maskierungsrichtlinie 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 benutzerdefinierten 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;
    
  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;
    
  4. Führen Sie eine Abfrage auf der Ansichtsspalte aus.

    use role ANALYST;
    select count(DISTINCT SSN) from <view>;
    

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.

Maskierungsrichtlinien mit freigegebenen Tabellen und Ansichten

Snowflake ermöglicht es Data Sharing-Anbietern und -Verbrauchern, Maskierungsrichtlinien zu Datenbankobjekten hinzuzufügen. Snowflake gibt einen Fehler zurück, wenn einer der folgenden Punkte zutrifft:

  • Die einer freigegebenen Tabellen- oder Ansichtsspalte zugewiesene Richtlinie wird mit einer ALTER MASKING POLICY-Anweisung aktualisiert, um eine externe Funktion aufzurufen.

  • Die Richtlinie ruft eine externe Funktion auf, und Sie versuchen, die Richtlinie einer freigegebenen Tabellenspalte mit der ALTER TABLE … ALTER COLUMN-Anweisung oder einer Ansichtsspalte mit der ALTER VIEW-Anweisung zuzuweisen.

Wenn die einer freigegebenen Tabelle oder Ansicht zugewiesene Maskierungsrichtlinie die Funktion CURRENT_ROLE oder CURRENT_USER aufruft oder eine sichere UDF aufruft, gibt Snowflake einen NULL-Wert für die Funktion oder die UDF 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 der Richtlinie die Funktion CURRENT_ACCOUNT verwenden.

Weitere Informationen zu Data Sharing und Maskierungsrichtlinien finden Sie in den Abschnitten Einschränkungen (unter diesem Thema).

Query Profile

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

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

Die Spalte mit den Sozialversicherungsnummern enthält eine Maskierungsrichtlinie.

explain using json select * from mydb.public.ssn_record;
{
  "GlobalStats": {
    "partitionsTotal": 0,
    "partitionsAssigned": 0,
    "bytesAssigned": 0
  },
  "Operations": [
    [
      {
        "id": 0,
        "operation": "Result",
        "expressions": [
          "1",
          "'**MASKED**'"
        ]
      },
      {
        "id": 1,
        "parent": 0,
        "operation": "Generator",
        "expressions": [
          "1"
        ]
      }
    ]
  ]
}

Entladen von Daten

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.

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 benutzerdefinierte 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 <schema_name> to role security_officer;

grant apply masking policy on account to role security_officer;

Wobei:

  • Schemaname

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

-- create a SECURITY_OFFICER custom role

use role accountadmin;
create role security_officer;

-- grant the CREATE masking policy privilege to the SECURITY_OFFICER role.

grant create masking policy on schema <schema_name> to role security_officer;

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

grant apply on masking policy ssn_mask to role human_resources;

Wobei:

  • grant apply on masking policy Name_der_Berechtigung to role Name_der_Rolle;

    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 benutzerdefinierten Rolle SUPPORT) und die Finanzabteilung (d. h. Benutzer mit der benutzerdefinierten Rolle FINANCE) Maskierungsrichtlinien erstellen. Beachten Sie, dass diese benutzerdefinierten Rollen möglicherweise nicht die benutzerdefinierte Rolle SECURITY_OFFICER enthalten.

use role accountadmin;

-- grant masking policy privileges to the SUPPORT custom role.

grant create masking policy on schema <schema_name> to role support;

-- grant masking policy privileges to the FINANCE custom role.

grant create masking policy on schema <schema_name> to role finance;

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

use role support;
grant apply on masking policy ssn_mask to role human_resources;

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

use role finance;
grant apply on masking policy cash_flow_mask to role audit_internal;

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.

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 . Eigentümer der Maskierungsrichtlinie (d. h. die Rolle mit der Berechtigung OWNERSHIP für die Maskierungsrichtlinie).

Maskierungsrichtlinien beschreiben

Eine der folgenden Optionen: . Eine Rolle mit der globalen Berechtigung APPLY MASKING POLICY oder . Eigentümer der Maskierungsrichtlinie (d. h. die Rolle mit der Berechtigung OWNERSHIP 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.

Nächste Themen: