Netzwerksicherheit ist keine Workload-Sicherheit

Sicherheitslücken, Hacks, Hijacking, Datenverlust und Exfiltration sind alles Probleme, die in den meisten Cloud-Architekturen aus einem ganz einfachen Grund auftreten: Die meisten IT-Technologien wurden ursprünglich nicht mit Sicherheit als Priorität entwickelt. Die Komplexität rund um die Anwendungsentwicklung, Workload-Betriebssysteme, Netzwerkprotokolle und das gesamte Prozessmanagement wurde mit Blick auf unterschiedliche Prioritäten konzipiert: Funktionalität und Stabilität. Diese Aufgaben müssen alle funktionieren, und sie müssen Ausfälle von Elementen in der Gesamtarchitektur überstehen, aber Sicherung Diese Elemente waren im Allgemeinen ein nachträglicher Gedanke.

Da das Netzwerk die kritische Infrastruktur in der Gesamtarchitektur darstellt, erscheint es sinnvoll, dort Sicherheits- und Mikrosegmentierungslösungen einzusetzen.

Unabhängig davon, wie Anwendungen entwickelt werden, wie verschiedene Betriebssysteme erstellt und bereitgestellt werden und wie all dies virtualisiert, abstrahiert und verwaltet wird, müssen die meisten dieser Elemente miteinander kommunizieren. Wenn kein Netzwerk vorhanden ist, ist jede Anwendung eine Insel. Und die meisten Anwendungen sind heute so konzipiert, dass sie von Remote-Clients entweder über ein privates Netzwerk oder über das Internet abgerufen werden können. Dies ist in jeder Art von Cloud-Architektur erforderlich, und jede native Cloud-Architektur funktioniert einfach nicht, wenn nicht bereits ein Netzwerk vorhanden ist, um darüber zu kommunizieren. Es kann also argumentiert werden, dass Das wichtigste Element einer Cloud-Gesamtarchitektur ist eigentlich das Netzwerk selbst.

Aufgrund der kritischen Natur der Netzwerkinfrastruktur in jeder Cloud-Architektur gibt es Herausforderungen und Prioritäten, die nur für die Netzwerkebene aller Architekturen spezifisch sind. Das Netzwerk hat Bedenken, die völlig unabhängig von Workloads und Anwendungen sind, die vom Netzwerk abhängig sind. Einige Beispiele für diese Netzwerkprobleme sind:

• Zuverlässigkeit (das Netzwerk muss funktionieren)
• Resilienz (der Ausfall eines oder mehrerer Netzwerkgeräte sollte nicht zu einem systemweiten Ausfall führen)
• Verkehrstechnik und Dienstqualität (IP-Netzwerke sind von Natur aus „verbindungslos“, aber es sollte Möglichkeiten geben, verschiedene Arten von Verkehr zu planen und zu priorisieren)
• Skalierung (Netzwerke sollten sich weiterentwickeln können, ohne eine bestimmte Ressourcenobergrenze zu überschreiten)

Anwendungen und Workloads sollten keine dieser Details kennen müssen, damit sie das Netzwerk nutzen können.

Was bedeutet das also für die Sicherung des Netzwerks und die Sicherung von Workloads? Es gibt verschiedene Überlegungen, die ich untersuchen werde, insbesondere den Kontrast zwischen Netzwerksicherheit und netzwerkbasierte Lösungen sowie Workload-Sicherheit und Lösungen wie Mikrosegmentierung.

Eine kurze Geschichte der Netzwerksicherheit

Da Sicherheit bei den meisten Cloud-Architekturen immer erst spät dran ist, müssen Sicherheit und Netzwerksegmentierung wurden traditionell auf Netzwerkebene implementiert. Da das Netzwerk die kritische Infrastruktur in der Gesamtarchitektur darstellt, erscheint es sinnvoll, dort Sicherheits- und Mikrosegmentierungslösungen einzusetzen.

Wenn Sie die Zeit mehrere Jahrzehnte zurückdrehen, bestand die Sicherheit in IP-Netzwerken ursprünglich in Form von Zugriffskontrolllisten („ACLs“) auf Routern und Switches. Netzwerkgeräte verarbeiten den Datenverkehr in der Regel pro Paket. Wenn also Pakete an einem Router oder Switch ankommen, werden diese ACLs überprüft, um Entscheidungen darüber zu treffen, ob die Weiterleitung eines Pakets zugelassen oder blockiert wird.

