Unsere Top 7 Best Practices für Snowflake RBAC

Wenn Sie Ihr Zugriffsmodell entwerfen und Berechtigungen an Nutzer in Ihrem Unternehmen vergeben, sollten Sie eine Struktur anstreben, in der Nutzer genau die Berechtigungen erhalten, die sie für ihre Arbeit brauchen – nicht mehr und nicht weniger. Warum sollte die neue Junior Finance Analystin Tabellen löschen dürfen, wenn sie lediglich eine Bilanztabelle abfragen muss?

Dieses Konzept ist als Principle of Least Privilege bekannt. Angewendet auf Ihr Snowflake-Zugriffsmodell bringt es eine Reihe von Vorteilen mit sich:

• Geringeres Risiko und kleinere Angriffsfläche bei externen Bedrohungen: Wer den Nutzerzugriff auf das Nötigste beschränkt, senkt das Risiko versehentlicher oder böswilliger Datenabflüsse. Und falls es doch zu einem Vorfall kommt, bleibt der Schaden auf jene Datenbankbereiche begrenzt, auf die die kompromittierten Konten zugreifen können.
• Weniger Risiko für Systemschäden, mehr Stabilität: Eingeschränkte Zugriffe verhindern Änderungen, die Datenintegrität oder Stabilität gefährden könnten. Teammitglieder mit eingeschränktem Aufgabenbereich sollten schlicht keine Datenbanken löschen dürfen! :)
• Einfacheres Auditing und Monitoring: Wer von vornherein nur das Minimum an Berechtigungen vergibt, hat auch weniger zu überwachen und zu pflegen.
• Vereinfachte Compliance: Das Prinzip erleichtert die Einhaltung regulatorischer Vorgaben rund um den Datenschutz – etwa DSGVO oder HIPAA –, indem der Zugriff auf sensible Daten auf das strikt Notwendige beschränkt wird.

Das Principle of Least Privilege ist ein guter Ausgangspunkt, weil es einen sinnvollen Kompromiss zwischen Sicherheit und Wartungsaufwand bietet. Manche Unternehmen bevorzugen schlankere Sicherheitsmodelle und nehmen dafür höhere Risiken in Kauf, andere fahren strengere Praktiken. Es lohnt sich, das Zero-Trust-Sicherheitsmodell und dessen Bezug zum Principle of Least Privilege näher anzusehen.

In unserem letzten Artikel haben wir verschiedene Rollentypen beschrieben: Account Roles, Database Roles und sogar Instance Roles. Sie unterscheiden sich grundlegend und technisch. Der Einfachheit halber konzentrieren wir uns in diesem Artikel auf Account Roles.

Hier verfolgen wir einen anderen Ansatz, um Rollen zu definieren: nach ihrem Zweck. Drei Rollentypen möchten wir vorstellen:

• Access Roles steuern den Zugriff auf Ihre Datenbanken;
• Functional Roles werden an Snowflake-Nutzer im Unternehmen vergeben; das Zugriffsniveau ergibt sich aus den zugewiesenen Access Roles (gemäß Principle of Least Privilege);
• Service Roles funktionieren genau wie Functional Roles, sind aber für Services gedacht und nicht für (menschliche) Endnutzer.

Hinweis: Es gibt keinen technischen Unterschied zwischen Access, Functional und Service Roles. Alle werden als Account Roles angelegt.

Access Roles

Access Roles regeln die unterschiedlichen Zugriffsebenen auf Datenbanken und Datenbankobjekte. Betrachten Sie sie als die untersten Bausteine Ihrer Hierarchie.

Ein einfacher Ansatz: pro Datenbank jeweils eine READ- und eine READWRITE-Rolle anlegen.

• READ: vergibt SELECT-Berechtigungen auf alle Tabellen/Views der Datenbank.
• READWRITE: vergibt SELECT-, INSERT-, UPDATE- und DELETE-Berechtigungen.

Das ist ein solider Startpunkt; je nach Anforderungen Ihres Unternehmens lassen sich aber auch feiner granulierte Access Roles bauen (z. B. für einzelne Schemata einer Datenbank).

Functional Roles

Functional Roles orientieren sich an Geschäftsfunktionen und bündeln eine passende Auswahl an Access Roles. Eine Rolle DATA_ANALYST könnte z. B. die Berechtigungen der READ-Access-Roles für mehrere Datenbanken erben, während eine Rolle DATA_ENGINEER die entsprechenden READWRITE-Rollen erbt.

Diese Rollen werden anschließend an Endnutzer vergeben. Sie lassen sich passgenau aus den Access Roles zusammensetzen – immer mit dem Principle of Least Privilege im Hinterkopf.

