Snowflake: Wie funktioniert Zugriffsverwaltung im Cloud DWH?

Die technologischen Verbesserungen und der Trend zu Cloud-Native-Services haben die Nutzung von Cloud-DWH-Lösungen für die leistungsstarke und skalierbare Speicherung und Auswertung von Daten hervorgebracht. Auch wenn Cloud-Data-Warehouse Anbieter, wie Snowflake, die Absicherung von Unternehmensdaten zusichern, existieren bei vielen Unternehmen Bedenken um die Datensicherheit. In diesem Artikel (Teil 2 unserer vierteiligen Blogreihe zu Snowflake) stellen wir deswegen vor wie jedes Unternehmen selbst Verantwortung übernehmen kann, um durch Konfiguration von Zugriffsverwaltung und Authentifizierung die Absicherung der eigenen Daten zu erhöhen.

Zugriffsverwaltung und Authentifizierung im Cloud DWH

Ganz selbstverständlich werden innerhalb eines Unternehmens Laptops mit Passwörtern versehen, Festplatten verschlüsselt und Zugriffe auf das Firmennetzwerk überwacht. Die Sicherheit von Daten – und damit von Informationen – ist schließlich nicht nur aus rechtlichen Aspekten wichtig, sondern ebenfalls für den Erfolg eines Unternehmens. 

In unserem letzten Blog-Beitrag haben wir Bedrohungsszenarien aufgezeigt, die unter anderem durch falsche Konfiguration entstehen können. Nach dem Prinzip der geteilten Verantwortung liegt der Handlungszwang in diesen Fällen bei den Nutzer:innen von Cloudservices. Während Snowflake, als Anbieter einer cloudbasierten Data-Warehouse-Lösung, für die Sicherheit der Cloud zuständig ist, trägt jede:r Nutzer:in die Verantwortung für die Absicherung der Daten innerhalb des Accounts. Dazu zählt auch, dass der Zugriff auf die Unternehmensdaten durch Regeln ausreichend eingeschränkt wird, um Datenverlust zu verhindern, ohne dabei effektive Arbeit zu gefährden.

Da es nicht einfach ist die perfekte Balance zu finden wollen wir hier Hilfestellungen für effektive Zugriffsverwaltung und Authentifizierungsmaßnahmen geben. Dafür erklären wir das Konzept der rollenbasierten Zugriffskontrolle und wie leicht zu verwaltende Rollenhierarchien aufgebaut werden können. Außerdem werden Empfehlungen hinsichtlich Authentifizierung gegeben. Zur anschaulichen Gestaltung haben wir zudem ein Beispiel kreiert, das jede:r mit einem Snowflake-Account reproduzieren kann.

Zugriffsverwaltung

Ein sehr wichtiger Aspekt für die Absicherung von Daten ist, dass jede:r Nutzer:in ausschließlich Zugriff auf die Daten hat, die er oder sie unmittelbar für die eigene Arbeit braucht. Darüber hinaus sollten auch konkrete Berechtigungen wie zum Beispiel das Erstellen, Ändern oder Löschen von Daten so weit wie möglich eingeschränkt werden, um unbeabsichtigten Datenverlust beim Teilen oder Ändern von Informationen zu verhindern. Durch einen derartig einschränkten Datenzugriff kann der Schaden minimiert werden, wenn jemand sich unberechtigten Zugang zu einem Benutzerkonto verschafft.

Um zu verstehen, wie Zugriffsverwaltung in Snowflake funktioniert, ist es notwendig die Schlüsselkonzepte der Architektur zu verstehen, die kontrollierte Zugriffsverwaltung ermöglichen. Grundsätzlich sind dabei sicherungsfähige Objekte und Berechtigungen zu nennen. Unter sicherungsfähige Objekte fallen zum Beispiel Datenbanken, Schemata oder Tabellen, deren Zugriff standardmäßig verweigert wird und nur gewährt wird, wenn eine passende Berechtigung besteht. Berechtigungen können dabei vielfaltige Ausprägungen haben, wie zum Beispiel das Nutzen, Ändern oder Löschen von Objekten.

