Aus der Wolke an den Wettbewerb : Mangelnde Cloud-Sicherheit ist wichtiger Angriffspunkt für Wirtschaftsspionage

Von Sergej Epp, Frankfurt/Main

Wirtschafts- und Industriespionage spielen sich längst nicht mehr nachts an verlassenen Orten ab, wo Aktenkoffer diskret den Besitzer wechseln. Versierte Angreifer operieren heute technisch hochgerüstet und oft im Auftrag von einschlägigen staatlichen Auftraggebern, die fremdes Know-how abgreifen wollen. Das Bayerische Landesamt für Verfassungsschutz weist dabei darauf hin, dass fast jedes Unternehmen Ziel von Spionage sein kann, unabhängig von der Größe – entscheidend sei, ob wertvolles Know-how vorhanden ist. Deutsche Unternehmen, die in kritischen Ländern geschäftlich tätig sind, seien in besonderer Weise diesem Risiko ausgesetzt. Die Behörde empfiehlt daher, Know-how-Schutz als Teil der Unternehmenskultur zu etablieren.

Unser durchdigitalisierter Geschäftsalltag eröffnet Cyberspionen verschiedenste Möglichkeiten, sich Zugang zu sensiblen Daten zu verschaffen. Neben der aktuell vor allem durch Covid-19 stark zunehmenden Nutzung von Videokonferenzen über das Internet und dem Trend private Geräte für Geschäftszwecke einzusetzen (Bring Your Own Devices – BYOD) nehmen Datenräuber mittlerweile vor allem die Cloud ins Visier: Deren sicherheitstechnisch anfälliges Gerüst aus dezentralisiertem Management und Benutzerkonten mit privilegiertem Zugriff erhöht das Risiko für kompromittierte Public-Cloud-Konten.

Beim Sicherheitsmanagement von Cloud-Ressourcen kommt es daher auf die richtige Konfiguration an, woran es aber häufig bereits scheitert – privilegierter Zugriff auf Cloudkonten klingt sicher, ist es aber oft nicht. Aufgrund dynamischer Umgebungen in der Cloud müssen Unternehmen kontinuierlich überwachen, welche Zugriffsprivilegien konfiguriert sind und wie diese genutzt werden. Andernfalls gibt es wenig Chancen, um ein kompromittiertes privilegiertes Konto und damit den möglichen Abfluss von Daten zu erkennen. Und dabei darf man nicht vergessen: Ressourcen in der Cloud verändern sich durch DevOps schnell – sehr schnell! (siehe auch www.kes.info/archiv/leseproben/2014/devops/)

Dazu herrscht weiterhin häufig ein mangelhaftes Sicherheitsverständnis, denn viele Unternehmen sehen den Cloud-Provider in der Pflicht für die Einhaltung von Datenschutz und Compliance. Im Rahmen des Shared-Responsibility-Modells ist jedoch der Cloud-Kunde für Compliance, Datenschutz und Datensicherheit verantwortlich! So wie es zum Beispiel auch Amazon für seine Webservices (AWS) klarstellt, verantwortet der Cloud-Provider die „Sicherheit der Cloud“ und der Kunde die „Sicherheit in der Cloud“.

Infrastructure as Code (IaC)

Unternehmen setzen heute vermehrt auf den DevOps-Ansatz und „Infrastructure as Code“ (IaC, vgl. Kasten auf S. 12), um Build-Prozesse in der Cloud zu verkürzen. Hierbei kommt es auf die sichere Konfiguration der IaC-Templates an. Die Forschungsabteilung von Palo Alto Networks Unit 42 hat unlängst untersucht, wie es um die Sicherheitskonfiguration von IaC-Templates steht – mit ernüchterndem Ergebnis:

• Derzeit sind knapp 200 000 unsichere Templates im Umlauf. Es gibt einen hohen Anteil von IaC-Templates, die hoch- und mittelkritische Sicherheitslücken aufweisen, wobei bereits eine einzige solche Fehlkonfiguration größere Cloud-Ressourcen gefährden kann, wenn sich Datenspione darüber Zugang verschaffen. Zudem hat Palo Alto schon in einer früheren Studie gewarnt, dass 65 % der Cloud-Sicherheitsvorfälle auf Fehlkonfigurationen zurückgehen.
• Fast zwei Drittel (60 %) der Cloud-Speicherdienste weisen eine deaktivierte Protokollierung auf. Dabei besteht die Gefahr, dass böswillige Akteure wie „CloudHopper“ oder „FancyBear“ unbemerkt in das Speichersystem eindringen. Das Storage-Logging ist auch entscheidend, um im Ernstfall das Ausmaß von Cloud-Leaks zu erfassen.
• Bei fast der Hälfte (43 %) der Cloud-Datenbanken ist die Verschlüsselung nicht aktiviert. Datenverschlüsselung ist aber eine grundlegende Anforderung gängiger Compliance-Standards und kann verhindern, dass Spione gespeicherte Daten lesen können. Dazu muss die Verschlüsselung in der Sicherheitskonfiguration des Cloud-Diensts jedoch auch aktiviert sein.

Infrastructure as Code (IaC): Viele Vorteile, aber auch Risiken

Softwareentwicklung erfolgte traditionell vor Ort in den eigenen Entwicklungsumgebungen der Unternehmen. Virtualisierung und native Cloud-Entwicklung haben die Verwaltung physischer Hardware überflüssig gemacht und ermöglichen es Entwicklern nun, eigene virtuelle Server oder Container nach Bedarf in der Cloud bereitzustellen. Der Aufbau einer Entwicklungsumgebung in der Cloud erforderte jedoch zunächst aufwendige Vorarbeit, bevor die eigentliche Programmierung beginnen konnte – zudem gab es keine einfache Möglichkeit, um Änderungen der Umgebung zu verfolgen und Inkonsistenzen zu verhindern, die sich auf die spätere Bereitstellung auswirken würden.

Der Infrastructure-as-Code-Ansatz (IaC) ermöglicht heute, die Bereitstellung von IT-Infrastruktur zu automatisieren: Statt einer manuellen Erstellung und Konfiguration können Entwickler diese Prozesse durch das Schreiben von Code steuern.

Um eine Applikation zu entwickeln, zu testen und in den produktiven Betrieb zu bringen, ist es also nicht mehr erforderlich, sämtliche Komponenten manuell bereitzustellen. Hierzu zählen unter anderem Netzwerke, virtuelle Maschinen, Load-Balancer, Middleware und Datenbankanbindungen. IaC ermöglicht die Verwaltung der Infrastruktur in einem deskriptiven Modell unter Verwendung derselben Versionierung, die ein DevOps-Team auch für seinen Quellcode verwendet: So wie der Quellcode eine Binärdatei erzeugt, bildet ein IaC-Modell für jede Anwendung die gewünschte Umgebung ab.

IaC ist ein wesentliches Element von DevOps und kommt auch in Verbindung mit Continuous Integration/Delivery (CI/CD) zum Einsatz. DevOps-Teams können mittels IaC eine Infrastruktur schnell erstellen und – analog zum Quellcode – versionieren, um Inkonsistenzen zwischen IT-Umgebungen zu vermeiden, die zu ernsthaften Problemen bei der Bereitstellung führen können.

Ohne IaC müssten Entwickler die Einstellungen der einzelnen Einsatzumgebungen beibehalten. Mit der Zeit wäre sonst jede Umgebung eine individuelle Konfiguration, die sich nicht mehr automatisch reproduzieren ließe. Für die Verwaltung und Wartung der Infrastruktur wären manuelle Prozesse erforderlich, die schwer zu verfolgen sind und zu Fehlern und Inkonsistenzen beitragen.

