Welche Risiken die Cloud-Sicherheit derzeit gefährden

Durch den Trend zum Multi-Cloud-Modell ist es für Unternehmen immer schwerer, ihre gesamte Datenumgebung zu kontrollieren. Entsprechend dem Shared-Responsibility-Prinzip ist die interne IT-Abteilung verantwortlich für eine sichere Konfiguration der Cloud-Ressourcen und eine sichere Datenübertragung. Dies gilt umso mehr bei kritischen Daten, die strengen Compliance-Regeln unterliegen. Laut einer Veritas-Studie gehen die Befragten in 76 Prozent der Unternehmen jedoch davon aus, dass der Cloud-Betreiber für Compliance und Datenschutz in der Cloud verantwortlich ist. Die gestiegene Komplexität, Nachlässigkeit und Unklarheiten bezüglich der Verantwortung sind mit dafür verantwortlich, dass zum Teil kritische Datensätze in der Cloud unverschlüsselt sind. Kommt dies ans Tageslicht, werden die betroffenen Unternehmen wegen Compliance-Verstößen belangt.

Sergej Epp, der Autor dieses Beitrags, ist Chief Security Officer (CSO) bei Palo Alto Networks in Zentraleuropa. In dieser Funktion verantwortet er die Cybersicherheits-Strategie und den Threat Intelligence Austausch in der Region (Bild: Palo Alto Networks).

Infrastructure-as-Code-Templates im Visier

Wie für andere Sicherheitsaspekte ist der Cloud-Nutzer auch für die sichere Konfiguration von Infrastructure-as-Code-Templates verantwortlich. Unternehmen nutzen Infrastructure-as-Code (IaC) oft im Rahmen von DevOps-Initiativen, um Build-Prozesse zu automatisieren. Werden die dabei eingesetzten IaC-Templates nicht auf Schwachstellen geprüft, ist später die Cloud-Umgebung anfällig für Cyberangriffe. Eine sichere Konfiguration erfordert insbesondere, dass die Verschlüsselung von Daten im Ruhezustand und in Bewegung aktiviert ist, was oft vernachlässigt wird. In einer Multi-Cloud-Umgebung muss eine sichere Konfiguration über mehrere Public-Cloud-Konten gewährleistet sein, was die Sache nicht unbedingt einfacher macht. Für die Überwachung einer ordnungsgemäßen Konfiguration der gesamten Datenumgebung steht in vielen Unternehmen keine geeignete zentrale Plattform zur Verfügung. Somit bleiben kritische Fehlkonfigurationen oft unentdeckt.

Das Risiko, das von unsicher konfigurierten IaC-Templates ausgeht, ist nicht zu unterschätzen. Dies belegt eine aktuelle Studie von Unit 42, der Forschungsabteilung von Palo Alto Networks.

So sind derzeit fast 200.000 unsichere Templates im Umlauf. Viele Templates weisen mittelkritische, aber auch hochkritische Schwachstellen auf. Nur eine Fehlkonfiguration genügt bereits, um Daten in einer Public-Cloud-Instanz zu gefährden. In einer früheren Untersuchung stellte Unit 42 bereits fest, dass 65 Prozent der Cloud-Sicherheitsvorfälle auf Fehlkonfigurationen zurückzuführen sind. Bei 60 Prozent der Cloud-Speicherdienste ist das Storage-Logging, also die Protokollierung der Vorgänge im Speichersystem, deaktiviert. Cyberkriminelle Gruppen wie CloudHopper oder FancyBear könnten somit unbemerkt in das Speichersystem eindringen. Ist die Speicherprotokollierung deaktiviert, ist es bei einem gravierenden Sicherheitsvorfall auch schwieriger zu bestimmen, wie viele Daten abgeschöpft wurden. Bei 43 Prozent der Cloud-Datenbanken ist die Datenverschlüsselung nicht aktiviert, die eigentlich verhindern soll, dass Cyberkriminelle die Daten lesen können. Verschlüsselung ist jedoch eine grundlegende Anforderung gängiger Compliance-Vorgaben und daher unverzichtbar.

