Was ist ein Unternehmensbrowser und warum ist sicheres Surfen für moderne Unternehmen wichtig?
- Ein Unternehmensbrowser ist eine Sicherheitsebene und nicht nur eine Browseranwendung.
- Die Einführung befindet sich noch in den Anfängen, schreitet jedoch zusehends voran. Gartner prognostiziert, dass bis zum Jahr 2028 25 % der Unternehmen ihre bestehenden sicheren Fernzugriffslösungen erweitern werden.
- Der Browser ist die wichtigste Angriffsfläche für den Diebstahl von Zugangsdaten und Phishing.
- Sie müssen den Browser nicht unbedingt austauschen – Sie müssen die Sitzung sichern.
- Die Einführung neuer Unternehmensbrowser ist mit erheblichen Hindernissen verbunden.
- Die Sicherheit von Browsern ist ein wesentlicher Bestandteil des Zero-Trust-Ansatzes. Das Zero-Trust-Reifegradmodell v2 der CISA.
- Die Kosten der Untätigkeit sind messbar. Die weltweiten Durchschnittskosten einer Datenpanne beliefen sich auf 4 US-Dollar.
Der Webbrowser hat sich still und leise zur folgenreichsten – und am wenigsten geschützten – Anwendung im Unternehmen entwickelt. Jede SaaS-Anmeldung, jede KI-Abfrage, jeder Datei-Upload und -Download, jeder Auftragnehmer, der auf ein internes Portal zugreift: All dies geschieht innerhalb eines Browser-Tabs. Gartner stellt fest, dass sichere Unternehmensbrowser „Unternehmenssicherheitskontrollen mithilfe eines maßgeschneiderten Browsers oder einer Erweiterung für bestehende Browser in das native Webbrowser-Erlebnis integrieren, anstatt zusätzliche Kontrollen auf Endgeräte- oder Netzwerkebene anzubringen.“ Dennoch behandeln die meisten Unternehmen den Browser nach wie vor als Standardprodukt und verlassen sich auf Chrome oder Edge in der Verbraucherausführung, ohne dass auf Sitzungsebene Richtlinien durchgesetzt werden. Diese Lücke ist heute der mit Abstand größte blinde Fleck in der Sicherheitsarchitektur von Unternehmen.
Was ist ein Unternehmensbrowser?
Ein Unternehmensbrowser ist eine Sicherheitsmaßnahme auf Browserebene, die darauf ausgelegt ist, unternehmensinterne Richtlinien –data loss prevention, Zugriffskontrollen, Bedrohungsüberprüfung und Sitzungsverwaltung – genau dort durchzusetzen, wo Benutzer mit Webanwendungen, SaaS-Plattformen und dem offenen Internet interagieren.
Gartner definiert ein SEB als eine Lösung, die Sicherheitsrichtlinien und -kontrollen für Unternehmen über eine zentral verwaltete Browsererweiterung und optional über einen maßgeschneiderten Full-Stack-Webbrowser bereitstellt. SEBs gewährleisten die Sicherheit und die Durchsetzung von Richtlinien für Web-, SaaS- und private Anwendungen sowie eine Browser-Absicherung, die über den Browser selbst und nicht auf der Ebene des Endpunkt-Betriebssystems oder des Netzwerks erfolgt. Darüber hinaus ermöglichen sie Transparenz, Kontrolle und Nachvollziehbarkeit der Daten von Webanwendungen, auf die Endbenutzer von verwalteten, leicht verwalteten oder nicht verwalteten Geräten zugreifen, ohne dass eine Inline-Entschlüsselung des Webdatenverkehrs erforderlich ist.
In der Praxis umfasst die Kategorie der Unternehmensbrowser zwei grundlegend unterschiedliche Ansätze:
Vollständiger Browser-Ersatz: Eine auf Chromium basierende Anwendung, die Chrome oder Edge vollständig ersetzt – Beispiele hierfür sind der Island Enterprise Browser und der Prisma Access Browser von Palo Alto Networks. Diese integrieren DLP, Identitätsmanagement und Sitzungssteuerung direkt in einen proprietären Browser.
Den bestehenden Browser-Ansatz sichern: Browser-Erweiterungen, remote browser isolation, SWG-Prüfung sowie CASB-Richtlinien, die auf die Browser angewendet werden, die die Mitarbeiter bereits nutzen. Dieser Ansatz vermeidet die vollständige Abschaffung von Chrome und gewährleistet dennoch die Durchsetzung von Datenkontrollen, die Blockierung bösartiger Inhalte sowie die Isolierung risikobehafteter Sitzungen.
Betrachten wir ein konkretes Beispiel: Ein Schadensregulierer bei einer Versicherungsgesellschaft nutzt Chrome, um auf Salesforce, ein internes Underwriting-Portal und gelegentlich auf einen generativen KI-Assistenten zur Zusammenfassung von Fallnotizen zuzugreifen. Bei einem „Ersatzmodell“ würde die IT-Abteilung den Sachbearbeiter auffordern, auf einen proprietären Browser umzusteigen, Lesezeichen und Erweiterungen neu zu lernen und in Kauf zu nehmen, dass einige interne Webanwendungen möglicherweise anders dargestellt werden. Bei einem Modell zur Sicherung des bestehenden Browsers legt die IT-Abteilung RBI über risikobehaftete oder nicht kategorisierte URLs, wendet DLP an, um zu verhindern, dass personenbezogene Daten in das KI-Tool eingefügt werden, und nutzt ein SWG, um bösartige Downloads zu blockieren – und das alles, ohne den täglichen Arbeitsablauf des Sachbearbeiters zu verändern.
Warum sicheres Surfen gerade jetzt so wichtig ist
Drei Faktoren haben dazu geführt, dass die Browsersicherheit mittlerweile eine betriebliche Notwendigkeit und nicht mehr nur ein nettes Extra ist.
1. Der Browser ist die neue Perimetergrenze. In Gartners „Innovation Insight“ vom April 2025 wird darauf hingewiesen, dass Webbrowser für die meisten modernen Unternehmensanwendungen die primäre Zugriffsmethode darstellen und einen endgeräteunabhängigen Kontrollpunkt für die Unternehmenssicherheit bieten. Wenn sich ein Außendienstmitarbeiter über das WLAN eines Hotels beim CRM anmeldet, ist der Browser das Einzige, was zwischen dieser Sitzung und einem Proxy zum Abgreifen von Anmeldedaten steht. Herkömmliche Firewalls und VPN-Konzentratoren nehmen von dieser Sitzung überhaupt keine Kenntnis.
2. Browserbasierte Angriffe nehmen stark zu. Der „Menlo Security 2025 State of Browser Security Report“ ergab, dass Zero-Hour-Phishing-Angriffe im Vergleich zum Vorjahr um 130 % zugenommen haben. Jeder fünfte browserbasierte Angriff im Jahr 2024 nutzte Ausweichtechniken, die darauf abzielten, herkömmliche netzwerk- und endpunktbasierte Sicherheitskontrollen zu umgehen. Dabei handelt es sich nicht um einfache Probleme der URL-Blockierung. Angreifer nutzen legitime SaaS-Domains, „Browser-im-Browser“-Overlays und KI-generierte Phishing-Köder, die von herkömmlichen Web-Gateways nur schwer erkannt werden können.
3. Der Diebstahl von Anmeldedaten beginnt im Browser. Der Verizon DBIR 2025 berichtet, dass 88 % der einfachen Angriffe auf Webanwendungen mit gestohlenen Anmeldedaten durchgeführt wurden. Eine Marketingmanagerin speichert ihr Salesforce-Passwort in der Autovervollständigungsfunktion von Chrome. Ein Infostealer auf einem privaten Gerät, das sie auch für berufliche Zwecke nutzt, kopiert alle gespeicherten Zugangsdaten und bietet sie auf einem Dark-Web-Marktplatz zum Verkauf an. Sechs Wochen später verschafft sich ein Angreifer mit einem gültigen Sitzungstoken Zugang zum CRM. Es wird kein Alarm ausgelöst, bis die Datenexfiltration bereits abgeschlossen ist.
Der IBM-Bericht „Cost of a Data Breach Report 2024“ ergab, dass es bei Sicherheitsverletzungen, bei denen Anmeldedaten gestohlen wurden, durchschnittlich 292 Tage dauerte, bis diese erkannt und eingedämmt wurden – länger als bei jedem anderen Angriffsvektor. Das entspricht einer Verweildauer von fast zehn Monaten. Maßnahmen auf Browserebene, die anomales Sitzungsverhalten erkennen, eine phishingresistente Authentifizierung durchsetzen und das Zwischenspeichern von Anmeldedaten auf nicht verwalteten Geräten verhindern, verkürzen diesen Zeitraum von Monaten auf Minuten.
So funktioniert die Browser-Sicherheit in Unternehmen
Die Browsersicherheit in Unternehmen erstreckt sich über vier funktionale Ebenen. Wenn Sie diese verstehen, können Sie die Ansätze der Anbieter besser bewerten und leere Marketingversprechen erkennen.
Ebene 1: Isolierung und Überprüfung von Bedrohungen
Remote browser isolation Webinhalte in einer Cloud-Sandbox Remote browser isolation , und es werden ausschließlich sichere Pixel (oder bereinigte DOM-Elemente) an den Endpunkt des Benutzers gestreamt. Ein Finanzanalyst klickt auf einen Link in einer E-Mail, der zu einer bisher unbekannten Domain führt. Dank RBI wird die Seite in einem isolierten Container ausgeführt. Selbst wenn sie einen Drive-by-Exploit oder einen Credential Harvester enthält, gelangt der Schadcode niemals auf den Rechner des Analysten. Der Nutzer sieht eine normal aussehende Seite; die Sicherheitsabteilung erkennt eine eingedämmte Bedrohung.
Ein secure web gateway ist vorgelagert, überprüft den TLS-entschlüsselten Datenverkehr, setzt Richtlinien zur URL-Kategorisierung durch und blockiert bekannte schädliche Ziele, noch bevor der Browser die Seite überhaupt anfordert. Gemeinsam schließen RBI und SWG sowohl die Lücken bei bekannten Bedrohungen als auch bei Zero-Hour-Bedrohungen.
Ebene 2: Data loss prevention Sitzungsebene
DLP auf der Browserebene fängt Kopier-/Einfügevorgänge, Datei-Uploads, Datei-Downloads und Druckvorgänge innerhalb der Browsersitzung selbst ab. Stellen Sie sich einen Vertrags-Personalvermittler vor, der über eine verwaltete Browsersitzung Zugriff auf Ihr HRIS hat. Der Personalvermittler kann zwar Bewerberdaten einsehen, aber weder eine CSV-Datei herunterladen, noch Sozialversicherungsnummern in einen privaten E-Mail-Tab einfügen, noch einen Screenshot der Seite erstellen – denn die DLP-Richtlinien werden auf der Rendering-Ebene durchgesetzt, nicht nur am Netzwerkausgang.
Ebene 3: Identitäts- und Zugriffskontrollen
Die Browsersicherheit lässt sich mit Identitätsanbietern (Okta, Entra ID) und CASB-Richtlinien integrieren, um einen bedingten Zugriff durchzusetzen. Ein Auftragnehmer meldet sich von einem nicht verwalteten privaten Laptop aus an. Anstatt ihm uneingeschränkten SaaS-Zugriff zu gewähren oder die Sitzung vollständig zu blockieren, leitet die Richtlinien-Engine die Sitzung über RBI weiter, wobei Einschränkungen beim Hoch- und Herunterladen, eine Sperrung der Zwischenablage sowie die Einblendung von Wasserzeichen gelten. Der Auftragnehmer kann seine Arbeit erledigen. Das Unternehmen behält die Kontrolle über seine Daten.
Ebene 4: Transparenz und Analytik
Die Sitzungstelemetrie – welcher Benutzer auf welche Anwendung zugegriffen hat, von welchem Gerät aus und welche Aktionen er versucht hat – fließt in den Workflow des Sicherheitsbetriebs ein. Dies ist die Ebene, die den Browser von einem blinden Fleck in einen Sensor verwandelt.
Wie sich die Browsersicherheit in die Unternehmensarchitektur einfügt
Die Browsersicherheit funktioniert nicht isoliert. Sie lässt sich in jede Ebene Ihres bestehenden Sicherheitsstacks integrieren – oder steht mit dieser in Konflikt. Die architektonische Frage lautet nicht: „Brauchen wir Browsersicherheit?“, sondern: „Wo ist die Browsersicherheit im Verhältnis zu SSE, CASB, DLP, Endpoint und Identität angesiedelt?“
NIST SP 800-46, Rev. 2, enthält grundlegende Leitlinien zu Sicherheitsaspekten bei Fernzugriffslösungen und empfiehlt Organisationen, alle Komponenten von Telearbeitstechnologien abzusichern und Richtlinien zu entwickeln, die Gerätetypen, Zugriffsebenen und BYOD-Kontrollen abdecken. Der Browser ist mittlerweile die vorherrschende Telearbeitstechnologie, doch in den Fernzugriffsarchitekturen vieler Organisationen wird er nach wie vor als transparente, unkontrollierte Übertragungsleitung behandelt.
Ein gut integrierter security service edge (SSE) vereint SWG, CASB, DLP, ZTNA und RBI unter einer einzigen Richtlinien-Engine. Wenn ein Benutzer eine SaaS-Anwendung öffnet, bewertet die SSE-Plattform Identität, Gerätestatus, Standort und Datensensibilität, um zu entscheiden, ob die Sitzung direkt zugelassen, über RBI weitergeleitet, DLP-Einschränkungen angewendet oder der Zugriff vollständig blockiert werden soll. Der Browser ist der Durchsetzungspunkt; die SSE-Plattform ist das „Richtlinien-Gehirn“.
Betrachten Sie die praktischen Herausforderungen der Alternative. Eine Einrichtung im Gesundheitswesen setzt einen eigenständigen Unternehmensbrowser für 500 Pflegekräfte ein, die auf ein EHR-System zugreifen. Für diesen Anwendungsfall funktioniert dies gut. Dieselben Pflegekräfte nutzen jedoch auch Chrome für eine SaaS-Anwendung zur Patiententerminierung, Edge für ein staatliches Medicaid-Portal und Safari auf ihren privaten Smartphones für die Dienstplanerstellung. Nun muss die IT-Abteilung vier Browserkontexte mit unterschiedlichen Sicherheitsstufen verwalten. Der eigenständige Unternehmensbrowser hat zwar ein Problem gelöst, gleichzeitig aber die Sicherheitsarchitektur fragmentiert.
Der integrierte Ansatz von SSE gewährleistet die einheitliche Durchsetzung von Richtlinien in allen vier Browserkontexten – ohne dass ein Browserwechsel erforderlich ist. DLP-Richtlinien gelten unabhängig davon, welcher Browser die Sitzung öffnet. Sicherheitsmaßnahmen für das Web und die Cloud werden einheitlich angewendet.
Das Problem der Einführungshürden: Den Browser ersetzen oder den Browser absichern
Gartner weist darauf hin, dass SEBs einen segmentierten Zugriff von nicht verwalteten oder nur in geringem Umfang verwalteten Endgeräten sowie aus BYOD-Umgebungen ermöglichen, in denen der Einsatz von Endpunkt-Agenten aus Datenschutz- oder Wartungsgründen nicht angebracht wäre. Dieser Anwendungsfall ist überzeugend. Die strategische Frage lautet, wie Sie diese Kontrollmaßnahmen umsetzen.
Das Nachfolgemodell erfordert, dass die Mitarbeiter ihren Standardbrowser aufgeben und eine proprietäre Anwendung nutzen. Der Anbieter kontrolliert die Rendering-Engine, das Ökosystem der Erweiterungen sowie den Aktualisierungszyklus. Sicherheitsteams erhalten umfassende Kontrolle auf Sitzungsebene.
Der Preis dafür sind Einführungshürden. Chrome hält weltweit einen Marktanteil von über 65 % im Desktop-Bereich. Die Mitarbeiter haben jahrelange Gewohnheiten, gespeicherte Passwörter, synchronisierte Lesezeichen und auf Chrome aufbauende Arbeitsabläufe mit Erweiterungen. Die Aufforderung zum Wechsel führt zu Helpdesk-Anfragen, Schatten-IT-Workarounds (Mitarbeiter, die Chrome trotzdem öffnen, weil „manches nicht funktioniert“) und ständigen Kompatibilitätstests für jeden internen Webanwendung.
Um einen detaillierteren Vergleich der beiden Modelle zu ermöglichen, untersucht die Analyse Skyhigh Securityzum Thema „Unternehmensbrowser vs. RBI“ die Vor- und Nachteile sowie die jeweils beste Eignung für den Unternehmensbereich.
Das „Secure the Existing Browser“-Modell behält Chrome, Edge oder Safari bei und umgibt die Sitzung mit Sicherheitsmaßnahmen, die über eine SSE-Plattform bereitgestellt werden und RBI-, SWG-, DLP-, CASB- sowie ZTNA-Kontrollen umfassen. Die Benutzererfahrung bleibt unverändert. Die Durchsetzung der Richtlinien erfolgt im Hintergrund, bis ein Benutzer einen risikobehafteten Vorgang ausführt – beispielsweise das Einfügen personenbezogener Daten in ein KI-Tool, das Herunterladen einer Datei aus einer „Shadow-SaaS“-Anwendung oder den Aufruf einer Phishing-Seite.
Der Kompromiss: Der SSE-Ansatz erfordert eine TLS-Überprüfung (was eigene Überlegungen hinsichtlich Zertifikatsverwaltung und Datenschutz mit sich bringt) und kann Kontrollen auf DOM-Ebene nicht so umfassend durchsetzen wie ein proprietärer Browser. Für die meisten Anwendungsfälle in Unternehmen – Schutz des SaaS-Zugangs, Durchsetzung von DLP, Isolierung risikobehafteter Browsing-Aktivitäten, Sicherung des Zugangs für Auftragnehmer – bietet das integrierte SSE-Modell einen gleichwertigen Schutz ohne den mit der Einführung verbundenen Aufwand.
Bewertungskriterien: Auswahl einer Sicherheitsstrategie für Browser
Wenn Sie die Sicherheit von Unternehmensbrowsern bewerten, sollten Sie sich folgende Fragen stellen, bevor Sie mit einem Anbieter sprechen:
Sicherheit eines alternativen Browsers im Vergleich zur in SSE integrierten Browsersicherheit
Die Rolle von Zero Trust bei der Browsersicherheit
Browsersicherheit und Zero-Trust sind keine getrennten Initiativen – es handelt sich um ein und dieselbe Initiative, die aus unterschiedlichen Blickwinkeln betrachtet wird.
Das „Zero Trust Maturity Model v2.0“ der CISA bietet einen Ansatz für die kontinuierliche Modernisierung im Bereich Zero Trust in einer sich rasch wandelnden Technologielandschaft und dient Behörden als Leitfaden bei der Konzeption und Umsetzung von Umstellungsplänen gemäß der Executive Order 14028. Das Modell basiert auf fünf Säulen – Identität, Geräte, Netzwerke, Anwendungen und Workloads sowie Daten – sowie drei übergreifenden Funktionen: Transparenz und Analytik, Automatisierung und Orchestrierung sowie Governance.
Jede dieser Säulen trifft im Browser aufeinander:
Identität: Authentifizierungs- und Sitzungstoken werden im Browser gespeichert. Bei Man-in-the-Middle-Angriffen werden Sitzungs-Cookies über den Browser gestohlen.
Geräte: Der Browser ist die erste Anwendung, die mit einem potenziell kompromittierten Endgerät in Kontakt kommt. Die Überprüfung des Gerätestatus regelt den browserbasierten Zugriff.
Netzwerke: Die TLS-Überprüfung am SWG fängt den Browser-Datenverkehr ab, bevor er die SaaS-Anwendung erreicht.
Anwendungen und Arbeitslasten: SaaS-Anwendungen werden über den Browser genutzt. CASB-Richtlinien regeln den Zugriff auf zugelassene bzw. nicht zugelassene Anwendungen.
Daten: Sensible Daten werden über den Browser eingesehen, kopiert, heruntergeladen und hochgeladen. DLP auf Browserebene ist die letzte Verteidigungslinie, bevor Daten das Unternehmen verlassen.
Ein praktisches Szenario: Der Kreditberater einer Regionalbank greift Private Access einem Café Private Access über ZTNA / Private Access auf eine interne Kreditanwendungsanwendung zu. Die Skyhigh SSE-Plattform überprüft die Identität des Sachbearbeiters (Okta MFA), kontrolliert den Gerätestatus (verwalteter Laptop, verschlüsselte Festplatte, aktueller Betriebssystem-Patch-Stand), leitet die Sitzung zur Bedrohungsprüfung über das SWG weiter, wendet DLP-Regeln an, die das Herunterladen von Kreditunterlagen mit personenbezogenen Kundendaten verhindern, und protokolliert jede Aktion für Auditzwecke. Kein VPN. Kein proprietärer Browser. Lediglich ein durch Richtlinien gesicherter Zugriff über den Browser, den der Sachbearbeiter ohnehin bereits nutzt.
Was passiert, wenn Sie die Browsersicherheit vernachlässigen?
Der Verizon DBIR 2025 ergab, dass sich die Beteiligung Dritter an Sicherheitsvorfällen im Vergleich zum Vorjahr verdoppelt hat und nun 30 % aller Sicherheitsvorfälle ausmacht. Viele dieser Kompromittierungen durch Dritte begannen damit, dass Auftragnehmer oder Partner über nicht verwaltete Browser ohne DLP, ohne Sitzungsverwaltung und ohne Isolierung auf SaaS-Anwendungen zugreifen konnten.
Stellen Sie sich folgende Abfolge vor: Ein Analyst eines Beratungsunternehmens greift über einen nicht verwalteten privaten Laptop auf Ihre Workday-Instanz zu. Das Chrome-Profil des Analysten synchronisiert die Anmeldedaten mit einem privaten Google-Konto. Ein Familienmitglied lädt auf denselben Laptop einen Spiel-Mod herunter, der einen Infostealer enthält. Der Infostealer erfasst alle gespeicherten Browser-Passwörter, einschließlich Ihrer Workday-Anmeldedaten. Sechs Wochen später nutzt ein Angreifer diese Anmeldedaten, um auf Ihre Workday-Umgebung zuzugreifen und W-2-Daten von 8.000 Mitarbeitern zu exportieren.
Dies ist kein theoretisches Szenario – es spiegelt das Muster wider, das im Verizon DBIR im Zusammenhang mit der „Snowflake“-Verletzungsserie dokumentiert wurde, bei der kompromittierte Anmeldedaten von mit Infostealer-Malware infizierten Geräten den Zugriff auf Cloud-Umgebungen ermöglichten, in denen keine Zwei-Faktor-Authentifizierung (MFA) durchgesetzt wurde.
NIST SP 800-46, Rev. 2, betont, wie wichtig es ist, sensible Informationen zu schützen, die auf Telearbeitsgeräten gespeichert sind und über Fernzugriff durch externe Netzwerke übertragen werden. Der Browser ist mittlerweile das wichtigste Telearbeitsgerät. Er speichert Anmeldedaten, Sitzungstoken, zwischengespeicherte Daten und den Inhalt der Zwischenablage. Ihn unkontrolliert zu lassen, entspricht einem dauerhaft offenen VPN-Tunnel ohne Authentifizierung.