Abbildung1 - Beispiel für sicherungsfähige Objekte (Konzept und Darstellung in Snowflake)

Um den Aufwand bei der Erstellung von Berechtigungen und Verwaltung dieser gering zu halten, ist es sinnvoll Nutzer:innen innerhalb von Rollen zu gruppieren und nicht einzeln Berechtigungen zuzuweisen. Dieses Prinzip heißt "rollenbasierte Zugriffskontrolle" (RBAC) und ist in Snowflake zur Berechtigungssteuerung vorgegeben. Deswegen ist es fundamental wichtig sich mit RBAC vertraut zu machen, um das bestmögliche Berechtigungskonzept für das eigene Unternehmen zu entwickeln.

Rollen sind innerhalb von Snowflake die kleinstmögliche Einheit der Zugriffsrechte gewährt werden können. Einem User können mehrere Rollen zugewiesen werden, sodass es möglich ist dynamisch die Rolle zu wählen, die für die aktuelle Aufgabe ausreichende Rechte besitzt. Interessant hierbei ist, dass innerhalb von Snowflake die Rollen eines Users nicht akkumulativ sind, sondern dass zu jedem Zeitpunkt genau eine Rolle ausgewählt werden muss, deren Berechtigungen man sich zu eigen macht. Dennoch existiert ebenfalls das Konzept von Rollenhierarchien, sodass Rollen mit mehr Zugriffsrechten ebenfalls die Privilegien der ihnen untergeordneten Rollen erben können, um so eine einfachere und strukturierte Handhabung von Zugriffsberechtigungen zu gewährleisten.

Abbildung 2 – Zusammenfassung Konzepte RBAC und Berechtigungen für Objekte

Wir empfehlen dabei dringend sich im Vorfeld über eine hierarchische Struktur zwischen verschiedenen Rollen Gedanken zu machen und diese ebenfalls innerhalb von Snowflake zu konfigurieren. Falls dies nicht getan wird, kann es dazu kommen, dass Berechtigungen redundant an verschiedene Rollen vergeben werden müssen, die eigentlich aufeinander aufbauen. Außerdem passiert es viel schneller, dass vergessen wird Berechtigungen zu vergeben.

Zum Beispiel könnte es eine Rolle für die Datenbankadministration geben, der umfassenden Lesezugriff auf alle Unternehmensdaten gewährt werden soll. Wenn diese Rolle nicht innerhalb der Rollenhierarchie allen überstellt ist, die dazu in der Lage sind neue Datenbankstrukturen anzulegen und zu verändern (z.B. der Vertrieb), könnte es sein, dass für manche Datenbankschemata schlichtweg vergessen wird der Datenbankadministrations-Rolle Berechtigungen einzuräumen. Im besten Fall würde dies zur Verwirrung führen, wichtige Informationen könnten aber auch unentdeckt bleiben. Außerdem trägt eine Rollenhierarchie zur vereinfachten Wartbarkeit bei, indem geänderte Berechtigungen an einer Stelle angepasst werden müssen, anstatt unter Umständen an vielen verschiedenen. In Abbildung 3 ist noch einmal verdeutlicht welche Problematiken auftreten können, wenn keine Rollenhierarchie aufgebaut wird.

Abbildung 3 - Beispiel für Relevanz von Rollenhierarchie

Das RBAC-Prinzip gewährt also hohe Flexibilität innerhalb des Datenmanagements, birgt aber ebenso das Risiko komplexer Rollenstrukturen. Um den Aufwand beim Hinzufügen oder Ändern von Rollen möglichst gering zu halten, ist es wichtig, sich im Voraus Gedanken über die Strukturierung von Rollen innerhalb des Unternehmens zu machen. Dabei gibt Snowflake bereits eine gewisse Grundstruktur durch Standardrollen vor, die für jeden Account konfiguriert sind.

