Lassen Sie Ihr Netzwerk nicht zu einem Hindernis für die Workload-Segmentierung werden

Sicherheit und Netzwerke sind seit langem eine Quelle widersprüchlicher Prioritäten. Bei der Planung eines herkömmlichen Rechenzentrums oder einer Hybrid-Cloud-Fabric liegt die Priorität der Netzwerkarchitektur in 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 nicht miteinander kommunizieren, es sei denn, es besteht ein Netzwerk zwischen ihnen. Und alle Netzwerke arbeiten, indem sie Weiterleitungsentscheidungen treffen, die auf der Analyse der Header von Paketen und verschiedenen anderen Metriken basieren. Darüber hinaus tauschen Router und Switches Informationen über Layer-2- und Layer-3-Konzepte 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 übertragen, und nicht darauf, welche Anwendungsdaten in diesem Verkehr enthalten sind.

Wenn es also darum geht, diese Anwendungen — und ihre Workloads — abzusichern, warum ziehen wir immer noch Ansätze in Betracht, die an das Netzwerk gebunden sind? Lassen Sie uns untersuchen, wie Sie Ihren Ansatz weiterentwickeln können, damit das Netzwerk kein Hindernis mehr für die agile Bereitstellung, Automatisierung und Sicherheit von Workloads darstellt.

Innenleben moderner Workloads

Workloads, die über ein beliebiges Netzwerk kommunizieren, sind darauf ausgelegt, dies auf der Grundlage anwendungsspezifischer Prioritäten zu tun. Was ein Workload tut, ist wichtiger als das Aussehen der zugrunde liegenden Netzwerkstruktur. Clients kommunizieren mit Workloads, und Workloads kommunizieren mit Datenbanken auf der Grundlage von Konzepten, die normalerweise nicht von Details abhängen, die in Netzwerkpaket-Headern enthalten sind.

Im Gegensatz zu herkömmlichen Bare-Metal-Workloads werden moderne Workloads weitgehend über die zugrunde liegenden Netzwerk- oder Serverressourcen hinaus abstrahiert. Es wird davon ausgegangen, dass die Präsenz eines Workloads auf einer beliebigen 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 Anweisungen. Aufgrund dieser Abstraktion von Workloads über den zugrunde liegenden Ressourcen ist es nicht mehr realistisch, die IP-Adresse eines Workloads als nützliche Identitätsform für die gesamte Lebensdauer des Workloads zu betrachten. Ein Workload kann im Laufe seines Lebenszyklus viele verschiedene IP-Adressen haben. Dies wirkt sich direkt darauf aus, wie Sicherheitsgrenzen in modernen Netzwerken definiert werden.

Traditionelle Netzwerksegmentierung und Firewalls

Änderungen an Netzwerken erfolgen aufgrund der kritischen Natur von Netzwerkstrukturen traditionell nur langsam. Viele Rechenzentrumsnetzwerke sind größtenteils flach, und viele Public-Cloud-Netzwerkstrukturen enthalten nur grobe Segmentierungsgrade. Wenn Netzwerke in einer beliebigen Umgebung segmentiert werden, geschieht 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. Andere Gründe für die Segmentierung eines Netzwerks sind die Optimierung der Netzwerkleistung, die Erhöhung des Durchsatzes, die Implementierung von Pfadredundanz oder die effizientere Gestaltung 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 mithilfe von SDN-Controllern und Tunneling wie VXLAN implementiert werden. Unabhängig davon, ob es sich bei der Topologie um eine Unterschicht oder eine Überlagerung handelt, enden all diese Netzwerksegmente an Routern oder Switches, entweder hardwaremäßig oder virtuell. Und die Implementierung der Sicherheit in diesen Segmenten erfolgt in der Regel mithilfe 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 den relevanten IP-Bereichen blockiert oder zugelassen werden sollen. Netzwerk-Firewalls implementieren keine Sicherheit, die auf dem anwendungsspezifischen Inhalt der Datennutzlast eines Pakets basiert. Firewalls betrachten die Ziel- oder Quell-IP-Adresse und den Port eines Pakets als Identität einer Arbeitslast. Auch 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. Die meisten Firewallregeln werden immer noch entlang herkömmlicher IP- und Portbereiche konfiguriert. Alte Gewohnheiten lassen sich schwer verderben.

