Verwenden der dynamischen Datenmaskierung¶

Unter diesem Thema wird eine Anleitung zum Konfigurieren und Verwenden der dynamischen Datenmaskierung in Snowflake bereitgestellt.

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

Verwenden der dynamischen Datenmaskierung¶

Im Folgenden sind die allgemeinen Schritte zum Konfigurieren und Verwenden der dynamischen Datenmaskierung in Snowflake aufgeführt:

Erteilen Sie der kundenspezifischen Rolle eines Sicherheits- oder Datenschutzbeauftragten die Berechtigungen zur Verwaltung von Maskierungsrichtlinien.
Weisen Sie die kundenspezifische Rolle den entsprechenden Benutzern zu.
Der Sicherheits- oder Datenschutzbeauftragte erstellt und definiert Maskierungsrichtlinien und wendet diese auf Spalten mit vertraulichen Daten an.
Führen Sie Abfragen in Snowflake aus. Beachten Sie Folgendes:
- Snowflake schreibt die Abfrage dynamisch neu, indem der SQL-Ausdruck der Maskierungsrichtlinie auf die Spalte angewendet wird.
- Das Umschreiben der Spalte erfolgt an jeder Stelle, an der die in der Maskierungsrichtlinie angegebene Spalte in der Abfrage angezeigt wird (z. B. Projektionen, JOIN-Prädikat, WHERE-Klausel-Prädikat, ORDER BY und GROUP BY).
- Benutzern werden maskierte Daten basierend auf den in den Maskierungsrichtlinien definierten Ausführungskontextbedingungen angezeigt. Weitere Informationen zum Ausführungskontext in Richtlinien zur dynamischen Datenmaskierung finden Sie unter Erweiterte Sicherheit auf Spaltenebene.

Durchsetzen dynamischer Datenmaskierungsrichtlinien für Apache Iceberg-Tabellen, die von Apache Spark™ abgefragt werden¶

Snowflake unterstützt die Durchsetzung dynamischer Datenmaskierungsrichtlinien für Apache Iceberg-Tabellen, die Sie von Apache Spark™ über Snowflake Horizon Catalog abfragen. Weitere Informationen dazu finden Sie unter Durchsetzen von Datenschutzrichtlinien bei der Abfrage von Apache Iceberg™-Tabellen von Apache Spark™.

Schritt 1: Kundenspezifischer Rolle Maskierungsrichtlinienberechtigungen erteilen¶

Ein Sicherheits- oder Datenschutzbeauftragter sollte als Administrator der Maskierungsrichtlinie (d. h. kundenspezifische Rolle: MASKING_ADMIN) fungieren und über Berechtigungen zum Definieren, Verwalten und Anwenden von Maskierungsrichtlinien auf Spalten verfügen.

Snowflake stellt die folgenden Berechtigungen zur Verfügung, die einem Sicherheits- oder Datenschutzbeauftragten erteilt werden können, um Maskierungsrichtlinien für Sicherheit auf Spaltenebene zu verwalten:


Berechtigung	Object	Beschreibung
CREATE MASKING POLICY	Schema	This privilege controls who can create masking policies.
APPLY MASKING POLICY	Account	This privilege controls who can [un]set masking policies on columns and is granted to the ACCOUNTADMIN role by default. . This privilege only allows applying a masking policy to a column and does not provide any additional table privileges described in Zugriffssteuerungsrechte.
APPLY	Masking policy	Optional. Diese Berechtigung auf Richtlinienebene kann von einem Richtlinieneigentümer verwendet werden, um die Operationen zum Festlegen/Aufheben einer bestimmten Maskierungsrichtlinie für bestimmte Spalten an die Objekteigentümer (d. h. der Rolle mit der OWNERSHIP-Berechtigung für das Objekt) zu übergeben. . Snowflake unterstützt die besitzverwaltete Zugriffssteuerung, bei der Objekteigentümer auch als Dateneigentümer gelten. . Wenn der Richtlinienadministrator den Objekteigentümern hinsichtlich der Dateneigentümerschaft für geschützte Spalten vertraut, kann der Richtlinienadministrator diese Berechtigung verwenden, um die Operationen zum Festlegen/Aufheben von Richtlinien zu dezentralisieren.

Im folgenden Beispiel wird die Rolle MASKING_ADMIN erstellt, und dieser Rolle werden Maskierungsrichtlinienberechtigungen erteilt.

Erstellen einer kundenspezifischen Rolle für den Administrator einer Maskierungsrichtlinie:

use role useradmin;
CREATE ROLE masking_admin;

Zuweisen von Berechtigungen zur Rolle masking_admin:

use role securityadmin;
GRANT CREATE MASKING POLICY on SCHEMA <db_name.schema_name> to ROLE masking_admin;
GRANT APPLY MASKING POLICY on ACCOUNT to ROLE masking_admin;

