Nutzung natürlicher Sprache zur Definition und Vereinfachung von Mikrosegmentierungsrichtlinien

Von den drei grundlegenden Ressourcen in jedem Rechenzentrum oder jeder Cloud — Rechenleistung, Speicher, Netzwerk — entwickelte sich das Netzwerk am langsamsten in die moderne Welt der Ressourcenvirtualisierung und -abstraktion. Dies ist größtenteils beabsichtigt. Man kann argumentieren, dass die Netzwerkstruktur die kritischste Ressource in jedem Rechenzentrum oder jeder Cloud-Architektur ist. Ohne ein Netzwerk sind Rechenleistung und Speicher unerreichbare Inseln. Das Netzwerk ermöglicht den Zugriff und die Kommunikation zwischen allen Rechen- und Speicherressourcen, untereinander und mit den Endbenutzern dieser Ressourcen. Ohne das Netzwerk, das einer Architektur zugrunde liegt, sind alle Cloud-Konversationen bedeutungslos. Ganz gleich, wie weit Sie Cloud-Konversationen rund um Rechenressourcen abstrahieren, von Bare-Metal bis hin zu serverlosen, wenn sich irgendwo im Bild ein IP-Paket befindet, ist das Netzwerk von entscheidender Bedeutung.

Netzwerksicherheit wird jetzt in natürlicher Sprache definiert, nicht in Netzwerksprache.

Das ist gesunder Menschenverstand, und Netzwerke haben ihre eigenen Formen der Ressourcenvirtualisierung, mit denen bestimmte Netzwerkprobleme gelöst werden sollen. Dennoch wird es hier aus dem einfachen Grund erwähnt, dass die Sicherheit in Rechenzentren oder Cloud-Bereitstellungen traditionell im Netzwerk implementiert wurde. Um den Netzwerkverkehr bei der Übertragung zwischen Cloud-Ressourcen zu blockieren oder zu aktivieren, wird irgendwo in der Netzwerkstruktur eine Firewall installiert. Endpunktsoftware kann auf Rechenressourcen installiert werden. Dabei handelt es sich in der Regel um signaturbasierte Tools, die nach bekannter Malware oder schlechtem Verhalten suchen. In der Regel untersuchen sie den Datenverkehr, blockieren oder erlauben ihn nicht. Die meisten Workloads verfügen über eingebaute Firewalling-Funktionen, wie z. B. Iptables unter Linux, aber die Orchestrierung dieser Tools im großen Maßstab ist oft schwierig zu verwalten und wird daher nicht verwendet. Also Netzwerksicherheit und die Durchsetzung des Datenverkehrs erfolgt traditionell mit Netzwerk-Firewalls.

Sicherheit wird oft in einer anderen Sprache definiert

Da Firewalls in der Regel von Netzwerkteams verwaltet werden, werden Sicherheitsrichtlinien meistens anhand von Begriffen definiert, die Netzwerkteams vertraut sind. Firewalls gibt es seit Jahrzehnten, und ihre Konfiguration hat sich im Laufe der Jahre nur minimal geändert. Richtlinienregeln werden traditionell mithilfe von IP-Adressen, TCP/UDP-Ports, VLANs und Zonen geschrieben. Firewalls sind in der Regel nicht so konzipiert, dass sie die Nutzlast von Paketen genauer untersuchen, um zu überprüfen, welche Inhalte oder Apps darin enthalten sind, da sie verhindern wollen, dass sie zu einem Engpass im Netzwerkverkehr werden.

