Adaptive Segmentationmicro-segmentation September 15, 2020

5 TIPS UM DAS LABELLING FÜR DIE MIKROSEGMENTIERUNG ZU ERLEICHTERN

Russell Goodwin, Field CTO, EMEA

IP Adressen haben eine Struktur, die sowohl Maschinen als auch Menschen verstehen können. Wenn man jemandem eine Kombination von Zahlen wie z.B. 192.168.1.254 zeigt, so verstehen viele das sofort. Die einfache Struktur ermöglicht es die Information schnell zu verarbeiten und zu verstehen. Deswegen kann das Internet so skalieren und funktionieren und die Hierarchie von IP-Adressen und Netzen ermöglicht es schnell die Zusammenhänge und Architektur zu verstehen.

Was wäre wenn man einen alternativen Ansatz wählt: eine Welt, in der man völlig freie Strukturen definieren kann. Was wäre wenn man in einer Minute 192.179.134.56.245.23 und in der nächsten 24.87 wahrnehmen würde. Wie kann man mit diesen Informationen Zusammenhänge erschliessen. Sicher, Flexibilität wird oft als ein positives Feature gesehen, aber in der Welt der Netze und genauso im Benennen von Objekten in Netzwerken resultiert das o.a. Beispiel in Verwirrung und überbordender Komplexität. Und im schlimmsten Fall führt es zu Inkonsistenzen in der Policy und ähnlich gelagerten Problemen, die wir alle schon bei traditionellen Firewalls oder Gruppen in Active Directory gesehen haben.

Seit einigen Jahren nun heften wir Tags an Objekte um eine Vielzahl von Attributen zu vergeben um diese Objekte zu identifizieren und zu gruppieren. Wozu hat das geführt? Die Vielzahl an Tags führt dazu, dass Dinge nicht mehr skalieren und schwer verwaltbar sind. Ohne eine Struktur ist es schwer eine Architektur über längere Zeit aufrecht zu erhalten und der Ansatz Dinge einfach zu halten führt zu einer leichteren Verwaltbarkeit und Skalierbarkeit von Dingen im Vergleich zu völlig freiem Tagging. Nicht umsonst werden bei all diesen Ansätzen irgendwann Tagging-Policies eingeführt, die diese Dinge verhindern sollen, aber natürlich meist wirkungslos verpuffen.

Illumio hat dieses Problem bereits frühzeitig gesehen und wir haben bewusst Struktur und Einfachheit gewählt um einen skalierenden Betrieb gewährleisten zu können.

Ganz einfach gesagt, Labels sollten einfach zu benutzen, vorhersehbar und einfach zu verstehen sein.

Wir wollen Ihnen 5 Tips geben um das Labelling von Workloads zu erleichtern:

1. Benutzen Sie ein 4-dimensionales Label-Schema

Wir ordnen Workloads (Server, Container, VMs) mit einigen einfachen und selbsterklärenden Parametern:

  1. Location: Wo ist der Workload, dies könnte eine Stadt, ein Land oder der Name eines Cloud Providers sein
  2. Environment: Ist dieser Workload in Produktion, Entwicklung, QA, Test?
  3. Application: Der Applikationsname, ist dies Teil einer Finanzapplikation oder von SAP oder des CRMs?
  4. Role: Die Rolle dieses Servers, geht es um einen Applikationsserver oder einen Webserver, um eine Datenbank oder eine Middleware?

Indem wir uns an diese einfachen Gruppen wie Rolle, Applikation, Umgebung oder Environment und Lokation (RAEL) halten können wir ein Metadaten-Modell bauen, das einfach verständlich, portabel und erweiterbar ist.

Diese Struktur erlaubt es uns Dinge von jeder der vier Dimensionen zu sehen und dabei gleichzeitig Kontrolle zu erhalten und Komplexität in der Berechnung zu vermeiden. Wären diese Labels für Fahrzeuge gemacht und wie folgt aussehen: „Typ | Hersteller | Modell | Farbe“, wäre es sehr einfach nur BMWs oder nur rote Autos zu finden.

Dabei sollte man nicht vergessen, dass diese Metadaten vorwiegend dazu dienen das Objekt zu beschreiben und nicht dazu die Beziehungen zu anderen Objekten zu beschreiben. Halten wir uns an dieses Prinzip und benutzen die Policy dazu die Beziehungen zu definieren und nicht die Metadaten selbst und werden den Rest der Tage glücklich sein – vertrauen Sie mir.

2. Legen Sie Sich auf ein Format fest

Obwohl wir als Menschen ganz einfach die Gemeinsamkeiten und Unterschiede in „Production“, „Prod“, „prod“ sehen wird es doch immer gelegentlich Schreibfehler oder ähnliches geben. In einem einfach strukturierten Modell mit vier Dimensionen fallen diese sehr schnell auf. In n-dimensionalen Modellen ist es schwierig den Fehler in „prod.fin.win.UK.CRM.web.bldg1.10“ zu finden.

3. Vorsicht beim Kürzen von Labelnamen

Wenn man beispielsweise ein Label wie „Production“ in „Prod“ kürzt und gleichzeitig Dinge wie „Database“ so belässt wie sie sind kann das zu Problemen führen. Zum Beispiel die Duplizierung von Labeln, die dann wiederum zu inkonsistenten Policys oder Supportproblemen beitragen kann. Wir empfehlen die vollen Namen zu benutzen (also Production, Development und Test) solange nicht die Kurzversion konsistent über ihre ganze Organisation verwendet wird (z.B. UAT).

Ein klassisches Beispiel hierfür ist, wenn plötzlich zwei Label existieren „Production“ und „Prod“. Wenn Workloads dann mit „Prod” gelabelt sind werden Regeln, die für “Production” gelten nicht mehr greifen.

