Erkennung von credential-basierten Angriffen auf Databricks

Bei Databricks wissen wir, dass Ihre Daten Ihr wertvollstes Gut sind. Databricks hat mit Tausenden von Kunden zusammengearbeitet, um die Databricks Data + AI Platform mit den entsprechenden Funktionen sicher bereitzustellen, damit diese ihre Anforderungen an Sicherheit, Datenschutz und Vorschriften erfüllen können.

Moderne Cyberangriffe beginnen nicht immer mit einer durchbrochenen Perimeter-Sicherheit, sondern oft mit einer gültigen Anmeldung. Sobald ein Angreifer ein geleastes Sitzungscookie, ein Personal Access Token (PAT) oder Anmeldeinformationen eines Dienstprinzipals erbeutet hat, ist der erste Einbruch bereits abgeschlossen. Von diesem Moment an besteht ihr gesamtes Ziel darin, sich anzupassen und unter dem Deckmantel Ihres kompromittierten Benutzers oder Dienstes zu agieren.

Aber nur weil man einen Schlüssel hat, kennt man noch lange nicht das Gebäude. Stellen Sie sich vor, ein Eindringling stiehlt einen Ausweis, um ein sicheres Büro zu betreten. Er hat vielleicht die Drehtüren passiert, muss aber immer noch am Sicherheitsdienst vorbei, raten, zu welchen Etagen er Zugang hat, und herausfinden, wo sich der Tresor befindet. Da einem Angreifer der tiefe, lokalisierte Kontext Ihrer tatsächlichen Mitarbeiter fehlt, wird sein Verhalten ihn schließlich verraten. Das Erkennen dieser Unregelmäßigkeiten ist der Schlüssel zu ihrer Erfassung.

In diesem Beitrag gehen wir darauf ein, wie ein auf Anmeldeinformationen basierender Angriff auf der Databricks-Plattform abläuft, wie Sie die Änderung im Verhalten einer Identität mithilfe von ausführlichen Databricks-Überwachungsprotokollen und Genie erkennen, wie Sie reagieren, sobald Sie eine Kompromittierung bestätigen, und welche Kontrollen einschränken, was gestohlene Anmeldeinformationen überhaupt bewirken können.

Ein Modell zur Verfolgung von auf Anmeldeinformationen basierenden Angriffen

Beim Einrichten des Zugriffs über legitime Anmeldeinformationen wissen Angreifer – ebenso wie Sicherheitsexperten –, dass ihr Zugriff jederzeit widerrufen werden kann, wenn sie zu stark vom erwarteten Verhalten der Identität abweichen. Angreifer verlassen sich auf nicht-lineare Angriffsabläufe, wie zum Beispiel das Validieren eines Satzes von Anmeldeinformationen zum Kartografieren Ihrer Umgebung und das anschließende Abrufen eines anderen Satzes von Anmeldeinformationen, um über eine neue Identität oder einen neuen Arbeitsbereich zurückzukehren, dem keine Erkennungsaktivität zugeordnet ist. Darüber hinaus können Angreifer Informationen sammeln, ohne Persistenz herzustellen, oder sich den Weg zurück in Ihre Databricks-Plattform bahnen, bevor sie ihre Ziele abschließen.

Wie das in der Praxis aussieht

Betrachten wir einen Dateningenieur, dessen Personal Access Token aus einem falsch konfigurierten CI/CD-Protokoll kopiert wurde. Innerhalb von Minuten wird das Token von einer neuen IP-Adresse aus verwendet, um Secret-Scopes, Kataloge und Repos im gesamten Arbeitsbereich aufzulisten – etwas, das dieser Ingenieur noch nie getan hat. Ein Secret, das Anmeldeinformationen eines Dienstprinzipals enthält, wird gelesen. Eine Stunde später erstellt dieser Dienstprinzipal (und nicht der Ingenieur) eine Funktion, fügt sich selbst einer Administratorgruppe hinzu und exportiert eine Handvoll Init-Skripte. Jedes dieser Ereignisse könnte als routinemäßige Plattformnutzung durchgehen, aber zusammengenommen zeigen sie einen Eindringling, der sich durch die Angriffskette bewegt.

