5 Tipps zur Vereinfachung der Workload-Kennzeichnung für Mikrosegmentierung

IP hat eine Struktur, die jeder und jede Maschine verstehen kann. Wenn Sie jemandem einen 4-dimensionalen Satz von Zahlen wie 192.168.1.254 zeigen, werden viele dies sofort erkennen. Durch die einfache Struktur sind die Informationen leicht zu konsumieren und zu verstehen. Das ist es, was das Internet skalieren und funktionieren lässt. Und für diejenigen, die damit arbeiten, bietet seine Hierarchie sofortige Einblicke.

Stellen Sie sich die Alternative vor: eine Welt, in der Menschen willkürliche Strukturen definieren. Was wäre, wenn du in einer Minute 192.179.134.56.245.23 siehst und in der nächsten 24.87? Wie finden wir heraus, wie diese miteinander in Beziehung stehen?

Wir betrachten Flexibilität und Willensfreiheit zwar als positiv, aber in der Welt der Netzwerkadressierung — und ebenso bei der Kennzeichnung von Arbeitslasten (insbesondere in Mikrosegmentierung) — es kann zu Verwirrung und Komplexität führen. Letztlich führt dies zu inkonsistenten Richtlinien und Problemen, die denen bei herkömmlichen Firewall-Richtlinien ähneln.

Seit einigen Jahren taggen wir Objekte mit einer Vielzahl von Attributen, um Vermögenswerte zu identifizieren und zu gruppieren, was immer wieder zu Problemen in Bezug auf Skalierbarkeit und Verwaltbarkeit geführt hat. Ohne Struktur wird es im Laufe der Zeit immer schwieriger, eine Architektur zu schaffen, die Bestand hat. Bei Illumio haben wir dies früh erkannt und entschieden, dass Struktur und Einfachheit enorme betriebliche Vorteile gegenüber willkürlicher Objektkennzeichnung bieten.

Einfach ausgedrückt, sollten Beschriftungen einfach zu verwenden, wiederholbar, vorhersehbar und später leicht verständlich sein.

Vor diesem Hintergrund finden Sie hier 5 Tipps zur Vereinfachung der Kennzeichnung von Workloads:

1. Halten Sie sich an ein 4-dimensionales Kennzeichnungsschema

Dies funktioniert, indem Arbeitslasten anhand einiger einfacher und offensichtlicher Dimensionsparameter klassifiziert werden. Zum Beispiel:

1. Standort: Wo befindet sich die Arbeitslast? Dies kann ein Land, eine Stadt, ein Cloud-Anbieter usw. sein.
2. Umwelt: Befindet sich dieses Objekt in Produktion, Entwicklung oder Test?
3. Anwendung: Dient es einer Finanz-, Personal- oder CRM-Anwendung?
4. Rolle: Ist es ein Anwendungsserver, ein Webserver oder eine Datenbank?

Indem wir uns an die vier einfachen Gruppen Rolle, Anwendung, Umgebung und Standort (RAEL) halten, können wir ein Kennzeichnungsmodell erstellen, das nicht nur leicht zu verstehen, sondern auch portabel und erweiterbar ist.

Diese Struktur ermöglicht es Benutzern, auf einer der vier Beschriftungen zu schwenken und einen einzigen Abschnitt zu verwenden, um die Steuerung zu vereinfachen und die Rechenzeit zu reduzieren. Wenn unsere Beschriftungen für Fahrzeuge galten und die Form „Typ | Marke | Modell | Farbe“ hätten, wäre die Übung sehr einfach und schnell, wenn nur BMWs oder rote Fahrzeuge identifiziert würden.

Und denken Sie daran, dass die Objektbeschriftung am einfachsten verwendet wird, um das Objekt und seinen Hauptzweck zu definieren, nicht seine Beziehungen. An diesem Prinzip festzuhalten und die Richtlinien zur Definition von Beziehungen zu nutzen, ist der Weg zum Glück — glauben Sie mir.