Service Roles

Im Kern entspricht eine Service Role einer Functional Role, wird aber nicht an Mitarbeitende, sondern an Service Accounts vergeben. Sie kommen bei Drittanbieter-Tools zum Einsatz – etwa BI- und Dashboard-Plattformen oder anderen SaaS-Diensten, die READ- oder READWRITE-Zugriff auf Snowflake-Datenbankobjekte brauchen (z. B. Airbyte, Rudderstack, Mode).

Wie Functional Roles lassen sich Service Roles bedarfsgerecht aus Access Roles zusammenstellen – stets mit Blick auf das Principle of Least Privilege.

Mit diesen drei Rollentypen haben Sie alle Bausteine für eine schlanke und wirksame Rollenhierarchie.

Ein zentrales Prinzip der Softwareentwicklung lautet: keine Wiederholungen im Code. Das Akronym D.R.Y. steht für "Don't Repeat Yourself". Mit Access, Functional und Service Roles können Sie nun skizzieren, wie Ihre Rollenhierarchie aussehen soll. Vier iterative Schritte helfen dabei:

1. Benötigte Functional und Service Roles definieren

Sammeln Sie die Anforderungen der verschiedenen Snowflake-Nutzer im Unternehmen und erstellen Sie eine Liste der nötigen Functional Roles samt erforderlicher Zugriffsebenen. Aus dieser Liste leiten Sie anschließend die nötigen Access Roles ab.

2. Access Roles anlegen

Sobald die Anforderungsliste steht, sehen Sie, welche Access Roles Sie brauchen. Legen Sie diese an und vergeben Sie die passenden Berechtigungen auf die jeweiligen Datenbankobjekte (z. B. FINANCE_DB_READ_ROLE).

3. Functional und Service Roles erstellen (und Access Roles zuweisen)

Mit den Access Roles als Grundlage haben Sie alles, um Functional Roles für Ihre Kolleginnen und Kollegen sowie Service Roles für die Dienste zu bauen. Weisen Sie den neu erstellten Functional- bzw. Service Roles (z. B. DATA_ANALYST) die passenden Access Roles zu, damit die ursprünglich definierten Anforderungen erfüllt werden.

4. Functional Roles an Nutzer und Service Roles an Service Accounts vergeben

Ihre Rollenhierarchie steht! Der letzte Schritt: die Functional Roles den Snowflake-Nutzern und die Service Roles den Service Accounts zuweisen. Sind Anpassungen nötig, wiederholen Sie einfach die Schritte 1 bis 4.

Vermeiden Sie…

⛔ Access Roles nicht direkt an Endnutzer oder Service Accounts vergeben

Wenn Sie die Functional-Roles-Ebene überspringen und einem Nutzer Access Roles direkt zuweisen, müssen Sie das bei jedem neuen Mitarbeitenden mit ähnlichen Aufgaben erneut tun. Und jede Anpassung müssen Sie manuell für mehrere Nutzer pflegen.

Mit einer Functional Role gibt es nur eine zentrale Stelle für Anpassungen. Diese Änderungen wirken sich automatisch auf alle Nutzer aus, denen die jeweilige Functional Role zugewiesen ist. Die Access-Roles-Ebene dient dazu, den Zugriff auf Datenbankobjekte über Ihren Account hinweg zu standardisieren – nicht zur direkten Vergabe!

⛔ Functional Roles nicht an andere Functional Roles vergeben

Halten Sie es einfach! Jede Functional Role sollte sich ausschließlich aus Access Roles zusammensetzen. Abhängigkeiten zwischen Functional Roles schaffen unnötige Komplexität – gerade wenn Ihr Unternehmen wächst und sich Rollenprofile mit der Zeit verändern.

Sie haben Access Roles für eine Datenbank angelegt, aber laufend kommen neue Schemata und Tabellen hinzu – und Sie aktualisieren ständig die Berechtigungen? Dann ist dieser Tipp für Sie. Sie können Berechtigungen auf zukünftige Schemata innerhalb einer Datenbank sowie auf zukünftige Tabellen, Views oder andere Objekte vergeben. Bei jedem neu erstellten Objekt wird die Berechtigung dann automatisch ergänzt.

Future Grants beim Anlegen von Access Roles reduzieren den Wartungsaufwand spürbar: Ihre Rollen verfügen automatisch über die richtigen Berechtigungen, sobald neue Datenbankobjekte entstehen. Kein erneutes grant-Statement für jedes neue Objekt!

