Übersicht zur Zugriffssteuerung¶

Framework für die Zugriffssteuerung¶

Der Ansatz von Snowflake für die Zugriffssteuerung kombiniert Aspekte aus den folgenden Modellen:

• Diskretionäre Zugriffssteuerung (DAC): Jedes Objekt hat einen Eigentümer, der wiederum Zugriff auf dieses Objekt gewähren kann.

• Rollenbasierte Zugriffssteuerung (RBAC): Zugriffsrechte werden Rollen zugewiesen, die wiederum Benutzern zugewiesen werden.

• Benutzerbasierte Zugriffssteuerung (UBAC): Die Zugriffsrechte werden den Benutzern direkt zugewiesen. Die Zugriffssteuerung berücksichtigt Berechtigungen, die Benutzern direkt zugewiesen werden, nur, wenn USE SECONDARY ROLE auf ALL gesetzt ist.

Weitere Informationen über Sekundärrollen finden Sie unter USE SECONDARY ROLES und Autorisierung durch Primärrolle und Sekundärrollen.

Einige Konzepte, die für das Verständnis der Zugriffssteuerung in Snowflake wichtig sind, sind:

• Sicherungsfähiges Objekt: Eine Entität, der Zugriff gewährt werden kann. Solange keine Erlaubnis erteilt wurde, wird der Zugriff verweigert.

• Rolle: Eine Entität, der Berechtigungen erteilt werden können.

• Berechtigung: Eine definierte Zugriffsebene auf ein Objekt. Es können mehrere unterschiedliche Berechtigungen verwendet werden, um die Granularität des gewährten Zugriffs zu steuern.

• Benutzer: Eine Benutzeridentität, die von Snowflake erkannt wird, unabhängig davon, ob sie mit einer Person oder einem Dienst verbunden ist. Ein Benutzer ist auch eine Entität, der Berechtigungen erteilt werden können.

In Snowflake ermöglichen Berechtigungen, die Rollen oder Benutzern zugewiesen werden, den Zugriff auf sicherungsfähige Objekte. Rollen können Benutzern oder anderen Rollen zugewiesen werden. Durch die Vergabe einer Rolle an eine andere Rolle entsteht eine Rollenhierarchie, die unter Rollenhierarchie und Vererbung von Berechtigungen näher beschrieben wird. Normalerweise verwenden Sie RBAC, um den Zugriff auf sicherungsfähige Objekte in Snowflake zu verwalten.

Das folgende Diagramm veranschaulicht, wie DAC, RBAC und UBAC eine angemessene Zuweisung von Berechtigungen für verschiedene sicherungsfähige Objekte unterstützen. In diesem Beispiel hat die Rolle 1 die Berechtigung OWNERSHIP sowohl für Objekt 1 als auch für Objekt 2. Mit anderen Worten: Rolle 1 ist Eigentümer beider Objekte. Dies veranschaulicht DAC.

Berechtigungen auf Objekt 1 können an die Rolle 2 vergeben werden, die dann an Benutzer 1 und Benutzer 2 vergeben werden kann. Mit anderen Worten: Benutzer 1 und Benutzer 2 haben Zugriff auf Objekt 1, eingeschränkt durch diese Berechtigungen, da beiden Benutzern die Rolle 2 zugewiesen ist. Dieser Teil der Abbildung veranschaulicht RBAC.

Berechtigungen auf Objekt 2 können direkt an Benutzer 3 und Benutzer 4 vergeben werden. Dieser Teil der Abbildung veranschaulicht, wie Sie UBAC verwenden können, um das Snowflake-Zugriffssteuerungssystem zu erweitern und so ein hohes Maß an Kontrolle und Flexibilität zu erreichen.

Sicherungsfähige Objekte¶

Jedes sicherungsfähige Objekt befindet sich innerhalb eines logischen Containers in einer Hierarchie von Containern. Der oberste Container ist die Kundenorganisation. Sicherungsfähige Objekte wie Tabellen, Ansichten, Funktionen und Stagingbereiche sind in einem Schemaobjekt enthalten, das wiederum in einer Datenbank enthalten ist. Alle Datenbanken für Ihr Snowflake-Konto sind im Kontoobjekt enthalten. Diese Hierarchie von Objekten und Containern ist im Folgenden dargestellt:

