Bewährte Praktiken der Zugriffssteuerung¶

Verwenden der ACCOUNTADMIN-Rolle¶

Die Rolle des Kontoadministrators (Benutzer mit der Systemrolle ACCOUNTADMIN) ist die mächtigste Rolle im System. Diese Rolle ist allein verantwortlich für die Konfiguration der Parameter auf Kontoebene. Benutzer mit der Rolle ACCOUNTADMIN können Snowflake-Abrechnungsdaten und Credit-Daten anzeigen und verwalten sowie alle in Ausführung befindlichen SQL-Anweisungen stoppen.

Beachten Sie, dass ACCOUNTADMIN keine Superuser-Rolle ist. Diese Rolle erlaubt nur dann das Anzeigen und Verwalten von Objekten im Konto, wenn diese Rolle oder eine Rolle, die in einer Rollenhierarchie untergeordnet ist, über ausreichende Berechtigungen für die Objekte verfügt.

In der Systemrollenhierarchie sind die anderen Administratorrollen untergeordnete Rollen dieser Rolle:

• Die Rolle des Benutzeradministrators (USERADMIN) umfasst die Berechtigung zum Erstellen und Verwalten von Benutzern und Rollen (vorausgesetzt, die Eigentümerschaft dieser Rollen oder Benutzer wurde nicht an eine andere Rolle übertragen).

• Die Rolle des Sicherheitsadministrators (SECURITYADMIN systemdefiniert) beinhaltet die globale Berechtigung MANAGE GRANTS, Berechtigungen für Objekte in dem Konto zu gewähren oder zu widerrufen. Die Rolle USERADMIN ist in der standardmäßigen Zugriffssteuerungshierarchie eine untergeordnete Rolle dieser Rolle. Weitere Informationen zu den untergeordneten systemdefinierten Rollen finden Sie unter Systemdefinierte Rollen.

• Die Rolle des Systemadministrators (SYSADMIN) beinhaltet die Berechtigung, Warehouses, Datenbanken und alle Datenbankobjekte (Schemata, Tabellen usw.) zu erstellen.

Zugriff auf Datenbankobjekte¶

Alle sicherungsfähigen Datenbankobjekte (wie TABLE, FUNCTION, FILE FORMAT, STAGE, SEQUENCE usw.) sind in einem SCHEMA-Objekt einer DATABASE enthalten. Um auf Datenbankobjekte zugreifen zu können, muss den Benutzern zusätzlich zu den Berechtigungen für die spezifischen Datenbankobjekte die Berechtigung USAGE für Datenbank und Schema des Containers erteilt werden.

Angenommen, mytable wird in mydb.myschema erstellt wird. Um mytable abzufragen, muss ein Benutzer mindestens über die folgenden Berechtigungen verfügen:

Datenbank:

USAGE für mydb

Schema:

USAGE für myschema

Tabelle:

SELECT für mytable

Verwalten von kundenspezifischen Rollen¶

Wenn eine kundenspezifische Rolle zum ersten Mal erstellt wird, existiert sie isoliert. Die Rolle muss allen Benutzern zugewiesen werden, die die mit der Rolle verbundenen Objektberechtigungen verwenden. Die kundenspezifische Rolle muss auch allen Rollen zugewiesen werden, die die von der kundenspezifischen Rolle erstellten Objekte verwalten.

Anweisungen zum Erstellen einer Rollenhierarchie finden Sie unter Erstellen einer Rollenhierarchie.

Ausrichten des Objektzugriffs an den Geschäftsfunktionen¶

Erwägen Sie, die Vorteile von Rollenhierarchien und der Vererbung von Berechtigungen zu nutzen, um den Zugriff auf Datenbankobjekte mit den Geschäftsfunktionen in Ihrem Unternehmen abzustimmen. In einer Rollenhierarchie werden Rollen an andere Rollen vergeben, um eine Vererbungsbeziehung zu bilden. Berechtigungen, die Rollen auf einer niedrigeren Ebene erteilt werden, werden an Rollen auf einer höheren Ebene vererbt.

Für eine optimale Flexibilität bei der Steuerung des Zugriffs auf Datenbankobjekte erstellen Sie eine Kombination von Objekt-Zugriffsrollen mit unterschiedlichen Berechtigungen auf Objekte und weisen diese entsprechend den Funktionsrollen zu:

• Erteilen Sie Berechtigungen für Datenbankobjekte oder Kontenobjekte (z. B. Warehouse) für Zugriffsrollen.

• Weisen Sie Zugriffsrollen funktionale Rollen zu, um eine Rollenhierarchie zu erstellen. Diese Rollen entsprechen den Geschäftsfunktionen Ihres Unternehmens und dienen als Sammelrollen für alle Zugriffsrollen, die für diese Funktionen erforderlich sind.

  Weisen Sie gegebenenfalls übergeordneten Funktionsrollen in einer Eltern-Kind-Beziehung untergeordnete Funktionsrollen zu, wobei die übergeordneten Rollen Geschäftsfunktionen abbilden, die die Berechtigungen der untergeordneten Rollen subsumieren sollen.

  Folgen Sie Best Practices für Rollenhierarchien, und weisen Sie der Rolle Systemadministrator (SYSADMIN) die funktionalen Rollen der höchsten Ebene in einer Rollenhierarchie zu. Systemadministratoren können dann allen Rollen in dieser Hierarchie Berechtigungen für Datenbankobjekte erteilen:

Beispiel¶

Als einfaches Beispiel nehmen wir an, dass zwei Datenbanken in einem Konto, fin und hr, jeweils Lohnabrechnungs- und Mitarbeiterdaten enthalten. Buchhalter und Analysten in Ihrem Unternehmen benötigen unterschiedliche Berechtigungen für die Objekte in diesen Datenbanken, um ihre Geschäftsfunktionen ausführen zu können. Buchhalter sollten Lese-/Schreibzugriff auf fin haben, benötigen aber möglicherweise nur Lesezugriff auf hr, da die Mitarbeiter der Personalabteilung die Daten in dieser Datenbank pflegen. Analysten benötigen möglicherweise einen Nur-Lese-Zugriff auf beide Datenbanken.

Berechtigungen für vorhandene Datenbankobjekte werden über die folgende Hierarchie von Zugriffsrollen und Funktionsrollen erteilt:

Bemerkung

Wenn in jeder Datenbank neue Objekte hinzugefügt werden, sollten Sie in Erwägung ziehen, Rollen auf der Grundlage des Objekttyps (z. B. Schemata, Tabellen oder Ansichten) automatisch Berechtigungen für die Objekte zu gewähren. Weitere Informationen dazu finden Sie unter Vereinfachen der Berechtigungsverwaltung mithilfe von zukünftigen Zuweisungen (unter diesem Thema).

Kundenspezifische Rolle	Beschreibung	Berechtigungen
db_hr_r	Zugriffsrolle, die den Nur-Lese-Zugriff auf Tabellen in der Datenbank hr erlaubt.	USAGE auf Datenbank hr. USAGE auf allen Schemas in der Datenbank hr. SELECT auf allen Tabellen in der Datenbank hr.
db_fin_r	Zugriffsrolle, die den Nur-Lese-Zugriff auf Tabellen in der Datenbank fin erlaubt.	USAGE auf Datenbank fin. USAGE auf allen Schemas in der Datenbank fin. SELECT auf allen Tabellen in der Datenbank fin.
db_fin_rw	Zugriffsrolle, die Lese-/Schreibzugriff auf Tabellen in der Datenbank fin erlaubt.	USAGE auf Datenbank fin. USAGE auf allen Schemas in der Datenbank fin. SELECT, INSERT, UPDATE, DELETE auf allen Tabellen in der Datenbank fin.
accountant	Funktionale Rolle für Buchhalter in Ihrer Organisation.	N/A
analyst	Funktionale Rolle für Analysten in Ihrer Organisation.	N/A

Die folgende Abbildung zeigt die Rollenhierarchie für dieses Beispiel:

So konfigurieren Sie die Zugriffssteuerung für dieses Beispiel:

1. Erstellen Sie als Benutzeradministrator (Benutzer mit der Rolle USERADMIN) oder als Benutzer mit einer anderen Rolle, die über die Berechtigung CREATE ROLE für das Konto verfügt, die Zugriffsrollen und funktionalen Rollen aus diesem Beispiel:

   CREATE ROLE db_hr_r;
   CREATE ROLE db_fin_r;
   CREATE ROLE db_fin_rw;
   CREATE ROLE accountant;
   CREATE ROLE analyst;
   

   Copy

