Hinweise zur Zugriffssteuerung¶

Verwenden der ACCOUNTADMIN-Rolle¶

Die Rolle des Kontoadministrators (d. h. Benutzer mit der Systemrolle ACCOUNTADMIN) ist die einflussreichste 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 (d. h. Benutzer mit der Systemrolle SECURITYADMIN) enthält die globale Berechtigung MANAGE GRANTS, um Berechtigungen für Objekte im Konto zu erteilen oder zu entziehen. Die Rolle USERADMIN ist in der standardmäßigen Zugriffssteuerungshierarchie eine untergeordnete Rolle dieser Rolle.

• Die Rolle Systemadministrator (SYSADMIN) beinhaltet die Berechtigungen zum Erstellen von Warehouses, Datenbanken und allen Datenbankobjekten (Schemas, Tabellen usw.).

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 jeder Datenbank neue Objekte hinzugefügt werden, sollten Sie in Erwägung ziehen, den Rollen automatisch Berechtigungen für diese Objekte auf der Basis des Objekttyps (z. B. Schema, Tabelle oder Ansicht) zu erteilen. 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 üblichen Rollen, die auf Kontoebene erstellt werden (d. h. kundenspezifische Kontorollen), mit Ausnahme ihres Geltungsbereichs: Um SQL-Aktionen auf Objekte innerhalb einer Datenbank zu ermöglichen, können einer Datenbankrolle derselben Datenbank Berechtigungen 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 Datenbankrollen einer anderen Datenbank erteilt 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.

Data Sharing (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 Zugriffsschemas¶

Bei regulären (d. h. nicht verwalteten) Schemas in einer Datenbank können Objekteigentümers (d. h. Rollen mit der OWNERSHIP-Berechtigung für ein oder mehrere Objekte) anderen Rollen Zugriff auf ihre Objekte gewähren einschließlich der Option, diesen Rollen auch 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 (d. h. 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 Zuweisungen 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 Zuweisungen ermöglichen die Definition eines anfänglichen Satzes von Berechtigungen für Objekte eines bestimmten Typs (z. B. Tabellen oder Ansichten) in einem angegebenen 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 (i.e. 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 (i.e. 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.