Dieser Ansatz wurde dann an dedizierte Netzwerkgeräte — Firewalls — ausgelagert, die ursprünglich denselben grundlegenden Ansatz verwendeten. Da alle IP-Pakete in ihren Headern Informationen enthalten, die Quelle und Ziel angeben, zusätzlich zu den TCP- oder UDP-Nummern, die angeben, welche Art von Daten in der Datennutzlast des Pakets enthalten sind, verwendet eine Firewall diese Informationen, um Weiterleitungsentscheidungen auf der Grundlage ihrer eigenen Zugriffskontrolllisten zu treffen. Da sich das Netzwerk mit Paketen befasst, war es sinnvoll, das Netzwerk auch mit Sicherheit und Mikrosegmentierung zu beauftragen, sodass sich die Anwendungsentwicklungs- und Systemteams auf andere Belange konzentrieren konnten.

Es ist jedoch im Allgemeinen einfach, eine paketbasierte Firewall zu täuschen. Es ist nicht allzu schwierig, Adressen und TCP/UDP-Portnummern in einem IP-Paket zu „fälschen“, was zu einem Paket führt, das leicht maskieren kann, was in seiner Nutzlast enthalten ist. Daher haben sich sitzungsbasierte Firewalls dahingehend weiterentwickelt, dass sie sich darauf konzentrieren, alle Pakete in einem bestimmten Datenfluss einer bestimmten Sitzung zuzuordnen und das Verhalten dieser Sitzung auf der Grundlage der Anwendung zu überwachen, mit der sie „glaubt“, verknüpft zu sein. Diese Firewalls hatten keinen vollständigen Einblick in jedes Paket, aber sie vergleichen das Verhalten dieser Pakete und Sitzungen mit dem Basisverhalten der Anwendung und suchen nach Anomalien.

Später kamen sogenannte Firewalls der „nächsten Generation“ auf den Markt, die weitaus mehr Intelligenz einsetzen, um zu identifizieren, was in einem Paket enthalten ist, mit welcher Anwendung es verknüpft ist, mit welchem Benutzer es verknüpft ist und um andere Details, die auf eine Sicherheitsverletzung hinweisen. Doch all diese Details finden direkt im Netzwerk statt, nicht in den Quell- oder Ziel-Workloads selbst. Firewalls haben keine Ahnung, was bei den Workloads vor sich geht, die diese Pakete senden und empfangen, es sei denn, sie kommunizieren irgendwie mit einem zentralen Tool, das ebenfalls Workloads und Anwendungen überwacht und dann ausgewählten Datenverkehr zur Firewall leitet. Die Bereitstellung kann jedoch komplex sein, sodass Firewalls oft einfach im Netzwerk sitzen und darauf warten, dass Pakete ankommen.

Netzwerksicherheit unterscheidet sich von Workload-Sicherheit

Parallel zu Firewalls, die Entscheidungen darüber treffen, welche Pakete weitergeleitet werden können und welche nicht, haben Router und Switches ihre eigenen Sicherheitsbedenken, die auf dasselbe grundlegende Problem zurückzuführen sind: Sicherheit war bei der ursprünglichen Entwicklung von Netzwerkprotokollen kein Hauptanliegen.

TCP/IP- und dynamische Routing-Protokolle, die zur Weiterleitung von Paketen verwendet werden, wie BGP und OSPF, wurden mit den gleichen grundlegenden Zielen wie Anwendungen und Workloads entwickelt: Funktionalität und Stabilität. Sicherheit hatte zu Beginn der Netzwerktechnik keine Priorität. Sicherheit und Mikrosegmentierung wurden in einer späteren Phase der Netzwerkentwicklung zu einer Priorität, und Netzwerksicherheitslösungen wurden eingesetzt, um sicherheitsspezifische Sicherheitsprobleme im Zusammenhang mit Netzwerken auszuräumen. Sicherheit ist nicht nur ein Problem für Workloads und Anwendungen. Es gibt Sicherheitsbedenken im Netzwerk, in die Workloads und Anwendungen keinen Einblick haben.

Zur Erinnerung: Dies sind nur einige Beispiele für Sicherheitsherausforderungen, die auf der Netzwerkebene jeder Cloud-Architektur bestehen:

• Verkehrstechnik
• Diensteverweigerung (DoS)
• ARP-Spoofing
• BGP-Authentifizierung
• Verkehrsumleitung
• Man-in-the-Middle-Angriffe
• Ausbreitung gefälschter Routen
• Router-Hijacking im First-Hop-Modus
• Hijacking von Sitzungscookies