2. Erteilen Sie als Sicherheitsadministrator (Benutzer mit der Rolle SECURITYADMIN) oder als Benutzer mit einer anderen Rolle, die über die Berechtigung MANAGE GRANTS für das Konto verfügt, den Zugriffsrollen die jeweils erforderlichen minimalen Berechtigungen:

   -- Grant read-only permissions on database HR to db_hr_r role.
   GRANT USAGE ON DATABASE hr TO ROLE db_hr_r;
   GRANT USAGE ON ALL SCHEMAS IN DATABASE hr TO ROLE db_hr_r;
   GRANT SELECT ON ALL TABLES IN DATABASE hr TO ROLE db_hr_r;
   
   -- Grant read-only permissions on database FIN to db_fin_r role.
   GRANT USAGE ON DATABASE fin TO ROLE db_fin_r;
   GRANT USAGE ON ALL SCHEMAS IN DATABASE fin TO ROLE db_fin_r;
   GRANT SELECT ON ALL TABLES IN DATABASE fin TO ROLE db_fin_r;
   
   -- Grant read-write permissions on database FIN to db_fin_rw role.
   GRANT USAGE ON DATABASE fin TO ROLE db_fin_rw;
   GRANT USAGE ON ALL SCHEMAS IN DATABASE fin TO ROLE db_fin_rw;
   GRANT SELECT,INSERT,UPDATE,DELETE ON ALL TABLES IN DATABASE fin TO ROLE db_fin_rw;
   

   Copy

3. Weisen Sie als Sicherheitsadministrator (Benutzer mit der Rolle SECURITYADMIN) oder als Benutzer mit einer anderen Rolle, die über die Berechtigung MANAGE GRANTS für das Konto verfügt, der funktionalen Rolle accountant die Zugriffsrolle db_fin_rw zu und der funktionalen Rolle analyst die Zugriffsrollen db_hr_r und db_fin_r:

   GRANT ROLE db_fin_rw TO ROLE accountant;
   GRANT ROLE db_hr_r TO ROLE analyst;
   GRANT ROLE db_fin_r TO ROLE analyst;
   

   Copy

4. Weisen Sie als Sicherheitsadministrator (Benutzer mit der Rolle SECURITYADMIN) oder als Benutzer mit einer anderen Rolle, die über die Berechtigung MANAGE GRANTS für das Konto verfügt, der Systemadministratorrolle SYSADMIN die Rollen analyst und accountant zu:

   GRANT ROLE accountant,analyst TO ROLE sysadmin;
   

   Copy

5. Weisen Sie als Sicherheitsadministrator (Benutzer mit der Rolle SECURITYADMIN) oder als Benutzer mit einer anderen Rolle, die über die Berechtigung MANAGE GRANTS für das Konto verfügt, die Geschäftsfunktionsrollen den Benutzern zu, die diese Geschäftsfunktionen in Ihrer Organisation ausführen: In diesem Beispiel wird die funktionale Rolle analyst dem Benutzer user1 zugewiesen und die funktionale Rolle accountant dem Benutzer user2.

   GRANT ROLE accountant TO USER user1;
   GRANT ROLE analyst TO USER user2;
   

   Copy

Verwalten des Datenbankobjektzugriffs mithilfe von Datenbankrollen¶

Datenbankrollen entsprechen im Wesentlichen den traditionellen Rollen, die auf der Ebene des Kontos erstellt werden (benutzerdefinierte Kontorollen), mit Ausnahme ihres Umfangs: Um SQL Aktionen auf Objekte innerhalb einer Datenbank zu ermöglichen, können einer Datenbankrolle Berechtigungen in derselben Datenbank erteilt werden.

Datenbankrollen sind für die folgenden Anwendungsfälle vorgesehen:

Einfache Verwaltung:

Datenbankeigentümer können den Zugriff auf sicherungsfähige Objekte in ihren eigenen Datenbanken unabhängig voneinander verwalten. Datenbankeigentümer können die folgenden Aktionen ausführen:

• Datenbankrollen erstellen und verwalten.