Welche Standardrollen existieren?

Innerhalb von Snowflake existieren standardmäßig fünf verschiedene Rollen (siehe Abbildung 4), die durch weitere, unternehmensspezifische Rollen ergänzt werden können. Zu diesen Standardrollen gehört auf der höchsten Ebene die ACCOUNTADMIN Rolle, die umfangreichsten Rechte besitzt und dementsprechend nur wenigen, ausgewählten Personen zugeteilt werden sollte. Falls es innerhalb einer Organisation mehrere Accounts in Snowflake gibt, ist der ACCOUNTADMIN Rolle zudem noch die des ORGADMIN überstellt. Der ACCOUNTADMIN vereint die vordefinierten Rollen des SECURITYADMIN und des SYSADMIN. Die SECURITYADMIN Rolle ist vor allem für die Absicherung und Verwaltung des Snowflake-Accounts zuständig. Dafür stehen Berechtigungen zur Erstellung und Veränderung von Nutzer:innen bereit, ebenso wie die Möglichkeit Objektberechtigungen global zu verwalten. Um dies umfangreich zu ermöglichen, erbt die SECURITYADMIN Rolle ebenfalls die Rechte der USERADMIN Rolle. Diese ist ausschließlich für das User- und Rollenmanagement zuständig. Parallel zum SECURITYADMIN existiert standardmäßig die Rolle des SYSADMIN, die über Rechte zur Erstellung von Datenbanken und virtuellen Warehouses verfügt. Nicht zuletzt ist die Pseudo-Rolle PUBLIC vorkonfiguriert. Alle Rechte, die öffentlich jedem User zugängig gemacht werden, werden automatisch auch von jeder anderen Rolle geerbt. Ebenso bekommt jede:r Nutzer:in automatisch bei der Erstellung die Rolle PUBLIC zugewiesen.

Abbildung 4 - Standardrollen

Wie finde ich die geeignete Rollenverteilung für mein Unternehmen?

In der offiziellen Dokumentation von Snowflake wird empfohlen selbst erstellte Rollen dem SYSADMIN unterzuordnen, damit Nutzer:innen dieser Rolle alle existierenden Objekte innerhalb des Accounts verwalten können. Außerdem ist so die strikte Trennung zwischen der Verwaltung von Nutzer:innen + Rollen (durch den SECURITYADMIN) und Objekten (durch den SYSADMIN) gegeben. Wir unterstützen diese Empfehlung und wollen darüber hinaus durch ein kleines Beispiel aufzeigen wie eine Organisation die passenden Rollen finden kann.

Dafür finden wir es besonders relevant sich im Vorhinein Gedanken darüber zu machen welcher Struktur man bei der Rollenerstellung folgen möchte. Eine Möglichkeit ist es der Abteilungsstruktur des Unternehmens zu folgen und jeweils eine Rolle für eine Abteilung zu erstellen. Dieser Rollen werden dann alle Rechte gewährt, die für den Arbeitsalltag der Abteilung benötigt werden. Ein Vorteil hierbei ist die klare und intuitive Abgrenzung welcher Person welche Rolle zugewiesen werden sollte. Problematisch ist jedoch, dass innerhalb einer Abteilung die Aufgabenbereiche sich immer noch stark voneinander unterscheiden können, was dazu führt, dass die Zugriffsrechte der Abteilungsrolle für jede:n einzelne:n Nutzer:in individuell zu weitreichend sein können. Eine andere Strukturierungsmöglichkeit, die diesem Nachteil entgegenwirkt, ist es Rollen nach logischen Einheiten innerhalb der Ressourcen zu erstellen. Das bedeutet, dass die vorhandenen Datenbanken, Schemata und Tabellen die Grundlage für die Entscheidung sind, welche Informationen in Verbindung miteinander in sinnvoller Weise verarbeitet werden können und demnach Rollen erstellt werden. Zuletzt ist es auch möglich Zugriffsrechte nach Projekten zu gruppieren. Das bedeutet, dass für jedes Projekt eine Rolle angelegt wird, die alle nötigen Privilegien für die Projektarbeit besitzt und allen Projektmitgliedern zugewiesen werden kann. Das hat zum Vorteil, dass es nach der Beendigung eines Projektes einfach möglich ist, die unter Umständen weitreichenden Rechte den Nutzer:innen wieder zu entziehen. Außerdem ist es möglich eine übergeordnete Projektmanagement Rolle einzurichten, die während eines Projektes bei Bedarf weitere Rechte verteilen kann.

