Die Migration in die Cloud ist für Unternehmen angesichts der Flexibilität, der unbegrenzten Skalierbarkeit und der potenziell niedrigeren Gesamtbetriebskosten (TCO) bei Infrastructure-as-a-Service (IaaS) verlockend.
Schon allein deshalb, weil sich Unternehmen nicht mit der Bereitstellung und Konfiguration von Routern und Switches oder mit Sicherheitsproblemen "in der Cloud" herumschlagen müssen. Die Migration zur Cloud schafft allerdings nicht alle Netzwerkprobleme aus dem Weg. Unter anderem müssen unzählige Datenpakete entschlüsselt und unnötige Datenströme verringert werden. Außerdem erfordern cloudbasierte Anwendungen genauso Transparenz wie On-Premises- oder virtualisierte Anwendungen. Und das nicht nur auf der Netzwerk- und Paketebene, sondern auch auf der Anwendungsebene. Auch die Herausforderung, Visibilität in den Ost-West-Verkehr zu gewinnen, um Datenflüsse zu verstehen und blinde Flecken zu vermeiden, besteht weiterhin. Viele, wenn nicht sogar die meisten der Probleme, mit denen Unternehmen On-Premises konfrontiert sind, bleiben also auch in der Cloud bestehen.
Trotz dieser Herausforderungen für die Cloud bleiben die Vorteile erhalten. Doch wie kann diesen Herausforderungen am besten begegnet werden, um eine sichere Netzwerkinfrastruktur und einen hohen Schutz gegenüber Cyberattacken zu gewährleisten?
Visibilität ist Voraussetzung für eine erfolgreiche Migration
Für IT-, Cloud- und Sicherheitsarchitekten, die mit diesen Herausforderungen konfrontiert sind und eine effektive Sicherheits- und Netzwerkhaltung in der Hybrid Cloud sicherstellen müssen, ist Sichtbarkeit des Netzwerkverkehrs der Schlüssel. Denn wenn ausgewählter Datenverkehr automatisch erfasst, analysiert, optimiert und auf unterschiedliche lokale und cloudbasierte Tools verteilt wird, erhöht das die Sicherheit und die Effizienz. Doch aktuell vielfach eingesetzte Tools können die Anforderungen an intelligente Netzwerkvisibilität, und damit an die Netzwerksicherheit, nicht gewährleisten.
Protokolldaten und Observability Tools eignen sich nicht als Visibilitätsquelle
Protokolldaten, z. B. aus VPC-Flow-Protokollen, sind für die Inhaltsprüfung unzureichend, da diese den Payload nicht enthalten und daher als Wahrheitsquelle unzuverlässig sind. Denn es kann sein, dass die Quelle der Protokolldaten kompromittiert ist und die Protokollinhalte von verschiedenen Elementen und Diensten variieren. Der Erhalt von Details auf Paketebene ist von entscheidender Bedeutung, da sich Malware in Paketen versteckt. Protokolle vermitteln nicht viel von dem, was Sicherheitstools benötigen.
Ähnlich verhält es sich mit IaaS-Anbietern wie AWS CloudWatch und Azure Network Watcher, die zwar die Möglichkeit bieten, bei bestimmten Ereignissen eine Paketerfassung auszulösen, doch dient dies in erster Linie nur der Fehlerbehebung und ist reaktiv. Die Spiegelung von Paketdaten erfordert eine extreme Granularität, die interne und kundenorientierte Anwendungen und Workloads in Entwicklungs-, Test- und Produktionsumgebungen umfasst.
In der Vergangenheit waren Administratoren auch gezwungen, sich ausschließlich auf systemeigene Verkehrsspiegelungsdienste oder aufwendige toolspezifische Agenten zu verlassen, um Rohdatenpakete zu erfassen und direkt an ihre Sicherheits- und Überwachungstools zu senden. Das Ergebnis sind komplexe Netzwerkdesigns, eine übermäßige Inanspruchnahme von Bandbreite und Prozessorleistung, ein Wettstreit der Tools um den Zugriff auf den Datenverkehr, überlastete Tools, die an Effektivität verlieren, und eine überflüssige Skalierung.
Die IT-Abteilung ist dadurch nur begrenzt in der Lage, den Netzwerkverkehr, die Nutzungserfahrung und die Anwendungs-/Flussinformationen zu analysieren. Sie hat Schwierigkeiten, den Zustand der Infrastruktur und der Anwendungen zu bewerten. Anbieter von Observability behaupten, diese Informationen zu liefern, allerdings nicht auf Workload-Ebene und auch nicht mit den erweiterten Metadatenattributen, die notwendig sind, um einige Probleme aufzuzeigen und zu lösen.
Visibilitäts-Tools müssen deshalb Zugang zu allen Netzwerkpaketen und Anwendungsdaten haben, einschließlich Ost-West-Verkehr, zwischen einzelnen VMs auf überwachten Servern und zwischen Container-Pods auf Worker Nodes.
Cloud-Anbieter sorgen für Sicherheit, richtig?
Ja und nein! Anbieter von Cloud-Infrastrukturen schützen die Rechen-, Speicher-, Datenbank- und Netzwerkelemente. Anwendungen, Kundendaten, Identitäts- und Zugriffsmanagement (IAM), Firewalls und mehr müssen Unternehmen selbst sichern. Zu den cloudnativen Sicherheitsdiensten, die üblicherweise in der öffentlichen Cloud eingesetzt werden, gehören IAM, Sicherheitsgruppen, Protokolle und Web Application Firewalls (WAF). Doch diese haben ihre Grenzen:
IAM
Sobald ein Angreifer erfolgreich Anmeldeinformationen gehackt hat, muss er keine auffälligen Aktivitäten durchführen, die von Cloud-Dashboards gemeldet werden; er könnte still dasitzen und gerade genug tun, um keine Warnungen auszulösen. Die Zeit bis zur Entdeckung beträgt in diesem Fall viele Wochen oder Monate.
Sicherheitsgruppen
Obwohl sie nur den Zugang zu den notwendigen Ports öffnen, haben Sicherheitsgruppenkonfigurationen keinen Anwendungskontext und keinen Einblick in höhere Schichten (über L4 hinaus). Angriffe könnten über diese Ports in der Anwendungsschicht erfolgen und zur Verbreitung von Malware oder zur Exfiltration von Daten führen.
Protokolle
Sie wissen, wer mit wem kommuniziert hat, haben aber keine Aufzeichnungen darüber, worum es bei der Kommunikation ging. Es werden keine Pakete oder Nutzdaten erfasst. Bei stillen Angriffen, bei denen Angreifer die Infrastruktur nutzen und versuchen, unterhalb der Grenzen von Schwellenwertverletzungen zu operieren, sind Protokolle nicht hilfreich.
WAF
Cloudnative WAFs sind in ihrer Funktionalität im Vergleich zu im Markt führenden WAFs sehr eingeschränkt und schützen Anwendungen nur vor den zehn häufigsten OWASP-Angriffen. Außerdem sind sie eine Art Blackbox, auf die die SecOps-Teams keinen Zugriff haben.
Auch die cloudnativen Sicherheitstools können eine vollständige Visibilität nicht gewährleisten.
Hybrid Traffic Intelligence wirft das Licht der Wahrheit auf alle Daten in Bewegung
Um einen effektiven Sicherheits- und Netzwerkstandard in der hybriden Cloud sicherzustellen, müssen CloudOps, DevOps und SecOps auf Hybrid Traffic Intelligence setzen. Eine solche Plattform bildet ein intelligentes Netz zwischen Endgeräten, Anwendungen sowie Clouds und erfasst, analysiert, optimiert und verteilt Datenverkehr und -pakete automatisch auf unterschiedliche lokale und cloudbasierte Tools. Durch die Optimierung wird auch der Datenverkehr insgesamt reduziert. Denn unserer Erfahrung nach sind bis zu 40 % der Anwendungsdaten im Netzwerk überflüssig und über 90 % der Log-, Monitoring- und Reporting-Daten.
Bild 1: Beispiel einer hybriden Multi-Cloud-Infrastruktur mit Hybrid Traffic Intelligence. (Quelle: Gigamon)
Insgesamt stellt eine Hybrid-Traffic-Intelligence-Plattform umfassende Sichtbarkeit in den gesamten Cloud-Workload-Verkehr über unterschiedliche Cloud-Anbieter hinweg her. Auch Inter-VPC bzw. Intra-Cloud-Sichtbarkeit wird sichergestellt und es wird NetFlow in der Cloud generiert. Durch Sicherstellung vertraulicher Datenübertragungen, das Erkennen von Anomalien ohne Rohdatenverkehr und eine Verschleierung der Identifizierung interner Ressourcen wird auch die Sicherheit und Compliance gewährleistet. Zudem bietet eine solche Lösung hohe Flexibilität und eine einfache Bereitstellung, da jede Cloud-Migrationsstrategie, mehrere Tools und automatisierte Skalierbarkeit unterstützt werden.
Schlussendlich führt der Einsatz hybrider Traffic-Intelligence durch vereinfachte Datenverkehrserfassung, Unterstützung nativer Verkehrsspiegelungsdienste in großem Umfang und verbesserter Tool-Kapazität zu einer erhöhten Kosteneffizienz.
Ohne Netzwerkvisibilität durch Hybrid Traffic Intelligence kann heute keine angemessene Sicherheit und Performance mehr gewährleistet werden – egal ob On-Premises, virtualisiert, in der Cloud oder in einer hybriden Netzwerkinfrastruktur.
Bild 2: Beispiel einer hybriden Cloud-Infrastruktur mit Hybrid Traffic Intelligence. (Quelle: Gigamon)