• Datenbankrollen Berechtigungen zuweisen.

  Die den Datenbankrollen erteilten Berechtigungen für Objekte müssen sich auf Objekte beziehen, die in der Datenbank enthalten sind, in der die Rolle existiert. Berechtigungen für Objekte in einer Datenbank (z. B. Tabellen oder Ansichten) können nicht an Datenbankrollen in einer anderen Datenbank vergeben werden.

  Jede Berechtigung, einschließlich OWNERSHIP, kann Datenbankrollen für Objekte in einer Datenbank erteilt werden. Beachten Sie, dass die OWNERSHIP-Berechtigung für die Datenbank selbst nur einer Kontorolle erteilt werden kann.

• Rollenhierarchien erstellen oder erweitern. Datenbankrollen können anderen Datenbankrollen innerhalb derselben Datenbank zugewiesen werden, und dann können die höchsten Datenbankrollen in der Rollenhierarchie einer Datenbank Kontorollen zugewiesen werden. Weitere Informationen dazu finden Sie unter Rollenhierarchie und Vererbung von Berechtigungen.

  Beachten Sie, dass durch das Zuweisen einer Datenbankrolle zu einer Kontorolle implizit die USAGE-Berechtigung für die Datenbank erteilt wird, die die Datenbankrolle zu dieser Kontorolle enthält. Ein explizites Erteilen der USAGE-Berechtigung für die Datenbank ist nicht erforderlich.

Datenfreigabe:

Datenanbieter, die das Snowflake-Feature Secure Data Sharing verwenden, können die sicherungsfähigen Objekte einer Freigabe segmentieren, indem sie mehrere Datenbankrollen in der freizugebenden Datenbank erstellen und jeder Datenbankrolle Berechtigungen für eine Teilmenge der Objekte in der Datenbank erteilen. Nach dem Erstellen einer Datenbank aus einer Freigabe, die Datenbankrollen enthält, weisen die Datenverbraucher diese Datenbankrollen einer oder mehreren Kontorollen des eigenen Kontos zu.

Wenn keine Datenbankrollen verwendet werden, erteilen die Kontoadministratoren der Datenverbraucherkonten den Rollen nur die Berechtigung IMPORTED PRIVILEGES, wodurch ihre Benutzer Zugriff auf alle Datenbanken und Datenbankobjekte (Tabellen, sichere Ansichten usw.) einer Freigabe erhalten. Es gibt keine Option, bei der verschiedenen Benutzergruppen eines Datenverbraucherkontos der Zugriff auf Teilmengen der freigegebenen Objekte gestattet wird. Bei diesem Alles-oder-Nichts-Ansatz müssen Datenanbieter mehrere Freigaben erstellen, um den Zugriff auf verschiedene Objekte in denselben Datenbanken zu ermöglichen.

Beachten Sie, dass Datenbankrollen nicht direkt in einer Sitzung aktiviert werden können. Zuweisen von Datenbankrollen zu Kontorollen, die in einer Sitzung aktiviert werden können.

Zentralisieren der Berechtigungsverwaltung mithilfe von verwalteten Zugriffsschemata¶

Bei regulären (nicht verwalteten) Schemata in einer Datenbank können Objekteigentümer (Rollen mit der Berechtigung OWNERSHIP für ein oder mehrere Objekte) anderen Rollen Zugriff auf diese Objekte gewähren, mit der Option, diesen Rollen darüber hinaus die Möglichkeit zu geben, Objektberechtigungen zu verwalten.

Verwenden Sie verwaltete Zugriffsschemas, um die Sicherheit von Objekten weiter zu erhöhen. In einem verwalteten Zugriffsschema verlieren Objekteigentümer die Möglichkeit, Berechtigungsentscheidungen zu treffen. Nur der Schemaeigentümer (die Rolle mit der OWNERSHIP-Berechtigung für das Schema) oder eine Rolle mit der Berechtigung MANAGE GRANTS kann Berechtigungen für Objekte im Schema, einschließlich zukünftiger Berechtigungszuweisungen erteilen, wodurch die Berechtigungsverwaltung zentralisiert wird.

Beachten Sie, dass eine Rolle mit der globalen Berechtigung MANAGE GRANTS der aktuellen (Berechtigungsgeber-)Rolle keine zusätzlichen Berechtigungen erteilen kann.

Weitere Informationen zu verwalteten Zugriffsschemas finden Sie unter Erstellen verwalteter Zugriffsschemas.

