Snowflake & Snowalert: Vertrauen ist gut – Monitoring ist besser

Die Nutzung eines Cloud Data Warehouse (Cloud DWH) wie Snowflake sollte durch passende Maßnahmen abgesichert werden. Die Möglichkeiten haben wir in den ersten drei Blogposts unserer Reihe zu Snowflake erörtert. Problematisch wird es jedoch, wenn ergriffene Sicherheitsmaßnahmen dazu führen, dass die Nutzbarkeit zu sehr eingeschränkt wird. Es muss also immer auch zwischen Sicherheit und Nutzbarkeit abgewogen werden. Deswegen sind Monitoring-Prozesse wichtig, um angemessen auf Bedrohungen zu reagieren, die nicht präventiv verhindert werden können. Wir wollen zeigen, wie Monitoring zur Datensicherheit in Snowflake beitragen kann, ganz nach dem Motto: Vertrauen ist gut – Monitoring ist besser.

Monitoring mit Snowalert

Während die Vorteile eines Cloud-DWH nicht zu leugnen sind, ist die Angst um die Datensicherheit dennoch präsent. Serviceanbieter wie Snowflake, einer der Vorreiter in diesem Markt, bieten zwar eine Vielzahl von Sicherheitsfunktionen, diese sind jedoch durch interne Konfigurationen zu ergänzen. Die Verantwortung über die Datensicherheit kann man schließlich nicht vollständig abgeben. Es ist zwar möglich, durch Zugriffsverwaltung, Authentifizierungsmaßnahmen und Data Governance die Datensicherheit zu erhöhen, dennoch bleibt ein Restrisiko, dass es zu Datenverlust kommt. Das liegt auch daran, dass Daten nutzbar sein müssen, um zum Unternehmenserfolg beizutragen. Sie so sehr zu schützen, dass ein effizientes Arbeiten unmöglich ist, ist daher keine Option. Wenn man sich zum Beispiel ein Telekommunikationsunternehmen vorstellt, ist es notwendig, dass das Servicepersonal auf Kundendaten zugreifen kann, um Problemen auf den Grund zu gehen und diese zu lösen. Dennoch dürfen keine vertraulichen Informationen unabhängig von Serviceanfragen eingesehen werden und es muss schnellstmöglich auffallen, falls sich jemand häufig zusammenhangslos über bestimmte Personen informiert. Hier helfen Monitoring-Maßnahmen und ein Alarmsystem, welches unbefugte Zugriffe meldet. Durch diese Transparenz können Bedrohungen rechtzeitig erkannt und frühzeitig Gegenmaßnahmen ergriffen werden. Das Sicherheitssystem kann inkrementell verbessert und an neue Bedrohungen angepasst werden.

Wir zeigen, wie die Protokolldaten, die innerhalb von Snowflake automatisch über die Aktivitäten im Unternehmen erfasst werden, dazu genutzt werden können, aktive Bedrohungen zu identifizieren. Dafür stellen wir vor allem SnowAlert vor, ein Open-Source-Projekt, das den Rahmen für ein gelungenes Monitoring bilden kann. Außerdem gehen wir darauf ein, wie mithilfe von Slack Warnungen individuell konfiguriert werden können.

Was ist Snowalert?

SnowAlert ist ein Open-Source-Projekt, das eigens von Snowflake dafür entwickelt wurde, einen Rahmen für die Sicherheitsanalyse von Snowflakes Protokolldaten zu bieten.

Die grundlegende Idee ist, unerwartetes Verhalten in Form von Regeln zu definieren, die dann als Ansichten auf Protokolldaten angewendet werden. Durch die Identifikation von Regelverstößen kann das Sicherheitsteam frühzeitig verständigt und geeignete Maßnahmen ergriffen werden. Anwendungsfälle können zum Beispiel sein:

• häufig auftretende, fehlgeschlagene Login-Versuche erkennen.
• Nutzer:innen identifizieren, die unverhältnismäßig viele Ressourcen in Anspruch nehmen.
• Abfragen hinterfragen, die eine überdurchschnittliche Laufzeit haben.