Ein Objekt zu besitzen bedeutet, dass eine Rolle die OWNERSHIP-Berechtigung für das Objekt hat. Jedes sicherungsfähige Objekt ist Eigentum einer einzigen Rolle, die standardmäßig die Rolle ist, mit der das Objekt erstellt wurde. Wenn diese Rolle Benutzern zugewiesen wird, haben sie effektiv die gemeinsame Kontrolle über das Objekt. Mit dem Befehl GRANT OWNERSHIP können Sie die Eigentümerschaft eines Objekts von einer Rolle auf eine andere Rolle übertragen, auch auf Datenbankrollen. Dieser Befehl gibt auch an, welche Objekte im jeweiligen Container sicherungsfähig sind.

In einem typischen Schema verfügt die Rolle des Eigentümers standardmäßig über alle Berechtigungen für das Objekt, einschließlich der Möglichkeit, anderen Rollen Berechtigungen für das Objekt zu erteilen oder zu entziehen. Darüber hinaus kann das Eigentum einer Rolle auf eine andere Rolle übertragen werden. In einem verwalteten Zugriffsschema verlieren Objekteigentümer die Möglichkeit, Berechtigungsentscheidungen zu treffen. Nur der Schemaeigentümer (die Rolle mit der Berechtigung OWNERSHIP für das Schema) oder eine Rolle mit der Berechtigung MANAGE GRANTS kann Berechtigungen für Objekte im Schema erteilen.

Die Möglichkeit, SQL-Aktionen für Objekte auszuführen, wird durch die Berechtigungen definiert, die der aktiven Rolle in einer Benutzersitzung gewährt werden. Wenn die aktive Rolle in Ihrer Sitzung beispielsweise über die Berechtigungen CREATE, USAGE, SELECT und WRITE in einem bestimmten Snowflake-Datenbankschema verfügt, können Sie ein Warehouse erstellen, die enthaltenen Tabellen auflisten und Daten zu einer Tabelle in diesem Schema hinzufügen.

Rollen¶

Rollen sind die Entitäten, denen Berechtigungen für sicherungsfähige Objekte erteilt und entzogen werden können. Rollen werden Benutzern zugewiesen, damit sie die für Geschäftsfunktionen in ihrer Organisation erforderlichen Aktionen ausführen können. Einem Benutzer können mehrere Rollen zugewiesen werden. Dies ermöglicht es Benutzern, die Rolle zu wechseln (d. h. zu wählen, welche Rolle in der aktuellen Snowflake-Sitzung aktiv ist), um verschiedene Aktionen mit unterschiedlichen Berechtigungen durchzuführen.

Es gibt eine kleine Anzahl von systemdefinierten Rollen in jedem Snowflake-Konto. Systemdefinierte Rollen können nicht gelöscht werden. Darüber hinaus können die diesen Rollen von Snowflake erteilten Berechtigungen nicht widerrufen werden.

Benutzer, denen eine Rolle mit den erforderlichen Berechtigungen zugewiesen wurde, können kundenspezifische Rollen erstellen, um spezifische Geschäfts- und Sicherheitsanforderungen zu erfüllen.

Rollen können auch anderen Rollen zugewiesen werden, wodurch eine Hierarchie von Rollen entsteht. Die mit einer Rolle verbundenen Berechtigungen werden von allen Rollen vererbt, die in der Hierarchie über dieser Rolle liegen. Weitere Informationen über Rollenhierarchien und die Vererbung von Berechtigungen finden Sie unter Rollenhierarchie und Vererbung von Berechtigungen.