Vereinfachen der Berechtigungsverwaltung mithilfe von zukünftigen Berechtigungszuweisungen¶

Zukünftige Berechtigungen ermöglichen die Definition einer anfänglichen Reihe von Berechtigungen für Objekte eines bestimmten Typs (z. B. Tabellen oder Ansichten) in einem bestimmten Schema. Wenn neue Objekte erstellt werden, werden die definierten Berechtigungen automatisch einer Rolle zugewiesen, wodurch die Verwaltung von Berechtigungen vereinfacht wird.

Stellen Sie sich das folgende Szenario vor, in dem einer bestimmten Rolle die Berechtigung SELECT für alle neuen, im Schema erstellten Tabellen erteilt wird. Zu einem späteren Zeitpunkt wird entschieden, die Berechtigung dieser Rolle wieder zu entziehen und stattdessen einer anderen Rolle zuzuweisen. Mit den Schlüsselwörtern ON FUTURE für neue Tabellen und dem Schlüsselwort ALL für vorhandene Tabellen sind einige SQL-Anweisungen erforderlich, um Berechtigungen für neue und vorhandene Tabellen zu erteilen und zu widerrufen. Beispiel:

-- Grant the SELECT privilege on all new (future) tables in a schema to role R1
GRANT SELECT ON FUTURE TABLES IN SCHEMA s1 TO ROLE r1;

-- / Create tables in the schema /

-- Grant the SELECT privilege on all new tables in a schema to role R2
GRANT SELECT ON FUTURE TABLES IN SCHEMA s1 TO ROLE r2;

-- Grant the SELECT privilege on all existing tables in a schema to role R2
GRANT SELECT ON ALL TABLES IN SCHEMA s1 TO ROLE r2;

-- Revoke the SELECT privilege on all new tables in a schema (future grant) from role R1
REVOKE SELECT ON FUTURE TABLES IN SCHEMA s1 FROM ROLE r1;

-- Revoke the SELECT privilege on all existing tables in a schema from role R1
REVOKE SELECT ON ALL TABLES IN SCHEMA s1 FROM ROLE r1;

Weitere Informationen zu zukünftigen Zuweisungen finden Sie unter Festlegen zukünftiger Berechtigungszuweisungen zu Objekten.

Anzeigen von Abfrageergebnissen¶

Ein Benutzer kann das Resultset einer Abfrage, die ein anderer Benutzer ausgeführt hat, nicht anzeigen. Dieses Verhalten ist beabsichtigt. Aus Sicherheitsgründen kann nur der Benutzer, der eine Abfrage ausgeführt hat, auf die Abfrageergebnisse zugreifen.

Erläuterungen zu geklonten Objekten und erteilten Berechtigungen¶

Durch das Klonen einer Datenbank, eines Schemas oder einer Tabelle wird eine Kopie des Quellobjekts erstellt. Das geklonte Objekt enthält eine Momentaufnahme der Daten, die im Quellobjekt vorhanden waren, als der Klon erstellt wurde.

Ein geklontes Objekt wird in Snowflake als neues Objekt angesehen. Alle Berechtigungen, die dem Quellobjekt erteilt wurden, werden nicht auf das geklonte Objekt übertragen. Ein geklontes Containerobjekt (eine Datenbank oder ein Schema) behält jedoch alle Berechtigungen, die für die im Quellobjekt enthaltenen Objekte erteilt werden. So behält beispielsweise ein geklontes Schema alle Berechtigungen, die für Tabellen, Ansichten, UDFs und andere Objekte im Quellschema erteilt werden.

Weitere Details zum Klonen finden Sie unter Hinweise zum Klonen und CREATE <Objekt> … CLONE.

Vergleich und Gegenüberstellung von RBAC mit UBAC¶

Die rollenbasierte Zugriffssteuerung (RBAC) ist Ihre Grundlage für die Zugriffssteuerung in Snowflake. RBAC bietet von Haus aus Skalierbarkeit und zentrale Kontrolle. Mit RBAC erteilen Sie Rollen Berechtigungen und weisen diesen Rollen dann Benutzer zu. Dies vereinfacht die Verwaltung, sorgt für Konsistenz und erleichtert den Prüfungszugang. RBAC wird im Allgemeinen für Produktionsumgebungen und die Verwaltung auf Unternehmensebene empfohlen. Die benutzerbasierte Zugriffssteuerung (UBAC) ist für Anwendungsfälle wie die private Entwicklung und Zusammenarbeit gedacht.

