Cloud-Security
Risikoquelle IaC-Templates
Infrastructure as Code (IaC) bietet Unternehmen Vorteile beim Aufbau einer Cloudumgebung. Die Möglichkeiten zur Umsetzung von Sicherheitsstandards bleiben häufig aber ungenutzt: Viele IaC-Templates weisen unsichere Konfigurationen auf.
Laut 2020 Thales Data Threat Report liegt bereits die Hälfte aller Daten in Cloudumgebungen. Fast die Hälfte (48 Prozent) davon ist als sensibel eingestuft. Der Trend zur Multi-Cloud-Nutzung und das zunehmende Datenvolumen in der Cloud machen die Datensicherheit nicht gerade einfacher. Komplexität stellt für 40 Prozent der Befragten die größte Hürde bei der Umsetzung von Datensicherheit dar. Alle Umfrageteilnehmer bestätigten, dass ein Teil ihrer sensiblen Daten in der Cloud nicht verschlüsselt ist. So musste im letzten Jahr fast die Hälfte (47 Prozent) der Unternehmen einen Compliance-Verstoß melden oder konnte die Anforderungen eines Audits nicht erfüllen.
Das Thema Cloudsicherheit erfordert einen genaueren Blick hinter die Kulissen. In den letzten zwei Jahren hat sich die Art und Weise, wie Unternehmen ihre Cloud-Infrastruktur aufbauen, radikal gewandelt: Unternehmen setzen vermehrt auf Infrastructure as Code (IaC), um Build-Prozesse in der Cloud zu automatisieren. IaC ist vielerorts das Mittel der Wahl, weil es den Aufbau einer unveränderlichen Infrastruktur ermöglicht. Dies bedeutet, die Fähigkeit, viele Teile der Cloudinfrastruktur zu standardisieren und einzufrieren, sodass die Ergebnisse bei jeder erneuten Ausführung des Codes konsistent und vorhersehbar sind.
Unternehmen, die auf IaC umsteigen, vermeiden die manuelle Erstellung und Konfiguration der Infrastruktur zugunsten des Schreibens von Code. Obwohl IaC nicht ganz neu ist, setzen es viele Unternehmen derzeit zum ersten Mal ein, was neue Risiken mit sich bringt. Unit 42, die Forschungsabteilung von Palo Alto Networks, hat die Rolle von IaC-Templates als Risikoquelle für die Cloudsicherheit näher untersucht. Die Studie zeigt, dass IaC zwar eine Möglichkeit zur Durchsetzung von Sicherheitsstandards bietet, diese durchaus effektive Fähigkeit jedoch weitgehend ungenutzt bleibt.
Die meisten IaC-Templates entstehen in einem einfachen dreistufigen Prozess: Entwurf, Code und Bereitstellung. Was die DevOps-Teams in Schwierigkeiten bringt, ist die fehlende Sicherheitsüberprüfung. Genau wie der Anwendungscode sind IaC-Templates bei jeder Erstellung oder Aktualisierung auf Sicherheitsprobleme zu scannen. Die Untersuchung zeigt jedoch, dass dies nicht geschieht.
Die IaC-Fehlkonfigurationen gehen auf den Cloudnutzer zurück, nicht den Cloudbetreiber. Im Rahmen des Shared-Responsibility-Modells obliegt die IaC-Template-Konfiguration vollständig dem Cloudnutzer. Die Herausforderung für Unternehmen besteht darin, dafür zu sorgen, dass die sicheren IaC-Konfigurationen über mehrere Public-Cloud-Konten, verschiedene Betreiber und Software-Entwicklungspipelines hinweg konsistent Anwendung finden.
Wie es um die Sicherheit der IaC-Tem- plates steht, zeigt die Studie: Fast 200.000 unsichere Templates sind aktuell in Gebrauch. Die Untersuchung brachte eine erstaunlich hohe Anzahl von Templates mit hoch kritischen sowie mittelschweren Schwachstellen ans Tageslicht. Eine solche Fehlkonfiguration reicht bereits aus, um eine ganze Cloudumgebung zu gefährden. Wie bei einem nicht abgesperrten Auto oder Haus kann ein Angreifer diese Fehlkonfigurationen nutzen, um sich Zugang zu verschaffen.
Diese hohe Zahl erklärt, warum Unit 42 in einem früheren Bericht festgestellt hat, dass 65 Prozent der Cloud-Sicherheitsvorfälle auf Fehlkonfigurationen zurückzuführen sind: Ohne sichere IaC-Templates von Anfang an sind Cloudumgebungen anfällig für einen Angriff.
43 Prozent der Cloud-Datenbanken sind nicht verschlüsselt. Die Verschlüsselung der Daten verhindert, dass Angreifer die gespeicherten Informationen lesen können, und die Verschlüsselung von Daten ist auch eine Anforderung vieler Compliance-Standards, darunter PCI-DSS und HIPAA. Die jüngsten Angriffe gegen Vistaprint und MoviePass unterstreichen die Bedeutung verschlüsselter Datenbanken.
Bei 60 Prozent der Cloud-Speicherdienste ist die Protokollierung deaktiviert. Ein Unternehmen würde es niemals dulden, dass mehr als die Hälfte seiner Lagerhäuser den Zutritt nicht protokolliert. Ebenso würde es nicht auf Sicherheitskameras an den Türen verzichten, weil es unmöglich wäre zu verfolgen, wer hineingeht. Wenn das Storage-Logging deaktiviert ist, könnten böswillige Akteure wie CloudHopper oder FancyBear in das Speichersystem eindringen, und niemand würde es je erfahren. Speicherprotokollierung ist zudem von entscheidender Bedeutung, wenn man versucht, das Ausmaß des Schadens bei cloudbasierten Datenlecks zu bestimmen.
Die am häufigsten verwendeten IaC-Templates sind Google Kubernetes YAML (39 Prozent), HashiCorp Terraform (37 Prozent) und AWS CloudFormation (24 Prozent). Unsicher waren laut der Studie 42 Prozent der CloudFormation-Templates, 22 Prozent der Terraform-Templates und neun Prozent der Kubernetes YAML-Templates. Die Mängelliste ist lang: 42 Prozent der CloudFormation-Konfigurationsdateien enthielten mindestens eine unsichere Konfiguration. Bei 48 Prozent der AWS- S3-Buckets war keine Server-seitige Verschlüsselung der Datenspeicherdienste aktiviert, bei 41 Prozent der Amazon-RDS-Instanzen (Relational Database Service) ebenfalls nicht. Bei 55 Prozent der vom Cloudnutzer konfigurierten S3-Buckets war die Protokollierung von Ereignissen in der Cloudumgebungen nicht aktiviert.
22 Prozent der Terraform-Konfigurationsdateien enthielten mindestens eine unsichere Konfiguration. Unter den AWS-Nutzerkonfigurationen war bei 66 Prozent der S3-Buckets die Protokollierung nicht aktiviert, bei 26 Prozent der EC2-Instanzen war SSH (Port 22) dem Internet ausgesetzt, 17 Prozent der AWS-Sicherheitsgruppen ließen sämtlichen eingehenden Datenverkehr zu.
Bei den „Google Kubernetes YAML“-Dateien enthielten nur neun Prozent mindestens eine unsichere Konfiguration. Bei 32 Prozent der unsicheren Kubernetes-Konfigurationen teilte der Container das Netzwerk des Hosts, 26 Prozent liefen als Root oder mit privilegierten Konten. Wenn ein Container das gleiche Netzwerk wie der Host nutzt, können Angreifer die Netzwerktopologie der Cloudinfrastruktur des Unternehmens leichter ermitteln.
Konfigurationen, die Container als Root erlauben, bieten Angreifern die Möglichkeit, praktisch jeden Aspekt dieses Containers zu erobern. Dies erleichtert auch die Durchführung von Container-Escape-Angriffen, die das Host-System für andere Bedrohungen öffnen. Sicherheits- und
DevOps-Teams sollten deshalb sicherstellen, dass Container nicht mit Root-Rechten oder privilegierten Konten laufen.
Da fast die Hälfte der gescannten CloudFormation-Templates (CFTs) eine potenziell riskante Konfiguration aufweist, ist die Wahrscheinlichkeit hoch, dass ein anfälliges Cloud-Template Verwendung findet. Generell legen die Ergebnisse der Studie den Schluss nahe, dass ein Unternehmen jedes IaC-Template, das aus einem öffentlichen Repository wie zum Beispiel GitHub stammt, als Teil der CI/CD-Pipeline gründlich auf Schwachstellen überprüfen muss. Erst dann sollte es mit dem Template ein System erstellen und dieses in einer Produktionsumgebung einsetzen.
Grundlegende Sicherheitsfunktionen wie Protokollierung und Verschlüsselung sollten in jedem Template aktiviert sein. Ebenso gilt es sicherzustellen, dass jeder Service vor der Verwendung der Templates genehmigt ist. Zusätzlich sind die Protokollierungs- und Verschlüsselungsfunktionen der Cloudbetreiber bei der Überwachung und beim Schutz der Cloudinfrastruktur überaus hilfreich.
Cloudnative Technik ermöglicht es Unternehmen, skalierbare Anwendungen dynamisch über IaC-Templates zu erstellen und auszuführen. Wenn ein Unternehmen die IaC-Templates nicht in seine Cloud-Sicherheitsstrategie mit einbezieht, gefährdet dies die Sicherheit sensibler Daten erheblich. Deshalb die Umsetzung effektiver Best Practices dringend anzuraten.
Sergej Epp ist CSO für Zentraleuropa bei Palo Alto Networks, www.paloaltonetworks.com.
Lesen Sie mehr zum Thema