Bei den Punkten in dieser kurzen Liste handelt es sich ausschließlich um Netzwerksicherheitsprobleme, nicht um Workloads oder Anwendungen. Technologien wie MPLS und die Zuverlässigkeit von Protokollen zur Etikettenverteilung lösen beispielsweise verkehrstechnische Herausforderungen. Denial-of-Service ist ein erhebliches Problem, das häufig durch den Einsatz von BGP-Communities behoben wird, die mit ISP-Routing-Peers ausgetauscht werden. ARP-Spoofing ist ein Problem, bei dem Router ihre Zuordnungen zwischen Layer-3- und Layer-2-Adressen ändern, wodurch das Ziel des Datenverkehrs gekapert wird. Die BGP-Authentifizierung erfordert etwas wie RPKI, um Informationen zu verschlüsseln, die zwischen BGP-Peers ausgetauscht werden, um Probleme beim Routing über das Internet zu vermeiden. Und so weiter. Netzwerke haben ihr eigenes Fachvokabular, um Sicherheitsprobleme zu lösen, die nur auf der Netzwerkebene einer Cloud-Architektur auftreten.

Diese Beispiele sind nur einige der wichtigsten Sicherheitsbedenken von Netzwerkarchitekturen, nicht von Workload- oder Anwendungsarchitekturen. Anwendungsentwicklungs- und Systemteams haben im Allgemeinen keinen Einblick in diese Netzwerksicherheitsprobleme, da sie dies eigentlich nicht benötigen sollten. Wenn das Betriebssystem eines Workloads Iptables verwendet, um beispielsweise ein Paket zu senden oder zu empfangen, müssen sie nicht wissen, ob BGP irgendwie irgendwo zwischen ISPs im Netzwerk gekapert wird. Workloads und Anwendungen befassen sich mit der Workload- und Anwendungssicherheit, nicht mit der Netzwerksicherheit.

Netzwerksicherheitslösungen sind keine Workload-Sicherheitslösungen

Was das bedeutet ist, dass Tools, die für die Bewältigung von Netzwerksicherheitsproblemen entwickelt wurden, sind in der Regel nicht die geeigneten Tools, um die Sicherheits- und Mikrosegmentierungsprobleme bei Workloads oder Anwendungen zu bewältigen. Workload-Sicherheit erfordert oft, dass keine Skalenbegrenzung besteht: Die Bereitstellung Tausender von Workloads in mehreren Clouds sollte nicht von einem Tool auf Netzwerkebene abhängig sein, das irgendwie Sicherheit auf Anwendungsebene für diese Workloads bietet.

Workloads werden häufig live über Layer-3-Grenzen oder zwischen Clouds migriert, und Workloads sollten nicht von Tools auf Netzwerkebene abhängig sein, die diese Migrationen irgendwie verfolgen, um sie durchzusetzen Workload-Sicherheit und Mikrosegmentierung. Anwendungen hängen von Abhängigkeiten zwischen verschiedenen Workloads ab, und diese Abhängigkeiten sind für Tools auf Netzwerkebene oft nicht sichtbar. Daher sollte die Definition eines Ringfence rund um Anwendungen nicht durch den fehlenden Einblick des Netzwerks in die vollständigen Anwendungsabhängigkeiten eingeschränkt werden.

Einige Netzwerkanbieter werden ihre SDN-Lösungen als Lösungen für die Anforderungen an Workload- und Anwendungssicherheit sowie Mikrosegmentierung anbieten. Diese Tools befinden sich jedoch auf der Netzwerk- oder Hypervisor-Ebene, und diese Tools wurden entwickelt, um Prioritäten auf diesen Ebenen zu berücksichtigen: wie Automatisierung, Virtualisierung, Netzwerkanalysen, Netzwerk-Overlays und -Tunneling sowie Authentifizierung zwischen dynamischen Routing-Protokollen. SDN-Tools wurden nicht dafür konzipiert, Sicherheit und Mikrosegmentierung für Workloads und Anwendungen in großem Maßstab zu bieten.

Sie können auch Firewalls — entweder Hardware oder virtualisierte Instanzen in einem Hypervisor — als Lösungen für die Anforderungen an die Workload- und Anwendungssicherheit vorschlagen, und argumentieren, dass Firewalls der nächsten Generation eine vollständige Layer-7-Transparenz des Netzwerkverkehrs bieten. Jede Firewall ist jedoch erst dann nützlich, wenn Pakete sie erreichen. Firewalls sind nicht in der Lage, das Verhalten von Anwendungen oder Workloads an ihrer Quelle zu beeinflussen, sondern warten nur darauf, dass Pakete am Port einer Firewall ankommen. Firewalls sorgen für Netzwerksicherheit und Mikrosegmentierung, da der Verkehr im Transit ist — Nord-Süd-Verkehr. Sie setzen die Anwendungs- oder Workload-Sicherheit nicht an der Quelle durch — den Ost-West-Verkehr. Beide Lösungen sind für eine echte Null Vertrauen Architektur muss realisiert werden, aber eine Ebene der Architektur kann der anderen keine vollständige Sicherheit und Mikrosegmentierung bieten.

Netzwerkteams sollten nicht mit der Workload- oder Anwendungssicherheit beauftragt werden

