Cloudflare gab heute bekannt, dass es die S2 Systems Corporation aufgekauft hat, ein Start-up-Unternehmen aus Seattle, das eine innovative Remote-Browser-Isolationslösung entwickelt hat, die sich von allem unterscheidet, was derzeit auf dem Markt existiert. Bei den meisten Endpunktgefährdungen spielen Webbrowser eine Rolle. Durch die Anordnung von Speicherplatz zwischen den Benutzergeräten und dem Ausführungsort des Webcodes werden Endpunkte durch Browser-Isolation wesentlich sicherer. In diesem Blogbeitrag werde ich erläutern, was Browser-Isolation ist, warum sie wichtig ist, wie der Cloud-Browser von S2 Systems funktioniert und wie er zu Cloudflares Mission passt, das Internet besser zu machen.

Was stimmt nicht beim Web-Browsing?

Vor mehr als 30 Jahren schrieb Tim Berners-Lee den Projektvorschlag, in dem er die zugrunde liegende Technologie dessen definierte, was wir heute das World Wide Web nennen. Was Berners-Lee sich als nützlich für „mehrere tausend Menschen vorstellte, von denen viele sehr kreativ sind und die alle auf gemeinsame Ziele hinarbeiten,“[1] hat sich zu einem grundlegenden Teil des Handels, des Geschäftslebens, der Weltwirtschaft und zu einem integralen Bestandteil der Gesellschaft entwickelt, der von mehr als 58 % der Weltbevölkerung[2] genutzt wird.

Das World Wide Web und Web-Browser sind eindeutig zur Plattform für einen Großteil der produktiven Tätigkeiten (und der Spiele) geworden, mit denen Menschen tagtäglich ihre Zeit verbringen. Doch mit der zunehmenden Nutzung des Internets wuchsen auch die Möglichkeiten für böswillige Akteure. Kaum ein Tag vergeht, ohne dass eine neue große Cybersicherheitsverletzung in den Nachrichten auftaucht. Mehrere Faktoren haben dazu beigetragen, die Cyberkriminalität auf ein nie dagewesenes Niveau anzuheben: die Kommerzialisierung von Hacking-Tools, das Auftauchen von Malware-as-a-Service, die Präsenz von gut finanzierten Nationalstaaten und organisiertem Verbrechen sowie die Entwicklung von Kryptowährungen, die es böswilligen Akteuren jeder Prägung ermöglichen, ihre Aktivitäten anonym in Geld umzusetzen.

Die überwiegende Mehrheit der Sicherheitsverletzungen hat ihren Ursprung im Internet. Gartner nennt das öffentliche Internet eine „Jauchegrube von Angriffen“ und identifiziert Webbrowser als die Hauptschuldigen, die für 70 % der Endpunktgefährdungen verantwortlich sind.[3] Das sollte nicht überraschen. Obwohl moderne Webbrowser bemerkenswert sind, wurden viele grundlegende architektonische Entscheidungen in den 1990er Jahren getroffen, bevor Konzepte wie Sicherheit, Datenschutz, Unternehmensaufsicht und Compliance zu Problemen wurden oder gar nur im Gespräch waren. Die Kernfunktionalität des Web-Browsings (einschließlich der gesamten zugrunde liegenden WWW-Architektur) wurde für eine andere Ära und andere Umstände entwickelt.

In der heutigen Welt sind mehrere Annahmen zum Web-Browsing veraltet oder sogar gefährlich. Webbrowser und die zugrunde liegenden Servertechnologien umfassen eine umfangreiche – und wachsende – Liste komplexer, miteinander verbundener Technologien. Diese Technologien sind ständig in Bewegung und werden von dynamischen Open-Source-Communities, Content-Anbietern, Suchmaschinen, Werbeagenturen und dem Wettbewerb zwischen Browser-Unternehmen beeinflusst. Als Folge dieser zugrunde liegenden Komplexität sind Webbrowser zu primären Angriffsvektoren geworden. Laut Gartner „setzt der bloße Akt der Benutzer, im Internet zu browsen und URL-Links anzuklicken, das Unternehmen einem erheblichen Risiko aus. [...] Angriffe durch den Browser sind zu einfach, und die Ziele sind zu reichhaltig.“[4] Sogar „scheinbar ‚gute‘ Websites können leicht gefährdet werden und lassen sich ausnutzen, um Besucher anzugreifen“ (Gartner[5]), wobei mehr als 40 % der bösartigen URLs auf „guten“ Domänen gefunden werden (Webroot[6]). (Eine vollständige Liste der Sicherheitsrisiken ginge über den Rahmen dieses Beitrags hinaus.)