Bei den Regeln kann zwischen Warnungen (alerts) und Verstößen (violations) unterschieden werden, die unterschiedliche Prioritäten symbolisieren. Durch die Aufteilung ist es möglich, die Anwendung der Regeln zu staffeln. So können die Protokolldaten zum Beispiel stündlich nach neuen Warnungen überprüft werden, aber nur einmal täglich nach neuen Verstößen. Außerdem ist es sinnvoll, Warnungen dafür zu nutzen, das Sicherheitsteam direkt auf Ungereimtheiten aufmerksam zu machen und Verstöße mithilfe von BI-Tools zu visualisieren, um strukturelle Fehler zu finden.

Vorteile von SnowAlert

Die Nutzung von SnowAlert bietet dabei den Vorteil, auf ein existierendes Framework zurückzugreifen, das auf Snowflake zugeschnitten ist. Damit ist es auch möglich, auf bestehende Beispiele aufzubauen und von den Erfahrungen anderer SnowAlert Nutzer:innen zu profitieren. Es bedarf lediglich SQL-Kenntnissen, um erfolgreich eigene Regeln anzulegen. Eine intuitive Web-UI vereinfacht die Konfiguration von SnowAlert weiter. Neben dem Zugriff auf Snowflakes Protokolldaten ist es auch möglich, Schnittstellen zu anderen Services einzurichten, um regelmäßig Daten von externen API’s zu laden und diese ebenfalls mithilfe von SnowAlert zu überwachen. Nicht zuletzt ist es praktisch, dass eine Vielzahl von Aktionen beim Auftreten von Warnungen ausgeführt werden können. So kann zum Beispiel konfiguriert werden, dass SnowAlert E-Mails oder Slack-Nachrichten versendet, JIRA-Tickets erstellt oder gespeicherte Prozeduren ausführt.

Bei der Erstellung einer SnowAlert Instanz werden ein virtuelles Warehouse, ein Benutzer, eine Rolle, eine Datenbank und ein Schema in der Snowflake-Instanz eingerichtet, die ausschließlich für die Sicherheitsanalyse bestimmt sind. Dadurch kann das Monitoring an zentraler Stelle durchgeführt werden und alle entstehenden Kosten leicht überwacht werden.

WIe funktioniert SnowAlert für Snowflake: Ein Beispiel

Die planmäßigen Abfragen, die Regeln für verdächtiges Verhalten darstellen, sind als Ansichten auf den Protokolldaten von Snowflake gespeichert. Die Verarbeitung der Daten bis zur Warnung ist dabei in einige Schritte aufgeteilt, die wir nun an einem Beispiel erklären wollen, um den Transfer auf eigene Anwendungsfälle zu erleichtern. Das Beispiel ist in Abbildung 1 visualisiert. Dafür stellen wir uns vor, dass wir Warnungen erhalten wollen, sobald Nutzer:innen sich ohne Mehr-Faktor-Authentifizierung (MFA) anmelden, als Hinweis darauf, dass die Authentifizierung entgegen der eigenen Standards konfiguriert ist.

