Wie Remote Browser Isolation die Zero-Trust-Architektur Remote Browser Isolation

Remote browser isolation RBI) ist einer der direktesten technischen Ausdrucksformen des Kernprinzips von Zero Trust: Keinen Inhalten, keiner Sitzung und keinem Gerät darf jemals implizites Vertrauen gewährt werden. Für Sicherheitsarchitekten, die Kontrollmaßnahmen an die Grundsätze des NIST SP 800-207 und das CISA Zero Trust Maturity Model anpassen, schließt die RBI eine Lücke, die durch SWG-URL-Filterung und Endpunkt-Erkennung allein nicht geschlossen werden kann – nämlich browserbasierte Bedrohungen, die ausgeführt werden, bevor eine Entscheidung getroffen wird. Dieser Artikel erläutert genau, wie RBI mit den Zero-Trust-Grundsätzen „explizite Überprüfung“, „Prinzip der geringsten Berechtigungen“ und „Annahme eines Sicherheitsverstoßes“ in Einklang steht und wo es neben ZTNA, SWG, CASB und DLP innerhalb eines modernen SSE-Stacks seinen Platz findet.

Was ist Remote Browser Isolation?

Remote browser isolation eine Sicherheitstechnologie, bei der Web-Browsing-Sitzungen in einem in der Cloud gehosteten Container ausgeführt werden, wodurch der gesamte Webcode physisch vom Endgerät des Benutzers getrennt wird. Das lokale Gerät verarbeitet aktiven Webcode niemals direkt; stattdessen empfängt es lediglich einen Pixelstrom oder ein bereinigtes, rekonstruiertes DOM.

Stellen Sie sich eine Beschaffungsanalystin bei einem mittelständischen Hersteller vor, die einen Link von einem neuen Lieferanten erhält. Die Domain wurde erst letzte Woche registriert, verfügt über keine URL-Reputation und befindet sich in der „unkategorisierten“ Grauzone, in der ein herkömmliches SWG sie entweder blockieren (was die Analystin frustrieren würde) oder zulassen würde (wobei man dem Unbekannten vertraut). Mit RBI wird die Seite in einem wegwerfbaren Cloud-Container geladen. Die Analystin sieht eine vollständig interaktive Seite – sie füllt ein Formular aus, lädt ein PDF herunter –, doch weder JavaScript noch ActiveX noch eingebettete Exploits gelangen jemals auf ihren Laptop. Sollte die Seite einen Zero-Day-Exploit enthalten, wird dieser harmlos innerhalb des Containers ausgelöst, der in dem Moment gelöscht wird, in dem sie den Tab schließt.

Dieses Modell ist wichtiger denn je. Die Google Threat Intelligence Group (GTIG) hat im Jahr 2024 75 Zero-Day-Schwachstellen erfasst, die in der Praxis ausgenutzt wurden, wobei 44 % dieser Angriffe auf Unternehmenstechnologien abzielten (GTIG, April 2025). Browserbasierte Angriffsketten stellen nach wie vor einen beständigen Angriffsvektor dar, und RBI bietet einen mehrschichtigen Schutz, unabhängig davon, ob die Bedrohung bekannt ist oder nicht.

Warum RBI für Zero Trust von Bedeutung ist

Zero Trust ist kein Produkt, das man kauft – es handelt sich vielmehr um eine Reihe von Gestaltungsprinzipien. In NIST SP 800 207 (2020) heißt es, dass Zero Trust davon ausgeht, dass Ressourcen oder Benutzerkonten kein implizites Vertrauen gewährt wird, das sich ausschließlich auf ihren physischen oder Netzwerkstandort oder auf die Eigentumsverhältnisse an den Ressourcen stützt. Der Browser funktioniert jedoch traditionell nach dem Prinzip des impliziten Vertrauens: Wenn eine URL die SWG-Zulassungsliste passiert oder eine Domain über ein gültiges Zertifikat verfügt, lädt der Endpunkt den gesamten vom Server gelieferten Code und führt ihn aus. Dabei handelt es sich um ein Perimeter-Vertrauensmodell, das auf eine Interaktion auf Sitzungsebene angewendet wird.

Die Reifelücke ist nach wie vor deutlich erkennbar. In der Gartner-Umfrage zur Zero-Trust-Einführung aus dem Jahr 2024 gaben 63 % der Unternehmen an, eine Zero-Trust-Strategie vollständig oder teilweise umgesetzt zu haben; Gartner stellte jedoch fest, dass Zero Trust bei den meisten Unternehmen nach wie vor nur die Hälfte oder weniger der Umgebung abdeckt und lediglich ein Viertel oder weniger des gesamten Unternehmensrisikos mindert. Eine der wichtigsten verbleibenden Lücken ist die Browsersitzung: Laut Gartner sind Browser der primäre Zugangsweg für die meisten modernen Unternehmensanwendungen, doch weniger als 10 % der Unternehmen setzen derzeit einen sicheren Unternehmensbrowser ein, auch wenn Gartner prognostiziert, dass die Einführungsrate bis 2028 auf 25 % steigen wird. Über den Browser interagieren Mitarbeiter täglich mit SaaS-Anwendungen, KI-Tools und externen Websites; dennoch behandeln viele Unternehmen ihn nach wie vor nach einem einfachen „Zulassen/Blockieren“-Modell, anstatt detaillierte Transparenz, Richtlinien und Datenschutzkontrollen anzuwenden.

Nehmen wir den Fall eines Compliance-Beauftragten im Finanzdienstleistungssektor, der auf ein von einem Drittanbieter gehostetes Regulierungsportal zugreift. Die SWG stuft die Domain als „Behörde“ ein und lässt den Zugriff zu. Das Portal des Anbieters nutzt jedoch ein anfälliges Plugin, und ein Angreifer hat einen bösartigen Iframe eingeschleust. Ohne RBI wird der Endpunkt des Compliance-Beauftragten nun zur Angriffsfläche. Mit RBI wird der Iframe in einem isolierten Container geladen, die bösartige Nutzlast erreicht den Endpunkt zu keinem Zeitpunkt, und die Beauftragte schließt ihre Aufgabe ab, ohne zu bemerken, dass die Bedrohung überhaupt existierte.

Wie sich RBI auf die drei Zero-Trust-Prinzipien bezieht

Ausdrücklich überprüfen

NIST SP 800 207 schreibt vor, dass kein System von vornherein als vertrauenswürdig gilt – das Unternehmen muss bei der Bewertung jeder Ressourcenanfrage die Sicherheitslage des jeweiligen Systems prüfen. RBI setzt diesen Grundsatz auf der Ebene der Web-Sitzungen um. Anstatt eine binäre Vertrauensentscheidung auf der Grundlage der URL-Reputation zu treffen, rendert RBI jede qualifizierte Sitzung isoliert und bewertet den Inhalt anhand seines Verhaltens innerhalb des Containers. Dadurch wird die Überprüfung von einer einmaligen Kontrolle (URL-Prüfung) auf ein kontinuierliches Containment-Modell verlagert, bei dem selbst „vertrauenswürdigen“ Domänen keine Rechte zur Ausführung von Rohcode auf Endgeräten gewährt werden.

Wenn ein Sachbearbeiter für Gesundheitserstattungsanträge ein Partnerportal öffnet und zu einer Seite navigiert, die einen „Drive-by-Download“ auslöst, sind die herkömmlichen expliziten Sicherheitskontrollen – MFA, Gerätekonformität, URL-Reputation – bereits erfolgreich durchlaufen worden. Der Benutzer ist authentifiziert, das Gerät wird verwaltet und die URL wird als sicher eingestuft. RBI fügt eine zusätzliche Verifizierungsebene hinzu: Selbst nachdem alle vorherigen Prüfungen erfolgreich durchlaufen wurden, wird dem Webinhalt selbst keine Vertrauenswürdigkeit für die Ausführung auf dem Endgerät zugeschrieben.

Prinzip der geringsten Berechtigungen

NIST SP 800 207 legt fest, dass die Prinzipien der geringsten Berechtigungen angewendet werden, um sowohl die Sichtbarkeit als auch die Zugänglichkeit einzuschränken. RBI wendet das Prinzip der geringsten Berechtigungen auf die Bereitstellung von Webinhalten an. Benutzer erhalten nur das, was sie zur Erfüllung ihrer Aufgaben benötigen: eine gerenderte visuelle Darstellung der Seite. Sie erhalten kein rohes JavaScript, CSS oder ausführbare Objekte. In RBI integrierte DLP-Kontrollen können je nach Sensibilität der Sitzung die Verwendung der Zwischenablage, das Drucken sowie das Hoch- und Herunterladen von Dateien weiter einschränken.

Ein konkretes Beispiel: Ein Managed-Services-Anbieter gewährt Auftragnehmern über ZTNA Zugriff auf das Ticketingsystem des Unternehmens. Die Auftragnehmer authentifizieren sich, durchlaufen die Gerätekonformitätsprüfungen und gelangen zur Anwendung. Der Sicherheitsarchitekt setzt jedoch zusätzlich eine RBI-Richtlinie durch: Die Sitzungen der Auftragnehmer werden isoliert ausgeführt, wobei die Funktion „Kopieren/Einfügen“ deaktiviert ist und Downloads auf flache PDF-Dateien beschränkt sind. Die Auftragnehmer können Tickets lesen und aktualisieren, jedoch keine Rohdaten extrahieren. Dies ist die Anwendung des Prinzips der geringsten Berechtigungen, das nicht nur für den Netzwerkzugang gilt, sondern auch für die Aktionen, die Benutzer innerhalb der Sitzung ausführen dürfen.

Gehen Sie von einer Sicherheitsverletzung aus

NIST SP 800 207 geht davon aus, dass das Netzwerk stets feindlich ist und dass jederzeit externe und interne Bedrohungen bestehen. RBI verkörpert dieses Prinzip bereits durch seine Konzeption: Es geht davon aus, dass jede Webseite kompromittiert werden könnte, und schafft eine Luftsperre zwischen Webinhalten und dem Endpunkt. Wie die Cloud Security Alliance feststellt, führt RBI risikoreiche Websitzungen in isolierten, kurzlebigen Cloud-Containern aus, wobei der lokale Endpunkt des Benutzers niemals direkt mit aktivem Webcode interagiert (CSA, Januar 2026).

Wenn ein Vertriebsmitarbeiter die Marketingseite eines kompromittierten SaaS-Anbieters aufruft, die über eine manipulierte JavaScript-Bibliothek eine dateilose Malware-Nutzlast übermittelt, wird diese Nutzlast innerhalb des Containers ausgeführt und beim Ende der Sitzung vernichtet. Es gibt keinen Persistenzmechanismus, keine Möglichkeit zur lateralen Bewegung und keine Spuren auf dem Endgerät. Die „Assume Breach“-Haltung wird beibehalten, auch wenn die Bedrohung alle anderen Kontrollmechanismen im Stack umgangen hat.

Wie sich RBI in das CISA-Reifegradmodell für Zero Trust einfügt

Das CISA Zero-Trust-Reifegradmodell v2.0 (2023) gliedert das Zero-Trust-Konzept in fünf Säulen – Identität, Geräte, Netzwerke, Anwendungen und Workloads sowie Daten – mit drei übergreifenden Funktionen: Transparenz und Analytik, Automatisierung und Orchestrierung sowie Governance. Die RBI leistet gleichzeitig einen Beitrag zu mehreren Säulen:

CISA-ZTMM-Säule: Beiträge zur RBI und Fälligkeitsentwicklung

NIST SP 800 207 definiert die Architektur-Triade aus Policy Engine (PE), Policy Administrator (PA) und Policy Enforcement Point (PEP). Innerhalb dieses Modells fungiert RBI als PEP auf der Ebene der Browsersitzung. Die PE bewertet den Kontext der Anfrage – Benutzeridentität, Gerätestatus, URL-Risiko, Datensensibilität – und der PA weist den RBI-Dienst an, die Sitzung zu isolieren und die entsprechenden Datenkontrollen anzuwenden. Dies steht im Einklang mit den Anforderungen der CISA an die Überprüfung pro Anfrage, wie sie von der Cloud Security Alliance (CSA, Januar 2026) beschrieben werden.

RBI im SSE-Stack: Integration mit ZTNA, SWG, CASB und DLP

RBI ist für sich genommen zwar nützlich, aber nur begrenzt einsetzbar. Sein voller „Zero-Trust“-Nutzen kommt erst dann zum Tragen, wenn es als integrierter Bestandteil einer Security Service Edge SSE)-Plattform fungiert, die SWG, CASB, ZTNA und DLP umfasst.

Betrachten Sie den Arbeitsablauf, wenn ein Mitarbeiter auf einem verwalteten Gerät über einen Browser auf ein generatives KI-Tool zugreift. Die SWG prüft die Anfrage, klassifiziert das Ziel und ermittelt das URL-Risiko. Das CASB identifiziert die KI-Anwendung und prüft, ob diese zugelassen ist. Die DLP-Engine scannt den Eingabetext auf sensible Daten. Und die RBI-Sitzung – die durch die SWG-Richtlinie ausgelöst wird, da das KI-Tool als „Monitor“ eingestuft ist – stellt sicher, dass der Mitarbeiter das Tool zwar nutzen kann, jedoch keine personenbezogenen Kundendaten einfügen, keine Antworten mit sensiblen Inhalten herunterladen oder keine Dateien mit regulierten Daten hochladen darf. All dies geschieht innerhalb einer einzigen Richtlinien-Engine und nicht über vier separate Produkte mit eigenen Konsolen hinweg.

Dieses Integrationsmuster ist der Grund, warum Gartner davon ausgeht, dass der SASE-Markt mit einer durchschnittlichen jährlichen Wachstumsrate (CAGR) von 26 % wachsen und bis 2028 ein Volumen von 28,5 Milliarden US-Dollar erreichen wird (Gartner, Februar 2025). Unternehmen führen Zugriffsmanagement, Bedrohungsschutz und Datensicherheit auf einheitlichen Plattformen zusammen, da die Alternative – das Zusammenfügen eigenständiger RBI-, SWG-, CASB- und DLP-Produkte – zu Richtlinienlücken, uneinheitlicher Durchsetzung und betrieblichem Mehraufwand führt, was das Zero-Trust-Modell untergräbt.

Skyhigh Private Access ZTNA mit DLP-Scans und nahtlosem RBI, sodass private Anwendungssitzungen isoliert werden, wenn dies gemäß den Richtlinien erforderlich ist, ohne dass der Datenverkehr über ein separates Produkt geleitet werden muss.

Wo der Browser zum Arbeitsbereich wird

Der Browser ist der primäre Arbeitsbereich für den Zugriff auf SaaS-Anwendungen, die Nutzung von KI-Tools, das Herunterladen von Dateien, die Eingabe von Anmeldedaten und die Zusammenarbeit mit Dritten. Ein Sicherheitsarchitekt, der ZTNA zum Schutz privater Anwendungen einsetzt, dabei jedoch die Browsersitzung außer Acht lässt, in der Mitarbeiter mit diesen Anwendungen interagieren, lässt eine Sicherheitslücke entstehen. RBI schließt diese Lücke – nicht, indem es die den Benutzern bereits vertrauten Browser (Chrome, Edge, Firefox, Safari) ersetzt, sondern indem es die Sitzung in eine cloudbasierte Isolationsschicht einbindet, die durch SSE-Richtlinien gesteuert wird.

Ein nicht verwalteter Auftragnehmer öffnet die CRM-Anwendung eines Unternehmens über einen Reverse-Proxy-CASB. Der CASB authentifiziert den Auftragnehmer, wendet Sitzungskontrollen an und löst eine RBI-Richtlinie aus, da es sich um ein nicht verwaltetes Gerät handelt. Der Auftragnehmer sieht und nutzt das CRM wie gewohnt, doch im Hintergrund läuft die Sitzung isoliert mit Einschränkungen für die Zwischenablage und einer Blockierung von Downloads. Das Unternehmen schützt die Daten, ohne den Auftragnehmer dazu zu zwingen, einen Agenten zu installieren, ein Gerät zu registrieren oder einen proprietären Browser zu verwenden.

Bewertungskriterien: Worauf Sie bei einem Zero-Trust-RBI achten sollten

Nicht jede RBI-Implementierung bietet den gleichen Zero-Trust-Nutzen. Sicherheitsarchitekten, die die Browserisolierung prüfen, sollten folgende Kriterien berücksichtigen:

1. Native SSE-Integration. RBI muss Teil derselben Richtlinien-Engine sein wie SWG, CASB, ZTNA und DLP. Wenn RBI eine separate Konsole, separate Richtlinien oder eine separate Datenverkehrssteuerung erfordert, führt dies zu betrieblichen Lücken und Inkonsistenzen bei den Richtlinien.

2. Detaillierte Datensteuerungen innerhalb isolierter Sitzungen. Das Zero-Trust-Modell erfordert die Durchsetzung des Prinzips der geringsten Berechtigungen auf Sitzungsebene. RBI sollte die Möglichkeit bieten, die Funktionen „Zwischenablage“, „Drucken“, „Hochladen“, „Herunterladen“ und „Bildschirmaufnahme“ unabhängig voneinander pro Richtlinie, pro Benutzergruppe und pro Anwendungskategorie zu deaktivieren.

3. Unterstützung nicht verwalteter Geräte. Eine Lösung, die zur Isolierung einen Endpunkt-Agenten erfordert, steht im Widerspruch zu einem der Hauptanwendungsfälle von RBI: dem Schutz vor Zugriffen durch Geräte, die nicht unter der Kontrolle des Unternehmens stehen.

4. Leistung und Benutzererlebnis. Sollte RBI spürbare Verzögerungen verursachen, werden die Nutzer dies umgehen – indem sie Links auf ihren privaten Geräten öffnen, mobile Hotspots nutzen oder sich einfach so lange beschweren, bis die IT-Abteilung Ausnahmen gewährt. Die Isolationsschicht muss Seiten nahezu mit nativer Geschwindigkeit darstellen.

5. Wiedergabetreue. Moderne SaaS-Anwendungen sind komplexe, JavaScript-lastige Single-Page-Anwendungen. RBI muss diese verarbeiten, ohne dass die Funktionalität beeinträchtigt wird, interaktive Elemente fehlen oder die Benutzererfahrung verschlechtert wird.

6. Skalierbare, richtlinienbasierte Aktivierung. Bei Zero Trust ist es nicht erforderlich, jede Sitzung zu isolieren. Die besten Implementierungen ermöglichen es Sicherheitsteams, risikobasierte Auslöser zu definieren: Isolierung nicht kategorisierter URLs, Isolierung aller Sitzungen von Benutzern mit hohem Risiko, Isolierung bestimmter SaaS-Kategorien oder Isolierung des gesamten Datenverkehrs von nicht verwalteten Geräten.

7. Transparenz und Analytik. Die RBI sollte Sitzungsdaten in die übergeordnete SSE-Analyseebene einspeisen und so zur bereichsübergreifenden Funktion „Transparenz und Analytik“ des CISA-ZTMM beitragen. Das bedeutet, zu wissen, wer wann, von wo aus und mit welchem Gerät auf welche Inhalte zugegriffen hat – und ob dieses Verhalten von der Basislinie abweicht.

Die Kosten des „blinden Flecks“ beim Surfen

Browser-Sitzungen außerhalb von Zero-Trust-Kontrollen zu belassen, ist mit messbaren Kosten verbunden. Laut dem IBM-Bericht „Cost of a Data Breach Report 2024“ (Juli 2024) beliefen sich die weltweiten Durchschnittskosten einer Datenpanne im Jahr 2024 auf 4,88 Millionen US-Dollar. Kompromittierte Anmeldedaten waren mit einem Anteil von 16 % aller Vorfälle der häufigste Angriffsvektor.

Browserbasiertes Phishing ist einer der wichtigsten Mechanismen zum Diebstahl von Zugangsdaten. Ein Lohnbuchhalter erhält einen Link zu einer Seite, die wie die Anmeldeseite eines Portals für Sozialleistungen aussieht. Die Domain wurde erst kürzlich registriert, besteht die DMARC-Prüfung und wirkt vertrauenswürdig. Ohne RBI gibt der Lohnbuchhalter seine Zugangsdaten auf der Seite des Angreifers ein, und der Diebstahl der Zugangsdaten ist vollzogen. Da RBI eine Isolationsrichtlinie für nicht kategorisierte Domains durchsetzt, wird die Phishing-Seite in einem Container geladen, DLP erkennt das Muster der Zugangsdatenübermittlung, und die Sitzung wird beendet, bevor die Zugangsdaten die isolierte Umgebung verlassen.

Die finanzielle Rechtfertigung für RBI ist nicht rein theoretischer Natur. Unternehmen, die Sicherheitslücken auf Browser-Ebene schließen, verringern ihr Risiko durch die kostspieligsten Angriffsvektoren – den Diebstahl von Anmeldedaten, die Verbreitung von Malware über das Internet sowie den Datendiebstahl durch unbeaufsichtigte Browseraktionen.

Häufige Fehler bei der Implementierung von RBI in einem Zero-Trust-Modell

Einsatz von RBI als eigenständiges Produkt. Ohne SSE-Integration wird RBI zu einer weiteren Punktlösung mit einem eigenen Richtlinien-Silo. Ein Gesundheitssystem, das RBI getrennt von seiner SWG einsetzt, verfügt letztendlich über zwei unterschiedliche URL-Kategorisierungsprogramme, zwei Richtlinienkonsolen und es kommt unweigerlich zu Abweichungen. Richtlinien stehen im Widerspruch zueinander, Ausnahmen nehmen überhand und das Zero-Trust-Modell wird beeinträchtigt.

Nicht alles immer isolieren. Eine pauschale Isolierung verschwendet Rechenressourcen und beeinträchtigt die Leistung bei Sitzungen mit geringem Risiko. Ein risikobasierter Ansatz – bei dem nicht kategorisierte Domänen, Benutzergruppen mit hohem Risiko und sensible Anwendungskategorien isoliert werden – sorgt für bessere Sicherheitsergebnisse bei geringerem Aufwand.

Nicht verwaltete Geräte werden außer Acht gelassen. Bei einigen Implementierungen müssen Agenten den Datenverkehr an den Isolationsdienst umleiten, wodurch genau der Anwendungsfall (Auftragnehmer, BYOD, M&A-Übergänge) ausgeschlossen wird, in dem RBI den größten Nutzen bietet. Ein Einzelhändler, der saisonale Lagerleiter mit privaten Tablets einarbeitet, benötigt eine agentenlose Isolation und keine agentenabhängige Umleitung.

Vernachlässigung von DLP in isolierten Sitzungen. RBI ohne Datenkontrollen verhindert zwar Malware, nicht jedoch den Datendiebstahl. Ein Mitarbeiter, der Kundendaten nicht über einen normalen Browser in eine private E-Mail einfügen kann, hat in einer isolierten Sitzung weiterhin die Möglichkeit dazu, sofern keine Kontrollen der Zwischenablage durchgesetzt werden.

RBI als Ersatz für VDI betrachten. RBI isoliert Browsersitzungen, nicht jedoch vollständige Desktops. Es ergänzt VDI für bestimmte Anwendungsfälle (Webzugriff für Dritte), ersetzt es jedoch nicht für Benutzer, die native Desktop-Anwendungen benötigen.