Nutzung natürlicher Sprache zur Definition und Vereinfachung von Mikrosegmentierungsrichtlinien

Von den drei grundlegenden Ressourcen in jedem Rechenzentrum oder jeder Cloud – Rechenleistung, Speicher, Netzwerk – hat sich das Netzwerk am langsamsten in die moderne Welt der Ressourcenvirtualisierung und -abstraktion entwickelt. Das ist weitgehend beabsichtigt. Man kann argumentieren, dass die Netzwerkstruktur die wichtigste 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 zu den Endbenutzern dieser Ressourcen. Ohne das Netzwerk, das einer Architektur zugrunde liegt, sind alle Cloud-Konversationen bedeutungslos. Unabhängig davon, wie weit Sie Cloud-Konversationen über Rechenressourcen abstrahieren, von Bare-Metal bis Serverless, wenn irgendwo im Bild ein IP-Paket vorhanden ist, ist das Netzwerk von entscheidender Bedeutung.

Die Netzwerksicherheit wird jetzt in natürlicher Sprache und nicht in der Netzwerksprache definiert.

Dies ist gesunder Menschenverstand, und Netzwerke haben ihre eigenen Formen der Ressourcenvirtualisierung, die dazu gedacht sind, bestimmte Netzwerkprobleme zu lösen. 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 Netzwerkdatenverkehr während der Übertragung zwischen Cloud-Ressourcen zu blockieren oder zu aktivieren, wird eine Firewall an einer beliebigen Stelle in der Netzwerkstruktur bereitgestellt. Endpunktsoftware kann auf Rechenressourcen bereitgestellt werden, bei denen es sich in der Regel um signaturbasierte Tools handelt, die nach bekannter Malware oder schlechtem Verhalten suchen, aber diese überprüfen im Allgemeinen den Datenverkehr, blockieren oder lassen ihn nicht zu. Die meisten Workloads verfügen über eine Art integrierter Firewalling-Funktionen, z. B. iptables in Linux, aber die Orchestrierung dieser Tools in großem Maßstab ist oft schwer zu verwalten und wird daher nicht verwendet. Daher werden die Netzwerksicherheit und die Durchsetzung des Datenverkehrs traditionell mit Netzwerk-Firewalls durchgeführt.

Sicherheit wird oft in einer anderen Sprache definiert

Da Firewalls in der Regel von Netzwerkteams verwaltet werden, werden Sicherheitsrichtlinien in den meisten Fällen mit Begriffen definiert, die Netzwerkteams vertraut sind. Firewalls gibt es schon seit Jahrzehnten, und die Art und Weise, wie sie konfiguriert sind, hat sich im Laufe der Jahre nur minimal verändert. Richtlinienregeln werden traditionell mithilfe von IP-Adressen, TCP/UDP-Ports, VLANs und Zonen geschrieben. Firewalls sind in der Regel nicht darauf ausgelegt, die Datennutzlast von Paketen genauer zu untersuchen, um zu überprüfen, welche Inhalte oder Anwendungen enthalten sind, da sie vermeiden wollen, zu einem Engpass im Netzwerkverkehr zu werden.

Es gibt sogenannte Next-Generation-Firewalls (NGFW), die in der Lage sind, Pakete mit Leitungsgeschwindigkeit viel tiefer zu untersuchen und Richtlinien für das zu definieren, was tatsächlich in der Datennutzlast eines Pakets enthalten ist, und nicht nur in seinen Netzwerkheadern. Aber da alte Gewohnheiten nur schwer sterben, ist die Realität, dass diese Firewalls oft auf die alte Weise konfiguriert werden und die Optionen der nächsten Generation ungenutzt bleiben. Das Ergebnis ist ein Gerät, das Netzwerkterminologie verwendet, um die Netzwerksicherheit zu definieren, was nicht der Art und Weise entspricht, wie Benutzer von Ressourcen, die in einem Rechenzentrum oder einer Cloud gehostet werden, diese Ressourcen wahrnehmen. Benutzer wissen oft nicht oder es ist ihnen egal, in welchem Netzwerksegment eine Ressource gehostet wird. Sie beschäftigen sich mit der Ressource selbst.

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

Wenn ein Benutzer oder Entwickler ein Problem meldet, z. B. dass eine Ressource, die in einem Rechenzentrum oder einer Cloud gehostet wird, nicht erreichbar ist, bezieht er sich in der Regel auf die spezifische Workload oder Anwendung, die nicht erreichbar ist. Sie melden in der Regel nicht, dass eine bestimmte IP-Adresse über einen bestimmten Port nicht erreichbar ist. Die Netzwerk- oder Sicherheitsbetriebsteams fordern diese Informationen jedoch an. Und hier tritt das Problem auf: Das gemeldete Problem ist in einer anderen Sprache als die Geräte, die die Netzwerkrichtlinie durchsetzen. Anwendungssprache ist in der Regel nicht gleichbedeutend mit Netzwerksprache.