Wie bereits erwähnt, wird bei der Konfiguration von SnowAlert eine eigene Datenbank erstellt, in der die Schemata „data“, „rules“ und „results“ liegen. In dem Schema für die Daten können Ansichten auf den Protokolldaten von Snowflake erstellt werden, die für die Erstellung von dedizierten Warnungen und Verstößen notwendig sind. Um Anmeldungen ohne MFA zu identifizieren, sind lediglich die erfolgreichen Logins von Relevanz. Das heißt, die Erstellung einer Ansicht auf der Login-Historie, die nur die erfolgreichen Anmeldungen abbildet, ist der erste Schritt, um ungewolltes Verhalten zu identifizieren. Innerhalb des Schemas „rules“ werden nun durch Ansichten auf die Informationen im „data“-Schema Regeln festgelegt, die auffälliges Verhalten beschreiben. Zum Beispiel kann hier eine Ansicht erstellt werden, die lediglich die erfolgreichen Anmeldungen ohne MFA anzeigt, die also den Wert „NEIN“ in der Spalte MFA haben. Innerhalb des „rules“-Schema können außerdem Unterdrückungsregeln (suppression rules) abgespeichert werden, die Informationen über bekannte Ausnahmefälle enthalten, die automatisch ignoriert werden sollen. So kann es einige Nutzer:innen geben, bei denen bewusst keine MFA gefordert ist und bei deren Anmeldung in Snowflake keine Warnung erzeugt werden soll. Letztendlich sind in dem Schema „results“ die Warnungen abgespeichert, die nach der Überlagerung von verschiedenen Ansichten auf den Protokolldaten übrig bleiben und damit die potenziell bedrohlichen Transaktionen darstellen.

Abbildung 1 - Aufbau SnowAlert

Damit auffälliges Verhalten schnell nach dem Auftreten identifiziert werden kann, muss SnowAlert regelmäßig ausgeführt werden. Bei einem SnowAlert Durchlauf (Abbildung 2) werden dabei zuerst die SQL-Ansichten in dem „rules“-Schema abgefragt, um Alarmergebnisse zu erfassen. Diese werden vorerst in das „results“- Schema geschrieben. Nach Abgleichen mit Ergebnissen aus vorherigen Durchläufen werden die Warnungen übersprungen, die bereits verarbeitet worden sind. Außerdem werden die Ergebnisse mit den Unterdrückungsregeln abgeglichen, um nur die relevanten Ergebnisse in angepasster Form an die konfigurierten Handler, wie zum Beispiel Slack oder Jira, weiterzugeben. Dadurch wird das Sicherheitsteam schnell und einfach auf Verstöße aufmerksam. Schlussendlich werden in einem SnowAlert Durchlauf die Ergebnisse in dem „data“- Schema dokumentiert. Da die Ausführung von SnowAlert automatisiert werden kann, empfehlen wir, mindestens einmal jede Stunde alle Warnungs-Funktionen laufen zu lassen. Für die Verstöße reicht es auch, die Funktionen täglich auszuführen.

Abbildung 2 – Ablauf SnowAlert 

Wie erstelle ich eigene warnungen in Snowalert?

Spannend wird es natürlich, wenn es darum geht, SnowAlert für das eigene Unternehmen zu konfigurieren und individualisierte Warnungen zu erstellen. Dafür ist es zuerst notwendig, eine eigene SnowAlert Instanz einzurichten. Dies wird einem dadurch leicht gemacht, dass ein Docker-Container zur Verfügung steht, der lediglich an der gewünschten Stelle ausgeführt werden muss. Eine detaillierte Anleitung für die Installation ist hier beschrieben.

Danach steht einem nichts mehr im Weg, um eigene Regeln für Warnungen zu kreieren! Diese können sowohl durch SQL-Statements wie auch durch den FormEditor in der Web UI konfiguriert werden. Wir wollen hier beide Möglichkeiten zeigen. Damit aus einer Idee eine erfolgreich automatisierte Warnung werden kann, ist es wichtig, den Ablauf von SnowAlert verstanden zu haben. So wissen wir bereits, dass es im ersten Schritt notwendig ist, die für die Auswertung interessanten Daten als Ansicht in dem Schema „SnowAlert.data“ zu speichern. Für unser Beispiel wollen wir die Login-Historie (siehe Abbildung 3) verwenden.

Abbildung 3 – Erstellung einer Ansicht in SnowAlert.data

Danach ist es möglich, durch ein weiteres SQL-Statement die Regel festzulegen, bei welchen Authentifizierungsversuchen eine Warnung erstellt werden soll. Dabei gibt es eine Reihe von Variablen (wie zum Beispiel Titel, Eventzeitpunkt und Detektor), die mit Informationen aus dem Datenschema konfiguriert werden können.