Namensstandards sind nichts neues für uns und es gibt gute Gründe dafür.

4. Konsistent bleiben

Nicht nur beim Labeln selbst sollte man konsistent bleiben, man sollte auch in der Datenquelle für diese Metadaten Konsistenz bewahren. Wenn Sie in Ihrer CMDB oder in den Hostnamen bereits Standards für Metadaten haben sollten Sie nicht anfangen neue Konventionen für das Labelling festzulegen. Sollten Sie beim Ausrollen der Mikrosegmentierung feststellen, dass die Datenquelle für die Metadaten bereits inkonsistent ist, so ist das eine gute Gelegenheit diese zu bereinigen und die Datenqualität zu verbessern. Das hilft Ihnen bei einer ganzen Menge Dinge und die Organisation wird davon extrem profitieren, man denke nur an Automation, die ohne konsistente Metadaten kaum funktionieren kann.

Der erste Anwendungsfall für die Mikrosegmentierung ist vielleicht auf eine Umgebung oder Applikation limitiert. Dennoch ist es sinnvoll die Struktur der Label mit der ganzen Organisation abzugleichen, für den Fall, dass die Umgebung wächst. Einfache Label-Schemas sind skalierbarer und können leichter verwaltet werden.

5. Benutzen Sie Labels um unterschiedliche Dinge auseinanderzuhalten

Um Objekte auseinanderzuhalten bietet es sich an verschiedene Label zu nutzen. Oft gibt es Fälle in denen man versucht ist ein neues Label zu erstellen obwohl dieses Objekt in der Policy nicht anders behandelt werden wird als das bereits existierende Objekt. Für diesen Fall sollte man das neue Label nicht einführen, denn Metadaten helfen nicht nur Policy zu definieren sondern dienen auch der Sichtbarkeit und allgemeinen Verständlichkeit des Applikationstraffics und zur Definition von Rollen zum rollenbasierten Zugriff.

Mit diesem Umstand im Hinterkopf sollten sie möglichst allgemeine Namen verwenden wo immer möglich. Zum Beispiel benutzen Apache, Nginx und IIS die gleichen Ports und Protokolle (z.B. 80/TCP, 443/TCP). Also sollten wir diese Dinge konsequenterweise nur Web-Server nennen. In den meisten Fällen möchte man keine unterschiedlichen Policies für IIS und Apache schreiben.

Benutzen Sie unterschiedliche Labelnamen nur, wenn verschiedene Workloads auch verschiedene Policy brauchen. Zum Beispiel Oracle, IBM DB2 und MS SQL benutzen vollkommen verschiedene Ports und Protokolle und jeder hat eigene Anforderungen an die Security-Policy. Wir empfehlen hier verschiedene Rollen-Label zu definieren. Damit können Sie für den Oracle Enterprise Manager zum Beispiel erlauben, dass dieser nur zu Oracle-Servern, aber nicht zu Sybase-Servern sprechen darf.

Wie hilft Illumio?

Illumio ASP benutzt ein multi-dimensionales Metadatenmodell mit vier Dimensionen mit denen Objekte gelabelt und identifiziert werden können. Andere Produkte folgen dem Ansatz freie Tags vergeben zu können. Das sieht auf den ersten Blick so aus als würde es das Labelling erleichtern und flexibler machen, aber die Herausforderungen mit diesem Modell werden wachsen und das Modell skaliert nicht. Die Verwaltung steigt ins Unermessliche.

Je mehr Label-Dimensionen man vergibt, desto schneller endet man wieder bei einem eindimensionalen Modell wo jedes Tag auch zu einer Policy gehört. Am besten kann man das zum Beispiel am Beispiel von Active Directory erkennen, wo man für jeden neuen Anwendungsfall gerne eine neue Gruppe vergibt und dieser User zuordnet. Die Anzahl der Gruppen wächst rapide und es wird sich überschneidende Gruppen geben. Nicht selten sieht man Active Directorys, die mehr Gruppen als user haben. Genauso verhält es sich beim freien Tagging, irgendwann endet man mit mehr Tags als Objekten und jedes Objekt hat eine große Zahl von zugeordneten Tags.

Das führt dazu, dass Administratoren diese Tags auch allen Objekten zuordnen müssen. Das Resultat ist, dass bei jedem neuen Objekt (Workload bzw. Server) alle Tags vergeben werden müssen damit die Policy für dieses neue Objekt errechnet werden kann. In diesem Szenario wird man schnell an Skalierbarkeitsgrenzen stoßen und gleichzeitig wird die Datenqualität und -konsistenz leiden.

Viele von uns waren bereits in dieser Situation. Wir wollten Zugriff auf eine Resource und es stellt sich heraus, dass wir eine Gruppenzuordnung oder ein Tag zuwenig haben. Mit einem einfachen vierdimensionalen Modell ist das Labeln neuer Objekte sehr einfach, vorhersehbar, wiederholbar und einfach zu betreuen. Vererbung von Policy wird zum Kinderspiel und die Verwaltung der Policy wird dadurch ganz wesentlich verbessert.

Die Definition eines skalierenden und konsistenten Label-Schemas verlangt nach einem Umdenken im Prozeß wie Policy definiert wird, aber sobald man das Modell versteht erkennt man wieviel effektiver dieses Modell ist um Policy zu modellieren und zu verwalten.

Für mehr Informationen über Labelling in Illumio, folgen Sie bitte diesem diesem tollen Video unseres Chief Evangelisten, Nathanael Iversen.

Adaptive Segmentationmicro-segmentation
Share this post:

Try Illumio Edge