Tabelle 1 – Strukturen für Rollenhierarchien

Wir empfehlen grundsätzlich die Rollenhierarchie nach logischen Einheiten innerhalb der Ressourcen aufzubauen und zusätzlich bei Bedarf Rollen für einzelne, größere Projekte hinzuzufügen. Um ein Gefühl dafür zu bekommen, was diese theoretische Einteilung bedeutet, wollen wir nun an einem kleinen Beispiel aufzeigen, wie eine Rollenhierarchie nach logischen Ressourceneinheiten aufgebaut werden kann.

Ein kleines Beispiel zur Rollenhierarchie

In unserem Beispiel handelt es sich um ein Unternehmen das verschiedene Haushaltswaren direkt an seine Kunden:innen verkauft. Für die Datenhaltung werden zum einen die zu verkaufenden Artikel gespeichert und zum anderen der Kunden:innenstamm. Außerdem existiert ebenfalls eine Tabelle zu den verbuchten Verkäufen. Es ist für das Unternehmen besonders wichtig die Kunden:innendaten bestmöglich zu schützen, da es sich hierbei um vertrauliche Daten handelt.

Abbildung 5 - Datenstruktur des Beispielunternehmens

In dem Unternehmen gibt es mehrere Mitarbeiter:innen, die verschiedenen Tätigkeiten nachgehen, um den Erfolg des Unternehmens zu sichern. Ein möglicher Aufgabenbereich ist so zum Beispiel neue Kunden:innendaten einzupflegen, sobald sie akquiriert wurden oder alle Verkäufe zu dokumentieren. Mitarbeiter:innen, die mit solchen Aufgaben betraut sind, benötigen Schreibzugriff auf die betreffenden Tabellen, müssen jedoch nicht dazu berechtigt sein Datenbankstrukturen selbstständig zu ändern oder anzulegen. Zusammengefasst werden können diese Berechtigungen in einer "Loader"-Rolle. Bei Bedarf kann diese noch weiter unterteilt werden, in verschiedene Rollen, denen lediglich das Schreiben in spezifische Tabellen gewährt wird.

Eine weitere Tätigkeit ist darüber hinaus die gesammelten Daten aufzubereiten und auszuwerten, um die aktuelle Situation des Unternehmens zu verdeutlichen und Verbesserungspotential zu erkennen. In unserem Beispiel kann so hinterfragt werden welche Produkte besonders häufig verkauft werden, oder welche Kunden besonders kaufstark sind. Personen mit derartigen Verantwortlichkeiten benötigen lediglich Lesezugriff auf ausgewählte Tabellen, müssen aber keine eigenen Daten einpflegen können. Wir haben diese Rolle "Reporter" genannt und sie generell mit ihren Berechtigungen der Rolle für "Business Intelligence" untergeordnet.