Ein wichtiges Detail bei der Automatisierung so vieler Ressourcen wie möglich in Cloud-Architekturen ist die Möglichkeit, Netzwerkrichtlinien mit denselben Begriffen zu definieren, die Benutzer als die zu schützenden Ressourcen wahrnehmen. Wenn eine Firewall Richtlinien zwischen den Anwendungen X, Y und Z erzwingt, 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 Public Cloud gehosteten Infrastrukturen, wie z. B. Microservices, in denen IP-Adressen kurzlebig sind. Workloads und Anwendungen werden häufig dynamisch über verschiedene Netzwerksegmente migriert, sodass eine IP-Adresse keine zuverlässige Methode mehr ist, um eine bestimmte Workload 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 sind sie darauf angewiesen, am Rand einer Cloud-Fabric zu sitzen und nur den Nord-Süd-Datenverkehr zu erzwingen, während der Großteil des Ost-West-Datenverkehrs blind ist.

Definieren Sie Sicherheit anhand von Metadaten, nicht von IPs

Die meisten modernen SDN-Controller können eine lokale Datenbank mit Workload-IPs und Metadaten erstellen, die auf jeden Workload angewendet wird. Wenn z. B. fünf Produktionsworkloads SQL-Server und weitere fünf Workloads Entwicklungs-SQL-Server sind, erstellt der Controller einen lokalen Datensatz, in dem diese Server in zwei Kategorien aufgelistet sind, wobei die ersten fünf Workload-IPs dem Metadaten-Tag "SQL-Prod" und die zweiten fünf Workload-IPs einem Metadaten-Tag von "SQL-Dev" zugewiesen sind. Der Controller überwacht diese Workloads, und wenn eine Workload ihre IP aus irgendeinem Grund ändert oder wenn sie heruntergefahren wird, aktualisiert der Controller seine lokalen Datensätze von Metadaten-zu-IP-Zuordnungen.

Auf diese Weise kann der Controller den gesamten Lebenszyklus der Arbeitslast auf der Grundlage 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 dieser Workload wird jedoch durch die ihnen zugewiesenen Metadaten beibehalten, unabhängig davon, welchem Netzwerksegment sie zugewiesen ist.

Durch die Identifizierung eines Workloads mithilfe von Metadaten kann die Identität dieses Workloads vollständig von allen Netzwerkdetails abstrahiert werden – so muss moderne Sicherheit definiert werden. Das Definieren von Richtlinien, die so etwas wie "Kein SQL-Server in der Entwicklung kann Kontakt mit SQL-Servern in prod initiieren" lautet, ist viel näher daran, wie Benutzer diese Ressourcen wahrnehmen, als etwas wie das Definieren einer Richtlinie, die als "192.168.10.0/24" lautet TCP 1024-2000 10.10.0.0/16 Genehmigung." Metadatenbegriffe sind viel besser für Menschen lesbar als Netzwerkbegriffe.

Die Verwendung von Metadaten zur Identifizierung von Ressourcen wird in der Regel als "Tags" oder "Labels" bezeichnet. Und dieses Konzept wird von anderen Controllern als SDN verwendet. Mit Illumio ASP können Sie jeder Workload eine Bezeichnung zuweisen, und jede Bezeichnung hat vier "Dimensionen": Rolle, Anwendung, Umgebung und Standort. Jeder Workload kann eine Bezeichnung zugewiesen werden, die sie anhand einer oder aller dieser Dimensionen identifiziert, und mithilfe dieser Bezeichnungen kann dann eine Richtlinie definiert werden. Ein Illumio-Regelsatz bezieht sich also nicht auf Ports oder IPs; Es bezieht sich auf Etiketten.

Der Wert von Illumio-Labels

Das Konzept der Labels mag wie ein kleines Detail erscheinen, aber es lohnt sich, es zu betonen. Mithilfe von Bezeichnungen können Sie Richtlinien mit den gleichen Begriffen definieren, die angeben, wie Benutzer die zu schützenden Ressourcen wahrnehmen. Dies ist eine wesentliche Änderung gegenüber der traditionellen Definition von Netzwerksicherheit. Seit Jahrzehnten wird Netzwerksicherheit um Netzwerkkonstrukte herum definiert: IPs, VLANs und Ports. Firewalls betrachten die Sicherheit durch die Linse dieser Netzwerkkonstrukte, und wenn sich eines dieser Konstrukte ändert, muss die Firewallkonfiguration geändert werden.

Wenn die Richtlinie jedoch mithilfe von Bezeichnungen definiert wird und diese Bezeichnungen dazu führen, dass die integrierten Firewallfunktionen der Workload so konfiguriert werden, dass diese Definition im Hintergrund erzwungen wird, entspricht die Richtlinie jetzt der tatsächlichen Verwendung von Ressourcen. Die Netzwerksicherheit wird jetzt in natürlicher Sprache und nicht in der Netzwerksprache definiert. Und diese Richtlinie für natürliche Sprache wird einmal definiert und bleibt auch dann ruhig, wenn Workloads über Netzwerk-Fabrics migriert, herunter- oder hochgefahren 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 Weiterentwicklung der Workloads, ohne dass die Sicherheit den DevOps-Prozess verlangsamt.

Also verwende ich Labels: Was nun?

Auch wenn sich Netzwerkteams daran gewöhnt haben, Richtlinien mit natürlichen Sprachetiketten zu definieren, um eine für Menschen lesbarere Sprache zu schaffen, ist die Denkweise hinter der Richtliniendefinition immer noch oft netzwerkzentriert. Während sich die Bezeichnungen auf Workloads und Anwendungen beziehen, betrachten Netzwerkteams Vertrauensgrenzen immer noch als Netzwerkgrenzen. Da jedoch immer mehr Unternehmen eine Zero-Trust-Denkweise annehmen, erfordert ein wichtiges Merkmal, dass Unternehmen die Vertrauensgrenzen weg vom Netzwerk und direkt auf die Ressourcen verschieben, auf die sich die Labels beziehen. Wenn Sie über fünf SQL-Workloads verfügen, ist jede dieser Workloads eine eigene Vertrauensgrenze. Die Vertrauensgrenze ist kein gemeinsames Netzwerksegment, das sie möglicherweise alle gemeinsam nutzen.

Illumio setzt Agenten, die als VENs bekannt sind, auf jedem überwachten Workload ein, und diese Agenten übersetzen die labelbasierte Richtlinie in Regeln für die integrierte Firewall für jeden Workload. Der erste Schritt im Leben eines Pakets, bei seiner Geburt, ist also die Politik. Eine andere Möglichkeit, über Zero Trust nachzudenken, ist: "Kein Paket darf die Netzwerkweiterleitungsebene erreichen, bis es überprüft wurde." Mit Illumio ist die Sicherheit bereits angewendet, wenn ein Paket die Netzwerkweiterleitungsebene erreicht.

Dies ist besonders wichtig, wenn versucht wird, das Problem der lateralen Bewegung zu lösen, die es böswilligen Akteuren oder Malware ermöglicht, ein Netzwerk unentdeckt zu passieren. Bei der Besprechung von Sicherheitsrichtlinien mit Remote-Benutzern wird beispielsweise in der Regel der Sicherheitsbedarf erkannt, aber eine häufige Antwort ist "Ich habe nichts zu verbergen", was als Rechtfertigung dafür verwendet wird, sich nicht die Mühe zu machen, eine Workload zu sichern. Während dieser Benutzer vielleicht nichts zu verbergen hat, könnte es jemand anderes tun. Malware verletzt häufig einen Workload zu dem Zweck, von diesem Workload zu anderen Workloads zu wechseln, wobei das Ziel eine wertvollere Ressource ist. Dabei handelt es sich um eine laterale Bewegung, bei der eine Arbeitslast als Startrampe für eine andere Arbeitslast verwendet wird.

Wenn es sich bei einer Vertrauensgrenze um ein Netzwerksegment handelt und Malware eine von mehreren Workloads in diesem Netzwerksegment verletzt, kann sie sich lateral zwischen Workloads bewegen, die ein Segment gemeinsam nutzen, ohne dass die Netzwerkfirewall etwas bemerkt. Lateral Movement muss bei jeder einzelnen Workload verhindert werden, nicht in der Netzwerkstruktur.

Labels sind nützlich, um Richtlinien leichter verständlich zu machen und das ultimative Ziel im Fokus zu behalten: die Sicherheitslösung auf das zu übertragen, was Sie zu sichern versuchen. Verlassen Sie sich nicht auf eine Schicht einer Cloud-Architektur, um eine andere Schicht zu sichern. Ihre Vertrauensgrenzen befinden sich dort, wo sich Ihre Workloads befinden. Zero Trust bedeutet, dass jeder Workload ein Segment ist, und wenn Sie jeden Workload sichern, reduzieren Sie das Risiko von Lateral Movement erheblich.

Um mehr über Illumio ASP und unsere Meinung zur Etikettierung zu erfahren, besuchen Sie:

• Neues Video über die Macht der Etiketten
• Der Illumio ASP Design Guide