Zulassen des Setzens/Aufhebens der Maskierungsrichtlinie ssn_mask für die Rolle table_owner (optional):

GRANT APPLY ON MASKING POLICY ssn_mask to ROLE table_owner;

Wobei:

db_name.schema_name
Gibt den Bezeichner des Schemas an, dem die Berechtigung erteilt werden soll.

Weitere Informationen dazu finden Sie unter:

Schritt 2: Kundenspezifische Rolle einem Benutzer zuweisen¶

Weisen Sie einem Benutzer, der als Sicherheits- oder Datenschutzbeauftragter fungiert, die kundenspezifische Rolle MASKING_ADMIN zu.

GRANT ROLE masking_admin TO USER jsmith;

Schritt 3: Maskierungsrichtlinie erstellen¶

Erstellen Sie mit der Rolle MASKING_ADMIN eine Maskierungsrichtlinie, und wenden Sie diese auf eine Spalte an.

In diesem typischen Beispiel wird Benutzern mit der Rolle ANALYST der nicht maskierte Wert angezeigt. Benutzern ohne ANALYST-Rolle wird eine vollständige Maske angezeigt.

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

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.

Schritt 4: Maskierungsrichtlinie auf Tabellen- oder Ansichtsspalte anwenden¶

In diesen Beispielen wird davon ausgegangen, dass bei der Erstellung der Tabelle auf die Tabellenspalte und bei der Erstellung der Ansicht auf die Ansichtsspalte keine Maskierungsrichtlinie angewendet wird. Sie können optional eine Maskierungsrichtlinie auf eine Tabellenspalte anwenden, wenn Sie die Tabelle mit einer CREATE TABLE-Anweisung oder eine Ansichtsspalte mit einer CREATE VIEW-Anweisung erstellen.

Führen Sie die folgenden Anweisungen aus, um die Richtlinie auf eine Tabellenspalte oder eine Ansichtsspalte anzuwenden.

-- apply masking policy to a table column

ALTER TABLE IF EXISTS user_info MODIFY COLUMN email SET MASKING POLICY email_mask;

-- apply the masking policy to a view column

ALTER VIEW user_info_v MODIFY COLUMN email SET MASKING POLICY email_mask;

Schritt 5: Daten in Snowflake abfragen¶

Führen Sie in Snowflake zwei verschiedene Abfragen aus, eine Abfrage mit der Rolle ANALYST und eine andere Abfrage mit einer anderen Rolle, um zu überprüfen, ob Benutzern ohne ANALYST-Rolle eine vollständige Maske angezeigt wird.

-- using the ANALYST role

USE ROLE analyst;
SELECT email FROM user_info; -- should see plain text value

-- using the PUBLIC role

USE ROLE PUBLIC;
SELECT email FROM user_info; -- should see full data mask

Maskierungsrichtlinien mit einer memoisierbaren Funktion¶

In diesem Beispiel wird eine memoisierbare Funktion verwendet, um das Ergebnis einer Abfrage auf der Zuordnungstabelle zwischenzuspeichern, mit der ermittelt wird, ob eine Rolle berechtigt ist, PII-Daten einzusehen. Ein Data Engineer verwendet eine Maskierungsrichtlinie, um die Spalten in der Tabelle zu schützen.

Die folgende Prozedur referenziert diese Objekte:

Eine Tabelle employee_data, die PII-Daten enthält:

+----------+-------------+---------------+
| USERNAME |     ID      | PHONE_NUMBER  |
+----------+-------------+---------------+
| JSMITH   | 12-3456-89  | 1555-523-8790 |
| AJONES   | 12-0124-32  | 1555-125-1548 |
+----------+-------------+---------------+

Eine Zuordnungstabelle, die festlegt, ob eine bestimmte Rolle auth_role_t berechtigt ist, Daten einzusehen:

+---------------+---------------+
| ROLE          | IS_AUTHORIZED |
+---------------+---------------+
| DATA_ENGINEER | TRUE          |
| DATA_STEWARD  | TRUE          |
| IT_ADMIN      | TRUE          |
| PUBLIC        | FALSE         |
+---------------+---------------+

Führen Sie diese Schritte aus, um eine Maskierungsrichtlinie zu erstellen, die eine memoisierbare Funktion mit Argumenten aufruft:

Erstellen Sie eine memoisierbare Funktion, die die Zuordnungstabelle abfragt. Die Funktion gibt ein Array von Rollen basierend auf dem Wert der Spalte is_authorized zurück:

CREATE FUNCTION is_role_authorized(arg1 VARCHAR)
RETURNS BOOLEAN
MEMOIZABLE
AS
$$
  SELECT ARRAY_CONTAINS(
    arg1::VARIANT,
    (SELECT ARRAY_AGG(role) FROM auth_role WHERE is_authorized = TRUE)
  )
