Evolution von SASE Architektur

Möglicherweise haben Sie im Allgemeinen und im Zusammenhang mit der Netzwerksicherheit von mehreren Architekturprinzipien gehört SASE insbesondere. Einige von der Industrie verwendete Prinzipien der Softwarearchitektur SASE Kontext sind:

• Single-Pass-Architektur
• One-Proxy-Architektur
• Run-to-Completion-Architektur
• Scale-out-Architektur
• Single-Pass-Parallelverarbeitungsarchitektur
• Bringen Sie Ihre eigene Sicherheitsfunktionsarchitektur mit
• Cloud-native Architektur
• Isolationsarchitektur
• API erste Architektur
• Slicing-Architektur (E2E-Segmentierung).

Viele der oben genannten Architekturprinzipien sind nicht neu. Single-Pass-, One-Proxy-, Single-Pass-Parallel-Processing- und Run-to-Completion-Architekturprinzipien sind seit UTM-Tagen (Unified Threat Management) in den frühen 2000er Jahren beliebt, obwohl sie zuvor unter anderen Namen bekannt waren.

Der Hauptzweck dieser Architekturprinzipien besteht darin, zu erreichen

• Höherer Durchsatz bei effizienter Ressourcennutzung.
• Geringere End-to-End-Latenz
• Geringerer Jitter
• Höhere Elastizität (Scale-out) und Ausfallsicherheit auch bei DDoS-Angriffen auf Sicherheitsdienste
• Schnellere Einführung neuer Sicherheitsfunktionen (Agilität)
• Integration von Sicherheitsfunktionen mehrerer Anbieter ohne Einführung von Ineffizienzen (Integration der besten Technologien)
• Anpassbarkeit (Überall ausführen)
• Einscheibenglas

Evolution

Das Tolle an der Netzwerksicherheitsbranche ist, dass sie dynamisch ist. Es übernimmt in jeder neuen Produktgeneration neuere Software- und Bereitstellungsarchitekturprinzipien. Außerdem bleibt der Schutz vor der Raffinesse der Angreifer erhalten.

Allerdings ist der Netzwerksicherheitsmarkt traditionell fragmentiert. Es gibt mehrere Sicherheitsanbieter, die unterschiedliche Sicherheitsfunktionen bereitstellen. Aus Innovationssicht ist dies gut und muss gefördert und fortgesetzt werden. Es ist zu beachten, dass ein Anbieter möglicherweise nicht alle Sicherheitsfunktionen beherrscht.

Wie Sie weiter sehen werden, kommt es zu enormen Ineffizienzen und damit zu enormen Kostenauswirkungen, wenn jeder Anbieter einen vollständigen Stack für seine Sicherheitsfunktionen bereitstellt. Darüber hinaus kann es zu einer höheren Latenz kommen, was für einige Anwendungen eine Herausforderung darstellen könnte. Daher die Anwendbarkeit neuerer Architekturprinzipien und Best Practices. Die Softwarearchitektur muss so gestaltet sein, dass Ineffizienzen vermieden werden, gleichzeitig aber die Integration von Technologien mehrerer Anbieter für die beste Cybersicherheit ermöglicht wird.

Vor der Konvergenz

Abbildung 1 und Abbildung 2 sind zwei repräsentative Beispiele für Netzwerksicherheit SASE. Abbildung 1 zeigt den sicheren Internetzugriff und Abbildung 2 zeigt ein Beispiel für den sicheren privaten Zugriff. Beachten Sie, dass die Reihenfolge der Sicherheitsfunktionen in diesen Bildern willkürlich ist und die Reihenfolge der Ausführung normalerweise anwendungsspezifisch ist.

Sicherer Internetzugang wird traditionell mithilfe mehrerer Sicherheitslösungen erreicht, wie in Abbildung 1 aufgeführt. Es ist die EnterpRise, der diese Sicherheitsfunktionen kauft und in eine Servicekette einfügt. Da viele Sicherheitsfunktionen eine Proxy-Verknüpfung der Verbindungen erfordern, wird diese Verkettung in der Industrie auch als Proxy-Verkettung bezeichnet.