Eine frisch angelegte Custom Role existiert zunächst isoliert – und das gilt ebenso für alle Objekte, die diese Rolle erstellt. Standardmäßig kann nicht einmal ACCOUNTADMIN die von einer Custom Role erstellten Objekte ändern oder löschen. Hat eine Rolle keine übergeordnete Rolle, riskieren Sie also Objekte im Account, auf die ausschließlich diese eine Rolle zugreifen kann.

Wenn Sie eine Custom Role an SYSADMIN vergeben, stellen Sie sicher, dass zumindest SYSADMIN (und damit auch ACCOUNTADMIN) die von dieser Rolle erstellten Objekte verwalten kann.

Etablieren Sie deshalb folgende Best Practice: Vergeben Sie Ihre Functional Roles standardmäßig an SYSADMIN.

Snowsight bietet eine praktische Funktion, mit der Sie die bestehende Rollenhierarchie in Ihrem Snowflake-Account visualisieren. So sehen Sie auf einen Blick, welche Rollen angelegt sind und wie sie zusammenhängen.

Unter Users & Roles finden Sie die Option Graph. Mit Focus nehmen Sie eine bestimmte Rolle sowie ihre über- und untergeordneten Rollen genauer unter die Lupe.

Oder anders gesagt: Verwenden Sie für jede administrative Tätigkeit die passende Rolle. Denken Sie an das Principle of Least Privilege!

Die Rolle ACCOUNTADMIN hat standardmäßig weit mehr Berechtigungen, als Sie im täglichen Betrieb brauchen. Verwenden Sie sie nur, wenn es einen triftigen Grund gibt. Für gängige Aufgaben bieten sich diese Alternativen an:

• Wenn Sie Nutzer oder Rollen anlegen möchten, nutzen Sie USERADMIN.
• Wenn Sie Berechtigungen verwalten (z. B. einem Nutzer eine Rolle zuweisen), nutzen Sie SECURITYADMIN.
• Wenn Sie Objekte erstellen, etwa Datenbanken, Schemata oder Virtual Warehouses, nutzen Sie SYSADMIN.
• Wenn Sie Datenbanken oder Datenbankobjekte wie Tabellen, Views o. ä. erstellen, nutzen Sie ebenfalls SYSADMIN.
• Für Ad-hoc-Datenoperationen auf einer bestimmten Tabelle (etwa SELECT oder INSERT) nutzen Sie eine passende Functional Role.
• Und schließlich: Wenn Sie einen Drittanbieter-Service an Snowflake anbinden, verwenden Sie auf keinen Fall ACCOUNTADMIN! Legen Sie stattdessen eine geeignete Service Role an :)

Beispiel: Das SELECT-Paket dbt-snowflake-monitoring benötigt die spezielle Berechtigung IMPORTED PRIVILEGES auf der Datenbank SNOWFLAKE, die nur ACCOUNTADMIN vergeben darf. Nutzen Sie in diesem Fall USERADMIN, um eine Access Role nur für diese eine Berechtigung anzulegen, vergeben Sie die Berechtigung mit ACCOUNTADMIN und weisen Sie die Access Role anschließend mit SECURITYADMIN einer Service Role für dbt zu.

Ausgangslage

Sie sind Data Engineer in einem Data Team und beginnen, Snowflake im Unternehmen einzuführen. Sie sollen drei Datenbanken verwalten:

Kurz beschrieben:

• HR_DB enthält Daten zu Mitarbeitenden und Personalbestand;
• FINANCE_DB enthält Finanzdaten wie Bilanzen und Abschlüsse;
• REPORTING_DB enthält Daten für Analytics- und Reporting-Zwecke.

Ihre Aufgabe: sicherstellen, dass alle im Unternehmen die richtigen Zugriffsrechte auf diese Datenbanken haben.

Anforderungen

Sie haben die verschiedenen Snowflake-Nutzer im Unternehmen nach ihrem Bedarf gefragt und folgende Anforderungen gesammelt:

1. Richard, Data Analyst für die Finance- und HR-Teams, möchte für seine Analysen alle Daten aus Finance und HR lesen können. Außerdem will er Reporting-Tabellen in der Reporting-Datenbank anlegen können.
2. Lily, Data Engineer im Unternehmen, muss historische Daten in die Finance- und HR-Datenbanken laden.
3. Das Finance-Team nutzt ein neues SaaS-Tool, das aus den Finance- und HR-Datenbanken Daten lesen und – als Bonus – aufbereitete Daten zurück in die Finance-Datenbank schreiben soll.
4. Sie sollen ein neues BI- und Dashboard-Tool einrichten, das Daten aus der Reporting-Datenbank konsumiert.

