Projektionsrichtlinien¶

Spaltennutzung¶

Snowflake verfolgt die Nutzung von Spalten. Indirekte Referenzen auf eine Spalte, wie z. B. eine Ansichtsdefinition, eine UDF (unter diesem Thema) oder ein allgemeiner Tabellenausdruck, wirken sich auf die Spaltenprojektion aus, wenn eine Projektionsrichtlinie für eine Spalte festgelegt ist.

Wenn eine Projektionsrichtlinie für die Spalte festgelegt ist und die Spalte nicht projiziert werden kann, gilt Folgendes:

• Die Spalte kann nicht in der Ausgabe eines Abfrageergebnisses enthalten sein.

• Die Spalte kann nicht in eine andere Tabelle eingefügt werden.

• Die Spalte kann nicht als Argument für eine externe Funktion oder gespeicherte Prozedur verwendet werden.

Einschränkungen¶

• Weitere Informationen zu Einschränkungen bei benutzerdefinierten Funktionen (UDFs) finden Sie unter Benutzerdefinierte Funktionen (UDFs) (unter diesem Thema).

• Eine Projektionsrichtlinie kann nicht auf Folgendes angewendet werden:

  • Ein einer Tabelle oder Spalte zugewiesenes Tag (d. h. eine Tag-basierte Projektionsrichtlinie).

  • Eine virtuelle Spalte oder die Spalte VALUE in einer externen Tabelle. Als Problemumgehung können Sie eine Ansicht erstellen und jeder Spalte, die nicht projiziert werden soll, eine Projektionsrichtlinie zuweisen.

  • Die Spalte value_column in einem PIVOT-Konstrukt. Weitere Informationen dazu finden Sie unter UNPIVOT (unter diesem Thema):

• Der body einer Projektionsrichtlinie kann nicht auf eine durch eine Maskierungsrichtlinie geschützte Spalte oder eine durch eine Zeilenzugriffsrichtlinie geschützte Tabelle verweisen. Weitere Informationen dazu finden Sie unter Richtlinien für Maskierung und Zeilenzugriff (unter diesem Thema).

Hinweise¶

Verwenden Sie Projektionsrichtlinien, wenn im Anwendungsfall die Abfrage einer sensiblen Spalte erforderlich ist, aber der Spaltenwert einem Analysten oder einer ähnlichen Rolle nicht direkt zugänglich sein darf. Der Spaltenwert innerhalb einer Spalte mit Projektionseinschränkung kann mit größerer Flexibilität analysiert werden als ein maskierter oder tokenisierter Wert. Bevor Sie jedoch eine Projektionsrichtlinie für eine Spalte festlegen, müssen Sie Folgendes beachten:

• Eine Projektionsrichtlinie verhindert nicht, dass eine Person gezielt anvisiert werden kann.

  So kann ein Benutzer beispielsweise Zeilen filtern, in denen die Spalte name einer bestimmten Person entspricht, selbst wenn die Spalte eine Projektionseinschränkung aufweist. Der Benutzer kann jedoch keine SELECT-Anweisung ausführen, um die Namen der Personen in der Tabelle anzuzeigen.

• Wenn eine Spalte mit Projektionseinschränkung der Verknüpfungsschlüssel für eine Abfrage ist, bei der Daten aus der geschützten Tabelle mit Daten aus einer ungeschützten Tabelle kombiniert werden, hindert nichts den Benutzer daran, Werte aus der Spalte in der ungeschützten Tabelle zu projizieren. Wenn also ein Wert in der ungeschützten Tabelle mit einem Wert in der geschützten Spalte übereinstimmt, kann der Benutzer diesen Wert erhalten, indem er ihn aus der ungeschützten Tabelle projiziert.

  Angenommen, der Spalte email der Tabelle t_protected wurde eine Projektionsrichtlinie zugewiesen. Ein Benutzer kann immer noch Werte in der Spalte t_protected.email ermitteln, indem Folgendes ausgeführt wird:

  SELECT t_unprotected.email
    FROM t_unprotected JOIN t_protected ON t_unprotected.email = t_protected.email;
  

  Copy

• Eine Projektionseinschränkung garantiert nicht, dass ein böswilliger Akteur nicht absichtliche Abfragen verwenden könnte, um potenziell sensible Daten aus einer projektionseingeschränkten Spalte zu erhalten. Projektionsrichtlinien eignen sich am besten für Partner und Kunden, zu denen Sie bereits ein gewisses Vertrauen aufgebaut haben. Darüber hinaus sollten Anbieter auf einen möglichen Missbrauch ihrer Daten achten (z. B. indem sie den Zugriffsverlauf auf ihre Freigabeangebote überprüfen).

