Netzwerksicherheit ist nicht gleich Workload-Sicherheit

Sicherheitsverletzungen, Hacks, Hijacking, Datenverlust und Exfiltration sind Probleme, die in den meisten Cloud-Architekturen aus einem sehr 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 unterschiedlichen Prioritäten im Hinterkopf entwickelt: Funktionalität und Ausfallsicherheit. Diese Aufgaben müssen alle funktionieren, und sie müssen Fehler von Elementen in der Gesamtarchitektur überstehen, aber die Sicherung dieser Elemente war in der Regel ein nachträglicher Gedanke.

Da das Netzwerk die kritische Infrastruktur in der Gesamtarchitektur ist, 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 aus aufgerufen werden können, entweder über ein privates Netzwerk oder über das Internet. Dies ist in jeder Art von Cloud-Architektur erforderlich, und jede Cloud-native Architektur funktioniert einfach nicht, wenn nicht bereits ein Netzwerk vorhanden ist, um darüber zu kommunizieren. Man kann also argumentieren, dass das wichtigste Element jeder gesamten Cloud-Architektur tatsächlich das Netzwerk selbst ist.

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

• Zuverlässigkeit (das Netzwerk muss funktionieren)
• Ausfallsicherheit (der Ausfall eines oder mehrerer Netzwerkgeräte sollte keinen systemweiten Ausfall verursachen)
• Traffic Engineering und Quality of Service (IP-Netzwerke sind von Natur aus "verbindungslos", aber es sollte Möglichkeiten geben, verschiedene Arten von Datenverkehr zu entwickeln und zu priorisieren)
• Skalierung (Netzwerke sollten in der Lage sein, sich weiterzuentwickeln, ohne eine Ressourcenobergrenze zu erreichen)

Anwendungen und Workloads sollten sich dieser Details nicht bewusst sein müssen, damit sie das Netzwerk verwenden können.

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

Eine kurze Geschichte der Netzwerksicherheit

Da Sicherheit bei den meisten Cloud-Architekturen immer das Nachzügler ist, wurden Sicherheit und Netzwerksegmentierung traditionell auf Netzwerkebene implementiert. Da das Netzwerk die kritische Infrastruktur in der Gesamtarchitektur ist, erscheint es sinnvoll, dort Sicherheits- und Mikrosegmentierungslösungen einzusetzen.

Dreht man die Uhr um mehrere Jahrzehnte zurück, so erfolgte 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, d. h., wenn 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 werden soll.

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

Im Allgemeinen ist es jedoch 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 Datennutzlast enthalten ist. Daher haben sich sitzungsbasierte Firewalls so entwickelt, dass sie sich darauf konzentrieren, alle Pakete in einem bestimmten Fluss einer eindeutigen Sitzung zuzuordnen und das Verhalten dieser Sitzung basierend auf der Anwendung zu überwachen, mit der sie "denkt", dass sie verbunden ist. Diese Firewalls hatten keinen vollständigen Einblick in jedes Paket, aber sie verglichen das Verhalten dieser Pakete und Sitzungen mit dem Baselineverhalten der Anwendung und suchten nach Anomalien.

Später erschienen sogenannte Firewalls der "nächsten Generation", die weitaus mehr Intelligenz anwenden, um zu identifizieren, was in einem Paket enthalten ist, mit welcher Anwendung es verbunden ist, mit welchem Benutzer es verbunden ist und andere Details, die auf eine Sicherheitsverletzung hinweisen. All diese Details erfolgen jedoch inline im Netzwerk, 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 auch Workloads und Anwendungen überwacht und dann ausgewählten Datenverkehr zur Firewall leitet. Die Bereitstellung kann jedoch komplex sein, so dass Firewalls oft einfach im Netzwerk sitzen und darauf warten, dass Pakete ankommen.

Netzwerksicherheit unterscheidet sich von der Workload-Sicherheit

Parallel zu Firewalls, die Entscheidungen darüber treffen, welche Pakete weitergeleitet werden dürfen und welche nicht, haben Router und Switches ihre eigenen Sicherheitsbedenken, die sich aus demselben grundlegenden Problem ergeben: Sicherheit war bei der ursprünglichen Entwicklung von Netzwerkprotokollen kein primäres Anliegen.

TCP/IP und dynamische Routing-Protokolle, die zum Weiterleiten von Paketen verwendet werden, wie z. B. BGP und OSPF, wurden mit den gleichen grundlegenden Zielen wie Anwendungen und Workloads entwickelt: Funktionalität und Ausfallsicherheit. Sicherheit hatte bei den Anfängen des Netzwerks keine Priorität. Sicherheit und Mikrosegmentierung wurden in einer späteren Phase der Netzwerkentwicklung zu einer Priorität, und Netzwerksicherheitslösungen wurden eingesetzt, um Sicherheitsbedenken auszuräumen, die für Netzwerke spezifisch sind. Sicherheit ist nicht nur ein Problem für Workloads und Anwendungen. Es gibt Sicherheitsbedenken im Netzwerk, die für Workloads und Anwendungen keinen Einblick haben.

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

• Verkehrstechnik
• Denial-of-Service (DoS)
• ARP-Spoofing
• BGP-Authentifizierung
• Umleitung des Datenverkehrs
• Man-in-the-Middle-Angriffe
• Gefälschte Routenweitergabe
• First-Hop-Router-Hijacking
• Hijacking von Sitzungscookies

Bei den Elementen in dieser kurzen Liste handelt es sich um Sicherheitsaspekte, die sich auf das Netzwerk beziehen, nicht auf Workloads oder Anwendungen. Zum Beispiel werden verkehrstechnische Herausforderungen durch Technologien wie MPLS und die Zuverlässigkeit von Etikettenverteilungsprotokollen gelöst. Denial-of-Service ist ein erhebliches Problem, das häufig durch die Verwendung von BGP-Communities gelöst 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, was dazu führt, dass das Ziel des Datenverkehrs gekapert wird. Die BGP-Authentifizierung erfordert so 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 verfügen über ein eigenes Fachvokabular, um Sicherheitsprobleme zu lösen, die für die Netzwerkschicht jeder Cloud-Architektur einzigartig sind.

Diese Beispiele sind nur einige der wichtigsten Sicherheitsbedenken von Netzwerkarchitekturen, nicht von Workload- oder Anwendungsarchitekturen. Anwendungsentwicklungs- und Systemteams haben in der Regel keinen Einblick in diese Bedenken hinsichtlich der Netzwerksicherheit, da sie dies auch nicht tun sollten. Wenn das Betriebssystem eines Workloads iptables verwendet, z. B. zum Senden oder Empfangen eines Pakets, muss es nicht wissen, ob BGP irgendwo zwischen ISPs im Netzwerk gekapert wird. Bei Workloads und Anwendungen geht es um die Workload- und Anwendungssicherheit, nicht um die Netzwerksicherheit.

Netzwerksicherheitslösungen sind keine Workload-Sicherheitslösungen

Das bedeutet, dass Tools, die für die Bewältigung von Herausforderungen der Netzwerksicherheit entwickelt wurden, in der Regel nicht die geeigneten Tools sind, um Sicherheits- und Mikrosegmentierungsherausforderungen bei Workloads oder Anwendungen zu bewältigen. Die Sicherheit von Workloads muss oft nicht durch die Skalierung begrenzt sein: Die Bereitstellung von Tausenden von Workloads über mehrere Clouds hinweg sollte nicht von einem einzigen Tool auf Netzwerkebene abhängig sein, um diesen Workloads Sicherheit auf Anwendungsebene zu bieten.

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 nachverfolgen, um die Workload-Sicherheit und Mikrosegmentierung durchzusetzen. Anwendungen beruhen auf Abhängigkeiten über Workloads hinweg, und diese Abhängigkeiten sind für Tools auf Netzwerkebene oft nicht sichtbar, sodass die Definition eines Ringfences um Anwendungen nicht durch den Mangel an Transparenz des Netzwerks in vollständige Anwendungsabhängigkeiten eingeschränkt werden sollte.

Einige Netzwerkanbieter bieten ihre SDN-Lösungen als Lösungen für Workload- und Anwendungssicherheits- und Mikrosegmentierungsanforderungen an. Diese Tools befinden sich jedoch in den Netzwerk- oder Hypervisor-Schichten, und diese Tools wurden entwickelt, um Prioritäten auf diesen Ebenen zu adressieren, z. B. Automatisierung, Virtualisierung, Netzwerkanalyse, Netzwerk-Overlays und Tunneling sowie Authentifizierung zwischen dynamischen Routing-Protokollen. SDN-Tools wurden nicht entwickelt, um Sicherheit und Mikrosegmentierung für Workloads und Anwendungen in großem Umfang zu bieten.

Sie können auch Firewalls – entweder Hardware oder virtualisierte Instanzen in einem Hypervisor – als Lösungen für Workload- und Anwendungssicherheitsanforderungen vorschlagen, mit dem Argument, dass Firewalls der nächsten Generation eine vollständige Layer-7-Transparenz des Netzwerkverkehrs bieten. Eine Firewall ist jedoch nur 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 erzwingen Netzwerksicherheit und Mikrosegmentierung, während der Datenverkehr unterwegs ist – Nord-Süd-Verkehr. Sie erzwingen die Anwendungs- oder Workloadsicherheit nicht an der Quelle – dem Ost-West-Datenverkehr. Beide Lösungen sind für die Realisierung einer echten Zero-Trust-Architektur erforderlich, aber eine Schicht der Architektur kann der anderen keine vollständige Sicherheit und Mikrosegmentierung bieten.

