Snowflake Roles 101: Zugriffskontrolle umfassend erklärt

Snowflake setzt auf Role-Based Access Control (RBAC), um zu steuern, worauf Nutzer und andere Systeme zugreifen und was sie tun dürfen. In RBAC bedeutet eine bestimmte Rolle zu haben, dass damit bestimmte Privilegien verbunden sind.

Klären wir zunächst die Begriffe:

• User – eine Entität, über die eine Person (oder ein Dienst) eine Verbindung zu Snowflake herstellen kann.
• Object – eine Entität, auf die ein User zugreifen kann (z. B. Tabelle, View, Datenbank), sofern er die entsprechenden Privilegien besitzt.
• Privilege – eine Operation, die ein User auf einem Object ausführen darf, sofern seiner Rolle dieses Privileg gewährt wurde.
• Role – eine Vermittlungs-Entität zwischen Usern und Privilegien. Privilegien werden Rollen gewährt, und Rollen werden Usern gewährt.

Kurz gefasst, in den Worten von Snowflake:

Privilegien werden Rollen gewährt, und Rollen werden Usern gewährt, um festzulegen, welche Operationen die User auf Objekten im System ausführen können.

Auf diesen vier Schlüsselbegriffen bauen die folgenden Abschnitte und Diagramme schrittweise auf – bis wir bei einem minimalen, aber vollständigen Setup für die Zugriffskontrolle landen.

Users

Ein Snowflake User ist eine Identität, die sich mit einem Snowflake-Account verbinden und eine Reihe erlaubter Operationen ausführen kann. Jede Person in Ihrem Datenteam sollte einen eigenen Snowflake User haben, mit dem sie sich verbindet und Abfragen ausführt. Ein Snowflake User kann auch von einem Drittsystem genutzt werden – etwa von BI-Tools (z. B. Tableau oder Looker) oder ELT-Tools (z. B. Stitch oder Fivetran).

Was Snowflake User tun dürfen, ist letztlich das Kernthema der Zugriffskontrolle.

Objects

Objects sind die Snowflake-Primitive, auf die Zugriff gewährt werden kann. Die offensichtlichsten Objekte sind Datenbanken, Schemas und Tabellen, doch auch Objekte auf Account-Ebene wie Warehouses, Storage Integrations usw. gehören dazu.

Hier einige typische Beispiele für Snowflake Objects:

Securable Object	Ebene	Beschreibung
Database	Account-Ebene	Datenbanken sind die zentralen Objekte, die alle anderen Securable Objects isolieren und logisch gruppieren.
Schema	Datenbank-Ebene	Eine logische Gruppierung von Objekten wie Tabellen, Views, Stages usw.
Table	Schema-Ebene	Das Objekt, das Daten enthält und physischen Speicher belegt. In den meisten Fällen sind Tabellen das Herzstück dessen, was Snowflake nützlich macht. Es gibt verschiedene Arten von Tabellen für unterschiedliche Anwendungsfälle.
View	Schema-Ebene	Eine Tabelle in Verkleidung. Sie bietet Zugriff auf Daten, belegt aber keinen Speicher. Ein View ist als Abfrage auf andere Tabellen definiert. Es gibt verschiedene Arten von Views für unterschiedliche Anwendungsfälle.
Virtual Warehouse	Account-Ebene	Die zentralen Compute-Ressourcen, die zum Ausführen von Abfragen oder zum Laden von Daten in Snowflake benötigt werden.
Storage Integration	Account-Ebene	Ein Objekt, das einen S3-Bucket (sowie GCS und Azure Blob Storage) mit Snowflake verbindet und Usern erlaubt, Daten zu laden, zu entladen oder die Bucket-Inhalte direkt abzufragen.
Snowpipe	Schema-Ebene	Ein Objekt, das das Laden von Daten aus S3 (oder GCS und Azure Blob Storage) in Tabellen automatisiert, sobald neue Dateien im Bucket eintreffen.
Stage	Schema-Ebene	Speicherort für Datendateien (CSV, Parquet usw.) im Cloud Storage. Es gibt zwei Arten von Stages: internal (von Snowflake verwalteter Cloud Storage) und external (selbstverwalteter Cloud Storage).

