Thought Leadership
Den Begriff der Netzwerksegmentierung gibt es schon lange, er stammt aus der Notwendigkeit, performante Netze zu unterteilen, um Broadcast Zeiten zu verringern. Irgendwann kam das Konzept der Segmentierung zu Sicherheitszwecken dazu und die Geschichte nahm ihren Lauf.
Unternehmen setzen heute traditionelle Netzwerkarchitektur ein, um die Sicherheit im Rechenzentrum zu erhöhen und es Angreifern zu erschweren, sich weiter im Netz zu bewegen.
Hieraus entsteht Reibung und Interessenskonflikte, weil die traditionellen Netzwerktechnologien darauf optimiert sind, Leistung und Funktion zu erbringen, sie wollen offen und performant sein. Die Anforderungen der Sicherheit jedoch stehen dem entgegen, hier geht es um Kontrolle und Isolation, man will eben geschlossen sein. Diese widerstrebenden Interessenslagen sorgen für Probleme, die sich mit den Anforderungen moderner IT an Agilität, Cloud oder Container nicht vereinbaren lassen.
Gehen wir mal einen Schritt zurück: Warum setzen Unternehmen Segmentierungsprojekte auf die Tagesordnung? Hier sind einige dieser Gründe zu finden:
- Regulatorische Anforderungen und Compliance
- Schutz von Kronjuwelen und kritischen Applikationen
- Fusionen und Akquisitionen
- Einbruchsschutz und Schadensbegrenzung
- Cloud-Migrationen
- Firewall-Aktualisierungen
- Transport-Verschlüsselung im RZ
All diese Themenbereiche stehen im Konflikt mit der oben genannten Problematik der widerstrebenden Interessenslagen in der traditionellen Segmentierung. Aber muss das so sein? Und was benötigt ein Unternehmen, um diese initialen Treiber zu erfüllen?
Abhängigkeit von IP Adressen
Fragt man einen erfahrenen Netzwerkarchitekten, ob er ein Netz ohne Anforderungen aus der Security anders bauen und konfigurieren würde, bekommt man immer dieselbe Antwort: Auf jeden Fall. Die größte Herausforderung vor der Network Security Engineers stehen, ist die Abhängigkeit von IP Adressen und die damit verbundene fehlende Flexibilität. Kleine Änderungen werden damit zu großen Aufwänden, die meist gescheut werden. Segmentierung ist somit ein recht ungeliebtes Thema geworden.
Visibilität in die Datenflüsse
Es erscheint offensichtlich, dass man nur das segmentieren, also unterteilen kann, was man kennt und versteht. Wer schon einmal versucht hat, den Datenverkehr in einem RZ zu analysieren und zu dokumentieren, wird nachvollziehen können, dass die Forderung an Transparenz leicht gestellt und schwer erfüllt wird. Technologien wie Cloud und Container erschweren die Erledigung dieser Anforderung noch ungemein. Jeder technisch versierte Administrator wird Tools wie Wireshark kennen und nutzen, dann aber feststellen, dass eine Echtzeitbetrachtung des gesamten Datenverkehrs in einem RZ und auch in Richtung der neueren RZ Technologien damit unmöglich ist. Die erste Forderung an ein Segmentierungsprojekt muss also lauten, Visibilität zu erzeugen.
Zentral gemanagte Enforcement Punkte
Solange man sich innerhalb eines abgeschlossenen RZ befindet, scheint es logisch durch Einsatz von Firewalls abgeschlossene Segmente zu produzieren. Erstreckt sich ein Unternehmen und dessen Applikationen über mehrere RZs, wird dies schon erheblich schwieriger und nahezu unmöglich, wenn man Cloud Infrastruktur Services wie Azure oder AWS verwendet. Hier hat der Einzelne keine Kontrolle mehr über die Datenflüsse und Enforcement Punkte, sondern muss sich auf diverse Komponenten verlassen. Hier sind unterschiedliche Firewall Hersteller, Security Groups, Security Tags, VLANs genannt, die ebenfalls nicht zentral verwaltet werden können, durch ihre Unterschiedlichkeit zu administrativen Bürden werden und somit zu Fehlkonfigurationen führen.
Nimmt man nur diese drei Punkte alleine, erklärt sich gut, dass traditionelle Segmentierung durch die Netzwerk-Architektur an einem Ende angekommen ist und es neuer Wege bedarf. Eine ähnliche Situation haben wir bereits schon einmal erlebt. OS Virtualisierung folgte demselben Muster. Es erschien unglaublich, ein Betriebssystem, eine Applikation von der Hardware zu trennen. Mittlerweile trennt man sogar die Komponenten einer Applikation selber auf und Virtualisierung ist Mainstream.
Um Segmentierung erfolgreich, agil und schlussendlich kostengünstig gestalten zu können benötigt man also ein paar Voraussetzungen:
- Eine Unabhängigkeit von IP-Adressen
- Eine Landkarte der Verkehrsflüsse
- Einen zentralen, einheitlichen Prozess
Jedes Unternehmen verfügt über mehr oder weniger gute Informationen über die eingesetzten Systeme und Server, meist im Rahmen einer CMDB, einer Asset-DB oder anderem. Diese Quellen enthalten beschreibende Informationen über die Systeme, die sich meist in Form von Labeln darstellen. Wo steht ein Server, was für eine Applikation unterstützt der Server, zu welcher Umgebung (Test, Dev, Prod) gehört der Server und oftmals auch, welche Rolle nimmt der Server ein, also Web-, Application- oder DB-Server. Mit Hilfe dieser Daten ist es ein leichtes, Regeln zu schreiben, die im Klartext und verständlich sind: „Der Webserver der CRM Applikation in der produktiven Umgebung in Deutschland darf nur mit den ProcessingServer der produktiven Umgebung in Deutschland sprechen“ oder noch einfacher: „Systeme in der DevUmgebung dürfen nur mit Systemen in Dev sprechen“. Die Abwesenheit von IP-Adresse, die Abstrahierung über Label ermöglicht vollkommen neue Segmentierungsregeln.
„Man kann nicht segmentieren, was man nicht sieht!“ Eine einfache Regel. Es wird also eine Darstellung der Kommunikation zwischen den einzelnen Servern benötigt. Wer spricht mit wem, grafisch aufbereitet. So erkennt man sofort Fehlkonfigurationen, kann Systemgrenzen festlegen und die Kommunikation innerhalb einer Applikation analysieren und verstehen.
Eine Landkarte, ähnlich Google Maps, in der die Systeme wie Orte sind, die Kommunikation wie Straßen sind und Verkehrsflüsse dargestellt werden, das ist die Grundlage einer erfolgreichen Segmentierungsstrategie und das Kernelement von guten Lösungen. Aus dem Wissen über die faktisch vorhandene Kommunikation kann man dann Regeln ableiten und Systeme schützen.
Das schwächste Glied der Kette
Jeder Firewall Admin kennt die Situation nur zu gut, man hat eine neue Regel implementiert und es beginnt der Moment der gespannten Erwartung. Wird das Telefon klingeln? Habe ich einen Fehler gemacht? Geht alles gut? Die Komplexität von Firewall Regeln ist nicht für Segmentierungsregeln gemacht worden, jedes System hat seine eigenen Logiken, jeder Cloud Service seinen eigenen Gesetze. Man benötigt also ein zentrales System, das die vorhandenen Firewalls der jeweiligen Server kennt und administrieren kann.
Diesem System zugrunde muss ein Prozess liegen, in welchem man die vorhandenen Verbindungen darstellen kann, auf Basis derer dann Regeln gebaut und diese sicher getestet werden können. Der Test implementiert bereits die erstellten Regeln, fügt aber ein Sicherheitsnetz ein, über welches unerkannte Flows gemeldet und dann bewertet werden können. Erst danach werden diese Regeln scharf geschaltet und die Systeme von der restlichen Umgebung abgetrennt.
Durch diese quasi Virtualisierung der Segmentierung wird sie nutzbar und ermöglicht Unternehmen die eingangs erwähnten Anforderungen auch zu erfüllen.
Oliver Keizers, Regional Director, DACH Illumino, www. illumio.com
