Übersicht zur Zugriffssteuerung

Die Zugriffssteuerungsrechte bestimmen, wer auf bestimmte Objekte in Snowflake zugreifen und Operationen darauf durchführen darf.

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. 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 Benutzergruppe 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 das Kundenkonto, in dem sich die Objekte USER, ROLE, WAREHOUSE und DATABASE befinden. Alle anderen sicherungsfähigen Objekte (wie TABLE, FUNCTION, FILE FORMAT, STAGE, SEQUENCE usw.) sind in einem SCHEMA-Objekt einer DATABASE enthalten. Diese Hierarchie von Objekten und Containern ist im Folgenden dargestellt:

Hierarchy of securable database objects

Jedes sicherungsfähige Objekt ist Eigentum einer einzigen Rolle, die typischerweise die Rolle ist, mit der das Objekt erstellt wurde. Wenn diese Rolle Benutzern zugewiesen wird, haben sie effektiv die gemeinsame Kontrolle über das sicherungsfähige Objekt. Die Rolle des Eigentümers verfügt 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.

Der Zugriff auf Objekte wird durch Berechtigungen definiert, die Rollen erteilt werden. Im Folgenden finden Sie Beispiele für Berechtigungen für verschiedene Objekte 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.

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.

Es gibt eine kleine Anzahl von systemdefinierten Rollen in einem Snowflake-Konto. Benutzer mit entsprechendem Zugriff können die systemdefinierten Rollen ändern und benutzerdefinierte Rollen erstellen.

Systemdefinierte Rollen

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 (z. B. wird SECURITYADMIN die Rolle USERADMIN erteilt).

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 und verwalten (vorausgesetzt, die Eigentümerschaft an diesen Rollen oder Benutzern wurde nicht auf eine andere Rolle übertragen).

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 benutzerdefinierten 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.

Benutzerdefinierte Rollen

Benutzerdefinierte Rollen (d. h. alle anderen Rollen als die vom System definierten Rollen) können sowohl von den SECURITYADMIN-Rollen als auch von jeder Rolle erstellt werden, der die Berechtigung CREATE ROLE erteilt wurde. Standardmäßig ist die neu erstellte Rolle weder einem Benutzer noch einer anderen Rolle zugewiesen.

Beim Erstellen von Rollen, die als Eigentümer von Objekten im System dienen, empfehlen wir, eine Hierarchie von benutzerdefinierten Rollen zu erstellen, wobei die oberste benutzerdefinierte 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 Rollen SECURITYADMIN oder ACCOUNTADMIN beschränkt wird.

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

Berechtigungen

Für jedes sicherungsfähige Objekt gibt es eine Reihe 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. So kann beispielsweise die SELECT-Berechtigung allen neuen Tabellen zugewiesen werden, die im Schema myschema erstellt werden.

Berechtigungen werden mit den Befehlen GRANT und REVOKE 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 die Berechtigung OWNERSHIP für das Objekt hat), oder auf Rollen, die die globale Berechtigung MANAGE GRANTS für das Objekt haben (normalerweise die SECURITYADMIN-Rolle).

  • In verwalteten Zugriffsschemas verlieren Objekteigentümer die Möglichkeit, Berechtigungsentscheidungen zu treffen. Nur der Schemabesitzer 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.

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 Rollen:

../_images/system-role-hierarchy.png

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.

Erzwingungsmodell

Jede aktive Benutzersitzung hat eine „aktuelle Rolle“. 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.

Während einer Sitzung kann der Benutzer den Befehl USE ROLE verwenden, um die aktuelle Rolle zu ändern. Wenn der Rolle andere Rollen zugewiesen sind, hat die Sitzung des Benutzers Berechtigungen in Höhe der Summe der Berechtigungen der aktuellen Rolle und aller Berechtigungen der Rollen, die der aktuellen Rolle innerhalb der Rollenhierarchie zugewiesenen sind.

Wenn ein Benutzer versucht, eine Aktion auf einem Objekt auszuführen, vergleicht Snowflake die in der Sitzung des Benutzers verfügbaren Berechtigungen mit den Berechtigungen, die für das Objekt für diese Aktion erforderlich sind. Wenn die Sitzung über die erforderlichen Berechtigungen für das Objekt verfügt, ist die Aktion zulässig.

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.