Was ist Remote Browser Isolation wie funktioniert RBI?

Remote browser isolation RBI) werden Webinhalte nicht auf dem Endgerät des Benutzers, sondern in einem einmalig verwendbaren Cloud-Container ausgeführt. Dadurch wird sichergestellt, dass schädlicher Code von Phishing-Seiten, Zero-Day-Exploits und Drive-by-Downloads niemals das Unternehmensgerät oder -netzwerk erreicht. Für Sicherheitsarchitekten, die Browser-Isolationstechnologie im Rahmen einer Zero-Trust-Strategie evaluieren, bietet RBI ein grundlegend anderes Sicherheitsmodell: Anstatt zu versuchen, jede Bedrohung im Webverkehr zu erkennen, geht es davon aus, dass alle Webinhalte als nicht vertrauenswürdig gelten, und trennt die Ausführung physisch vom Endgerät. Dieser Ansatz gewinnt zunehmend an Bedeutung, da der Browser in jedem Unternehmen zum primären Arbeitsbereich – und zur primären Angriffsfläche – wird.

Was ist Remote Browser Isolation?

Remote browser isolation eine Cybersicherheitstechnologie, die die Web-Browsing-Aktivitäten eines Benutzers physisch von seinem lokalen Gerät und dem Unternehmensnetzwerk trennt. Wenn ein Benutzer eine Website aufruft, wird die Seite nicht im Browser seines Laptops oder seiner Workstation geladen und ausgeführt, sondern in einem sicheren, kurzlebigen Cloud-Container. Der Nutzer sieht eine sichere visuelle Darstellung der Seite und interagiert mit dieser; der gesamte zugrunde liegende Code – HTML, CSS, JavaScript, eingebettete Objekte – bleibt auf die Remote-Umgebung beschränkt. Wenn die Sitzung endet, wird der Container zusammen mit allen möglicherweise darin enthaltenen schädlichen Payloads gelöscht. Wird diese Technologie als cloudbasierter Dienst bereitgestellt, wird sie als remote browser isolation bezeichnet.

So funktioniert der Vorgang in der Praxis: Eine Marketingleiterin erhält eine E-Mail mit einem Link zu einem angeblichen Branchenbericht. Sie klickt darauf. Anstatt dass der Link direkt in Chrome auf ihrem Laptop geladen wird, wird der Datenverkehr über das secure web gatewayumgeleitet, das die nicht kategorisierte URL in eine RBI-Sitzung weiterleitet. Ein temporärer Cloud-Container wird gestartet, lädt die Seite und stellt sie dar. Die Marketingleiterin sieht eine vollständig interaktive Version der Seite – sie kann scrollen, klicken und lesen –, doch weder HTML noch JavaScript oder ausführbare Inhalte gelangen jemals auf ihren Rechner. Führt der Link zu einer Phishing-Seite, die mit einem Zero-Day-Exploit versehen ist, wird der Schadcode innerhalb des Containers ausgeführt, der nach Beendigung der Sitzung gelöscht wird. Ihr Endgerät bleibt unversehrt. Es findet kein Datenabfluss statt. Das SOC muss möglicherweise gar keinen Vorfall einordnen, da der Angriff bereits im Keim erstickt wurde.

Dieses Modell unterscheidet sich grundlegend von herkömmlichen, auf Erkennung basierenden Sicherheitslösungen. Im Gegensatz zu Antiviren-Engines oder URL-Reputationsfiltern, die sich auf bekannte Bedrohungsmuster und Signaturen stützen, verfolgt die Browser-Isolation einen Zero-Trust-Ansatz – dabei werden alle Webinhalte unabhängig von ihrer Reputation als potenziell bösartig behandelt. Dieser Unterschied ist von Bedeutung, da herkömmliche Tools strukturell blind gegenüber Zero-Hour-Angriffen sind, also solchen Bedrohungen, für die es noch keine Signatur gibt.

Warum Remote Browser Isolation gerade jetzt Remote Browser Isolation

Der Browser ist längst nicht mehr nur ein Fenster zum Internet. Er ist der Arbeitsbereich im Unternehmen, in dem E-Mail, SaaS-Anwendungen, CRM-Systeme, Finanzplattformen und KI-Tools zusammenlaufen. Diese Konzentration sensibler Aktivitäten macht den Browser zu einem äußerst attraktiven Angriffsziel.

Fast die Hälfte der im Jahr 2024 untersuchten Sicherheitsvorfälle (44 %) betraf böswillige Aktivitäten, die über die Browser von Mitarbeitern ausgelöst oder ermöglicht wurden, darunter Phishing, Missbrauch von URL-Weiterleitungen und das Herunterladen von Malware (Unit 42 Global Incident Response Report 2025). Unterdessen zeigt der „2025 State of Browser Security Report“ von Menlo Security einen Anstieg der Phishing-Angriffe auf Browser um 140 % im vergangenen Jahr, wobei „Zero-Hour“-Phishing-Vorfälle – also Angriffe, die zu neu sind, um in einer Signaturdatenbank erfasst zu sein – um 130 % zugenommen haben.

Die finanziellen Auswirkungen sind gravierend. Laut dem „Cost of a Data Breach Report“ von IBM beliefen sich die weltweiten Durchschnittskosten einer Datenpanne im Jahr 2024 auf 4,88 Millionen US-Dollar. Es dauerte durchschnittlich 292 Tage, bis Angriffe mit gestohlenen Zugangsdaten erkannt und eingedämmt wurden. Viele dieser Ketten von Zugangsdatendiebstählen beginnen im Browser – ein Nutzer gelangt auf eine überzeugende Phishing-Seite, gibt seine Zugangsdaten ein, und der Angreifer befindet sich fast zehn Monate lang in der Umgebung, bevor der Angriff eingedämmt wird.

Betrachten wir ein konkretes Szenario: Ein Finanzanalyst bei einer mittelgroßen Bank erhält eine Browser-Benachrichtigung, die scheinbar aus dem Dokumentenmanagementsystem der Bank stammt. Der Link führt zu einem pixelgenauen Klon der Anmeldeseite, der auf einer legitimen Cloud-Plattform gehostet wird, um URL-Reputationsfilter zu umgehen. Ohne Browser-Isolation gibt der Analyst seine Anmeldedaten ein, und der Angreifer erlangt Zugriff auf interne Systeme. Mit RBI wird die Phishing-Seite innerhalb eines Cloud-Containers geladen; selbst wenn der Analyst versucht, Anmeldedaten einzugeben, kann die Sitzung so konfiguriert werden, dass die Eingabe von Anmeldedaten auf nicht kategorisierten Domains blockiert oder Formularübermittlungen vollständig unterbunden werden. Die Angriffskette wird bereits beim ersten Link unterbrochen.

NIST SP 800-46 Rev. 2 unterstreicht das Bedrohungsmodell, das RBI unverzichtbar macht: Das Dokument geht davon aus, dass Client-Geräte im Homeoffice mit Malware infiziert werden, und empfiehlt mehrschichtige Kontrollmaßnahmen, darunter Netzwerkzugangslösungen, die den Sicherheitsstatus des Clients überprüfen, bevor der Zugriff gewährt wird. RBI setzt diese Annahme in die Praxis um – indem es dem Endgerät von vornherein nicht zutraut, Webinhalte sicher zu verarbeiten.

So Remote Browser Isolation : Drei Rendering-Ansätze

Alle RBI-Lösungen basieren auf derselben Kernarchitektur: Webinhalte werden in einer entfernten, isolierten Umgebung (in der Regel einem kurzlebigen Cloud-Container) abgerufen und ausgeführt, und nur eine sichere Darstellung der Seite wird an den lokalen Browser des Nutzers übermittelt. Der entscheidende Unterschied liegt darin, wie diese sichere Darstellung erzeugt und übertragen wird. Es gibt drei Hauptansätze.

Pixel-Verarbeitung (Pixel-Streaming)

Bei diesem Ansatz werden Webinhalte auf einem Remote-Server gerendert und eine visuelle Darstellung der Webseite wird als interaktives Bild oder als Videostream an das Gerät des Nutzers gesendet. Stellen Sie sich dies wie einen Live-Videostream einer Browsersitzung vor, die auf dem Computer einer anderen Person läuft – das Gerät des Nutzers fungiert dabei als schlanker Display-Client.

Sicherheitsvorteil: Maximale Isolierung. Der ursprüngliche Webcode oder die Skripte gelangen zu keinem Zeitpunkt auf den Endpunkt. Alle potenziellen Angriffsvektoren, die im Code der Website eingebettet sind, bleiben auf dem Remote-Server isoliert.

Abwägung: Die kontinuierliche Kodierung und Übertragung von Videostreams ist bandbreitenintensiv und bei großem Umfang kostspielig. Selbst bei hoher Optimierung führt die unvermeidbare Latenz zu einer spürbar veränderten Benutzererfahrung. Auf Bildschirmen mit hoher DPI-Auflösung kann Text unscharf erscheinen; mobile Nutzer mit schwankender Verbindungsqualität müssen mit einer verminderten Bildqualität rechnen.

Am besten geeignet für: Hochsichere Umgebungen, in denen die Vertraulichkeit Vorrang vor der Benutzerfreundlichkeit hat – OSINT-Recherchen, privilegierter Administratorzugriff auf kritische Systeme oder das Surfen in geheimhaltungsrelevanten Umgebungen.

DOM-Spiegelung (DOM-Rekonstruktion)

Bei der DOM-Rekonstruktion werden Webseiten in einer isolierten Umgebung geladen, auf der Ebene des Document Object Model analysiert und neu geschrieben, um potenzielle Bedrohungen zu beseitigen. Sobald der Inhalt bereinigt ist, wird eine bereinigte Version an das Gerät des Nutzers gesendet, wo der Endpunkt-Browser sie mithilfe seiner eigenen Engine darstellt.

Sicherheitsvorteil: Leicht und schnell. Der Endpunkt profitiert von einem nahezu nativen Browsererlebnis, bei dem die GPU-Beschleunigung und das standardmäßige Scrollverhalten erhalten bleiben.

Kompromiss: Die zugrunde liegenden Technologien – HTML, CSS, Web-Schriftarten – stellen selbst Angriffsvektoren dar. Der Versuch, schädliche Inhalte durch Bereinigung zu entfernen, ist von Natur aus unvollkommen; neue Ausnutzungstechniken könnten durchschlüpfen. Komplexe dynamische Seiten können fehlerhaft werden oder falsch dargestellt werden.

Am besten geeignet für: Allgemeines Surfen in Unternehmen, bei dem Leistung und Benutzererlebnis im Vordergrund stehen und das Unternehmen zugunsten der Produktivität eine etwas geringere Isolationsgrenze in Kauf nimmt.

Network Vector Rendering (NVR)

NVR fängt Zeichnungsbefehle von der in Chromium und Firefox verwendeten Grafik-Engine ab, verschlüsselt diese und überträgt sie per Streaming an den lokalen Browser. Da NVR Vektor-Zeichnungsbefehle anstelle des eigentlichen Website-Codes überträgt, ist der Bandbreitenverbrauch geringer als beim „Pixel-Pushing“, während gleichzeitig eine starke Isolationsgrenze aufrechterhalten wird.

Sicherheitsvorteil: Es gelangt kein Website-Code auf den Endpunkt – ähnlich wie beim „Pixel Pushing“ –, doch der Bandbreitenverbrauch ist deutlich geringer, da Vektorzeichnungsbefehle weitaus kompakter sind als Pixel-Videobilder.

Kompromiss: Die Verbreitung von NVR ist geringer und hängt möglicherweise von der Unterstützung durch bestimmte Browser-Engines ab. Hinsichtlich der Sicherheits- und Leistungsmerkmale liegt NVR zwischen „Pixel Pushing“ und „DOM-Spiegelung“.

Am besten geeignet für: Unternehmen, die eine nahezu pixelgenaue Sicherheit ohne Bandbreitenaufwand benötigen – verteilte Belegschaften mit unterschiedlichen Netzwerkverbindungen.

Vollständige Isolierung vs. selektive Isolierung: Die Wahl des richtigen Modells

Die meisten Unternehmen müssen – und wollen – nicht jede Browsersitzung isolieren. Der Leistungsaufwand und die Rechenkosten einer vollständigen Isolierung lassen sich kaum rechtfertigen, wenn der Großteil des Datenverkehrs an bekannte, kategorisierte SaaS-Anwendungen gerichtet ist. Hier erweist sich die selektive Isolierung als sinnvolle Strategie.

Bei der vollständigen Isolierung wird der gesamte Webdatenverkehr über RBI geleitet. Jede Seite, jede Sitzung, jeder Nutzer. Dieser Ansatz ist für Segmente mit hohen Sicherheitsanforderungen sinnvoll: eine Regierungsbehörde, die mit vertraulichen Informationen umgeht, ein Finanzhandelsraum oder ein Forschungslabor im Gesundheitswesen, das auf externe Datenquellen zugreift. Die Sicherheitsgarantie ist absolut, doch dies gilt auch für die Kosten und die Auswirkungen auf die Latenz.

Bei der selektiven Isolierung wird RBI nur auf Datenverkehr angewendet, der einen festgelegten Risikoschwellenwert überschreitet. Zu den typischen Auslösern zählen:

Nicht kategorisierte oder neu registrierte Domains. Ein Auftragnehmer klickt auf einen Link zu einer Domain, die vor 48 Stunden registriert wurde. Die SWG stuft diese als nicht kategorisiert ein; RBI isoliert die Sitzung automatisch.

Kategorien risikobehafteter URLs. Websites, die als Filesharing-Dienste, private E-Mail-Dienste oder Werbenetzwerke eingestuft werden, werden isoliert, während der SaaS-Datenverkehr von Unternehmen ungehindert weiterfließt.

Eingebettete E-Mail-Links. Jede URL in eingehenden E-Mails – unabhängig von deren Reputation – wird über RBI geöffnet, wodurch der primäre Übertragungsweg für Phishing-Angriffe unschädlich gemacht wird.

Sensible Benutzergruppen. Führungskräfte sowie Mitarbeiter aus den Bereichen Finanzen und Personalwesen, die mit regulierten Daten umgehen, surfen standardmäßig in einer isolierten Umgebung; die übrigen Mitarbeiter nutzen diese Funktion nur für risikobehaftete Ziele.

Der zentrale Integrationspunkt ist das secure web gateway(SWG), das den Datenverkehr in Echtzeit klassifiziert und weiterleitet. Die SWG-Richtlinie legt fest, welche Sitzungen in das RBI gelangen und welche die Standardprüfung durchlaufen. Ist das SWG Teil einer umfassenderen SSE-Plattform, können bei Isolierungsentscheidungen CASB-Risikobewertungen, DLP-Klassifizierungen, Benutzeridentitäten, Gerätestatus sowie Bedrohungsinformationen in Echtzeit berücksichtigt werden – wodurch eine kontextbezogene Richtlinie entsteht, die Sicherheit und Produktivität in Einklang bringt.

Wie sich RBI in die Zero-Trust- und SSE-Architektur einfügt

Die Browserisolierung funktioniert nicht isoliert. Wird sie eigenständig eingesetzt, bekämpft sie zwar webbasierte Malware und Phishing, lässt jedoch Lücken in Bezug auf Datenexfiltration, SaaS-Shadow-IT und identitätsbasierte Angriffe offen. Der wahre Nutzen kommt erst zum Tragen, wenn die Browserisolierung (RBI) zusammen mit ergänzenden Kontrollmaßnahmen in eine Zero-Trust-Architektur integriert wird.

Das „Zero Trust Maturity Model v2.0“ (2023) der CISA ermöglicht eine Abkehr von traditionellen, auf den Perimeter ausgerichteten Ansätzen und versetzt Unternehmen in die Lage, Hosts zu isolieren, Verschlüsselung durchzusetzen, Aktivitäten zu segmentieren und Sicherheitskontrollen näher an Anwendungen und Daten zu implementieren. RBI orientiert sich direkt an diesen Grundsätzen: Es isoliert die Browserumgebung, erzwingt die Verschlüsselung zwischen dem Container und dem Endgerät und trennt risikobehaftete Webaktivitäten vom Unternehmensnetzwerk ab.

Der technische Leitfaden der Cloud Security Alliance aus dem Jahr 2026 zur Browsersicherheit geht noch einen Schritt weiter und positioniert den Browser als erstklassigen „Policy Enforcement Point“ (PEP) innerhalb einer umfassenden Zero-Trust-Architektur neu, die Zugriffskontrollen nach dem Prinzip der geringsten Berechtigungen, phishingresistente Multi-Faktor-Authentifizierung, Überprüfung des Gerätestatus, adaptive Sitzungssteuerung und remote browser isolation vereint. Die CSA empfiehlt ausdrücklich den Einsatz remote browser isolation privilegierte oder mit erhöhtem Risiko behaftete Sitzungen, um sowohl Kompromittierungen von Endgeräten als auch bösartige webbasierte Bedrohungen zu neutralisieren.

In praktischen SSE-Architekturen arbeitet RBI mit folgenden Komponenten zusammen:

SWG für URL-Filterung, Bedrohungsinformationen und Entscheidungen zur Datenverkehrsweiterleitung.

CASB zur Transparenz bei der Nutzung von genehmigten und nicht genehmigten SaaS-Diensten, mit der Möglichkeit, Sitzungen auf Schatten-IT-Dienste zu beschränken und gleichzeitig Upload- und Download-Vorgänge zu blockieren.

DLP dient dazu, Inhalte zu überprüfen, die über isolierte Sitzungen übertragen werden, und zu verhindern, dass sensible Daten beim risikobehafteten Surfen eingefügt, hochgeladen oder ausgedruckt werden.

ZTNA / Private Access Isolierung Private Access Sitzungen von nicht verwalteten Geräten, die auf interne Anwendungen zugreifen – ein Auftragnehmer greift über seinen privaten Laptop über eine isolierte Sitzung auf das Unternehmensintranet zu, in der die Funktionen „Kopieren“, „Einfügen“ und „Herunterladen“ deaktiviert sind.

Laut dem Gartner Magic Quadrant SSE aus dem Jahr 2024 werden bis 2026 85 % der Unternehmen, die ihre Web-, SaaS- und privaten Anwendungen absichern möchten, die erforderlichen Sicherheitsfunktionen über ein SSE-Angebot beziehen. RBI wird unter den erwarteten Funktionen einer ausgereiften SSE-Plattform aufgeführt, was unterstreicht, dass Isolierung für Unternehmen, die die Sicherheit ihrer Unternehmensbrowser ernst nehmen, nicht mehr optional ist.

Bewertung von RBI-Lösungen: Worauf Sicherheitsarchitekten besonderen Wert legen sollten

Nicht alle RBI-Implementierungen sind gleich. Konzentrieren Sie sich bei der Bewertung von Lösungen auf Kriterien, die sich unmittelbar auf die Sicherheitslage, die Komplexität des Betriebs und die Akzeptanz bei den Anwendern auswirken.

1. Rendering-Verfahren und Isolationsgrenze. Klären Sie, ob die Lösung auf Pixel-Pushing, DOM-Spiegelung, NVR oder einen hybriden Ansatz basiert. Fragen Sie den Anbieter, welche Inhalte – falls überhaupt – im Browser des Endgeräts ausgeführt werden. Eine DOM-Spiegelungslösung, die bereinigtes JavaScript an das Endgerät sendet, weist eine andere Angriffsfläche auf als eine Pixel-Pushing-Lösung, die ausschließlich Bildframes überträgt.

2. Benutzererfahrung und Latenz. Fordern Sie einen Proof-of-Concept in Ihrer tatsächlichen Netzwerkumgebung an. Lassen Sie die Benutzer ihre zehn am häufigsten genutzten SaaS-Anwendungen über die isolierte Sitzung laden und messen Sie die Ladezeiten der Seiten, die Flüssigkeit beim Scrollen, das Verhalten beim Kopieren und Einfügen sowie die Abläufe beim Hoch- und Herunterladen von Dateien. Sollte sich die Benutzererfahrung spürbar verschlechtern, wird die Akzeptanz bei den Benutzern scheitern – und die Benutzer werden Umgehungslösungen finden, die die Isolierung vollständig umgehen.

3. Integrationsgrad der SSE. Die Isolations-Engine sollte Richtlinien, Identitätskontext, DLP-Regeln und Bedrohungsinformationen mit SWG-, CASB- und ZTNA-Komponenten teilen. Wenn Sie RBI-Richtlinien in einer separaten Konsole mit einer separaten Regelsprache verwalten müssen, erwerben Sie ein Einzelprodukt und keine Plattformfunktion. Die SSE-Plattform Skyhigh Security integriert RBI mit SWG, CASB, DLP und ZTNA unter einer einzigen Richtlinien-Engine – ein Beispiel für den einheitlichen Ansatz, den Sicherheitsarchitekten fordern sollten.

4. Unterstützung nicht verwalteter Geräte. Einer der wertvollsten Anwendungsfälle für RBI ist die Ermöglichung eines sicheren Zugriffs über Geräte, die nicht unter der Kontrolle des Unternehmens stehen – beispielsweise Laptops von Auftragnehmern, Geräte von Partnern oder private Tablets. Die Lösung sollte eine clientlose (agentlose) Bereitstellung unterstützen, bei der sich Benutzer über einen Standardbrowser verbinden, ohne Agenten oder proprietäre Software installieren zu müssen.

5. Granularität der Datenkontrolle. Kann die Lösung das Kopieren und Einfügen, das Drucken, das Erstellen von Screenshots und das Herunterladen von Dateien auf der Grundlage einzelner Richtlinien deaktivieren? Für eine isolierte Sitzung, in der ein Auftragnehmer auf Salesforce zugreift, ist ein schreibgeschützter Zugriff erwünscht, bei dem das Kopieren und Einfügen blockiert ist und kein lokales Dateicaching stattfindet.

6. Skalierbarkeit und Cloud-Präsenz. Jede isolierte Sitzung beansprucht Rechenressourcen. Erkundigen Sie sich nach der Cloud-Infrastruktur des Anbieters, seiner geografischen Präsenz, den Obergrenzen für die Anzahl gleichzeitiger Sitzungen sowie danach, wie sich die Kosten entwickeln, wenn Sie weitere Nutzer hinzufügen oder den Anteil des isolierten Datenverkehrs erhöhen.

7. Kompatibilität mit bestehenden Browsern. Der erfolgreichste Einführungsweg besteht darin, die bestehenden Browser der Nutzer – Chrome, Edge, Firefox, Safari – beizubehalten, anstatt einen proprietären Browser als Ersatz vorzuschreiben. Wie der Vergleich zwischen Unternehmensbrowsern und RBI zeigt, ermöglichen es Ihnen integrierte SSE-Lösungen von RBI, die Browser zu sichern, die Ihre Mitarbeiter bereits nutzen, ohne eine störende Migration zu erzwingen.

Häufige Fehler bei der Einführung von RBI-Systemen

Alles bereits am ersten Tag isolieren. Eine vollständige Isolierung des gesamten Datenverkehrs klingt in einer Präsentationsdatei zwar sicher, führt jedoch zu Beschwerden über Leistungseinbußen, die das Vertrauen der Nutzer untergraben. Ein besserer Ansatz: Beginnen Sie mit Kategorien mit hohem Risiko – nicht kategorisierte Domains, in E-Mails eingebettete URLs und Sitzungen auf nicht verwalteten Geräten. Erweitern Sie den Umfang der Isolierung schrittweise, während Sie die Auswirkungen auf die Nutzer messen und Vertrauen aufbauen.

Einsatz von RBI als eigenständiges Produkt. RBI ohne SWG-Integration kann keine intelligenten Routing-Entscheidungen treffen. RBI ohne DLP kann nicht verhindern, dass ein Benutzer während einer isolierten Sitzung sensible Daten in ein Webformular eingibt. RBI ohne CASB hat keinen Einblick darin, ob es sich bei dem Ziel um einen zugelassenen Cloud-Speicher oder um ein persönliches Dateifreigabekonto handelt. Die Isolierung löst ein Problem – nämlich zu verhindern, dass schädliche Inhalte den Endpunkt erreichen –, doch für die Datensicherheit ist der vollständige SSE-Stack erforderlich.

Der Anwendungsfall „nicht verwaltete Geräte“ wird außer Acht gelassen. Viele Unternehmen erwerben RBI für verwaltete Endgeräte, vernachlässigen jedoch Auftragnehmer und externe Nutzer, die BYOD-Geräte verwenden. Diese Nutzer stellen einige der Sitzungen mit dem höchsten Risiko dar. NIST SP 800-46 Rev. 2 warnt ausdrücklich davor, dass alle Komponenten von Telearbeitstechnologien, einschließlich BYOD-Client-Geräten, gegen erwartete Bedrohungen gesichert werden sollten, die anhand von Bedrohungsmodellen identifiziert wurden. RBI ist eine der praktischsten Möglichkeiten, dies zu erreichen, ohne dass eine Registrierung im Gerätemanagement erforderlich ist.

Die Nichtberücksichtigung der Identität bei der Isolierung. Eine pauschale Isolierungsrichtlinie, die alle Benutzer gleich behandelt, verschwendet Ressourcen und führt bei Benutzern mit geringem Risiko zu Frustration. Verknüpfen Sie Isolierungsrichtlinien mit Identitätsgruppen, rollenbasierten Zugriffskontrollen und adaptiver Risikobewertung. Ein leitender Angestellter, der von einem verwalteten Gerät aus im Unternehmensnetzwerk surft, benötigt möglicherweise keine Isolierung; derselbe leitende Angestellte, der von einem Hotel-WLAN-Netzwerk aus auf einem privaten Tablet surft, sollte hingegen automatisch isoliert werden. Der „Unit 42 2025 Global Incident Response Report“ ergab, dass 70 % der Vorfälle drei oder mehr Angriffsvektoren umfassten – kontextbezogene Richtlinien, die Identität, Gerät und Ziel berücksichtigen, sind unerlässlich, um Angriffsketten mit mehreren Vektoren zu durchbrechen.