Es gibt sogenannte Firewalls der nächsten Generation (NGFW) die in der Lage sind, Pakete bei Kabelgeschwindigkeit viel genauer zu untersuchen und Richtlinien dafür definieren können, was tatsächlich in der Datennutzlast eines Pakets enthalten ist, und nicht nur in seinen Netzwerk-Headern. Aber weil alte Gewohnheiten schwer fallen, ist es in der Realität so, dass diese Firewalls oft auf die alte Art konfiguriert werden, wobei die Optionen der nächsten Generation ungenutzt bleiben. Das Ergebnis ist ein Gerät, das die Netzwerkterminologie zur Definition verwendet Netzwerksicherheit, so nehmen Benutzer von Ressourcen, die in einem Rechenzentrum oder einer Cloud gehostet werden, diese Ressourcen nicht wahr. Benutzer wissen oft nicht oder es ist ihnen egal, in welchem Netzwerksegment eine Ressource gehostet wird. Sie befassen sich mit der Ressource selbst.

Die Netzwerkpolitik sollte widerspiegeln, wie Benutzer die zu schützenden Ressourcen wahrnehmen

Wenn ein Benutzer oder Entwickler ein Problem meldet, z. B. weil er eine Ressource, die in einem Rechenzentrum oder einer Cloud gehostet wird, nicht erreichen kann, bezieht er sich normalerweise auf die spezifische Arbeitslast oder Anwendung, die nicht erreichbar ist. Im Allgemeinen melden sie nicht, dass eine bestimmte IP-Adresse über einen bestimmten Port nicht erreichbar ist. Allerdings ist das Netzwerk oder Sicherheitsoperationen Die Teams werden diese Informationen anfordern. Und hier tritt das Problem auf: Das gemeldete Problem ist in einer anderen Sprache als die der Geräte, die die Netzwerkrichtlinien durchsetzen. Anwendungssprache ist in der Regel nicht gleichbedeutend mit Netzwerksprache.

Ein wichtiges Detail bei dem Bestreben, so viele Ressourcen wie möglich in Cloud-Architekturen zu automatisieren, ist die Fähigkeit, Netzwerkrichtlinien unter Verwendung derselben Begriffe zu definieren, die Benutzer als die zu schützenden Ressourcen wahrnehmen. Wenn eine Firewall Richtlinien zwischen den Anwendungen X, Y und Z durchsetzt, sollte sie in der Lage sein, Richtlinien zu definieren, die für diese Anwendungen spezifisch sind und nicht spezifisch für die Netzwerkressource, auf der sie gehostet werden.

Dies ist besonders relevant in modernen, in der öffentlichen Cloud gehosteten Infrastrukturen wie Microservices, in denen IP-Adressen kurzlebig sind. Workloads und Anwendungen werden oft dynamisch über verschiedene Netzwerksegmente hinweg migriert, sodass eine IP-Adresse keine zuverlässige Methode mehr ist, um eine bestimmte Arbeitslast für den Lebenszyklus dieser Ressource zu identifizieren. Wenn Sie eine Firewall jedes Mal ändern müssen, wenn sich eine IP-Adresse ändert, ist dies nicht skalierbar.

Das Ergebnis ist, dass Firewalls in modernen Cloud-Architekturen sehr oft einfach nicht eingesetzt werden. Stattdessen sitzen sie nur am Rand einer Cloud-Struktur und regeln nur den Nord-Süd-Verkehr, sodass sie für den Großteil des Ost-West-Verkehrs blind sind.

Definieren Sie Sicherheit mithilfe von Metadaten, nicht anhand von IPs

Die meisten modernen SDN-Controller können quasi eine lokale Datenbank mit Workload-IPs und Metadaten erstellen, die auf jeden Workload angewendet wird. Wenn beispielsweise fünf Produktions-Workloads SQL-Server sind und weitere fünf Workloads Entwicklungs-SQL-Server sind, erstellt der Controller einen lokalen Datensatz, der diese Server in zwei Kategorien auflistet, wobei die ersten fünf Workload-IPs dem Metadaten-Tag „SQL-Prod“ zugewiesen sind und die zweiten fünf Workload-IPs dem Metadaten-Tag „SQL-Dev“ zugewiesen sind. Der Controller überwacht diese Workloads, und wenn ein Workload aus irgendeinem Grund seine IP ändert oder wenn er heruntergefahren wird, aktualisiert der Controller seine lokalen Datensätze der Metadaten-IP-Zuordnungen.

