Warum Hybrid Cloud nicht gleich hybrider Sicherheit sein sollte

Hybrid-Cloud-Netzwerkstrukturen lösen viele Herausforderungen in Unternehmensnetzwerken von heute. Sie ermöglichen die Erstellung einer einzigen Netzwerkarchitektur, die über den zugrunde liegenden Rechenzentrumsumgebungen abstrahiert ist. Sie ermöglichen außerdem Fehlertoleranz, Resilienz, „elastische“ Dienste über Rechenzentren hinweg und eine Netzwerktopologie, die nicht von einem einzelnen Netzwerkanbieter abhängig ist. Ein Unternehmen kann mehrere physische Netzwerkumgebungen verwalten, aber kann es eine einzige Netzwerkstruktur für alle einrichten?

Beispielsweise kann ein Unternehmen zusätzlich zu mehreren öffentlichen Cloud-Bereitstellungen auf AWS, Azure und/oder GCP zwei Rechenzentren (ein primäres und ein weiteres für die Notfallwiederherstellung) unterhalten. Jede dieser Hosting-Umgebungen stellt ihre eigenen zugrunde liegenden physischen Netzwerkarchitekturen mit ihren eigenen spezifischen Technologien bereit, häufig mit unterschiedlichen Routing- und Switching-Anbietern.

Aber mit dem Aufkommen von Softwaredefiniertes Netzwerk (SDN) In der gesamten Netzwerkbranche kann die Mehrheit der Netzwerkanbieter heute ihre eigene „Cloud“ erstellen. In der Netzwerkterminologie ist eine Cloud im Wesentlichen ein virtuelles Netzwerk, bei dem die Netzwerktopologie über der physischen Topologie abstrahiert wird, was oft als „Overlay-Netzwerk“ bezeichnet wird. Und ein Overlay-Netzwerk ist im Wesentlichen eine Sammlung von Tunneln, die alle von einem zentralen SDN-Controller verwaltet werden. Diese Cloud kann eine einzige, einheitliche Netzwerkstruktur für alle verwalteten Hosting-Umgebungen schaffen.

Ein Tunnelprotokoll wie VXLAN wird verwendet, um die Overlay-Netzwerktopologie zu erstellen, sodass der Verkehrspfad davon bestimmt wird, wie diese Tunnel bereitgestellt werden, und nicht davon, wie die zugrunde liegende physische Topologie bereitgestellt wird. Alle Netzwerkanbieter verwenden unterschiedliche Begriffe, um ihren SDN-basierten Ansatz zu beschreiben, um dies zu ermöglichen, aber am Ende des Tages machen sie alle im Grunde dasselbe: Sie verwenden Tunnel, um ein Overlay-Netzwerk zu erstellen, das automatisiert und von einer zentralen Steuerung verwaltet wird.

Viele dieser Anbieter sind zwar in der Lage, Overlay-Netzwerke von lokalen Rechenzentren auf Public-Cloud-Anbieter auszudehnen, aber die Realität sieht so aus, dass viele Unternehmen Overlay-Netzwerke nur lokal in ihren lokalen Rechenzentren bereitstellen.

Anstatt ihre lokale SDN-Lösung auf die Public Cloud auszudehnen (z. B. ihre getunnelte Netzwerktopologie auf AWS oder Azure auszudehnen), erstellen viele Unternehmen lokal verwaltete Umgebungen in ihren Public-Cloud-Instanzen und verwalten diese Netzwerke anders als die Verwaltung ihrer lokalen Rechenzentrumsnetzwerke. Sie entscheiden sich oft dafür, die Netzwerkansätze zu verwenden, die bereits von jedem Public-Cloud-Anbieter verwendet werden, z. B. VPCs in AWS und VNet in Azure, und verwalten dann die SDN-Lösungen in ihren lokalen Rechenzentren unterschiedlich.

Das Ergebnis ist eine Hybrid-Cloud-Netzwerkbereitstellung, die nach einem „Drehstuhl“ -Ansatz verwaltet wird. Der Netzwerkmanager dreht seinen Stuhl zwischen den Tools hin und her, die für die Verwaltung seines Rechenzentrums vor Ort verwendet werden, und anderen Tools, die für die Verwaltung seiner öffentlichen Cloud-Netzwerke verwendet werden. Der Begriff Hybrid Cloud impliziert oft eine einzige, einheitliche Architektur, die in Bezug auf den Betrieb oft nicht korrekt ist.

Schutz Ihrer Hybridumgebung

Dieser fragmentierte Ansatz für das Netzwerkmanagement gilt insbesondere für die Sicherheit in einer Hybrid Cloud. So wie lokal verwaltete Netzwerktools in jeder Umgebung in lokalen Rechenzentren und öffentlichen Clouds verwendet werden, gilt das Gleiche für Sicherheitslösungen. Die meisten SDN-Netzwerkanbieter verfügen über ihre eigenen grundlegenden, integrierten Sicherheitstools, die verwendet werden können, um in ihrer lokal verwalteten Umgebung ein gewisses Maß an Durchsetzung von Richtlinien zu ermöglichen. Und alle großen Public-Cloud-Anbieter haben ihre eigenen Sicherheitslösungen, die ebenfalls grundlegende Maßnahmen zur Durchsetzung von Richtlinien ermöglichen.

