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.

Firewalls betrachten jedes Segment traditionell entweder als eine Gruppe von IP-Bereichen zusammen mit den zugehörigen TCP/UDP-Ports oder als Zonen, bei denen es sich um eine Sammlung von Segmenten handelt, zusammen mit den Ports, die zwischen relevanten IP-Bereichen blockiert oder zugelassen werden sollen. 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 eines Workloads. Selbst mit modernen Firewalls der "nächsten Generation",die in der Lage sind, Entscheidungen auf der Grundlage von Anwendungsdaten zu treffen, die tief im Paket enthalten sind, werden die meisten Firewall-Regeln immer noch entlang traditioneller IP- und Portbereiche konfiguriert. Alte Gewohnheiten sterben schwer.

Bruch mit Traditionen

Die DevOps-Philosophie legt großen Wert auf die Geschwindigkeit der Bereitstellung und auf die Automatisierung. Und wie bereits erwähnt, erfolgen Änderungen an Netzwerksegmenten und Firewalls in der Regel langsam und manuell. Die Automatisierung von Änderungen an Netzwerken und Sicherheit stößt oft auf betriebliche Hindernisse, die schwer zu ändern sein können. Das Ergebnis ist, dass Sicherheit oft ein nachträglicher Gedanke ist, da sie Prozesse einfach verlangsamt. In der Regel werden Workloads schnell und agil bereitgestellt, und die Sicherheit wird erst dann wieder Priorität, wenn eine Sicherheitsverletzung auftritt und das Unternehmen mit Rechtsstreitigkeiten konfrontiert ist. Niemand möchte die Person sein, die dem CEO erklärt, warum Sicherheit keine hohe Priorität hatte und warum sein Unternehmen jetzt verklagt wird.

Amazon hat diesen Prioritätenkonflikt zwischen Workload-Agilität und Netzwerkänderungen bereits 2012 mit den Worten ausgedrückt: "Das Netzwerk steht mir im Weg." Das Netzwerk und sich ändernde Netzwerksegmente sind Hindernisse für agile Workload-Bereitstellungen. Daher wird die Netzwerksegmentierung oft nicht oder nur sehr grob von Netzwerkteams 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.

Wenn Tools auf Workloadebene die Segmentierung und Durchsetzung zwischen Workloads auf eine Weise definieren können, die über die zugrunde liegende Netzwerkstruktur abstrahiert wird, können Netzwerkbetriebsteams nicht mehr von Anwendungsanforderungen beeinflusst werden. Durch die Verlagerung der Anwendungssegmentierung und -durchsetzung auf die Workload-Ebene können Netzwerkbetriebsteams Netzwerk-Fabrics entlang der Netzwerkprioritäten entwerfen.

Firewalls werden weiterhin verwendet, um breite Segmente in der gesamten Fabric zu erstellen, wie es immer der Fall war, aber es ist nicht mehr erforderlich, eine unhandliche Anzahl von VLANs oder Subnetzen zu erstellen, um die Anforderungen an die Anwendungssegmentierung zu erfüllen. Netzwerkarchitekten können sich beim Entwerfen der Netzwerksegmentierung stattdessen auf Netzwerkprioritäten konzentrieren, z. B. Durchsatz, Redundanz, Routenzusammenfassung, Spanning Tree und ECMP. Die Anwendungssegmentierung muss dem Netzwerkdesign keine Kopfschmerzen mehr bereiten. Wenn Workloads Segmentierungsgrenzen erstellen und erzwingen, wird das Netzwerk auch davon befreit, das erste zu sein, wenn bei der Behebung von Sicherheitsproblemen nach Ursachen gesucht wird.

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ürliche Sprachausdrücke, um Richtlinien zwischen diesen Workloads zu definieren. Sie erhalten eine Karte der Anwendungsabhängigkeiten , die ein klares Bild davon liefert, welche Workloads untereinander kommunizieren und wer mit wem Verbindungen initiiert – über Ihre gesamte Hybrid-Cloud-Fabric hinweg. Und obwohl Sie einen vollständigen Überblick über die von Workloads verwendete IP-Adressierung haben, sollten Richtlinien nicht für die IP-Adressierung definiert werden, da die Verbindung zwischen Netzwerkadressierung und Anwendungen 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 viel skalierbarerer Ansatz in modernen Cloud-Fabrics besteht darin, Mikrosegmente zu erstellen und Richtlinien durchzusetzen, die für Workloads relevant sind, sodass die Netzwerksegmentierung entlang von Prioritäten definiert werden kann, die für den Netzwerkentwurf relevant sind. Das Netzwerk ist nicht mehr das Hindernis für die Agilität und Sicherheit von Anwendungs-Workloads . Und das Netzwerk ist nicht mehr an erster Stelle, wenn es um die Fehlerbehebung bei der Anwendungssicherheit geht, was die Schuldzuweisungen bei der Reaktion auf Vorfälle reduziert.

Schauen Sie sich dieses Video an, um eine kurze Reise zu erhalten, die die Entwicklung der Segmentierung aufschlüsselt, und erfahren Sie hier mehr über unsere Lösung.