• Aus all diesen Gründen sollten Sie, wenn Sie die Weitergabe von Informationen über eine bestimmte Spalte oder Entität verhindern müssen, die Spalte vollständig aus Ihren Daten weglassen oder differentielle Privatsphäre verwenden.

Beispiele für Richtlinien¶

Die einfachsten Projektionsrichtlinien rufen die Funktion PROJECTION_CONSTRAINT direkt auf:

Spaltenprojektion zulassen

CREATE OR REPLACE PROJECTION POLICY mypolicy
AS () RETURNS PROJECTION_CONSTRAINT ->
PROJECTION_CONSTRAINT(ALLOW => true)

Copy

Spaltenprojektion verhindern

CREATE OR REPLACE PROJECTION POLICY mypolicy
AS () RETURNS PROJECTION_CONSTRAINT ->
PROJECTION_CONSTRAINT(ALLOW => false)

Copy

Kompliziertere SQL-Ausdrücke können geschrieben werden, um die PROJECTION_CONSTRAINT-Funktion aufzurufen. Der Ausdruck kann Funktionen für bedingte Ausdrücke und Kontextfunktionen verwenden, um eine Logik einzuführen, die es bestimmten Benutzern mit einer bestimmten Rolle erlaubt, eine Spalte zu projizieren, und alle anderen Benutzer daran hindert, eine Spalte zu projizieren.

Tipp

Bei der Verwendung von Kontextfunktionen in einer bedingten Richtlinie können Sie die folgenden Strategien anwenden:

• Kontextfunktionen geben Zeichenfolgen zurück, sodass bei Vergleichen mit diesen Funktionen die Groß-/Kleinschreibung beachtet wird. Sie können LOWER verwenden, um Zeichenfolgen in Kleinbuchstaben umzuwandeln, wenn Sie einen Vergleich ohne Berücksichtigung der Groß-/Kleinschreibung durchführen möchten.

• Die Funktion POLICY_CONTEXT hilft Ihnen zu beurteilen, ob ein Richtlinientext den korrekten Wert zurückgibt, wenn eine Kontextfunktion einen bestimmten Wert zurückgibt. Die Funktion POLICY_CONTEXT simuliert Abfrageergebnisse, die auf einem bestimmten Wert einer oder mehrerer Kontextfunktionen basieren.

Das folgende Beispiel enthält einen CASE-Ausdruck und eine CURRENT_ROLE-Kontextfunktion, um eine bedingte Richtlinie zu erstellen, die es nur Benutzern mit der benutzerdefinierten Rolle analyst erlaubt, eine Spalte zu projizieren:

CREATE OR REPLACE PROJECTION POLICY mypolicy
AS () RETURNS PROJECTION_CONSTRAINT ->
CASE
  WHEN CURRENT_ROLE() = 'ANALYST'
    THEN PROJECTION_CONSTRAINT(ALLOW => true)
  ELSE PROJECTION_CONSTRAINT(ALLOW => false)
END;

Copy

Das folgende Beispiel verwendet die Funktion SYSTEM$GET_TAG_ON_CURRENT_COLUMN, sodass ein Tag, das einer Spalte zugewiesen ist, bestimmt, ob die Spalte projiziert werden kann. Wenn in diesem Fall die Richtlinie einer Spalte zugewiesen ist, muss der Wert des tags.accounting_col-Tags auf dieser Spalte public sein, um die Spalte zu projizieren.

CREATE PROJECTION POLICY mypolicy
AS () RETURNS PROJECTION_CONSTRAINT ->
CASE
  WHEN SYSTEM$GET_TAG_ON_CURRENT_COLUMN('tags.accounting_col') = 'public'
    THEN PROJECTION_CONSTRAINT(ALLOW => true)
  ELSE PROJECTION_CONSTRAINT(ALLOW => false)
END;

Bei Data Sharing-Anwendungsfällen kann der Anbieter eine Projektionsrichtlinie schreiben, um die Spaltenprojektion für alle Verbraucherkonten mit der Kontextfunktion CURRENT_ACCOUNT einzuschränken oder um die Spaltenprojektion in bestimmten Freigaben mit der Kontextfunktion INVOKER_SHARE selektiv einzuschränken. Beispiel:

Alle Verbraucherkonten einschränken

In diesem Beispiel ist provider.account der Kontobezeichner im Kontonamensformat:

CREATE OR REPLACE PROJECTION POLICY restrict_consumer_accounts
AS () RETURNS PROJECTION_CONSTRAINT ->
CASE
  WHEN CURRENT_ACCOUNT() = 'provider.account'
    THEN PROJECTION_CONSTRAINT(ALLOW => true)
  ELSE PROJECTION_CONSTRAINT(ALLOW => false)
END;

Copy

Bestimmte Freigaben einschränken

Angenommen, bei einem Data Sharing-Anbieterkonto ist auf einer Spalte einer sicheren Ansicht eine Projektionsrichtlinie festgelegt. Es gibt zwei verschiedene Freigaben (SHARE1 und SHARE2), die auf die sichere Ansicht zugreifen können, um zwei verschiedene Data Sharing-Verbraucher zu unterstützen.

Wenn ein Benutzer im Data Sharing-Verbraucherkonto versucht, die Spalte über eine der beiden Freigaben zu projizieren, dann kann die Spalte projiziert werden, bei anderen Freigaben kann die Spalte nicht projiziert werden:

CREATE OR REPLACE PROJECTION POLICY projection_share
AS () RETURNS PROJECTION_CONSTRAINT ->
CASE
  WHEN INVOKER_SHARE() IN ('SHARE1', 'SHARE2')
    THEN PROJECTION_CONSTRAINT(ALLOW => true)
  ELSE PROJECTION_CONSTRAINT(ALLOW => false)
END;

Copy

Abfrage einer separaten Tabelle zur Bestimmung der Projektionsrichtlinie

Sie können eine SELECT-Abfrage in Ihrer Richtlinienlogik verwenden, um zu bestimmen, ob die Projektion erlaubt oder blockiert werden soll. Wenn Sie eine Tabelle (eine Zuordnungstabelle) auf diese Weise abfragen, empfehlen wir, die Zuordnungstabelle in derselben Datenbank wie die geschützte Tabelle abzulegen. Dies ist besonders wichtig, wenn der body Abschnitt IS_DATABASE_ROLE_IN_SESSION aufruft.

Hier ein erweitertes Beispiel für die Erstellung und Befüllung einer einfachen Zuordnungstabelle von Rollennamen und Projektionsberechtigung und die anschließende Abfrage dieser Tabelle, um festzustellen, ob eine Spalte auf den aktuellen Benutzer entsprechend seiner Rolle projiziert werden kann.

-- Create mapping table with two columns: role name, whether that role can project the column
CREATE OR REPLACE TABLE roles_with_access(role string, allowed boolean)
AS SELECT * FROM VALUES ('ACCOUNTADMIN', true), ('RANDOM_ROLE', false);

-- Create a policy that queries the mapping table, and allows projection when current
-- user role has an `allowed` value of TRUE.
-- Note that the logic is written to default to FALSE in all other cases, including the
-- current role not being in the queried table.
CREATE OR REPLACE PROJECTION POLICY pp AS () RETURNS projection_constraint ->
  CASE WHEN
    exists(
      SELECT 1 FROM roles_with_access WHERE role = current_role() AND allowed = true
    ) THEN projection_constraint(ALLOW=>true)
  ELSE projection_constraint(ALLOW=>false) END;

-- Create a new table with the policy and query it in one step.
CREATE OR REPLACE TABLE t(user string, address string WITH PROJECTION POLICY pp)
  AS SELECT * FROM VALUES ('Carson', 'CA'), ('Emily', 'NY'), ('John', 'NV');

-- Succeeds
USE ROLE ACCOUNTADMIN;
SELECT * FROM t;

-- Fails with projection policy error on column ADDRESS
USE ROLE any_other_role;
SELECT * FROM t;

Copy

Projektionsrichtlinie ersetzen¶

Die empfohlene Methode zum Ersetzen einer Projektionsrichtlinie ist die Verwendung des Parameters FORCE, um mit einem Befehl die bestehende Projektionsrichtlinie abzutrennen und die neue Projektionsrichtlinie zuzuweisen. So können Sie die alte Richtlinie atomar ersetzen, ohne dass eine Sicherheitslücke entsteht.

So können Sie beispielsweise einer Spalte, die bereits eine Projektionseinschränkung aufweist, eine neue Projektionsrichtlinie zuweisen:

ALTER TABLE finance.accounting.customers
  MODIFY COLUMN account_number
  SET PROJECTION POLICY proj_policy2 FORCE;

Sie können die Projektionsrichtlinie für eine Tabellenspalte auch mit einer Anweisung (… UNSET PROJECTION POLICY) aufheben und dann mit einer anderen Anweisung (… SET PROJECTION POLICY <name>) eine neue Richtlinie für die Spalte festlegen: Wenn Sie sich für diese Methode entscheiden, ist die Spalte zwischen dem Trennen der einen Richtlinie und dem Zuweisen der anderen Richtlinie nicht durch eine Projektionsrichtlinie geschützt. Wird in dieser Zeit eine Abfrage ausgeführt, könnte sie möglicherweise auf sensible Daten zugreifen.

Projektionsrichtlinien ermitteln¶

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

SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.PROJECTION_POLICIES
ORDER BY POLICY_NAME;

Copy

Referenzen von Projektionsrichtlinien erkennen¶

Die Information Schema-Tabellenfunktion POLICY_REFERENCES kann Referenzen von Projektionsrichtlinien identifizieren. Es gibt zwei verschiedene Syntaxoptionen:

1. Rückgabe einer Zeile für jedes Objekt (d. h. Tabelle oder Ansicht), bei dem die angegebene Projektionsrichtlinie auf eine Spalte gesetzt wurde:

   USE DATABASE my_db;
   SELECT policy_name,
          policy_kind,
          ref_entity_name,
          ref_entity_domain,
          ref_column_name,
          ref_arg_column_names,
          policy_status
   FROM TABLE(information_schema.policy_references(policy_name => 'my_db.my_schema.projpolicy'));
   

   Copy

2. Rückgabe einer Zeile für jede Richtlinie, die der Tabelle my_table zugewiesene ist:

   USE DATABASE my_db;
   USE SCHEMA information_schema;
   SELECT policy_name,
          policy_kind,
          ref_entity_name,
          ref_entity_domain,
          ref_column_name,
          ref_arg_column_names,
          policy_status
   FROM TABLE(information_schema.policy_references(ref_entity_name => 'my_db.my_schema.my_table', ref_entity_domain => 'table'));
   

   Copy

Richtlinien für Maskierung und Zeilenzugriff¶

In diesem Abschnitt wird beschrieben, wie eine Projektionsrichtlinie mit einer Maskierungsrichtlinie und einer Zeilenzugriffsrichtlinie interagiert.

Mehrere Richtlinien:

Einer Spalte können gleichzeitig eine Maskierungsrichtlinie und eine Projektionsrichtlinie zugewiesen sein, und die Tabelle, die diese Spalte enthält, kann durch eine Zeilenzugriffsrichtlinie geschützt sein. Wenn alle drei Richtlinien vorhanden sind, verarbeitet Snowflake die Tabelle und die Richtlinien wie folgt:

1. Zeilenfilter werden gemäß der Zeilenzugriffsrichtlinie angewendet.

2. Es wird ermittelt, ob die Abfrage versucht, Spalten zu projizieren, die durch die Projektionsrichtlinie eingeschränkt sind, und wenn ja, wird die Abfrage zurückgewiesen.

3. Spaltenmasken werden gemäß der Maskierungsrichtlinie angewendet.

Eine Spalte, die durch eine Maskierungsrichtlinie geschützt ist, kann auch eine Projektionseinschränkung aufweisen. Beispielsweise kann eine Maskierungsrichtlinie, die auf einer Spalte mit Kontonummern festgelegt ist, eine Bedingung enthalten, die es Benutzern mit der benutzerdefinierten Rolle finance_admin erlaubt, die Kontonummern zu sehen, und eine andere Bedingung, die die Kontonummern für alle anderen Rollen durch einen Hash ersetzt.

Eine Projektionsrichtlinie kann die Spalte weiter einschränken, sodass Benutzer mit der kundenspezifischen Rolle analyst die Spalte nicht projizieren können. Beachten Sie, dass Benutzer mit der benutzerdefinierten Rolle analyst die Spalte immer noch analysieren können, indem sie Hashes gruppieren oder eine Verknüpfung (Join) über diese Hashes vornehmen.

Snowflake empfiehlt, dass Richtlinienadministratoren mit internen Compliance- und Regulierungsbeauftragten zusammenarbeiten, um die Spalten zu bestimmen, für die Projektionseinschränkungen gelten sollen.