2. Standardisieren Sie auf ein Format

Obwohl wir ähnliche Dinge für Netzwerke und Computer sehen, gibt es einen großen Unterschied zwischen „Produktion“, „Prod“ und „Prod“. Es wird immer Fälle geben, in denen Rechtschreibfehler auftreten, und in einem strukturierten, 4-dimensionalen Modell ist es einfach, Fehler zu beheben.

In einer lockeren Freestyle-Umgebung wird der Versuch, den Fehler in „Prod.Fin.Win.UK.CRM.Web.Bldg1.10“ zu finden, jedoch ein langer Prozess sein.

3. Seien Sie vorsichtig, wenn Sie Labelnamen kürzen

Beispielsweise kürzen Sie eine Bezeichnung wie „Produktion“ auf „Produktion“, aber nicht „Datenbank“. Eine inkonsistente Verkürzung von Bezeichnungen kann zur Duplizierung von Bezeichnungen führen, was wiederum zu inkonsistenten Richtlinien oder Problemen bei der Unterstützbarkeit führen kann.

Wir empfehlen Ihnen, die vollständigen Namen (Production, Development und Test) zu verwenden, es sei denn, eine verkürzte Version oder ein Akronym ist die in Ihrer Organisation häufig verwendete Nomenklatur (z. B. UAT). Ein klassisches Beispiel, bei dem dies zu Problemen führen kann, ist, wenn sowohl die Bezeichnungen „Prod“ als auch „Production“ erstellt werden. Wenn einige Workloads als „Prod“ gekennzeichnet sind, werden die für „Produktion“ erstellten Regeln nicht auf sie angewendet.

Die Definition eines Benennungsstandards ist kein neues Konzept, und dafür gibt es einen guten Grund.

4. Bleiben Sie auf allen Systemen konsistent

Zusätzlich zur Konsistenz innerhalb Ihres Kennzeichnungsschemas für die Mikrosegmentierung empfehlen wir Ihnen, die Konsistenz mit externen Metadatenquellen aufrechtzuerhalten.

Wenn Sie Benennungskonventionen für Metadaten festgelegt haben, vielleicht in Ihrer Configuration Management Database (CMDB), Hostbenennungskonventionen oder der Verwendung von IP-Adressblöcken, erstellen Sie keine alternativen Konventionen für Ihr Kennzeichnungsschema. Wenn Sie während Ihres Bereitstellungsprojekts feststellen, dass Ihre Standarddatenquelle ebenfalls Inkonsistenzen aufweist, ist dies eine Gelegenheit, diese zu beheben und die Qualität dieser Datenquelle zu verbessern. Dies ist aus einer Vielzahl von Gründen äußerst vorteilhaft, und Ihr Unternehmen wird davon profitieren.

Ihr anfänglicher Anwendungsfall für die Bereitstellung ist möglicherweise auf eine bestimmte Umgebung oder Anwendung beschränkt. Wenn Sie Ihr Etikettendesign jedoch unter Berücksichtigung Ihrer gesamten Organisation strukturieren, sparen Sie Arbeit, wenn der Einsatz erweitert wird. Einfachere Etikettenschemas sind skalierbarer und unterstützbarer.

5. Verwenden Sie Beschriftungen, um die Unterscheidung zwischen Objekten zu ermöglichen

Wenn Sie Richtlinien zwischen Objekten unterscheiden müssen, verwenden Sie unterschiedliche Bezeichnungen. Es gibt oft Fälle, in denen es verlockend sein mag, unterschiedliche Bezeichnungen zu verwenden, aber in Wirklichkeit gibt es keine Differenzierung der Richtlinien, sodass dies unnötig ist. Und denken Sie daran, dass die Politik in dieser Hinsicht die Sicherheitspolitik einschließt, aber auch RBAC, Berichterstattung, Änderungskontrolle und andere Arten von Richtlinien.

