Lassen Sie Ihr Netzwerk kein Hindernis für die Segmentierung der Workloads sein

Sicherheit und Vernetzung sind seit langem eine Quelle von Konflikten zwischen den Prioritäten. Bei der Entwicklung eines traditionellen Rechenzentrums oder einer Hybrid-Cloud-Fabric liegt die Priorität der Netzwerkarchitektur auf der zuverlässigen und belastbaren Bereitstellung des Datenverkehrs. Das Netzwerk ist vielleicht die wichtigste Ressource in jedem Rechenzentrum oder jeder Cloud-Architektur. Schließlich können Workloads, Clients und Datenbanken nur miteinander kommunizieren, wenn ein Netzwerk zwischen ihnen besteht. Und alle Netzwerke funktionieren, indem sie Weiterleitungsentscheidungen treffen, die auf der Analyse der Header von Paketen und verschiedener anderer Metriken basieren. Darüber hinaus tauschen Router und Switches Informationen zu Layer-2- und Layer-3-Konzepten aus, die beide weitgehend unabhängig von den anwendungsspezifischen Details sind, die tief in der Datennutzlast von Paketen enthalten sind. Netzwerke konzentrieren sich in erster Linie darauf, den Datenverkehr zuverlässig und schnell zu leiten, und nicht darauf, welche Anwendungsdaten in diesem Datenverkehr enthalten sind.

Wenn es also um die Sicherung dieser Anwendungen – und ihrer Workloads – geht, warum ziehen wir immer noch Ansätze in Betracht, die an das Netzwerk gebunden sind? Sehen wir uns an, wie Sie Ihren Ansatz weiterentwickeln können, damit das Netzwerk kein Hindernis mehr für die agile Workloadbereitstellung, Automatisierung und Sicherheit darstellt.

Innenleben moderner Workloads

Workloads, die über ein beliebiges Netzwerk kommunizieren, sind so konzipiert, dass dies auf der Grundlage anwendungsspezifischer Prioritäten geschieht. Die Aufgabe einer Workload ist wichtiger als das Aussehen der zugrunde liegenden Netzwerkstruktur. Clients kommunizieren mit Workloads, und Workloads kommunizieren mit Datenbanken auf der Grundlage von Konzepten, die in der Regel nicht von Details abhängig sind, die in Netzwerkpaketheadern enthalten sind.

Im Gegensatz zu herkömmlichen Bare-Metal-Workloads werden moderne Workloads weitgehend über die zugrunde liegenden Netzwerk- oder Serverressourcen abstrahiert. Es wird davon ausgegangen, dass das Vorhandensein einer Workload auf einer zugrunde liegenden Ressource vorübergehend ist und dynamisch live zwischen Hosts, Rechenzentren und Clouds migriert werden kann. Diese Migrationen erfolgen in der Regel dynamisch, ohne manuelle menschliche Anweisung. Aufgrund dieser Abstraktion von Workloads über die zugrunde liegenden Ressourcen ist es nicht mehr realistisch, die IP-Adresse einer Workload als nützliche Form der Identität für die Lebensdauer dieser Workload zu betrachten. Eine Workload kann im Laufe ihres Lebenszyklus viele verschiedene IP-Adressen haben, und dies wirkt sich direkt darauf aus, wie Sicherheitsgrenzen in modernen Netzwerken definiert werden.

Herkömmliche Netzwerksegmentierung und Firewalls

Änderungen an Netzwerken sind aufgrund der kritischen Natur von Netzwerk-Fabrics traditionell langsam. Viele Rechenzentrumsnetzwerke sind weitgehend flach, und viele Public-Cloud-Netzwerkstrukturen enthalten nur grobe Segmentierungsebenen. Wenn Netzwerke in einer beliebigen Umgebung segmentiert werden, erfolgt dies in der Regel für netzwerkspezifische Prioritäten, z. B. um eine Isolierung über breite Ressourcenkategorien hinweg zu schaffen, z. B. eine DMZ, ein WAN-Segment, ein Campus-Segment oder die traditionellen Web-/App-/Dev-Segmente. Weitere Gründe für die Segmentierung eines Netzwerks sind die Optimierung der Netzwerkleistung, die Erhöhung des Durchsatzes, die Implementierung von Pfadredundanz oder die Steigerung der Effizienz von Aufgaben wie Routenzusammenfassung, Spanning Tree und ECMP.

Netzwerksegmente werden traditionell durch die Erstellung von VLANs und Subnetzen implementiert, entweder über ältere "Underlay"-Netzwerke oder über "Overlay"-Netzwerke, die mit SDN-Controllern und Tunneling wie VXLAN implementiert werden. Unabhängig davon, ob es sich bei der Topologie um ein Underlay oder ein Overlay handelt, enden alle diese Netzwerksegmente an Routern oder Switches, entweder Hardware oder virtuell. Die Implementierung von Sicherheit in diesen Segmenten erfolgt in der Regel durch die Verwendung von Netzwerk-Firewalls.

Traditionell betrachten Firewalls jedes Segment entweder als eine Gruppe von IP-Bereichen zusammen mit zugehörigen TCP/UDP-Ports oder als Zonen, die eine Sammlung von Segmenten zusammen mit den zu blockierenden oder zuzulassenden Ports zwischen relevanten IP-Bereichen darstellen. Netzwerk-Firewalls implementieren keine Sicherheit basierend auf dem anwendungsspezifischen Inhalt der Datennutzlast eines Pakets. Firewalls betrachten die Ziel- oder Quell-IP-Adresse und den Port eines Pakets als Identität der Arbeitslast. Selbst bei modernen Firewalls der „nächsten Generation“, die Entscheidungen auf Basis tief im Datenpaket verborgener Anwendungsdaten treffen können, werden die meisten Firewall-Regeln immer noch über traditionelle IP- und Portbereiche konfiguriert. Alte Gewohnheiten lassen sich schwer ablegen.

Bruch mit Traditionen

Die DevOps-Philosophie legt großen Wert auf die Geschwindigkeit der Bereitstellung und auf die Automatisierung. Wie bereits erwähnt, erfolgen Änderungen an Netzwerksegmenten und Firewalls in der Regel langsam und manuell. Die Automatisierung von Änderungen an Netzwerken und Sicherheitsvorkehrungen stößt häufig auf operative Hindernisse, deren Überwindung sich als schwierig erweisen kann. Die Folge ist, dass Sicherheit oft erst im Nachhinein berücksichtigt wird, da sie die Prozesse einfach verlangsamt. Üblicherweise werden Workloads schnell und agil bereitgestellt, und die Sicherheit rückt erst dann wieder in den Vordergrund, wenn es zu einem Sicherheitsvorfall kommt und das Unternehmen mit Rechtsstreitigkeiten konfrontiert wird. Niemand möchte derjenige sein, der dem CEO erklären muss, warum Sicherheit keine hohe Priorität hatte und warum sein Unternehmen nun verklagt wird.

Amazon brachte diesen Prioritätenkonflikt zwischen Workload-Agilität und Netzwerkänderungen bereits 2012 mit dem berühmten Satz zum Ausdruck: „Das Netzwerk steht mir im Weg.“ Das Netzwerk und sich ändernde Netzwerksegmente stellen Hindernisse für agile Workload-Bereitstellungen dar. Daher wird die Netzwerksegmentierung von den Netzwerkteams oft gar nicht oder nur sehr grob durchgeführt.

Aber was wäre, wenn Netzwerksegmentierung und -sicherheit direkt aus dem Workload heraus implementiert werden könnten? Sie müssen nicht mehr darauf warten, dass der Netzwerkbetrieb die Segmentierung in der zugrunde liegenden Netzwerkstruktur implementiert.

Was wäre, wenn Sie die erforderlichen Segmente stattdessen direkt aus demselben agilen Prozess heraus implementieren könnten, wie bei der Bereitstellung einer Workload über den DevOps-Prozess?

Und, was noch wichtiger ist, was wäre, wenn die Sicherheit zwischen diesen Segmenten mithilfe von Richtlinien in natürlicher Sprache definiert werden könnte, anstatt sich auf veraltete IP-/Port-Firewall-Regeln zu verlassen? Es werden keine Richtlinien mehr für Quell-IP-Adressen und -Ports definiert, die auf Ziel-IP-Adressen und -Ports verweisen, da diese nicht mehr während ihres gesamten Lebenszyklus an Arbeitslasten gebunden sind.

Was wäre, wenn Sie stattdessen eine Richtlinie schreiben könnten, die die Art und Weise widerspiegelt, wie Benutzer die Ressourcen wahrnehmen, z. B. "Nur Webserver, die in New York bereitgestellt werden, können mit Datenbankservern in London kommunizieren?"

Und was wäre, wenn Sie dies in einem granularen Ansatz definieren könnten, um einen echten "mikrosegmentierten" Zero-Trust-Ansatz zu erreichen, wie z. B. "Nur Webserver-1 kann mit Webserver-2 am selben Standort kommunizieren"?

Es gibt vier große Schichten in einer Netzwerkarchitektur, auf die Richtlinien angewendet werden können, wie in diesem Diagramm dargestellt:

Wenn man die Schichten hinaufsteigt, wird die Politik in einer natürlicheren Sprache ausgedrückt, die für die unteren Schichten agnostisch ist. Durch die direkte Anwendung der Workload-Richtlinie auf die Workloads können sich die unteren Schichten auf die Netzwerkprioritäten konzentrieren.

Indem Tools der Workload-Ebene die Segmentierung und Durchsetzung zwischen Workloads auf eine Weise definieren können, die über der zugrunde liegenden Netzwerkstruktur abstrahiert ist, werden die Netzwerkbetriebsteams davon befreit, dass Anwendungsanforderungen Einfluss auf das Netzwerkdesign nehmen. Durch die Verlagerung der Anwendungssegmentierung und -durchsetzung auf die Workload-Ebene können Netzwerkbetriebsteams Netzwerkstrukturen entsprechend den Netzwerkprioritäten entwerfen.

Firewalls werden weiterhin verwendet, um breite Segmente im gesamten Netzwerk zu erstellen, wie es schon immer üblich war. Es ist jedoch nicht mehr erforderlich, eine unüberschaubare Anzahl von VLANs oder Subnetzen zu erstellen, um den Anforderungen der Anwendungssegmentierung gerecht zu werden. Netzwerkarchitekten können sich stattdessen bei der Konzeption der Netzwerksegmentierung auf Netzwerkprioritäten wie Durchsatz, Redundanz, Routenzusammenfassung, Spanning Tree und ECMP konzentrieren. Anwendungssegmentierung muss dem Netzwerkdesign keine zusätzlichen Kopfschmerzen bereiten. Wenn Arbeitslasten Segmentierungsgrenzen erstellen und durchsetzen, wird das Netzwerk auch davon befreit, bei der Fehlersuche nach Sicherheitsproblemen als erstes in Betracht gezogen zu werden.

Moderne Segmentierung für moderne Workloads

Die Adaptive Security Platform (ASP) von Illumio ermöglicht die Mikrosegmentierung zwischen Workloads, die für den Aufbau einer echten Zero-Trust-Architektur unerlässlich ist, und verwendet natürlichsprachliche Ausdrücke, um Richtlinien zwischen diesen Workloads zu definieren. Es liefert Ihnen eine Anwendungsabhängigkeitskarte , die ein klares Bild davon vermittelt, welche Workloads untereinander kommunizieren und wer die Verbindungen zu wem initiiert – und zwar über Ihre gesamte Hybrid-Cloud-Infrastruktur hinweg. Und obwohl Sie vollen Einblick in die von den Workloads verwendete IP-Adressierung haben, werden Richtlinien nicht – und sollten auch nicht – anhand der IP-Adressierung definiert, da die Verbindung zwischen Netzwerkadressierung und Anwendungen nur vorübergehend ist.

Illumio verwendet Labels, um Workloads anhand von Kriterien zu identifizieren, die über das Segment der zugrunde liegenden Hybrid-Cloud-Netzwerksegmente abstrahiert sind, auf denen sie gehostet werden:

• Diese Bezeichnungen enthalten Metadaten, die Workloads zugeordnet sind, unabhängig von ihrer aktuellen IP-Adressierung.
• Die Bezeichnungen sind "Role", "Application", "Environment, and Location" ("RAEL").
• Sie werden verwendet, um Segmente zwischen Workloads zu definieren, und die Erzwingung zwischen diesen bezeichneten Workloads wird mithilfe von Ausdrücken in natürlicher Sprache definiert, z. B. Webworkloads können mit App-Workloads kommunizieren, aber nur App-Workloads können mit Datenbankworkloads kommunizieren. Die Richtlinie ist nicht spezifisch für die IP-Adressierung.
• Illumio übersetzt diese bezeichnungsbasierten Richtlinienregeln dann in Konfigurationen, die für die Netzwerkfilterfunktionen des Betriebssystems spezifisch sind, auf dem diese Workloads derzeit ausgeführt werden – entweder Linux-iptables und ipsets, Windows Filtering Platform (WFP) oder die IPFilter-Statustabelle für Solaris- und AIX-Workloads.

Da Illumio es Ihnen ermöglicht, Richtlinien auf eine Weise zu definieren, die vollständig über die Art und Weise abstrahiert ist, wie und wo ein Workload gehostet wird, führt dies dazu, dass Netzwerkprioritäten und Anwendungsprioritäten nicht mehr in Konflikt stehen.

Zusammenfassend

In modernen Rechenzentrums- und Hybrid-Cloud-Netzwerkarchitekturen wird der Perimeter einfach als der Ort definiert, an dem Ihre Workload derzeit gehostet wird, und diese Workload kann dynamisch über jedes Segment der Cloud verschoben werden. Die bisherige Definition des Perimeters als Perimeter zwischen dem Rechenzentrum und dem Internet ist nicht mehr relevant, und der Versuch, die Netzwerkstruktur so zu gestalten, dass eine Mikrosegmentierung über Anwendungsgrenzen hinweg möglich ist, ist schwierig zu skalieren. SDN-Lösungen, die Controller und Overlay-Netzwerke verwenden, die in Hypervisoren enden, verschieben die Grenze zwischen dem Netzwerk und den Workloads effektiv nach oben in den Host, verlassen sich jedoch immer noch auf die Definition von Segmenten von "unten nach oben": von der Netzwerkschicht, um ein Problem in der Workload-Schicht zu lösen.

Ein wesentlich skalierbarerer Ansatz in modernen Cloud-Infrastrukturen besteht darin, auf Workload-Ebene Mikrosegmente zu erstellen und Richtlinien durchzusetzen, die für die Workloads relevant sind. Dadurch wird die Netzwerksegmentierung frei, um sie anhand von Prioritäten zu definieren, die für das Netzwerkdesign relevant sind. Das Netzwerk stellt kein Hindernis mehr für die Agilität und Sicherheit von Anwendungsworkloads dar. Und das Netzwerk steht bei der Fehlersuche in der Anwendungssicherheit nicht mehr an erster Stelle, was Schuldzuweisungen bei der Reaktion auf Sicherheitsvorfälle reduziert.

Schauen Sie sich dieses Video an, um einen kurzen Überblick über die Entwicklung der Segmentierung zu erhalten, und erfahren Sie hier mehr über unsere Lösung.