Snowflake access control at scale

Immer mehr Unternehmen stellen Snowflake in den Mittelpunkt ihrer Datenplattformen. Auch wenn es sich um eine verwaltete Lösung handelt, müssen Sie die Umgebung dennoch verwalten. Das kann eine Herausforderung sein, insbesondere für große Unternehmen.

Eine der Herausforderungen ist die Zugriffskontrolle. Sie ist ein entscheidender Bestandteil eines jeden Data Governance-Programms. Snowflake bietet sofort einsatzbereite Funktionen, um diese Herausforderung zu bewältigen. Aber wenn Sie Dutzende von Benutzern und Terabytes von Daten haben, reichen die integrierten Funktionen nicht aus. Sie müssen sich eine Strategie für die Verwaltung Ihres Kontos überlegen.

Das haben wir schon erlebt. Für einen unserer Kunden haben wir ein Konto mit mehr als 50 aktiven Benutzern verwaltet. Wir haben eine Lösung zur Skalierung der Zugangskontrollverwaltung entwickelt.

In diesem Artikel werden die wichtigsten Erkenntnisse aus dem vergangenen Jahr beschrieben.

Bevor wir in das Unternehmen eintraten, war das Konto eingerichtet und viele gute Ideen waren umgesetzt worden. Es waren benutzerdefinierte Rollen erstellt worden. Die Benutzer wurden sorgfältig verwaltet. Aber es gab ein paar Einschränkungen:

Wir haben ein neues System zur Verwaltung der Zugangskontrolle und zur Bekämpfung dieser Unzulänglichkeiten entwickelt.

Zunächst haben wir den Benutzern alle Standardrollen (SYSADMIN, USERADMIN ...) entzogen ... Nur einige wenige Personen konnten diese Rollen übernehmen. Das waren die Personen, die für die Verwaltung zuständig waren.

Zweitens haben wir einen Rahmen für die Zugriffskontrolle auf der Grundlage von benutzerdefinierten Rollen geschaffen. Wir haben zwei Arten von benutzerdefinierten Rollen definiert:

Wir haben uns für die Definition von Zugriffsrollen auf Datenbankebene entschieden. So lassen sich die Berechtigungen mit Hilfe des Null-Kopie-Klonens leicht von einer Umgebung in eine andere übertragen. Es war auch ein Kompromiss zwischen der Flexibilität, die wir den Endnutzern gewähren, und der strikten Anwendung des Prinzips der geringsten Rechte.

Auf der Datenbankebene haben wir 3 Ebenen von Zugriffsrollen definiert:

Wir haben eine ähnliche Strategie für den Lagerzugang mit zwei Arten von Rollen angewandt:

Unten sehen Sie eine Abbildung unseres Rahmens. Die Pfeile stehen für Finanzhilfen.

Zu diesem Zeitpunkt hatten wir eine bessere Vorstellung davon, wie wir die Berechtigungen verwalten würden, aber wir hatten auch Probleme mit der Benutzerverwaltung.

Wir haben Single Sign On eingerichtet, damit sich Snowflake-Benutzer über Azure Active Directory (AAD) anmelden können. Dadurch entfiel die Komplexität der Verwaltung von zwei Benutzerdatenbanken und der Offboarding-Prozess war robuster. Wir mussten den Benutzer nur in AAD deaktivieren, und die Löschung wurde automatisch in Snowflake repliziert.

Da es in Snowflake eine Zuordnung zwischen AD-Gruppen und Rollen gibt, konnten wir jedem Benutzer, den wir anlegen, eine Rolle zuweisen. Wir folgen dem gleichen Prozess für jeden neuen Benutzer.

Es handelt sich um ein Verfahren für echte menschliche Benutzer, das jedoch eine der eingangs erwähnten Einschränkungen nicht berücksichtigt: die Verwendung persönlicher Anmeldedaten für automatisierte Aufgaben.

Aus diesem Grund haben wir die Servicekonten eingeführt. Die Verwaltung von Dienstkonten ähnelt sehr dem, was wir gerade beschrieben haben. Der einzige Unterschied besteht darin, dass wir für jedes Dienstkonto eine funktionale Rolle erstellen. Es besteht eine Eins-zu-Eins-Beziehung zwischen Dienstkonten und ihren Rollen. Daher schränken wir den Umfang der Berechtigungen für jedes Dienstkonto streng ein.

Diese Schritte waren große Verbesserungen. Alles wurde dokumentiert. Die Teams nahmen den neuen Rahmen schnell an. Wir waren zufrieden.

Aber wir verbrachten immer noch viel Zeit damit, den Zugang manuell zu gewähren, und da dies sehr manuell war, war es auch fehleranfällig. Der Bedarf an einem Tool zur Automatisierung dieser Aufgaben war klar.

Wir hatten ein paar Möglichkeiten:

Schließlich haben wir ein CLI in Python erstellt.

Wir bevorzugen die Verwendung von Terraform für die Bereitstellung der Infrastruktur und nur der Infrastruktur. Unerwünschte Verhaltensweisen können auftreten, wenn Sie beginnen, Ihre Benutzer und Berechtigungen mit Terraform zu verwalten. Zum Beispiel ist die Rotation von Geheimnissen sehr schwer zu verwalten.

Wir mögen bash, aber nur für ad-hoc und einfache Operationen. Hier müssen wir Konfigurationsdateien laden, mit der Snowflake-API interagieren und Datenstrukturen manipulieren. Das ist zwar möglich, wäre aber auf lange Sicht schwer zu pflegen.

Zusätzlich zu diesem Aspekt brauchten wir auch Zuverlässigkeit. Eine Möglichkeit, dies zu erreichen, besteht darin, Tests zu schreiben. Das ist in Programmiersprachen wie Python einfacher.

Wenn Sie das Tool ausführen, geschieht Folgendes hinter den Kulissen.

Das Tool kann keine Rolle erstellen, die bereits existiert. Dasselbe gilt für Berechtigungen. Das Tool berechnet den Unterschied zwischen der Konfiguration und der entfernten Umgebung und wendet die erforderlichen Änderungen an. Auf diese Weise können wir Ausfallzeiten vermeiden.

Wir haben dieses Tool zunächst lokal ausgeführt. Dies konnte jedoch zu Problemen führen. So konnte es beispielsweise zu Konflikten zwischen zwei Ingenieuren kommen, die versuchten, gleichzeitig Änderungen vorzunehmen. Deshalb haben wir einen Workflow eingerichtet, der auf den CI/CD-Funktionen von Azure DevOps (ADO) basiert.

Hinweis: Wir haben ADO verwendet, aber Sie können das Gleiche mit GitHub, GitLab oder Bitbucket tun.

Hier ist der endgültige Prozess.

Dieser vollautomatisierte Arbeitsablauf funktioniert sehr gut. Die Tests fangen Fehler frühzeitig in der CI-Pipeline ab. Und die obligatorische Überprüfung ist auch eine Möglichkeit, Zwischenfälle zu verhindern.

Außerdem dienen Pull Requests als eine Art Dokumentation aller Anforderungen.

Es ist etwas weniger als ein Jahr her, dass wir mit dieser Lösung begonnen haben. Auch wenn die Implementierung anfangs eine gewisse Zeit in Anspruch nahm, war es das absolut wert.

Wir verbringen nun mehr Zeit damit, mit den Nutzern über ihre Wünsche zu diskutieren und weniger mit der eigentlichen Implementierung. Die meisten Anfragen können in etwa 10 Zeilen YAML gelöst werden. Das ist sehr effizient und skaliert gut. Wir freuen uns immer noch über neue Nutzer und können die Nachfrage bewältigen. Außerdem haben wir die anfänglichen Probleme behoben. Es war also ein Erfolg!