Demgegenüber nehmen Teams mit IaC alle Änderungen an einem versionierten Konfigurationsmodell vor, das in der Regel in gut dokumentierten Codeformaten wie JSON vorliegt. Die Release-Pipeline führt das Modell aus, um Zielumgebungen zu konfigurieren – wenn Entwickler Änderungen vornehmen müssen, bearbeiten sie nun den Quellcode, nicht die Zielumgebung.

IaC ermöglicht es DevOps-Teams so, Anwendungen in produktionsähnlichen Umgebungen zu einem frühen Zeitpunkt des Entwicklungszyklus zu testen. Hierfür lassen sich mehrere Testumgebungen zuverlässig und nach Bedarf bereitstellen. Die als Code dargestellte Infrastruktur lässt sich validieren und testen, um häufige Bereitstellungsprobleme zu vermeiden. Ebenso lassen sich in der Cloud Entwicklungsumgebungen auf IaC-Basis bereitstellen und wieder stilllegen. Dies reduziert die Zeit, den Aufwand und die Fachkenntnisse, die für die Bereitstellung und Skalierung der Infrastruktur erforderlich sind – und ermöglicht Unternehmen, von der verbrauchsabhängigen Kostenstruktur der Cloud zu profitieren.

Insgesamt bietet IaC den Vorteil, stabile Umgebungen schnell und skalierbar bereitzustellen zu können. Die aufwändige manuelle Konfiguration entfällt; Entwickler können den gewünschten Zustand ihrer Umgebungen per Code darstellen, was zur Konsistenz beiträgt. Sie müssen damit weniger Zeit für Anpassungsarbeiten aufwenden und gewinnen mehr Zeit für die Entwicklung innovativer, geschäftskritischer Softwarelösungen.

IaC-Implementierungen sind wiederholbar und verhindern Laufzeitprobleme, die durch Konfigurationsdiskrepanzen oder fehlerhafte Abhängigkeiten verursacht werden. DevOps-Teams können mit einem einheitlichen Satz von Prozessen und Tools zusammenarbeiten, um Anwendungen zu entwickeln, die auf der zugrunde liegenden Infrastruktur innerhalb kurzer Zeit betriebsbereit und problemlos skalierbar ist.

Bei all diesen Vorteilen darf man aber auch die mit diesem Vorgehen verbundenen Sicherheitsrisiken nicht außer Acht lassen. Entfällt etwa die Überprüfung der hierfür genutzten IaC-Templates auf Schwachstellen, kann die Cloud-Umgebung gefährdet sein. Möglicherweise sind Cloud-Überwachungsfunktionen oder die ordnungsgemäße Verschlüsselung von Daten im Ruhezustand und in Bewegung fälschlicherweise deaktiviert. Um eine Gefährdung kritischer Daten zu vermeiden, müssen Unternehmen für sichere IaC-Konfigurationen über mehrere Public-Cloud-Konten, verschiedene Betreiber und Software-Entwicklungspipelines hinweg sorgen.

Die gängigsten IaC-Templates sind häufig unsicher

Von allen untersuchten Templates waren 39 % Google Kubernetes YAML Templates, 37 % HashiCorp Terraform Templates und 24 % AWS CloudFormation Templates. Die Rechnung, dass bekannte Software weniger Schwachstellen enthält, geht bei den IaC-Templates leider nicht auf:

• Erschreckende 42 % aller CloudFormation-Konfigurationsdateien wiesen mindestens eine unsichere Konfiguration auf: So war zum Beispiel bei 48 % der AWS-S3-Buckets die serverseitige Verschlüsselung der Datenspeicherdienste nicht aktiviert – 41 % der Amazon RDS-Instanzen (Relational Database Service) waren ebenfalls nicht verschlüsselt. Bei 55 % der S3-Buckets war die Protokollierung von Ereignissen innerhalb von Cloud-Umgebungen nicht aktiviert.
• 22 % der Terraform-Konfigurationsdateien enthielten mindestens eine unsichere Konfiguration: Bei 66 % der von den Cloud-Nutzern konfigurierten S3-Buckets war die Protokollierung nicht aktiviert. Bei 26 % der von Cloud-Nutzern konfigurierten AWS-EC2-Instanzen war SSH (Port 22) dem Internet ausgesetzt – und 17 % der von Cloud-Nutzern konfigurierten AWS-Sicherheitsgruppen ließen sämtlichen eingehenden Datenverkehr zu.
• Von den Google-Kubernetes-YAML-Dateien enthielten immerhin nur 9 % mindestens eine unsichere Konfiguration: Bei 32 % der unsicheren Kubernetes-Konfigurationen teilte der Container das Netzwerk des Hosts – 26 % liefen als Root oder mit privilegierten Konten. Wenn ein Container das gleiche Netzwerk wie der Host nutzt, können Angreifer jedoch die Netzwerktopologie der Cloud-Infrastruktur des Unternehmens leichter ermitteln. Und Konfigurationen, die Container als Root erlauben, erleichtern Angreifern zum Beispiel die Durchführung von Container-Escape-Attacken, wodurch das Host-System für andere potenzielle Bedrohungen geöffnet wird. Container sollten daher nicht mit Root- oder privilegierten Konten laufen.

Generell legen die Ergebnisse der Studie den Schluss nahe, dass jedes IaC-Template, das aus einem öffentlichen Repository wie GitHub stammt, als Teil der Continuous-Integration-(CI)-/Continuous-Delivery-(CD)-Pipeline gründlich auf Schwachstellen zu überprüfen ist. Erst dann ist das Template einsatzbereit, um eine Infrastruktur zu erstellen, die eine Produktionsumgebung sicher nutzen kann. Protokollierung und Verschlüsselung sind dabei unverzichtbar und sollten in jedem Template aktiviert sein.

Riskanter Einsatz gängiger Protokolle

Die gleiche Unit42-Analyse hat zudem die Risiken in Zusammenhang mit dem Einsatz der gängigen SecureShell-(SSH) und Remote-Desktop-Protokolle (RDP) sowie der Transport-Layer-Security (TLS) näher untersucht:

• Bei 76 % der betrachteten Cloud-Workloads war SSH (Port 22) gefährdet: Angreifer nehmen SSH-Dienste aktiv ins Visier, um Fernzugriff auf Cloud-Umgebungen zu erlangen. Unternehmen dürfen bei der ganzen Automatisierung nicht vergessen, SSH-Dienste richtig zu konfigurieren und bei möglichen Sicherheitslücken schnellstmöglich zu patchen.
• Bei 69 % der Unternehmen ist RDP (Port 3389) gefährdet, das ebenfalls sicherheitskritisch ist: Wo RDP oder SSH öffentlich zugänglich sind, können Angreifer „an die Haustür klopfen“, ohne dass Unternehmen wissen, dass es diese Haustür überhaupt gibt. Es ist dringend zu empfehlen, RDP nicht direkt dem öffentlichen Internet auszusetzen und stattdessen cloudnative Alternativen zu nutzen (z. B. Azure Bastion).
• Bei 27 % der Unternehmen sind veraltete TLS-Versionen im Einsatz: TLS v1.1 wurde schon 2008 aufgrund seiner erhöhten Anfälligkeit für Angriffe aufgegeben. Kommt eine veraltete TLS-Version nach wie vor zum Einsatz, gefährdet dies die Daten durch die Möglichkeit von Man-in-the-Middle-Angriffen. Im Falle von kompromittierten Kundendaten können gravierende Compliance-Verstöße die Folge sein.