Auf diese Weise kann der Controller den gesamten Lebenszyklus des Workloads anhand der ihm zugewiesenen Metadaten verfolgen, unabhängig davon, welche IP-Adresse er ihm zugewiesen hat. Die Paketweiterleitung zu und von den Workloads erfolgt weiterhin mithilfe von IP-Lookups unter Verwendung der aktuell zugewiesenen IP-Adresse. Die Identität dieses Workloads wird jedoch durch die ihm zugewiesenen Metadaten aufrechterhalten, unabhängig davon, welchem Netzwerksegment er zugewiesen ist.

Durch die Identifizierung eines Workloads anhand von Metadaten kann die Identität dieses Workloads vollständig von allen Netzwerkdetails abstrahiert werden — so muss moderne Sicherheit definiert werden. Die Definition einer Richtlinie, die so etwas wie „Kein SQL-Server in der Entwicklung kann Kontakt mit SQL-Servern in der Produktion aufnehmen“ lautet, kommt der Wahrnehmung dieser Ressourcen durch Benutzer viel näher als die Definition einer Richtlinie, die wie folgt lautet: „192.168.10.0/24 TCP 1024-2000 10.10.0.0/16 permit“. Begriffe aus Metadaten sind für Menschen viel besser lesbar als Begriffe aus dem Bereich Netzwerke.

Die Verwendung von Metadaten zur Identifizierung von Ressourcen wird normalerweise als „Tags“ oder „Labels“ bezeichnet. Und dieses Konzept wird von anderen Controllern als SDN verwendet. Mit Illumio ASP, Sie können jedem Workload ein Label zuweisen, und jedes Label hat vier „Dimensionen“: Rolle, Anwendung, Umgebung und Standort. Jedem Workload kann ein Label zugewiesen werden, das ihn anhand einer oder aller dieser Dimensionen identifiziert. Anhand dieser Labels können dann Richtlinien definiert werden. Ein Illumio Regelsatz bezieht sich also nicht auf Ports oder IPs, sondern auf Labels.

Der Wert von Illumio Labels

Das Konzept der Etiketten mag wie ein kleines Detail erscheinen, aber es muss betont werden. Mithilfe von Labels können Sie Richtlinien definieren und dabei die gleichen Begriffe verwenden, wie Benutzer die zu schützenden Ressourcen wahrnehmen. Dies ist eine bedeutende Veränderung gegenüber der traditionellen Definition von Netzwerksicherheit. Jahrzehntelang wurde Netzwerksicherheit anhand von Netzwerkkonstrukten definiert: IPs, VLANs und Ports. Firewalls betrachten die Sicherheit durch die Linse dieser Netzwerkkonstrukte. Wenn sich eines dieser Konstrukte ändert, muss die Firewallkonfiguration geändert werden.

Wenn die Richtlinie jedoch mithilfe von Labels definiert wird und diese Labels dazu führen, dass die integrierten Firewallfunktionen des Workloads so konfiguriert werden, dass diese Definition im Hintergrund durchgesetzt wird, entspricht die Richtlinie jetzt der tatsächlichen Nutzung der Ressourcen. Die Netzwerksicherheit wird jetzt in natürlicher Sprache definiert, nicht in Netzwerksprache. Und diese „Natural Language Policy“ wird nur einmal definiert und bleibt unauffällig, selbst wenn Workloads über Netzwerkstrukturen migrieren, heruntergefahren oder erhöht oder auf große Bereitstellungen hochskaliert werden.

Sicherheit sollte kein Hindernis für die Anforderungen an die Skalierbarkeit von Workloads sein. Die Verwendung natürlicher Sprache zur Definition von Richtlinien — mithilfe von Labels — ermöglicht die Entwicklung der Arbeitslast, ohne dass die Sicherheit den DevOps-Prozess verlangsamt.

Also verwende ich Labels: Was nun?

