Warum Hybrid Cloud nicht gleichbedeutend mit Hybrid-Sicherheit sein sollte
Hybrid-Cloud-Netzwerk-Fabrics lösen heute viele Herausforderungen in Unternehmensnetzwerken. Sie ermöglichen die Erstellung einer einzigen Netzwerkarchitektur, die über die zugrunde liegenden Rechenzentrumsumgebungen abstrahiert ist. Sie ermöglichen auch Fehlertoleranz, Ausfallsicherheit, "elastische" Dienste über Rechenzentren hinweg und eine Netzwerktopologie, die nicht von einem einzigen zugrunde liegenden Netzwerkanbieter abhängig ist. Ein Unternehmen kann mehrere physische Netzwerkumgebungen verwalten, aber kann es eine einzige Netzwerkstruktur für alle erstellen?
So kann ein Unternehmen beispielsweise zwei Rechenzentren (ein primäres und ein weiteres für die Notfallwiederherstellung) zusätzlich zu mehreren Public-Cloud-Bereitstellungen auf AWS, Azure und/oder GCP unterhalten. Jede dieser Hosting-Umgebungen stellt ihre eigenen zugrunde liegenden physischen Netzwerkarchitekturen mit ihren eigenen spezifischen Technologien bereit, oft mit unterschiedlichen Routing- und Switching-Anbietern.
Aber mit dem Aufkommen von Software-Defined Networking (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 häufig 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. Mit dieser Cloud kann eine einzige, einheitliche Netzwerkstruktur für alle verwalteten Hosting-Umgebungen erstellt werden.
Ein Tunneling-Protokoll, z. B. VXLAN, wird verwendet, um die Overlay-Netzwerktopologie zu erstellen, sodass der Pfad des Datenverkehrs durch die Art und Weise bestimmt wird, wie diese Tunnel bereitgestellt werden, und nicht durch die Art und Weise, 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 im Grunde alle dasselbe: Sie verwenden Tunnel, um ein Overlay-Netzwerk zu erstellen, das automatisiert und von einem zentralen Controller verwaltet wird.
Während viele dieser Anbieter in der Lage sind, Overlay-Netzwerke von lokalen Rechenzentren auf Public-Cloud-Anbieter auszudehnen, ist die Realität, 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 ihre lokalen Rechenzentrumsnetzwerke. Sie entscheiden sich häufig dafür, die Netzwerkansätze zu verwenden, die bereits bei 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 anders.
Das Ergebnis ist eine Hybrid-Cloud-Netzwerkbereitstellung, die in einem "Drehstuhl"-Ansatz verwaltet wird. Der Netzwerkmanager wechselt zwischen den Tools, die für die Verwaltung seines lokalen Rechenzentrums verwendet werden, und anderen Tools, die für die Verwaltung seiner öffentlichen Cloud-Netzwerke verwendet werden, hin und her. Der Begriff Hybrid Cloud impliziert oft eine einzige, einheitliche Architektur, die oft nicht korrekt ist, wenn es um den Betrieb geht.
Sichern Ihrer hybriden Umgebung
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 Public Clouds verwendet werden, gilt dies auch für Sicherheitslösungen. Die meisten Anbieter von SDN-Netzwerken verfügen über ihre eigenen grundlegenden, integrierten Sicherheitstools, die verwendet werden können, um ein gewisses Maß an Richtliniendurchsetzung in ihrer lokal verwalteten Umgebung zu ermöglichen. Und alle großen Public-Cloud-Anbieter haben ihre eigenen Sicherheitslösungen, die auch ein grundlegendes Maß an Richtliniendurchsetzung ermöglichen.
Aber leider sind diese Sicherheitstools in der Gesamtarchitektur isoliert. Jede Sicherheitslösung funktioniert in der Sandbox nicht gut mit anderen, und die Korrelation einer Sicherheitsverletzung zwischen allen ist eine umständliche Aufgabe, die zu großen Verzögerungen bei der Lösung führt.
Wenn Workloads live zwischen Umgebungen migriert werden, z. B. zwischen einem lokalen Rechenzentrum und einer Public Cloud-Instanz, wird die Richtliniendurchsetzung diese Workload in der Regel nicht bis zu ihrem Ziel verfolgen. Dies führt dazu, dass manuelle Ansätze erforderlich sind, um Richtlinien zwischen Sicherheitstools in jeder Umgebung zu übertragen, oder dass man sich auf eine SIEM-Lösung verlassen muss, um Informationen aus allen Umgebungen zu übermitteln, was im Vorfeld viel Skriptarbeit erfordert.
Aufgrund der betrieblichen Komplexität werden diese Schritte einfach nicht oft durchgeführt, was zu erheblichen Lücken in der 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 für Ihre Workloads durchzusetzen, warum nicht stattdessen einfach Sicherheit und Transparenz direkt am Workload durchsetzen, abstrahiert von den zugrunde liegenden Netzwerktools?
Ähnlich wie Overlay-Netzwerke Topologien erstellen, die über die Abhängigkeiten der zugrunde liegenden Router und Switches abstrahiert sind, warum nicht den gleichen Ansatz für die Sicherheit anwenden? Die Sicherheit sollte auch von den zugrunde liegenden Abhängigkeiten der Netzwerk-Fabric abstrahiert – virtualisiert – und direkt an der Workload aktiviert werden, unabhängig davon, wo diese Workload gehostet wird oder wohin sie während ihres Lebenszyklus live migriert wird. Ähnlich wie Overlay-Netzwerke einen konsistenten Ansatz für Netzwerke in einer Hybrid Cloud ermöglichen, sollte die Sicherheit auf die gleiche Weise gestaltet werden.
Wie Mikrosegmentierung helfen kann
Bei Illumio wenden wir Sicherheit (Mikrosegmentierung) direkt auf jeden einzelnen Workload in einer gesamten Hybrid Cloud an. Da die Mikrosegmentierungsrichtlinie so nah wie möglich an der Entität durchgesetzt werden sollte, die Sie schützen möchten, setzen wir für jeden Workload, ob virtuell oder Bare-Metal, einen schlanken Agenten ein:
- Dieser Agent ist nicht mit Datenverkehr verbunden. Es befindet sich einfach im Hintergrund und überwacht das Anwendungsverhalten direkt auf der Workload.
- Die Informationen werden dann an die Policy Compute Engine (PCE) zurückgesendet, um einen klaren Einblick in das Verhalten aller 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.
- Der zentrale PCE verwendet einfache Bezeichnungen, um zu definieren, was segmentiert werden muss, da das Definieren von Richtlinien für IP-Adressen in Architekturen, in denen Workloads dynamisch live migriert werden und sich IP-Adressen ändern, nicht skaliert werden kann.
Während der PCE eine virtualisierte Sicherheitsarchitektur erstellt, kann er bei Bedarf auch in die Netzwerkschicht "greifen" und Zugriffslisten für Hardware-Switches in einem lokalen Rechenzentrum konfigurieren. Während also die Sicherheit virtualisiert und über das Netzwerk abstrahiert wird, kann Illumio sowohl die Workload als auch die Netzwerksicherheit von einem zentralen Richtlinienbetriebsmodell aus anwenden.
Wenn Sie die grundlegenden, wesentlichen Ressourcen in einem Rechenzentrum oder einer Hybrid Cloud als Computing, Speicher und Netzwerk definieren, werden alle drei Ressourcen jetzt in der Regel virtualisiert und über die zugrunde liegenden Ressourcen abstrahiert.
Die vierte wichtige Ressource für Rechenzentren ist die Sicherheit, und sie sollte ebenfalls virtualisiert sein und Ressourcenabhängigkeiten zugrunde liegen. Hybrid Cloud sollte nicht gleichbedeutend mit hybrider Sicherheit sein. Die Sicherheit sollte sich über die gesamte Netzwerk-Cloud-Fabric erstrecken, und die Workload-Sicherheit sollte direkt an der Workload als eine einheitliche Sicherheits-"Fabric" für alle Netzwerk-Fabrics durchgesetzt werden. Durch die Virtualisierung der Sicherheit können sich die zugrunde liegenden Netzwerkarchitekten auf die Netzwerkprioritäten konzentrieren, und die Workload-Sicherheit wird dort platziert, wo sie hingehört: direkt an der Arbeitslast.
Erfahren Sie mehr darüber, wie dieser Ansatz die Verwaltung der Sicherheit in Ihren Hybrid-Cloud-Umgebungen erleichtert.