Privileges

Privilegien sind ein zentrales Konzept der Zugriffskontrolle. Sie erlauben das Ausführen einer einzelnen Operation oder manchmal einer Reihe von Operationen auf einem Objekt.

Bei einer Snowflake-Tabelle könnte ein User beispielsweise das Privileg haben, mit SELECT Daten daraus abzufragen, mit INSERT Zeilen einzufügen, mit DELETE Daten zu löschen usw. In einer Snowflake-Datenbank könnte ein User mit CREATE SCHEMA ein Schema anlegen oder die Datenbank mit MONITOR überwachen.

Die folgende Tabelle beschreibt kurz einige der wichtigsten Privilegien, die auf zentrale Objekte gewährt werden können.

Object	Object Privilege	Beschreibung
Database	USAGE	Ermöglicht das Verwenden und Anzeigen der Datenbank; für Aktionen darin sind weitere Privilegien erforderlich.
	MONITOR	Ermöglicht das Ausführen eines DESCRIBE-Befehls.
	CREATE SCHEMA	Ermöglicht das Erstellen (oder Klonen) eines Schemas in der Datenbank.
	IMPORTED PRIVILEGES	Gilt nur für geteilte Datenbanken und erlaubt es anderen Account-Rollen, auf die geteilten Objekte zuzugreifen. Mehr zu Imported Privileges: https://docs.snowflake.com/en/user-guide/data-share-consumers#option-1-objects-in-a-share-not-associated-with-a-database-role.
Schema	USAGE	Ermöglicht das Sehen und Verwenden des Schemas; für Schema-Objekte sind weiterhin zusätzliche Privilegien nötig, um sie zu sehen oder Befehle darauf auszuführen.
	MONITOR	Ermöglicht das Ausführen eines DESCRIBE-Befehls.
	CREATE TABLE / CREATE VIEW / CREATE STAGE / CREATE PIPE	Ermöglicht das Erstellen einer Tabelle / eines Views / einer Stage / einer Pipe im Schema.
Table	SELECT	Ermöglicht das Abfragen der Tabelle, um Daten auszulesen.
	INSERT	Ermöglicht das Einfügen von Zeilen in die Tabelle.
	UPDATE	Ermöglicht das Aktualisieren bestehender Daten in der Tabelle.
	TRUNCATE	Ermöglicht das Löschen aller Daten aus der Tabelle.
	DELETE	Ermöglicht das Löschen aller oder einer bestimmten Teilmenge von Zeilen aus der Tabelle.
View	SELECT	Ermöglicht das Abfragen des Views, um Daten auszulesen (unabhängig von den zugrunde liegenden Tabellen und den darauf gewährten Privilegien).
Stage	USAGE	Ermöglicht das Verwenden der external Stage in einer SQL-Anweisung.
	READ	Ermöglicht das Ausführen aller Befehle, die aus der internal Stage lesen (GET, LIST, COPY INTO).
	WRITE	Ermöglicht das Ausführen aller Befehle, die in die internal Stage schreiben (PUT, REMOVE, COPY INTO).

Eine vollständige Liste der verfügbaren Object Privileges für die Snowflake-Zugriffskontrolle finden Sie hier.

Diese Liste ist beim Auditieren von Zugriffen Gold wert – denn Privilegien werden je nach Ebene, auf der ein Objekt erstellt wird (Account-, Datenbank- oder Schema-Ebene), unterschiedlich gewährt.

Ownership-Privileg

Snowflake setzt auf Role-Based Access Control (RBAC) […]