Netzwerkteams sollten nicht mit der Arbeitslast oder der Anwendungssicherheit betraut werden

Netzwerkteams konzentrieren sich auf Netzwerkaufgaben, die sich von Workload- oder Anwendungsaufgaben unterscheiden. Diese Aufgaben betreffen Begriffe, die für diese Teams relevant sind, wie z. B. Layer-2- und Layer-3-Übersetzungen und Weiterleitungsmechanismen, Routing-Protokolle wie BGP und OSPF und deren Peering untereinander sowie ihre eigenen Authentifizierungsmechanismen. Lösungen für Layer-2-Netzwerkprobleme, wie z. B. Spanning Tree und ECMP, haben ebenfalls ihre eigenen Sicherheitsprioritäten. Netzwerktools wie SDN und virtualisierte Netzwerkgeräte, die in Hypervisoren bereitgestellt werden, konzentrieren sich auf Probleme, die für Netzwerkprioritäten spezifisch sind. Bei keiner dieser Lösungen haben Sicherheitsrisiken innerhalb einer Workload selbst Priorität.

Das alles bedeutet, dass beim Entwerfen von Sicherheits- und Mikrosegmentierungslösungen für Workloads diese Lösungen dort eingesetzt werden sollten: auf der Workload. Netzwerktools haben Prioritäten, die sich von der Workload oder den Anwendungsaspekten unterscheiden. Netzwerksicherheitstools werden immer vorhanden sein, die sich auf die Durchsetzung des Nord-Süd-Datenverkehrs innerhalb und außerhalb der gesamten Netzwerkstruktur konzentrieren. Diese Netzwerktools werden auf Netzwerkgeräten bereitgestellt. Die Workloadsicherheit sollte für die Workloads selbst bereitgestellt werden, wobei der Schwerpunkt auf der Durchsetzung des Ost-West-Datenverkehrs zwischen Workloads und zwischen Anwendungen liegt.

Wenn sich jede Schicht der Gesamtarchitektur auf die Prioritäten konzentriert, die für ihre eigene Schicht spezifisch sind, kann jede Schicht gegenüber der anderen agnostisch sein, wobei keine der beiden Schichten die Funktionsweise oder Skalierung der anderen einschränkt. Das Ergebnis ist eine vollständig realisierte Zero-Trust-Architektur.

Viele Cloud-native Architekturen befolgen Best Practices für die Sicherheit und stellen Workload-Sicherheitslösungen für die Workloads selbst bereit. Aber alte Gewohnheiten sterben schwer, und wenn bestehende IT-Umgebungen von Rechenzentren zu Cloud-Diensten migriert werden, wird oft auch der traditionelle Ansatz der Verwendung von Netzwerklösungen zur Durchsetzung der Workload-Sicherheit migriert, was zu einer Netzwerkschicht führt, die oft blind für Ost-West-Sicherheitsanforderungen zwischen Workloads und Anwendungen ist. Das Ergebnis ist nicht Zero Trust.

Hier fügt sich Illumio in die gesamte Sicherheitsarchitektur ein. Im Gegensatz zu herkömmlichen Ansätzen zur Netzwerksegmentierung ermöglicht Illumio die Durchsetzung von Sicherheit und Mikrosegmentierung direkt an der Stelle, die Sie sichern und segmentieren möchten: der Arbeitslast selbst. Auf diese Weise können Workload- und Anwendungssicherheit sowie Mikrosegmentierung skaliert und weiterentwickelt werden, ohne dass diese davon abhängig sind, wo sie sich im Netzwerk befinden. Auf diese Weise können Workloads überall in lokalen Rechenzentren oder bei Cloud-Anbietern gelagert oder migriert werden.

Eine Multi-Cloud-Architektur schafft eine umfassende Netzwerkstruktur mit Erreichbarkeit über alle zugrunde liegenden Netzwerktopologien hinweg. Sicherheit und Mikrosegmentierung sollten der gleichen Richtlinie folgen und eine konsistente und skalierbare Lösung über dieselbe Netzwerkstruktur hinweg und von Anfang bis Ende bieten. Zero Trust bedeutet, dass die Sicherheitsvertrauensgrenze auf jeden einzelnen Workload und jede Anwendung ausgeweitet wird, die geschützt werden muss, und dieses Ziel sollte nicht durch den Versuch eingeschränkt werden, dieses Ziel in einer anderen Schicht der Cloud-Architektur zu ermöglichen.

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

• Sehen Sie sich dieses kurze Übersichtsvideo über die Evolution der Segmentierungan
• Sehen Sie sich dieses On-Demand-Webinar an: Unlock Security from the Network: Segmentierung leicht gemacht