Ü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. 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. Benutzer mit entsprechendem Zugriff können benutzerdefinierte Rollen erstellen. 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. Systemdefinierte Rollen können nicht gelöscht werden. Darüber hinaus können die diesen Rollen von Snowflake erteilten Berechtigungen nicht widerrufen werden.

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, empfehlen wir, diese zusätzlichen Berechtigungen einer benutzerdefinierten Rolle zu erteilen und diese benutzerdefinierte Rolle dann der systemdefinierten Rolle zuzuweisen.

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.

    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. Außerdem muss die Rolle über die globale CREATE USER- bzw. CREATE ROLE-Berechtigung verfügen, um Benutzer oder Rollen zu ändern, deren Eigentümer sie ist.

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.

Durchsetzungsmodell: 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.

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.

Wenn ein Benutzer versucht, ein Objekt zu erstellen, vergleicht Snowflake die für die aktuelle Rolle in der Sitzung des Benutzers verfügbaren Berechtigungen mit den zum Erstellen des Objekts erforderlichen Berechtigungen. Bei allen anderen SQL-Aktionen, die der Benutzer versucht, vergleicht Snowflake die für die aktuellen Primär- und Sekundärrollen verfügbaren Berechtigungen mit den für die Ausführung der Aktion auf den Zielobjekten erforderlichen Berechtigungen. 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.