Sowohl für SSH als auch für RDP ist ein Zero-Trust-Modell der empfehlenswerte Sicherheitsansatz für Cloud-Ressourcen: Der Zugriff auf Cloud-Ressourcen erfolgt dann nach dem Prinzip „Vertrauen ist gut, Kontrolle ist besser“. Zur Umsetzung von Zero-Trust gilt es zunächst, den zu schützenden Bereich sowie Sicherheitskontrollen festzulegen und die Transaktionsströme im Rahmen einer Whitelist abzubilden. Nach dem Aufbau der Zero-Trust-Architektur und der Definition einer Zero-Trust-Richtlinie erfolgt die Überwachung der Umgebung.

Best Practices für Cloud-Sicherheit

Der beste Schutz vor unbefugtem Zugriff auf Cloud-Ressourcen ist die konsequente Umsetzung von Best Practices: Zuallererst gilt: Was nicht sichtbar ist, lässt sich nicht schützen! An dieser Stelle kommen häufig spezialisierte Cloud-Sicherheitsplattformen zum Einsatz, weil übliche SIEM- oder Monitoring-Systeme mit der Dynamik und der Komplexität der Logformate aus Public-Clouds oft schlicht überfordert sind. Dabei gilt es einen Überblick zu sämtlichen Containern, Serverless-Implementierungen und CI-/CD-Pipelines in öffentlichen, privaten und hybriden Clouds gesamtheitlich herzustellen, damit man die Dynamik der Ressourcen nachvollziehen kann. Konsequente Cloud-Sicherheit erfordert zudem die strikte Durchsetzung von Standards in Public-, Private-, Hybrid- und Multi-Cloud-Umgebungen – eine grundlegende Orientierungshilfe liefert dafür die Broschüre „Sichere Nutzung von Cloud-Diensten“ des BSI (www.bsi.bund.de/DE/Themen/DigitaleGesellschaft/CloudComputing/Sichere_Nutzung_Cloud/Sichere_Nutzung_Cloud_node.html).

Die Sicherheitsüberprüfung von IaC-Templates ist ebenfalls Teil der Best Practices: Unternehmen sollten mittels eines IaC-Scan-Tools die Qualität ihrer IaC-Templates vor dem Einsatz in der Cloud und auch im produktiven Geschäftsbetrieb testen.

Alle diese Kontrollen greifen aber nur, wenn man seinen Sicherheitsansatz nach dem „Shift-Left“-Prinzip aufstellt, also die Cloud-Sicherheit möglichst früh im Entwicklungslebenszyklus einbindet. Im Vergleich zur heute üblichen Praxis beginnen Sicherheitsmaßnahmen dabei viel „weiter links“ auf der Zeitachse – und zwar so früh wie möglich, am besten bereits in der Anforderungs- und Entwicklungsumgebung und nicht erst dann, wenn die Applikation in die Produktion geht.

Fazit

Obwohl Public-Clouds für Unternehmen eine Chance bieten, um ihre Cybersicherheit zu verbessern, sehen sich diese zunehmend auch mit spezifischen Bedrohungen in der Cloud konfrontiert. Teils öffnen gravierende Schwachstellen in der Konfiguration von Cloud-Umgebungen Tür und Tor für Angreifer – und damit oft auch für Wirtschaftsspionage. Solche Sicherheitslücken sind die Folge von mangelnden Sicherheits-Kenntnissen, unzureichendem Sicherheits-Bewusstsein und riskanten Nachlässigkeiten.

Ebenso zielstrebig, wie Angreifer nach Lücken suchen, um fremde Cloud-Ressourcen anzuzapfen, müssen Unternehmen vorgehen, um diese Lücken in ihren Systemen zu schließen. Dies erweist sich mit klassischen Strategien und Mitteln oft als große Herausforderung. Von DevSecOps über „Shift Left“ bis „Zero Trust“ gibt es aber durchaus effektive neuere Ansätze, um Daten-Spionen das Handwerk zu legen.

Sergej Epp ist CSO Central Europe bei Palo Alto Networks.