Vielleicht haben Sie im Zusammenhang mit der Netzwerksicherheit im Allgemeinen und SASE im Besonderen schon von den Prinzipien der Mehrfacharchitektur gehört. Einige von der Industrie im SASE-Kontext verwendete Software-Architekturprinzipien sind:

  • Single-Pass-Architektur
  • Ein-Proxy-Architektur
  • Run-to-Completion Architektur
  • Skalierbare Architektur
  • Parallelverarbeitung in einem Durchgang Architektur
  • Bringen Sie Ihre eigene Sicherheitsfunktion mit Architektur
  • Cloud-native Architektur
  • Isolationsarchitektur
  • API first Architektur
  • Slicing (E2E-Segmentierung) Architektur

Viele der oben genannten Architekturprinzipien sind nicht neu. Die Architekturprinzipien Single-Pass, One-Proxy, Single-Pass-Parallel-Processing und Run-to-Completion sind seit den UTM-Tagen (Unified Threat Management) in den frühen 2000er Jahren beliebt, auch wenn sie vorher unter anderen Namen bekannt waren. Der Hauptzweck dieser architektonischen Prinzipien ist es, Folgendes zu erreichen

  • Höherer Durchsatz bei effizienter Nutzung der Ressourcen.
  • Geringere Ende-zu-Ende-Latenz
  • Niedrigerer Jitter
  • Höhere Elastizität (Scale-out) und Ausfallsicherheit auch bei DDoS-Angriffen auf Sicherheitsdienste
  • Schnellere Einführung von neuen Sicherheitsfunktionen (Agilität)
  • Integration von Sicherheitsfunktionen mehrerer Anbieter, ohne Ineffizienzen zu verursachen (Integration der besten Technologien)
  • Adoptierbarkeit (Überall ausführen)
  • Einscheibenglas

Entwicklung

Eine großartige Sache an der Netzwerksicherheitsbranche ist, dass sie dynamisch ist. In jeder neuen Produktgeneration werden neuere Prinzipien der Software- und Einsatzarchitektur übernommen. Außerdem bleibt der Schutz gegen die Raffinesse der Angreifer erhalten. Allerdings ist der Markt für Netzwerksicherheit traditionell fragmentiert. Es gibt mehrere Sicherheitsanbieter, die unterschiedliche Sicherheitsfunktionen anbieten. Das ist aus Sicht der Innovation gut und muss gefördert werden und soll weitergehen. Es ist zu beachten, dass ein Anbieter möglicherweise nicht alle Sicherheitsfunktionen beherrscht. Wenn jeder Anbieter einen kompletten Stack für seine Sicherheitsfunktionen anbietet, führt dies zu enormen Ineffizienzen und damit zu enormen Kosten. Außerdem kann sich die Latenzzeit erhöhen, was für einige Anwendungen eine Herausforderung darstellen könnte. Daher die Anwendbarkeit von neueren Architekturprinzipien und bewährten Verfahren. Die Software-Architektur muss so gestaltet sein, dass Ineffizienzen vermieden werden, aber die Integration von Technologien verschiedener Anbieter für die beste Cybersicherheit möglich ist.

Vor der Konvergenz