Netzwerkteams konzentrieren sich auf Netzwerkaufgaben, die sich von Workload- oder Anwendungsaufgaben unterscheiden. Diese Aufgaben beinhalten Begriffe, die für diese Teams relevant sind, wie Layer-2- und Layer-3-Übersetzungen und Weiterleitungsmechanismen, Routing-Protokolle wie BGP und OSPF und wie sie miteinander verglichen werden sowie ihre eigenen Authentifizierungsmechanismen. Lösungen für Layer-2-Netzwerkprobleme wie Spanning Tree und ECMP haben ebenfalls ihre eigenen Sicherheitsprioritäten. Netzwerktools wie SDN und virtualisierte Netzwerk-Appliances, die in Hypervisoren eingesetzt werden, konzentrieren sich auf Probleme, die für Netzwerkprioritäten spezifisch sind. Bei keiner dieser Lösungen haben Sicherheitsrisiken innerhalb eines Workloads selbst Priorität.

All dies bedeutet, dass bei der Entwicklung von Sicherheits- und Mikrosegmentierungslösungen für Workloads diese Lösungen dort eingesetzt werden sollten: auf der Arbeitslast. Netzwerktools haben Prioritäten, die sich je nach Arbeitslast oder Anwendungsproblemen unterscheiden. Tools zur Netzwerksicherheit wird es immer geben, deren Schwerpunkt auf der Durchsetzung des Nord-Süd-Verkehrs innerhalb und außerhalb des gesamten Netzwerkgefüges liegt. Diese Netzwerktools werden auf Netzwerkgeräten eingesetzt. Die Workload-Sicherheit sollte auf den Workloads selbst installiert werden. Diese werden sich auf die Durchsetzung des Ost-West-Traffics, zwischen Workloads und zwischen Anwendungen konzentrieren.

Wenn sich jede Ebene der Gesamtarchitektur auf die Prioritäten konzentriert, die für ihre eigene Ebene spezifisch sind, kann jede Ebene unabhängig von der anderen sein, ohne dass keine Ebene die Funktionsweise oder Skalierung der anderen einschränkt. Das Ergebnis ist eine vollständig realisierte Zero-Trust-Architektur.

Viele Cloud-native Architekturen folgen bewährten Sicherheitsmethoden und implementieren Workload-Sicherheitslösungen auf den Workloads selbst. Alte Gewohnheiten lassen sich jedoch nur schwer überwinden, und zwar häufig, wenn bestehende IT-Umgebungen von Rechenzentren zu Cloud-Dienste, der traditionelle Ansatz, bei dem versucht wird, die Workload-Sicherheit mithilfe von Netzwerklösungen durchzusetzen, wird ebenfalls migriert. Das Ergebnis ist eine Netzwerkebene, die häufig blind für die Sicherheitsanforderungen von Ost nach West zwischen Workloads und Anwendungen ist. Das Ergebnis ist nicht Zero Trust.

An dieser Stelle fügt sich Illumio in die gesamte Sicherheitsarchitektur ein. Im Gegensatz zu herkömmlichen Ansätzen zur Netzwerksegmentierung ermöglicht Illumio, dass Sicherheit und Mikrosegmentierung direkt bei der Einheit durchgesetzt werden, die Sie schützen und segmentieren möchten: bei der Arbeitslast selbst. Auf diese Weise können Workload- und Anwendungssicherheit sowie Mikrosegmentierung skaliert und weiterentwickelt werden, ohne davon abhängig zu sein, wo sich diese im Netzwerk befinden. Auf diese Weise können Workloads überall in Rechenzentren vor Ort oder zwischen Cloud-Anbietern gespeichert oder migriert werden.

Eine Multi-Cloud-Architektur wird eine umfassende Netzwerkstruktur schaffen, die über alle zugrunde liegenden Netzwerktopologien hinweg erreichbar ist. Sicherheit und Mikrosegmentierung sollten derselben Richtlinie folgen und eine konsistente und skalierbare Lösung für dieselbe Netzwerkstruktur bieten, von Anfang bis Ende. Zero Trust bedeutet, dass die Grenze des Sicherheitsvertrauens auf jeden einzelnen Workload und jede Anwendung, die geschützt werden muss, ausgedehnt wird. Dieses Ziel sollte nicht dadurch eingeschränkt werden, dass versucht wird, dieses Ziel auf einer anderen Ebene der Cloud-Architektur zu erreichen.

Um mehr über diese Themen zu erfahren und zu erfahren, wie Illumio Workload- und Anwendungssicherheit löst:

• Sehen Sie sich dieses kurze Übersichtsvideo an Die Entwicklung der Segmentierung
• Schauen Sie sich dieses On-Demand-Webinar an: Sicherheit aus dem Netzwerk herauspacken: Segmentierung leicht gemacht