👆Der erste Satz dieses Abschnitts stimmt nur zum Teil. Snowflake kombiniert RBAC mit einem zentralen Konzept aus einem anderen Zugriffsmodell – der Discretionary Access Control (DAC). In DAC muss jedes Objekt einen Eigentümer haben.

In Snowflakes DAC-Umsetzung gehört jedes Objekt der Rolle, mit der es erstellt wurde. Dass eine Rolle ein Objekt besitzt, bedeutet, dass sie das OWNERSHIP-Privileg darauf hat.

Wichtig: Nicht User besitzen Objekte, sondern Rollen. Wenn alle Analysten in Ihrem Datenteam dieselbe Rolle haben, gehören die Objekte, die ein Analyst erstellt, faktisch allen Analysten gemeinsam.

Beachten Sie: Das OWNERSHIP-Privileg auf einem Objekt lässt sich an eine andere Rolle übertragen. Sie können den Besitz einer Tabelle z. B. an eine "mächtigere" Rolle übergeben, um einzuschränken, wer anderen Rollen Zugriff darauf gewähren darf.

Privilegien auf zukünftige Objekte

Beim initialen Einrichten der Zugriffskontrolle existieren manche Objekte noch gar nicht. Sie wissen aber schon im Voraus, dass eine bestimmte Rolle nach deren Erstellung Zugriff darauf haben soll. Snowflake erlaubt uns, hier proaktiv vorzugehen und bestimmte Privilegien auf zukünftige Objekte zu gewähren.

So lässt sich einer Rolle ANALYST z. B. das SELECT-Privileg auf zukünftige Tabellen in der Datenbank GOLDEN_DB oder auf zukünftige Tabellen in einem bestimmten Schema gewähren. Mehr zur Priorität von Future Grants finden Sie in dieser Snowflake-Doku.

Rollen

Snowflake-Rollen lassen sich wie Schlüssel verstehen. 🔑 Sie haben einen Schlüssel zu Ihrer Wohnung, einen fürs Auto und vielleicht einen fürs Büro. Wenn Sie nette Nachbarn haben, besitzen die vielleicht einen Zweitschlüssel zu Ihrer Wohnung (für den Notfall). Die Wohnungsschlüssel geben sowohl Ihnen als auch den Nachbarn Zugang.

Genauso öffnet eine Snowflake-Rolle, die einem User gewährt wurde, den Zugang zu verschiedenen Operationen und Objekten. Die folgende Abbildung zeigt, wie sich unser Organigramm auf Snowflake-Rollen abbilden lässt.

In Snowflake gibt es drei zentrale Rollentypen:

• Account Roles
• Database Roles
• Instance Roles

Daneben gibt es noch Application Roles, die an Snowflake Native Applications gebunden sind – ein spannendes Thema, das einen eigenen Beitrag verdient und den Rahmen von Snowflake Roles 101 sprengen würde.

Account Role

Die ursprünglichen Snowflake-Rollen, die Account Roles, sind die Standardrollen, die:

• Privilegien auf allen Securable Objects im Account erhalten können,
• einen accountweit eindeutigen Namen haben und
• an User oder andere Account Roles vergeben werden können.

Database Role

Wie der Name schon andeutet, ist eine Database Role an eine bestimmte Datenbank gebunden und:

• kann nur Privilegien für Objekte dieser Datenbank (Schemas, Tabellen, Views usw.) erhalten,
• ihr Name ist nur innerhalb der Datenbank eindeutig, in der sie angelegt wurde,
• sie kann anderen Database Roles (derselben Datenbank) und Account Roles gewährt werden,
• sie kann nicht direkt an User vergeben werden, und
• eine Database Role hat standardmäßig das USAGE-Privileg auf ihre Datenbank.

Instance Role

Instance Roles sind der am seltensten verwendete Rollentyp. Sie sind an eine Snowflake Class Instance gebunden, werden an Account Roles vergeben und ermöglichen Usern das Ausführen von Methoden der Class Instance.

