DE{CODE}: Warum der Edge kein Edge-Fall ist

Wenn Sie am Edge sind, dürfen Geschwindigkeit, Sicherheit und Serverzustand keine Nebensächlichkeiten sein. In dieser Sitzung diskutieren Cloudflare VP of Product Sergi Isasi und WP Engine Product Manager Pavan Tirupati, warum eine Edge-First-Mentalität für den Erfolg jeder Website, die Sie erstellen oder pflegen, unerlässlich ist

Sitzungsfolien

Vollständige Textabschrift

PAVAN TIRUPATI : Hey, alle zusammen. Vielen Dank für Ihre Teilnahme an dieser Sitzung darüber, dass das Alter nicht wirklich ein Grenzfall ist. Ich bin Pavan Tirupati, Produktmanager bei WP Engine im The Outreach-Team, und ich bin in erster Linie für die Sicherheit, Leistung und Zuverlässigkeit des Edge verantwortlich, um WP Engine-Kunden zu erweitern und zu stärken.

Und heute kommt Sergi, VP of Product Management, von Cloudflare zu uns. Sergi, möchtest du dich vorstellen?

SERGI ISASI : Sicher. Danke, dass du mich eingeladen hast, Pavan. Und ich danke Ihnen allen, dass Sie an unserer Sitzung teilgenommen haben. Wie Pavan sagte, bin ich VP of Product for Application Performance bei Cloudflare und konzentriere mich auf die Leistung und Zuverlässigkeit unseres Edge. Wir wollen die Dinge für alle unsere Kunden schnell und zuverlässig machen. Produkte, die ich behandle, sind, wie Cloudflare Datenverkehr am Edge empfängt und verarbeitet, also sowohl auf Layer 4 als auch auf Layer 7. Dazu gehören also unser Cache, unser Proxy, das FL-Spektrum, grundlegende Technologien für Cloudflare wie unsere DNS-Systeme, unsere Zertifikatsverwaltungssysteme und unsere IP-Adressverwaltungssysteme und dann auch die neuen Edge-Anwendungen, also Load-Balancing, unser brandneues Waiting Room-Produkt und unsere kommenden Web3-Produkte.

Ich bin seit ungefähr 4 1/2 Jahren bei Cloudflare. Und ich bin froh, heute hier zu sein.

PAVAN TIRUPATI: Großartig. Und heute haben wir eine wundervolle Session für euch, in der wir genauer untersuchen, was Edge genau ist und wie es nützlich ist, und wie der Titel schon sagt, warum Edge kein Grenzfall mehr ist. Die Agenda, die wir für euch haben, ist eine tiefere Auseinandersetzung mit dem, was Edge ist und was die Vorteile davon sind. Und angesichts dieser Zeiten ist es entscheidend, sich mehr auf die Sicherheit zu konzentrieren.

Und wir werden über einige Beispiele sprechen und über einige Sicherheitsbedrohungen sprechen. Wir werden uns auch ansehen, wie Edge für das hier anwesende Publikum und alle, die weltweit digital präsent sind, von Vorteil sein wird. Und wir werden uns auch einige spezifische Beispiele ansehen, die für Menschen von Vorteil sein könnten, die möglicherweise einige dieser Sicherheitsbedrohungen und -probleme durchmachen.

Es wird also spannend, einfallsreich und aufschlussreich. Beginnen wir also damit, hier einen Kontext festzulegen. Ich möchte eine Grundlinie dessen festlegen, was Edge ist. Und ich denke, es ist für niemanden eine Überraschung, wenn ich sage, dass Unternehmen einen Wandel hin zu einer Builder-Kultur erleben, einer Kultur, die auf der Fähigkeit von Entwicklern aufbaut, digitale Erlebnisse direkt zu erstellen und zu steuern.

Da Sites und Anwendungen von monolithischen Builds zu einer Microservices-Architektur übergehen, wird die Fähigkeit, Inhalte aus verschiedenen Quellen bereitzustellen, immer wichtiger. Und wir kennen und verstehen den Edge als Teil des Internets, der unseren Endbenutzern tatsächlich am nächsten ist, manchmal auch als letzte Meile bezeichnet. Aber bevor ich auf die Einzelheiten eingehe, Sergi, möchte ich das Publikum darüber aufklären, was der Vorteil ist und warum es überhaupt kritisch ist.

SERGI ISASI: Sicher. Es gibt also ein altes Sprichwort im Cloud-Computing, das lautet: „Cloud ist nur der Computer von jemand anderem“. Ich mag diesen Spruch sehr. Es bedeutet, dass es dasselbe ist, was Sie auf Ihrem Desktop oder Laptop haben würden, aber es ist nur jemand anderes, der es verwaltet. Und der Rand ist genau dasselbe, er ist nur näher am Benutzer.

Warum ist das wichtig? Wir möchten, dass die Dinge – bei Cloudflare – so nah wie möglich am Benutzer sind. Und es kommt wirklich auf diese Aussage an, die Sie gesagt haben, nämlich die letzte Meile. Also, egal wie schnell Sie Ihre Software machen, wie effizient Sie sie machen können, wenn Sie überhaupt auf etwas reagieren – wenn Ihre Software im Submillisekundenbereich laufen kann, sind Sie immer noch der Lichtgeschwindigkeit verpflichtet. Und wenn sich Ihre Software nicht auf dem Gerät des Benutzers oder so nah wie möglich am Benutzer befindet, wird der Benutzer dieses kleine bisschen Latenz erleben. Und manchmal ist diese Latenz in Ordnung und manchmal ist sie für den Endbenutzer sehr, sehr störend. Es geht also darum, das zu optimieren, was sinnvoll ist, um nahe am Rand des Endbenutzers oder nahe am Kern zu sein.

Und was Cloudflare tut, ist, dass wir versuchen, alles auf den Rand zu bringen. Ich denke, einer der Gründe, warum Sie mich gebeten haben, diesen Chat zu führen, ist, dass wir wohl eines der größten Edge-Netzwerke der Welt betreiben und offensichtlich unglaublich stolz darauf sind. Cloudflare ist etwas mehr als 10 Jahre alt und wir haben dieses Netzwerk die ganze Zeit aufgebaut. Es ist auf 250 Städte in 100 verschiedenen Ländern angewachsen, mit dem Ziel – und tatsächlich haben wir dieses Ziel erreicht – innerhalb von 50 Millisekunden 95 % der Internetnutzer auf der ganzen Welt zu erreichen. Und das wiederum, die letzte Meile – wenn wir innerhalb von 50 Millisekunden sein können, können wir jeden dieser Endbenutzer so viel schneller erreichen.

Der andere Teil davon ist die Verbindung zu anderen Netzwerken. Wir verbinden uns also mit 10.000 anderen Netzwerken auf der ganzen Welt, zum Beispiel vielen lokalen ISPs, und dann betreiben wir auch unser eigenes Backbone, also machen Sie das Backhauling dieses Datenverkehrs, wenn wir zum Kern oder zum Ursprung gehen müssen, machen Sie das noch schneller. Wir haben das Jahr 2021 mit einer Kapazität von etwas mehr als 100 Terabit pro Sekunde beendet. Und das ist wichtig, wenn es um die horizontale Skalierung geht, sowohl für die Zunahme des Datenverkehrs für unsere Kunden als auch für die Zunahme von Angriffen auf unsere Kunden und auch auf unser eigenes Netzwerk.

Eines der Dinge, die in den letzten 30, 40 Jahren an der Datenverarbeitung interessant waren, ist ihr Übergang, hin und her, von Edge zu Core zu Client, je nachdem, wo es sinnvoll war und wo die gesamte Rechenleistung zu diesem Zeitpunkt war. Wenn Sie also bis zum voröffentlichen Internet zurückdenken, hatten Sie Mainframes. Sie hatten viel Rechenleistung im Kern und sehr wenig Rechenleistung am Rand und sehr wenig Bandbreite, um das hin und her zu übertragen. Sie haben also Befehle an den Mainframe gesendet und er hat Ihnen die Ergebnisse dieser Befehle als Text zurückgesendet.

Wir sind von dort zu vielen Verbesserungen am Endpunkt übergegangen, sodass Sie viele fette Clients erhalten haben – Windows, Microsoft Word, all diese Dinge, für die Sie jetzt am Endpunkt viel Rechenleistung erbracht haben und die Sie dann zurückgeschickt haben, normalerweise zum Kern, um diese Inhalte zu teilen.

Als der Rand und der Kern stärker wurden, fingen Sie an, Cloud-Apps zu sehen. Anstatt diese Änderung auf Ihrem Gerät vorzunehmen, haben Sie die Änderung in einem Webbrowser vorgenommen und diese Änderung wurde über andere Geräte zum Teilen weitergegeben. Und das wurde wirklich wichtig, als wir mobile Geräte hatten, insbesondere frühe mobile Geräte, die weniger Rechenleistung, aber viel mehr Bandbreite hatten.

Warum ist das kritisch? Es dreht sich wirklich alles um die Erwartungen der Benutzer an die Geschwindigkeit. Der Benutzer wünscht sich also immer eine gute Benutzererfahrung. Und gerade heute ist die Idee einer guten Benutzererfahrung eine Art sofortige Interaktion. Ich klicke auf einen Link, ich drücke eine Taste, etwas passiert, und es ist mir egal, wo es passiert ist. Ich weiß vielleicht nicht einmal, wo es passiert ist, aber ich möchte, dass es schnell geht.

Die andere Sache, die sich geändert hat, ist die Umgebung, in der wir uns befinden. Es gibt also deutlich mehr Angriffe, hauptsächlich weil diese Geräte leistungsfähiger geworden sind. Und dann sehen wir viele sich ändernde Vorschriften, da Sicherheit und Datenschutz nicht nur für Benutzer, sondern auch für Regierungen an erster Stelle stehen. Und deshalb fügt Cloudflare ständig POPs hinzu. Wir sehen mehr Benutzer, wir sehen mehr Verkehr, wir sehen mehr Angriffe und wir sehen mehr Anwendungsfälle, die wir an den Rand bringen und für diese Endbenutzer leistungsfähig machen könnten.

PAVAN TIRUPATI: Großartig. Können wir uns ein bisschen mit Pop beschäftigen? Was ist POP? Und was hat sich bei den POPs im Laufe der Zeit verändert? Und speziell die Cloudflare-Implementierung von POP, was ist einzigartig?

SERGI ISASI: Also danke, dass du das zurückgebracht hast. Ich sage oft POPs, und ich sollte spezifizieren, was es bedeutet. Es ist ein Internet Point of Presence. Und im Fall von Cloudflare und in den meisten anderen Fällen, wenn Sie jemanden über einen POP sprechen hören, ist das ein Stapel von Servern, die irgendwo sitzen und Software ausführen.

Was sich im Laufe der Zeit geändert hat, ist eigentlich einfacher darüber zu sprechen, was sich geändert hat, als was nicht. Und darauf gehen wir ein bisschen ein. Wir sind also auf unserer 11. Generation von Servern. Wir schreiben über jede dieser Iterationen in unserem Blog. Wir bekommen also immer schnellere Computer am Rand, was großartig ist. Es bedeutet niedrigere Kosten, es bedeutet mehr Möglichkeiten, es bedeutet einfach allgemein bessere Dinge für Endbenutzer.

Eines der interessanten Dinge, die sich im Laufe der Zeit geändert haben, ist, dass wir tatsächlich drei verschiedene CPU-Architekturen implementiert haben – oder eigentlich zwei verschiedene CPU-Architekturen, drei Hersteller. Wir betreiben also sowohl Intel als auch AMD und wir führen auch ARM auf unserem Edge aus.

Die andere Sache, die sich im Laufe der Zeit geändert hat, ist, dass wir einfach immer wieder Standorte hinzufügen. Mir ist nicht klar, wie viele wir hatten, als wir vor über 10 Jahren auf den Markt kamen. Es lag im Dutzendbereich. Aber es gibt eine lustige Geschichte von unserem CTO, der ein früher Cloudflare-Fan war, unsere Gründer kannte, sich aber weigerte, Cloudflare beizutreten, bis er einen POP in der Nähe seines Standorts in Europa bekam. Er sagte, wann kommt das? Und dann trete ich bei.

Unsere Standorte wuchsen zunächst aufgrund der Nachfrage. Sie sehen also viel Datenverkehr in einer Region, es ist im Allgemeinen weniger kostspielig, Hardware in einer Region zu platzieren und dort Datenverkehr bereitzustellen. Also haben wir erstmal damit angefangen.

Als wir groß wurden, sahen wir, dass lokale Partner oder ISPs uns baten, Hardware in der Region zu bauen, um die Dinge für sie und ihre Endbenutzer effizienter zu machen. Das war also eine interessante Art von grundlegender Veränderung in der Welt von Cloudflare.

Unser ursprüngliches Ziel war es, innerhalb von 100 Millisekunden bei den Endbenutzern zu sein. Und dann haben wir gemerkt, dass wir es besser machen können. Jetzt haben wir also das 50-Millisekunden-Ziel. Und ich wäre nicht überrascht, wenn Sie sehen, dass das im Laufe der Jahre noch kleiner wird.

Was sich nicht geändert hat, ist, dass wir sehr früh eine für uns einzigartige und ziemlich schicksalhafte Entscheidung getroffen haben, nämlich dass wir dieselbe Software auf jedem Edge-Server an jedem Standort ausführen würden. Dies erwies sich für die meisten unserer Ingenieurteams als einfachere Wahl. Wir wissen, was auf jedem Gerät läuft, und Sie können dort Fehler beheben und die Dinge ein wenig effizienter ausführen. Einige unserer Engineering-Teams haben dadurch auch viel mehr Arbeit.

Es macht die Dinge viel einfacher zu skalieren, sowohl langfristig als auch kurzfristig. Kurzfristig ermöglicht es uns, Ressourcen nach Bedarf je nach Auslastung und dem, was an diesem Ort zu diesem Zeitpunkt passiert, auf verschiedene Dienste zu verschieben. Wir können über jede Maschine hinweg horizontal skalieren.

Langfristig ermöglicht es uns, proaktiv zu entscheiden, wo neue Maschinen eingesetzt werden müssen, weil wir wissen, dass wir den gesamten Stack ausführen müssen. Der andere große Vorteil für unsere Engineering-Teams und insbesondere unsere Produkt-Engineering-Teams besteht darin, dass wir über alle Services hinweg konsistente Leistungen erbringen. Wir machen uns keine Sorgen darüber, dass ein Standort näher an bestimmten Arten von Benutzern liegt und daher schneller ist und ein anderes Erlebnis bietet. Es wird auf allen Servern und auf der ganzen Welt konsistent sein.

Und eine der großen Änderungen, die wir vorgenommen haben – das ist zu diesem Zeitpunkt wahrscheinlich drei Jahre alt – ist, dass wir unseren Kunden jetzt erlauben, ihren Code auf unserem Edge über unser Workers-Produkt auszuführen. Und der nette Vorteil, wenn sich dieser Kunde für den Einsatz seines Produkts entscheidet, wählt er tatsächlich die Region der Welt aus. Wir zwingen sie nicht zu sagen, ich will in den US-Westen kandidieren oder was auch immer. Ihre Software wird an allen Standorten eingesetzt und läuft so nah wie möglich an ihrem Augapfel.

PAVAN TIRUPATI: Großartig. Wie verhält sich also der Rand zum Kern?

SERGI ISASI: Sicher. Es hängt also von Ihrer Architektur ab. Und für einige Architekturen ist der Rand der Kern und der Kern der Rand. Wenn du nur einen Ort hast, machst du quasi alles auf einmal.

Im Allgemeinen wird der Rand jedoch schneller und effizienter für die Berechnung sein, und der Kern ist der Ort, an dem Sie Geheimnisse und Konfigurationen aufbewahren und Daten vom Kern zum Rand übertragen.

PAVAN TIRUPATI: Und hat Cloudflare einen Kern? Und wenn ja, wie wird es umgesetzt?

SERGI ISASI: Vom ersten Tag an, ja. Und wir reden nicht viel darüber. Es ist irgendwie interessant. Aber wenn Sie darüber nachdenken, wir wurden 2009 gegründet, und daher war es 2009 unglaublich unpraktisch, alles am Rande zu betreiben, und in manchen Dingen ist es jetzt unpraktisch.

Was führen wir also im Kern aus? Konfigurationsmanagement – ​​also müssen wir Software herausbringen. und wir müssen es von irgendwo aus tun, also pushen wir immer noch die Cloudflare-Software, alle unsere neuen Versionen, wir pushen unseren Code jeden Tag von unserem Kern zu unserem Edge. Und dann führen wir auch eine Kundenkonfiguration aus, die immer noch mit unseren Kernrechenzentren kommuniziert. Und von dort aus geht es bis zum Rand. Und es ist tatsächlich eine interessante Geschichte hier von WP Engine und unserer DNS-Software.

In den frühen Tagen betrieb Cloudflare also PowerDNS, eine Open-Source-DNS-Software. Und wir haben 2013 damit begonnen, etwas zu entwickeln, das wir intern RR DNS nennen, unsere eigene DNS-Software. Und eine sehr effiziente Software. Wir hatten einige Zonen mit Hunderttausenden von Datensätzen, und alles verlief relativ gut mit diesen Anforderungen. Und dann kam WP und sie sagten, dass wir möglicherweise mehr als eine Million Datensätze in unserer Zone haben. Und die Aktualisierungsgeschwindigkeit, also die Möglichkeit, Änderungen vorzunehmen und diese an unsere Grenzen zu bringen, war unglaublich wichtig, da dies bedeutete, dass ein Kunde an Bord genommen wurde und diese Erfahrung haben musste. Und das war für uns ein echter Grenzfall. Also haben wir uns das angesehen und gesagt, OK, wir müssen natürlich überarbeiten, wie wir unseren Kern verwalten und diesen Datenverkehr an den Rand senden, um sowohl die Größe dieses Inhalts als auch die Geschwindigkeit und Häufigkeit, mit der Sie ihn aktualisieren, zu bewältigen.

Im Jahr 2016 fragte einer unserer DNS-Ingenieure, Tom Arnfeld, ob er sich mit WP Engine zusammensetzen könnte, um tatsächlich zu verstehen, was Sie wollten und warum Sie es wollten und wie es 2017 aussehen würde und wie es in 2017 aussehen würde 2022, jetzt, wo wir fünf Jahre dabei sind. Und so haben wir 2017 tatsächlich die gesamten Datenstrukturen für unsere DNS-Software neu geschrieben, um es auf Wunsch unseres CEOs zu ermöglichen, Daten wie von Zauberhand vom Edge zu verschieben. Und es war tatsächlich eines dieser Dinge, bei denen wir einen Kunden mit einem Bedürfnis hatten, wir wollten dieses Bedürfnis erfüllen, aber wir mussten überdenken, wie wir Daten vom Kern zum Rand verschieben.

Eine andere Sache, die wir immer noch im Kern machen, ist Analytik. Die Telemetrie kommt also von der Kante in den Kern. Wenn unsere Kunden ihre Analysen anzeigen, gehen sie zu einem Dashboard oder einer API, und das alles wird vom Kern aus bedient.

Im Laufe der Zeit haben uns die Kundengröße und die zunehmende Raffinesse der Angriffe dazu veranlasst, unsere Art der Telemetrie zu überdenken. Früher haben wir beispielsweise unsere gesamte DDoS-Erkennungssoftware im Kern ausgeführt. Telemetrie würde also von der Edge kommen, würde der Kern sagen, das sieht aus wie ein DDoS, und es würde Daten zurück an die Edge senden, um sie abzuschwächen. Das reicht für einige DDoS-Angriffe aus, aber für andere müssen wir diese Entscheidung tatsächlich am Edge treffen. Also haben wir unser ursprüngliches Gatebot-System, das den Kern ausführt, Mitte letzten Jahres um ein paar neue Systeme erweitert, die tatsächlich am Rand ausgeführt werden und Entscheidungen unabhängig vom Kern treffen und dann Rückmeldungen geben, um uns sozusagen kontinuierlich an den Angriff anzupassen Oberfläche.

Das Letzte, worüber ich im Kern sprechen werde, ist, dass wir heute den größten Teil unseres maschinellen Lernens im Kern durchführen. Wir stützen uns insbesondere bei Sicherheitsprodukten stark auf maschinelles Lernen. Aber wir wollen mehr davon am Rand tun, weil wir wahrscheinlich ein ähnliches Muster beim DDoS-System sehen. Also haben wir uns mit NVIDIA zusammengetan, um mehr von unserem ML auch am Edge auszuführen.

PAVAN TIRUPATI: Sergi, Sie haben DDoS und Sicherheit erwähnt. Ich möchte ein wenig darauf eingehen, insbesondere weil die Sicherheit sehr kritisch ist. Was sind einige der Trends und Dinge, die Sie sehen?

SERGI ISASI: Sicher, also ein kleiner Rekord von uns, aber DDoS-Angriffe sind rekordverdächtig. Wir brechen diesen Rekord Jahr für Jahr. Der Grund dafür ist, dass die Botnets immer größer werden und leistungsfähigere Geräte nutzen. Wenn Sie also darüber nachdenken, wie viel schneller Ihr Handy jetzt ist oder Ihr Computer im Vergleich zum Vorjahr, macht es nur Sinn, dass sie gerade immer mehr Kapazität bekommen, um sowohl große Angriffe zu starten, also einen erheblichen Durchsatz, den wir abgewehrt haben „2-Terabyte-pro-Sekunde“-Angriff vor einer Weile – es ist der zweitgrößte, von dem wir gehört haben – und dann auch intelligentere Angriffe, die Dinge ohne viel Durchsatz, aber vielleicht viele Anfragen und teure Anfragen erledigen können.

Worüber wir hier wirklich sprechen, ist mehr Raffinesse durch Angriffe. Und die Statistik, die ich für am interessantesten halte, ist etwas, das wir haben

gerade darüber gesprochen wurde, dass 8 % des Datenverkehrs an unserem Rand gemildert werden. Bevor wir irgendwelche Regeln oder ähnliches machen, werden 8 % einfach ganz weggelassen, was bedeutet, dass ein Kunde, der über Security-at-Edge nachdenkt, schnell viele Transaktionen und Interaktionen mit seiner Anwendung loswerden kann die sie einfach nicht wollen oder brauchen, weil es eine Art Angriff ist.

PAVAN TIRUPATI: Ja, und bei WP Engine versuchen wir, Advanced Network, eines unserer Netzwerkangebote, als Standard für alle unsere Kunden einzurichten, damit sie diese zusätzliche Sicherheitsebene nutzen können. Und wir erleben auch ein nie zuvor gesehenes Wachstum mit unserem Sicherheitsangebot GES, das damit verwandt ist – mehr auf die Kunden abgestimmt ist, die nach zusätzlichen Sicherheitsebenen und -ebenen suchen. Und es kommt mit – GES ist etwas, das mit einer Webanwendungs-Firewall und Argo Smart Routing geliefert wird.

Aber eine Sache, die ich hier hervorheben möchte, ist, dass 65 % der WP Engine-Kunden derzeit in keinem dieser Netzwerke sind. Argo Smart Routing und WAF könnten definitiv davon profitieren. Würde es Ihnen etwas ausmachen, ein wenig zu erläutern, wie dieses intelligente Routing und die WAF aus Cloudflare-Perspektive funktionieren.

SERGI ISASI: Sicher. Argo ist also ein sehr interessantes Produkt. Es ist sehr einzigartig für Cloudflare und es ist etwas, das ein wenig umständlich ist, wenn Sie nicht so vertraut damit sind. Also nimmt Argo die Telemetrie, von der ich gesprochen habe, die Edge-Telemetrie, und sucht tatsächlich nach besseren Routen über das Internet. Es gibt ein internes Sprichwort, es ist wie das Waze für das Internet, was meiner Meinung nach irgendwie funktioniert. Es ist nicht meine Lieblingsanalogie, aber es ist eine vernünftige.

Denn manchmal sind Routen ineffizient und es ist nicht konsistent. Heute kann es also schneller sein, direkt zum Ursprung zu gehen, und manchmal ist es das nicht. Manchmal ist es für uns sinnvoller, tatsächlich von einem Cloudflare-Edge zum anderen zu wechseln, um eine gewisse Internetüberlastung zu umgehen.

Der große Vorteil von Argo ist, dass es die Effizienz auf der letzten Meile sowohl vom Benutzer zum Rand als auch vom Rand zum Ursprung – weil Sie heute wahrscheinlich nicht alle Ihre Inhalte vom Rand aus bereitstellen – um 40 % reduziert. Und das ist eine massive Steigerung, da im Grunde nur eine Taste gedrückt wird und keine Codeänderung für die Anwendung erforderlich ist.

PAVAN TIRUPATI: Das ist eigentlich ziemlich aufschlussreich. Danke, Sergi. Welche Veränderungen sehen Sie für Ihren Kundenstamm? Welche praktischen Auswirkungen haben die Zunahme der Angriffe und die tatsächliche Oberfläche der Angriffe?

SERGI ISASI: Ich denke, die große Veränderung im Jahr 2020 und im Jahr 2021 ist, dass wir den Anstieg von Ransomware-Angriffen und einer anderen Art von Ransomware zu sehen begannen, also nicht eine, die den Endpunkt übernahm und verschlüsselte, sondern wir werden angreifen Sie und bringen Sie herunter, wenn Sie uns nicht bezahlen.

Im Jahr 2020 haben wir einige davon gesehen. Im Jahr 2021 sahen wir einen Anstieg, aber eine Änderung des Musters. Und die Musteränderung bestand darin, anstatt allgemein ein Ziel zu finden, ein Ziel in derselben Branche zu finden. Das Interessante ist also, dass wir gesehen haben, dass viele Voiceover-IP- und Telefonkonferenzunternehmen ins Visier genommen wurden. Irgendwie sinnvoll, oder? Da alle mehr aus der Ferne arbeiteten, waren diese Dienste von entscheidender Bedeutung. Und es war sowohl für die Benutzer als auch für die Anbieter wichtig, online zu bleiben, damit der Angreifer dort ein sehr offensichtliches Ziel hatte.

Eine Sache, die immer noch gilt, ist, dass gemeinsame Intelligenz wichtig ist. Während wir sahen, dass jeder einzelne Kunde ins Visier genommen wurde, sahen wir, dass dieselben Muster eingingen und dieselben Angriffsmuster auf diese Anwendungen gingen, was es für jemanden wie uns, der diesen Datenverkehr sieht, einfacher macht – es für uns einfacher macht, ihn zu blockieren.

PAVAN TIRUPATI: Ja, Vorhersagbarkeit oder Muster sind tatsächlich gut, um die Daten zu verstehen, also verstehe ich das. Aber wie und wo sollten die Entwickler bei diesem Aufruf generell über den Schutz nachdenken? Was ist das Worst-Case-Szenario, das Sie in der Vergangenheit gesehen haben und das Sie hier teilen können?

SERGI ISASI: Sicher. Ein Worst-Case-Szenario ist also ein gezielter Angriff. Wenn Sie also wirklich jemand offline nehmen möchte, ist es äußerst schwierig, mit dieser Art von motiviertem Angreifer fertig zu werden. Es ist also etwas zu bedenken, wenn Sie eine Anwendung ausführen, die in irgendeiner Weise umstritten ist oder eine Art Feind haben könnte. Und das ist heutzutage vieles.

Der Angriff, den ich hier habe, ist ein Beispiel dafür, dass Adidas 17,2 Millionen Anfragen pro Sekunde hatte. Das ist also kein Durchsatz, sondern nur eine tatsächliche legitime HTTP-Anfrage. Diese wurden nicht verstärkt oder gefälscht. Dieser Angreifer hatte also Zugriff auf genügend Geräte, die diese Verbindungen herstellen und sie legitim aussehen lassen konnten – oder tatsächlich waren sie legitim. Extrem verteilter Angriff. In einigen Regionen war es zwar in gewisser Weise konzentriert, aber an der überwiegenden Mehrheit unserer Standorte war es zu beobachten.

Und das Worst-Case-Szenario ist, dass die Minderung teuer war. Es wurde auf Layer 7 gemacht. Also mussten wir die Verbindung akzeptieren. Wir mussten SSL terminieren – das sind also eine Reihe von Handshakes, die hin und her gehen – bevor wir den Angriff gegen legitimen Datenverkehr abwehren und identifizieren konnten. Wenn Sie versuchen, dies auf einer lokalen WAF oder ähnlichem auszuführen, wird es also sehr, sehr teuer, nur den Datenverkehr zu finden, geschweige denn, ihn zu mindern.

PAVAN TIRUPATI: Großartig. Danke, Sergi. Bleiben wir bei der Sicherheit: In Kriegszeiten, wie wir sie gerade mit Russland und der Ukraine erleben, ist mit einem Anstieg von Cyberangriffen zu rechnen. Tatsächlich haben CIA und FBI eine gemeinsame Empfehlung über die zerstörerische Natur dieser Angriffe herausgegeben und darüber, wie anfällig kritische Vermögenswerte und Daten in diesen Zeiten sein können. Sie empfehlen allen Organisationen, unabhängig von ihrer Größe, eine erhöhte Sicherheitshaltung einzunehmen. Und bei WP sehen wir diesen Aufwärtstrend auch bei Angriffen.

Wie schätzen Sie die Bereitschaft für solche Veranstaltungen ein? Und wie können wir uns auf solche Situationen vorbereiten? Einige der anderen großen Ereignisse neben dem Russland-Ukraine-Krieg, die mir in den Sinn kommen, sind das Log4shell-Ereignis, das wir letztes Jahr miterlebt haben und das sich auf ziemlich viele Anwendungen auf der ganzen Welt ausgewirkt hat.

SERGI ISASI: Ja, ich meine, wir müssen reagieren. Das ist die Welt, in der wir uns befinden. Dinge passieren, und wirklich, wirklich schreckliche Dinge passieren, und wir müssen darauf reagieren. Was die Ukraine angeht, können wir nicht viele Informationen teilen, aber eines der Dinge, die wir teilen können, ist, dass der Datenverkehr in der Ukraine aus der Sicht der Benutzer insgesamt relativ konstant geblieben ist, wir jedoch einen erheblichen Anstieg der Firewall-Minderungen erlebt haben.

Es ist also von den typischen 8 %, über die wir zuvor gesprochen haben, auf bis zu 30 % aller Anfragen gestiegen. Das bedeutet also, dass sich einfach mehr Angriffsverkehr mit dem normalen Benutzerverkehr vermischt. Und wieder, genau wie im vorherigen Beispiel, sind dies teure Gegenmaßnahmen, Dinge, die auf Layer 7 erledigt werden müssen, weil es schwierig ist, sie von regulären Angriffen zu unterscheiden, die nur auf Layer 4 basieren.

Wir sprechen über Log4shell, das war wahrscheinlich das größte Event, an das ich mich seit langem erinnern kann. Das hat die Branche also ziemlich hart getroffen. Ich erinnere mich, dass viele Personen, beide bei Cloudflare, die interne Diskussion gelesen haben, und ich erinnere mich, dass ich einfach gesagt habe, oh, oh Gott, das ist gewaltig.

Und es war eine Schwachstelle und ein sehr verbreitetes Stück Software, das es dem Angreifer ermöglichte, einige willkürliche Zeichen einzufügen, und dann würde das Vorhandensein dieser Zeichen dazu führen, dass die Software eine Git-Anforderung für eine URL ausgibt, die der Angreifer eingefügt hat. Also haben alle geschwärmt. Möglicherweise kennen Sie Ihre Abhängigkeiten nicht. Das ist eine Art Lektion eins: Kennen Sie Ihre Abhängigkeiten, wissen Sie, welche Software Sie ausführen und welche Software diese Software ausführt.

Aber das Wichtigste war, dass es hier viele wirklich clevere Exploits gab. Als wir dies für unsere Kunden – und für Ihre Kunden – milderten, hatten wir viele verschiedene Variationen unserer Firewall-Regeln, die immer wieder bereitgestellt werden mussten, weil Inhalte vorhanden waren und Sie diese Inhalte auf unterschiedliche Weise codieren können.

Eines der Dinge, die ich für das Interessanteste an Log4j hielt, war, dass wir es in der Protokollierungspipeline gesehen haben. Selbst wenn Sie also dachten, Ihre Anwendung sei so durch eine Firewall geschützt, dass sie keine Verbindung von der Außenwelt erhalten würde, würde sie, wenn Sie ein Protokollereignis abrufen, das diese Zeichen enthält, trotzdem diese Anfrage stellen. Eine einfache Firewall war also nicht genug.

Edge ist hier wichtig und sehr hilfreich, da Sie damit eine schnelle und einfache Möglichkeit haben, Kontrollen einzuleiten, unabhängig davon, ob Sie sicher sind, ob Sie anfällig sind oder nicht. Die Einführung der Kontrollen hat keine Nachteile, was ein weiterer Grund dafür ist, dass wir sie sogar für unsere kostenlosen Kunden eingeführt haben. Der einzige Kontrollpunkt ist also in diesem Szenario wirklich sehr hilfreich.

PAVAN TIRUPATI: Und welche Tools oder Techniken stehen Kunden zur Verfügung, um den Datenverkehr in diesem Szenario zu skalieren?

SERGI ISASI: Sicher, also haben wir für jedes Szenario Arbeiter bei Cloudflare. Auf diese Weise können Sie Ihren Code auf unserem Edge ausführen und erstellen, was Sie wollen, ohne sich Gedanken über die horizontale Skalierung machen zu müssen.

Außerdem haben wir Anfang 2021 ein Produkt namens Waiting Room eingeführt. Wartezimmer ist etwas, mit dem Sie wahrscheinlich vertraut sind. Du wolltest etwas kaufen und wurdest in eine Warteschlange gestellt, um zu entscheiden, ob es genug von dem Ding zum Kaufen gibt. Es kann auch für eine Anwendung funktionieren. Können Sie sich mit der Website verbinden und eine gute Erfahrung machen? Oder solltest du warten?

Das ist eigentlich ein wirklich interessantes Produkt, das wir gebaut haben. Wir haben es am Rand gebaut und Cloudflare-Worker verwendet. Und das war schwierig. Es ist wahrscheinlich ein einfacheres Produkt, um im Kern zu bauen. Das ist nicht die DNA von Cloudflare. Wir können Dinge hochkant bauen, und wir haben wirklich nach Skalierung gesucht. Wenn Sie versuchen, etwas im Kern zu skalieren, wird es viel schwieriger.

Das große Problem, das wir hatten, als wir den Warteraum bauten, war der gemeinsame Zustand. Sie wollten also, dass Benutzer weltweit ein einziges Wartezimmererlebnis haben. Und wir sprachen von über 200 Standorten. Das ist nicht einfach.

Also gebe ich Ihnen ein Beispiel. Nehmen wir an, es gibt ein Konzert hier in der Bay Area. Die meisten Käufer für dieses Konzert werden in der Bay Area sein und sich wahrscheinlich mit unserem Rechenzentrum in San Jose verbinden. Einige sind es jedoch nicht. Sie werden eine Handvoll oder einen gewissen Prozentsatz von Käufern haben, die weltweit zu dem Konzert einfliegen oder vielleicht zu dieser Zeit reisen.

Wie macht man es also fair? Sie können keine Warteschlange für Benutzer in der Bay Area haben und eine Warteschlange für Benutzer befindet sich an jedem anderen Standort. Das erforderte, dass wir darüber nachdachten, wie wir den Zustand über den Rand hinweg teilen können. Und ich denke, das ist der Punkt, an dem die Zukunft nach vorne strebt.

Und wir verwenden unser eigenes Durable Objects-Produkt – Sie können es hier auf der Folie sehen – um den Zustand an allen Standorten zu synchronisieren und zu teilen. Aber da wir als Branche versuchen, mehr dieser Probleme am Rand zu lösen, werden Sie meiner Meinung nach viel mehr Anwendungsfälle von Software am Rand sehen, wo das Teilen von Zuständen immer noch schwierig ist, und was tun Sie? über Konsistenz, ob das irgendwie schlussendlich oder sofort ist? Und ich denke, das ist die Zukunft unserer Software.

PAVAN TIRUPATI: Großartig. Danke, Sergi. Ich weiß, dass wir bei WP Engine diese Edge-First-Mentalität haben, um sicherzustellen, dass wir unseren Kunden Leistung und Sicherheit bieten. Sergi, was sind Ihre abschließenden Gedanken oder Ratschläge oder wichtigsten Überlegungen oder Vorschläge für die Entwickler bei der Telefonkonferenz, die am Edge bauen?

SERGI ISASI: Also ich denke erstmal, dass du am richtigen Ort baust. Und zweitens denke ich, dass es darum geht, kreativ zu sein. Wenn Sie mich vor einem Jahr gefragt hätten, ob wir sie am Rande machen könnten, hätte ich gesagt, äh, ich weiß nicht. Ich glaube nicht. Und es gibt einfach ein schnelleres Innovationstempo, das Sie hier finden, und viele kreative Entwickler, die über die Probleme nachdenken, an die Sie denken, und Lösungen sowohl auf der Kunden- als auch auf der Produktseite finden.

Eine andere interessante Sache ist die Art zu kommunizieren und zu teilen. Wir haben viel Bewegung gesehen, insbesondere in Entwickler-Discords, neue, kreative Wege zu finden, um Probleme zu lösen und mehr Dinge am Rand zu bauen. Ich denke, schließlich, als Plug-in für Cloudflare, wenn Sie etwas nicht tun können, finden Sie einen Cloudflare-Produktmanager. Senden Sie uns eine E-Mail, finden Sie uns auf Twitter oder was auch immer, und teilen Sie uns mit, was Sie bauen möchten, und wir werden sehen, ob wir Ihnen beim Bauen nicht helfen können.

PAVAN TIRUPATI: Das ist großartig. Und ich denke, es ist fair zu sagen, dass Edge kein Edge-Fall mehr ist, denn wenn Sicherheit und Leistung Ihr Fokus sind, dann ist Edge der richtige Ort.

Also danke, Sergi, für diese großartigen Worte über Edge. Ich hoffe, Sie fanden diese Sitzung nützlich. Vielen Dank, dass Sie sich die Zeit nehmen und sich uns anschließen. Ich hoffe, Sie haben einen guten Rest des Tages.

MODERATOR: Und das ist ein Abschluss für DE{CODE} 2022. Ich hoffe, Sie fanden es inspirierend und verlassen es mit mehr WordPress-Expertise und neuen Community-Verbindungen. Halten Sie ab Freitag Ausschau nach den aufgezeichneten Inhalten auf der Website, um alles nachzuholen, was Sie möglicherweise verpasst haben, oder sehen Sie sich ein Video erneut an.

Ich möchte mich abschließend bei unseren Sponsorpartnern bedanken – Amsive Digital, Box UK, Candyspace, Draw, Elementary Digital, Illustrate Digital, Kanopi Studios, Springbox, Studio Malt, StrategiQ, WebDev Studios und 10Up. Ein riesiges Dankeschön für Ihre Spende an unsere DECODE-Spendenaktion. Wir schätzen Ihre Großzügigkeit sehr.

Jetzt werden wir für alle, die mit uns in unserem Teilnehmerzentrum und unseren Sitzungen interagiert haben, die drei besten Gewinner auswählen und Sie am Ende von DE{COD}E darüber informieren, wie Sie Ihren Preis einfordern können. Wir freuen uns darauf, Sie bei unseren zukünftigen Veranstaltungen wiederzusehen, entweder persönlich oder virtuell. Wir können es kaum erwarten, Ihnen mehr über die neuesten WordPress-Entwicklungstrends zu erzählen und wie Sie diese implementieren können, um WordPress-Sites schneller zu erstellen. Das ist alles von mir. Vielen Dank, dass Sie sich uns angeschlossen haben und passen Sie auf sich auf.