Lesen Sie unseren Artikel über

1

.

Wie wir die Verwaltung eines Kontos mit mehr als 50 Nutzern unter Einhaltung der Data-Governance-Standards automatisiert haben

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.

Initial situation

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:

  • Die Verwaltung erfolgte manuell, was für die zuständigen Mitarbeiter sehr zeitaufwendig war.
  • Datenanalysten und Entwickler nutzten ihre Konten für automatisierte Aufgaben. Das war ein Problem, weil die Mitarbeiter ihre Passwörter weitergeben mussten. Neben dem erheblichen Sicherheitsproblem kam es zu Fehlern aufgrund widerrufener Anmeldedaten, wenn Mitarbeiter das Unternehmen verließen.
  • Es gab keine Dokumentation der bestehenden Rollen, was es schwierig machte, die aktuellen Berechtigungen zu prüfen und regelmäßig zu überprüfen.

  • Die Benutzer wurden ausschließlich von Snowflake aus verwaltet. Wenn Mitarbeiter das Unternehmen verließen, mussten sich die Administratoren der Snowflake-Umgebung dessen bewusst sein. Das für die Benutzerverwaltung (Active Directory) zuständige Team war nicht dasselbe wie das für das Snowflake-Konto zuständige. Es bestand also das Risiko, dass ehemalige Mitarbeiter nach ihrem Ausscheiden auf die Daten des Unternehmens zugreifen konnten.

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

Access control framework design

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:

  • Zugriffsrollen umfassen eine Reihe von Berechtigungen auf niedriger Ebene für Snowflake-Objekte. Eine Zugriffsrolle kann zum Beispiel nur Leseberechtigungen für eine bestimmte Datenbank umfassen. Sie werden den Benutzern nicht direkt gewährt.

  • Funktionale Rollen sind die Rollen, die den Benutzern zugewiesen werden. Sie umfassen eine Reihe von Zugriffsrollen. Sie werden für ein bestimmtes Team erstellt.

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:

  • Schreibgeschützt

  • Lesen und Schreiben

  • Verwaltung

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

  • Benutzer

  • Verwaltung

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

Below is an illustration of our framework. Arrows represent grants. Snowflakes

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

User management

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.

  • Sie senden eine Anfrage über unser Ticketingsystem, in der sie erklären, zu welchem Team sie gehören und welchen Bedarf sie an Zugang haben
  • Wir fügen den Benutzer in die entsprechende(n) AD-Gruppe(n) ein

  • Die Synchronisierung erfolgt im Hintergrund

  • Der Benutzer kann auf Snowflake zugreifen und die ihm zugewiesene Rolle verwenden

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.

Automation to the rescue

Wir hatten ein paar Möglichkeiten:

  • Verwenden Sie den Snowflake Terraform-Anbieter, um die Umgebung zu verwalten
  • Schreiben von Bash-Skripten zur Automatisierung der Benutzererstellung und der Erteilung von Berechtigungen
  • Unser eigenes CLI in einer Sprache wie Python oder Go schreiben

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.

1

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.

Here is the final process of snowflakes

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.

Conclusion

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!

Vielen Dank an Samy Dougui , der diesen Artikel geprüft und mit mir an der Entwicklung dieser Lösung gearbeitet hat

1

Medium Blog von Artefact.

Dieser Artikel wurde ursprünglich auf Medium.com veröffentlicht.
Folgen Sie uns auf unserem Medium Blog!

Unseren Artikel lesen
Artefact Newsletter

Interessiert an Datenberatung | Daten & Digitales Marketing | Digitaler Handel?
Lesen Sie unseren monatlichen Newsletter und erhalten Sie umsetzbare Ratschläge, Einblicke und Business Cases von unseren Datenexperten aus aller Welt!

Anmeldung zum Newsletter