Des Weiteren bilden die Tätigkeiten des Datenmanagements eine logische Einheit. Dieser Aufgabenbereich lässt sich dabei weiter unterteilen, in die Erstellung und Änderung der Datenstrukturen auf einer hohen Abstraktionsebene und die Möglichkeit Daten nach Bedarf mit weiteren Informationen anzureichern. Weitere Informationen können dabei zum Beispiel der durchschnittliche Rechnungsbetrag pro Kunde oder die Gewinnmarge für jeden Artikel sein. Hierfür haben wir eine übergeordnete „Developer"-Rolle erstellt und dieser sowohl die Rolle „Transformer“ wie auch „Analyst“ unterstellt.

In der folgenden Abbildung sind die Snowflake Standardrollen (hellblau) um die soeben beschriebenen möglichen Anwendungsrollen (dunkelblau) erweitert. Außerdem ist die übergeordnete Rolle der Datenbankadministration (grau) visualisiert, um zu verdeutlichen, dass es ebenfalls für verschieden Teilbereiche eigene Unterhierarchien geben kann, die nebeneinander existieren und alle dem SYSADMIN unterstellt sind.

Abbildung 6 - Einordnung von unternehmensspezifischen Rollen in die Rollenhierarchie

Wie lege ich eine Rollenhierarchie in Snowflake an?

Snowflake bietet sowohl eine intuitive Benutzeroberfläche wie auch die Möglichkeit durch SQL-Statements Rollen und Rollenhierarchien anzulegen. Im folgenden Code-Block sind die nötigen SQL-Statements für die Erstellung einer Rollenhierarchie dargestellt.

Authentifizierung

Neben der richtigen Rollenstruktur ist es ebenso wichtig den Zugriff auf die Benutzerkonten zu schützen. Authentifizierung stellt als Zugangskontrolle den Anfang zu der Nutzung jedes Services dar und kann somit als "erste Verteidigungslinie" in Kraft gesetzter Sicherheitsmaßnahmen verstanden werden. Bei der Authentifizierung handelt es sich um die Überprüfung ob ein:e Nutzer:in tatsächlich die behauptete Identität mit Zugriffsrechten auf den Service besitzt.

Beispielsweise ist ein Authentifizierungsprozess das Login-Verfahren mit Benutzername- und Passwort-Angabe. Dadurch wird zuerst behauptet, die Identität hinter einem Benutzernamen zu besitzen und im nächsten Schritt durch das Wissen des geheimen Passwortes bewiesen, dieses tatsächlich zu tun. Auch wenn die Authentifizierung mit Benutzernamen und Passwort zum Standard für viele Anwendungen geworden ist, besteht stets noch die Gefahr, dass sich jemand unberechtigten Zugang verschafft. Gerade die Tatsache, dass Passwörter in der Regel recht kurz sind, und manchmal auch so ausgewählt werden das sie einfach zu merken sind, lässt es bereits zu durch Brute-Force Methoden die Authentifizierungsmaßnahmen auszuhebeln. Snowflake bietet für den weiteren Schutz des Accounts einige Maßnahmen an, die nach der Konfiguration das Authentifizierungs-Verfahren besser gegen Angriffe absichern. Dazu zählen vor allem die Multi-Faktor-Authentifizierung (MFA) und die Nutzung von Schlüsselpaaren zur Authentifizierung.

Multi-Faktor Authentifizierung (MFA)

Bei der Zugangskontrolle wird grundsätzlich zwischen Single-Faktor Methoden (wie die Angabe eines Passwortes) und Multi-Faktor Methoden unterschieden. Da bei Multi-Faktor Methoden mehrere „Beweise“ erbracht werden müssen, dass man tatsächlich die Zugriffsberechtigung zu einem Service hat, gelten MFA- Methoden grundsätzlich als sicherer.

Innerhalb von Snowflake ist unter dem Thema MFA vor allem die Zwei-Faktor Authentifizierung zu nennen. Dabei macht der Rückgriff auf einen externen Service es notwendig, nicht nur das Passwort für die Authentifizierung zu wissen, sondern auch im Besitz eines vorher konfigurierten Handys zu sein. Wir empfehlen die MFA grundsätzlich für alle Nutzer:innen, denen durch ihre Rollen umfassenden Datenzugriff gewährt ist, da die Kompromittierung dieser Konten schwerwiegende Auswirkungen für das Unternehmen haben kann. Im besten Fall sollte jede:r Nutzer:in auf MFA Authentifizierung zurückgreifen, durch den höheren Konfigurationsaufwand ist es jedoch unter Umständen sinnvoll dies bei Nutzer:innen mit Zugriff auf vor allem öffentliche Daten zu vernachlässigen, um die Nutzbarkeit nicht unproportional zur erhöhten Sicherheit einzuschränken. Außerdem ist die Nutzung von MFA für technische Konten nicht möglich.

Schlüsselpaar-Nutzung 

Die Nutzung von Schlüsselpaaren erhöht anders als bei der MFA die Sicherheit des Authentifizierungsprozess nicht dadurch, dass mehrere Merkmale zur Authentifizierung notwendig sind, sondern dadurch, dass die Idee von Passwörtern weiter ausgebaut wird. Bei einem Schlüssel handelt es sich ebenfalls um eine Aneinanderkettung von Buchstaben, Satz- und Sonderzeichen, die durch ihre Länge praktisch nicht durch Ausprobieren erraten werden kann. Da Schlüsselpaare nicht in der Anmeldungsbenutzeroberfläche verwendet werden können und schwierig zu konfigurieren sind, empfehlen wir den Einsatz grundsätzlich für technische Konten.

Fazit

Sobald es um die Nutzung von Cloudservices geht, steht auch die Frage um die Datensicherheit im Raum. Am besten gewährleistet werden kann sie, wenn Serviceanbieter und Nutzer:innen sich zusammen dafür verantwortlich fühlen.

In unserem letzten Blog-Beitrag haben wir beschrieben welche Sicherheitsmaßnahmen von Snowflake ergriffen werden, um jetzt zu beschreiben, wie das Konzept von Zugriffsverwaltung dazu beiträgt die Datensicherheit nicht dem Zufall zu überlassen. Zugriffsverwaltung beschreibt das Konzept, dass jede:r Nutzer:in lediglich auf die Daten zugreifen kann, die er oder sie für die eigene Arbeit benötigt und diese auch nicht weiter als notwendig bearbeiten kann. Das erhöht die Sicherheit, indem das Risiko von versehentlicher Datenweitergabe sinkt und der Datenverlust minimiert wird, wenn es zu der Kompromittierung eines Benutzerkontos kommt.

Um die Berechtigungsverwaltung zu vereinfachen und sowohl skalierbar, wie auch wartbar zu machen, werden Berechtigungen nicht einzelnen Nutzer:innen erteilt, sondern ausschließlich Rollen. Wir haben gezeigt nach welchen Prinzipien ein Unternehmen eine sinnvolle Rollenstruktur und Rollenhierarchie aufbauen kann. Da nicht zuletzt auch die Absicherung der Benutzerkonten während der Authentifizierung nötig ist, haben wir die von Snowflake unterstützten Maßnahmen von MFA und Schlüsselpaaren erläutert und Anwendungsfälle aufgezeigt. Dieser Blog-Beitrag stellt damit neben einer Hilfestellung zur Konfiguration von Snowflake auch die Grundlage dar, um weitere fein abgestufte Zugriffsverwaltung zu verstehen. Bei Interesse lest also auch gerne unseren nächsten Beitrag in der Reihe zu Sicherheitsmaßnahmen in Snowflake, der sich mit Konzepten im Bereich von Governance beschäftigt, wie zum Beispiel Datenmaskierung und Zeilenzugriffsrichtlinien!

Interessiert? Weitere Informationen gibt es auf unserer Seite zu Cloud Data Warehouse.

Zu diesem Blogartikel hat Melena Thieß (WWU Münster) mit ihrer Tätigkeit als Werkstudententin maßgeblich beigetragen.