Übersicht zur Zugriffssteuerung¶

Framework für die Zugriffssteuerung¶

Der Ansatz von Snowflake zur Zugriffssteuerung kombiniert Aspekte aus den beiden 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.

Die Schlüsselkonzepte zum Verständnis der Zugriffssteuerung in Snowflake 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. Rollen werden wiederum Benutzern zugewiesen. Beachten Sie, dass Rollen auch anderen Rollen zugewiesen werden können, wodurch eine Rollenhierarchie erstellt wird.

• 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 von Snowflake erkannte Benutzeridentität, unabhängig davon, ob sie mit einer Person oder einem Programm verbunden ist.

Im Snowflake-Modell ist der Zugriff auf sicherungsfähige Objekte über Berechtigungen erlaubt, die den Rollen zugewiesen sind, die wiederum anderen Rollen oder Benutzern zugewiesen sind. Durch das Zuweisen einer Rolle zu einer anderen Rolle wird eine Rollenhierarchie erstellt, die im Abschnitt Rollenhierarchie und Vererbung von Berechtigungen (unter diesem Thema) erläutert wird.

Darüber hinaus verfügt jedes sicherungsfähige Objekt über einen Eigentümer, der Zugriff auf andere Rollen gewähren kann. Dieses Modell unterscheidet sich von einem benutzerbasierten Zugriffssteuerungsmodell, bei dem jedem Benutzer oder jeder Gruppe von Benutzern Rechte und Berechtigungen zugewiesen werden. Das Snowflake-Modell bietet ein hohes Maß an Kontrolle und Flexibilität.

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

Die Fähigkeit, SQL-Aktionen auf Objekten auszuführen, wird durch die Berechtigungen definiert, die der aktiven Rolle in einer Benutzersitzung gewährt werden. Im Folgenden finden Sie Beispiele für SQL-Aktionen auf unterschiedlichen Objekten in Snowflake:

• Berechtigung zum Erstellen eines Warehouse

• Berechtigung zum Auflisten der Tabellen, die in einem Schema enthalten sind

• Berechtigung zum Hinzufügen von Daten zu einer Tabelle

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. Auf diese Weise können Benutzer die Rollen wechseln (d. h. wählen, welche Rolle in der aktuellen Snowflake-Sitzung aktiv ist), um verschiedene Aktionen mit separaten Berechtigungen auszufü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 an alle Rollen vererbt, die in der Hierarchie über dieser Rolle liegen. Weitere Informationen zu Rollenhierarchien und zur Vererbung von Berechtigungen finden Sie unter Rollenhierarchie und Vererbung von Berechtigungen (unter diesem Thema).

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. Bei vorhandenen Objekten müssen Berechtigungen dem einzelnen Objekt erteilt werden (z. B. die Berechtigung SELECT für die Tabelle mytable). Um die Berechtigungsverwaltung zu vereinfachen, ermöglichen zukünftige Zuweisungen die Definition eines ersten Satzes von Berechtigungen für Objekte, die in einem Schema erstellt werden (z. B. kann die SELECT-Berechtigung allen neuen Tabellen zugewiesen werden, die im Schema myschema für eine spezifische Rolle erstellt werden).

Berechtigungen werden mit den Befehlen GRANT <Berechtigungen> und REVOKE <Berechtigungen> verwaltet.

• In regulären (d. h. nicht verwalteten) Schemas ist die Verwendung dieser Befehle auf die Rolle beschränkt, die Eigentümer eines Objekts ist (d. h. die Rolle mit OWNERSHIP-Berechtigung für das Objekt), oder auf beliebige Rollen, die die globale Berechtigung MANAGE GRANTS für das Objekt haben (standardmäßig die SECURITYADMIN-Rolle).

• 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 Datenbankrolle auf höchster Ebene in der Beispielhierarchie wird einer kundenspezifischen (d. h. 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.

Durchsetzungsmodell mit 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. ein Benutzer verbindet sich über JDBC/ODBC oder meldet sich bei der Snowflake-Weboberfläche an), 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.

Darüber hinaus können in einer Benutzersitzung mehrere Sekundärrollen 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 immer genau eine aktive Primärrolle haben muss, während gleichzeitig eine beliebige Anzahl von Sekundärrollen aktiviert werden kann.

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ärrollenhierarchie Eigentümer eines Objekts ist (d. h. die Berechtigung OWNERSHIP für das Objekt hat), würden die Sekundärrollen die Ausführung aller DDL-Aktionen auf dem Objekt autorisieren. Sowohl die Primärrolle als auch alle Sekundärrollen erben Berechtigungen von allen Rollen, die in der Rollenhierarchie unter ihnen liegen.

Für Organisationen, deren Sicherheitsmodell eine große Anzahl von Rollen umfasst, von denen jede mithilfe von Berechtigungen über eine fein abgestufte Autorisierung verfügt, 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.

Während einer Sitzung kann der Benutzer den Befehl USE ROLE oder USE SECONDARY ROLES verwenden, um die aktuelle Primär- oder Sekundärrollen zu ändern. Der Benutzer kann 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 ein oder mehrere Berechtigungen erfordert (z. B. erfordert die Abfrage einer Tabelle die SELECT-Berechtigung für eine Tabelle mit USAGE-Berechtigung für Datenbank und Schema), werden die Primärrolle, die Sekundärrollen und alle anderen Rollen, die vererbt werden, bei der Suche nach den Zuweisungen dieser Berechtigungen berücksichtigt.