$$;

Rufen Sie die memoisierbare Funktion auf, um die Abfrageergebnisse zwischenzuspeichern. In diesem Beispiel übergeben Sie den Wert TRUE als Argumentwert, da das resultierende Array als Quelle der zulässigen Rollen für den Zugriff auf die durch die Maskierungsrichtlinie geschützten Daten dient:
```
SELECT is_role_authorized(IT_ADMIN);
```
```
+---------------------------------------------+
|         is_role_authorized(IT_ADMIN)        |
+---------------------------------------------+
|                    TRUE                     |
+---------------------------------------------+
```
Erstellen Sie eine Maskierungsrichtlinie zum Schutz der Spalte id. Die Richtlinie ruft die memoisierbare Funktion auf, um festzustellen, ob die zur Abfrage der Tabelle verwendete Rolle berechtigt ist, die Daten in der geschützten Spalte einzusehen:
```
CREATE OR REPLACE MASKING POLICY empl_id_mem_mask
AS (val VARCHAR) RETURNS VARCHAR ->
CASE
  WHEN is_role_authorized(CURRENT_ROLE()) THEN val
  ELSE NULL
END;
```
Legen Sie die Maskierungsrichtlinie für die Tabelle mit einem ALTER TABLE … ALTER COLUMN-Befehl fest:
```
ALTER TABLE employee_data MODIFY COLUMN id
  SET MASKING POLICY empl_id_mem_mask;
```
Fragen Sie die Tabelle ab, um die Richtlinie zu testen:
```
USE ROLE data_engineer;
SELECT * FROM employee_data;
```
Diese Abfrage gibt nicht maskierte Daten zurück.

Wenn Sie jedoch in die Rolle PUBLIC wechseln und die Abfrage aus diesem Schritt wiederholen, werden die Werte in der Spalte id durch NULL ersetzt.

Weitere Beispiele für Maskierungsrichtlinien¶

Im Folgenden finden Sie weitere typische Beispiele, die im Richtlinientext zur dynamischen Datenmaskierung verwendet werden können.

Erlauben Sie einem Produktions konto, nicht maskierte Werte anzuzeigen, und allen anderen Konten (z. B. Entwicklung, Test), maskierte Werte anzuzeigen.

case
  when current_account() in ('<prod_account_identifier>') then val
  else '*********'
end;

Rückgabe von NULL für nicht autorisierte Benutzer:

case
  when current_role() IN ('ANALYST') then val
  else NULL
end;

Rückgabe eines statischen maskierten Werts für nicht autorisierte Benutzer:

CASE
  WHEN current_role() IN ('ANALYST') THEN val
  ELSE '********'
END;

Rückgabe eines Hashwerts mit SHA2 , SHA2_HEX für nicht autorisierte Benutzer: Die Verwendung einer Hashing-Funktion in einer Maskierungsrichtlinie kann zu Kollisionen führen. Gehen Sie daher mit diesem Ansatz vorsichtig um. Weitere Informationen dazu finden Sie unter Erweiterte Sicherheit auf Spaltenebene.

CASE
  WHEN current_role() IN ('ANALYST') THEN val
  ELSE sha2(val) -- return hash of the column value
END;

Anwenden einer Teil- oder Vollmaske:

CASE
  WHEN current_role() IN ('ANALYST') THEN val
  WHEN current_role() IN ('SUPPORT') THEN regexp_replace(val,'.+\@','*****@') -- leave email domain unmasked
  ELSE '********'
END;

Verwenden von Zeitstempeln.

case
  WHEN current_role() in ('SUPPORT') THEN val
  else date_from_parts(0001, 01, 01)::timestamp_ntz -- returns 0001-01-01 00:00:00.000
end;
Wichtig

Gegenwärtig unterstützt Snowflake keine unterschiedlichen Ein- und Ausgabedatentypen in einer Maskierungsrichtlinie, wie z. B. beim Definieren der Maskierungsrichtlinie, um einen Zeitstempel anzusteuern und eine Zeichenfolge (z. B. ***MASKED***) zurückzugeben. Die Ein- und Ausgabedatentypen müssen übereinstimmen.

Eine Abhilfe besteht darin, den tatsächlichen Zeitstempelwert mithilfe eines generierten Zeitstempelwerts umzuwandeln. Weitere Informationen dazu finden Sie unter DATE_FROM_PARTS und CAST, ::.

Verwenden einer UDF:

CASE
  WHEN current_role() IN ('ANALYST') THEN val
  ELSE mask_udf(val) -- custom masking function
END;

Auf Variant-Daten:

CASE
   WHEN current_role() IN ('ANALYST') THEN val
   ELSE OBJECT_INSERT(val, 'USER_IPADDRESS', '****', true)
END;