Den systemdefinierten Rollen können zusätzliche Berechtigungen erteilt werden, was jedoch nicht empfohlen wird. Systemdefinierte Rollen werden mit Berechtigungen in Bezug auf die Kontoverwaltung erstellt. Es wird nicht empfohlen, Berechtigungen zur Kontoverwaltung und entitätsspezifische Berechtigungen in ein und derselben Rolle zu kombinieren. Wenn zusätzliche Berechtigungen benötigt werden, empfiehlt Snowflake, diese zusätzlichen Berechtigungen einer kundenspezifischen Rolle zu erteilen und diese kundenspezifische Rolle dann der systemdefinierten Rolle zuzuweisen.

Berechtigungen¶

Die Zugriffssteuerungsrechte bestimmen, wer auf bestimmte Objekte in Snowflake zugreifen und Operationen darauf durchführen darf. Für jedes sicherungsfähige Objekt gibt es einen Satz von Berechtigungen, die diesem Objekt erteilt werden können. Für bestehende Objekte müssen Berechtigungen für einzelne Objekte erteilt werden (z. B. die SELECT-Berechtigung für die Tabelle mytable). Um die Verwaltung von Berechtigungen zu vereinfachen, ermöglichen zukünftige Berechtigungen die Definition einer anfänglichen Reihe von Berechtigungen für Objekte, die in einem Schema erstellt werden (z. B. die Gewährung der SELECT-Berechtigung für alle neuen Tabellen, die im Schema myschema erstellt werden, an eine bestimmte Rolle).

Die Berechtigungen werden mit den folgenden Befehlen verwaltet:

• GRANT <Berechtigungen> … TO ROLE

• REVOKE <Berechtigungen> … FROM ROLE

• GRANT <Berechtigungen> … TO USER

• REVOKE <Berechtigungen> … FROM USER

In regulären (nicht verwalteten) Schemas ist die Verwendung dieser Befehle auf die Rolle beschränkt, die Eigentümer eines Objekts ist (mit der Berechtigung OWNERSHIP für das Objekt), sowie auf alle Rollen oder Benutzer, die über die globale Berechtigung MANAGE GRANTS für das Objekt verfügen (standardmäßig nur die Rolle SECURITYADMIN).

In verwalteten Zugriffsschemas verlieren Objekteigentümer die Möglichkeit, Berechtigungsentscheidungen zu treffen. Nur der Schemaeigentümer 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 Details dazu finden Sie unter Zugriffssteuerungsrechte.

Rollenhierarchie und Vererbung von Berechtigungen¶

Die folgende Abbildung veranschaulicht die Hierarchie für die vom System definierten Rollen sowie die empfohlene Struktur für zusätzliche, benutzerdefinierte Kontorollen und Datenbankrollen: Die höchste Datenbankrolle in der Beispielhierarchie wird einer angepassten (benutzerdefinierten) Kontorolle zugewiesen. Diese Kontorolle wiederum wird einer anderen kundenspezifischen Rolle in einer empfohlenen Struktur zugewiesen, die es der systemdefinierten Rolle SYSADMIN ermöglicht, die Berechtigungen von kundenspezifischen Kontorollen und Datenbankrollen zu erben:

Ein spezifischeres Beispiel für die Vererbung von Rollenhierarchien und Berechtigungen zeigt das folgende Szenario:

• Rolle 3 wurde Rolle 2 zugewiesen.

• Rolle 2 wurde Rolle 1 zugewiesen.

• Rolle 1 wurde Benutzer 1 zugewiesen.

In diesem Szenario gilt:

• Rolle 2 erbt Berechtigung C.

• Rolle 1 erbt die Berechtigungen B und C.

• Benutzer 1 hat alle drei Berechtigungen.

Eine Anleitung zum Erstellen einer Rollenhierarchie finden Sie unter Erstellen einer Rollenhierarchie.

Autorisierung durch Primärrolle und Sekundärrollen¶

Jede aktive Benutzersitzung hat eine aktuelle Rolle, die auch als Primärrolle bezeichnet wird. Wenn eine Sitzung initiiert wird (z. B. wenn ein Benutzer eine Verbindung über JDBC/ODBC herstellt oder sich bei der Snowflake Weboberfläche anmeldet), wird die aktuelle Rolle anhand der folgenden Kriterien bestimmt:

1. Wenn eine Rolle als Teil der Verbindung angegeben wurde und diese Rolle eine Rolle ist, die dem verbindenden Benutzer bereits zugewiesen wurde, wird die angegebene Rolle zur aktuellen Rolle.

2. Wenn keine Rolle angegeben wurde und eine Standardrolle für den verbindenden Benutzer festgelegt wurde, wird diese Rolle zur aktuellen Rolle.

3. Wenn keine Rolle angegeben wurde und keine Standardrolle für den verbindenden Benutzer festgelegt wurde, wird die Systemrolle PUBLIC verwendet.

Um die aktuelle Rolle für eine Sitzung anzuzeigen, führen Sie die Funktion CURRENT_ROLE aus.

Darüber hinaus kann eine Reihe von Sekundärrollen in einer Benutzersitzung aktiviert werden. Benutzer können SQL-Aktionen auf Objekten in einer Sitzung ausführen, indem sie die aggregierten Berechtigungen verwenden, die der Primärrolle und den Sekundärrollen erteilt wurden. Die Rollen müssen dem Benutzer zugewiesen werden, bevor sie in einer Sitzung aktiviert werden können. Beachten Sie, dass eine Sitzung zwar genau eine aktive Primärrolle haben muss, aber eine Sitzung kann eine beliebige Anzahl von Sekundärrollen gleichzeitig aktivieren.

Die Berechtigung zur Ausführung von CREATE <Objekt>-Anweisungen kommt nur von der Primärrolle. Beim Erstellen eines Objekts wird dessen Eigentümerschaft auf die zu diesem Zeitpunkt aktive Primärrolle übertragen. Für jede andere SQL-Aktion kann jedoch jede Berechtigung, die einer aktiven Primär- oder Sekundärrolle erteilt wurde, zur Autorisierung der Aktion verwendet werden. Wenn beispielsweise eine beliebige Rolle in einer sekundären Rollenhierarchie Eigentümer eines Objekts ist (über die Berechtigung OWNERSHIP für das Objekt verfügt), sind die Sekundärrollen autorisiert, alle DDL-Aktionen für das Objekt durchzuführen. Sowohl die Primärrolle als auch alle Sekundärrollen erben Berechtigungen von allen Rollen, die in ihrer Rollenhierarchie niedriger sind.

Für Unternehmen, deren Sicherheitsmodell eine große Anzahl von Rollen umfasst, von denen jede mit einer feinen Granularität von durch Berechtigungen definierten Autorisierungen ausgestattet ist, vereinfacht die Verwendung von Sekundärrollen die Rollenverwaltung. Alle Rollen, die einem Benutzer zugewiesen wurden, können in einer Sitzung aktiviert werden. Sekundärrollen sind besonders nützlich für SQL-Operationen wie datenbankübergreifende Verknüpfungen (Joins), für die sonst eine übergeordnete Rolle für die Rollen erstellt werden müsste, die Zugriffsrechte auf die Objekte in jeder Datenbank haben.

Im Verlauf einer Sitzung können Sie den Befehl USE ROLE oder USE SECONDARY ROLES ausführen, um die aktuellen Primär- bzw. Sekundärrollen zu ändern. Sie können die Funktion CURRENT_SECONDARY_ROLES verwenden, um alle aktiven Sekundärrollen für die aktuelle Sitzung anzuzeigen.

Wenn Sie ein Objekt erstellen, für dessen Verwendung ein oder mehrere Berechtigungen erforderlich sind, werden bei der Suche nach den Zuweisungen dieser Berechtigungen nur die Primärrolle und die Rollen, die sie direkt oder indirekt erben, berücksichtigt.

Für jede andere Anweisung, die eine oder mehrere Berechtigungen erfordert (z. B. die Abfrage einer Tabelle erfordert die Berechtigung SELECT für eine Tabelle mit der Berechtigung USAGE für die Datenbank und das Schema), werden die Primärrolle, die Sekundärrollen und alle anderen geerbten Rollen bei der Suche nach der Vergabe dieser Berechtigungen berücksichtigt.