Abbildung 1 und Abbildung 2 sind zwei repräsentative Beispiele für die Netzwerksicherheit vor SASE. Abbildung 1 zeigt den sicheren Internetzugang, und Abbildung 2 zeigt ein Beispiel für den sicheren privaten Zugang. Beachten Sie, dass die Reihenfolge der Sicherheitsfunktionen in diesen Bildern willkürlich ist und die Reihenfolge der Ausführung normalerweise einsatzspezifisch ist. Ein sicherer Internetzugang wird traditionell durch mehrere Sicherheitslösungen erreicht, die in Abbildung
1. Es ist das Unternehmen, das diese Sicherheitsfunktionen kauft und sie in eine Servicekette einbindet. Da viele Sicherheitsfunktionen ein Proxying der Verbindungen erfordern, wird diese Verkettung in der Branche auch als Proxy Chaining bezeichnet. Da jede einzelne Sicherheitslösung autark ist und von mehreren Anbietern stammt, wiederholen sich die gemeinsamen Funktionen in diesen Lösungen. Zu den allgemeinen Funktionen gehören Traffic Policing am Eingang, Traffic Shaping am Ausgang, Traffic Filtering, um sicherzustellen, dass nur relevanter Datenverkehr an die Proxies weitergeleitet wird, TCP-Terminierung der Client-Verbindung, neue TCP-Verbindung zum Ziel, SSL/TLS-Abhörung (die ihrerseits eine On-Demand-Zertifikatsgenerierung erfordert, die das Zielzertifikat emuliert), einschließlich TLS-Entschlüsselung & TLS-Verschlüsselung, Proxy-Authentifizierung (Kerberos, NTLM, OIDC), HTTP 1.1/2.0-Entschlüsselung. Diese gemeinsame Funktionalität in jeder Box/virtuellen Appliance beansprucht nach einer Schätzung 50% der CPU-Ressourcen der gesamten Sicherheitslösung. Der sichere Anwendungszugang wird auf ähnliche Weise durch die Verkettung der diskreten Sicherheitslösung erreicht, wie in Abbildung
2. Auch hier ist die gemeinsame Funktionalität bei mehreren Sicherheitslösungen die gleiche. Es handelt sich fast um die gleiche Funktionalität wie bei den Sicherheitslösungen, die in Secure Internet Access verwendet werden. Zu den Unterschieden gehören die Beendigung von SSL/TLS anstelle des Abfangens und die Benutzerauthentifizierung über herkömmliche Methoden anstelle der Proxy-Authentifizierung. Der durchschnittliche Overhead für gemeinsame Funktionen in einer Sicherheitslösung kann bis zu 50 % der Gesamtlösung ausmachen. Die Latenzzeit kann bei dieser Architektur aufgrund der Verkettung von Funktionen um einige Millisekunden ansteigen. Eine weitere große Herausforderung für Unternehmen mit physischen und virtuellen Appliances ist die Skalierung. Ursprünglich wurde die Skalierung durch den Einsatz größerer Appliances oder die Zuweisung von mehr CPU- und Speicherressourcen für die VM-basierten Sicherheitslösungen erreicht. Dies wird als Scale-up bezeichnet. Wenn der Datenverkehr ein konstantes Volumen aufweist, ist es für Unternehmen sinnvoll, Geld für größere physische/virtuelle Appliances auszugeben. Aber wenn der Verkehr sehr stark ist, sehen Unternehmen es nicht gerne, wenn Geld verschwendet wird. Denken Sie an Fälle, in denen nur an wenigen Tagen im Jahr der Verkehr höher ist. Warum sollte ein Unternehmen das ganze Jahr über Geld für diese Beulen ausgeben wollen? Das führte zur nächsten Entwicklung, bei der die Sicherheitsanbieter begannen, eine Scale-Out-Architektur über einen Cloud-Service zu unterstützen. Dies entspricht der Argumentation für IaaS in der Welt der Cloud-Anwendungen. In einer Scale-Out-Architektur werden automatisch mehr Instanzen der Sicherheitslösungen hochgefahren, wenn ein höherer Datenverkehr oder ein DDoS-Angriff festgestellt wird, und wieder heruntergefahren, wenn die Nachfrage sinkt. Abbildung 3 zeigt diese Scale-Out-Architektur. Es besteht kein Zweifel, dass eine Scale-Out-Funktionalität erforderlich ist. Es benötigt jedoch einen Load Balancer für jede Sicherheitslösung. Dieser Load Balancer wird benötigt, um die Last der Sitzungen auf mehrere Instanzen der Sicherheitslösung zu verteilen. Mehrere Load Balancer Traversals erfordern mehr Ressourcen und erhöhen die End-to-End-Latenz von Verkehrssitzungen. Die nächste Evolution der Netzwerksicherheitsarchitektur befasst sich mit den Herausforderungen von

  • Bedarf an einer höheren Anzahl von Rechenressourcen
  • Höhere Latenz