Zum Zeitpunkt dieses Beitrags kann nur Snowflake selbst Classes erstellen. Mehr zu den verfügbaren Snowflake Classes finden Sie hier.

Welchen Rollentyp sollten Sie verwenden?

Wenn Sie gerade erst starten, kommen Sie mit Account Roles sehr weit.

Spannend wird es, sobald Sie Database Roles ins Spiel bringen und ihr Potenzial nutzen, um Ihre Konfiguration zu vereinfachen und zu standardisieren: Der Eigentümer einer Datenbank kann Privilegien darauf selbst verwalten, ohne ACCOUNTADMIN zu benötigen.

Und falls Sie zusätzlich Snowflake Shares zum Teilen Ihrer Daten verwenden, lässt sich die Zugriffskontrolle mit Database Roles deutlich einfacher konfigurieren.

Rollen können auch anderen Rollen gewährt werden. So entsteht eine Rollenhierarchie.

Am einfachsten lässt sich eine Rollenhierarchie an einem Beispiel zeigen. In der folgenden Hierarchie verfügt Splinter mit seiner Rolle SYSADMIN über die Vereinigungsmenge der Privilegien der Rollen DATA_ENG_ROLE, ANALYST_ROLE und DB_MANAGER_ROLE, während Kim nur die Privilegien von DATA_ENG_ROLE und DB_MANAGER_ROLE hat.

Wenn Sie einen Snowflake-Account anlegen und Admin / Users & Roles öffnen, sehen Sie eine Reihe von Rollen, die Snowflake standardmäßig anlegt. Diese systemdefinierten Rollen lassen sich weder löschen, noch können die ihnen zugewiesenen Standard-Privilegien geändert werden. Jede hat ihren festen Zweck:

• ACCOUNTADMIN – die "Gott-Rolle", die alles auf Account-Ebene darf. Gewähren Sie sie bewusst und sparsam. Beachten Sie: ACCOUNTADMIN erbt sämtliche Privilegien von SECURITYADMIN und SYSADMIN.
• SECURITYADMIN – diese Rolle besitzt das accountweite Privileg MANAGE GRANTS und kann damit Grants auf allen Objekten im Account an andere Rollen vergeben oder entziehen. SECURITYADMIN erbt zudem alle Privilegien von USERADMIN.
• USERADMIN – wie der Name sagt: Diese Rolle dient dem Erstellen und Verwalten von Usern (über die accountweiten Privilegien CREATE USER und CREATE ROLE).
• SYSADMIN – diese Rolle darf alle Objekte im Account erstellen (einschließlich Datenbanken, Warehouses und weiterer Schema-Objekte).
• PUBLIC – jeder User im Account erhält standardmäßig die Rolle PUBLIC. Ohne explizit gewährte Zugriffe kann sie wenig ausrichten. Trotzdem: Achten Sie sorgfältig darauf, ihr nicht versehentlich Privilegien auf wichtige Daten zu gewähren – sonst können alle User darauf zugreifen. Oder noch besser: Vergeben Sie überhaupt keine Privilegien an PUBLIC. 😉

Eine Sonderrolle spielt ORGADMIN. Sie kommt für Operationen auf Organisationsebene zum Einsatz – etwa das Anlegen weiterer Snowflake-Accounts – und fügt sich nicht sauber in die Standard-Rollenhierarchie ein.

Beim Anlegen eigener Rollen und beim Aufbau einer Rollenhierarchie empfiehlt Snowflake, dass alle Custom Roles letztlich Nachfahren von SYSADMIN sind.

Aus unserer Arbeit mit zahlreichen Snowflake-Accounts wissen wir: Häufig wird der Großteil der Datenbankobjekte von ACCOUNTADMIN erstellt – und gehört entsprechend dieser Rolle. Das ist grundsätzlich schlechte Praxis: Es deutet darauf hin, dass kaum über Zugriffskontrolle nachgedacht wird, und ist ein Hinweis darauf, dass ACCOUNTADMIN als Standardrolle verwendet wird – was zu folgenschweren Fehlern wie dem versehentlichen Löschen von Daten oder Usern führen kann. In Teil II dieser Beitragsreihe gehen wir auf Best Practices für die Zugriffskontrolle ein. 🙌

