Übersicht zur Zugriffssteuerung

Unter diesem Thema finden Sie Informationen zu den wichtigsten Aspekten der Zugriffssteuerung in Snowflake.

Unter diesem Thema:

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.

Access control relationships

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:

Hierarchy of securable database objects

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 (in diesem Thema).

Bemerkung

Ein Rolleneigentümer (d. h. die Rolle, die die OWNERSHIP-Berechtigung für die Rolle hat) erbt nicht die Berechtigungen der eigenen Rolle. Die Vererbung von Berechtigungen ist nur innerhalb einer Rollenhierarchie möglich.

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.

Typen von Rollen

Die folgenden Rollentypen sind bis auf ihren Geltungsbereich im Wesentlichen gleich. Beide Typen ermöglichen es Administratoren, den Zugriff auf Objekte in Ihrem Konto zu autorisieren und einzuschränken.

Bemerkung

Sofern in der Produktdokumentation nicht anders angegeben, bezieht sich der Begriff Rolle auf einen der beiden Typen.

Kontorollen

Um SQL-Aktionen auf beliebigen Objekten in Ihrem Konto zuzulassen, erteilen Sie einer Kontorolle Berechtigungen für das Objekt.

Datenbankrollen

Um SQL-Aktionen auf eine einzelne Datenbank und auf ein beliebiges Objekt in der Datenbank zu beschränken, erteilen Sie einer Datenbankrolle in derselben Datenbank Berechtigungen für das Objekt.

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

Weitere Informationen zu Datenbankrollen finden Sie unter:

Instanzrollen

Um den Zugriff auf eine Instanz einer Klasse zu ermöglichen, weisen Sie einer Kontorolle eine Instanzrolle zu.

Eine Klasse kann eine oder mehrere Klassenrollen haben, wobei jeder Rolle unterschiedliche Berechtigungen zugewiesen werden. Wenn eine Instanz einer Klasse erstellt wird, können die Instanzrollen den Kontorollen zugewiesen werden, um den Zugriff auf Instanzmethoden zu gewähren.

Beachten Sie, dass Instanzrollen nicht direkt in einer Sitzung aktiviert werden können. Weisen Sie Kontorollen die Instanzrollen zu, die in einer Sitzung aktiviert werden können.

Weitere Informationen dazu finden Sie unter Instanzrollen.

Aktive Rollen

Aktive Rollen dienen als Quelle der Autorisierung für jede Aktion, die ein Benutzer in einer Sitzung ausführt. Sowohl die Primärrolle als auch alle Sekundärrollen können in einer Benutzersitzung aktiviert werden.

Eine Rolle wird auf eine der folgenden Arten zu einer aktiven Rolle:

  • Wenn eine Sitzung zum ersten Mal ausgeführt wird, werden die Standardrolle und die Standard-Sekundärrollen des Benutzers als Primär- bzw. Sekundärrollen der Sitzung aktiviert.

    Beachten Sie, dass die Eigenschaften der Clientverbindung, die zum Einrichten der Sitzung verwendet werden, explizit die zu verwendende Primärrolle oder die zu verwendenden Sekundärrollen überschreiben können.

  • Das Ausführen einer USE ROLE- oder USE SECONDARY ROLES-Anweisung aktiviert eine andere Primärrolle bzw. andere Sekundärrollen. Diese Rollen können sich im Laufe einer Sitzung ändern, falls einer der beiden Befehle erneut ausgeführt wird.

Systemdefinierte Rollen

ORGADMIN

(Organisationsadministrator)

Rolle, die den Betrieb auf Organisationsebene verwaltet. Dabei gilt Folgendes:

ACCOUNTADMIN

(Kontoadministrator)

Rolle, die die vom System definierten Rollen SYSADMIN und SECURITYADMIN kapselt. Dies ist die oberste Rolle im System und sollte nur einer begrenzten/kontrollierten Anzahl von Benutzern in Ihrem Konto zugewiesen werden.

SECURITYADMIN

(Sicherheitsadministrator)

Rolle, die jede erteilte Objektberechtigung global verwalten sowie Benutzer und Rollen erstellen, überwachen und verwalten kann. Dabei gilt Folgendes:

  • Die Rolle wird die Sicherheitsberechtigung MANAGE GRANTS erteilt, um jede Berechtigung ändern zu können, einschließlich des Widerrufs.

  • Die Rolle erbt die Berechtigungen der Rolle USERADMIN über die Systemrollenhierarchie (d. h. SECURITYADMIN wird die Rolle USERADMIN zugewiesen).

USERADMIN

(Benutzer- und Rollenadministrator)

Rolle, die nur der Benutzer- und Rollenverwaltung gewidmet ist. Dabei gilt Folgendes:

  • Der Rolle werden die Sicherheitsberechtigungen CREATE USER und CREATE ROLE erteilt.

  • Die Rolle kann Benutzer und Rollen im Konto erstellen.

    Die Rolle kann auch Benutzer und Rollen verwalten, deren Eigentümer sie ist. Nur die Rolle mit OWNERSHIP-Berechtigung für ein Objekt (d. h. Benutzer oder Rolle) oder eine höhere Rolle kann die Objekteigenschaften ändern.