Mit

  • Eine Proxy-Architektur
  • Single-Pass-Architektur

Single-Pass- und One-Proxy-Architektur (Konvergierte Architektur)

Wie in Abbildung 4 unten zu sehen ist, sind alle Sicherheitsfunktionen gebündelt, wobei der Proxy und andere allgemeine Funktionen nur einmal ins Spiel kommen. Alle Sicherheitsfunktionen werden einzeln nacheinander aufgerufen, so dass sie vollständig ausgeführt werden können. Daher verbraucht diese Architektur die Rechenressourcen effizient. Da alle Funktionen im gleichen User-Space-Kontext aufgerufen werden, werden Speicherkopien vermieden. Außerdem reduziert die Architektur mit nur einem Benutzerraumprozess die Anzahl der Kontextwechsel des Betriebssystems erheblich. Eine einzelne Proxy-Instanz kann über Multi-Threading mehrere Sitzungen gleichzeitig verarbeiten, wobei jeder Thread eine Teilmenge von Sitzungen verarbeitet und so Multi-Core-CPUs effektiv nutzt. Durch die Multi-Threading-Fähigkeit können außerdem einige Sicherheitsfunktionen parallel statt seriell für eine bestimmte Verkehrssitzung ausgeführt werden, wodurch sich die Latenzzeit verbessert. Diese Architektur wird ‚Single Pass Parallel Processing‘ genannt. Um unerwartete Last zu bewältigen und DDoS-Szenarien anzugehen, wird eine Auto-Scale-Out-Architektur eingesetzt, bei der eine Load-Balancer-Instanz für den Lastausgleich der Sitzungen sorgt. In dieser Architektur stellt der Proxy eine Schnittstellen-API zur Verfügung. Alle Sicherheitsfunktionen greifen auf diese API zu. Der Proxy ruft während der Verarbeitung von Verkehrssitzungen die entsprechenden gehakten Sicherheitsfunktionen auf. Nicht alle Sicherheitsfunktionen können von den Entwicklern von SASE-Lösungen implementiert werden. Die Entwickler von SASE-Lösungen arbeiten mit Technologieanbietern zusammen, indem sie die Engines und Feeds der Technologieanbieter in die Proxys integrieren. Auf diese Weise erhalten die Kunden von SASE-Anbietern das Beste aus beiden Welten – eine hochleistungsfähige SASE mit den besten Sicherheitsimplementierungen. Allerdings liefern einige Technologieanbieter möglicherweise keine Engine in Form eines SDKs für die Entwicklung von Sicherheitsfunktionen als Teil des Proxys. Es kann sein, dass sie es als Cloud-Service anbieten. DLP ist ein Beispiel dafür, dass viele Technologieanbieter dies als Cloud-Service anbieten. In einigen Fällen kann es auch sein, dass der Anbieter der SASE-Lösung einige Sicherheitsfunktionen nicht in denselben User-Space-Prozesskontext des Proxys integrieren möchte, z.B. aus Gründen der Speicherbeschränkung, zur Vermeidung von Lizenzinkompatibilität, um den User-Space nicht anfällig zu machen und andere.

Einheitliche Architektur & Bring Your Own Security Funktionen