Auch wenn sich Netzwerkteams daran gewöhnen, Richtlinien mithilfe von Bezeichnungen in natürlicher Sprache zu definieren, um eine für Menschen lesbarere Sprache zu schaffen, ist die Denkweise, die hinter der Definition der Richtlinien steht, immer noch oft netzwerkzentriert. Die Bezeichnungen beziehen sich zwar auf Arbeitslasten und Anwendungen, aber Netzwerkteams betrachten Vertrauensgrenzen immer noch als Netzwerkgrenzen. Doch da immer mehr Unternehmen ein Null Vertrauen Denkweise, ein wichtiges Merkmal erfordert, dass Unternehmen die Vertrauensgrenzen weg vom Netzwerk und direkt zu den Ressourcen verschieben, auf die sich die Labels beziehen. Wenn Sie fünf SQL-Workloads haben, stellt jede dieser Workloads eine eigene Vertrauensgrenze dar. Die Vertrauensgrenze ist kein gemeinsames Netzwerksegment, das sich möglicherweise alle teilen.

Illumio setzt Agenten ein, bekannt als VENs, auf jedem überwachten Workload, und diese Agenten übersetzen die auf Bezeichnungen basierende Richtlinie in Regeln auf der integrierten Firewall auf jedem Workload. Der erste Schritt im Leben eines Pakets, bei seiner Geburt, ist also die Richtlinie. Eine andere Art, über Zero Trust nachzudenken, lautet: „Kein Paket darf die Netzwerkweiterleitungsebene erreichen, bis es überprüft wurde.“ Bei Illumio ist die Sicherheit bereits gewährleistet, wenn ein Paket die Netzwerkweiterleitungsebene erreicht.

Dies ist besonders wichtig, wenn versucht wird, das Problem von anzugehen seitliche Bewegung, wodurch böswillige Akteure oder Schadsoftware unentdeckt ein Netzwerk durchqueren können. Wenn beispielsweise Sicherheitsrichtlinien mit Remote-Benutzern besprochen werden, wird in der Regel erkannt, dass Sicherheit erforderlich ist, aber die übliche Antwort lautet: „Ich habe nichts zu verbergen“, was als Rechtfertigung dafür verwendet wird, dass man sich nicht die Mühe macht, eine Arbeitslast abzusichern. Dieser Benutzer hat vielleicht nichts zu verbergen, aber jemand anderes schon. Malware greift häufig in einen Workload ein, um von diesem Workload zu anderen Workloads zu springen, wobei das Ziel eine wertvollere Ressource ist. Dabei handelt es sich um eine laterale Bewegung, bei der ein Workload als Ausgangspunkt für einen anderen Workload genutzt wird.

Wenn es sich bei einer Vertrauensgrenze um ein Netzwerksegment handelt und Malware eine von mehreren Workloads in diesem Netzwerksegment durchbricht, kann sie sich lateral zwischen Workloads bewegen, die sich ein Segment teilen, ohne dass die Netzwerk-Firewall etwas bemerkt. Seitliche Bewegungen müssen bei jeder einzelnen Arbeitslast verhindert werden, nicht in der Netzwerkstruktur.

Labels sind nützlich, um Richtlinien verständlicher zu machen und das eigentliche Ziel im Blick zu behalten: die Sicherheitslösung auf das ausdehnen, was Sie schützen möchten. Verlassen Sie sich nicht auf eine Ebene einer Cloud-Architektur, um eine andere Ebene abzusichern. Ihre Vertrauensgrenzen liegen überall dort, wo sich Ihre Workloads befinden. Zero Trust bedeutet, dass jeder Workload ein Segment ist. Wenn Sie jeden Workload sichern, reduzieren Sie das Risiko einer seitlichen Verschiebung drastisch.

Um mehr über Illumio ASP zu erfahren und wie wir über Etikettierung denken, schauen Sie sich Folgendes an:

• Neues Video auf der Macht der Etiketten
• Das Illumio ASP Designleitfaden