Die Struktur und die zugrunde liegenden Technologien, die das Internet antreiben, sind von Natur aus schwer zu sichern. Einige Browser-Schwachstellen resultieren aus illegitimer Verwendung von legitimen Funktionen. So ist es z. B. gut, wenn Browser Dateien und Dokumente herunterladen können, aber das Herunterladen von mit Malware infizierten Dateien ist schlecht; dynamisches Laden von Inhalten aus mehreren Websites auf einer einzelnen Webseite ist gut, aber Website-übergreifendes Skripting ist schlecht; die Möglichkeit eines umfangreichen Werbe-Ökosystems ist gut, aber die Unfähigkeit, gehackte Links oder böswillige Umleitungen zu Malware- oder Phishing-Sites zu erkennen, ist schlecht – und so weiter und so fort.

Probleme für Unternehmen beim Browsen

Unternehmen sehen sich mit herkömmlichen Browsern zusätzlichen Problemen ausgesetzt.

Paradoxerweise haben IT-Abteilungen die wenigste Kontrolle über die allgegenwärtigste App im Unternehmen – den Webbrowser. Die häufigsten Beschwerden über Webbrowser von Unternehmenssicherheits- und IT-Experten sind:

  1. Sicherheit (offensichtlich). Das öffentliche Internet ist eine ständige Quelle von Sicherheitsverletzungen, und angesichts einer 11-fachen Eskalation von Angriffen seit 2016 wächst das Problem weiter (Meeker[7]). Die Kosten für Erkennung und Behebung steigen, und die Rufschädigung und finanzielle Verluste bei Sicherheitsverletzungen können erheblich sein.
  2. Kontrolle. IT-Abteilungen haben wenig Einblick in die Benutzeraktivität und nur begrenzte Möglichkeiten, Mechanismen für CDR (Content Disarm & Reconstruction) und DLP (Data Loss Prevention) zu nutzen, einschließlich wann, wo oder wer Dateien herunterlädt/hochlädt.
  3. Compliance. Die Unfähigkeit, Daten und Aktivitäten über Regionen hinweg zu kontrollieren oder die erforderliche Überwachungstelemetrie aufzubringen, um immer strengere regulatorische Anforderungen zu erfüllen. So werden Unternehmen einem erheblichen Risiko von Strafen oder Geldbußen ausgesetzt.

Angesichts von Schwachstellen, die durch alltägliche Benutzeraktivitäten wie E-Mail und Web-Browsing bloßgelegt werden, versuchen einige Unternehmen, diese Aktivitäten einzuschränken. Da beides legitime und kritische Geschäftsfunktionen sind, scheitern Bemühungen zu einer eingeschränkten Verwendung von Webbrowsern unweigerlich oder haben wesentliche negative Auswirkungen auf die Produktivität der Unternehmen und die Mitarbeitermoral.

Aktuelle Ansätze zur Minderung von Sicherheitsproblemen, die mit dem Browsen im Internet verbunden sind, basieren weitgehend auf Signatur-Technologien für Datendateien und ausführbare Dateien sowie auf Listen bekannter guter/schlechter URLs und DNS-Adressen. Das Problem bei diesen Ansätzen liegt in der Schwierigkeit, bei bekannten Angriffen (Dateisignaturen, URLs und DNS-Adressen) auf dem Laufenden zu bleiben, und in ihrer inhärenten Anfälligkeit für Zero-Day-Angriffe. Hacker haben automatisierte Tools entwickelt, um signaturbasierte Ansätze zu überwinden (z. B. durch Generieren von großen Dateimengen mit unbekannten Signaturen) und Millionen von kurzlebigen Websites zu erstellen, um URL/DNS-Blacklists zu bezwingen.

Obwohl diese Ansätze sicherlich einige Angriffe verhindern, deuten die wachsende Zahl von Vorfällen und die Schwere der Sicherheitsverletzungen eindeutig darauf hin, dass effektivere Alternativen erforderlich sind.

Was ist Browser-Isolation?

Das Kernkonzept hinter der Browser-Isolation ist Sicherheit durch physische Isolation, um eine „Lücke“ zwischen dem Webbrowser eines Benutzers und dem Endgerät zu schaffen und so das Gerät (und das Unternehmensnetzwerk) vor Exploits und Angriffen zu schützen. Im Gegensatz zu sicheren Web-Gateways, Antivirensoftware und Firewalls, die auf bekannten Bedrohungsmustern oder Signaturen basieren, handelt es sich hierbei um einen Zero-Trust-Ansatz.

Es gibt zwei primäre Browser-Isolationsarchitekturen: (1) clientbasierte lokale Isolation und (2) Remote-Isolation.

Bei der lokalen Browser-Isolation wird versucht, einen Browser, der an einem lokalen Endpunkt ausgeführt wird, mithilfe von Sandboxing auf App- oder Betriebssystemebene zu isolieren. Diese Systeme stellen bei einem Isolationsversagen nicht nur ein Risiko für den Endpunkt dar, sondern erfordern auch erhebliche Endpunktressourcen (Speicher + Rechenleistung), sind in der Regel anfällig, und sind für die IT-Abteilung schwer zu verwalten, da sie auf Unterstützung durch bestimmte Hardware- und Softwarekomponenten angewiesen sind.

Darüber hinaus trägt die lokale Browser-Isolation nicht dazu bei, die oben genannten Kontroll- und Compliance-Probleme zu beheben.

Die Remote-Browser-Isolation (RBI) schützt den Endpunkt, indem der Browser zu einem Remote-Dienst in der Cloud oder zu einem separaten lokalen Server innerhalb des Unternehmensnetzwerks verschoben wird:

  • Durch die Vor-Ort-Isolierung wird das Risiko einfach vom Endpunkt an einen anderen Standort innerhalb des Unternehmens verschoben, ohne es tatsächlich zu beseitigen.
  • Cloudbasiertes Remote-Browsing isoliert das Endbenutzergerät und das Netzwerk des Unternehmens und ermöglicht gleichzeitig vollständige IT-Kontroll- und Compliance-Lösungen.

Angesichts der inhärenten Vorteile nutzen die meisten Browser-Isolationslösungen – einschließlich S2 Systems – cloudbasierte Remote-Isolation. Bei richtiger Implementierung kann Remote-Browser-Isolation das Unternehmen vor Browser-Exploits, Plug-Ins, Zero-Day-Sicherheitsrisiken, Malware und anderen in Webinhalte eingebetteten Angriffen schützen.

Wie funktioniert Remote-Browser-Isolation (RBI)?

In einem typischen cloudbasierten RBI-System (blau umrandeter Kasten ❶ unten) werden einzelne Remote-Browser ❷ in der Cloud als containerisierte Einmal-Instanzen ausgeführt – in der Regel eine Instanz pro Benutzer. Der Remote-Browser sendet den gerenderten Inhalt einer Webseite mithilfe eines spezifischen Protokolls und Datenformats ❸ an das Endpunktgerät ❹ des Benutzers. Aktionen des Benutzers wie Tastenanschläge, Maus- und Scrollbefehle, werden über einen sicheren verschlüsselten Kanal an den Isolationsdienst zurückgesendet, wo sie vom Remote-Browser verarbeitet werden, und alle resultierenden Änderungen an der Remote-Browser-Webseite werden an das Endpunktgerät zurückgeschickt.

Tatsächlich fungiert das Endpunktgerät als eine Art „Fernsteuerung“ des Cloud-Browsers. Bei einigen RBI-Systemen werden proprietäre Clients eingesetzt, die am lokalen Endpunkt installiert sind, während andere Systeme vorhandene HTML5-kompatible Browser am Endpunkt nutzen und als „clientlos“ gelten.

Datenpannen, die im Remote-Browser auftreten, sind vom lokalen Endpunkt und dem Unternehmensnetzwerk isoliert. Jede Remote-Browser-Instanz wird wie eine kompromittierte Instanz behandelt und nach der Sitzung beendet. Neue Browsersitzungen beginnen mit einer neuen Instanz. Natürlich muss der RBI-Dienst verhindern, dass Browser-Verletzungen die Browser-Container verlassen und an den Dienst selbst weitergegeben werden. Die meisten RBI-Systeme haben Remote-Dateianzeigen, die das Herunterladen von Dateien überflüssig machen, verfügen aber auch über die Möglichkeit, Dateien auf Malware zu überprüfen, bevor sie heruntergeladen werden dürfen.

Eine wichtige Komponente in der obigen Architektur ist die spezifische Remoting-Technologie, die vom Cloud-RBI-Dienst verwendet wird. Die Remoting-Technologie hat erhebliche Auswirkungen auf die Betriebskosten und Skalierbarkeit des RBI-Dienstes, die Datentreue und Kompatibilität von Websites, die Bandbreitenanforderungen, die Anforderungen an Hardware und Software am Endpunkt und sogar die Benutzerfreundlichkeit. Die Remoting-Technologie bestimmt auch das effektive Sicherheitsniveau des RBI-Systems.

Alle aktuellen Cloud-RBI-Systeme verwenden eine von zwei Remoting-Technologien:

(1)    Pixel-Pushing ist ein videobasierter Ansatz, der Pixelbilder des Remote-Browser-„Fensters“ erfasst und eine Sequenz von Bildern an den Client-Endpunktbrowser oder proprietären Client überträgt. Dies ähnelt der Funktionsweise von Remote-Desktop- und VNC-Systemen. Obwohl dieser Ansatz als relativ sicher angesehen wird, weist er mehrere inhärente Probleme auf:

  • Die kontinuierliche Codierung und Übertragung von Videostreams von Remote-Webseiten an Endpunktgeräte von Benutzern ist sehr kostspielig. Diesen Ansatz auf Millionen von Benutzern zu skalieren, ist finanziell unerschwinglich und logistisch komplex.
  • Es ist erhebliche Bandbreite erforderlich. Selbst bei hoher Optimierung ist Pixel-Pushing bandbreitenintensiv.
  • Unvermeidbare Latenz führt zu einer unbefriedigenden Benutzererfahrung. Diese Systeme sind in der Regel langsam und führen zu vielen Benutzerbeschwerden.
  • Die Unterstützung für mobile Geräte wird durch hohe Bandbreitenanforderungen beeinträchtigt und durch inkonsistente Konnektivität noch weiter erschwert.
  • HiDPI-Displays werden möglicherweise mit niedrigeren Auflösungen gerendert. Die Pixeldichte nimmt exponentiell mit der Auflösung zu, was bedeutet, dass Remote-Browsersitzungen auf HiDPI-Geräten unscharf erscheinen können (betrifft insbesondere Schriftarten).

(2) Die DOM-Rekonstruktion entstand als Reaktion auf die Mängel des Pixel-Pushings. Dabei wird versucht, HTML, CSS usw. auf Webseiten zu bereinigen, bevor der Inhalt an den lokalen Endpunktbrowser weitergeleitet wird. Das zugrunde liegende HTML, CSS usw. wird rekonstruiert, um zu versuchen, aktiven Code, bekannte Exploits und andere potenziell böswillige Inhalte zu beseitigen. Während die Probleme von Latenz, Betriebskosten und Benutzerfreundlichkeit des Pixel-Pushings angegangen werden, wirft dieser Ansatz zwei neue wesentliche Probleme auf:

  • Sicherheit. Bei den zugrunde liegenden Technologien – HTML, CSS, Web-Schriftarten usw. – handelt es sich um die Angriffsvektoren, die Hacker nutzen, um Endpunkte anzugreifen. Wenn versucht wird, bösartige Inhalte oder Code zu entfernen, ist das so, als wenn man Mücken waschen würde: Sie können versuchen, sie sauber zu bekommen, aber sie bleiben von Natur aus Überträger von gefährlichen und schädlichen Stoffen. Es ist unmöglich, im Voraus alle Mittel zum Missbrauch dieser Technologien zu identifizieren – nicht einmal mit einem RBI-System.
  • Website-Zuverlässigkeit. Bei der Rekonstruktion von HTML, CSS und anderen Aspekten moderner Websites kommt es durch den Versuch, böswilligen aktiven Code zu entfernen, unweigerlich zu fehlerhaften Seiten, die nicht richtig oder überhaupt nicht gerendert werden. Websites, die heute funktionieren, funktionieren morgen möglicherweise nicht, da Website-Betreiber täglich Änderungen vornehmen, die die Funktionalität der DOM-Rekonstruktion beeinträchtigen können. Das Ergebnis ist eine unendliche Folge von Problemen, die erhebliche Ressourcen und endlose Anstrengungen erfordern, um ständig neu auftretende Fehler zu beheben. Während mit Malware infizierte Web-E-Mails weiterhin eine bedeutende Quelle für Sicherheitsverletzungen darstellen, bereitet es einigen RBI-Lösungen Mühe, gängige unternehmensweite Dienste wie Google G Suite oder Microsoft Office 365 zu unterstützen.

Kunden haben die Wahl zwischen einer sicheren Lösung mit schlechter Benutzererfahrung und hohen Betriebskosten oder einer schnelleren, viel weniger sicheren Lösung, die zu fehlerhaften Websites führt. Diese Abstriche haben einige RBI-Anbieter dazu gebracht, beide Remoting-Technologien in ihre Produkte zu implementieren. Dadurch wird das Problem jedoch lediglich auf die Kunden verlagert, ohne dass die grundlegenden Ursachen angegangen werden.

Angesichts der erheblichen Abstriche bei heutigen RBI-Systemen besteht eine übliche Optimierung für aktuelle Kunden darin, Remote-Browsing-Funktionen nur für die anfälligsten Benutzer in einem Unternehmen bereitzustellen, z. B. Führungskräfte in kritischen Positionen oder Mitarbeiter in den Bereichen Finanzen, Geschäftsentwicklung oder Personal. Ähnlich wie bei einem Szenario, bei dem nur die Hälfte der Schüler einer Klasse geimpft wird, führt dies zu einem falschen Gefühl der Sicherheit und trägt wenig zum Schutz des Unternehmens insgesamt bei.

Leider ist die größte „Lücke“, die durch aktuelle Remote-Browser-Isolationssysteme geschaffen wird, die Lücke zwischen dem Potenzial des zugrunde liegenden Isolationskonzepts und der realen Implementierung derzeit verfügbarer RBI-Systeme.

Remote-Browser-Isolation mit S2 Systems

Die Remote-Browser-Isolation von S2 Systems ist ein grundlegend anderer Ansatz, der auf patentierter S2-Technologie mit der Bezeichnung Network Vector Rendering (NVR) basiert.

Der S2-Remote-Browser beruht auf dem Open-Source-Chromium-Modul, auf dem Google Chrome aufgebaut ist. Zusätzlich zu Google Chrome mit seinem Marktanteil von ca. 70 %[8] unterstützt Chromium 21 weitere Webbrowser, darunter auch Microsofts neuen Edge-Browser.[9] Als Ergebnis sorgen beträchtliche laufende Investitionen in das Chromium-Modul für ein Höchstmaß an Website-Unterstützung, Kompatibilität und einen kontinuierlichen Strom von Verbesserungen.

Ein wesentliches architektonisches Merkmal des Chromium-Browsers besteht in der Nutzung der Skia-Grafikbibliothek. Skia ist ein weit verbreitetes, plattformübergreifendes Grafikmodul für Android, Google Chrome, Chrome OS, Mozilla Firefox, Firefox OS, FitbitOS, Flutter, das Electron-Anwendungsframework und viele andere Produkte. Wie Chromium sorgt auch die Verbreitung von Skia für eine kontinuierliche, umfassende Hardware- und Plattformunterstützung.

Skia-Code-Fragment

Alles, was in einem Chromium-Browserfenster sichtbar ist, wird über die Skia-Rendering-Ebene gerendert. Dazu gehören Elemente von Benutzeroberflächen in Anwendungsfenstern, wie etwa Menüs, aber noch wichtiger ist, dass der gesamte Inhalt des Webseitenfensters über Skia gerendert wird. Chromium-Aufbau, -Layout und -Rendering sind extrem komplex und laufen über mehrere parallele Pfade, die für verschiedene Inhaltstypen, Gerätekontexte usw. optimiert sind. Die folgende Abbildung ist eine extreme Vereinfachung der S2-Funktionsweise für Veranschaulichungszwecke (Chromium-Experten werden um Verzeihung gebeten):

Die NVR-Technologie von S2 Systems fängt die Skia-Zeichnen-Befehle des Remote-Chromium-Browsers ab ❶, tokenisiert und komprimiert sie und verschlüsselt und überträgt sie dann über die Leitung ❷ an einen beliebigen HTML5-kompatiblen Webbrowser ❸ (Chrome, Firefox, Safari usw.), der lokal auf dem Desktopcomputer oder Mobilgerät am Benutzerendpunkt läuft. Die vom NVR erfassten Skia-API-Befehle sind vorgerastert, d. h. sie sind sehr kompakt.

Bei der ersten Verwendung überträgt der S2-RBI-Dienst transparent eine NVR-WebAssembly-(Wasm)-Bibliothek ❹ an den lokalen HTML5-Webbrowser auf dem Endpunktgerät, auf dem sie für spätere Verwendungen zwischengespeichert wird. Der NVR-Wasm-Code enthält eine eingebettete Skia-Bibliothek und den notwendigen Code zum Entpacken, Entschlüsseln und „Wiedergeben“ der Skia-Zeichnen-Befehle vom Remote-RBI-Server im lokalen Browserfenster. Die Fähigkeit eines WebAssemblys, „Befehle mit nativer Geschwindigkeit auszuführen, indem allgemeine Hardwarefunktionen genutzt werden, die auf einer Vielzahl von Plattformen verfügbar sind“,[10] führt zu nahezu nativer Zeichenleistung.

Der S2-Remote-Browser-Isolationsdienst verwendet monitorlose Chromium-basierte Browser in der Cloud, fängt die Ausgabe von Zeichnen-Ebenen transparent ab, überträgt die Zeichnen-Befehle effizient und sicher über das Web und zeichnet sie in den Fenstern lokaler HTML5-Browser neu. Diese Architektur bietet eine Reihe von technischen Vorteilen:

(1)    Sicherheit: Der zugrunde liegende Datentransport ist kein vorhandener Angriffsvektor und Kunden sind nicht gezwungen, einen Kompromiss zwischen Sicherheit und Performance einzugehen.

(2)    Website-Kompatibilität: Es gibt keine Probleme mit der Website-Kompatibilität und kein langes Hinterherrennen nach neuen Web-Technologien oder aufkommenden Schwachstellen.

(3)    Performance: Das System ist sehr schnell, in der Regel schneller als lokales Browsen (Thema eines zukünftigen Blogbeitrags).

(4)    Transparente Benutzererfahrung: S2-Remote-Browsing verleiht den Eindruck von nativem Browsen. Benutzer merken es im Allgemeinen nicht, wenn sie remote browsen.

(5)    Für die meisten Websites ist weniger Bandbreite erforderlich als bei lokalem Browsen. Es sind erweitertes Caching und andere proprietäre Optimierungen möglich, die sich nur bei Webbrowsern und der besonderen Natur von Web-Inhalten und -Technologien erzielen lassen.

(6)    Clientlos: Es werden vorhandene HTML5-kompatible Browser genutzt, die bereits auf dem Desktopcomputer und den Mobilgeräten am Benutzerendpunkt installiert sind.

(7)    Kostengünstige Skalierbarkeit: Obwohl die Details über den Rahmen dieses Beitrags hinausgehen, soll erwähnt werden, dass die Back-End- und die NVR-Technologie von S2 wesentlich niedrigere Betriebskosten aufweisen als bestehende RBI-Technologien. Betriebskosten schlagen sich direkt in Kundenkosten nieder. Das S2-System wurde entwickelt, um für Kunden die Bereitstellung für ein ganzes Unternehmen und nicht nur für bestimmte Benutzer („die halbe Klasse impfen“) realisierbar und attraktiv zu machen.

(8)    RBI-as-a-Platform: ermöglicht die Implementierung verwandter bzw. benachbarter Dienste wie DLP, Content Disarm & Reconstruction (CDR), Phishing-Erkennung und -Prävention usw.

Der Remote-Browser-Isolationsdienst von S2 Systems und die zugrunde liegende NVR-Technologie heben die Kluft zwischen den konzeptionellen Möglichkeiten und dem Versprechen der Browser-Isolation auf der einen Seite und der unbefriedigenden Realität aktueller RBI-Technologien auf der anderen Seite auf.

Cloudflare und Remote-Browser-Isolation von S2 Systems

Die globale Cloud-Plattform von Cloudflare ist für Remote-Browsing-Isolation besonders gut geeignet. Nahtlose Integration in unsere Cloud-nativen Performance-, Zuverlässigkeits- und erweiterten Sicherheitsprodukte und -dienste bietet unseren Kunden leistungsstarke Möglichkeiten.

Unsere Cloudflare-Workers-Architektur ermöglicht Edge-Computing in 200 Städten in mehr als 90 Ländern und macht einen Remote-Browser für 99 % der mit dem Internet verbundenen Bevölkerung in den Industrieländern innerhalb von 100 Millisekunden erreichbar. Mit mehr als 20 Millionen Websites, die direkt mit unserem Netzwerk verbunden sind, profitiert Cloudflares Remote-Browser-Isolation von lokal zwischengespeicherten Daten und baut auf der beeindruckenden Konnektivität und Performance unseres Netzwerks auf. Unsere Funktion Argo Smart Routing nutzt unsere Kommunikations-Backbone, um Datenverkehr über schnellere und zuverlässigere Netzwerkpfade zu leiten, was durchschnittlich zu einem 30 % schnelleren Zugriff auf Web-Ressourcen führt.

Sobald sie in unsere „Cloudflare for Teams“-Suite mit erweiterten Sicherheitsprodukten integriert ist, wird Remote-Browser-Isolation Schutz vor Browser-Exploits, Zero-Day-Sicherheitsrisiken, Malware und anderen Angriffen bieten, die in Webinhalte eingebettet sind. Unternehmen werden in der Lage sein, die Browser aller Mitarbeiter zu sichern, ohne Kompromisse zwischen Sicherheit und Benutzerfreundlichkeit eingehen zu müssen. Der Dienst ermöglicht die IT-Kontrolle von browserübermittelten Unternehmensdaten und die Überwachung der Compliance-Einhaltung. Die nahtlose Integration unserer Produkte und Services wird es Nutzern und Unternehmen ermöglichen, ohne Angst oder Folgen im Internet zu browsen.

Die Mission von Cloudflare besteht darin, das Internet besser zu machen. Das bedeutet, Benutzer und Unternehmen zu schützen, während sie im Internet arbeiten und spielen; es bedeutet, den Zugriff auf das Internet schnell, zuverlässig und transparent zu gestalten. Die Neugestaltung und Modernisierung der Funktionsweise des Web-Browsings ist ein wichtiger Teil davon, das Internet besser zu machen.


[1] https://www.w3.org/History/1989/proposal.html

[2] „Internet World Stats“, https://www.internetworldstats.com/, abgerufen am 21.12.2019.

[3] „Innovation Insight for Remote Browser Isolation“, (Bericht-ID: G00350577) Neil MacDonald, Gartner Inc, 8. März 2018

[4] Gartner, Inc., Neil MacDonald, „Innovation Insight for Remote Browser Isolation“, 8. März 2018

[5] Gartner, Inc., Neil MacDonald, „Innovation Insight for Remote Browser Isolation“, 8. März 2018

[6] „2019 Webroot Threat Report: Forty Percent of Malicious URLs Found on Good Domains“, 28. Februar 2019

[7] „Kleiner Perkins 2018 Internet Trends“, Mary Meeker.

[8] https://www.statista.com/statistics/544400/market-share-of-internet-browsers-desktop/, abgerufen am 21. Dezember 2019

[9] https://en.wikipedia.org/wiki/Chromium_(web_browser), abgerufen am 29. Dezember 2019

[10] https://webassembly.org/, abgerufen am 30. Dezember 2019