/
Zero-Trust-Segmentierung

Ist Intent-Based Networking eine „gescheiterte“ Technologie?

Mitte der 2010er Jahre verliebten sich Experten und Analysten des Technologiemarketings gleichermaßen in eine Technologie, die sie Intent-Based Networking (IBN) nannten — und haben sie ausgiebig gehypt.

Jetzt, fast ein Jahrzehnt später, hört man nicht mehr viel von IBN. Das heißt aber nicht, dass es weg ist.

Dieser Artikel beschreibt die Geschichte von IBN und seine wichtigen Grundlagen der heutigen modernen Cloud-Infrastruktur — und Cloud-Sicherheit.

Anfang der 2010er Jahre: Anpassung an schnelle Veränderungen im Cloud-Netzwerk

Kurz zuvor, bei HP Networking, erlebte das Büro des CTO, wie ähnliche neue Netzwerkabstraktionen isoliert von mehreren Gruppen erfunden wurden, die versuchten, sich an das neue Ausmaß und die Geschwindigkeit der Veränderungen in Cloud-Netzwerken anzupassen. Ein Großteil dieser Arbeit wurde in Open-Source-Projekten (z. B. OpenStack, Open Day Light) geleistet.

HP beschloss, Ressourcen in den Versuch zu investieren, diese Arbeit zu vereinheitlichen, und veranstaltete 2013 den „IBN Summit“ in den HP Labs in Palo Alto. Eingeladen wurden alle, von denen bekannt ist, dass sie an netzwerkpolitischen Lösungen für SDN- und Cloud-Projekte arbeiten, darunter Mitarbeiter von Cisco, HP, RedHat, IBM, Huawei, Brocade, Microsoft, NEC, VMware usw. Die verschiedenen Parteien stellten Aspekte ihrer Arbeit in diesem Bereich vor und einigten sich darauf, einen Weg zu einer gemeinsamen API zu finden.

Mitte der 2010er Jahre: Definition von IBN

Vertreter vieler dieser Unternehmen arbeiteten dann während meiner Präsidentschaft weiterhin in der Arbeitsgruppe North-Bound Interface (NBI) der Open Networking Foundation (ONF) zusammen. Im Oktober 2016 veröffentlichte ONF ein Dokument, das den Mitgliedern einen Konsens über eine Definition und einen technischen Überblick für ein IBN-System bieten sollte.

Lesen Sie das Dokument Intent NBI - Definition und Prinzipien, hier.

Die Definition aus diesem Dokument lässt sich mit einer Art goldener Regel zusammenfassen: Absicht beinhaltet keine Implementierungsdetails, die sie plattform- oder infrastrukturspezifisch machen würden.

Die Absicht besteht aus deklarativen Aussagen über das gewünschte Netzwerkverhalten in geschäftlicher Hinsicht. Unabhängig davon gibt es einen Mapping-Prozess, der weiß, wie die Absicht in die aktuelle Konfiguration/den aktuellen Zustand/die aktuelle Topologie der Infrastruktur implementiert werden kann.

Kritiker behaupteten, wir würden die Implementierung wegwerfen und ignorieren, sodass sie keinen Wert habe. Wir wiesen darauf hin, dass wir es nicht wegwerfen, sondern es unter der Kontrolle eines Mapping-Prozesses an einen anderen Ort verschieben würden. Um eine „reine“ Absicht zu erklären, müssen die Verfasser der Richtlinien keine Experten für Infrastrukturtechnologien sein, sondern sie müssen lediglich die geschäftlichen Einschränkungen verstehen, die für die Politik gelten.

In diesem Dokument beschrieb die ONF-Definition eine „intentionelle aktive Schleife“ innerhalb des Controllers:

„Dieses Element ist dafür verantwortlich, aktive Serviceabsichten und Zuordnungen aus dem Repo und Netzwerkinformationen vom SBI-Handler kontinuierlich auszuwerten und Maßnahmen zu ergreifen, die erforderlich sind, um neue Dienstkonfigurationen zu instanziieren oder bestehende Dienstkonfigurationen entsprechend zu ändern, je nach erkannten Intent-Änderungen (Repo) und/oder von Intent NBI.“

Intent NBI Definition and Principles

Die Beschreibung des Intent-Active-Loops steht im Einklang mit einem Begriff, der aus Kubernetes bekannt geworden ist. Er beschreibt Controller, die deklarative Absicht in Systemverhalten übersetzen, als auf einem Continuous Reconciliation Loop (CRL) aufgebaut, der kontinuierlich eine Implementierung der deklarierten Absicht innerhalb der Infrastruktur aufrechterhält.

In diesem Artikel wird der Begriff Continuous Reconciliation Loop oder CRL verwendet, um all diese technischen Ansätze zu bezeichnen.