Evaluation von Richtlinien:

Eine Spalte mit Projektionseinschränkung kann in folgenden Fällen nicht durch eine Maskierungsrichtlinie oder eine Zeilenzugriffsrichtlinie referenziert werden:

• Hinzufügen einer Zeilenzugriffsrichtlinie zu einer Tabelle

• Enumerieren einer oder mehrerer Spalten in einer bedingten Maskierungsrichtlinie

• Ausführen eines Lookups auf einer Zuordnungstabelle

Wie im Abschnitt Einschränkungen (unter diesem Thema) erwähnt, kann im body einer Projektionsrichtlinie nicht auf eine durch eine Maskierungsrichtlinie geschützte Spalte oder eine durch eine Zeilenzugriffsrichtlinie geschützte Tabelle verwiesen werden.

Abhängige Objekte mit anderen Projektionsrichtlinien¶

Betrachten Sie die folgende Serie von Objekten:

base_table » v1 » v2

Wobei:

• v1 ist eine aus der Tabelle namens base_table erstellte Ansicht.

• v2 ist eine aus v1 erstellte Ansicht.

Wenn es eine Abfrage auf einer Spalte einer Ansicht gibt, die eine Projektionseinschränkung aufweist, und diese Spalte von einer base_table-Spalte mit Projektionseinschränkung abhängt, wird die Ansichtsspalte nur projiziert, wenn beide Projektionsrichtlinien die Projektion der Spalte erlauben.

Snowflake prüft die Spaltenherkunftskette bis hinunter zur Basistabelle, um sicherzustellen, dass alle Referenzen auf die Spalte keine Projektionseinschränkung aufweisen. Wenn eine Spalte in der Herkunftskette eine Projektionseinschränkung aufweist und die Spalte nicht projiziert werden darf, blockiert Snowflake die Abfrage.

Ansichten und materialisierte Ansichten¶

Eine Projektionsrichtlinie auf einer Ansichtsspalte schränkt die Ansichtsspalte ein, aber nicht die zugrunde liegende Basistabellenspalte.

Was die Referenzen betrifft, so wird eine Projektionsrichtlinie, die eine Tabellenspalte einschränkt, auf eine Ansicht übertragen, die auf die eingeschränkte Tabellenspalte verweist.

Streams und Aufgaben¶

Projektionsrichtlinien auf Spalten einer Tabelle werden auf einen Stream derselben Tabelle übertragen. Beachten Sie, dass eine Projektionsrichtlinie nicht auf einen Stream festgelegt werden kann.

In ähnlicher Weise bleibt eine Spalte mit Projektionsrichtlinie eingeschränkt, wenn eine Aufgabe auf die eingeschränkte Spalte verweist.

UNPIVOT¶

Das Ergebnis eines UNPIVOT-Konstrukts hängt davon ab, ob eine Spalte ursprünglich durch eine Projektionsrichtlinie eingeschränkt war. Hinweis:

• Bei eingeschränkten Spalten bleibt die Projektionseinschränkung vor und nach der Ausführung von UNPIVOT erhalten.

• Die Spalte name_column wird immer im Abfrageergebnis angezeigt.

• Wenn eine der Spalten in der column_list-Liste eine Projektionseinschränkung aufweist, weist auch die Spalte value_column eine Projektionseinschränkung auf.

Geklonte Objekte¶

Der folgende Ansatz unterstützt Sie dabei, Daten vor Benutzern mit SELECT-Berechtigung für eine geklonte Tabelle oder Ansicht schützen, die in der geklonten Datenbank oder dem geklonten Schema gespeichert ist:

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

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

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

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

  • Wenn die Quelltabelle auf eine Projektionsrichtlinie 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.

Replikation¶

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

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

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

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

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

Benutzerdefinierte Funktionen (UDFs)¶

Beachten Sie die folgenden Hinweise zu Projektionseinschränkungen und UDFs:

Skalare SQL-UDFs:

Snowflake wertet die UDF aus und wendet dann die Projektionsrichtlinie auf die Spalte mit Projektionseinschränkung an.

Wenn eine Spalte in einer SELECT-Anweisung transitiv von einer UDF abgeleitet ist, die wiederum von einer Spalte mit Projektionseinschränkung abgeleitet ist, blockiert Snowflake die Abfrage. Mit anderen Worten:

pc_column » UDF » column (in SELECT-Anweisung)

Wobei:

• pc_column bezieht sich auf eine Spalte mit Projektionseinschränkung.