Die am häufigsten verwendeten IaC-Templates sind Unit 42 zufolge Google Kubernetes YAML (39 Prozent), HashiCorp Terraform (37 Prozent) und AWS CloudFormation (24 Prozent). Im Rahmen der Studie wiesen 42 Prozent der CloudFormation-Templates, 22 Prozent der Terraform-Templates und 9 Prozent der Kubernetes YAML-Templates unsichere Konfigurationen auf. Je nach IaC-Template kann die Wahrscheinlichkeit einer unsicheren Konfiguration sehr hoch sein.

Zu den gängigen Fehlkonfigurationen zählt, dass die serverseitige Verschlüsselung der Datenspeicherdienste und Protokollierung von Ereignissen bei AWS S3-Buckets deaktiviert ist. Nicht verschlüsselte Amazon RDS-Instanzen kommen auch häufig vor. Bei den von den Cloud-Nutzern konfigurierten AWS EC2-Instanzen kann es sein, dass SSH (Port 22) aus dem Internet zugänglich ist. Ebenfalls problematisch ist es, wenn AWS-Sicherheitsgruppen für sämtlichen eingehenden Datenverkehr offen sind.

Bei unsicheren Kubernetes-Konfigurationen teilt sich der Container das gleiche Netzwerk mit dem Host, wodurch Angreifer die Netzwerktopologie der Cloud-Infrastruktur des Unternehmens leichter ermitteln können. Unsichere Kubernetes-Konfigurationen laufen häufig als Root oder mit privilegierten Konten. Dies erleichtert Angreifern die Durchführung von Container-Escape-Angriffen, wodurch das Host-System für andere potenzielle Bedrohungen geöffnet wird. Unternehmen sollten folglich dafür sorgen, dass Container nicht mit Root- oder privilegierten Konten laufen.

Riskante Nutzung gängiger Protokolle

Unit 42 untersuchte auch Trends im Zusammenhang mit dem riskanten Einsatz der Protokolle SSH (Secure Shell), RDP (Remote Desktop Protocol) und TLS (Transport Layer Security).

76 Prozent der Cloud-Workloads setzen SSH (Port 22) dem gesamten Internet aus, 20 Prozent mehr als im vorherigen Bericht, was eine riskante Praxis ist. Angreifer nehmen SSH-Dienste aktiv ins Visier, da sie den Fernzugriff auf Cloud-Umgebungen ermöglichen. 69 Prozent der Unternehmen machen RDP (Port 3389) über das Internet zugänglich, 30 Prozent mehr als im letzten Bericht. Wenn RDP und SSH öffentlich zugänglich ist, können Angreifer sehr nah an die Cloud-Ressourcen gelangen. 27 Prozent der Unternehmen verwenden veraltete Versionen von Transport Layer Security (TLS), immerhin 34 Prozent weniger als im letzten Bericht. TLS v1.1 wurde 2008 aufgrund der erhöhten Anfälligkeit für Angriffe aufgegeben. Neben der Verletzung von Compliance-Anforderungen wie PCI DSS gefährden Unternehmen auch die Daten ihrer Kunden.

Sicherheitsteams sollten von vertrauensbasierten Zugangsmodellen wie Konten und Passwörtern zu einem Zero-Trust-basierten Ansatz nach dem Prinzip „Niemals vertrauen, immer überprüfen“ wechseln. Zero Trust kann in jeder Cloud-Umgebung implementiert werden anhand der folgenden fünf Schritte:

1. Definieren der Schutzoberfläche
2. Abbildung der Transaktionsströme
3. Aufbau einer Zero-Trust-Architektur
4. Zero-Trust-Richtlinie erstellen
5. Überwachung und Wartung

Cryptojacking macht der Cloud-Infrastruktur zu schaffen

Cryptomining-Operationen, auch „Cryptojacking“ genannt, sind zu einem der am häufigsten mit dem Betrieb in einer Cloud-Umgebung verbundenen Risiken geworden. Während die Nutzung privater Mining-Pools für böswillige Akteure üblich ist, fanden die Forscher von Unit 42 heraus, dass fast 9 Prozent der Cloud-Betreiber Anzeichen für eine Verbindung zu Mining-Operationen über öffentliche Monero (XMR)-Mining-Pools aufweisen und diese wahrscheinlich durchführen.