Bei Databricks erwarten wir eine nicht-lineare Ereignisreihenfolge in Bezug auf auf Anmeldeinformationen basierende Angriffe und verwenden dieses Modell, um einzelne Ereignisse zu einer einzigen Untersuchung zu verknüpfen, anstatt sie als nicht zusammenhängende Ereignisse zu behandeln.

Die sechs Phasen eines auf Anmeldeinformationen basierenden Angriffs

Wenn Angreifer kompromittierte Anmeldeinformationen in einer PaaS-Umgebung (Platform-as-a-Service) wie Databricks nutzen, lässt sich ihre Aktivität in sechs Phasen unterteilen, obwohl sie sich selten auf einem geraden Weg durch sie hindurchbewegen. Jede der folgenden Phasen beschreibt, was der Angreifer zu tun versucht und worauf in den Databricks-Überwachungsprotokolltabellen zu achten ist. Betrachten Sie diesen Leitfaden als Ausgangspunkt und passen Sie ihn an die normale Automatisierung Ihrer Umgebung an.

Hinweis: Ereignisse werden als service_name.action_name geschrieben, zum Beispiel secrets.getSecret.

1. Der Angreifer erhält Zugriff mit gültigen Anmeldeinformationen

Die Anmeldung selbst sieht selten ungewöhnlich aus. Da die Anmeldeinformation echt ist, ist die Authentifizierung erfolgreich wie beim rechtmäßigen Besitzer. Was die Identität jedoch in den Minuten nach der Anmeldung tut, unterscheidet sich oft stark von ihrer normalen Aktivität, und genau diese Änderung können Responder erkennen. Im Beispiel des Dateningenieurs authentifiziert sich das gestohlene Token erfolgreich, und der einzige Unterschied bei der Anmeldung ist eine Quell-IP-Adresse, die der Ingenieur noch nie verwendet hat. Die darauffolgende Aktivität ist das, was auffällt.

Ziel des Angreifers: Zugriff auf den Arbeitsbereich mit gültigen Anmeldeinformationen erhalten – sei es eine gestohlene Browsersitzung, ein wiederverwendetes PAT oder Anmeldeinformationen eines Dienstprinzipals – und sich in Aktivitäten einfügen, die die Kontrollen zulassen sollen.

Worauf zu achten ist:

• Verwenden Sie das Authentifizierungsereignis als Ausgangspunkt für Ihre Zeitleiste. Eine Anmeldung allein reicht selten aus, um einen Alarm auszulösen, aber user_identity, source_ip_address, user_agent, sessionId, request_id und workspace_id ermöglichen es Ihnen, nachzuvollziehen, was das Token als Nächstes tut.
• Markieren Sie accounts.tokenLogin-Ereignisse, die in einem kurzen Burst von einem unbekannten Client eintreffen und gefolgt werden von der Verwendung desselben Tokens von einer anderen Quell-IP-Adresse. Dieses Muster kann darauf hindeuten, dass jemand ein gestohlenes Token testet, und requestParams.tokenId ermöglicht es Ihnen, diese Ereignisse demselben Token zuzuordnen.
• Markieren Sie OAuth-Token von Dienstprinzipalen, die aus dem erwarteten Netzwerk mit einem unerwarteten User-Agent erstellt wurden, insbesondere dann, wenn innerhalb einer Minute Aktivitäten von einer neuen Quell-IP-Adresse folgen.

2. Der Angreifer kartografiert die Umgebung

Als Nächstes muss der Angreifer herausfinden, worauf die Anmeldeinformation zugreifen kann, bevor der Zugriff widerrufen wird. Infolgedessen kann eine kompromittierte Identität innerhalb von Sekunden von ihrer gewohnten Aktivität dazu übergehen, Daten, Secrets, Code und Netzwerkkontrollen aufzulisten. Diese Aufklärung erstreckt sich in der Regel über mehrere Dienste gleichzeitig und läuft schneller ab als bei einem Menschen, der durch die Benutzeroberfläche navigiert. In unserem Szenario besteht diese Phase aus dem Burst von Aufrufen zur Auflistung von Secret-Scopes, Katalogen und Repos innerhalb von Minuten nach der Verwendung des Tokens – eine Aktivität, die der Ingenieur noch nie zuvor ausgeführt hat.