Da die Spalte in der SELECT-Anweisung auf eine Spalte mit Projektionseinschränkung zurückverfolgt werden kann, blockiert Snowflake die Abfrage.

SQL UDTFs:

SQL-UDTF (benutzerdefinierte Tabellenfunktionen) verhalten sich genauso wie SQL-UDFs, mit dem Unterschied, dass aufgrund der Rückgabe von Zeilen in der Funktionsausgabe Snowflake jede Tabellenspalte unabhängig auswertet, um festzustellen, ob die Spalte in der Funktionsausgabe projiziert werden soll.

Andere UDFs:

Das Folgende gilt für Einführung in Java-UDFs, Einführung in JavaScript-UDFs, Einführung in Python-UDFs:

• Eine Spalte mit Projektionseinschränkung ist in der UDTF-Ausgabe eingeschränkt.

Logging und Ereignistabellen:

Wenn eine UDF, UDTF oder JavaScript-UDF ein Argument mit Projektionseinschränkung hat, erfasst Snowflake keine Protokoll- und Ereignisdetails in der entsprechenden Ereignistabelle. Snowflake lässt jedoch die Ausführung der UDF/UDTF zu und lässt die Anweisung, die die UDF/UDTF aufruft, nicht aus Logging-Gründen fehlschlagen.

Berechtigungen von Projektionsrichtlinien¶

Snowflake unterstützt die folgenden Berechtigungen für das Projektionsrichtlinienobjekt.

USAGE-Berechtigung für die übergeordnete Datenbank und das Schema ist erforderlich, um Operationen an einem beliebigen Objekt in einem Schema durchzuführen.

Weitere Details dazu finden Sie unter Übersicht der DDL-Befehle, Operationen und Berechtigungen (unter diesem Thema).

Übersicht zu DDL für Projektionsrichtlinien¶

Snowflake unterstützt die folgenden DDL-Befehle zum Erstellen und Verwalten von Projektionsrichtlinien.

• CREATE PROJECTION POLICY

• ALTER PROJECTION POLICY

• DESCRIBE PROJECTION POLICY

• DROP PROJECTION POLICY

• SHOW PROJECTION POLICIES

Übersicht der DDL-Befehle, Operationen und Berechtigungen¶

Die folgende Tabelle fasst die Beziehung zwischen Projektionsrichtlinie-Berechtigungen und DDL-Operationen zusammen.

USAGE-Berechtigung für die übergeordnete Datenbank und das Schema ist erforderlich, um Operationen an einem beliebigen Objekt in einem Schema durchzuführen.

Snowflake unterstützt verschiedene Berechtigungen zum Erstellen und Festlegen einer Projektionsrichtlinie für ein Objekt.

1. Bei einem zentralen Ansatz für die Verwaltung von Projektionsrichtlinien, bei dem die kundenspezifische Rolle projection_policy_admin Projektionsrichtlinien für alle Objekte erstellt und festlegt, sind die folgenden Berechtigungen erforderlich:

   USE ROLE securityadmin;
   GRANT USAGE ON DATABASE mydb TO ROLE projection_policy_admin;
   GRANT USAGE ON SCHEMA mydb.schema TO ROLE projection_policy_admin;
   
   GRANT CREATE PROJECTION POLICY ON SCHEMA mydb.schema TO ROLE projection_policy_admin;
   GRANT APPLY ON PROJECTION POLICY ON ACCOUNT TO ROLE projection_policy_admin;
   

   Copy

2. In einem hybriden Verwaltungsansatz verfügt eine einzelne Rolle über die CREATE PROJECTION POLICY-Berechtigung, um die konsistente Benennung der Projektionsrichtlinien sicherzustellen, und einzelne Teams oder Rollen verfügen über die APPLY-Berechtigung für eine bestimmte Projektionsrichtlinie.

   So kann beispielsweise der kundenspezifischen Rolle finance_role die Berechtigung erteilt werden, die Projektionsrichtlinie cost_center für Tabellen und Ansichten festzulegen, deren Eigentümer die Rolle ist (d. h. die Rolle hat die OWNERSHIP-Berechtigung für die Tabelle oder Ansicht):

   USE ROLE securityadmin;
   GRANT CREATE PROJECTION POLICY ON SCHEMA mydb.schema TO ROLE projection_policy_admin;
   GRANT APPLY ON PROJECTION POLICY cost_center TO ROLE finance_role;
   

   Copy