Um zu verstehen, warum bestehende DLP-Implementierungen zu kurz greifen, lohnt ein Blick darauf, wie Daten in modernen Umgebungen tatsächlich abfließen. Innerhalb einer Browser-Sitzung können Nutzer Daten in Web-Seiten und Anwendungen tippen, einfügen und hochladen — in genehmigte ebenso wie in nicht genehmigte.
Ein zentrales Einfallstor ist die Zwischenablage. Beschäftigte kopieren regelmäßig sensible Inhalte — Kundendaten, Zugangsdaten, Quellcode — aus internen Systemen und fügen sie in private E-Mails, SaaS-Anwendungen und KI-Werkzeuge ein. Dieses Kopieren und Einfügen kann von herkömmlichen DLP-Lösungen kaum kontextbezogen geprüft oder kontrolliert werden.
Daten bewegen sich aber nicht nur als Datei oder über die Zwischenablage. Häufig werden sie direkt in Web-Formulare, SaaS-Anwendungen oder KI-Eingaben getippt. Weil all das ausschließlich innerhalb der Browser-Sitzung geschieht, schlagen endpunkt- und netzwerkbasierte DLP-Kontrollen nie an.
Auch Datei-Uploads bleiben ein wesentlicher Vektor, der an der Oberfläche wie normales Arbeiten aussieht. Beschäftigte laden Quellcode, Finanz- und Kundendaten hoch — doch bis zur Hälfte dieser Uploads kann an nicht genehmigte Ziele gehen, etwa an persönliche Konten oder nicht freigegebene Werkzeuge. Selbst innerhalb zugelassener Domains und Anwendungen bleiben Lücken: Ein Nutzer kann etwa Gesundheitsdaten über ein persönliches Konto in eine KI-Eingabe geben oder sensible Dateien in einem privaten Google Drive ablegen statt im Unternehmenskonto. Aus Sicht klassischer DLP ist diese Aktivität oft nicht von normaler Nutzung derselben Domain zu unterscheiden.
Keep Aware schildert einen typischen Ablauf: Ein Entwickler öffnet das private GitHub-Repository des Unternehmens, kopiert proprietären Quellcode und fügt ihn in einer persönlichen ChatGPT-Sitzung ein, um ein Problem zu lösen. In diesem Moment hat sensibler Code die Organisation verlassen. Es wurde keine Datei herunter- oder hochgeladen; da das Unternehmen den Datenverkehr zu ChatGPT erlaubt, greift kein netzwerkbasierter Schutz, und keine klassische DLP-Kontrolle meldet den Einfügevorgang.
Genau hier setzt browser-native DLP an. Eine solche Lösung erkennt laut Keep Aware die sensiblen Daten, versteht, dass sie aus einer genehmigten Anwendung stammen, und bemerkt, dass sie an ein nicht genehmigtes KI-Werkzeug mit persönlichem Konto gehen. Eine Richtlinie kann die Aktion dann blockieren oder das Sicherheitsteam warnen und zugleich einen vollständigen zeitlichen Ablauf erfassen.
Klassische DLP-Werkzeuge wurden für ein anderes Risikomodell entworfen. Endpunkt-DLP sieht weder, was im Browser kopiert und eingefügt wird, noch welche Web-Anwendung oder welcher Kontotyp beteiligt ist. Netzwerk-DLP fehlt derselbe Kontext — selbst wenn Proxy-Lösungen verschlüsselten Browser-Verkehr aufbrechen —, und verteilte Belegschaften verschärfen das Sichtbarkeitsproblem. Cloud-DLP wiederum kontrolliert nur eine bestimmte, ohnehin bereits freigegebene SaaS-Instanz oder Cloud-Umgebung.
Browser-native DLP arbeitet direkt in der Sitzung des Nutzers. Nach Darstellung des Anbieters ersetzt dieser Ansatz den bestehenden DLP-Bestand nicht, sondern ergänzt ihn und schließt eine Sichtbarkeitslücke, die netzwerk- und endpunktbasierte Werkzeuge konstruktionsbedingt nicht abdecken. Keep Aware analysiert nach eigenen Angaben getippte Eingaben, Kopier- und Einfügevorgänge sowie Uploads in Echtzeit — samt Kontext zu Anwendung, Instanz und Konto — und erlaubt Richtlinien, die Aktionen blockieren, Nutzer vorab warnen oder freigegebene Abläufe mit Schutzmaßnahmen zulassen.
Der Beitrag ist gesponsert und stammt von Keep Aware.