Da jede einzelne Sicherheitslösung eigenständig ist und von mehreren Anbietern stammt, wird die gemeinsame Funktionalität bei diesen Lösungen wiederholt. Zu den allgemeinen Funktionen gehören die Verkehrsüberwachung beim Eingang, die Verkehrsgestaltung beim Ausgang, die Verkehrsfilterung, um sicherzustellen, dass nur relevanter Verkehr an die Proxys weitergeleitet wird. TCP Beendigung der Client-Verbindung, Neu TCP Verbindung zum Ziel, SSL/TLS-Abfangen (das selbst eine On-Demand-Zertifikatgenerierung erfordert, die das Zielzertifikat emuliert), einschließlich TLS-Entschlüsselung und TLS-Verschlüsselung, Proxy-Authentifizierung (Kerberos, NTLM, OIDC) und HTTP 1.1/2.0-Dekodierung. Diese gemeinsame Funktionalität in jeder Box/virtuellen Appliance beansprucht einer Schätzung zufolge 50 % der CPU-Ressourcen der gesamten Sicherheitslösung.

Secure Application Access wird auf ähnliche Weise auch durch die Verkettung der einzelnen Sicherheitslösung erreicht, wie in Abbildung 2 dargestellt. Auch hier ist die gemeinsame Funktionalität über mehrere Sicherheitslösungen hinweg gleich. Es ähnelt fast der allgemeinen Funktionalität der Sicherheitslösungen, die bei Secure Internet Access verwendet werden. Einige Unterschiede umfassen SSL/TLS-Terminierung statt Abfangen und Benutzerauthentifizierung über herkömmliche Methoden statt Proxy-Authentifizierung.

Der durchschnittliche Overhead allgemeiner Funktionalität in einer Sicherheitslösung kann bis zu 50 % der Gesamtlösung betragen. Durch die Verkettung von Funktionen kann sich die Latenz dieser Architektur um einige Millisekunden erhöhen.

Eine weitere große Herausforderung für Enterpmit physischen und virtuellen Appliances steigt, ist auf Skalierung. Ursprünglich wurde die Skalierung durch den Einsatz größerer Appliances oder die Zuweisung von mehr CPU- und Speicherressourcen an die VM-basierten Sicherheitslösungen erreicht. Dies wird als Scale-up bezeichnet. Wenn das Verkehrsaufkommen konstant ist, ist es für Ent sinnvollerpsteigt, um Geld für größere physische/virtuelle Geräte auszugeben. Aber wenn der Verkehr stark ist, ist EnterpAufsteiger mögen es nicht, wenn Geld verschwendet wird. Denken Sie an Fälle, in denen der Verkehr nur an wenigen Tagen im Jahr höher ist. Warum sollte EnterpGibt jemand gerne das ganze Jahr über Geld für diese Beulen aus? Dies führte zur nächsten Entwicklung, bei der Sicherheitsanbieter begannen, Scale-out-Architekturen zu unterstützen cloud-gelieferter Service. Dies ist wie die Begründung dafür IaaS der Cloud Anwendungswelt. In einer Scale-out-Architektur werden automatisch mehr Instanzen der Sicherheitslösungen aktiviert, wenn ein höherer Datenverkehr erkannt wird oder ein DDoS-Angriff erfolgt, und sie werden heruntergefahren, wenn die Nachfrage sinkt. Bild 3 zeigt diese Scale-Out-Architektur.

Es besteht kein Zweifel, dass Scale-out-Funktionalität erforderlich ist. Allerdings ist bei jeder Sicherheitslösung ein Load Balancer erforderlich. Dieser Lastausgleicher wird benötigt, um die Last der Sitzungen auf mehrere Instanzen der Sicherheitslösung auszugleichen. Mehrere Load-Balancer-Durchläufe erfordern mehr Ressourcen und erhöhen die End-to-End-Latenz von Datenverkehrssitzungen.