Legen Sie die Datenbanken mit folgendem Code in Snowflake an:

use role SYSADMIN ;

create database FINANCE_DB ;
create database HR_DB ;
create database REPORTING_DB ;

-- Tabellen, Views, ... anlegen
-- ...

Vorgehen

Functional und Service Roles definieren

Mit den Anforderungen in der Hand können Sie zunächst klar auflisten, was Sie brauchen.

Für Functional Roles:

Für Service Roles:

⚠️ Einem Drittanbieter-Tool – wie hier dem Finance-SaaS – volle READWRITE-Berechtigungen auf allen Schemata einer Datenbank zu geben, ist in der Praxis nicht unbedingt die beste Idee. Realistischer wäre es, dem Tool nur Zugriff auf jene Schemata zu geben, in denen es tatsächlich lesen oder schreiben muss. Denken Sie daran: Das hier ist ein vereinfachtes Modell.

Access Roles erstellen

Anhand der obigen Tabellen ergeben sich folgende benötigten Access Roles:

• HR_READ_ROLE
• HR_READWRITE_ROLE
• FINANCE_READ_ROLE
• FINANCE_READWRITE_ROLE
• REPORTING_READ_ROLE
• REPORTING_READWRITE_ROLE

Wie eingangs erwähnt, erlauben READ- und READWRITE-Rollen jeweils SELECT bzw. SELECT, INSERT, UPDATE und DELETE. Das sieht so aus:

Und das sind die Statements, die Sie in Snowflake ausführen:

-- Access Roles für HR_DB anlegen
use role USERADMIN ;

create role HR_READ_ROLE
        comment = 'Access Role READ for HR_DB' ;
create role HR_READWRITE_ROLE
        comment = 'Access Role READWRITE for HR_DB' ;

-- Berechtigungen an Access Roles für HR_DB vergeben
use role SECURITYADMIN ;

-- Berechtigungen für HR_READ_ROLE
-- Datenbank
grant usage on database HR_DB to role HR_READ_ROLE ;

Code aufklappen

Sie können feste Namenskonventionen für Datenbanken und Access Roles nutzen. Damit lässt sich ein einziges Skript mit Templating erstellen, mit dem Sie mehrere Datenbanken inklusive zugehöriger Access Roles wiederverwendbar und einfach ausrollen. Ein Beispiel:

-- Werte für folgende Variablen entsprechend setzen
set database_name = 'HR_DB';
set role_read_name = 'HR_READ_ROLE';
set role_readwrite_name = 'HR_READWRITE_ROLE';

-- Datenbank anlegen
use role SYSADMIN ;
create database identifier($database_name) ;

-- Access Roles für die Datenbank anlegen
use role USERADMIN ;
create role identifier($role_read_name) ;
create role identifier($role_readwrite_name) ;

-- Berechtigungen für READ-Rolle vergeben

Code aufklappen

Functional Roles erstellen

Mit den Access Roles im Rücken lassen sich Functional Roles bauen, die den Bedarf der Nutzer abbilden. Jetzt schauen wir uns die Anforderungen im Detail an.

Beginnen wir mit Richards Anliegen:

🎯 Richard, Data Analyst für die Finance- und HR-Teams, möchte für seine Analysen alle Daten aus Finance und HR lesen können. Außerdem will er Tabellen in der Reporting-Datenbank schreiben können.

Das sieht so aus:

Eine einfache Umsetzung mit Access- und Functional Roles, die Richards Anforderungen abdeckt. Die Rolle ANALYST_ROLE ist die Functional Role und übergeordnete Rolle von HR_READ_ROLE, FINANCE_READ_ROLE und REPORTING_READWRITE_ROLE (allesamt Access Roles).

Richard bekommt dann die ANALYST_ROLE. Er kann jetzt Tabellen in HR_DB und FINANCE_DB abfragen und Daten in REPORTING_DB verändern. Und die Rolle lässt sich auch an alle weiteren Teammitglieder mit vergleichbaren Aufgaben vergeben. 🎉

In Snowflake sieht das so aus:

-- Functional Role ANALYST_ROLE anlegen
use role USERADMIN ;

create role ANALYST_ROLE
        comment = 'Functional Role for Data Analysts' ;

-- Zuweisungen an ANALYST_ROLE
use role SECURITYADMIN ;

grant role HR_READ_ROLE to role ANALYST_ROLE ;
grant role FINANCE_READ_ROLE to role ANALYST_ROLE ;
grant role REPORTING_READWRITE_ROLE to role ANALYST_ROLE ;