SYSADMIN

(Systemadministrator)

Rolle, die die Berechtigung hat, Warehouses und Datenbanken (und andere Objekte) in einem Konto zu erstellen.

Wenn Sie wie empfohlen eine Rollenhierarchie erstellen, die letztendlich alle kundenspezifischen Rollen der SYSADMIN-Rolle zuordnet, hat diese Rolle auch die Möglichkeit, anderen Rollen Berechtigungen für Warehouses, Datenbanken und andere Objekte zu erteilen.

PUBLIC

Pseudorolle, die automatisch jedem Benutzer und jeder Rolle in Ihrem Konto zugewiesen wird. Die Rolle PUBLIC kann wie jede andere Rolle sicherungsfähige Objekte besitzen. Allerdings stehen Objekte, die sich im Eigentum dieser Rolle befinden, per Definition jedem anderen Benutzer und jeder anderen Rolle in Ihrem Konto zur Verfügung.

Diese Rolle wird typischerweise in Fällen verwendet, in denen keine explizite Zugriffssteuerung erforderlich ist und alle Benutzer in Bezug auf ihre Zugriffsrechte als gleichwertig angesehen werden.

Kundenspezifische Rollen

Kundenspezifische Kontorollen können sowohl mit der USERADMIN-Rolle (oder höher) als auch mit jeder Rolle erstellt werden, der die Berechtigung CREATE ROLE erteilt wurde.

Kundenspezifische Datenbankrollen können vom Datenbankeigentümer erstellt werden (d. h. die Rolle mit OWNERSHIP-Berechtigung für die Datenbank).

Standardmäßig ist eine neu erstellte Rolle weder einem Benutzer noch einer anderen Rolle zugewiesen.

Beim Erstellen von Rollen, die als Eigentümer von sicherungsfähigen Objekten im System dienen, empfiehlt Snowflake, eine Hierarchie von kundenspezifischen Rollen zu erstellen, wobei die oberste kundenspezifische Rolle der Systemrolle SYSADMIN zugeordnet ist. Mit dieser Rollenstruktur können Systemadministratoren alle Objekte im Konto verwalten, z. B. Warehouses und Datenbankobjekte, während die Verwaltung von Benutzern und Rollen auf die Rolle USERADMIN beschränkt wird.

Wenn umgekehrt eine kundenspezifische Rolle SYSADMIN nicht über eine Rollenhierarchie zugeordnet wird, können die Systemadministratoren die der Rolle gehörenden Objekte nicht verwalten. Nur Rollen, denen die Berechtigung MANAGE GRANTS erteilt wurde (standardmäßig nur die Rolle SECURITYADMIN), können die Objekte anzeigen und deren Zugriffsrechte ändern.

Eine Anleitung zum Erstellen kundenspezifischer Rollen finden Sie unter Erstellen von kundenspezifischen Rollen.

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:

Role hierarchy example

Bemerkung

ORGADMIN ist eine separate Systemrolle, die Operationen auf Organisationsebene verwaltet. Diese Rolle ist nicht in der Hierarchie der Systemrollen enthalten.

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.

Privilege inheritance for granted roles

In diesem Szenario gilt:

  • Rolle 2 erbt Berechtigung C.

  • Rolle 1 erbt die Berechtigungen B und C.

  • Benutzer 1 hat alle drei Berechtigungen.

Datenbankrollen und Rollenhierarchien

Derzeit gelten für Datenbankrollen folgende Einschränkungen:

  • Wenn eine Datenbankrolle einer Freigabe zugewiesen wird, können dieser Datenbankrolle keine anderen Datenbankrollen zugewiesen werden. Wenn beispielsweise die Datenbankrolle d1.r1 einer Freigabe zugewiesen wurde, dann wird das Zuweisen der Datenbankrolle d1.r2 zu d1.r1 blockiert.

    Außerdem gilt: Wenn eine Datenbankrolle einer anderen Datenbankrolle zugewiesen wurde, kann die zugewiesene Datenbankrolle nicht mehr einer Freigabe zugewiesen werden.

    Andererseits können Datenbankrollen, die einer Freigabe zugewiesen sind, auch anderen Datenbankrollen sowie Kontorollen zugewiesen werden.

  • Kontorollen können nicht Datenbankrollen in einer Rollenhierarchie zugewiesen werden.

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.

Bemerkung

Eine Datenbankrolle kann weder eine Primär- noch eine Sekundärrolle sein. Um die einer Datenbankrolle erteilten Berechtigungen zu übernehmen, weisen Sie die Datenbankrolle einer Kontorolle zu. In einer Sitzung können nur Kontorollen aktiviert werden.

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.

Primary and Secondary Role Operations

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.

Bemerkung

Es gibt in Snowflake kein Konzept eines „Superusers“ oder einer „Superrolle“, mit dem Berechtigungsprüfungen umgangen werden können. Für jeden Zugriff sind entsprechende Zugriffsrechte erforderlich.