Verwenden einer kundenspezifischen Berechtigungstabelle. Beachten Sie die Verwendung von EXISTS in der WHEN-Klausel. Verwenden Sie beim Einfügen einer Unterabfrage in den Maskierungsrichtlinientext immer EXISTS. Weitere Informationen zu Unterabfragen, die Snowflake unterstützt, finden Sie unter Verwenden von Unterabfragen.

CASE
  WHEN EXISTS
    (SELECT role FROM <db>.<schema>.entitlement WHERE mask_method='unmask' AND role = current_role()) THEN val
  ELSE '********'
END;

Verwenden von DECRYPT auf zuvor mit ENCRYPT oder ENCRYPT_RAW verschlüsselte Daten unter Verwendung einer Passphrase für die verschlüsselten Daten:

case
  when current_role() in ('ANALYST') then DECRYPT(val, $passphrase)
  else val -- shows encrypted value
end;

Verwenden einer <JavaScript UDF auf JSON (VARIANT):

In diesem Beispiel maskiert eine JavaScript-UDF die Standortdaten in einer JSON-Zeichenfolge. Es ist wichtig, den Datentyp in der UDF und in der Maskierungsrichtlinie als VARIANT festzulegen. Wenn der Datentyp in Tabellenspalte, UDF und Signatur der Maskierungsrichtlinie nicht übereinstimmen, gibt Snowflake eine Fehlermeldung zurück, da der SQL-Code nicht aufgelöst werden kann.

-- Flatten the JSON data

create or replace table <table_name> (v variant) as
select value::variant
from @<table_name>,
  table(flatten(input => parse_json($1):stationLocation));

-- JavaScript UDF to mask latitude, longitude, and location data

CREATE OR REPLACE FUNCTION full_location_masking(v variant)
  RETURNS variant
  LANGUAGE JAVASCRIPT
  AS
  $$
    if ("latitude" in V) {
      V["latitude"] = "**latitudeMask**";
    }
    if ("longitude" in V) {
      V["longitude"] = "**longitudeMask**";
    }
    if ("location" in V) {
      V["location"] = "**locationMask**";
    }

    return V;
  $$;

  -- Grant UDF usage to ACCOUNTADMIN

  grant ownership on function FULL_LOCATION_MASKING(variant) to role accountadmin;

  -- Create a masking policy using JavaScript UDF

  create or replace masking policy json_location_mask as (val variant) returns variant ->
    CASE
      WHEN current_role() IN ('ANALYST') THEN val
      else full_location_masking(val)
      -- else object_insert(val, 'latitude', '**locationMask**', true) -- limited to one value at a time
    END;

Verwendung des Datentyps GEOGRAPHY:

In diesem Beispiel verwendet eine Maskierungsrichtlinie die Funktion TO_GEOGRAPHY, um für Benutzer, deren CURRENT_ROLE nicht ANALYST ist, alle GEOGRAPHY-Daten einer Spalte in einen festen Punkt zu konvertieren: den Längen- und Breitengrad für Snowflake in San Mateo, Kalifornien, USA.
create masking policy mask_geo_point as (val geography) returns geography ->
  case
    when current_role() IN ('ANALYST') then val
    else to_geography('POINT(-122.35 37.55)')
  end;
Legen Sie die Maskierungsrichtlinie für eine Spalte mit dem Datentyp GEOGRAPHY fest, und setzen Sie den Wert GEOGRAPHY_OUTPUT_FORMAT für die Sitzung auf GeoJSON:
alter table mydb.myschema.geography modify column b set masking policy mask_geo_point;
alter session set geography_output_format = 'GeoJSON';
use role public;
select * from mydb.myschema.geography;
Snowflake gibt Folgendes zurück:
---+--------------------+
 A |         B          |
---+--------------------+
 1 | {                  |
   |   "coordinates": [ |
   |     -122.35,       |
   |     37.55          |
   |   ],               |
   |   "type": "Point"  |
   | }                  |
 2 | {                  |
   |   "coordinates": [ |
   |     -122.35,       |
   |     37.55          |
   |   ],               |
   |   "type": "Point"  |
   | }                  |
---+--------------------+
Die Werte der Abfrageergebnisse in Spalte B hängen vom Wert des Parameters GEOGRAPHY_OUTPUT_FORMAT der Sitzung ab. Wenn der Parameterwert beispielsweise auf WKT gesetzt ist, gibt Snowflake Folgendes zurück:
alter session set geography_output_format = 'WKT';
select * from mydb.myschema.geography;

---+----------------------+
 A |         B            |
---+----------------------+
 1 | POINT(-122.35 37.55) |
 2 | POINT(-122.35 37.55) |
---+----------------------+

Beispiele für die Verwendung anderer Kontextfunktionen und Rollenhierarchien finden Sie unter Erweiterte Sicherheit auf Spaltenebene.

Nächste Themen:

Erweiterte Sicherheit auf Spaltenebene