Die nächste Entwicklung in der SASE-Architektur ist unten dargestellt. Die drei wichtigsten Punkte sind in Abbildung 6 unten dargestellt. Unterstützung für Sicherheitsdienste über ICAP (Internet Content Adaptation Protocol): Unternehmen sind möglicherweise an Sicherheitsdienste anderer Anbieter gewöhnt oder möchten diese nutzen. Die ICAP-Spezifikationen der IETF legen fest, wie Proxys mit externen Inhaltsanpassungsdiensten, einschließlich Sicherheitsdiensten, kommunizieren können.
Indem sie externe Sicherheitsdienste zulassen, ermöglichen die Anbieter von SASE-Lösungen den Unternehmen, die Sicherheitsdienste ihrer Wahl zu nutzen. Bringen Sie Ihre eigenen Sicherheitsfunktionen mit: Laut dem IBM-Sicherheitsbericht „Cost of a Data Breach Report 2022“ benötigen Unternehmen im Durchschnitt 277 Tage, um eine Datenschutzverletzung zu entdecken und einzudämmen. Obwohl SASE eine sehr gute Richtlinienkonfiguration bietet, könnte es sein, dass die Eindämmung von Datenschutzverletzungen programmatische Regeln erfordert. Unternehmen, die die Datenpanne analysieren, sind in einer guten Position, um diese Programme zu entwickeln. Abhängig von SASE-Anbietern oder Sicherheitsdiensten können Anbieter Zeit brauchen, da die Produktversionen einen kompletten Softwareentwicklungszyklus durchlaufen müssen. Um diese Verzögerungen zu vermeiden, bieten neue SASE-Architekturen den Sicherheitsteams von Unternehmen die Möglichkeit, programmatische Regeln selbst zu entwickeln und einzusetzen. Da diese keine Instabilität im Proxy verursachen sollen, bieten SASE-Architekturen WASM-Laufzeiten, um die Erstellung von programmatischen Regeln als WASM-Module zu ermöglichen. Da die WASM-Laufzeitumgebung als Sandbox fungiert, führen Probleme mit WASM-Modulen nicht dazu, dass der Hosting-Benutzerspeicher und andere Sicherheitsfunktions-Plugins abstürzen/sterben. Vereinheitlichter Proxy: Ein einheitlicher Proxy sowohl für Secure Internet Access als auch für Secure Application Access kann den Speicherbedarf reduzieren. Engines und Feeds einiger Sicherheitsfunktionen, wie Anti-Malware und DLP, sind Speicherfresser. Die Einrichtung von zwei verschiedenen Proxy-Instanzen für jede Enterprise-Site kann daher kostspielig sein. Darüber hinaus ist ein Proxy, der alle drei Modi (vorwärts, rückwärts und transparent) unterstützt, auch unter dem Gesichtspunkt der Entwicklerproduktivität eine gute Entwicklungspraxis.

Weitere Architekturprinzipien, die in der neueren Generation der SASE-Architektur befolgt werden, sind