kubernetes-reconciliation-loop

2017: IBN ist „das nächste große Ding“

Kurz nachdem wir das Dokument veröffentlicht hatten, begann die Branche, über IBN zu sprechen, als Gartner den Begriff 2017 prägte und ihn das „nächste große Ding“ in einer blogartikel.

Marketingspezialisten machten IBN schließlich bedeutungslos, was sie tun, zuerst, indem alle Anbieter behaupteten, IBN schon immer gehabt zu haben. Und dann hörten die Leute irgendwann auf, darüber zu reden.

Nach all dem Lärm kann man zurückblicken und sich fragen: War IBN in der Praxis ein Misserfolg?

Die Antwort lautet nein — ganz im Gegenteil.

Heute: IBN lebt und gedeiht in der modernen Cloud-Infrastruktur

Wir sprechen nicht viel über IBN, aber es ist in der modernen Cloud-Infrastruktur allgegenwärtig.

Drei Beispiele verdeutlichen die breite Anwendung dieses Ansatzes in großen Produktionsumgebungen.

Kubernetes-Netzwerkrichtlinien

Der Container Network Interface (CNI) Policy-Controller (CNI) von K8, die Certificate Revocation List (CRL), kennt den Status aller Pods/Endpoints, virtuellen Switches, Sidecar-Proxys, Gateways, NATs usw. Er kennt auch die Zuordnungen für die Implementierung (IP-Adressen, Ports, Protokolle, Identität, Autorisierung, Labels, Namespaces usw.) und führt eine kontinuierliche Abstimmungsschleife durch, um die Implementierung mit den Netzwerkrichtlinien konsistent zu halten.

Entwickler bieten Kubernetes Netzwerkrichtlinien (KNPs) ohne Implementierungsdetails (Absicht), und der Controller macht es so. KNPs ermöglichen es Benutzern zwar, untergeordnete Attribute wie IP-Adresse oder Port anzugeben, aber es hat sich bewährt, markenbasierte Selektoren in lokalen Richtliniendeklarationen zu verwenden, um von der verteilten Zustandsautomatisierung in der KNP-Engine zu profitieren.

Illumio Policy Compute Engine (PCE) und Illumio VEN (Agent)

Illumio verfügt über ein ausgereiftes und weit verbreitetes Unternehmensprodukt, das das Wertversprechen der Absicht auf Bare-Metal- und virtuelle Maschinen und Container überträgt, indem es eine ähnliche labelbasierte Abstraktion verwendet. Dies umfasst mehrere dynamische Instanzen, die einen CRL-Controller verwenden, um die Einhaltung von Policy-Einschränkungen zu gewährleisten.

Es gibt einen Distributed Controller (PCE), der mit abstrakten, dynamischen, labelbasierten Richtlinien vorkonfiguriert ist und die kontinuierliche Abgleichschleife verwendet, um diese Richtlinien im Kontext des aktuellen Infrastrukturstatus und der aktuellen Topologie zu implementieren.

Die tatsächliche Durchsetzung der Richtlinien erfolgt in diesem Fall durch die Programmierung der untergeordneten, nativen Tools für verschiedene lokale und öffentliche Cloud-Infrastrukturplattformen.

Wacholder/Apstra

Apstra IBN verfügt auch über ein deklaratives Modell mit Automatisierung, um abstrakte Richtlinien in bestimmte Infrastrukturimplementierungen umzuwandeln. Das Problem, das es löst, unterscheidet sich jedoch geringfügig von den vorherigen Beispielen.

Sowohl die Kubernetes-Netzwerkrichtlinien als auch die Plattform von Illumio können als „Overlay“ -Netzwerktechnologien eingestuft werden. Sie erstellen und steuern die Funktionen eines virtuellen Netzwerks auf einem Netzwerk, das bereits über grundlegende Konnektivität zwischen physischen Geräten verfügt.

Die Juniper Apstra-Lösung ist in der Lage, das ‚Äúunderlay'-Netzwerk zu erstellen und zu steuern, das Racks voller Rechenzentrumsgeräte umfasst, die über Kabel miteinander verbunden sind. Wie bei den obigen Beispielen wird jedoch die Konsistenz gewahrt, indem die deklarativen Richtlinien kontinuierlich mit dem Netzwerk abgeglichen werden.

IBN: Das Rückgrat der Cloud-Performance im großen Maßstab

Die zusätzliche Abstraktionsebene, die durch einen absichtsbasierten Ansatz bereitgestellt wird, ist notwendig, um den Umfang, die Änderungsrate und die Leistung zu erreichen, die für Cloud-Workloads erforderlich sind.

Wenn Sie Tausende oder mehr dynamische Instanzen einer „Anwendung“ haben, die sich ständig ändert, können Menschen nicht auf dem schnellsten Weg sein, Richtlinien zu aktualisieren. Eine absichtsbasierte Oberfläche „komprimiert“ den Regelbereich aus der Benutzerperspektive und verbirgt die ganze Magie, die hinter dieser Oberfläche steckt, um ihn Wirklichkeit werden zu lassen. Sie ermöglicht es, Instanzen mit ähnlichem/identischem Verhalten als Gruppe zu behandeln, auf die die Richtlinie angewendet werden kann.

Wenn Ihre Absicht ist, dass „Dinge in Gruppe A mit Dingen in Gruppe B kommunizieren können“, erstellen Sie eine einfache Regel, die sich niemals ändern muss. Es ist die richtige Regel und führt zum richtigen Verhalten, unabhängig davon, ob es keine Instanzen gibt, eine, zwei, drei oder eine Milliarde Instanzen, auf einem einzelnen Server oder Millionen. Es gibt nur eine Regel, aber ihre Implementierung in einem großen System erfordert möglicherweise dynamische Aktualisierungen von einer Milliarde Firewallregeln in hunderttausend Firewalls.

Es ist die Entwicklung dieser riesigen, verteilten, automatisierten Continuous Reconciliation Loop-Controller, die es ermöglichen, globale Netzwerkrichtlinien für große verteilte Systeme zu implementieren, die zunehmend von globalen Unternehmen in der Cloud aufgebaut werden.

Die Zeiten einer Excel-Tabelle mit den Regeln für all Ihre Firewalls sind lange vorbei — jeder manuelle, individuelle Ansatz zur „Programmierung von Firewalls“ für größere Systeme ist ebenfalls überholt.

Moderne Cloud-Sicherheit basiert auf IBN

IBN hat stillschweigend die gesamte Fahrt auf dem Hype-Zyklus. Es ist so tief in die Grundlagen moderner Netzwerke verwoben, dass kein Schlagwort mehr damit verbunden ist.

Die Tatsache, dass mehrere Parteien isoliert konzeptionell ähnliche Lösungen erfunden haben, ist immer ein starkes Zeichen dafür, dass etwas Wichtiges passiert. Die Leute, die diese Arbeit geleistet haben, sind weitgehend unbekannt, aber sie wissen, dass sie dazu beigetragen haben, die großartigen Dinge zu ermöglichen, die wir heute in der Cloud tun können.

Diese Fähigkeit erweist sich als noch wichtiger als Cyber-Bedrohungen Erhöhung und der Schutz von Null Vertrauen Insbesondere die Vernetzung wird noch wichtiger. Die zuverlässige, skalierbare Natur von IBN wiederum ermöglicht es Plattformen wie Illumio, zuverlässige, skalierbare Sicherheit in der Cloud zu bieten.

Erfahren Sie mehr darüber, wie Illumio CloudSecure Sicherheitslücken in der Hybrid Cloud eindämmert hier.

Interessiert daran, Ihr Cloud-Netzwerk zu sichern mit Illumio Zero Trust Segmentierung? Kontaktiere uns heute für eine Beratung und Demo.

Verwandte Themen

Keine Artikel gefunden.

In Verbindung stehende Artikel

Verbesserung des Sicherheits-ROI, ZTS für Endgeräte und Sicherheitsherausforderungen auf Bundesebene
Zero-Trust-Segmentierung

Verbesserung des Sicherheits-ROI, ZTS für Endgeräte und Sicherheitsherausforderungen auf Bundesebene

Da Ransomware und andere Cyberangriffe immer raffinierter werden, zeigt der Aufbau von Cyber-Resilienz durch Eindämmung einen besseren Sicherheits-ROI.

Was Sie für die Ermittlung von Zero-Trust-Richtlinien benötigen
Zero-Trust-Segmentierung

Was Sie für die Ermittlung von Zero-Trust-Richtlinien benötigen

Um eine Zero-Trust-Richtlinie zu verfassen, ist eine Analyse erforderlich, um eine Anwendung und ihren Kontext zu verstehen, um eine Mikrosegmentierungslösung implementieren zu können.

Minimierung Ihrer Angriffsfläche bei M&A und Veräußerungen
Zero-Trust-Segmentierung

Minimierung Ihrer Angriffsfläche bei M&A und Veräußerungen

Die Illumio Adaptive Security Platform (ASP) spielt eine grundlegende Rolle im M&A- und Veräußerungsprozess.

Keine Artikel gefunden.

Gehen Sie von einem Verstoß aus.
Auswirkungen minimieren.
Erhöhen Sie die Widerstandsfähigkeit.

Sind Sie bereit, mehr über Zero-Trust-Segmentierung zu erfahren?