Sie sollten die Verwendung von UBAC für kollaborative Szenarien in Betracht ziehen, z. B. für die Erstellung von Streamlit-Anwendungen. Während eines kollaborativen Entwicklungsprozesses möchte ein Asset-Eigentümer möglicherweise den Zugriff auf das Asset kontrollieren, bevor er es mit einem breiteren Publikum teilt. UBAC ergänzt RBAC, indem es die Flexibilität bietet, Berechtigungen direkt an einzelne Benutzer zu vergeben. UBAC ist besonders nützlich in Szenarien, die von einem detaillierteren Modell der Zugriffssteuerung profitieren.

UBAC bietet Objekteigentümern keine neuen Berechtigungsstufen. Wenn Sie derzeit darauf vertrauen, dass die Objekteigentümer den Zugriff auf ihre Objekte mit Hilfe von Rollen in RBAC verwalten, dann ändert die Verwendung von UBAC dieses Vertrauen nicht grundlegend. Objekteigentümer haben bereits die Möglichkeit, jeder Rolle Zugriff zu gewähren, einschließlich allgemein zugänglicher Rollen wie PUBLIC. UBAC ermöglicht es Objekteigentümern, bestimmten Benutzern direkt Zugriff zu gewähren. UBAC hat keinen Einfluss auf die Leistung der Abfrage.

Vermeidung von ausufernden Berechtigungen bei der Verwendung von UBAC¶

Um zu verhindern, dass Objekteigentümer wahllos Zugriff auf Objekte gewähren, verwenden Sie verwaltete Zugriffsschemata. Verwaltete Zugriffsschemata nehmen den Objekteigentümer die Möglichkeit, anderen Rollen oder Benutzern Zugriff zu gewähren. Nur Schemaeigentümer oder eine Rolle mit der Berechtigung MANAGE GRANTS können Berechtigungen für Objekte in einem verwalteten Zugriffsschema erteilen. Ausufernde Berechtigungen können entweder mit UBAC oder RBAC auftreten. Außerhalb von verwalteten Zugriffsschemata können Objekteigentümer bei der Verwendung von RBAC jeder Rolle in einem Konto Zugriff gewähren, genauso wie sie bei der Verwendung von UBAC jedem Benutzer Berechtigungen gewähren können.

Überwachung der Zugriffssteuerungsrechte in Ihrem Konto¶

Sie können die Berechtigungen, die Rollen, Benutzern und Anwendungen gewährt werden, mit der Ansicht GRANTS_TO_ROLES in ACCOUNT_USAGE überwachen. Weitere Informationen dazu finden Sie unter Ansicht GRANTS_TO_ROLES.

Sie können die Zugriffssteuerungsrechte in Ihrem Konto auch auf die folgenden Arten überwachen:

• Anzeigen von direkten Berechtigungen für alle Benutzer

• Direkte Berechtigungen für bestimmte Benutzer

• Anzeigen der aktuellen Berechtigungen für ein Objekt

• Anzeigen der aktuellen Berechtigungen für ein Schema

• Anzeigen der Berechtigungen für ein Datenbankschema

• Anzeigen der aktuellen Berechtigungen, die einer Rolle oder einem Benutzer gewährt werden

Wenn Sie zum Beispiel die direkten Berechtigungen für alle Benutzer anzeigen möchten, führen Sie die folgende Abfrage aus:

SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.GRANTS_TO_ROLES
  WHERE granted_to = 'USER';

Zum Beispiel, um direkte Berechtigungen für bestimmte Benutzer anzuzeigen:

1. Führen Sie den folgenden Befehl aus, um alle Berechtigungen für einen bestimmten Benutzer anzuzeigen:

   SHOW GRANTS TO USER <user_name>;
   

   Copy