Abbildung 4 - SQL-Statement für die Erstellung einer Warnungsregel

Wie bereits erwähnt wollen wir ebenfalls kurz zeigen, wie dieselbe Warnungsregel mit dem FormEditor der WebUI erstellt werden kann. Hier sind alle konfigurierbaren Parameter bereits mit Textfeldern aufgelistet, die nach Bedarf ausgefüllt werden können. Die Informationen werden dann automatisch in ein SQL-Statement umgewandelt.

Abbildung 5 - WebUI für die Erstellung einer Warnungsregel

Abschließend sind die Befehle interessant, die notwendig sind, um alle konfigurierten Funktionen auszuführen und die Web-UI zu erreichen.

Abbildung 6 - Befehle für SnowAlert Ausführung

Snowalert warnungen einfach in slack

Um Warnungen und Verstöße nicht nur durch manuelle Abfragen der entsprechenden Tabellen zu bemerken, ist es möglich, innerhalb von SnowAlert Handler zu konfigurieren, die die Warnungen direkt an das zuständige Sicherheitspersonal senden. Zu den verschiedenen Handler-Möglichkeiten zählen E-Mail, SMS, Slack genauso wie ServiceNow, Jira und PagerDuty. Es können auch automatisch gespeicherte Prozeduren durchgeführt werden.

Welcher Handler am besten geeignet ist, hängt davon ab, wie viele Warnungen durch eine Regel durchschnittlich erzeugt werden, wie hoch das Sicherheitsrisiko eingestuft wird, wie häufig Warnungen auf tatsächliche bedrohliche Situationen hinweisen und ob ein:e klare:r Zuständige:r ersichtlich ist. Gerade bei ausgefeilten Warnungsregeln, die häufig auf Handlungsbedarf hinweisen, finden wir die Nutzung von Slack für die Warnungsübermittlung sehr sinnvoll. In vielen Unternehmen wird Slack sowieso für Großteile der internen Unternehmenskommunikation verwendet und es ist möglich sowohl über Channel eine Gruppe von Leuten zu erreichen wie auch einzelne Personen und Zuständige gesondert. Deswegen wollen wir hier stellvertretend für alle Handler erklären, wie Slack innerhalb von SnowAlert konfiguriert werden kann.

Da es einige Schritte gibt, die nur einmalig bei der Konfiguration ausgeführt werden müssen, haben wir den Prozess in Abbildung 7 zur Veranschaulichung visualisiert.

Abbildung 7- Konfiguration Slack-Handler

Als Erstes muss eine unternehmensinterne Slack-Anwendung erstellt werden, der es gestattet ist, automatisch Nachrichten an das Personal zu senden. Damit die Anwendung Nachrichten an einzelne Nutzer:innen schreiben kann, muss der Berechtigungsumfang wie in Abbildung 8 konfiguriert werden. Nach der Erstellung der Anwendung muss diese lediglich noch im Workspace installiert werden.

Abbildung 8 - Berechtigungsumfang Slack-Anwendung

Damit SnowAlert beim Ausführen der Funktionen auf die Slack-Anwendung zugreifen kann, muss der Slack-Token in der Datei für die Umgebungsvariablen (.envs-Datei) gespeichert werden. Dafür kann einfach eine weitere Zeile mit „SLACK_API_TOKEN =“ eingefügt werden. Den richtigen Token findet man unter dem Bot User OAuth Token (siehe Abbildung 9). Bei Bedarf kann zum Testen der API-Response diese Website genutzt werden.

Abbildung 9 - Token für die Slack-Anwendung

Nun ist es vor allem wichtig, die Handler in den Regeldefinition für die Warnungen zu integrieren. Dafür kann einfach ein Array mit allen Nachrichtenformen, die für eine Warnung erstellt werden sollen, zu den anderen Parametern hinzugefügt werden. Ein Beispiel ist in Abbildung 10 zu sehen, wo sowohl ein Slack-Channel benachrichtigt wird, wie auch eine individuelle Person. Es ist möglich, den Text, der in der Mitteilung erscheinen soll, direkt in das „message“ Feld zu schreiben. Schöner ist es jedoch, wenn man auf ein zuvor erstelltes Template zugreift, das dafür sorgt, dass wichtige Meta-Daten über die Warnung in der gesendete Mitteilung enthalten sind.

Abbildung 10 - SQL-Statement für Handler-Parameter

Wie in Abbildung 10 zu sehen ist, werden Templates in dem Schema „rules“ gespeichert. Unten ist das Beispiel noch einmal genau aufgeführt. Dem Handler wird ein alert-Objekt übergeben, dessen Variablen ausgelesen werden können, um sie dann textuell aufzubereiten. Sinnvolle Informationen für die Darstellung können dabei die Art der Sicherheitsverletzung, die Prioritätseinstufung der Warnung oder der Eventzeitpunkt sein. In Abbildung 12 ist zu sehen, wie eine Nachricht aussieht, die mit dem Template aus Abbildung 11 erstellt worden ist.

Abbildung 11 - Template für Slack-Nachrichten

Abbildung 12 - Slack Nachricht von SnowAlert

fazit: Monitoring als Teil einer sicheren Cloud DWH-Strategie

Sicherheit bedeutet nicht, den Zugriff auf Daten nahezu unmöglich zu machen. Daten müssen nutzbar sein, damit im Rahmen der erlaubten Verwendung ein Mehrwert generiert werden kann. Als Konsequenz besteht ein Risiko, dass Daten missbräuchlich verwendet werden oder in unbefugte Hände fallen. Um diesen Spagat zu bewältigen, empfehlen wir dringend, dass Monitoring-Maßnahmen Teil der Sicherheitsstrategie sind. So können Bedrohungen schnell erkannt werden, was Reaktionsspielraum ermöglicht, bevor ein großer Schaden entsteht. Gleichzeitig kann eine Kultur für einen sensiblen Umgang mit Daten entstehen, bei welcher der Zugriff grundsätzlich möglich ist, aber Missbrauch überwacht und geahndet wird.

Wir haben SnowAlert als Framework für das Monitoring innerhalb von Snowflake vorgestellt und beschrieben, wie Warnungen aufgebaut sind und selbst erstellt werden können. Wir haben ebenfalls gezeigt, wie eine Verbindung von Warnungen, die innerhalb des Cloud DWH identifiziert werden, mit dem beliebten Kommunikationstool Slack hergestellt werden kann. Vor allem derartige Verbindungen ermöglichen einen leichten, benutzerfreundlichen Umgang mit automatisch generierten Warnungen und können dazu genutzt werden, Monitoring-Maßnahmen auf die Praktiken des eigenen Unternehmens zuzuschneiden.

Dieser Beitrag bildet vorerst den Abschluss unserer Blog-Beitragsreihe zu Sicherheitsmaßnahmen in Snowflake. Wir denken, dass es wichtig ist, Bedrohungsszenarien ernst zu nehmen und deswegen Sicherheitsmaßnahmen zugeschnitten auf Bedrohungsszenarien zu konfigurieren. Neben den Maßnahmen, die Snowflake ergreift, um Sicherheit in der Cloud zu gewährleisten, haben wir gezeigt, wie Zugriffsverwaltung, Data Governance und Monitoring zur Datensicherheit beitragen können. Wir haben gezeigt, dass die Bedenken um die Datensicherheit bei der Nutzung von Cloud-DWH-Lösungen durch proaktives Handeln so weit eingeschränkt werden können, das dem Nutzen der Vorteile von Cloud-native Lösungen nichts mehr im Weg steht.

Interessiert? Im Rahmen der NAVIGATE 2022 gibt es im Rahmen der Masterclass "Von Null zum Cloud Data Warehouse" Gelegenheit zum Austausch.

Mehr Informationen zum Thema Cloud DWH finden Sie 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.