Ziel des Angreifers: Erstellen einer Karte der zugänglichen Daten, Anmeldeinformationen, Repositorys und Schutzmechanismen, um einen tieferen Pfad in die Umgebung zu planen, bevor der Zugriff widerrufen wird.

Worauf zu achten ist:

• Achten Sie auf eine einzelne Identität, die schnelle Listenaufrufe über den Arbeitsbereich und die Account-Ebenen hinweg ausführt, wie zum Beispiel secrets.listScopes / listSecrets, unityCatalog.listMetastores / listCatalogs / listSchemas / listExternalLocations / listStorageCredentials, repos.listRepos und Account-Ebene accountsManager.listWorkspaceConfigurations / listNetworkConfigurations / listStorageConfigurations. Wenn beispielsweise fünf oder mehr verschiedene Erkennungs-APIs innerhalb einer Minute aufgerufen werden, ist es unwahrscheinlich, dass dies eine Person ist, die auf der Plattform navigiert.
• Vergleichen Sie die Aktivität mit der Baseline der Identität. Die allererste Secret-Enumeration, die jemals von einer etablierten Identität durchgeführt wurde, oder eine SQL-Sitzung, die von geschäftlichen Abfragen zu SHOW TABLES gegen Zugriffssteuerung- und Konfigurationsschemata wechselt, ist aussagekräftiger als ein hohes Aufrufvolumen. Wenn die ausführliche Überwachungsprotokollierung aktiviert ist, bewahrt commandSubmit die Abfrage in commandText auf.
• Beziehen Sie fehlgeschlagene Anfragen in Ihre Suche ein. Untersuchen Sie die erste IpAccessDenied einer Identität, insbesondere wenn sie auf accounts.oidcTokenAuthorization folgt oder sich über Arbeitsbereiche hinweg wiederholt. In diesem Fall war die Autorisierung erfolgreich, aber die Anfrage stammte aus einem blockierten Netzwerk, was oft der früheste Nachweis dafür ist, dass Anmeldeinformationen von einem nicht vertrauenswürdigen Standort aus wiederverwendet wurden.

3. Der Angreifer sammelt weitere Anmeldeinformationen

Das Sammeln von Anmeldeinformationen erfordert in der Regel mehrere Schritte. Der Angreifer listet Secret-Scopes auf, listet die Secrets darin auf und liest dann diejenigen, die nützlich erscheinen. Der Wert, den sie abrufen, ermöglicht es ihnen, als andere, oft privilegiertere Identität zurückzukehren. Aus diesem Grund lohnt es sich, jedem von einer verdächtigen Identität gelesenen Secret nachzugehen. Im Beispiel des Dateningenieurs liest der Angreifer ein Secret, das die Anmeldeinformationen eines Dienstprinzipals enthält. Von diesem Zeitpunkt an muss die Untersuchung zwei Identitäten verfolgen: den Ingenieur und den Dienstprinzipal.

Ziel des Angreifers: Abrufen eines Tokens, eines API-Schlüssels oder eines Dienstprinzipal-Secrets, das den anfänglichen Zugriff auf einen umgebungsweiten Zugriff unter einer neuen Identität hochuft.

Worauf Sie achten sollten:

• Achten Sie auf Warnungen bei der Abfolge von Aufrufen. secrets.listScopes allein ist üblich und erzeugt Rauschen. Wenn jedoch listScopes gefolgt von listSecrets und dann getSecret über mehrere Bereiche hinweg in rascher Folge wiederholt wird, deutet dies auf ein Harvesting hin. listSecrets zeichnet den Bereich auf, und getSecret zeichnet sowohl den Bereich als auch den Schlüssel auf.
• Korrelieren Sie verweigerte Lesevorgänge mit späteren erfolgreichen. Ein verweigerter getSecret in einem streng kontrollierten Bereich, gefolgt von einem erfolgreichen Lesevorgang desselben oder eines zugehörigen Schlüssels in einem weniger eingeschränkten Bereich, deutet darauf hin, dass die Identität nach einer Kopie sucht, auf die sie zugreifen kann.
• Überwachen Sie den Zugriff auf Compute-Seite zusätzlich zur Secrets API. Wenn die ausführliche Audit-Protokollierung aktiviert ist, können Notebook- submitCommand und Databricks SQL- commandSubmit-Ereignisse Code anzeigen, der Secret-Hilfsprogramme aufruft oder read_files() für Pfade ausführt, die Anmeldeinformationen enthalten. Denken Sie daran, dass der übermittelte Text anzeigt, was ausgeführt wurde, aber nicht bestätigt, dass ein Wert zurückgegeben wurde.
• Verknüpfen Sie jeden gelesenen Secret mit den nachfolgenden Schritten, wie etwa einem neuen accounts.tokenLogin, erstmals gesehenen Service-Principal-Aktivitäten, einer geänderten IP oder einem geänderten User Agent oder generateTemporaryTableCredential- / generateTemporaryVolumeCredential-Aufrufen. Rotieren Sie als Reaktion darauf alle Anmeldeinformationen, auf die die Identität hätte zugreifen können, und überprüfen Sie, wo die einzelnen Anmeldeinformationen verwendet und wo sie gespeichert wurden.

4. Der Angreifer findet einen funktionierenden Ausführungspfad

Sobald der Zugriff hergestellt ist, suchen Angreifer nach einer Möglichkeit, ihren eigenen Code auszuführen. Auf Databricks geschieht dies typischerweise über benutzerdefinierte Funktionen (UDFs) und Jobs. Eine Funktion kann eine Nutzlast in gewöhnlich aussehendem Code verpacken, der wiederholt aufgerufen werden kann, und ein Job kann diesen Code nach einem Zeitplan auf verschiedenen Compute-Ressourcen ausführen. Die zentrale Frage für die Erkennung ist daher, ob eine Identität begonnen hat, Aktionen auszuführen, die sie zuvor noch nicht ausgeführt hat. Um auf den Data Engineer zurückzukommen: Eine Stunde nach dem Lesen des Secrets erstellt der Service Principal eine Funktion. Da der Service Principal und nicht der Engineer diese Aktion durchführt, würde eine Suche, die sich nur auf die Aktivität des Engineers beschränkt, dies übersehen.

Ziel des Angreifers: Eine zuverlässige, wiederverwendbare Möglichkeit zur Ausführung von Nutzlasten einrichten, mit einem Fallback für den Fall, dass ein Compute-Pfad blockiert wird.

Worauf Sie achten sollten:

• Priorisieren Sie createFunction-Ereignisse von einer Identität, IP oder einem Katalog ohne Historie der Funktionserstellung, insbesondere wenn mehrere in kurzer Zeit auftreten. Markieren Sie dort, wo Funktionsdefinitionen verfügbar sind, Code, der Prozesse ausführt, Code dynamisch auswertet, auf Instanzmetadaten zugreift, ausgehende Netzwerkverbindungen öffnet oder in Cloud-Speicher schreibt. Verfolgen Sie auch Verweise zwischen Funktionen, da ein harmlos aussehender Wrapper eine UDF mit höherem Risiko aufrufen kann. Beachten Sie, dass function_info in system.access.audit für alle außer Kontoadministratoren und databricks_pii_access maskiert ist, verknüpfen Sie Audit-Daten daher mit Funktionsinventaren.
• Verfolgen Sie den Jobs-Pfad nach Identität, IP und Job- oder Run-ID. Eine typische Sequenz ist importNotebook, gefolgt von changeJobAcl, Jobs create, runNow und getRunOutput. Diese Ereignisse bewahren den Notebook-Text nur selten auf, behalten Sie daher Notebook-Versionen und Job-Konfigurationen zusammen mit ihnen bei. Wiederholte Import-und-Ausführungs-Aktivitäten aus einer Quelle sind ein stärkeres Signal als jede Aktion allein.
• Achten Sie auf eine Identität, die nach einem Fehler die Compute-Ressourcen wechselt. Beispielsweise kann eine fehlgeschlagene Cluster-Erstellung oder ein submitRun, kurz darauf gefolgt von einem startWarehouse oder einem neuen Job auf anderen Compute-Ressourcen, darauf hindeuten, dass ein Angreifer einen blockierten Pfad umgeht. Die Antwortcodes und der kurze Abstand zwischen den Ereignissen unterscheiden diese Sequenz von routinemäßigen Fehlern. Serverless Compute ist ein gängiger Fallback.