Die nächste Entwicklung der Netzwerksicherheitsarchitektur befasst sich mit den Herausforderungen von

• Bedarf an mehr Rechenressourcen
• Höhere Latenz

Mit der

• Eine Proxy-Architektur
• Single-Pass-Architektur

Single-Pass- und One-Proxy-Architektur (Converged Architecture)

Wie in Abbildung 4 unten dargestellt, sind alle Sicherheitsfunktionen gebündelt, wobei Proxy- und andere allgemeine Funktionen nur einmal ins Spiel kommen. Alle Sicherheitsfunktionen werden einzeln und bis zur Fertigstellung aufgerufen. Infolgedessen verbraucht diese Architektur Rechenressourcen effizient. Da alle Funktionen im selben User-Space-Kontext aufgerufen werden, werden Speicherkopien vermieden. Darüber hinaus reduziert eine einzige User-Space-Prozessarchitektur die Kontextwechsel des Betriebssystems erheblich. Eine einzelne Proxy-Instanz kann über Multithreading mehrere Sitzungen gleichzeitig verarbeiten, wobei jeder Thread eine Teilmenge von Sitzungen verarbeitet, wodurch Multi-Core-CPUs effektiv genutzt werden. Durch die Multithreading-Fähigkeit können einige Sicherheitsfunktionen für eine bestimmte Verkehrssitzung auch parallel statt seriell ausgeführt werden, wodurch die Latenz verbessert wird. Diese Architektur wird „Single Pass Parallel Processing“ genannt.

Um unerwartete Lasten zu bewältigen und DDoS-Szenarien zu begegnen, wird eine Architektur mit automatischer Skalierung eingesetzt, wobei eine Lastausgleichsinstanz den Sitzungslastausgleich behindert.

In dieser Architektur stellt der Proxy die Schnittstellen-API bereit. Alle Sicherheitsfunktionen sind in diese API eingebunden. Der Proxy ruft während der Verarbeitung der Datenverkehrssitzung die relevanten Hook-Sicherheitsfunktionen auf. Möglicherweise sind nicht alle Sicherheitsfunktionen implementiert SASE Lösungsentwickler. SASE Lösungsentwickler arbeiten mit Technologielieferanten zusammen, indem sie Engines und Feeds von Technologielieferanten in die Proxys integrieren. Auf diese Weise können die Kunden von SASE Anbieter erhalten das Beste aus beiden Welten – hohe Leistung SASE mit besten Sicherheitsimplementierungen.

Allerdings liefern einige Technologielieferanten Engine möglicherweise nicht in SDK-Form für die Entwicklung von Sicherheitsfunktionen als Teil des Proxys. Es kann sein, dass sie es als haben cloud Service. DLP ist ein Beispiel dafür, dass viele Technologieanbieter dies nutzen cloud Service. In einigen Fällen kann es auch sein, dass die SASE Lösungsanbieter möglicherweise nicht want Aus Gründen wie Speicherbeschränkungen, zur Vermeidung von Lizenzinkompatibilitäten, zur Vermeidung einer Zerbrechlichkeit des Benutzerbereichs und anderen Gründen müssen einige Sicherheitsfunktionen in denselben Benutzerraumprozesskontext des Proxys integriert werden.

Einheitliche Architektur und eigene Sicherheitsfunktionen

Die nächste Entwicklung in der SASE Architektur ist unten dargestellt. In Abbildung 6 unten sind drei hervorstechende Punkte dargestellt.

Unterstützung für Sicherheitsdienste über ICAP (Internet Content Adaptation Protocol): EnterpRises sind möglicherweise daran gewöhnt oder möchten möglicherweise Sicherheitsdienste anderer Sicherheitsanbieter nutzen. ICAP Spezifikationen der IETF legen fest, wie Proxys mit externen Inhaltsanpassungsdiensten, einschließlich Sicherheitsdiensten, kommunizieren können. Durch die Zulassung externer Sicherheitsdienste SASE Lösungsanbieter ermöglichen Enterpsteigt auf, um ihre Wahl der Sicherheitsdienste zu treffen.

