Snowflake-Zugangskontrolle im großen Maßstab

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

Eine der Herausforderungen ist Zugangskontrolle. Es ist ein wichtiger Bestandteil eines jeden data governance-Programms. Snowflake bietet sofort einsatzbereite Funktionen um diese Herausforderung zu meistern. Aber wenn Sie Dutzende von Benutzern und Terabytes von data 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 der unsere Kunden, verwalteten wir ein Konto mit mehr als 50 aktiven Benutzern. Wir haben eine Lösung zur Skalierung der Zugriffskontrolle entwickelt.

In diesem Artikel werden die wichtigsten Erkenntnisse des vergangenen Jahres beschrieben.

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

Wir haben ein neues System entwickelt, um die Zugangskontrolle zu verwalten und diese Mängel zu bekämpfen.

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 dafür entschieden, die Zugriffsrollen auf der dataGrundstufe. Es macht es einfach, die Privilegien von einer Umgebung in eine andere zu replizieren, indem es Zero-Copy-Cloning verwendet. Es war auch ein Kompromiss zwischen der Flexibilität, die wir den Endbenutzern zugestehen, und der strikten Anwendung des Prinzips der geringsten Privilegien.

Auf der Ebene database 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 Illustration unseres Rahmens. Die Pfeile stehen für Zuschüsse.

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

Wir richten ein Einmalige Anmeldung um Snowflake-Benutzern zu ermöglichen sich über Azure Active Directory (AAD) anmelden. Auf diese Weise entfiel die Komplexität der Verwaltung von zwei data-Benutzerdatenbanken, und der Offboarding-Prozess war robuster. Tatsächlich mussten wir 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 erstellen, eine Rolle zuweisen. Wir folgen demselben Prozess für jeden neuen Benutzer.

Es handelt sich dabei um den Prozess für echte menschliche Benutzer, der jedoch eine der eingangs erwähnten Einschränkungen nicht berücksichtigt: die Verwendung persönlicher Anmeldedaten für automatisierte Aufträge.

Aus diesem Grund haben wir Servicekonten. Die Verwaltung von Servicekonten ähnelt sehr dem, was wir gerade beschrieben haben. Der einzige Unterschied besteht darin, dass wir für jedes Servicekonto eine funktionale Rolle erstellen. Es gibt eine Eins-zu-eins-Beziehung zwischen Servicekonten 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 haben immer noch viel Zeit damit verbracht, den Zugriff manuell zu gewähren, und da dies sehr manuell war, war es auch fehleranfällig. Es war klar, dass wir ein Tool brauchten, um diese Aufgaben zu automatisieren.

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 von Infrastruktur und nur von Infrastruktur. Wenn Sie anfangen, Ihre Benutzer und Berechtigungen mit Terraform zu verwalten, kann es zu unerwünschten Verhaltensweisen kommen. 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 data-Strukturen manipulieren. Das ist zwar möglich, aber auf lange Sicht wäre es 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 erstellt keine Rolle, die bereits existiert. Dasselbe gilt für Privilegien. Das Tool berechnet die Unterschied zwischen der Konfiguration und der entfernten Umgebung und wendet die notwendigen Änderungen an. So können wir jegliche Ausfallzeiten vermeiden.

Wir haben dieses Tool zunächst lokal ausgeführt. Aber das konnte zu Problemen führen. So konnte es beispielsweise zu Konflikten zwischen zwei Ingenieuren kommen, die gleichzeitig Änderungen vornehmen wollten. Aus diesem Grund haben wir ein Arbeitsablauf basierend auf den CI/CD-Funktionen von Azure DevOps (ADO).

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

Hier ist der endgültige Prozess.

Dieser vollständig automatisierte Arbeitsablauf funktioniert sehr gut. Die Tests fangen Fehler schon früh 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 jetzt etwas weniger als ein Jahr her, dass wir mit dieser Lösung begonnen haben. Obwohl die Implementierung anfangs eine gewisse Zeit in Anspruch nahm, hat sie sich absolut gelohnt.

Wir verbringen jetzt mehr Zeit damit, mit den Benutzern ü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 lässt sich gut skalieren. Wir freuen uns immer noch über neue Benutzer und können die Nachfrage bewältigen. Außerdem haben wir die anfänglichen Probleme gelöst. Es war also ein Erfolg!