5. Der Angreifer stellt die Persistenz sicher

Mit der Möglichkeit, Code auszuführen, versuchen Angreifer als Nächstes sicherzustellen, dass sie zurückkehren können, nachdem die ursprüngliche Anmeldeinformation widerrufen wurde. Gängige Persistenzmethoden sind Zugriffsberechtigungen, neu erstellte Token, Änderungen an Gruppen- und Workspace-Mitgliedschaften sowie Bearbeitungen der Control Plane. Das nützlichste Signal ist eine sensible Änderung, die von einer unbekannten Identität oder einem unbekannten Ausführungskontext vorgenommen wurde. Beispielsweise verdient eine innerhalb eines Jobs vorgenommene Berechtigungsänderung mehr Aufmerksamkeit als dieselbe Änderung durch einen Administrator in der Konsole. Als Nächstes im Szenario fügt sich der Service Principal selbst einer Admin-Gruppe hinzu. Selbst wenn das Token des Engineers widerrufen wird, sorgt diese Gruppenmitgliedschaft dafür, dass der Zugriff des Angreifers erhalten bleibt.

Ziel des Angreifers: Dauerhafte, unabhängige Zugriffspfade schaffen, die den Widerruf der kompromittierten Anmeldeinformation überstehen.

Worauf Sie achten sollten:

• Warnen Sie vor Berechtigungs- und Identitätsvergabe aus unerwarteten Kontexten, wie etwa putAcl für einen Secret-Bereich, updatePermissionAssignment, addPrincipalToGroup oder setAdmin. Achten Sie besonders darauf, wenn ein Service Principal einer anderen Identität Zugriff gewährt oder wenn mehrere Zuweisungen in kurzer Zeit erfolgen.
• Behandeln Sie Versuche, Sicherheitskontrollen zu ändern, als hochgradig schwerwiegend, selbst wenn sie fehlschlagen. Dazu gehören setSetting / deleteSetting, Bearbeitungen von IP-Zugriffslisten und createPrivateAccessSettings. Überprüfen Sie die angeforderte Änderung, die Antwort und die Quelle, bevor Sie Schlussfolgerungen darüber ziehen, ob eine Kontrollmechanismus tatsächlich umgangen wurde. Überprüfen Sie auch SCIM-Gruppenänderungen, die von etwas anderem als dem erwarteten IdP stammen.
• Markieren Sie generateDbToken-Aufrufe aus einer unbekannten Quelle oder während eines Job-Laufs. Jedes resultierende Token ist eine separate Anmeldeinformation, die widerrufen werden muss.
• Achten Sie auf Workloads, die von selbst weiterlaufen. Korrelieren Sie Control-Plane-Ereignisse mit run_by, run_as und dem erwarteten Ausführungsfenster. Wenn ein Job weiterhin Gruppen, Berechtigungen oder Einstellungen ändert, nachdem die interaktive Aktivität des Angreifers aufgehört hat, hält er möglicherweise den Zugriff eigenständig aufrecht. Sichern Sie die Job-Definition und die Artefakte, bevor Sie ihn beenden.

6. Der Angreifer sammelt Daten und bereinigt den Zugriff

