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?

Sicherheitsfunktionen auf Spaltenebene erlauben die Anwendung von Maskierungsrichtlinien auf Spalten einer Tabelle oder Ansicht zum Schutz der darin gespeicherten Daten. Derzeit stehen für die Sicherheit auf Spaltenebene zwei Funktionen zur Verfügung:

  1. Dynamische Datenmaskierung

  2. Externe Tokenisierung

Die dynamische Datenmaskierung ist eine Sicherheitsfunktion 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. Datenfreigaben 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.

Der Maskierungsrichtlinienadministrator kann Objektbesitzern oder anderen Rollen Berechtigungen zum Ausführen dieser Aktionen erteilen.

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.

  • ->

    Ersetzen Sie den Pfeil in der Anweisung zur Maskierungsrichtlinie nicht durch andere Zeichen.

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

Weitere Informationen zur Verwendung von Maskierungsrichtlinien finden Sie unter:

Maskierungsrichtlinien zur Laufzeit von Abfragen

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:

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

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

  • Wenn verschachtelte Ansichten vorhanden sind (z. B. Tabelle 1 -> Ansicht 1 -> Ansicht 2 -> … Ansicht n), werden die Richtlinien nacheinander 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.

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.

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_Ausdruck>) nur für die Spalte email gilt.

Einfache Abfrage:

SELECT email, city from customers where city = 'San Mateo';

SELECT <SQL_expression>(email), city from customers where city = 'San Mateo';

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

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

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.

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

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

Nicht der Objektbesitzer, sondern ein Sicherheits- oder Datenschutzbeauftragter entscheidet, welche Spalten geschützt werden sollen. . Maskierungsrichtlinien sind einfach zu verwalten und unterstützen zentrale und dezentrale 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.

Bei der dynamischen Datenmaskierung können Sie als Data Sharing-Verbraucher keine Maskierungsrichtlinie auf eine freigegebene Datenbank oder Tabelle anwenden. . Importieren Sie zur Umgehung dieses Problems die freigegebene Datenbank oder Tabelle, und wenden Sie die Maskierungsrichtlinie auf eine lokale Ansicht dieser freigegebenen Datenbank oder Tabelle an. . Bei der externe Tokenisierung kann Secure Data Sharing nicht angewendet werden, da externe Funktionen im Kontext einer Freigabe nicht aufgerufen werden können.

Materialisierte Ansichten (MV).

Die folgenden Aktionen werden nicht unterstützt: Zuordnen einer Maskierungsrichtlinie zu einer MV-Spalte, Erstellen einer MV aus einer Tabelle, die eine Maskierungsrichtlinie für eine oder mehrere ihrer Spalten enthält, und Zuordnen einer Maskierungsrichtlinie zu einer Tabellenspalte, falls eine MV in dieser Tabelle vorhanden ist.

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

Erfordert, dass die Maskierungsrichtlinie und deren Zuordnungen in einer Datenbank und einem Schema eigenständig sind. . Beispiel: database_1 enthält 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.

Mehrere Spalten in einer einzigen Anweisung.

Nur eine Spalte pro ALTER TABLE- oder ALTER VIEW-Anweisung. Führen Sie eine einzelne ALTER-Anweisung für eine Spalte aus, um eine Maskierungsrichtlinie für Sicherheit auf Spaltenebene festzulegen oder zu deaktivieren.

Änderungsmanagement für Maskierungsrichtlinien.

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

Microsoft Azure-Cloudplattform

Die Unterstützung der externen Tokenisierung auf der Microsoft Azure-Cloudplattform ist geplant.

Google Cloud Platform

Die Unterstützung von Konten auf Google Cloud Platform ist geplant.

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.

Maskierungsrichtlinien auf Spalten anwenden

Führen Sie die folgenden Anweisungen aus, um Richtlinien für Maskierungsrichtlinien auf Spalten in Tabellen oder Ansichten anzuwenden:

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

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.

Externe Tabellen

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

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

Sie können die Maskierungsrichtlinie nicht direkt auf eine virtuelle Spalte anwenden. Erstellen Sie stattdessen eine Ansicht für die externe Tabelle, und wenden Sie eine Maskierungsrichtlinie auf die Spalten in der Ansicht an.

Streams

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

Das Ergebnis ist, dass nicht autorisierten Benutzern maskierte Daten angezeigt werden. Die Daten in von autorisierten Benutzern erstellten Streams werden wie in der Maskierungsrichtlinie angezeigt.

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

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 Sicherheit auf Spaltenebene

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

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

Berechtigung

Verwendung

APPLY

Aktiviert das Anwenden von Operationen zum Festlegen/Aufheben der Maskierungsrichtlinie.

OWNERSHIP

Überträgt die Eigentümerschaft an einer Maskierungsrichtlinie, wodurch die vollständige Kontrolle über die Maskierungsrichtlinie gewährt wird. Erforderlich, um die meisten Eigenschaften einer Maskierungsrichtlinie zu ändern.

Bemerkung

Das Durchführen von Operationen auf einer Maskierungsrichtlinie erfordert auch die USAGE-Berechtigung für die übergeordnete Datenbank und das übergeordnete Schema.

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 Sicherheit auf Spaltenebene

Snowflake bietet die folgenden Befehle zum Verwalten von Sicherheitsrichtlinien auf Spaltenebene.

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

Operation

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

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

Maskierungsrichtlinie auf Spalten anwenden/aussetzen (SET/UNSET)

Entweder: . Eine Rolle mit der globalen Berechtigung APPLY MASKING POLICY oder . Eine Rolle mit der Berechtigung APPLY on MASKING POLICY für eine bestimmte Maskierungsrichtlinie und Berechtigung OWNERSHIP für die Zieltabelle/-ansicht.

Liste der Spalten mit Maskierungsrichtlinie

Eine der folgenden Optionen: . Die Rolle mit den Berechtigungen APPLY MASKING POLICY oder . Die Rolle mit der Berechtigungen APPLY on 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 überprü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: