So bewerten Sie Sicherheitslösungen für Unternehmensbrowser

Die Browsersicherheit hat sich still und leise zur Entscheidung mit den höchsten Risiken auf Ihrer SSE-Roadmap entwickelt. Gartner prognostiziert, dass bis 2028 25 % der Unternehmen ihre bestehenden Lösungen für sicheren Fernzugriff und Endpunktsicherheit durch den Einsatz mindestens einer sicheren Unternehmensbrowser-Technologie ergänzen werden – doch die Mehrheit hat noch keine solche Technologie eingeführt. Diese Kluft zwischen Absicht und Umsetzung bedeutet, dass sich die meisten Sicherheitsteams irgendwo in der Mitte befinden: Sie sind sich bewusst, dass der Browser geschützt werden muss, sind sich jedoch unsicher, welchen Ansatz sie wählen sollen, und stehen unter dem Druck, eine Entscheidung zu treffen, bevor der nächste Sicherheitsvorfall sie dazu zwingt.

Dieser Leitfaden für Praktiker bietet Ihnen einen strukturierten Bewertungsrahmen, der das gesamte Spektrum der Sicherheitsansätze für Unternehmensbrowser abdeckt – proprietäre Ersatzbrowser, Browser-Erweiterungen, remote browser isolation (RBI) sowie in SSE integrierte Kontrollmechanismen abdeckt –, damit Sie einen fundierten Auswahlprozess durchführen können und nicht in einen von Anbietern gesteuerten Demo-Zyklus geraten.

Voraussetzungen: Was Sie vor der Bewertung bereitstellen sollten

Eine Sicherheitsbewertung des Browsers ohne vorherige Voraussetzungen durchzuführen, ist so, als würde man eine Firewall kaufen, ohne die Topologie des eigenen Netzwerks zu kennen. Bevor Sie auch nur einen einzigen Anbieter in die engere Wahl ziehen, sollten Sie diese vier Schritte durchführen.

1. Erstellen Sie eine Bestandsaufnahme Ihrer Browser-Landschaft. Ermitteln Sie, welche Browser Ihre Mitarbeiter tatsächlich nutzen – nicht welche die IT-Abteilung bereitstellt. Laut Gartner (2025) machen Chromium-basierte Browser etwa 75 % des gesamten Browser-Marktanteils aus; daher muss Ihre Lösung mit Chrome, Edge und wahrscheinlich auch mit Varianten wie Brave oder Arc kompatibel sein. Wenn Ihre Belegschaft Abteilungen umfasst, in denen überwiegend Macs mit Safari zum Einsatz kommen, ist dies eine zwingende Kompatibilitätsanforderung und kein bloßes „Nice-to-have“.

2. Erstellen Sie eine Übersicht über Ihr SaaS- und privates Anwendungsportfolio. Ermitteln Sie, welche Anwendungen ausschließlich im Browser laufen und welche Thick-Client-Komponenten beinhalten. Ein Mitarbeiter des Marketingteams, der auf Salesforce zugreift, Kundenlisten auf eine Kampagnenplattform hochlädt und gelegentlich Segmente in ein GenAI-Schreibtool einfügt, weist ein grundlegend anderes Risikoprofil auf als ein Entwickler, der über ZTNA auf interne Code-Repositories zugreift.

3. Erstellen Sie eine Bestandsaufnahme Ihrer bestehenden Sicherheitsinfrastruktur. Dokumentieren Sie Ihre derzeitigen SWG-, CASB-, DLP-, ZTNA- und Endpunktüberwachungstools. Das SSE-Bewertungsrahmenwerk von Forrester (1. Quartal 2024) identifiziert drei primäre Sicherheitstechnologien – ZTNA, CASB und SWG – sowie mehrere sekundäre Technologien, darunter RBI und DLP. Ihre Browser-Sicherheitslösung muss sich in diese Kontrollmechanismen integrieren – und darf diese nicht duplizieren.

4. Ermitteln Sie das Risiko durch nicht verwaltete Geräte. Auftragnehmer, die mit privaten Laptops auf Ihre Workday-Instanz zugreifen, oder externe Prüfer, die von Business-Centern in Hotels aus auf SharePoint zugreifen, stellen Ihr größtes Browser-Risiko dar. Ermitteln Sie, wie viele Benutzer in die Kategorien „verwaltete“, „teilweise verwaltete“ und „vollständig nicht verwaltete“ Geräte fallen – dies bestimmt unmittelbar, welche Ansätze realisierbar sind.

Phase 1: Legen Sie Ihre Bewertungskriterien und Bedrohungsszenarien fest

Eine Bewertung, die mit Anbietervorführungen beginnt, endet damit, dass der lauteste Verkäufer den Zuschlag erhält. Beginnen Sie stattdessen mit Bedrohungsszenarien, die Ihr tatsächliches Risiko widerspiegeln.

Erstellen Sie eine Szenariobibliothek

Erstellen Sie fünf bis acht Szenarien, die Ihre am häufigsten auftretenden und mit den größten Auswirkungen verbundenen browserbasierten Risiken darstellen. Praktische Beispiele:

SaaS-Zugriff durch Auftragnehmer: Ein externer Berater greift von einem nicht verwalteten Gerät aus auf Ihr CRM zu, ruft personenbezogene Daten von Kunden ab und versucht, eine Kontaktliste auf ein privates Laufwerk herunterzuladen.

Datenleck bei KI-Tools: Ein Produktmanager kopiert ein Dokument zur Wettbewerbsanalyse aus SharePoint, fügt es in ein nicht genehmigtes GenAI-Tool ein, und die Antwort des Tools enthält vertrauliche Umsatzdaten.

Phishing innerhalb einer Browsersitzung: Ein Finanzanalyst klickt auf einen Link in einer Teams-Nachricht, wodurch eine Seite zum Abgreifen von Anmeldedaten geöffnet wird, die so gestaltet ist, dass sie Ihren SSO-Anbieter imitiert – und zwar innerhalb einer aktiven, authentifizierten Sitzung.

Exfiltration durch Kopieren und Einfügen: Ein ausscheidender Mitarbeiter öffnet Salesforce in einem Tab und einen persönlichen Gmail-Entwurf in einem anderen Tab und kopiert anschließend Pipeline-Daten zwischen den Tabs hin und her.

Diese Szenarien bilden die Grundlage für Ihre POC-Testskripte. Jeder Anbieter, der keine aussagekräftigen Kontrollmaßnahmen für Ihre fünf wichtigsten Szenarien nachweisen kann, wird ausgeschlossen, unabhängig von seiner Platzierung im Analysten-Quadranten.

Passen Sie sich an Ihre Zero-Trust-Architektur an

Das „Zero Trust Maturity Model v2.0“ (2023) der CISA gliedert das Zero-Trust-Konzept in fünf Säulen – Identität, Geräte, Netzwerke, Anwendungen und Workloads sowie Daten – und bietet Organisationen damit einen Fahrplan für die kontinuierliche Modernisierung. Die Bewertung der Browsersicherheit sollte sich direkt auf mindestens drei dieser Säulen beziehen: Geräte (erkennt die Browsersitzung das jeweilige Gerät?), Anwendungen (können Sie auf Browserebene Richtlinien pro Anwendung durchsetzen?) und Daten (kann die Lösung Daten, die innerhalb des Browsers übertragen werden, überprüfen und kontrollieren?).

Phase 2: Bewertung der vier Sicherheitsansätze der Browser

Nicht jede Organisation benötigt denselben Ansatz. Der Markt bietet derzeit vier unterschiedliche Architekturmodelle an, die jeweils mit erheblichen Kompromissen verbunden sind.

Hersteller-eigene Ersatzbrowser

Ein maßgeschneiderter Full-Stack-Browser ersetzt Chrome, Edge oder Firefox durch eine vom Anbieter kontrollierte Chromium-Abzweigung, in die DLP-, Identitäts- und Richtliniendurchsetzungsfunktionen auf Ebene der Rendering-Engine integriert sind. Gartner definiert einen sicheren Unternehmensbrowser als eine Lösung, die Unternehmenssicherheitsrichtlinien und -kontrollen über eine zentral verwaltete Browsererweiterung und optional über einen maßgeschneiderten Full-Stack-Webbrowser bereitstellt und so Sicherheit sowie die Durchsetzung von Richtlinien für Web-, SaaS- und private Anwendungen gewährleistet.

Die Sicherheit ist hoch – Sie kontrollieren die gesamte Rendering-Pipeline. Doch der Aufwand für die Bereitstellung ist ebenso hoch. Sie verlangen von Tausenden von Nutzern, den Browser aufzugeben, den sie seit Jahren verwenden, ihre Gewohnheiten neu zu erlernen und zu akzeptieren, dass ihre Lesezeichen, Erweiterungen und gespeicherten Passwörter möglicherweise nicht reibungslos migriert werden können. Das Beschaffungsteam stellt fest, dass dies bedeutet, dass die IT-Abteilung nun für einen neuen Software-Lebenszyklus verantwortlich ist – Browser-Patches, Kompatibilitätstests, Versionsmanagement –, der zuvor in der Zuständigkeit von Google oder Microsoft lag.

Browser-Erweiterungen

Ein schlanker Agent wird im bestehenden Browser des Benutzers installiert, überwacht die Aktivitäten auf den Seiten, steuert die Vorgänge in der Zwischenablage und setzt DLP-Richtlinien durch, ohne den Browser selbst zu ersetzen. Durch Erweiterungen bleibt die Benutzerumgebung vertraut, und der mit der Umstellung auf einen anderen Browser verbundene Aufwand entfällt. Allerdings ist die auf Erweiterungen basierende Sicherheit von den APIs der Browserhersteller abhängig, die sich mit jedem Browser-Update ändern können – und einige kritische Vorgänge (wie die tiefgreifende Überprüfung der JavaScript-Engine) können architektonisch eingeschränkt sein.

Remote browser isolation RBI)

RBI führt Webinhalte in einem cloudbasierten Container aus und überträgt ausschließlich sichere visuelle Ausgaben an den lokalen Browser des Benutzers. Der „Capacity Enhancement Guide“ (2023) der CISA empfiehlt die Kombination aus Browserisolierung, Webinhaltsfilterung, DLP und sicheren Gateways als mehrschichtigen Schutz. Das Sicherheitsmodell ist architektonisch robust – auf dem Endgerät wird kein Webcode ausgeführt. Bei der Integration in eine SSE-Plattform fungiert RBI als abgestufte Richtlinienreaktion: Bekanntlich sichere Ziele werden durchgelassen, bekanntlich schädliche Ziele werden blockiert und riskante oder nicht kategorisierte Websites werden isoliert.

In SSE integrierte Browser-Steuerelemente

Anstatt die Browsersicherheit als eigenständiges Produkt zu betrachten, vereint dieser Ansatz SWG-URL-Filterung, CASB-Inline-Richtlinien, DLP-Inhaltsprüfung und selektives RBI über ein einheitliches secure web gateway. Der Browser selbst bleibt unverändert – die Sicherheit wird auf Netzwerk- und Proxy-Ebene durchgesetzt, wobei bei entsprechendem Risiko eine richtlinienbasierte Eskalation in die Isolierung erfolgt. Dieser Ansatz entspricht am ehesten der Art und Weise, wie Sicherheitsarchitekturen in Unternehmen bereits funktionieren.

Phase 3: Bewertung der Anbieter anhand von acht gewichteten Kriterien

Verwenden Sie den folgenden Bewertungsrahmen, um jede in die engere Wahl gegangene Lösung zu bewerten. Gewichten Sie jedes Kriterium entsprechend den Prioritäten Ihrer Organisation – eine Organisation mit einem großen Anteil an externen Mitarbeitern wird den Support für nicht verwaltete Geräte anders gewichten als eine Organisation, in der überwiegend verwaltete Endgeräte zum Einsatz kommen.

Bewertungsrahmen für Lieferanten

Bewerten Sie jedes Kriterium auf einer Skala von 1 bis 5 (1 = erfüllt die Anforderung nicht, 5 = übertrifft die Anforderung). Multiplizieren Sie die Punktzahl mit der Gewichtung, um eine gewichtete Gesamtpunktzahl zu erhalten. Jede Lösung, die bei „Sicherheitstiefe“ oder „SSE-Integration“ die Note 1 erhält, sollte unabhängig von der Gesamtpunktzahl ausgeschlossen werden.

Phase 4: Führen Sie einen Proof-of-Concept durch, der tatsächlich etwas belegt

Die meisten POCs scheitern, weil dabei die falschen Aspekte getestet werden. Eine 30-minütige Anbieter-Demo auf einer leeren virtuellen Maschine mit zwei Testnutzern gibt Ihnen keinerlei Aufschluss darüber, wie sich die Lösung verhält, wenn an einem Montagmorgen Hunderte von echten Nutzern darauf zugreifen.

POC-Entwurfsprinzipien

Beziehen Sie echte Nutzer ein, nicht das Sicherheitsteam. Wählen Sie 50 bis 100 Nutzer aus mindestens drei Abteilungen aus – Finanzen, Technik und einem Geschäftsbereich mit intensiver SaaS-Nutzung. Nutzer, die sich nicht für das Tool entschieden haben, werden Probleme aufzeigen, die den Befürwortern des Anbieters entgehen würden.

Testen Sie Ihren tatsächlichen SaaS-Stack. Führen Sie den POC an Ihrer produktiven Salesforce-Instanz, Ihrer Workday-Umgebung und Ihren internen Anwendungen durch. Der „M-Trends 2025“-Bericht von Mandiant ergab, dass Exploits 33 % der Erstinfektionen ausmachten, während gestohlene Anmeldedaten auf 16 % stiegen – der zweithäufigste Angriffsvektor. Das bedeutet, dass Ihre Browsersicherheit nicht nur Malware-Downloads, sondern auch Szenarien wie den Diebstahl von Anmeldedaten und das Hijacking von Sitzungen abdecken muss.

Bewerten Sie sowohl die Sicherheit als auch die Benutzerfreundlichkeit. Verfolgen Sie drei Kategorien von Kennzahlen:

Sicherheitskennzahlen: Abgewehrte Phishing-Versuche, Auslösungen von DLP-Richtlinien, isolierte Sitzungen, verhinderte Malware

Metriken zur Benutzerfreundlichkeit: Durchschnittliche Differenz bei der Seitenladezeit (im Vergleich zum Ausgangswert), Bearbeitungszeit für fünf Standard-Workflows, Anzahl der Helpdesk-Tickets

Nutzungskennzahlen: Aktive Nutzer im Vergleich zu registrierten Nutzern, Umgehungsversuche, Nutzerzufriedenheitswert (einfache Umfrage auf einer Skala von 1 bis 5)

Eine Lösung, die zwar jede Bedrohung blockiert, aber das Laden jeder Seite um drei Sekunden verzögert, wird eine Revolte der Nutzer hervorrufen, die sie aus betrieblicher Sicht wertlos macht. Umgekehrt ist eine reibungslose Lösung, die Datenabflüsse per Kopieren/Einfügen übersieht, bloßes Sicherheits-Theater.

Dauer und Umfang des POC

Führen Sie den POC mindestens drei Wochen lang durch. In der ersten Woche werden anfängliche Schwierigkeiten bei der Bereitstellung und die Einarbeitung der Benutzer abgedeckt. In der zweiten Woche zeigt sich die Leistung im Dauerbetrieb. In der dritten Woche werden Randfälle erfasst – der vierteljährliche Berichtszyklus, der ungewöhnliche Datenmengen erzeugt, der Auftragnehmer, der vorübergehend Zugriff auf eine eingeschränkte Anwendung benötigt, sowie der Benutzer, der versucht, geschützte Daten in ein GenAI-Tool einzufügen.

Phase 5: Bewertung der SSE-Integration und der Vereinheitlichung der Richtlinien

Genau hier liegt der Fehler bei den meisten Sicherheitsbewertungen von Browsern. Die Teams bewerten die Browsersicherheit isoliert und stellen dann bei der Bereitstellung fest, dass dadurch ein paralleles Richtlinienuniversum entsteht, das von ihren SWG-, CASB- und DLP-Kontrollen abgekoppelt ist.

Ein Praxistest: Konfigurieren Sie eine DLP-Richtlinie, die das Hochladen von Sozialversicherungsnummern in nicht genehmigte Cloud-Speicher verhindert. Überprüfen Sie anschließend, ob dieselbe Richtlinie auch dann ausgelöst wird, wenn ein Benutzer diese Nummern in einer isolierten Browsersitzung in eine GenAI-Eingabeaufforderung eingibt, sie zwischen Browser-Registerkarten kopiert oder versucht, eine Seite mit diesen Nummern auszudrucken. Wenn für jede dieser Aktionen eine separate Richtlinie in einer separaten Konsole erforderlich ist, verursacht Ihre Browsersicherheit operative Schulden, anstatt diese zu reduzieren.

Die SSE-Bewertung von Forrester (1. Quartal 2024) ergab, dass die Datenlokalisierung nach wie vor ein entscheidendes Anliegen ist, insbesondere außerhalb der USA, und dass einige Anbieter besser in der Lage sind als andere, Daten in einem bestimmten Land zu belassen. Überprüfen Sie im Rahmen Ihrer Bewertung, wo Browser-Isolationssitzungen verarbeitet werden, wo Überwachungsprotokolle gespeichert werden und ob Sie die Weiterleitung von Sitzungen in bestimmte Regionen steuern können – insbesondere, wenn Sie den Anforderungen der DSGVO, des CCPA oder branchenspezifischen Vorschriften zur Datenhoheit unterliegen.

Die Bedrohungslage erfordert diesen Grad an Integration. Der CSA-Bericht „State of SaaS Security Report“ (2025) ergab, dass 56 % der Unternehmen angeben, dass Mitarbeiter sensible Daten in nicht autorisierte SaaS-Anwendungen hochladen. Browsersicherheit, die keinen Kontext mit Ihrem CASB und DLP austauscht, kann diese Risiken nicht in Echtzeit bewältigen. Die SSE-Plattform Skyhigh Security vereint beispielsweise SWG-, CASB-, DLP- und RBI-Richtlinien in einer einzigen Konsole – und beseitigt damit das Problem doppelter Richtlinien, unter dem eigenständige Browsersicherheitsprodukte leiden.

Häufige Fehler, die die Bewertung der Browsersicherheit beeinträchtigen

Fehler 1: Bewertung der Sicherheitstiefe ohne Prüfung der Benutzererfahrung. Ein CISO wählt anhand einer Checkliste mit Sicherheitsfunktionen einen Ersatzbrowser aus, stellt diesen für Tausende von Benutzern bereit und stellt fest, dass drei wichtige SaaS-Anwendungen nicht korrekt dargestellt werden. Innerhalb von zwei Wochen breiten sich „Shadow-IT“-Workarounds aus – Benutzer wechseln zu privaten Browsern, greifen von privaten Geräten auf Unternehmensanwendungen zu, und die Sicherheitslage verschlechtert sich tatsächlich.

Fehler 2: Die Sicherheit von Browsern als eigenständige Anschaffung zu betrachten. Ein Beschaffungsteam erwirbt eine Browser-Sicherheitslösung von einem Anbieter außerhalb seines SSE-Stacks und verbringt anschließend sechs Monate damit, diese in bestehende SWG- und CASB-Richtlinien zu integrieren. Das Ergebnis sind zwei Richtlinienkonsolen, doppelte DLP-Regeln mit leicht abweichender Logik sowie eine Alarmmüdigkeit aufgrund widersprüchlicher Telemetriedaten. Die Bewertungsrichtlinien von Gartner (Oktober 2025) empfehlen ausdrücklich, zu erfragen, wie sich Lösungen in Ihren SIEM-, SOAR-, SSE- und EDR-Stack integrieren lassen – und nicht, ob dies theoretisch möglich ist.

Fehler 3: Den Anwendungsfall „nicht verwaltete Geräte“ außer Acht lassen. Teams bewerten die Browsersicherheit auf verwalteten Firmenlaptops und stellen dann nach der Bereitstellung fest, dass ein erheblicher Teil ihres Browserrisikos von Auftragnehmern und BYOD-Nutzern ausgeht, die keinen Agenten oder kein MDM-Profil installieren können. Lösungen, die eine Endpunktkontrolle erfordern – wie beispielsweise einige Ersatzbrowser, die eine Installation durch einen lokalen Administrator erfordern –, versagen stillschweigend bei den Nutzern, die den Schutz am dringendsten benötigen.

Fehler 4: Die Analyse des Kostenmodells auslassen. Die Kosten für RBI steigen mit dem Nutzungsvolumen – die Isolierung jeder einzelnen Websitzung für jeden Nutzer ist kostspielig. Eine selektive Isolierung (nur risikobehaftete und nicht kategorisierte Websites) senkt die Kosten erheblich, ohne die Sicherheitslage zu beeinträchtigen. Prüfen Sie, ob die Preisgestaltung des Anbieters eine gezielte Isolierung belohnt oder benachteiligt.

Fehler 5: Durchführung eines zweitägigen POC mit fünf Mitgliedern des Sicherheitsteams. Dies zeigt Ihnen lediglich, dass das Produkt für technische Anwender in einer kontrollierten Umgebung funktioniert. Es sagt jedoch nichts darüber aus, wie eine Mitarbeiterin der Kreditorenbuchhaltung in der Niederlassung in Houston reagieren wird, wenn ihre Browsersitzung während der Isolierung unterbrochen wird oder wenn ihre bevorzugte Chrome-Erweiterung nicht mehr funktioniert. Führen Sie einen echten POC mit echten Anwendern über einen Zeitraum von mindestens drei Wochen durch.

Kennzahlen und Erfolgskriterien für Ihre endgültige Entscheidung

Nutzen Sie nach dem POC diese Vergleichswerte, um der Unternehmensleitung eine fundierte Empfehlung zu unterbreiten:

Die Abweichung bei der Seitenladezeit liegt im akzeptablen Bereich. Sollten die durchschnittlichen Ladezeiten der Seiten gegenüber dem Referenzwert (gemessen anhand Ihrer 20 meistgenutzten Anwendungen) erheblich ansteigen, ist mit Beschwerden von Nutzern zu rechnen, die die Akzeptanz beeinträchtigen werden. Verfolgen Sie die genaue Abweichung in Millisekunden pro Anwendung.

Der DLP-Schutzumfang sollte mindestens dem Ihrer bestehenden Lösung entsprechen oder diesen übertreffen. Die Browser-Sicherheitslösung sollte DLP-Verstöße erkennen, die auch Ihre bestehende Inline-DLP-Lösung erfasst, und darüber hinaus Schutz vor browserspezifischen Angriffsvektoren (Zwischenablage, Drucken, Bildschirmaufnahmen) bieten.

Benutzerzufriedenheit von mindestens 3,5 auf einer 5-Punkte-Skala. Unterhalb dieses Schwellenwerts ist mit Eskalationen, Umgehungsversuchen und Ausnahmegenehmigungen durch Führungskräfte zu rechnen, die den Sicherheitsnutzen untergraben.

Das Helpdesk-Ticketvolumen liegt in einem überschaubaren Rahmen. Ein starker Anstieg deutet auf Probleme bei der Einführung hin, die sich nicht von selbst lösen werden. Verfolgen Sie die Anzahl der Tickets pro 100 registrierte Nutzer pro Woche.

Die durchschnittliche Zeit bis zur Änderung einer Richtlinie beträgt weniger als vier Stunden. Sollte die Aktualisierung einer browserspezifischen DLP-Regel länger dauern als die Aktualisierung Ihrer SWG-Regel, ist die Integration unzureichend.

Keine kritischen Anwendungsausfälle. Jede Anwendung in Ihren Top 20, die nicht korrekt dargestellt wird oder die Funktionstests nicht besteht, stellt ein Hindernis für die Bereitstellung dar und ist kein „bekanntes Problem“.

Der Bericht „M-Trends 2026“ von Mandiant ergab, dass die Medianzeit zwischen der ersten Kompromittierung und der Übergabe an eine zweite Angreifergruppe im Jahr 2025 auf nur noch 22 Sekunden gesunken ist – gegenüber über acht Stunden im Jahr 2022. Ihre Browsersicherheit muss mit „Wire Speed“ arbeiten – das heißt, Bedrohungen müssen bereits während der Browsersitzung erkannt und blockiert werden, bevor ein Angreifer von kompromittierten Anmeldedaten ausgehend eine laterale Bewegung einleitet.

Wenn Sie die Rolle der Browserisolierung in Ihrer übergeordneten Sicherheitsarchitektur verstehen, können Sie diese Kennzahlen besser einordnen. Die Isolierung ist keine eigenständige Abwehrmaßnahme – sie ist vielmehr eine richtliniengesteuerte Eskalationsstufe innerhalb eines mehrschichtigen Sicherheitsmodells.