Öffentliche Mining-Pools sind Systeme oder Netzwerke, die Mining-Operationen koordinieren, verwalten und verteilen. Ferngesteuerte Systeme stellen eine Verbindung zu diesen Pools her, um Mining-Anweisungen zu erhalten und nach Abschluss dieser Operationen einen Anteil an den finanziellen Erträgen zu erhalten.

Die Verbindungen des öffentlichen XMR-Mining-Netzes sind geografisch verteilt. Fast 60 Prozent aller Verbindungen liefen zu XMR-Pools in den USA, 22,56 Prozent in die Niederlande und 14,17 Prozent nach Deutschland. Das Blockieren von Netzwerkverbindungen zu öffentlichen Mining-Pools auf Grundlage von Ländern oder Regionen ist nicht immer zuverlässig. Unternehmen müssen diese Verbindungen daher auf Grundlage verdächtiger Netzwerkverbindungsmuster wie IP-Port-Kombinationen oder, noch besser, unter Verwendung von Layer-7-Paketinspektionssignaturen über virtuelle Next-Generation-Firewalls blockieren.

Zusätzlich zu den öffentlichen Mining-Pools wurden Gruppen wie Rocke, Pacha und die 8220 Mining Group beobachtet, die mit einer Cloud-Infrastruktur arbeiten. Während alle diese wahrscheinlich in China ansässigen cyberkriminellen Gruppen gemeinsame Mining-Operationen ausführen, haben einige begonnen, sich auch außerhalb dieser Art von Aktivitäten zu versuchen.

Best Practices für die Cloud-Sicherheit

Die Studie von Unit 42 sieht die Cloud-Sicherheit gefährdet durch drei Probleme: Schwachstellen in Infrastructure-as-Code, den riskanten Einsatz gängiger Protokolle und externe Bedrohungen der Cloud-Infrastruktur. Durch die konsequente Umsetzung der folgenden Best Practices können Unternehmen diesen Sicherheitsproblemen entgegentreten:

• Die strikte Durchsetzung von Sicherheitsstandards in der Cloud ist unverzichtbar.
• Eine Cloud-native Sicherheitsplattform (CNSP) bietet vollständige Sichtbarkeit von Containern, Serverless-Implementierungen und CI-/CD-Pipelines in der gesamten Cloud-Umgebung, um sich den entscheidenden Vorsprung gegenüber den Angreifern zu verschaffen.
• Generell müssen IaC-Templates aus öffentlichen Repositorys wie GitHub konsequent auf Schwachstellen geprüft werden und erst dann für den Einsatz in der Produktionsumgebung freigegeben werden. Eine aktivierte Protokollierung und Verschlüsselung in allen IaC-Templates bietet ein entscheidendes Maß an zusätzlicher Sicherheit.
• Der „Shift Left“-Sicherheitsansatz bedeutet, die Sicherheit hin zum frühestmöglichen Zeitpunkt im Entwicklungsprozess vorzuziehen, um ein Höchstmaß an Cloud-Sicherheit zu erzielen.

Unternehmen müssen alles daransetzen, um eine Gefährdung ihrer Cloud-Umgebung von vornherein zu verhindern. Die Umsetzung von Best Practices mit Unterstützung einer für die Cloud konzipierten Sicherheitsplattform erweist sich als effektiv, um aktuellen Cloud-Bedrohungen entgegenzutreten.


ANZEIGE
Auf zu neuen Höhen mit SkySQL, der ultimativen MariaDB Cloud
In diesem Webinar stellen wir Ihnen SkySQL vor, erläutern die Architektur und gehen auf die Unterschiede zu anderen Systemen wie Amazon RDS ein. Darüber hinaus erhalten Sie einen Einblick in die Produkt-Roadmap, eine Live-Demo und erfahren, wie Sie SkySQL innerhalb von nur wenigen Minuten in Betrieb nehmen können.
Jetzt registrieren und Aufzeichnung ansehen.