2. Filtern Sie das Ergebnis des vorherigen Schritts, um nur die Berechtigungen anzuzeigen, die dem Benutzer direkt und nicht über Rollen gewährt wurden:

   SELECT * FROM TABLE(RESULT_SCAN(LAST_QUERY_ID())
    WHERE "role" is null;
   

   Copy

Um zum Beispiel die aktuellen Berechtigungen für ein Objekt anzuzeigen, können Sie den Befehl SHOW GRANTS ausführen.

Um beispielsweise die aktuellen Berechtigungen für ein Schema anzuzeigen, führen Sie den folgenden Befehl aus:

SHOW GRANTS ON SCHEMA <database_name>.<schema_name>;

Um beispielsweise die Berechtigungen für database_a.schema_1 anzuzeigen, die unter Erstellen von kundenspezifischen Rollen erteilt wurden, führen Sie den folgenden Befehl aus:

SHOW GRANTS ON SCHEMA database_a.schema_1;

Snowflake gibt die folgenden Ergebnisse zurück:

+-------------------------------+-----------------------+------------+----------------------+------------+--------------------------+--------------+---------------+
| created_on                    | privilege             | granted_on | name                 | granted_to | grantee_name             | grant_option | granted_by    |
|-------------------------------+-----------------------+------------+----------------------+------------+--------------------------+--------------+---------------|
| 2022-03-07 09:04:23.635 -0800 | USAGE                 | SCHEMA     | database_a.schema_1  | ROLE       | R1                       | false        | SECURITYADMIN |
+-------------------------------+-----------------------+------------+----------------------+------------+--------------------------+--------------+---------------+

Sie können auch den Befehl SHOW GRANTS ausführen, um die aktuellen Berechtigungen zu sehen:

• Eine Rolle:

  SHOW GRANTS TO ROLE <role_name>;
  

  Copy

  Führen Sie beispielsweise den folgenden Befehl aus, um die Berechtigungen der Rolle r1 anzuzeigen, die als kundenspezifische Rolle erstellt wurde:

  SHOW GRANTS TO ROLE r1;
  

  Copy

  Snowflake gibt die folgenden Ergebnisse zurück:

  +-------------------------------+-----------+------------+----------------------+------------+--------------+--------------+---------------+
  | created_on                    | privilege | granted_on | name                 | granted_to | grantee_name | grant_option | granted_by    |
  |-------------------------------+-----------+------------+----------------------+------------+--------------+--------------+---------------|
  | 2022-03-07 09:08:43.773 -0800 | USAGE     | DATABASE   | D1                   | ROLE       | R1           | false        | SECURITYADMIN |
  | 2022-03-07 09:08:55.253 -0800 | USAGE     | SCHEMA     | D1.S1                | ROLE       | R1           | false        | SECURITYADMIN |
  | 2022-03-07 09:09:07.206 -0800 | SELECT    | TABLE      | D1.S1.T1             | ROLE       | R1           | false        | SECURITYADMIN |
  | 2022-03-07 09:08:34.838 -0800 | USAGE     | WAREHOUSE  | W1                   | ROLE       | R1           | false        | SECURITYADMIN |
  +-------------------------------+-----------+------------+----------------------+------------+--------------+--------------+---------------+
  

• Ein Benutzer:

  SHOW GRANTS TO USER <user_name>;
  

  Copy

  Führen Sie zum Beispiel den folgenden Befehl aus, um die Berechtigungen des Benutzers user1 anzuzeigen:

  SHOW GRANTS TO USER user1;
  

  Copy

  Snowflake gibt die folgenden Ergebnisse zurück:

  +-------------------------------+-----------+------------+---------------------------+-----------+------------+--------------+--------------+---------------+
  | created_on                    | privilege | granted_on | name                      |  role     | granted_to | grantee_name | grant_option | granted_by    |
  |-------------------------------+-----------+------------+---------------------------+-----------+------------+--------------+------------------------------|
  | 2025-05-07 09:08:43.773 -0800 | USAGE     | DATABASE   | test_db                   | null      | USER       | user1        | false        | SECURITYADMIN |
  | 2025-05-07 09:08:55.253 -0800 | USAGE     | SCHEMA     | test_db.test_sch          | null      | USER       | user1        | false        | SECURITYADMIN |
  | 2025-05-07 09:08:55.253 -0800 | SELECT    | TABLE      | test_db.test_sch.test_tbl | null      | USER       | user1        | false        | SECURITYADMIN |
  | 2025-05-07 09:08:34.838 -0800 | USAGE     | WAREHOUSE  | test_wh                   | null      | USER       | user1        | false        | SECURITYADMIN |
  +-------------------------------+-----------+------------+---------------------------+-----------+------------+--------------+--------------+---------------+