Sicherheit für SaaS-Anwendungen durch Kontrollmaßnahmen auf Browserebene

Ihr CASB verhindert, dass ein Auftragnehmer eine Kundenliste aus Salesforce auf einen nicht verwalteten Laptop herunterlädt. Fünf Sekunden später markiert derselbe Auftragnehmer die gesamte Tabelle, kopiert sie in die Zwischenablage, fügt sie in ein persönliches Gmail-Fenster zum Verfassen einer E-Mail ein und klickt auf „Senden“. Das CASB bemerkt davon nichts. Der Browser hingegen schon – und hätte dies mit den richtigen Kontrollmaßnahmen verhindern können. Dieser Leitfaden führt SaaS-Sicherheitsadministratoren und CASB-Betreiber durch einen schrittweisen Ansatz zur Schließung dieser Lücke, indem Kontrollmaßnahmen auf Browserebene eingesetzt werden – remote browser isolation (RBI), Richtlinien für secure web gateway SWG), DLP und Sitzungsmaßnahmen – auf bestehende CASB-Implementierungen aufzusetzen.

Voraussetzungen: Was Sie vor Beginn bereitstellen sollten

Bevor Sie die Steuerungsfunktionen auf Browserebene aktivieren, vergewissern Sie sich bitte, dass Ihre Umgebung vier grundlegende Voraussetzungen erfüllt. Werden diese übersprungen, führt dies zu Richtlinienkonflikten, Frustration bei den Benutzern und einer unvollständigen Abdeckung.

1. Eine CASB-Lösung, die bereits im Forward- und Reverse-Proxy-Modus bereitgestellt ist. Sie benötigen eine Inline-Verkehrsprüfung für genehmigte SaaS-Anwendungen (Reverse-Proxy) sowie Transparenz hinsichtlich Schatten-IT (Forward-Proxy) als Grundlage für die Durchsetzung Ihrer Richtlinien. Sollte Ihre CASB-Bereitstellung ausschließlich über eine API erfolgen, fehlt Ihnen der Inline-Pfad, den Browser-Kontrollen abdecken.

2. Einheitliche DLP-Richtlinien-Engine. Kontrollen auf Browserebene müssen sich auf dieselben Datenklassifizierungen beziehen – personenbezogene Daten (PII), geschützte Gesundheitsdaten (PHI), Finanzdaten, Quellcode, geistiges Eigentum –, die auch in Ihren CASB- und E-Mail-DLP-Richtlinien verwendet werden. Sollten Ihre DLP-Definitionen in getrennten Silos vorliegen, sollten Sie zunächst mit deren Konsolidierung beginnen. Uneinheitliche Klassifizierungen führen dazu, dass ein Kanal blockiert, was ein anderer zulässt. Eine zentralisierte DLP-Plattform verhindert diese Fragmentierung.

3. Integration eines Identitätsanbieters (IdP) und Bewertung des Gerätestatus. Browsersteuerungen werden wesentlich nützlicher, wenn sie sich daran anpassen, wer der Benutzer ist und welches Gerät er nutzt. Ein Marketing-Freiberufler, der ein privates MacBook nutzt, sollte strengere Einschränkungen erhalten als ein festangestellter Finanzanalyst, der einen verwalteten Windows-Endpunkt nutzt. Dies erfordert eine SAML/OIDC-Verbundlösung mit Ihrem IdP sowie Überprüfungen des Gerätestatus (verwaltet vs. nicht verwaltet, Patch-Stand des Betriebssystems, Status der Festplattenverschlüsselung).

4. Bestandsaufnahme der SaaS-Anwendungen mit Einstufung der Vertraulichkeitsstufe. Sie können keine Browser-Richtlinien festlegen, ohne zu wissen, welche SaaS-Anwendungen vertrauliche Daten enthalten. Ordnen Sie Ihre 20 bis 50 wichtigsten SaaS-Anwendungen nach Vertraulichkeitsstufen (kritisch, hoch, mittel, niedrig) ein. Die „SaaS Governance Best Practices“ der CSA empfehlen, Risiken in allen Phasen des SaaS-Lebenszyklus zu bewerten – Bewertung, Einführung, Nutzung und Beendigung. Diese Bestandsaufnahme dient als Grundlage für die Festlegung Ihrer Richtlinien.

Phase 1: Schließung der Sicherheitslücken bei der Zwischenablage und beim Herunterladen in Szenarien mit hohem Risiko

Beginnen Sie dort, wo das Risiko am höchsten und die Nutzerzahl am geringsten ist: bei nicht verwalteten Geräten, die auf sensible SaaS-Anwendungen zugreifen.

Das Szenario, das Phase 1 rechtfertigt: Ein externer Prüfer meldet sich von einem privaten Laptop aus über SSO bei Ihrer Workday-Instanz an. Ihr CASB-Reverse-Proxy authentifiziert die Sitzung und blockiert Dateidownloads gemäß den Richtlinien. Der Prüfer öffnet jedoch einen Bericht zur Mitarbeitervergütung, wählt dreißig Zeilen mit Gehaltsdaten aus, kopiert diese, öffnet in einem neuen Tab ein persönliches Google-Tabellen-Dokument und fügt die Daten dort ein. Das CASB erkannte eine authentifizierte Workday-Sitzung und eine Google-Tabellen-Sitzung – zwei separate, jeweils für sich zulässige Ereignisse. Es hat den Datenaustausch zwischen diesen beiden Sitzungen nicht erfasst, da der Vorgang mit der Zwischenablage vollständig innerhalb des Rendering-Kontexts des Browsers stattfand.

Was Sie bereitstellen sollten: Aktivieren Sie remote browser isolation alle Sitzungen auf nicht verwalteten Geräten, die auf SaaS-Anwendungen der Stufen 1 (kritisch) und 2 (hoch) zugreifen. Bei der RBI wird die SaaS-Anwendung in einem in der Cloud gehosteten Container dargestellt, und es werden lediglich Pixel an den Browser des Benutzers gestreamt. Diese Architektur ermöglicht Ihnen eine detaillierte Kontrolle über die Aktionen innerhalb der Sitzungen:

Einschränkung beim Kopieren und Einfügen: Blockieren Sie Lese- und Schreibvorgänge in der Zwischenablage aus der isolierten Sitzung, oder lassen Sie das Einfügen zu, blockieren Sie jedoch das Kopieren, um zu verhindern, dass Daten den Kontext der SaaS-Anwendung verlassen.

Download-Unterdrückung: Verhindern Sie das Herunterladen von Dateien aus der gerenderten Sitzung vollständig oder beschränken Sie das Herunterladen auf bestimmte Dateitypen.

Druckblockierung: Deaktivieren Sie die Befehle „Drucken“ und „Als PDF drucken“.

Wasserzeichen für Screenshots: Fügen Sie dem gerenderten Stream ein sichtbares oder forensisches Wasserzeichen ein, das die E-Mail-Adresse des Benutzers und einen Zeitstempel enthält, um die Erstellung von Screenshots zu verhindern.

NIST SP 800-53 SC 7 schreibt vor, dass Systemkomponenten durch Grenzschutzmechanismen isoliert werden müssen, um Informationsflüsse zu steuern und den potenziellen Schaden durch böswillige Angriffe und Fehler zu begrenzen. RBI schafft genau diese Grenze zwischen den Daten der SaaS-Anwendung und dem lokalen Gerät des Benutzers und setzt dabei Kontrollen des Informationsflusses durch, die ein Netzwerk-Proxy nicht leisten kann.

Einschränkung des Anwendungsbereichs: Wenden Sie diese Kontrollmaßnahmen in Phase 1 ausschließlich auf nicht verwaltete Geräte und Auftragnehmer an. Verwaltete Endgeräte, auf denen ein Agent installiert ist und deren Sicherheitsstatus überprüft wurde, können weniger strenge Kontrollmaßnahmen (wie z. B. Wasserzeichen ohne Sperrung der Zwischenablage) erhalten, um die Produktivität aufrechtzuerhalten.

Phase 2: Ausweitung der Browser-DLP auf verwaltete Endgeräte und umfassendere SaaS-Abdeckung

Sobald sich Phase 1 stabilisiert hat – in der Regel nach 4 bis 6 Wochen der Telemetriedatenerfassung und der Feinabstimmung der Richtlinien –, erweitern Sie die Abdeckung auf verwaltete Geräte und eine breitere Palette von SaaS-Anwendungen.

Das Szenario, das Phase 2 rechtfertigt: Ein Vollzeit-Vertriebsmitarbeiter greift über einen verwalteten Laptop über Chrome auf Salesforce zu. Er öffnet einen Kundenstammsatz, kopiert den Namen, den Firmennamen und die Telefonnummer des Ansprechpartners und fügt diese Angaben anschließend in ChatGPT ein, um eine personalisierte Kontakt-E-Mail zu erstellen. Es wurde keine Datei heruntergeladen. Es wurde keine Freigaberegel von Salesforce verletzt. Dennoch haben die personenbezogenen Daten des Kunden gerade Ihre kontrollierte SaaS-Umgebung verlassen und sind über die Zwischenablage des Browsers in ein KI-Tool eines Drittanbieters gelangt.

Laut dem „State of SaaS Security Report“ (2025) von CSA geben 63 % der Unternehmen an, dass Daten übermäßig nach außen weitergegeben werden, und 56 % berichten, dass Mitarbeiter sensible Daten in nicht autorisierte SaaS-Anwendungen hochladen – häufig genau über jene Zwischenablage- und Upload-Pfade, die herkömmliche Kontrollmechanismen übersehen. DLP auf Browserebene ist die Kontrollmaßnahme, die diese Aktionen abfängt, bevor die Daten das nicht genehmigte Ziel erreichen.

Was soll bereitgestellt werden:

SWG hat die DLP-Prüfung auf verwalteten Endgeräten durchgesetzt. Ihr secure web gateway fängt den Browser-Datenverkehr ab und wendet die DLP-Klassifizierung auf Daten in Bewegung an – einschließlich der Übermittlung von Formularfeldern, des Einfügens von Inhalten aus der Zwischenablage in Webanwendungen sowie des Hochladens von Dateien über den Browser. Dadurch wird das oben beschriebene Szenario von Salesforce zu ChatGPT erfasst.

Selektive RBI für sensible Kategorien. Anstatt den gesamten Webverkehr zu isolieren, leiten Sie Sitzungen zu Tier-1- und Tier-2-SaaS-Anwendungen über RBI weiter, sobald das Verhalten des Benutzers ein Risikosignal auslöst (z. B. Zugriff auf ein Kundendatenobjekt, Öffnen einer Exportansicht, Aufruf eines KI-Tools mit Unternehmenszugangsdaten).

Wasserzeichen zur Verhinderung von Sitzungsaufzeichnungen. Fügen Sie Sitzungen, in denen sensible Daten angezeigt werden, sichtbare Wasserzeichen hinzu, sodass im Falle einer Bildaufnahme des Bildschirms durch einen Benutzer anhand des Wasserzeichens der konkrete Benutzer, die Sitzung und der Zeitstempel ermittelt werden können.

Grundsatz zur Richtliniengestaltung aus NIST SP 800-53 AC 4: Mechanismen zur Durchsetzung von Zugriffsrechten können auf Anwendungs- und Dienstebene eingesetzt werden, um eine erhöhte Informationssicherheit zu gewährleisten und Informationsflüsse in einem Umfang zu kontrollieren, der über die Möglichkeiten von Kontrollen auf Netzwerkebene hinausgeht. DLP- und RBI-Lösungen auf Browserebene arbeiten genau auf dieser Anwendungs- und Dienstebene und bieten zusätzliche Durchsetzungsmöglichkeiten, die CASB-Proxys auf Netzwerkebene nicht erreichen können.

Phase 3: Integration von Browser-Steuerelementen in Ihre SSE-Richtlinienstruktur

Die Bereitstellung von Browser-Kontrollen als eigenständige Ebene verursacht zusätzlichen Betriebsaufwand: separate Richtlinien, separate Konsolen, separate Vorfallwarteschlangen. Phase 3 vereint die Durchsetzung auf Browserebene mit Ihrem umfassenderen Security Service Edge (SSE)-Plattform, sodass eine einzige Richtlinien-Engine die Entscheidungen in den Bereichen CASB, SWG, DLP, RBI und ZTNA steuert.

Das Szenario, das Phase 3 rechtfertigt: Ihr SOC erhält drei Warnmeldungen: eine CASB-Warnmeldung, dass ein Benutzer auf eine „Shadow“-SaaS-Anwendung zugegriffen hat, eine SWG-Warnmeldung, dass die Browsersitzung desselben Benutzers einen DLP-Musterabgleich ausgelöst hat, und eine RBI-Warnmeldung, dass eine Kopieraktion in die Zwischenablage blockiert wurde. Drei Konsolen, drei Analysten, drei Tickets – für einen einzigen Benutzer, der eine einzige Abfolge von Aktionen ausführt. Die Unified-SSE-Richtlinie fasst dies zu einem einzigen korrelierten Ereignis mit einem einzigen Reaktions-Workflow zusammen.

Was soll bereitgestellt werden:

Einheitliche Richtlinienregeln, die in einer einzigen Bedingung auf die Benutzeridentität, den Gerätestatus, die Sensitivitätsstufe der SaaS-Anwendung, die Datenklassifizierung und die Art der Browseraktion (Herunterladen, Zwischenablage, Drucken, Hochladen) Bezug nehmen.

Adaptive Isolierung, die eine Sitzung automatisch auf „Full RBI“ hochstuft, wenn die SSE-Plattform eine Kombination von Signalen erkennt – beispielsweise wenn ein nicht verwaltetes Gerät auf eine Tier-1-Anwendung zugreift, während DLP sensible Inhalte auf der Seite erkennt.

Die Telemetriedaten der Sitzungen werden an das SIEM/SOAR-System weitergeleitet, sodass Ereignisse auf Browserebene (Sperrung der Zwischenablage, Einblendung von Wasserzeichen, Unterdrückung von Downloads) neben den CASB-, SWG- und ZTNA-Ereignissen zur Korrelation und Untersuchung sichtbar sind.

Das „Zero Trust Maturity Model“ der CISA fordert Organisationen dazu auf, bereitgestellte Anwendungen mithilfe granularer Zugriffskontrollen und integrierter Schutzmaßnahmen gegen Bedrohungen zu verwalten und zu sichern, um eine optimale Reifegradstufe in den Säulen „Anwendungen und Workloads“ sowie „Daten“ zu erreichen. Durch die Integration von Kontrollen auf Browserebene in die SSE-Richtlinie setzen Sie diese Leitlinien für SaaS-Anwendungen, auf die über den Browser zugegriffen wird, in die Praxis um.

Integrationspunkte: Wo Browser-Steuerelemente an Ihre bestehende Infrastruktur angebunden werden

Kontrollmechanismen auf Browserebene ersetzen bestehende Sicherheitstools nicht – sie schließen vielmehr die Lücke bei der Durchsetzung zwischen diesen Tools. Ordnen Sie die Integrationspunkte klar zu, um Doppelarbeit zu vermeiden und eine lückenlose Abdeckung sicherzustellen.

Betrachten Sie einen realen Integrationsablauf: Eine Organisation im Gesundheitswesen nutzt den CASB-API-Modus, um in Box gespeicherte geschützte Gesundheitsdaten (PHI) zu scannen und Richtlinien für die Weitergabe durchzusetzen. Wenn jedoch eine Pflegefachkraft auf ihrem privaten Tablet ein Patientendokument über den Browser öffnet, wurde der API-Scan bereits durchgeführt – er verhindert nicht, dass die Diagnose des Patienten über die Zwischenablage in eine Messaging-App kopiert wird. Eine RBI-Sitzung mit Einschränkungen für die Zwischenablage und Wasserzeichen schließt diese Lücke, ohne dass ein Endpunkt-Agent auf dem privaten Tablet erforderlich ist. Der Ansatz Skyhigh Security zum Schutz von Cloud-Anwendungen vor nicht verwalteten Geräten adressiert genau diesen Anwendungsfall, indem er Reverse-Proxy, RBI und DLP in einer integrierten Richtlinie kombiniert.

Kennzahlen und Erfolgskriterien

Kontrollen auf Browserebene generieren Telemetriedaten, die mit früheren reinen CASB-Implementierungen nicht erfasst werden konnten. Legen Sie die Kennzahlen vor der Implementierung fest, damit Sie den Nutzen nachweisen und die Richtlinien optimieren können.

Betriebskennzahlen (wöchentliche Erfassung):

Blockieren Sie Zwischenablage-Ereignisse nach Benutzer, Anwendung oder Gerätetyp. Ein sprunghafter Anstieg der Zwischenablage-Blockierungen bei einem bestimmten Benutzer kann auf einen Exfiltrationsversuch hindeuten oder darauf, dass eine Richtlinie für einen legitimen Arbeitsablauf zu restriktiv ist. Untersuchen Sie Ausreißer.

Laden Sie Ereignisse zur Download-Unterdrückung herunter. Verfolgen Sie diese nach SaaS-Anwendung und Benutzerrolle. Eine hohe Anzahl blockierter Downloads aus einer bestimmten Anwendung kann darauf hindeuten, dass die Benutzer eine sichere Alternative benötigen (z. B. einen Viewer im schreibgeschützten Modus oder einen kontrollierten Export-Workflow).

Wasserzeichen haben Ermittlungen ausgelöst. Zählen Sie, wie oft ein mit einem Wasserzeichen versehener Screenshot oder ein ausgedrucktes Dokument im Rahmen einer Ermittlung zu einem Nutzer zurückverfolgt werden konnte. Selbst eine geringe Zahl belegt die abschreckende Wirkung.

Anträge auf Ausnahmen von Richtlinien. Verfolgen Sie, wie viele Benutzer Ausnahmen von den Browsereinschränkungen beantragen und welche Gründe dafür angegeben werden. Ein hohes Ausnahmevolumen für eine bestimmte App deutet darauf hin, dass die Richtlinie angepasst werden muss.

Kennzahlen zur Risikominderung (vierteljährliche Erfassung):

Rückgang der Vorfälle mit sensiblen Daten, die die Zwischenablage oder Upload-Pfade von SaaS-Anwendungen betreffen. Vergleichen Sie das Vorfallvolumen vor und nach der Einführung von Browser-Kontrollen für dieselben SaaS-Anwendungen und Nutzergruppen.

Abdeckungsgrad der Sitzungssteuerung für nicht verwaltete Geräte. Ermitteln Sie den prozentualen Anteil der SaaS-Sitzungen auf nicht verwalteten Geräten, die über RBI laufen, im Vergleich zu denen, die RBI umgehen. Streben Sie für Tier-1-Anwendungen eine Abdeckung von mindestens 95 % an.

Durchschnittliche Zeit bis zur Erkennung von Versuchen, Daten über den Browser zu exfiltrieren. Die Browser-Telemetrie sollte die Erkennungszeit von Tagen (bei Verwendung von nachträglichen DLP-Scan-Warnmeldungen) auf Sekunden (Echtzeit-Sperrung der Zwischenablage) verkürzen.

Der Verizon DBIR 2025 ergab, dass 60 % der Sicherheitsvorfälle auf menschliches Versagen zurückzuführen waren – also auf Klicks, Kopiervorgänge, Uploads und Einfügevorgänge durch den Nutzer. Kontrollen auf Browserebene erfassen genau diese menschlichen Handlungen und liefern Ihrem SOC Einblicke in einen Angriffsvektor, den Netzwerk- und API-Kontrollen gänzlich übersehen. Gleichzeitig berichtet Forrester, dass etwa jede fünfte Datenpanne auf Vorfälle durch Insider zurückzuführen ist (2026), und Kontrollen der Browsersitzungen ermöglichen eine direkte Echtzeit-Überwachung der Zwischenablage und der Upload-Pfade, die Insider am häufigsten ausnutzen.

Häufige Fehler

Fehler 1: Die vollständige RBI-Isolation für alle Benutzer vom ersten Tag an einzuführen. Eine vollständige Pixel-Streaming-Isolation verändert das Surferlebnis. Die Latenzzeit steigt leicht an, einige Browser-Erweiterungen funktionieren nicht mehr, und komplexe Webanwendungen werden möglicherweise anders dargestellt. Wenn Sie dies gleichzeitig auf 5.000 Mitarbeiter ausweiten, wird es beim Helpdesk zu Protesten kommen, und die Geschäftsleitung wird das Projekt einstellen. Beginnen Sie mit nicht verwalteten Geräten und risikoreichen Anwendungen. Erweitern Sie den Einsatz schrittweise.

Fehler 2: Die Anwendung identischer Browserrichtlinien auf verwaltete und nicht verwaltete Geräte. Ein nicht verwalteter Laptop eines Auftragnehmers erfordert eine vollständige Sperrung der Zwischenablage und eine Unterbindung von Downloads. Ein verwalteter Unternehmensendpunkt mit einem Agenten, verifizierter Festplattenverschlüsselung und aktuellen Patches benötigt möglicherweise lediglich Wasserzeichen und selektive Einschränkungen beim Einfügen. Differenzieren Sie die Richtlinien je nach Gerätestatus. Das Risikoprofil eines kompromittierten Zugangsdatensatzes auf einem verwalteten Gerät mit EDR unterscheidet sich grundlegend von dem auf einem nicht verwalteten Gerät ohne Transparenz – Ihre Browserrichtlinien sollten diese Asymmetrie widerspiegeln.

Fehler 3: Das Ignorieren von KI-Tool-Zielen in der DLP-Richtlinie. Viele Unternehmen haben ihre Browser-DLP-Einstellungen so konfiguriert, dass Uploads in traditionelle „Shadow-IT“-Kategorien – wie persönliche Cloud-Speicher oder Webmail – blockiert werden, haben dabei jedoch vergessen, KI-Assistenten einzubeziehen. KI-Tools gehören mittlerweile zu den häufigsten nicht autorisierten Zielen für eingefügte und hochgeladene Daten. Aktualisieren Sie Ihre SWG- und DLP-URL-Kategorien, um generative KI-Dienste einzubeziehen, und wenden Sie dieselben Einschränkungen für die Zwischenablage und das Hochladen an, die Sie auch für andere nicht genehmigte Anwendungen durchsetzen.

Fehler 4: Browser-Steuerelemente als eigenständiges Projekt statt als Erweiterung der SSE-Richtlinien zu behandeln. Wenn Browser-Steuerelemente in einer separaten Konsole mit eigenen Richtlinien untergebracht sind, werden sie zu einem weiteren Tool, das das SOC ignoriert. Integrieren Sie sie ab Phase 3 in Ihre SSE-Plattform, damit Browser-Ereignisse in einem einzigen Vorfall-Workflow mit CASB-, SWG- und ZTNA-Ereignissen korreliert werden können.

Fehler 5: Das Versäumnis, SaaS-Anwendungen vor der Erstellung von Richtlinien nach ihrer Sensitivität zu klassifizieren. Ohne ein nach Sensitivitätsstufen gegliedertes SaaS-Inventar kommt es entweder zu einer übermäßigen Sperrung (wodurch Anwendungen mit geringem Risiko isoliert und die Nutzer verärgert werden) oder zu einer unzureichenden Sperrung (wodurch kritische Anwendungen ohne Kontrollen bleiben). Großunternehmen nutzen routinemäßig Dutzende bis Hunderte von SaaS-Angeboten, und die Klassifizierung ist keine Option – sie ist die Grundlage für gezielte Richtlinien, die sowohl Sicherheitslücken als auch Unmut bei den Nutzern vermeiden.