DSPM gibt es, weil sensible Daten nicht mehr an einem Ort verbleiben.
Über die Datenbank hinaus befinden sich sensible Daten in Protokollen, Warteschlangen, SaaS-Tools, Support-Systemen, Analyse-Pipelines, Data Warehouses, Backups und mittlerweile auch in KI-Prompts und Vektorspeichern. Sie werden verschoben, weil die Anwendung sie verschiebt. Die E-Mail-Adresse eines Kunden könnte beispielsweise in einem Anmeldeformular erfasst werden, eine API durchlaufen, in Postgres geschrieben werden, in einem Anwendungsprotokoll auftauchen, in Snowflake kopiert werden, in ein Support-Tool fließen, an Stripe gesendet werden und später vielleicht in einen KI-Workflow eingezogen werden. Und das gilt als ziemlich normaler Arbeitsablauf.
Wenn also von DSPM – also „Data Security Posture Management“ – die Rede ist, ist das Grundkonzept eigentlich ganz einfach: Es soll Teams dabei helfen, zu verstehen, wo sich sensible Daten befinden, um welche Art von Daten es sich handelt, wer oder was darauf zugreifen kann, wie sie geschützt sind und wo sie möglicherweise gefährdet sind.
Die meisten Unternehmen verfügen nicht über einen vollständigen Überblick darüber, wo sich sensible Daten befinden. Sie wissen, dass sie über Kundendaten, Zahlungsdaten, Tokens, Mitarbeiterdaten und mittlerweile auch alle möglichen Arten von KI-Kontextdaten verfügen. Was sie jedoch nicht immer wissen, ist, wo all diese Daten letztendlich gelandet sind, wer Zugriff darauf hat oder ob sie in einer Weise verarbeitet werden, die ihren Sicherheits- und compliance entspricht.
Das Problem, das herkömmliche DSPM zu lösen versucht, ist die Sichtbarkeit.
Das herkömmliche DSPM beginnt dort, wo die Daten eingegangen sind
Bei einem herkömmlichen DSPM-Ansatz beginnt man meist mit der Bestandsaufnahme der Daten. Das bedeutet in der Regel, Speichersysteme und damit verbundene Plattformen zu scannen: S3-Buckets, Datenbanken, Data Warehouses, SaaS-Anwendungen und Backups.
Das Tool sucht nach sensiblen Daten, klassifiziert diese, überprüft Berechtigungen und den Zugriffsbereich und hilft dem Sicherheitsteam dabei, Prioritäten zu setzen. Es könnte Ihnen beispielsweise mitteilen, dass ein S3-Bucket personenbezogene Daten enthält. Oder dass eine Warehouse-Tabelle zahlungsbezogene Daten enthält. Oder dass eine Dateifreigabe zu weitreichend zugänglich ist. Oder dass ein Backup Produktionskundendaten enthält, die an einem Ort gespeichert sind, den seit einem Jahr niemand mehr angesehen hat.
Das ist natürlich sehr nützlich. In modernen Umgebungen kursieren zahlreiche sensible Daten, von denen ein Großteil kopiert, repliziert, exportiert, protokolliert, synchronisiert, archiviert und schließlich vergessen wird. Herkömmliche DSPM-Lösungen helfen Teams dabei, diese Daten aufzuspüren. Sie verschaffen dem Sicherheitsteam einen besseren Überblick über die tatsächliche Datenlandschaft, der über die bloßen Cloud-Ressourcen hinausgeht.
Für Entwickler und AppSec ist das jedoch oft erst die zweite Hälfte der Geschichte.
Im ersten Teil geht es darum, wie die Daten dorthin gelangt sind.
Die fehlende Frage betrifft den Codepfad
Ein herkömmliches DSPM-Tool würde möglicherweise melden: „In diesem Protokollspeicher wurden personenbezogene Daten gefunden.“
Der Entwickler muss jedoch noch herausfinden, warum die personenbezogenen Daten dort vorhanden sind, welcher Teil der Anwendung sie geschrieben hat, ob dies beabsichtigt war und welche Änderung das Problem tatsächlich beheben würde. Und dafür muss man sich den Code ansehen.
Die Anwendung hat die Daten erfasst, verarbeitet und entschieden, welche Felder von einer API zurückgegeben werden sollten. Anschließend hat sie den Request-Body protokolliert, ein Token an einen Worker weitergeleitet, Kundenmetadaten an einen Anbieter gesendet und die Eingabeaufforderung erstellt, die sensible Kontextinformationen enthielt.
Die für Entwickler relevantere Frage sollte also über „Wo werden sensible Daten gespeichert?“ hinausgehen und eher lauten: „Welcher Codepfad hat die Sicherheitslücke verursacht?“ Das ist die „Shift-Left“-Version von DSPM.
Der code-basierte DSPM-Ansatz setzt bei der Anwendung an und nicht bei der Speicherebene. Er berücksichtigt APIs, ORM-Modelle, Protokollierungsaufrufe, Queue-Consumer, CI/CD-Workflows, KI-Integrationen und vieles mehr. Ziel ist es, zu verstehen, wie sensible Daten in das System gelangen, wie sie sich dort bewegen, wo sie gespeichert werden, wo sie das System verlassen und wo sie möglicherweise unsachgemäß behandelt werden.
Code-basierte DSPM- und Datenexposure-Audits
Im Bereich Aikido lässt sich unser codebasiertes DSPM meiner Meinung nach am treffendsten als „Data Exposure Audit“ beschreiben, bei dem mithilfe von KI sensible Datenflüsse und Sicherheitsrisiken im Code aufgedeckt werden.
Ein Data-Exposure-Audit ist anders. Es untersucht den Code und ermittelt, wie sensible Daten durch diese Anwendung fließen und wo dieser Datenfluss Risiken birgt. Es umfasst personenbezogene Daten (PII), geschützte Gesundheitsdaten (PHI), PCI-Daten, secrets, Tokens, Kundeninhalte sowie den Umgang mit KI-bezogenen Daten. Jedes Ergebnis wird durch Belege untermauert und enthält eine Korrekturmaßnahme im Code, ohne dass eine direkte Verbindung zu den Datenspeichern erforderlich ist.
Beim Durchlesen des Codes lassen sich zudem Schwachstellen beim Datenschutz aufdecken. So können beispielsweise folgende Probleme erkannt werden: ein ohne Verschlüsselung gespeichertes sensibles Feld, ein im Quellcode fest codierter Schlüssel, die Verwendung von MD5, SHA1 oder Base64 als Verschlüsselung, ein im Repository hinterlegtes Geheimnis sowie sensible Daten, die über einen unsicheren Kanal übertragen werden.
Man kann das auch anders formulieren: Herkömmliche DSPM-Lösungen benötigen Zugriff auf Ihre eigentlichen Daten und stellen Verbindungen zu S3-Buckets, Datenbanken und Data Warehouses her, um deren Inhalt zu durchsuchen. Code-basierte DSPM-Lösungen lesen stattdessen den Code, der diese Daten erstellt und verschiebt, sodass sie niemals Zugriff anfordern oder etwas herunterladen. Das Auslesen aus dem Code senkt die Hürde für die Aktivierung, da kein neuer Zugriff auf die Produktionsumgebung gewährt werden muss.
Dadurch wird der Vorgang auch schneller, da nichts gecrawlt werden muss. Außerdem ist er genauer, da er die tatsächliche Verwendung eines Feldes auswertet, anstatt davon auszugehen, dass jede neunstellige Zahl eine Sozialversicherungsnummer ist. Das Ergebnis ist eine Übersicht darüber, wo sich sensible Daten in Ihrer Architektur befinden und wie sie geschützt sind – vollständig auf der Grundlage des Codes erstellt.
Im Aikido ist dies Teil der KI-Codeanalyseab; das Data Exposure Audit wird also im Rahmen der übrigen Codeüberprüfung durchgeführt und nicht als separate Integration zur Überprüfung des Datenzugriffs.
Inwiefern sich die Qualität der Ergebnisse unterscheidet
Nehmen wir als einfaches Beispiel die Protokollierung.
Ein herkömmliches DSPM-Produkt würde Ihnen vielleicht irgendwann mitteilen, dass personenbezogene Daten in Anwendungsprotokollen enthalten sind. Auch das ist nützlich. Aber nun muss sich jemand auf die Suche nach der Quelle machen.
Ein code-basiertes Audit zur Datenoffenlegung kann ein umfassenderes Bild vermitteln, indem es die Daten, den Codepfad, das Ziel, das Offenlegungsrisiko und die Abhilfe miteinander verknüpft. Dadurch ist es für Entwickler von größerem Nutzen.
Beispielsweise protokolliert der Checkout-Controller das vollständige „billingDetails“-Objekt, wenn die Zahlungsautorisierung fehlschlägt. Dieses Objekt enthält die E-Mail-Adresse, die Telefonnummer, die Rechnungsadresse und die letzten vier Ziffern der Kartennummer. Die Protokolle werden an Datadog übermittelt. Die Lösung besteht darin, diese Felder vor der Protokollierung zu schwärzen und nur die Kunden-ID, die Zahlungsabsichts-ID und den Fehlercode beizubehalten.
Das sind ganz andere Informationen als die, die man von einem herkömmlichen DSPM erhält.
Das Gleiche gilt für secrets Tokens. Nehmen wir beispielsweise ein SCM-Token, das zum Abrufen von Code aus GitHub, GitLab oder Bitbucket verwendet wird. Aus einer speicherorientierten Perspektive könnte man fragen, ob das Token in der Datenbank verschlüsselt ist. Das ist jedoch nicht die ganze Geschichte.
Wo gelangt das Token in die Plattform? Handelt es sich um ein OAuth-Token, ein GitHub-App-Token oder ein vom Benutzer übermitteltes PAT? Welche Berechtigungsbereiche hat es? Wie wird es validiert? Wo wird es verschlüsselt? Wo wird es gespeichert? Wann wird es entschlüsselt? Wird es zwischengespeichert? Ist es in einer Klon-URL eingebettet? Wird es an einen Worker weitergeleitet? Könnte es über Protokolle, Traces, Fehlermeldungen, Prozessargumente oder Telemetriedaten nach außen gelangen? Es handelt sich um ein Problem der Datensicherheit, aber der Code verrät uns alles, was wir über seinen Weg wissen müssen.
Vom Dashboard zur Fehlerbehebung
An dieser Stelle wird meiner Meinung nach die code-basierte DSPM interessant.
Die beste Lösung hierfür ist nicht ein weiteres Dashboard, das anzeigt: „Sie verfügen über sensible Daten.“ Das weiß jeder. Eine bessere Lösung sieht so aus: Hier ist das Verzeichnis der sensiblen Daten, hier ist der Datenfluss, hier ist das Risiko einer Offenlegung, hier sind die entsprechenden Kontrollmaßnahmen und hier ist die Codeänderung, die das Risiko verringert.
Wenn die Sicherheitslücke durch den Code verursacht wurde, sollte die Behebung wahrscheinlich im Code selbst erfolgen.
Der typische Arbeitsablauf eines Entwicklers sollte daher wie folgt aussehen:
- Sensible Felder vor der Protokollierung unkenntlich machen.
- Gibt ein kleineres API-Antwortobjekt zurück.
- Eine Überprüfung des Mietereigentums hinzufügen.
- Verwenden Sie keine Tokens mehr in URLs.
- Maskieren Sie die Produktionsdaten, bevor Sie sie in die Staging-Umgebung zurückführen.
- Führen Sie vor der Speicherung eine Verschlüsselung durch.
- Kundendaten aus einer LLM-Eingabe entfernen.
- Die Löschlogik so anpassen, dass nachgelagerte Datensätze tatsächlich entfernt werden.
Der Ingenieur möchte wissen, welcher konkrete Codepfad ein bestimmtes Risiko der Datenpreisgabe verursacht und wie man dieses beheben kann.
Dadurch wird auch der Zusammenhang mit Sicherheits- und compliance deutlich konkreter. Wird ein Token unsachgemäß gehandhabt, kann dies Auswirkungen auf die Authentifikationsverwaltung, den Übertragungsschutz, das Prinzip der geringsten Berechtigungen und den Schutz von Prüfprotokollen haben. Werden personenbezogene Daten ohne Schwärzung protokolliert, kann dies Auswirkungen auf den Datenschutz, die Aufbewahrungsfristen, die Datenminimierung und die Überwachungskontrollen haben. Werden Kundendaten ohne Maskierung in eine Staging-Umgebung kopiert, kann dies die Zugriffskontrolle, die Trennung von Umgebungen und compliance beeinträchtigen. Wenn Datensätze eine Löschanforderung überstehen oder Daten über ihre Aufbewahrungsfrist hinaus bestehen bleiben, steht dies in direktem Zusammenhang mit den Verpflichtungen gemäß DSGVO und CCPA, und dies muss in der Lösch- und Aufbewahrungslogik selbst behoben werden.
Die Feststellung, die lediglich lautet: „Unsicheres Protokollierungsmuster“, ist in ihrem Nutzen ziemlich begrenzt. Eine Aussage wie: „Über diesen Codepfad gelangen personenbezogene Daten von Kunden in die Protokolle, was ein Risiko der Datenoffenlegung darstellt, diese Kontrollmaßnahmen beeinträchtigt und durch das Schwärzen dieser Felder vor der Protokollierung behoben werden kann“, ist hingegen umsetzbar.
Das ist eine viel bessere Möglichkeit, die Bereiche Technik, AppSec und compliance ein und dieselbe Diskussion einzubeziehen.
Die einfache Version
Das herkömmliche DSPM spielt nach wie vor eine wichtige Rolle. Es hilft Teams dabei, zu verstehen, wo sich sensible Daten in der tatsächlichen Umgebung befinden. Es kann vergessene Speicherbereiche, ungeschützte Datenbanken, Schattendaten und Speicherorte mit übermäßigen Berechtigungen aufspüren.
Ein code-basiertes DSPM ergänzt jedoch die fehlende Anwendungsschicht. Es hilft dabei zu erklären, wie sensible Daten dorthin gelangen, wie sie sich bewegen, wo der Mechanismus für die Offenlegung liegt und was Entwickler dagegen tun können.
Die vereinfachte Version sieht also so aus:
Das herkömmliche DSPM-Verfahren ermittelt sensible Daten direkt an ihrem Speicherort.
Der code-basierte DSPM ermittelt, wie sensible Daten offengelegt werden.
Ein Audit zur Datenoffenlegung führt diesen Ablauf zurück zum Code, zur Kontrolllücke und zur Behebung.
Das ist die „Shift-Left“-Version von DSPM. Und für Entwickler und AppSec ist dies wahrscheinlich die Version, die den Teams am meisten hilft.
Aikido die erste Lösung ihrer Art im Bereich des code-basierten DSPM. Schützen und verfolgen Sie Ihre Daten, ohne Ihre Datenbanken überhaupt verbinden zu müssen.