Datensammlung kann so geringfügig sein wie ein paar gezielte Exporte, und das Aufräumen kann mehr umfassen als das Löschen von Dateien. Achten Sie auf gezielte Exporte, Anfragen für temporäre Anmeldeinformationen, das Entfernen kurzlebiger Tools und verschleierte Befehle, die die Rekonstruktion der Aktivität erschweren. Jedes einzelne dieser Ereignisse kann routinemäßig wirken, daher ist die Sequenz um sie herum wichtiger als der jeweilige Export oder das Löschen. Schließlich exportiert der Service Principal aus unserem Szenario eine Handvoll Init-Skripte. Für sich genommen ist das ein kleiner Export. Da es jedoch auf das Lesen eines Secrets und eine neue Funktion desselben Service Principals folgt, sollte es im Rahmen desselben Einbruchs untersucht werden.

Ziel des Angreifers: Die relevanten Daten mitnehmen und die offensichtlichsten Tools beseitigen, während ein unauffälligerer Zugriff aufrechterhalten wird.

Worauf Sie achten sollten:

• Betrachten Sie den Kontext jedes Exports anstelle der Anzahl der Exporte. workspaceExport zeichnet den Pfad, das Format und die Tatsache auf, ob es sich um einen direkten Download handelte. Priorisieren Sie Exporte durch unbekannte Identitäten zu ungewöhnlichen Pfaden oder in ungewöhnlichen Formaten, aus zuvor nicht gesehenen Netzwerken oder solche, die auf den Zugriff auf Secrets oder eine neue Ausführung folgen. Ein kleiner, gezielter Export von Init-Skripten kann mehr preisgeben als ein gesamtheitlicher SOURCE-Dump.

Untersuchung von anmeldeinformationsbasierten Angriffen mit Genie

Anhand der Angriffskette für anmeldeinformationsbasierte Angriffe als Leitfaden kannst du Genie anweisen, die Angriffsphasen zu durchlaufen, ohne jede Abfrage von Grund auf neu zu schreiben. Jede Erkennung in diesem Beitrag basiert auf Telemetriedaten, die dir bereits vorliegen. Databricks schreibt Control-Plane-Aktivitäten in die Systemtabelle system.access.audit.

Installiere zu Beginn die Detection App, die einen Genie-Agenten für das Audit-Logging von Databricks hinzufügt. Du kannst ihn über Genie One auf zwei Wegen nutzen:

• Frage in deinen eigenen Worten, wie zum Beispiel: „Welche Notebooks hat user@example.com gestern exportiert?“ Genie schreibt und führt das SQL für dich aus.
• Verwende die integrierten Erkennungen. Der Detection-App-Genie-Agent enthält über 30 Erkennungen, die von Token-Missbrauch bis hin zu Administrator-Zuweisungen reichen. Frage „Wer hat letzte Woche persönliche Zugriffstoken erstellt?“, und Genie führt die passende Erkennung aus, anstatt neuen SQL-Code zu schreiben. Gib ihm ein Ziel, wie zum Beispiel „Wurden wir in den letzten 90 Tagen kompromisiert?“, und er arbeitet die Erkennungen nacheinander ab.

Beachte zwei Einschränkungen. Erstens bedeutet ein leeres Ergebnis nicht, dass nichts passiert ist. Das Ereignis liegt möglicherweise außerhalb deines Zeitfensters, oder das detaillierte Audit-Logging ist deaktiviert. Zweitens zeichnen Audit-Logs auf, dass sich etwas geändert hat und wer es geändert hat, oft jedoch nicht die alten oder neuen Werte.

Von der Erkennung zur Reaktion

Sobald eine Suche eine Identität zutage fördert, die nicht zu ihrem normalen Muster passt, verlagert sich der Fokus darauf, welchen Zugriff der Angreifer noch hat. Da anmeldeinformationsbasierte Angriffe nicht linear verlaufen, ist der erste gefundene Zugriff selten der einzige. Im Beispiel des Dateningenieurs würde das Widerrufen des Tokens des Ingenieurs die Anmeldeinformationen des Dienstprinzipials, seine Mitgliedschaft in der Administratorgruppe und die von ihm erstellte Funktion an Ort und Stelle belassen. Eine vollständige Reaktion entfernt sowohl die ursprüngliche Anmeldeinformation als auch jeden Pfad, den der Angreifer danach erstellt hat, einschließlich Berechtigungen, Token, Funktionen und Jobs, die auch nach der Deaktivierung des Benutzers weiterlaufen.