Standardrolle eines Users

Beim Verbinden mit Snowflake startet ein User eine Session, für die in den meisten Fällen eine Rolle gesetzt werden muss. Wird keine angegeben, greift Snowflake auf die Default Role des Users zurück.

Secondary Roles

Mit Secondary Roles lassen sich die Zugriffsrechte mehrerer Rollen gleichzeitig nutzen. Die meisten Snowflake-Kunden arbeiten nur mit Primary Roles (also einer einzigen Rolle), doch Secondary Roles sind eine mächtige Funktion, die das Zusammenführen mehrerer Rollen oft überflüssig macht.

Analog zum Setzen der Primary Role per use role innerhalb einer Session können Sie use secondary roles aufrufen. Der wesentliche Unterschied: Dieser Befehl akzeptiert zwei Optionen:

1. use secondary roles all aktiviert alle Rollen, auf die der User Zugriff hat.
2. use secondary roles none deaktiviert Secondary Roles.

Schon klar, schon klar – "Jetzt aber endlich SQL!! 💢", höre ich Sie.

Fügen wir das Puzzle mit einem End-to-End-Beispiel zusammen: Wir richten einen frischen Snowflake-Account ein, sodass Kim und Rufus damit genau das tun können, was sie brauchen.

Zusammengefasst:

• Wir legen User, Rollen und die Datenbank an.

use role SECURITYADMIN;
create role DATA_ENGINEER_ROLE;
create role DB_MANAGER_ROLE;
create role ANALYST_ROLE;

use role USERADMIN;
create user KIM;

use role SYSADMIN; -- objects are owned by the active role
create database SOURCE_DB;
create warehouse ANALYSIS_WH;

• Privilegien auf Securable Objects werden an Rollen vergeben.

use role SECURITYADMIN;

grant USAGE, MODIFY, CREATE SCHEMA
	on database SOURCE_DB to role DB_MANAGER_ROLE;
grant USAGE on database SOURCE_DB to role ANALYST_ROLE;

grant USAGE, OPERATE
	on warehouse ANALYSIS_WH to role ANALYST_ROLE;

• Rollen werden zu einer Hierarchie verknüpft, sodass Privilegien vererbt werden.

use role SECURITYADMIN;

grant role DB_MANAGER_ROLE to role DATA_ENGINEER_ROLE;
grant role ANALYST_ROLE to role DATA_ENGINEER_ROLE;
grant role DATA_ENGINEER_ROLE to role SYSADMIN;

• User erhalten Zugriff auf Securable Objects, indem ihnen Rollen gewährt werden.

use role SECURITYADMIN;

grant role DATA_ENGINEER_ROLE to user KIM;
grant role ANALYST_ROLE to user RUFUS;

Damit haben wir eine Konfiguration, die:

1. Kim erlaubt:
2. Schemas in SOURCE_DB zu erstellen und die Datenbank zu nutzen;
3. das ANALYSIS_WH zu nutzen und zu steuern.
4. Rufus erlaubt:
5. SOURCE_DB zu nutzen (falls Sie sich fragen, ob zusätzliche Privilegien auf Schemas und Datenbanken fehlen – ja, 💯 richtig, sie sind der Einfachheit halber weggelassen);
6. das ANALYSIS_WH zu nutzen und zu steuern.

So einfach diese Konfiguration auch ist – sie liefert alle Bausteine, die Sie brauchen, um Ihr eigenes RBAC-Modell in Snowflake umzusetzen. In Teil II gehen wir auf Best Practices für RBAC in Snowflake ein und geben Ihnen konkrete, klar positionierte Empfehlungen.