Zurück 
Cybersicherheit hat den schlechten Ruf, dem Geschäft im Weg zu stehen. Viele CIOs und CISOs widmen viel Zeit der Minimierung der Leistungseinbußen bei Sicherheitslösungen im Netzwerkverkehr und stellen gleichzeitig sicher, dass die Lösungen weiterhin ihre Aufgabe erfüllen und das Netzwerk sicher halten. Der Wechsel in die Cloud verschärft diese Herausforderung.
Vor einigen Jahren installierte ein Sicherheitsteam Sicherheitsdienste auf einer Reihe von physischen Geräten. Firewall, URL-Filterung, E-Mail-Überwachung, Bedrohungsscan und Data Loss Prevention (DLP)-Funktionen können beispielsweise jeweils auf einer eigenen Box ausgeführt werden. Die fünf Geräte könnten seriell konfiguriert werden, so dass ein Datenpaket in ein Gerät einfließt, das Gerät seinen Standarddienst ausführt und das Paket anschließend zum nächsten Gerät weitergeleitet wird, das wiederum alle seine Standardschritte durchläuft. Die Skalierbarkeit jedes Dienstes wäre durch den auf seinem physischen Gerät verfügbaren Speicherplatz begrenzt. Und wenn die Hardware maximal ausgelastet war, ließ die Leistung der Sicherheitsprüfungen – und somit auch die Leistung des Netzwerkverkehrs – nach. Diese Herausforderungen wurden durch verschlüsselte Datenströme und die Notwendigkeit, den Datenverkehr für jede Funktion mehrmals zu entschlüsseln, zu scannen und dann erneut zu verschlüsseln, noch verschärft.
Viele Kunden versuchten, die Skalierbarkeit durch die Umstellung auf virtuelle Appliances zu verbessern, stießen dabei jedoch auf das gleiche Engpassproblem. Unabhängig davon, ob eine Lösung in der Cloud oder vor Ort ausgeführt wird, erfordert die Virtualisierung von Administratoren die Zuweisung bestimmter Ressourcen, darunter CPU, Speicher und Festplattenspeicher. Einige Sicherheitsplattformen konsolidieren eine Reihe unterschiedlicher Dienste. Dadurch erhält die Lösungssuite insgesamt Zugriff auf mehr Ressourcen, die Dienste müssen jedoch um diese begrenzte Menge aller verfügbaren Ressourcen konkurrieren und die Leistung ist letztlich für keine von ihnen optimiert. Dieses konzeptbedingte „Tauziehen“ um die Ressourcen erzwingt letztlich einen Kompromiss zwischen Sicherheitsverarbeitung und Leistung.
Unabhängig vom Ansatz ist der Spielraum für eine horizontale Skalierung bei physischen, virtuellen oder Cloud-basierten Ansätzen normalerweise begrenzt. Ab diesem Zeitpunkt kommt es aufgrund von Ressourcenbeschränkungen zu Latenzen bei der Leistung der darin enthaltenen Lösungen. Eine Sicherheitsinfrastruktur, die über eine Datenverkehrspipeline mit festem Durchmesser betrieben wird, stößt früher oder später an diese Einschränkungen und Engpässe. Die Netzwerkgeschwindigkeit wird darunter leiden, was sich letztlich in einer verschlechterten Benutzererfahrung niederschlägt und im schlimmsten Fall dazu führt, dass Benutzer die Sicherheitskontrollen gänzlich umgehen und dadurch das Unternehmen einem Risiko aussetzen.
Lose gekoppelte, aber unabhängige Microservices
Als Netskope unsere heutige SASE-fähige (Secure Access Service Edge) Plattform entwickelte, entwarfen wir die Architektur mit dem Ziel, die Latenz zu überwinden, die die Leistung herkömmlicher Sicherheitslösungen beeinträchtigt. Um dieses Ziel zu erreichen, haben wir zwei Aspekte der grundlegenden Funktionsweise der Sicherheitstechnologie überdacht.
Zunächst haben wir die wichtigsten Sicherheitsfunktionen auf einer einzigen einheitlichen Plattform konsolidiert und gleichzeitig einzelne Sicherheitsfunktionen in das abstrahiert, was wir bei Netskope „Microservices“ nennen. Prozesse wie Data Loss Prevention (DLP), Bedrohungsschutz, Web-Inhaltsfilterung und Zero Trust Network Access (ZTNA) werden unabhängig voneinander und jeweils mit eigenen Ressourcen ausgeführt. Wenn Ressourcenbeschränkungen die Leistung eines der Microservices beeinträchtigen, ist die Netskope Security Cloud so konzipiert, dass sie diesen Microservice automatisch hochskaliert (oder vergrößert), indem sie die erforderlichen Ressourcen unabhängig freigibt.
Beispielsweise wird das Abfangen von SSL höchstwahrscheinlich durch die Eingabe/Ausgabe (E/A) des Systems eingeschränkt, das versucht, den aus dem Netzwerk empfangenen Datenverkehr zu entschlüsseln. Während die Einrichtung einer TLS/SSL-Sitzung für die asymmetrischen Schlüsseloperationen allgemein als an die zentrale Verarbeitungseinheit (CPU) gebunden gilt, sind die symmetrischen Verschlüsselungs- und Entschlüsselungsfunktionen nach dem Aufbau einer Sitzung nicht mehr an die CPU gebunden, da die meisten modernen CPUs über integrierte AES-Anweisungen verfügen. Dementsprechend wird während der eigentlichen Datenübertragungsphase schnell die Geschwindigkeit zum Engpass, mit der Pakete in das System hinein- und aus ihm herausgelangen können (E/A, nicht CPU), wobei jede Paketkopie einen zusätzlichen Overhead erzeugt, der die Latenz der gesamten Paketverarbeitung erhöht. DLP hingegen ist tendenziell stärker an die CPU gebunden, da sein Zweck darin besteht, verdächtige Dateien mithilfe prozessorintensiver Technologien wie verschiedenen regulären Ausdrucks-Engines zu öffnen. Wenn die DLP-Leistung durch CPU-Einschränkungen beeinträchtigt würde, würde das Design von Netskope die Prozessorleistung schnell und speziell für diesen DLP-Mikrodienst erhöhen, anstatt die CPU-Leistung generell und für alle Sicherheitsdienste hochzufahren, um die sie konkurrieren.
Das erinnert vielleicht ein wenig an die guten alten Zeiten, als jede Sicherheitslösung auf ihrer eigenen Hardware lief. Das ist aber nicht der Fall. Es handelt sich um eine dramatische Vereinfachung und Abstraktion durch die unzähligen Netskope-Mikroservices. Dies führt zum zweiten bemerkenswerten Aspekt der Netskope-Architektur: Die einzelnen Mikroservices sind zwar unabhängig, bleiben aber dennoch eng miteinander verbunden. Obwohl sie Ressourcen wie E/A oder CPU unabhängig voneinander nutzen, teilen sie die Ergebnisse bestimmter Prozesse, sodass dieselben Arbeitslasten nicht unnötig über mehrere Mikrodienste hinweg wiederholt werden, die dieselben Pakete analysieren. Dadurch wird die Effizienz erheblich gesteigert, sodass Netskope große Datenmengen verarbeiten, den „Kontext“ der Sicherheitsergebnisse besser verknüpfen und letztendlich die Leistung steigern und die Latenz verkürzen kann.
Schnellere Verkehrsabwicklung und effektivere Sicherheit
Bei jedem Sicherheitsprodukt oder -dienst kommt es zu einer gewissen Latenz. Das ist eine Tatsache. Jede Lösung, die ein bewegtes Datenpaket berührt, wird aufgrund der Gesetze der Physik verlangsamt. Die Single-Pass-Architektur von Netskope ist jedoch darauf ausgelegt, die End-to-End-Latenz zu minimieren. Dies wird erreicht, indem der „Inhalt“ von den Metadaten getrennt wird und indem sich wiederholende Aktivitäten nur einmal ausgeführt werden, um die Ergebnisse für alle Mikrodienste, die diese Aktivitäten nutzen, besser zu nutzen. Ich werde in diesem Blog nicht im Detail darauf eingehen, aber die Optimierungen der privaten Sicherheits-Cloud von Netskope, genannt NewEdge, reduzieren die Latenzzeit noch weiter und sorgen für das bestmögliche Benutzer- und Anwendungserlebnis. Hierzu zählen Entscheidungen hinsichtlich der integrierten Racks, die wir für den Einsatz in unseren Rechenzentren bauen, hinsichtlich der Steuerung der gesamten Verkehrsführung und der Standorte der Rechenzentren, hinsichtlich des umfassenden Peerings mit Web-, Cloud- und SaaS-Anbietern (in jedem Rechenzentrum) sowie hinsichtlich einer massiven Überbereitstellung jedes Rechenzentrums und des Betriebs der Infrastruktur mit geringer Auslastung (und maximalem Spielraum), um ungewöhnliche Verkehrsspitzen oder die Kundenakzeptanz zu bewältigen.
Kommen wir zurück zum Thema der sich wiederholenden Aktivitäten, die innerhalb der Netskope Security Cloud ausgeführt werden. Betrachten wir als Beispiel die „Entschlüsselung“. Etwa 90 % des Datenverkehrs, den Netskope heute abwickelt, ist verschlüsselt. Obwohl unsere Sicherheits-Mikrodienste nach der Entschlüsselung unterschiedliche Vorgänge auf den Datenverkehr anwenden, ist bei allen Diensten zunächst die Entschlüsselung des Pakets erforderlich, bevor sie ihre spezielle Aktion oder Operation ausführen können. In diesem Fall abstrahiert unsere Single-Pass-Architektur die Microservices höherer Ebene vom Entschlüsselungsprozess, sodass Netskope den Datenverkehr nur einmal entschlüsselt, dann die zahlreichen, unterschiedlichen und den Richtlinien entsprechenden Microservices auf den Datenverkehr anwendet und den Datenverkehr anschließend erneut verschlüsselt und weiterleitet.
Um genauer darauf einzugehen: Der Prozess der Datenverkehr-Entschlüsselung selbst führt sowohl zu verwertbaren Inhalten als auch zu Metadaten, die die abgefangenen Pakete beschreiben. Wenn ein Netskope-Mikrodienst – etwa DLP oder Bedrohungsschutz – anschließend auf diesen Datenverkehr trifft, hat er sofortigen Zugriff auf Informationen darüber, wer der Benutzer ist, auf welche Anwendung er zugreift, welche Aktivität er auszuführen versucht und wo sich der zugehörige Inhalt im Paketstrom befindet. Wenn der Mikrodienst den Inhalt des Pakets überprüfen muss, kann er dies viel schneller tun, als wenn er zum ersten Mal auf verschlüsselte Kommunikation stößt.
Neben dem Entschlüsselungsszenario ist die Sicherheitsrichtlinie ein weiterer Bereich, in dem allgemeine Workloads einmal ausgeführt und dann von mehreren Microservices gemeinsam genutzt und genutzt werden können. Alle Netskope-Mikroservices verwenden dieselbe Richtlinien-Engine und Richtliniensuchen können dienstübergreifend wiederverwendet werden. Dies bedeutet, dass die Sicherheitsdefinitionen bei allen verschiedenen Netskope Security Cloud-Diensten konsistent sind. Dementsprechend müssen CISOs und ihre Sicherheitsexperten beispielsweise die Datenschutz-Grundverordnung (DSGVO) oder die Richtlinien der Payment Card Industry (PCI) für E-Mail-, Endpunkt-, Web- oder SaaS-Sicherheit nicht separat definieren. Diese Vereinheitlichung und Vereinfachung der Richtlinien erfolgt nicht nur über eine einzige Verwaltungskonsole, die Netskope-Kunden sehr schätzen, sondern auch auf einer niedrigeren Mikroservices-Ebene, was die Gesamtsystemleistung weiter verbessert.
Dieser Ansatz erspart außerdem mehreren Diensten die Wiederholung derselben Aktionen. Beispielsweise erfordern einige Sicherheitsprozesse möglicherweise, dass die Identität des Benutzers, der eine bestimmte Web-Anforderung (mit einem entsprechenden Netzwerkpaket) initiiert hat, mit einer Reihe von Benutzerprofilen abgeglichen wird. Diese Informationen können beispielsweise hilfreich sein, um Richtlinienaktionen für den Datenverkehr dieses Benutzers zu definieren. Nachdem diese Suche abgeschlossen und der Benutzer identifiziert wurde, können diese Informationen problemlos mit den übrigen Netskope-Mikroservices geteilt werden. Der DLP-Dienst kann diese Informationen verwenden, um zu bestimmen, wie Daten klassifiziert werden, zum Beispiel ob sie vertraulich sind oder nicht. Der Bedrohungsschutzdienst könnte sich bei Entscheidungen zur Malware-Untersuchung beispielsweise auf diesen Benutzerkontext beziehen, wenn es sich um einen bekannten Risikobenutzer handelt. Sobald die Identität ermittelt ist, muss in beiden Fällen keiner der Microservices diese Aktion wiederholen.
Durch die Wiederverwendung hochrangiger Vorgänge (z. B. Entschlüsselung, Richtlinien, Benutzeridentifizierung) rationalisiert die Single-Pass-Architektur die Paketverarbeitung letztendlich erheblich und reduziert die End-to-End-Latenz der Microservices. Die Auswirkungen können erheblich sein. Bei DLP beispielsweise können derartige Aktivitäten 20 % der gesamten Zeit (und Ressourcen) ausmachen, die dieser Mikrodienst verbraucht. Die Abstraktion von Mikrodiensten durch die Netskope-Architektur und die gleichzeitige lose Kopplung dieser Dienste optimiert die Datenverkehrsverarbeitung von und zur Cloud und minimiert die Auswirkungen der Sicherheit auf das Endbenutzererlebnis.
Konsistenz der Politik und Sichtbarkeit auf Führungsebene
Die Netskope Single-Pass-Architektur von ermöglicht außerdem die Anzeige von Sicherheitsereignissen, die über Netskope Next Gen Secure Web Gateway (SWG), den Cloud Access Security Broker (CASB), DLP und andere Serviceangebote von generiert werden, über ein einziges Dashboard für Vorfallmanagement und -verwaltung. Aus Sicht des CISO sch