Bei einer vermuteten Workspace-Kompromisierung sollten Administratoren und Responder wie folgt vorgehen:

1. Die Identität deaktivieren. Deaktiviere den Benutzer auf Kontoebene, wodurch alle Workspaces gesperrt werden. Es gibt keine API, um die Browsersitzungen eines Benutzers zu beenden, aber die Deaktivierung sperrt ihn. Für einen Dienstprinzipal: lösche seine OAuth-Geheimnisse und deaktiviere ihn über die Account-SCIM-API. OAuth-Token, die der Dienstprinzipal bereits besitzt, bleiben bis zu einer Stunde lang gültig.
2. Persönliche Zugriffstoken widerrufen. Das Deaktivieren eines Benutzers löscht seine Token nicht, und die Token funktionieren wieder, wenn der Benutzer reaktiviert wird. Verwende die Token-Management-API oder den Token-Bericht in der Kontonsole.
3. Speichern, was du brauchst, und dann die Compute-Ressourcen stoppen. Exportiere zuerst Job-Definitionen und Notebook-Versionen. Breche dann Job-Ausführungen ab, beende Cluster und stoppe SQL Warehouses. Bei Serverless brichst du die Ausführung oder die Anweisung ab. Das Deaktivieren eines Benutzers stoppt keine bereits laufenden Compute-Ressourcen.
4. Jedes von dem Akteur gelesene Geheimnis rotieren. Ändere es an der Quelle und aktualisiere dann den gespeicherten Wert. Rotiere auch die Anmeldeinformation, die der Angreifer zum Eindringen verwendet hat.
5. Vom Akteur geschaffene Persistenz rückgängig machen. Entferne ACLs für Secret Scopes, Workspace-Zuweisungen und Gruppenmitgliedschaften. Lösche die Funktionen und widerrufe die Berechtigungen. Stelle deine kontextbasierten Ingress-Richtlinien (und IP-Zugriffslisten, falls du sie noch verwendest) anhand deiner eigenen Aufzeichnungen wieder her.
6. Code überprüfen, den die Identität außerhalb von Databricks ändern konnte, wie zum Beispiel Init-Skripte und ETL-Code im Cloud-Speicher.
7. Bestätigen, dass es gestoppt wurde. Führe eine Suche nach Aktivitäten des Akteurs durch. Wenn das detaillierte Audit-Logging ausgeschaltet war, schalte es ein. Befehlstontexte werden nur protokolliert, während es aktiv ist.

Verhinderung anmeldeinformationsbasierter Angriffe

Um zum Bürogebäude zurückzukehren: Die kontextbasierte Eingangskontrolle entscheidet, wer durch die Drehtüren kommt, und das Prinzip der geringsten Privilegien entscheidet, welche Etagen ihre Karte öffnen kann. Eine frühzeitige Erkennung verschafft Reaktionszeit, aber präventive Kontrollen begrenzen, was gestohlene Anmeldeinformationen bewirken können. Die folgenden Kontrollen sind danach gruppiert, was sie dem Angreifer entziehen, ungefähr in der Reihenfolge, in der sie ihre Angriffskette unterbrechen.

Gestohlene Anmeldeinformationen fernhalten

Die stärkste präventive Kontrolle gegen die Wiederverwendung von Anmeldeinformationen ist die kontextbasierte Ingress-Steuerung. Sie bewertet, wer eine Anfrage stellt, woher sie kommt und wozu sie dient, anstatt sich auf einen einzelnen Netzwerkperimeter zu verlassen. Dies ist besonders nützlich, da immer mehr Unternehmen von VPNs abweichen. Selbst ohne ein Unternehmensnetzwerk als Ankerpunkt kannst du ein gestohlenes Token auf die Kontexte beschränken, die sein Besitzer tatsächlich nutzt. Beispielsweise kannst du einen privilegierten Dienstprinzipal auf API-Anfragen aus vertrauenswürdigen Netzwerken beschränken und gleichzeitig eine andere Richtlinie auf menschliche Benutzer anwenden.