Bringen Sie Ihre eigenen Sicherheitsfunktionen mit: Laut dem IBM-Sicherheitsbericht „Cost of a Data Breach Report 2022“ benötigen Unternehmen durchschnittlich 277 Tage, um eine Datenschutzverletzung zu erkennen und einzudämmen. Obwohl SASE Bietet eine sehr gute Richtlinienkonfiguration. Es kann sein, dass die Eindämmung einiger Datenschutzverletzungen programmatische Regeln erfordert. Organisationen, die Datenschutzverletzungen analysieren, sind in einer guten Position, diese Programme zu entwickeln. Es hängt davon ab SASE Anbieter oder Sicherheitsdienste können Anbieter einige Zeit in Anspruch nehmen, da Produktveröffentlichungen einen vollständigen Softwareentwicklungslebenszyklus durchlaufen müssen. Um diese Verzögerungen zu vermeiden, neu SASE Architekturen bieten eine Möglichkeit für UnternehmenerpDie Sicherheitsteams von Rises können selbst programmatische Regeln entwickeln und einsetzen. Da diese keine Instabilität im Proxy verursachen dürfen, SASE Architekturen stellen WASM-Laufzeiten bereit, um die Erstellung programmatischer Regeln als WASM-Module zu ermöglichen. Da die WASM-Laufzeit als Sandbox fungiert, führen Probleme mit WASM-Modulen nicht zum Absturz/Absturz des Hosting-Benutzerbereichs und anderer Sicherheitsfunktions-Plugins.

Einheitlicher Proxy: Ein einheitlicher Proxy für Secure Internet Access und Secure Application Access kann den Speicherbedarf reduzieren. Engines und Feeds einiger Sicherheitsfunktionen wie Anti-Malware und DLP sind Speicherfresser. Für jedes Unternehmen werden zwei verschiedene Proxy-Instanzen aufgerufenerpDer Bau einer Baustelle kann daher kostspielig sein. Darüber hinaus ist die Verwendung eines Proxys, der alle drei Modi (Vorwärts, Rückwärts und Transparent) unterstützt, auch aus Sicht der Entwicklerproduktivität eine gute Entwicklungspraxis.

Weitere Architekturprinzipien wurden in der neueren Generation befolgt SASE Architektur sind

Cloud Eingeborener: Wie im Universal besprochen SASE von diesem Blog-Post, SASE Dienste sind in On-Prem erforderlich, Clouds und Kanten. Daher neue Generation SASE Architekturen folgen dem „Cloud native' Prinzipien zu machen SASE überall arbeiten. Obwohl Cloud Native und Kubernetes sind oft keine Synonyme, Lösungen, die sagen cloud native basieren auf Kubernetes. Der Grund für die Entscheidung, die Lösungen auf Kubernetes laufen zu lassen, ist das alles cloud/edge-Anbieter bieten Kubernetes-as-a-Service an, und was noch wichtiger ist, die API-Schnittstelle bleibt dadurch intakt cloud/edge-Anbieter. Aufgrund der einheitlichen API-Schnittstelle von Kubernetes übergreifend cloud/edge-Anbieter, K8s-basiert SASE Lösungen funktionieren reibungslosssly rüber cloud/edge-Anbieter.

Isolationsarchitektur: Strom SASE Aus Effizienzgründen ermöglichen Architekturen die Durchführung mehrerer Mandantensitzungen über gemeinsam genutzte Benutzerraumprozesse. Mithilfe cleverer Methoden wird sichergestellt, dass ein gewisses Maß an Isolation aufrechterhalten bleibt, auch wenn sich die IP-Adressen der Mandanten überschneiden. Shared User Space-Prozesse für mehrere Mandanten sind aus Sicht der Leistungs- und Sicherheitsisolation keine gute Sache. Bei gemeinsam genutzten Ressourcen ist es möglich, dass Fehlverhalten, wie z. B. ein DDOS-Angriff auf einen Mandanten, zu Leistungsproblemen im Datenverkehr anderer Mandanten führen kann. Außerdem kann jeder Exploit im Shared User Space-Prozess alle Geheimnisse/Passwörter/Schlüssel aller Mandanten preisgeben. Unter Berücksichtigung des oben Gesagten, neuere Generation SASE Architekturen setzen zunehmend auf dedizierte Proxy-Instanzen, entweder über dedizierte User-Space-Prozesse oder dedizierte Container.

