Adaptive Segmentationmicro-segmentation September 15, 2020

NATÜRLICHE SPRACHE UM MIKROSEGMENTIERUNGS-POLICY ZU DEFINIERN UND ZU VEREINFACHEN

Christer Swartz, Principal Technical Marketing Engineer

Von den drei Basisresourcen im Rechenzentrum oder in der Cloud – Compute, Storage und Netzwerk – ist das Netzwerk der Teil, der am sich am langsamsten in die moderne Welt der Virtualisierung und Abstraktion entwickelt hat. Der Grund dafür liegt im Design. Die neudeutsch Netzwerk-Fabric (Netzwerk-Infrastruktur) ist meist die kritischste Ressource in jedem Rechenzentrum oder Cloud-Architektur. Ohne das Netzwerk sind Compute und Storage Inseln ohne Fähranschluss. Das Netzwerk erlaubt Zugriff und Kommunikation zwischen Compute- und Storage-Ressourcen, untereinander, aber auch von End-Usern auf diese Ressourcen. Ohne das darunter liegende Netzwerk sind alle Cloud-Themen obsolete. Und egal wie weit man Compute von der Hardware abstrahiert, ist die IP Kommunikation, also das Netzwerk, zwischen Ressourcen die kritische Komponente

Wir setzen dies voraus und das Netzwerk hat seine eigene Art der Virtualisierung um spezifische Netzwerkprobleme zu lösen. Wir erwähnen es hier aber trotzdem, da Security in Rechenzentren oder der Cloud traditionell über das Netzwerk implementiert wurde. Um Traffic zwischen Cloud-Ressourcen zu blocken oder zu erlauben wird irgendwo in der Netzwerk-Fabric der Cloud eine Firewall implementiert. Oft wird Endpoint-Software auf Compute-Ressourcen installiert, die normalerweise signatur-basiert sind und sich um bekannte Malware oder bekannte bösartiges Verhalten kümmern und oft auch Traffic untersuchen, aber auch oft weder blocken noch explizit erlauben. Die meisten Workloads (auch: Host, Server, Instanz, Pod, Container) haben irgendeine Art eingebauter Firewall-Fähigkeiten, wie zum Beispiel iptables unter Linux, aber die Kontrolle und Steuerung dieser Tools in einer größeren Umgebung ist schwer, und wird deswegen, selten genutzt. Also fallen wir zurück zu dem was wir kennen, Netzwerk-Sicherheit und die Steuerung des Traffic-Flusses mithilfe von Netzwerk-Firewalls.

Sicherheit spricht oft eine unterschiedliche Sprache

Weil Firewalls normalerweise vom Netzwerk-Team verwaltet werden wird auch die Sicherheits-Policy mit den Begriffen geschrieben, die dieses Team spricht. Firewalls existieren seit Jahrzehnten und die Art wie sie verwaltet werden hat sich in den letzten Jahren nur unwesentlich geändert. Policy Regeln werden traditionell mit IP-Adressen, TCP/UDP Ports, VLANs, Zonen und Interfaces ausgedrückt. Firewalls sind nicht wirklich dafür gebaut tiefer in Pakete zu schauen um nicht einen Flaschenhals im Netz zu erzeugen. Tun sie es doch, werden sie unverhältnismäßig teuer.

Es gibt natürlich sogenannte Next-Generation Firewalls (NGFW), die viel tiefer in Pakete schauen können und dennoch den theoretischen Durchsatz der Infrastruktur schaffen. Mit ihnen kann man Policy auf Basis des Paketinhalts definieren und nicht nur auf Basis der IP und TCP/UDP Header. Alte Gewohnheiten sind schwer abzulegen und in in der Realität werden diese Firewalls oft nur als Paketfilter benutzt. Die Einrichtung von Regeln auf Basis des Paketinhalts ist schwer und fehleranfällig und schwer zu skalieren. Am Ende des Tages haben wir ein Gerät, das mit Netzwerk-Begriffen Netzwerk-Sicherheit implementiert – das ist nicht die Art wie Benutzer und Anwendungsverantwortliche die Resourcen benennen, die in Rechenzentren und der Cloud leben. Diese Mitarbeiter wissen nicht, und interessieren sich auch oft nicht dafür, in welchem Netzwerksegment eine Ressource gehostet wird. Ihr Interesse gilt der Ressource selbst.

Policy sollte wiederspiegeln wie Benutzer den Schutzbedarf sehen

Wenn ein Benutzer oder Entwickler ein Problem meldet, wie zum Beispiel, dass eine Ressource nicht erreichbar ist, die in einem bestimmten Rechenzentrum oder der Cloud ist, dann beschreiben sie meist den Workload oder die Applikation, die nicht erreichbar ist. Sie sprechen normalerweise nicht, dass eine spezifische IP über einen bestimmten Port nicht erreichbar ist. Aber das Netzwerk-Team wird diese Information verlangen und vom Melder einfordern. Genau hier liegt das Problem. Das gemeldete Problem wird in einer anderen Sprache gemeldet, die vollkommen unterschiedlich ist von der Sprache, die Firewalls und andere Netzwerksicherheits-Geräte sprechen. Die Sprache der Anwendungen ist eine völlig andere als die Sprache der Netzwerker.

Ein wichtiges Detail ist bei der Suche nach der Automatisierung von möglichst vielen Ressourcen wie möglich in Cloud Architekturen, ist die Fähigkeit Netzwerk-Policy mit den selben Begriffen, die auch der User versteht, zu verwenden. Wenn eine Firewall den Traffic zwischen den Applikationen X, Y und Z steuert, dann sollte es möglich sein Policy so zu beschreiben und nicht die jeweiligen Netzwerk-Begriffe zu verwenden.

Besonders relevant ist dies in modernen Public-Cloud Infrastrukturen, zum Beispiel bei Microservices, in denen IP Adressen sehr kurzlebig sind. Workloads und Anwendungen werden sehr dynamisch zwischen verschiedenen Netzwerksegmenten umgezogen, die IP-Adresse ist also kein zuverlässiger Weg mehr eine Ressource zu benennen. Wenn man in diesem Szenario bei jeder IP-Änderung eine Firewall-Regel ändern müsste skaliert dieser Ansatz nicht mehr. Eins der Szenarien, die moderne Entwicklungsteams besonders fürchten.

Das Resultat ist sehr oft, dass Firewalls gar nicht erst in modernen Cloud-Architekturen implementiert werden. Stattdessen benutzt man sie am Rand der Cloud-Fabric, wo sie meist nur Nord-Süd Traffic kontrollieren und den großen Rest des Ost-West Traffics gar nicht erst sehen können.

Definieren von Security über Metadaten (und nicht mehr IPs)

Die meisten SDN Controller haben eine lokale Datenbank von Workload IP Adressen und Metadaten, die sie auf jeden Workload anwenden. Ein Beispiel: Man hat fünf SQL Server, die produktiv sind, fünf weitere, die Entwicklungsserver sind. Der Controller wird daraufhin die Server in zwei Kategorien einordnen, die ersten fünf IP-Adressen mit dem Metadatum „SQL-Production“, die zweiten fünf als „SQL-Development“. Wenn der Controller erkennt, dass sich eine der Adressen ändert, oder plötzlich nicht mehr verfügbar ist, dann wird er die Datenbank mit den IP-Adressen und Metadaten ändern.

So kann der Controller den ganzen Lebenszyklus des Workloads überwachen, ganz unabhängig davon welche IP dieser Workload hat. Die Weiterleitung von Paketen zu den Workloads läuft natürlich weiter über IP mit der jeweils gültigen Adresse. Aber die Identität des Workloads wird über die Metadaten festgestellt und ist unabhängig vom unterliegenden Netzwerksegment.

Dass wir den Workload über Metadaten ansprechen erlaubt uns, dass wir ihn vollkommen von allen Netzwerkdetails identifizieren können – so muss moderne Security definiert werden. Eine Regel wie „Kein SQL Server in der Entwicklung kann Verbindungen zu SQL Servern in der Produktion aufbauen“ ist viel näher an der Wahrnehmung von Usern als etwas wie „192.168.10.0/24 TCP 1024-2000 10.10.0.0/16 permit“. Metadaten sind schlicht viel einfacher für Menschen zu lesen und zu verstehen.

Das Benutzen von Metadaten um Ressourcen zu identifizieren wird auch oft als „Tag“ oder „Label“ bezeichnet und wird auch von anderen Controllern als nur SDN Controllern verwendet.

Mit Illumio ASP, kann man jedem Workload Label geben und diese Label haben vier Dimensionen: Role, Application, Environment und Location. Jeder Workload kann eins oder mehrere dieser Label erhalten und man definiert Policy ebenfalls über diese Label. Ein Ruleset in Illumio spricht nicht von Source-IPs oder Destination-IPs, sondern von Labeln.

labels

Der Wert der Labels in Illumio

Das Konzept der Label mag auf den ersten Blick nur ein kleines, unwichtiges Details ein, aber es kann gar nicht genug betont werden. Mit Labeln kann man Policy definieren, so wie User den Schutz von Resourcen verstehen. Das ist eine wichtige und große Änderung in der Art wie wir Security traditionell definieren. Über Jahrzehnte haben wir Security mit Netzwerk-Konstrukten definiert: IP-Adressen, VLANs, Ports. Das ist wie Firewalls Security verstehen, wenn sich eins dieser Dinge ändert muss die Firewallkonfiguration bereits angepasst werden.

Wählt man Label um Policy zu definieren und benutzt diese Label um die interne Firewall von Workloads zu konfigurieren auf Basis der definierten Regeln, entspricht die Policy der Art wie Ressourcen wirklich genutzt werden. Die Security wird über menschlich lesbare und verständliche Regeln definiert und nicht in Netzwerksprache. Diese Regeln werden einmal definiert und gelten auch wenn Workloads Netzwerkgrenzen passieren oder ihre IP-Adressen ändern, wenn sie herunterfahren und plötzlich in einer Cloud-Infrastruktur wieder hochfahren oder die ganze Umgebung plötzlich massiv wächst.

Security sollte nicht im Weg stehen wenn es darum geht Umgebungen zu skalieren. Mit natürlicher Sprache in der Definition der Policy – mit Hilfe von Labeln – können wir beliebig skalieren ohne den DevOps Prozeß und unsere Agilität zu verlangsamen.

Jetzt benutze ich also Label: Wie geht es weiter?

Selbst wenn die Netzwerk-Teams Policy mit Labeln und natürlicher Sprache definieren ist das dahinterstehende Denkmuster oft noch netzwerkorientiert. Während die Label auf den Workload zentriert sind, denken wir Netzwerker oft in Zonen als die Grenzen eines Netzwerks. Mit dem Einzug eines Zero Trust Gedankens in viele Unternehmen jedoch werden diese Zonen mit implizierten Trust immer kleiner und bewegen sich in Richtung der jeweiligen Ressourcen, also den Workloads. Wenn man sich die fünf SQL Server aus unserem vorherigen Beispiel betrachtet, dann ist jeder dieser Workloads eine eigene Zone, und nicht etwa ein gemeinsames Segment in dem all diese Server sitzen.

Illumio benutzt Agenten, sogenannte VENs (Virtual Enforcement Nodes) auf jedem beobachteten Workload. Diese Agenten erhalten die von einer label-basierten Policy errechneten Firewall Regeln und transferieren diese in die Firewall des Workloads (iptables, Windows Filtering Platform, etc.). Bereits wenn ein Paket also die Applikation verlässt wird es schon von Policy kontrolliert. Eine extreme Form von Zero Trust ist: „Kein Paket soll jemals das Netzwerk erreichen, bevor es nicht kontrolliert wurde.“ Mit Illumio ist jedes weitergeleitete Paket bereits kontrolliert worden.

Dies ist umso wichtiger, wenn wir das Problem des Lateral Movements betrachten, das es böswilligen Akteuren oder Malware erlaubt ein Netzwerk ungehindert zu passieren und sich weiterzuverbreiten. Wenn man z.B. die Sicherheitsrichtlinien mit Benutzern diskutiert, die remote arbeiten erkennen diese natürlich den Sicherheitsbedarf, entgegnen aber oft: „Ich habe nichts zu verbergen“, was oft als Ausrede benutzt wird um für diesen Workload keine Sicherheitsmaßnahmen einzuleiten. Natürlich hat dieser User selbst meist nichts zu verbergen, aber vielleicht hat jemand anderes etwas zu verbergen. Malware gelangt oft unbemerkt auf Geräte und wartet dann darauf sich auf eine bessere Ressource zu verbreiten. Lateral Movement in Reinkultur, eine schwache Ressource wird als Brückenkopf im Netz benutzt um dann weitere, interessantere Ziele zu erreichen.

Ist das Netzwerk-Segment die Zone, der man vertraut und eine Malware befällt einen von vielen Workloads in diesem Segment, so kann diese Malware sich ungehindert zwischen den Workloads in diesem Segment weiterverbreiten, ohne, dass die Netzwerk-Firewall dies überhaupt bemerkt. Lateral Movement MUSS auf jedem Workload verhindert werden, nicht in der Netzwerk-Fabric.

Label sind großartig um Policy zu erleichtern und das finale Ziel im Auge zu behalten: Die Sicherheit da zu etablieren wo der Schutz wirklich gebraucht wird. Man sollte nicht auf einer Ebene Sicherheit etablieren, wenn man eine andere Ebene schützen will. Die Grenzen des Vertrauens sind da wo auch die Workloads sind. Zero Trust bedeutet, dass jeder Workload ein eigenes Segment für sic hist, und wenn man jeden Workload sichert, so geht die Möglichkeit von Lateral Movement tatsächlich gegen Null.

Um mehr über Illumio ASP und wie wir über Label denken zu erfahren, empfehlen wir Ihnen auch:

Adaptive Segmentationmicro-segmentation
Share this post:

Try Illumio Edge