• Wende Richtlinien sowohl auf Workspace- als auch auf Kontoanfragen an. Workspace-Richtlinien decken die Kontonsole oder APIs auf Kontoebene nicht ab.
• Starte im Testmodus (Dry-Run). Überprüfe Ablehnungen und Testmodus-Verstöße in system.access.inbound_network, schütze privilegierte Dienstprinzipale zuerst und erzwinge die Richtlinien, nachdem du legitime Automatisierungen und Partnerintegrationen berücksichtigt hast.
• Teste Serverless- und Private-Connectivity-Workflows vor einer umfassenden Durchsetzung, da sie separaten Richtlinienregeln folgen. Dokumentiere alle Ausnahmen und überwache deren Verwendung.
• Betrachte IP-Zugriffslisten als zusätzliche Ebene. Wo beide gelten, muss eine Anfrage beide passieren. Konfiguriere Workspace- und Kontonsole-Listen, wenn du sie weiterhin verwendest.

Erbeutete Anmeldeinformationen entwerten

• Leg Exspirations- und Rotationsanforderungen für Anmeldeinformationen von Dienstprinzipalen, Integrationsanmeldeinformationen und persönliche Zugriffstoken fest und ziehe nicht mehr verwendete Anmeldeinformationen aus dem Verkehr. Inaktive Anmeldeinformationen sind für Angreifer besonders attraktiv, da eine Kompromisierung monatelang unbemerkt bleiben kann.
• Setze das Prinzip der geringsten Privilegien für Secret Scopes durch. Vermeide es, Kopien mächtiger Anmeldeinformationen in Scopes mit unterschiedlichen ACLs zu speichern, und überprüfe sowohl, wer die Inhalte von Scopes auflisten als auch wer Werte abrufen kann.

Einschränken, was eine Anmeldeinformation ausführen oder ändern kann

• Schränke Operationen mit hoher Auswirkung ein. Beschränke UDF-Erstellungen, Änderungen an Secret-Scope-ACLs, Workspace-Berechtigungsänderungen, Job-Administration und Änderungen von Ingress-Richtlinien auf genehmigte Identitäten und kontrollierte Automatisierungen.
• Trenne administrative Pfade von Compute-Pfaden. Gewöhnliche Job-Laufzeiten sollten Konto- und Netzwerksteuerungen nicht ändern können, und jeder Versuch dazu sollte einen Alarm auslösen.
• Schütze Cloud-Ausführungsumgebungen. Verwende nach Möglichkeit gehärtete Metadatendienst-Konfigurationen und schränke den ausgehenden Datenverkehr von Compute ein, damit Workloads nicht frei auf Anmeldeinformationsendpunkte oder nicht genehmigte Ziele zugreifen können.
• Schränke ein, welche Identitäten Kontoisidentitäten verwalten, Workspace-Zugriff zuweisen und Jobs erstellen können.

Behalte die Beweise

• Bewahre untersuchungsbereite Telemetriedaten für potenzielle Sicherheitsvorfälle auf.
• Speichere Audit-Protokolle, Notizbuch- und Job-Versionsverläufe, UDF-Definitionen und -Abhängigkeiten, den Verlauf von Berechtigungsänderungen, Cloud-Speicher-Schreibereignisse und Ablehnungsprotokolle für den kontextbasierten Ingress lange genug auf, um einen Vorfall zu rekonstruieren.

Denke daran, dass der Schadensradius gestohlener Anmeldeinformationen nur so groß ist wie die ihnen zugewiesenen Berechtigungen. Verringere dieses Risiko und sei in der Lage, nach ungewöhnlichen Aktivitäten zu suchen, indem du diese Schritte befolgst:

• Sieh dir die Databricks Security Best Practices an, um deine Workspaces und dein Konto abzusichern.
• Aktiviere die detaillierte Protokollierung und richte die kontextbasierte Ingress-Steuerung ein, damit beide Ebenen abgedeckt sind.
• Installiere die Detection App, um deine Suche zu starten, und stelle Genie deine erste Frage: „Wurden wir in den letzten 90 Tagen kompromittiert?“

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag