Zurück 
Mitautoren: Jeff Brainard und Jason Hofmann
In mehr als einem Gespräch mit großen Unternehmenskunden haben wir gehört, dass die Netzwerk- und Infrastrukturleiter, die für die Verwaltung des globalen WAN des Unternehmens verantwortlich sind, sich selbst scherzhaft als „Chief Hairpinning Officer“ oder CHO bezeichnen. Auf den ersten Blick sorgt dies für einen Lacher. Doch an dieser Aussage ist durchaus einiges dran, wenn man bedenkt, wie viel Zeit, Energie und Budget Netzwerkexperten traditionell für die Verwaltung komplexer Entscheidungen zum Netzwerkrouting aufwenden. Diese Entscheidungen waren von entscheidender Bedeutung für die Verbindung verschiedener Unternehmensstandorte und Niederlassungen mit dem Rechenzentrum. Gleichzeitig mussten wir mit mehreren Internetdienstanbietern zusammenarbeiten, um einen schnellen, zuverlässigen Zugriff für ihre Benutzer sowie eine reaktionsschnelle Anwendungserfahrung sicherzustellen. Schwierig wurde es in den letzten Jahren, diese Netzwerkziele mit den wachsenden Sicherheitsanforderungen der Unternehmen in Einklang zu bringen. Durch die Migration von Anwendungen und Daten in die Cloud und zu SaaS, die zunehmend komplexeren Angriffe und die in jüngster Zeit explosionsartig gestiegene Zahl von Remote-Arbeitsplätzen hat sich das Problem nur noch verschärft.
Was ist Hairpinning?
Die meisten Unternehmen nutzen heute eine Architektur, die stark auf "Hairpinning" oder dem basiert, was gemeinhin auch als Traffic-Backhauling bezeichnet wird. In einem Netzwerkkontext bezieht sich Hairpinning auf die Art und Weise, wie ein Paket zu einer Schnittstelle gelangt, in Richtung Internet geht, aber anstatt weiterzugehen, eine "Haarnadelkurve" macht – denken Sie nur an das alltägliche Instrument , das verwendet wird, um die Haare einer Person an Ort und Stelle zu halten – und auf derselben Schnittstelle wieder eintrifft. Das klassische Szenario ist die Filiale, in der kein Datenverkehr ein- oder ausgehen soll, ohne vorher einer Sicherheitsüberprüfung unterzogen zu werden. Die Bereitstellung eines eigenständigen Sicherheitsstacks in jeder Zweigstelle, in Dutzenden oder sogar Hunderten von Zweigstellen auf der ganzen Welt, könnte eine praktikable Strategie sein, aber aus Sicht der Kosten, der Komplexität und des Verwaltungsaufwands wäre es ein Albtraum.
Stattdessen besteht der bevorzugte Ansatz darin, alle Client-Anfragen an das Internet von der Filiale zurück an einen zentralen Standort wie das Rechenzentrum zu senden (oder zu bündeln), wo die Sicherheitsmaßnahmen durchgeführt werden, und den Datenverkehr erst dann – nach dem Scannen – an das Internet weiterzuleiten. Das Gleiche gilt, unabhängig davon, ob Sie Webinhalte anfordern oder mit einer geschäftskritischen SaaS-App interagieren. Bei der Serverantwort muss der Datenverkehr dann demselben Umweg zurück durch das Rechenzentrum zur Zweigstelle und schließlich zum Desktop des Benutzers folgen. Man muss kein Netzwerkingenieur sein, um zu erkennen, dass dieser Ansatz das Benutzererlebnis beeinträchtigt, Latenzen hinzufügt und die Dinge deutlich verlangsamt. Wenn man das Benutzererlebnis und letztlich die Geschäftsproduktivität außer Acht lässt, bedeutet dieser Ansatz auch eine größere Belastung für die teuren und schwer zu wartenden privaten WAN-Verbindungen, wie etwa MPLS-Verbindungen, auf die sich Unternehmen seit langem verlassen, um ihre verteilten Unternehmen miteinander zu verbinden.
Die Entwicklung von Hairpinning zu WAN/SD-WAN
Angesichts der unbestreitbaren Verlagerung von Anwendungen und Daten in die Cloud und des wachsenden Volumens und der Kritikalität dieses Datenverkehrs besteht einer der großen Vorteile des Cloud-Sicherheitsmodells darin, Haarnadeln zu eliminieren und das Netzwerkdesign drastisch zu vereinfachen. Es ist auch einer der Haupttreiber für den boomenden SD-WAN-Markt und der Anstoß für groß angelegte Netzwerktransformationsprojekte. Dies wurde in einem anderen kürzlich erschienenen Blog mit dem Titel "How Netskope NewEdge Takes SD-WAN to the Next Level" behandelt. Die Schlussfolgerung, die man daraus ziehen kann, ist, dass Netzwerkprofis es vorziehen würden, Haarnadeln zu vermeiden, und dass es in Zukunft zunehmend darum gehen wird, ihren Datenverkehr mit einem Cloud-First-Sicherheitsansatz direkt ins Netz zu senden. Warum sollte sich ein Kunde also für eine Cloud-Sicherheitslösung entscheiden, die auf einer Netzwerkarchitektur basiert, die sich auf eine Hairpinning-Netzwerkarchitektur stützt?
Leider beobachten wir auf dem Markt immer wieder, dass die Architektur ihrer Clouds bei fast allen Cloud-Sicherheitsanbietern völlig falsch ist. Im Wesentlichen stellt man fest, dass sie die dem traditionellen WAN-Design von Unternehmen innewohnenden Fehler wiederholen und diese in einem Cloud-Formfaktor replizieren. Das klassische Beispiel hierfür ist der virtuelle Point of Presence (oder vPOP), ein Ansatz, der bekanntermaßen von Anbietern wie Broadcom/Symantec, Palo Alto, Forcepoint, McAfee und anderen verwendet wird. (Vertrauen Sie mir nicht, schauen Sie einfach auf deren Websites nach und suchen Sie nach Ausdrücken wie „Physical Location of Security Compute“ oder dem Begriff „vPOP“.) vPOPs liefern nicht nur eine irreführende Ansicht hinsichtlich der Abdeckung, sie geben auch Aufschluss darüber, wo innerhalb des Netzwerks des Cloud-Sicherheitsanbieters die Datenverkehrsverarbeitung stattfindet.
Auf der einfachsten Ebene stellen vPOPs einen Ein- und Ausgangspunkt für den Datenverkehr dar. Ein in einem früheren Blog mit dem Titel „ Um die Abdeckung zu verstehen, muss man nicht nur die Anzahl der Rechenzentren zählen“ erörtertes Beispiel zeigte ein Szenario mit einem Remote-Benutzer in Kenia. Dieser Benutzer müsste eine Verbindung zu einem vPOP in Johannesburg (Südafrika) herstellen, seinen Datenverkehr zur Verarbeitung nach Frankfurt (Deutschland) und dann zurück nach Johannesburg senden lassen, bevor die Anforderung des Benutzers an das Internet und die Web-, Cloud- oder SaaS-App gesendet wird, auf die er zugreifen möchte. Stellen Sie sich nur die Latenz vor, die durch dieses Hin und Her des Datenverkehrs entsteht, der über riesige Entfernungen und mehrere Netzwerke hinweg geleitet wird und das Benutzererlebnis letztlich auf ein Minimum reduziert. Das Problem besteht darin, dass es sich bei vPOPs im wahrsten Sinne des Wortes um eine erneute Verkehrsspirale mit denselben Auswirkungen auf Komplexität, Latenz und möglicherweise Kosten handelt.
Und wenn Anbieter auf öffentliche Cloud-Infrastrukturen wie AWS, Azure oder GCP angewiesen sind, verlassen sie sich entweder auf die Edge-Rechenzentren der öffentlichen Cloud-Anbieter, um regionale Ausgangspunkte für den Datenverkehr bereitzustellen (Palo Alto). Oder noch schlimmer, und das kommt weitaus häufiger vor, sie nutzen das Backhaul über das überlastete und unvorhersehbare öffentliche Internet und verwenden zur Implementierung ihrer vPOPs (alle anderen) eine „Telefonbank“ aus Ausgangs-IPs, die jeweils in einem anderen Land registriert sind. Dasselbe Problem tritt immer wieder auf: Der Datenverkehr muss über enorme Entfernungen geleitet und zwischen mehreren Standorten hin- und hergeschickt werden, bevor er schließlich die wenigen (oft weniger als 30) einzigartigen Standorte auf der Welt erreicht, an denen sich die Rechenressourcen befinden und die Verarbeitung des Sicherheitsdatenverkehrs stattfinden kann. Kunden glauben, dass sie sich eine Cloud-Strategie zunutze machen, um direkt auf das Netz zuzugreifen und die wichtigen Sicherheitsvorkehrungen zu nutzen, die sie benötigen. Tatsächlich jedoch bekommen sie dieselben alten Netzwerkprobleme der Vergangenheit, nur neu implementiert in der Cloud. Dies ist das schmutzige Geheimnis der meisten Cloud-Sicherheitsanbieter.
Die Leistungsfähigkeit von NewEdge
Ein weiteres Horrorbeispiel für Hairpinning innerhalb des Netzwerks eines namhaften Cloud-Sicherheitsanbieters ereignete sich kürzlich bei einem Kunden, mit dem wir in Lateinamerika (LATAM) zusammengearbeitet haben. Während der Anbieter mit vier Rechenzentren in Lateinamerika wirbt, verfügt er tatsächlich über drei vPOPs und eine öffentliche Cloud-Region in Lateinamerika – nämlich vPOPs in Chile, Argentinien und Kolumbien sowie VMs, die in GCP Brasilien laufen. Während Benutzer in Brasilien von GCP Brasilien aus bedient wurden, wurden alle anderen Länder in Lateinamerika von den USA aus bedient. Der LATAM-Verkehr musste zur Verarbeitung und Durchsetzung der Sicherheitsrichtlinien in die USA zurückgeleitet werden. Der Ansatz dieses Anbieters war nicht nur hinsichtlich der Abdeckung enorm irreführend – es scheint, als ob er nur über ein LATAM-Rechenzentrum verfügt und nicht über vier! –, sondern dieser auf Haarnadelkurven basierende Ansatz führte auch zu Latenzen von Hunderten von Millisekunden. Schlimmer noch: Der Kunde musste aufgrund der hohen Latenz einen verringerten Gesamtdurchsatz (weil der Durchsatz bei TCP umgekehrt proportional zur Latenz ist), erhöhte Fehlerraten und Paketverluste sowie eine insgesamt geringere Zuverlässigkeit feststellen. Bis er mit Netskope sprach und erfuhr, wie wir NewEdge konzipiert haben, war dieser Kunde unentschlossen, ob er Cloud-Sicherheit einführen sollte, und stand kurz davor, seine vorhandenen physischen Geräte und die hässliche MPLS-WAN-Architektur zu verdoppeln.
Viele Anbieter behaupten, dass vPOPs die einzige Möglichkeit seien, ein nahtloses Benutzererlebnis zu bieten, sodass Benutzer beispielsweise ihre Google-Suchergebnisse oder Anzeigen passend für ihren jeweiligen Standort oder ihre Region lokalisiert erhalten. Die Realität sieht so aus, dass jeder Anbieter, der sich bei der Bereitstellung eines Cloud-Sicherheitsdienstes auf die öffentliche Cloud statt auf seine eigenen Rechenzentren verlässt, auf die Städte und Regionen beschränkt ist, in denen sein Cloud-Anbieter Compute-Dienste (VM) anbietet. Daher bleibt ihm keine andere Wahl, als Backhauling durchzuführen und vPOPs zu verwenden, um zu versuchen, die Wahrscheinlichkeit zu verringern, dass das Backhauling nicht zu Inhaltslokalisierung, Geoblocking oder anderen Problemen führt, die sich aus der Weiterleitung in eine weit entfernte Region ergeben.
Wir haben diesen Punkt in anderen Blogbeiträgen immer wieder betont, aber der Ansatz, den Netskope mit NewEdge verfolgt, ist wirklich anders und deshalb haben wir mehr als 100 Millionen US-Dollar investiert, um die weltweit größte und leistungsstärkste private Sicherheits-Cloud aufzubauen. NewEdge verwendet ein Direct-to-Net-Modell, um den Verkehrspfad zu optimieren und sich auf die Netzwerkvereinfachung zu konzentrieren, während gleichzeitig eine höhere Zuverlässigkeit und Belastbarkeit erreicht wird. Wir sind nicht auf vPOPs oder die öffentliche Cloud angewiesen, daher ist unsere Leistung besser und vorhersehbarer. Und jedes unserer Rechenzentren ist mit allen Computerfunktionen ausgestattet und bietet Zugriff auf sämtliche Netskope Security Cloud Services. All dies gewährleistet den schnellsten Zugriff mit der geringsten Latenz für Benutzer, unabhängig davon, ob sie von einem Café in Mailand, einer Zweigstelle in Hongkong oder der Firmenzentrale in New York City kommen. Darüber hinaus verschafft die hohe Vernetzung von NewEdge mit umfassendem Peering mit den für Kunden wichtigsten Web-, Cloud- und SaaS-Anbietern den Kunden von NewEdge und Netskope einen echten Vorteil. Es ist an der Zeit, dass sich die Kunden über das schmutzige kleine Geheimnis der Netzwerke der meisten Cloud-Sicherheitsanbieter informieren und sicherstellen, dass sie bei der Auswahl ihrer Cloud-Sicherheitsdienste nicht die Fehler der Vergangenheit, wie etwa das Hairpinning, wiederholen.
Um mehr über Netskope und NewEdge zu erfahren, besuchen Sie bitte: https://www.netskope.com/netskope-one/newedge
Den Blog lesen