Verwenden Sie vor diesem Hintergrund nach Möglichkeit gebräuchliche Namen für Ihre Etiketten. Apache, Nginx und IIS verwenden beispielsweise ähnliche Dienstports und Protokolle, wie 80/TCP oder 443/TCP. Daher empfehlen wir Ihnen, einen allgemeinen Labelnamen wie „Webserver“ zu verwenden. In den meisten Fällen müssen Sie dafür wahrscheinlich keine anderen Richtlinien verfassen.

Variieren Sie Labelnamen nur, wenn Workloads eine andere Sicherheitsrichtlinie erfordern. Beispielsweise verwenden Oracle, IBM DB2 und MS SQL Server unterschiedliche Service-Ports und Protokolle, und jedes hat eigene Sicherheitsrichtlinienelemente, wie z. B. Cluster-Datenverkehrsflüsse. Daher empfehlen wir, den Workloads, auf denen diese Anwendungen ausgeführt werden, drei verschiedene Rollenbezeichnungen zuzuweisen. Auf diese Weise können Sie beispielsweise eine bestimmte Richtlinie schreiben, die Ihren Oracle Enterprise Manager-Servern nur den Zugriff auf Ihre Oracle-Datenbankserver und nicht auf Ihre Sybase-Server ermöglicht.

Wie Illumio helfen kann

Illumio Core verwendet ein mehrdimensionales Design mit einer Kombination aus vier Bezeichnungen, die Richtlinienobjekte identifizieren. Bei anderen Produkten, die Tagging verwenden, können Sie möglicherweise eine beliebige Anzahl von Tags erstellen. Obwohl es den Anschein hat, dass dies die Etikettierung flexibler macht, führt dies zu Herausforderungen, die sich im Laufe der Zeit verschärfen.

Wenn Sie immer wieder verschiedene Label-Dimensionen hinzufügen, erhalten Sie sehr schnell ein eindimensionales Modell, in dem jedes angegebene Tag auf eine eindeutige Richtlinienanwendung hinweist. Eine gute Analogie dazu ist ein Verzeichnisdienst, bei dem für jede neue Anforderung eine neue Gruppe (Tag) erstellt und auf Benutzer angewendet werden kann. Die Anzahl dieser Gruppen nimmt schnell zu und sind oft denselben Objekten zugeordnet, was zu Doppelungen führt. Es ist nicht ungewöhnlich, dass es ein Szenario gibt, in dem es mehr Gruppen als Benutzer gibt. Ähnlich kann es bei einer Tag-basierten Lösung sein, dass Sie am Ende mehr Tags als Objekte haben, wobei jedes Objekt einer großen Anzahl von Tags zugeordnet ist.

Es obliegt dann den Administratoren, alle Objekte mit allen Tags zu verknüpfen, die sie benötigen. Das Ergebnis ist, dass jedes Mal, wenn ein neues Objekt erstellt wird, es mit einer ständig wachsenden Sammlung von Tags versehen werden muss, um den erforderlichen Zugriff zu erhalten. In diesem Szenario wird die Skalierbarkeit zu einer Herausforderung und die Konsistenz beginnt zu versagen.

Viele von uns waren in einer Situation, in der unser Zugang nicht ganz dem eines anderen Teammitglieds entspricht, und es stellt sich heraus, dass uns eine Gruppe (oder ein Tag) fehlt. Durch die Verwendung eines einfachen 4-dimensionalen Modells ist die Kennzeichnung neuer Objekte einfach, vorhersehbar, wiederholbar und unterstützbar, und die Vererbung im Richtlinienentwurf verbessert die Verwaltbarkeit erheblich.

Die Definition eines skalierbaren und konsistenten Kennzeichnungssystems erfordert ein Umdenken bei der Gestaltung von Richtlinien, aber wenn man es einmal verstanden hat, wird seine Einfachheit die Verwaltung der Politik effektiver machen.

Weitere Informationen darüber, wie wir bei Illumio über Etikettierung denken, finden Sie unter dieses tolle Video von unserem Chefevangelisten Nathanael Iversen.