API-erste Architektur: Strom SASE Lösungen bieten CLI und Portal zum Konfigurieren und Beobachten. Manche SASE Lösungen nutzen APIs zwischen CLI/Portal und Backend-Verwaltungssystemen, sie werden nicht beworben. In einigen Fällen wären APIs nicht sauber gewesen. Neu SASE Lösungen übernehmen die API-First-Architektur, bei der APIs nicht nur für CLI- und Portal-Implementierungen, sondern auch für Dritte zur Entwicklung externer Programmeinheiten definiert werden. APIs ermöglichen SecOps-as-Code über Terraform und andere, von der einfachen Skriptentwicklung bis hin zur komplexen Workflow-Entwicklung.

Es ist üblich, RESTful API und JSON-Payloads mit OpenAPI-basierter Dokumentation zu verwenden, aber einige stellen auch benutzerdefinierte Kubernetes-Ressourcen zur Verfügung, um Sicherheits- und Netzwerkobjekte und -richtlinien zu konfigurieren.

Von der API-First-Architektur wird außerdem erwartet, dass sie die eigentliche Backend-Logik von der Implementierung der RBAC (Role Based Access Control) trennt. Branchenerfahrungen zeigen, dass es zahlreiche Schwachstellen gibt, wenn RBAC und Geschäftslogik kombiniert werden. Infolgedessen geht die Branche dazu über, die RBAC-Funktionalität auf externe Einheiten auszulagern und den Fokus der Anwendungen auf die Geschäftslogik zu legen. Die gleiche Logik wird angewendet SASE Managementsysteme, wo SASE Managementsysteme konzentrieren sich auf SAE-Richtlinien/-Objekte und Beobachtbarkeit und überlassen die RBAC-Funktionalität externen Einheiten wie Eingangs-Proxys und API-Gateways. 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 unterstützen kann. Aus diesem Grund müssen sich Administratorbenutzer nur mit einer RBAC-Entität für viele Anwendungen vertraut machen. Für diese Trennung der Geschäftslogik von RBAC wird erwartet, dass API-First-Architekturlösungen einigen Richtlinien folgen. Beispielsweise erwarten viele Ingress-Proxys und API-Gateways, dass URI verwendet wird, um auf eine Ressource für RBAC zu verweisen. Bei der Workflow-basierten Automatisierung besteht die Erwartung, dass die Verwaltungssysteme die Konfiguration mit Tags versehen und auf ältere Tags zurücksetzen können, um Saga-Muster zu ermöglichen. Von jeder API-First-Architektur wird erwartet, dass sie den Best Practices der Branche folgt.

Zusammenfassung

Netzwerksicherheitsarchitekturen entwickeln sich von physischen/monolithischen Einheiten hin zu virtuellen Appliances und Containern. Viele cloud-native Prinzipien, die in der Anwendungswelt populär geworden sind, werden übernommen SASE Lösungen, um das zu bekommen cloud-ähnliche Vorteile, einschließlich Scale-Out/In, Agilität, Multi-cloud / Edge-Ready und effiziente Nutzung von Ressourcen über mehrere Mandanten hinweg. Bitte beachten Sie diesen Bereich für neue Architekturprinzipien und wie Aryaka nutzt cloud-ähnliche Technologien.

• CTO Insights-Blog

  Die Aryaka-CTO-Insights-Blogserie bietet Vordenker für Netzwerk, Sicherheit und SASE-Themen. Aryaka Produktspezifikationen beziehen sich auf Aryaka Datenblätter.