5 Tipps zur Vereinfachung der Workload-Beschriftung für die 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, Viele werden dies sofort erkennen. Die einfache Struktur macht die Informationen leicht zu konsumieren und zu verstehen. Das ist es, was das Internet skalierbar und funktionsfähig macht. Und für diejenigen, die damit arbeiten, bietet seine Hierarchie unmittelbare Einblicke.
Stellen Sie sich die Alternative vor: eine Welt, in der Menschen willkürliche Strukturen definieren. Was wäre, wenn Sie in der einen Minute 192.179.134.56.245.23 und in der nächsten Minute 24.87 sehen würden? Wie finden wir heraus, wie sich diese zueinander verhalten?
Während wir Flexibilität und freien Willen als positiv betrachten, kann dies in der Welt der Netzwerkadressierung – und ebenso bei der Workload-Kennzeichnung (insbesondere bei der Mikrosegmentierung) – zu Verwirrung und Komplexität führen. Letztendlich führt dies zu inkonsistenten Richtlinien und Problemen, die denen bei herkömmlichen Firewall-Richtlinien ähneln.
Seit einigen Jahren verschlagworten wir Objekte mit einer Vielzahl von Attributen, um Assets zu identifizieren und zu gruppieren, was immer wieder zu Herausforderungen bei der Skalierbarkeit und Verwaltbarkeit geführt hat. Ohne Struktur wird es mit der Zeit immer schwieriger, eine Architektur zu schaffen, die Bestand haben kann. Bei Illumio haben wir dies frühzeitig erkannt und entschieden, dass Struktur und Einfachheit enorme betriebliche Vorteile gegenüber beliebigem Objekt-Tagging bieten.
Einfach ausgedrückt sollten Labels einfach zu verwenden, wiederholbar, vorhersehbar und später einfach zu verstehen sein.
In diesem Sinne finden Sie hier 5 Tipps, um die Beschriftung von Workloads zu vereinfachen:
1. Halten Sie sich an ein 4-dimensionales Kennzeichnungsschema
Dies funktioniert, indem Workloads mit einigen einfachen und offensichtlichen dimensionalen Parametern klassifiziert werden. Zum Beispiel:
- Ort: Wo befindet sich die Arbeitslast? Dies kann ein Land, eine Stadt, bei einem Cloud-Anbieter usw. sein.
- Umwelt: Befindet sich dieses Objekt in der Produktion, Entwicklung oder im Test?
- Anwendung: Dient es einer Finanz-, HR- oder CRM-Anwendung?
- Rolle: Handelt es sich um einen Applikationsserver, einen Webserver oder eine Datenbank?
Indem wir uns an die vier einfachen Gruppen Rolle, Anwendung, Umgebung und Standort (RAEL) halten, können wir ein Etikettierungsmodell erstellen, das nicht nur leicht verständlich, sondern auch portabel und erweiterbar ist.
Diese Struktur ermöglicht es Benutzern, sich auf eine der vier Beschriftungen zu konzentrieren und einen einzigen Abschnitt zu verwenden, um die Steuerung zu vereinfachen und die Rechenzeit zu reduzieren. Wenn unsere Labels für Fahrzeuge bestimmt wären und die Form "Typ | Marke | Modell | Farbe" und dann nur BMWs oder rote Fahrzeuge zu identifizieren, macht die Übung sehr einfach und schnell.
Und denken Sie daran, dass die Objektbeschriftung am einfachsten verwendet wird, um das Objekt und seinen Hauptzweck zu definieren, nicht seine Beziehungen. Sich an dieses Prinzip zu halten und die Politik zu nutzen, um Beziehungen zu definieren, 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 können, gibt es einen großen Unterschied zwischen "Production", "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 jedoch versucht, den Fehler in "prod.fin.win.UK.CRM.web.bldg1.10" zu finden. wird ein langer Prozess sein.
3. Seien Sie vorsichtig beim Kürzen von Etikettennamen
Beispiel: Sie kürzen eine Bezeichnung, z. B. "Produktion", auf "Produktion", aber nicht auf "Datenbank". Die inkonsistente Verkürzung von Bezeichnungsnamen kann zur Duplizierung von Bezeichnungen führen, was wiederum zu inkonsistenten Herausforderungen bei der Richtlinienanwendung oder zur Unterstützung führen kann.
Es wird empfohlen, die vollständigen Namen ("Production", "Development" und "Test") zu verwenden, es sei denn, eine abgekü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 ein "Prod"- als auch ein "Production"-Label 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 über alle Systeme hinweg konsistent
Zusätzlich zur Konsistenz innerhalb Ihres Kennzeichnungsschemas für die Mikrosegmentierung empfehlen wir Ihnen, die Konsistenz mit externen Metadatenquellen zu wahren.
Wenn Sie Benennungskonventionen für Metadaten festgelegt haben, z. B. in Ihrer Konfigurationsverwaltungsdatenbank (CMDB), Hostnamenskonventionen oder die Verwendung von IP-Adressblöcken, erstellen Sie keine alternativen Konventionen für Ihr Bezeichnungsschema. Wenn Sie während Ihres Bereitstellungsprojekts feststellen, dass Ihre Standarddatenquelle ebenfalls Inkonsistenzen aufweist, ist dies eine Gelegenheit, dies zu beheben und die Qualität dieser Datenquelle zu verbessern. Dies ist aus einer Vielzahl von Gründen von großem Vorteil, und Ihr Unternehmen wird davon profitieren.
Ihr anfänglicher Anwendungsfall für die Bereitstellung kann auf eine bestimmte Umgebung oder Anwendung beschränkt sein. Wenn Sie Ihr Etikettendesign jedoch unter Berücksichtigung Ihrer gesamten Organisation strukturieren, sparen Sie Arbeit, wenn die Bereitstellung erweitert wird. Einfachere Bezeichnungsschemata 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 tatsächlich gibt es keine politische Differenzierung, so dass dies unnötig ist. Und denken Sie daran, dass Richtlinien in dieser Hinsicht Sicherheitsrichtlinien, aber auch RBAC, Berichterstellung, Änderungssteuerung und andere Arten von Richtlinien umfassen.
Verwenden Sie daher nach Möglichkeit gebräuchliche Namen für Ihre Etiketten. Apache, Nginx und IIS verwenden beispielsweise ähnliche Dienstports und -protokolle, z. B. 80/TCP oder 443/TCP. Daher wird empfohlen, einen allgemeinen Bezeichnungsnamen zu verwenden, z. B. "Webserver". In den meisten Fällen müssen Sie wahrscheinlich keine unterschiedlichen Richtlinien für diese schreiben.
Ändern Sie die Bezeichnungsnamen nur, wenn für Workloads andere Sicherheitsrichtlinien erforderlich sind. Oracle, IBM DB2 und MS SQL Server verwenden beispielsweise unterschiedliche Service-Ports und -Protokolle, und jeder verfügt über einzigartige Sicherheitsrichtlinienelemente, wie z. B. Cluster-Datenverkehrsflüsse. Daher wird empfohlen, den Workloads, die diese Anwendungen ausführen, drei verschiedene Rollenbezeichnungen zuzuweisen. Auf diese Weise können Sie z. B. eine bestimmte Richtlinie schreiben, die Ihren Oracle Enterprise Manager-Servern den Zugriff nur auf Ihre Oracle Database-Server und nicht auf Ihre Sybase-Server ermöglicht.
Wie Illumio helfen kann
Illumio Core verwendet ein mehrdimensionales Design mit einer Kombination aus vier Labels, die Richtlinienobjekte identifizieren. Bei anderen Produkten, die Tagging verwenden, können Sie möglicherweise eine beliebige Anzahl von Tags erstellen. Auch wenn es den Anschein hat, dass die Etikettierung dadurch flexibler wird, ergeben sich dadurch Herausforderungen, die sich im Laufe der Zeit immer deutlicher werden.
Wenn Sie immer wieder verschiedene Bezeichnungsdimensionen hinzufügen, erhalten Sie sehr schnell ein eindimensionales Modell, bei dem ein bestimmtes Tag eine eindeutige Richtlinienanwendung angibt. 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. Diese Gruppen nehmen schnell zu und sind oft mit denselben Objekten verknüpft, was zu Duplikaten führt. Es ist nicht ungewöhnlich, dass es ein Szenario gibt, in dem es mehr Gruppen als Benutzer gibt. In ähnlicher Weise kann es in einer Tag-basierten Lösung vorkommen, dass Sie 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 erforderlichen Tags zu verknüpfen. Dies hat zur Folge, 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 schon einmal in einer Situation, in der unser Zugriff nicht ganz mit dem eines anderen Mitglieds unseres Teams identisch ist, und es stellt sich heraus, dass uns eine Gruppe (oder ein Tag) fehlt. Durch die Verwendung eines einfachen 4-dimensionalen Modells ist die Beschriftung neuer Objekte unkompliziert, vorhersehbar, wiederholbar und unterstützbar, und die Vererbung im Richtlinienentwurf verbessert die Verwaltbarkeit erheblich.
Die Definition eines skalierbaren und konsistenten Kennzeichnungssystems erfordert ein Umdenken in der Art und Weise, wie Sie über die Gestaltung von Richtlinien nachdenken, aber wenn Sie es einmal verstanden haben, wird seine Einfachheit das Management der Politik effektiver machen.
Weitere Informationen darüber, wie wir bei Illumio über die Etikettierung denken, finden Sie in diesem großartigen Video von unserem Chief Evangelist, Nathanael Iversen.