-- Functional Role an SYSADMIN vergeben (zuvor erwähnte Best Practice)
grant role ANALYST_ROLE to role SYSADMIN ;

Code aufklappen

Dieselben Prinzipien wenden wir nun auf Lily an:

🎯 Lily, Data Engineer im Unternehmen, muss historische Daten in die Finance- und HR-Datenbanken laden.

Ein analoges Beispiel für eine Functional Role im Data Engineering:

Der Aufbau ist ähnlich, nur dass hier ENGINEER_ROLE die übergeordnete Rolle von HR_READWRITE_ROLE und FINANCE_READWRITE_ROLE ist und an Lily vergeben wird.

Das passende SQL:

-- Functional Role ENGINEER_ROLE anlegen
use role USERADMIN ;

create role ENGINEER_ROLE
        comment = 'Functional Role for Data Engineers' ;

-- Zuweisungen an ANALYST_ROLE
use role SECURITYADMIN ;

grant role HR_READWRITE_ROLE to role ENGINEER_ROLE ;
grant role FINANCE_READWRITE_ROLE to role ENGINEER_ROLE ;

-- Functional Role an SYSADMIN vergeben (zuvor erwähnte Best Practice)
grant role ENGINEER_ROLE to role SYSADMIN ;

Code aufklappen

Weiter zu den Anforderungen rund um das neue Finance-SaaS:

🎯 Das Finance-Team nutzt ein neues SaaS-Tool, das aus den Finance- und HR-Datenbanken Daten lesen und – als Bonus – aufbereitete Daten zurück in die Finance-Datenbank schreiben soll.

Klingt einfach, oder? Hier das Diagramm:

In diesem Fall legen wir eine neue Service Role namens FINANCE_SAAS_ROLE an. Sie funktioniert im Kern wie eine Functional Role, mit dem einzigen Unterschied, dass sie programmatisch von einem Service und nicht von einem Menschen genutzt wird. Die Rolle erbt die Berechtigungen aus FINANCE_READWRITE_ROLE und HR_READ_ROLE und wird einem Snowflake-Service-Account zugewiesen, den der Dienst verwendet.

Im Code:

-- Service Role FINANCE_SAAS_ROLE anlegen
use role USERADMIN ;

create role FINANCE_SAAS_ROLE
        comment = 'Service Role for Finance SaaS' ;

-- Zuweisungen an FINANCE_SAAS_ROLE
use role SECURITYADMIN ;

grant role FINANCE_READWRITE_ROLE to role FINANCE_SAAS_ROLE ;
grant role HR_READ_ROLE to role FINANCE_SAAS_ROLE ;

-- Service Role an SYSADMIN vergeben (zuvor erwähnte Best Practice)
grant role FINANCE_SAAS_ROLE to role SYSADMIN ;

Code aufklappen

Nun zum Use Case rund um das BI-Tool:

🎯 Sie sollen ein neues BI- und Dashboards-Tool einrichten, das Daten aus der Reporting-Datenbank konsumiert.

Business as usual?

In diesem Fall braucht BI_ROLE nur eine einzige Access Role: REPORTING_READ_ROLE. Damit kann das BI-Tool SELECT-Abfragen ausführen, um seine Dashboards zu befüllen! 🎉

Im Code:

-- Service Role BI_ROLE anlegen
use role USERADMIN ;

create role BI_ROLE
        comment = 'Service Role for BI and Insights Tool' ;

-- Zuweisungen an BI_ROLE
use role SECURITYADMIN ;

grant role REPORTING_READ_ROLE to role BI_ROLE ;

-- Service Role an SYSADMIN vergeben (zuvor erwähnte Best Practice)
grant role BI_ROLE to role SYSADMIN ;

-- Rolle an Service Account vergeben

Code aufklappen

Fazit

Mit allen abgedeckten Use Cases steht unsere initiale Rollenhierarchie! So sieht das Ganze im Überblick aus:

Bonus – Änderungen und Anpassungen meistern

Einer der Vorteile einer DRY-Hierarchie: Sie lässt sich bei neuen Anforderungen mühelos anpassen. Stellen Sie sich vor, die Data Engineerin Lily hat vergessen, READWRITE-Zugriff auf REPORTING_DB zu beantragen. Die Anfrage ist schnell erledigt:

-- Functional Role DATA_ENGINEER anpassen
use role SECURITYADMIN ;
grant role REPORTING_READWRITE_ROLE to role DATA_ENGINEER ;

Sie verwalten jetzt eine Hierarchie, die sich mühelos an neue Geschäftsanforderungen anpasst! 🎉