Bruch mit Traditionen

Die DevOps-Philosophie legt großen Wert auf die Geschwindigkeit der Bereitstellung und auf die Automatisierung. Und, wie bereits erwähnt, Änderungen an Netzwerksegmenten und Firewalls sind normalerweise langsam und manuell. Die Automatisierung von Änderungen an Netzwerken und Sicherheit stößt häufig auf betriebliche Hindernisse, deren Änderung schwierig sein kann. Das Ergebnis ist, dass Sicherheit oft erst im Hintergrund steht, da sie lediglich Prozesse verlangsamt. In der Regel werden Workloads schnell und agil bereitgestellt, und Sicherheit hat erst dann wieder Priorität, wenn es zu einer Sicherheitsverletzung kommt und das Unternehmen mit Rechtsstreitigkeiten konfrontiert wird. Niemand möchte dem CEO erklären, warum Sicherheit keine hohe Priorität hatte und warum sein Unternehmen jetzt verklagt wird.

Amazon drückte diesen Prioritätenkonflikt zwischen Workload-Agilität und Netzwerkveränderungen bereits 2012 bekanntermaßen mit den Worten aus: „Das Netzwerk steht mir im Weg.“ Das Netzwerk und sich ändernde Netzwerksegmente sind Hindernisse für agile Workload-Bereitstellungen. Also Netzwerksegmentierung wird oft nicht oder nur auf sehr grobe Weise 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 stattdessen, wenn du könntest Implementieren Sie die erforderlichen Segmente direkt aus demselben agilen Prozess heraus, als würden Sie einen Workload über den DevOps-Prozess bereitstellen?

Und, was noch wichtiger ist, was wäre, wenn Könnte die Sicherheit zwischen diesen Segmenten mithilfe einer Natural Language Policy definiert werden, anstatt sich auf veraltete IP/Port-Firewallregeln zu verlassen? Es gibt keine Richtlinien mehr, die sich auf die Quell-IP und die Ports beziehen, die auf die Ziel-IP und -Ports verweisen, da diese während ihres gesamten Lebenszyklus nicht mehr an Workloads gebunden sind.

Was wäre stattdessen, wenn du könntest eine Richtlinie verfassen, die die Art und Weise widerspiegelt, wie Benutzer die Ressourcen wahrnehmen, z. B. „Können nur in New York bereitgestellte Webserver mit Datenbankservern in London kommunizieren?“

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

Eine Netzwerkarchitektur besteht aus vier großen Ebenen, auf denen Richtlinien angewendet werden können, wie in diesem Diagramm dargestellt:

Wenn Sie die Ebenen aufsteigen, wird die Politik in einer natürlicheren Sprache ausgedrückt, unabhängig von den unteren Ebenen. Wenn Sie Workload-Richtlinien direkt auf die Workloads anwenden, haben die unteren Ebenen mehr Zeit, sich auf die Netzwerkprioritäten zu konzentrieren.

Mithilfe von Tools auf Workload-Ebene können die Segmentierung und Durchsetzung zwischen Workloads auf eine Weise definiert werden, die über der zugrunde liegenden Netzwerkstruktur abstrahiert wird, sodass Netzwerkbetriebsteams nicht mehr von Anwendungsanforderungen das Netzwerkdesign beeinflussen müssen. Wenn die Anwendungssegmentierung und Durchsetzung auf die Workload-Ebene verlagert wird, können Netzwerkbetriebsteams Netzwerkstrukturen entsprechend den Netzwerkprioritäten entwerfen.

Firewalls werden weiterhin verwendet, um breite Segmente in der gesamten Fabric zu erstellen, wie es immer getan wurde, aber es ist nicht mehr erforderlich, eine unhandliche Anzahl von VLANs oder Subnetzen zu erstellen, um den Anforderungen der Anwendungssegmentierung gerecht zu werden. Netzwerkarchitekten können sich stattdessen beim Entwurf auf die Netzwerkprioritäten konzentrieren Netzwerksegmentierung, wie Durchsatz, Redundanz, Routenzusammenfassung, Spanning Tree und ECMP. Die Anwendungssegmentierung muss dem Netzwerkdesign keine Kopfschmerzen mehr bereiten. Wenn Workloads Segmentierungsgrenzen schaffen und durchsetzen, muss das Netzwerk auch nicht mehr an erster Stelle stehen, wenn bei der Behebung von Sicherheitsproblemen nach Ursachen gesucht wird.

Moderne Segmentierung für moderne Workloads

Illumios Adaptive Sicherheitsplattform (ASP) ermöglicht die Mikrosegmentierung zwischen Workloads, die für den Aufbau einer echten Zero-Trust-Architekturund verwendet Ausdrücke in natürlicher Sprache, um Richtlinien zwischen diesen Workloads zu definieren. Es gibt dir eine Abbildung der Anwendungsabhängigkeiten das bietet ein klares Bild davon, welche Workloads genau untereinander kommunizieren und wer Verbindungen mit wem initiiert — in Ihrer gesamten Hybrid-Cloud-Fabric. Und obwohl Sie einen vollständigen Überblick über die von Workloads verwendete IP-Adressierung haben, sollten — und sollten — Richtlinien nicht gegen die IP-Adressierung definiert werden, da die Verknüpfung 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, in denen sie gehostet werden, abstrahiert werden:

• Diese Labels enthalten Metadaten, die Workloads zugeordnet sind, unabhängig von ihrer aktuellen IP-Adresse.
• Die Bezeichnungen lauten Rolle, Anwendung, Umgebung und Standort („RAEL“).
• Sie werden verwendet, um Segmente zwischen Workloads zu definieren, und die Durchsetzung zwischen diesen beschrifteten Workloads wird mithilfe natürlicher Sprachausdrücke definiert, z. B. können Web-Workloads mit App-Workloads kommunizieren, aber nur App-Workloads können mit Datenbank-Workloads kommunizieren. Die Richtlinie ist nicht spezifisch für die IP-Adressierung.
• Illumio übersetzt diese Label-basierten Richtlinienregeln dann in Konfigurationen, die für die Netzwerkfilterfunktionen des Betriebssystems spezifisch sind, auf dem diese Workloads gerade ausgeführt werden — entweder Linux-Iptables und IPsets, Windows Filtering Platform (WFP) oder die IPFilter-Statustabelle für Solaris- und AIX-Workloads.

Da Sie mit Illumio Richtlinien so definieren können, dass sie völlig unabhängig davon sind, wie und wo ein Workload gehostet wird, stehen Netzwerkprioritäten und Anwendungsprioritäten nicht mehr im Konflikt.

Fassen wir es zusammen

In modernen Rechenzentrums- und Hybrid-Cloud-Netzwerkarchitekturen wird der Perimeter einfach so definiert, wo Ihr Workload gerade gehostet wird, und dieser Workload kann sich dynamisch über jedes Segment der Cloud bewegen. Die bisherige Definition, dass der Perimeter zwischen dem Rechenzentrum und dem Internet liegt, 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 bis in den Host, aber sie sind immer noch darauf angewiesen, Segmente von „unten nach oben“ zu definieren: von der Netzwerkebene aus, um ein Problem in der Workload-Ebene zu lösen.

Ein viel skalierbarerer Ansatz in modernen Cloud-Fabrics besteht darin, anhand der Arbeitslast Mikrosegmente zu erstellen und Richtlinien durchzusetzen, die für Workloads relevant sind, sodass die Netzwerksegmentierung anhand von Prioritäten definiert werden kann, die für das Netzwerkdesign relevant sind. Das Netzwerk ist nicht mehr das Hindernis für Arbeitslast der Anwendung Agilität und Sicherheit. Und das Netzwerk steht nicht mehr an erster Stelle, wenn Anwendungssicherheit Es erfolgt eine Problembehandlung, wodurch das Zeigen mit dem Finger bei der Reaktion auf Vorfälle reduziert wird.

Schau dir das an Video für eine kurze Reise, die die Entwicklung der Segmentierung aufschlüsselt und mehr über unsere Lösung erfahren hier.