Cloud Native: Wie im Universal SASE dieses Blog-Beitrags beschrieben, sind SASE-Services in On-Prem, Clouds und Edges erforderlich. Daher folgen die SASE-Architekturen der neuen Generation den Prinzipien der „Cloud Native“, damit SASE überall funktionieren kann. Obwohl Cloud Native und Kubernetes keine Synonyme sind, basieren viele Lösungen, die als Cloud Native bezeichnet werden, auf Kubernetes. Der Grund für die Entscheidung, die Lösungen auf Kubernetes laufen zu lassen, ist, dass alle Cloud-/Edge-Anbieter Kubernetes-as-a-Service anbieten und, was noch wichtiger ist, die API-Schnittstelle von den Cloud-/Edge-Anbietern intakt gehalten wird. Aufgrund der konsistenten API-Schnittstelle von Kubernetes über Cloud-/Edge-Anbieter hinweg funktionieren K8s-basierte SASE-Lösungen nahtlos über Cloud-/Edge-Anbieter hinweg. Isolierte Architektur: Aktuelle SASE-Architekturen ermöglichen es aus Effizienzgründen, dass mehrere Tenant-Sitzungen über gemeinsame User-Space-Prozesse laufen. Durch geschickte Methoden wird sichergestellt, dass ein gewisses Maß an Isolierung beibehalten wird, auch wenn sich die IP-Adressen der Mieter überschneiden. Gemeinsam genutzte User-Space-Prozesse für mehrere Mandanten sind aus Sicht der Leistung und der Sicherheitsisolierung keine gute Sache. Bei gemeinsam genutzten Ressourcen ist es möglich, dass jegliches Fehlverhalten, wie z.B. ein DDOS-Angriff auf einen Tenant, zu Leistungsproblemen im Datenverkehr anderer Tenants führen kann. Außerdem kann jeder Angriff auf den gemeinsam genutzten Benutzerbereichsprozess alle Geheimnisse/Passwörter/Schlüssel aller Tenants offenlegen. In Anbetracht der obigen Überlegungen setzen SASE-Architekturen der neueren Generation zunehmend auf dedizierte Proxy-Instanzen, entweder über dedizierte User-Space-Prozesse oder dedizierte Container. API-basierte Architektur: Aktuelle SASE-Lösungen bieten CLI und Portal zur Konfiguration und Überwachung. Einige SASE-Lösungen verwenden APIs zwischen CLI/Portal und Backend-Verwaltungssystemen, die nicht bekannt gemacht werden. In einigen Fällen wären die APIs nicht sauber gewesen. Neue SASE-Lösungen verwenden eine API-First-Architektur, bei der APIs nicht nur für CLI- und Portal-Implementierungen, sondern auch für Dritte zur Entwicklung externer programmatischer Einheiten definiert werden. APIs ermöglichen SecOps-as-code über Terraform und andere, von der einfachen Skriptentwicklung bis zur Entwicklung komplexer Workflows. In der Regel werden RESTful-APIs, JSON-Nutzdaten mit OpenAPI-basierter Dokumentation verwendet, aber einige stellen auch benutzerdefinierte Kubernetes-Ressourcen zur Konfiguration von Sicherheits- und Netzwerkobjekten und -richtlinien bereit. Von der API First-Architektur wird auch erwartet, dass sie die eigentliche Backend-Logik von der Implementierung der RBAC (Role Based Access Control) trennt. Die Erfahrung der Branche zeigt, dass es eine ganze Reihe von Sicherheitslücken gibt, wenn RBAC und Geschäftslogik kombiniert werden. Infolgedessen geht die Branche dazu über, die RBAC-Funktionalität an externe Stellen auszulagern und die Anwendungen auf die Geschäftslogik zu konzentrieren. Die gleiche Logik wird für SASE-Verwaltungssysteme angewandt, wobei sich SASE-Verwaltungssysteme auf SAE-Richtlinien/Objekte und Beobachtbarkeit konzentrieren und die RBAC-Funktionalität externen Einheiten wie Ingress Proxies & API-Gateways überlassen. Ingress-Proxys kümmern sich um die gesamte Authentifizierung und Autorisierung sowie das API-Routing. Das Gute daran ist, dass ein Ingress Proxy mehrere Anwendungen vorschalten kann. Dadurch müssen sich Verwaltungsbenutzer nur mit einer RBAC-Entität für viele Anwendungen vertraut machen. Für diese Trennung von Geschäftslogik und RBAC wird von API-first Architekturlösungen erwartet, dass sie einigen Richtlinien folgen. Viele Ingress Proxies und API-Gateways erwarten zum Beispiel, dass URI verwendet wird, um auf eine Ressource für RBAC zu verweisen. Im Falle einer workflowbasierten Automatisierung wird erwartet, dass die Verwaltungssysteme die Konfiguration taggen und auf ältere Tags zurückgreifen können, um Saga-Muster zu ermöglichen. Von jeder API-first-Architektur wird erwartet, dass sie den besten Praktiken der Branche folgt.

Zusammenfassung

Die Netzwerksicherheitsarchitekturen entwickeln sich von physischen/monolithischen Einheiten zu virtuellen Appliances und Containern. Viele Cloud-Native-Prinzipien, die in der Welt der Anwendungen populär geworden sind, werden in SASE-Lösungen übernommen, um die Cloud-ähnlichen Vorteile zu erhalten, einschließlich Scale-out/in, Agilität, Multi-Cloud-/Edge-Fähigkeit und effizienter Nutzung von Ressourcen über mehrere Mandanten hinweg. Bitte halten Sie an dieser Stelle Ausschau nach neuen Architekturprinzipien und wie Aryaka Cloud-ähnliche Technologien nutzt.

  • CTO Insights Blog

    Die Blogserie Aryaka CTO Insights bietet Denkanstöße zu Netzwerk-, Sicherheits- und SASE-Themen.
    Aryaka Produktspezifikationen finden Sie in den Aryaka Datenblättern.