Leider sind diese Sicherheitstools in der Gesamtarchitektur isoliert. Jede Sicherheitslösung lässt sich in der Sandbox nicht gut mit anderen kombinieren, und das Korrelieren einer Sicherheitsverletzung zwischen allen ist eine umständliche Aufgabe, die zu großen Verzögerungen bei der Behebung führt.

Wenn Workloads außerdem live zwischen Umgebungen migriert werden, z. B. zwischen einem lokalen Rechenzentrum und einer öffentlichen Cloud-Instanz, wird die Richtliniendurchsetzung diesen Workload in der Regel nicht bis zum Ziel verfolgen. Dies führt dazu, dass manuelle Ansätze erforderlich sind, um die Richtlinien irgendwie zwischen den Sicherheitstools in den einzelnen Umgebungen zu übertragen, oder dass man sich auf eine SIEM-Lösung verlassen muss, um Informationen aus allen Umgebungen einzuspeisen, was im Vorfeld eine Menge an Skripterstellung erfordert.

Aufgrund der betrieblichen Komplexität werden diese Schritte einfach nicht oft durchgeführt, was zu erheblichen Lücken in Bezug auf Sicherheit und Workload-Transparenz in der gesamten Hybrid Cloud führt.

Anstatt sich auf die isolierten, nativen Sicherheitstools in jeder Netzwerkumgebung in einer Hybrid Cloud zu verlassen, um die Sicherheit Ihrer Workloads durchzusetzen, warum setzen Sie Sicherheit und Transparenz nicht einfach direkt am Workload durch, abstrahiert von den zugrunde liegenden Netzwerktools?

Ähnlich wie Overlay-Netzwerke Topologien erstellen, die über Abhängigkeiten von den zugrunde liegenden Routern und Switches abstrahiert sind, warum nicht denselben Sicherheitsansatz anwenden? Die Sicherheit sollte auch von den zugrunde liegenden Abhängigkeiten der Netzwerkstruktur abstrahiert — virtualisiert — und direkt am Workload aktiviert werden, unabhängig davon, wo der Workload gehostet wird oder wohin er während seines Lebenszyklus live migriert wird. Ähnlich wie Overlay-Netzwerke einen konsistenten Netzwerkansatz in einer Hybrid-Cloud ermöglichen, sollte auch die Sicherheit auf die gleiche Weise konzipiert werden.

Wie Mikrosegmentierung helfen kann

Bei Illumio wenden wir Sicherheit (Mikrosegmentierung) direkt auf jeden einzelnen Workload in einer gesamten Hybrid Cloud an. Da die Richtlinien zur Mikrosegmentierung so nah wie möglich an der Entität durchgesetzt werden sollten, die Sie schützen möchten, setzen wir für jeden Workload, ob virtuell oder Bare-Metal, einen Lightweight Agent ein:

• Dieser Agent ist für keinen Verkehr zuständig. Er befindet sich einfach im Hintergrund und überwacht das Anwendungsverhalten direkt auf der Arbeitslast.
• Die Informationen werden dann an den zurückgesendet Richtlinie Compute Engine (PCE), um einen klaren Einblick in das Verhalten zwischen allen Workloads zu ermöglichen, unabhängig davon, wo sie gehostet werden oder zwischen welchen Netzwerkumgebungen sie live migrieren. Im Wesentlichen virtualisieren wir die Sicherheit, abstrahiert von den zugrunde liegenden Netzwerkabhängigkeiten.
• Das zentrale PCE verwendet einfache Bezeichnungen, um zu definieren, was segmentiert werden muss, da die Definition von Richtlinien anhand von IP-Adressen in Architekturen, in denen Workloads dynamisch migriert werden und sich IP-Adressen ändern, nicht skaliert werden kann.

Das PCE erstellt zwar eine virtualisierte Sicherheitsarchitektur, kann aber bei Bedarf auch bis in die Netzwerkebene „hinab“ reichen und Zugriffslisten für Hardware-Switches in einem lokalen Rechenzentrum konfigurieren. Während also die Sicherheit virtualisiert und über dem Netzwerk abstrahiert wird, kann Illumio sowohl Workload als auch Netzwerksicherheit von einem zentralen politischen Betriebsmodell aus.

Wenn Sie die grundlegenden, wesentlichen Ressourcen in einem Rechenzentrum oder einer Hybrid-Cloud als Rechenleistung, Speicher und Netzwerk definieren, werden alle drei Ressourcen nun üblicherweise virtualisiert und über den zugrunde liegenden Ressourcen abstrahiert.

Die vierte wichtige Ressource im Rechenzentrum ist die Sicherheit, und es sollte sich ebenfalls um virtualisierte und zugrunde liegende Ressourcenabhängigkeiten handeln. Eine Hybrid-Cloud sollte nicht mit hybrider Sicherheit gleichgesetzt werden. Die Sicherheit sollte sich über die gesamte Netzwerk-Cloud-Fabric erstrecken, und die Workload-Sicherheit sollte direkt am Workload durchgesetzt werden, und zwar als eine einheitliche Sicherheits- „Fabric“ für alle Netzwerkstrukturen. Die Virtualisierung der Sicherheit gibt den zugrundeliegenden Netzwerkarchitekten die Möglichkeit, sich auf die Netzwerkprioritäten zu konzentrieren, und die Workload-Sicherheit wird dort platziert, wo sie hingehört: direkt am Workload.

Erfahren Sie mehr darüber, wie dieser Ansatz es einfacher macht, verwalten Sie die Sicherheit in Ihren Hybrid-Cloud-Umgebungen.