Schlagwort-Archive: Infrastructure as Code

Infrastructure as Code: Sicherheitsrisiken kennen und vermeiden

Originalbeitrag von David Fiser (Cyber Threat Researcher)

Ständig steigende Anforderungen an IT-Infrastrukturen und die Zunahme von Continuous Integration and Continuous Deployment (CI/CD)-Pipelines haben den Bedarf an konsistenter und skalierbarer Automatisierung erhöht. Hier bietet sich Infrastruktur als Code (IaC) an. IaC liefert die Bereitstellung, Konfiguration und Verwaltung der Infrastruktur durch formatierte, maschinenlesbare Dateien. Anstelle der manuellen Einrichtung von Onpremise- und Cloud-Umgebungen können Administratoren und Architekten diese einfach mit IaC automatisieren. IaC arbeitet gut mit Infrastructure as a Service (IaaS) zusammen und besticht durch die schnellere und kostengünstigere Entwicklung und Bereitzustellung von skalierbaren Cloud-Implementierungen.

Das IaC-Konzept weist Ähnlichkeiten mit Programmierskripts auf (die ebenfalls IT-Prozesse automatisieren), doch verwendet IaC eine beschreibende Sprache für die Kodierung von anpassungsfähigeren Bereitstellungen und Implementierungen (d.h. die Software selbst ist für die Einleitung von Infrastrukturänderungen verantwortlich). IaC gilt als besonders wichtig für Cloud Computing und DevOps.

Es gibt zwei Arten von IaC-Werkzeugen: Orchestrierungswerkzeuge dienen der Bereitstellung, Organisation und Verwaltung von Infrastrukturkomponenten (z.B. CloudFormation und Terraform). Konfigurationsmanagement-Tools wiederum ermöglichen die Installation, Aktualisierung und Verwaltung laufender Software in Infrastrukturkomponenten (z. B. Ansible, Chef, Puppet und SaltStack). Diese Tools entheben Entwickler und Cloud-Architekten von manuellen, fehleranfälligen Aufgaben und vereinfachen die Konfiguration und Verwaltung.

Sicherheitsrisikobereiche in IaC-Implementierungen

Zu den Herausforderungen, die IaC mit sich bringt, zählen etwa ungepatchte Schwachstellen in einem IaC-Tool als Eintrittspunkt für Bedrohungen in die Kerninfrastruktur. Schwachstellen könnten es Angreifern ermöglichen, Verfahren zu umgehen, Code auf gehackten Servern auszuführen oder sogar Kryptowährungs-Miner einzusetzen. IaC-Templates mit Fehlkonfigurationen könnten auch sensible Daten offen legen oder Schlupflöcher für Angriffe öffnen.

Speicherung von sensiblen Daten

Das allgemeine IaC-Prinzip sieht vor, dass eine einzige Anwendung mehrere in den Konfigurationsdateien beschriebene Umgebungen verwalten kann, die als Code vorliegen und den Code (auch bösartig) auch innerhalb der Zielumgebungen ausführen. Eine IaC-Anwendung kann verschiedene Ansätze zur Beschreibung der Zielumgebung verwenden; das Gemeinsame ist die Konfiguration selbst, ihre Speicherung und insbesondere die geheimen Informationen, die für die Verbindung mit der verwalteten Infrastruktur erforderlich sind.

Die Speicherung von solchen Informationen ist wichtig, weil es um sensible Daten geht, wie etwa Anwendungs-Token für die Authentifizierung, Secure Shell (SSH)-Schlüssel und Passwörter. Die Speicherung dieser Daten in Storing Source Code Management (SCM)-Systemen (z.B. Git) oder Klartextdateien ist eine gefährliche – und aus Sicherheitssicht unverantwortliche – Praxis, da sie leicht zugänglich gemacht werden können. Beispielsweise könnten Bots, die öffentliche SCM-Sites durchforsten und nach sensiblen Informtionen suchen, diese schnell ausnutzen und die Infrastruktur gefährden (z.B. durch das Ausbringen von Kryptowährungs-Minern). Es empfiehlt sich daher, Vaults für die Speicherung von Geheimnissen zu verwenden und diese in den Konfigurationsdateien zu referenzieren.

Kommunikationskanal des Masters

Einige IaC-Konfigurationsmanagement-Tools (z. B. SaltStack) verwenden eine Master-Node-Architektur, bei der die Knoten von einem Master-Knoten aus verwaltet werden. Beim Zugriff auf eine verwaltete Infrastruktur von einem einzigen Punkt aus (d.h. von einem Master) ist es im Allgemeinen entscheidend, diesen einzelnen Punkt zu sichern, da er die gesamten Infrastruktur- oder Einsatzspezifikationen enthält und die Kompromittierung der Sicherheit die gesamte Infrastruktur gefährden würde.

Die Verwendung entsprechend vorbereiteter Umgebungen innerhalb der Cloud reduziert das Risiko von Kompromittierungen durch Fehlkonfigurationen und das Risiko, Infrastrukturen von Grund auf neu zu konfigurieren.

Bild 1. Ein Überblick über eine Master-Node-Architektur

Der Master muss über einen sicheren Kommunikationskanal verfügen, um mit den Knoten zu kommunizieren und sie steuern zu können. Es gibt zwei verschiedene Ansätze für das Management:

  • Installation eines benutzerdefinierten Agenten für das Management des Knotens, der bestimmte Aufgaben ausführt,
  • Einsatz allgemein verfügbarer Software und Kommunikationsprotokolle für das Management von Knoten (auch als „agentenlos“ bekannt), so etwa Bash-Skriptausführung via SSH-Protokoll.

Vom Standpunkt der Sicherheit stellt die Verwendung eines benutzerdefinierten Netzwerkprotokolls eine weitere Angriffsfläche dar. Möglicherweise rücken sogar mögliche Schwachstellen in den Vordergrund, wie im Fall von CVE-2020-11651 und CVE-2020-11652, Schwachstellen im Salt-Management-Framework von SaltStack, das in Rechenzentren und Cloud-Servern eingesetzt wird.

Bei Missbrauch von CVE-2020-11651 könnte ein nicht authentifizierter Nutzer aus der Ferne Code in der ganzen Infrastruktur ausführen. Die Path Traversal Vulnerability CVE-2020-11652 wiederum ermöglicht es Dritten, beliebige Dateien zu lesen. In beiden Fällen können Böswillige sich den Root-Schlüssel verschaffen und Zugang zum Master erlangen und damit zur gesamten Infrastruktur. Einzelheiten dazu liefert auch ein Trend Micro-Forschungsbeitrag.

Benutzerprivilegien

Benutzerprivilegien sind ein weiterer sicherheitsrelevanter Aspekt. Wird eine IaC-Anwendung zur Verwaltung der Anwendungsbereitstellung genutzt, ist es unwahrscheinlich, dass dafür Root-Rechte auf dem Zielrechner erforderlich sind. Das Prinzip der geringsten Privilegien sollte hier das Risiko einer Kompromittierung mindern.

Dasselbe Prinzip gilt auch für den Einsatz innerhalb öffentlicher Clouds wie Amazon Web Services (AWS). Wird ein Account oder eine Rolle nur für einen bestimmten Zweck zugewiesen (z.B. das Erstellen virtueller Maschinen), sollte diese mit eingeschränkten Fähigkeiten verwendet werden. Die Weitergabe von Zugangsdaten von Cloud-Providern mit Administrator-Zugriff für weniger privilegierte Aufgaben ist eine unsichere Praxis.

IaC-Templates

IaC-Templates sind für die agile Bereitstellung über Provisioning und die Verwaltung der Cloud-Infrastruktur wichtig. Es sind maschinenlesbare Definitionsdateien, mit deren Hilfe die Umgebungen aufgebaut werden, in denen Code aus externen Quellen bereitgestellt und ausgeführt wird. Sie sind jedoch nicht ohne Risiken. Diese Templates sind Teil von IaC-Prozessen und könnten unbeabsichtigt Betriebssystem- oder Container-Images aus nicht vertrauenswürdigen Quellen verwenden, die dann Bedrohungen wie Backdoors und Kryptowährungs-Miner Tür und Tor öffnen.

IaC-Vorlagen beinhalten möglicherweise auch Schwachstellen und unsichere Standardkonfigurationen, die zu einer Gefährdung von Daten führen. Betreiber sollten deshalb IaC-Vorlagen zu Beginn des Entwicklungsprozesses zunächst auf unsichere Konfigurationen und andere potenzielle Schwachstellen überprüfen. Regelmässiges Scannen mit Hilfe eines Cloud Security Posture Management Service hilft ebenfalls, Fehlkonfigurationen zu erkennen und zu beheben.

Lehren ziehen, Best Practices anwenden

IaC gehört zu den wichtigsten DevOps-Praktiken für die agile Softwareentwicklung. Mit IaC wird die Infrastruktur innerhalb von Textdateien (Code) definiert. Fehlkonfigurationen stellen eines der grössten Sicherheitsprobleme in Cloud-Umgebungen dar.

Die folgenden Empfehlungen helfen beim Absichern von hybriden und öffentlichen Cloud-Umgebungen:

  • Durchsetzen des Prinzips der geringsten Privilegien. Account-Privilegien in Cloud-Services sollten eingeschränkt werden, vor allem wenn sie an öffentliche Cloud-Provider gebunden sind. Die Berechtigungen und der Zugang zu Tools sollten eingeschränkt werden, um zu verhindern, dass Angreifer in den Knoten Fuss fassen können. Auf diese Weise werden IaC-Konfigurationen sicher gespeichert und Datenverluste verhindert.
  • Einsatz von IaC Sicherheits-Plugins. Diese Plugins in integrierten Entwicklungsumgebungen können mögliche Probleme in IaC-Templates vor der Installation verhindern.
  • Update der Infrastruktursoftware auf die neueste Version. Sicherheits-Patches sollten immer sofort aufgespielt werden.
  • Nie ein zentrales System exponieren. Zentrale Server sollten nie im Internet exponiert sein, um so zu verhindern, dass eine mögliche Kompromittierung auf weitere Komponenten übergeht.
  • Haltung zur Sicherheit und Compliance verbessern.  Um den Schutz in der Pipeline zu gewährleisten, sollte Echtzeit-Sicherheit, die Fehlkonfigurationen bei Anbietern von Cloud-Diensten erkennt, eingesetzt werden. Lösungen, die über eine automatische Korrekturfunktion verfügen, können auch bei der Behebung von Ausfällen helfen.

Weitere Empfehlungen zur Sicherheit der IAC-Pipeline gibt es hier.

Cloud Sicherheitslösungen von Trend Micro

Trend Micros Lösung Hybrid Cloud Security unterstützt die DevOps Pipeline mit mehreren XGen Threat Defense-Techniken und kann physische, virtuelle und Cloud-Workloads zur Laufzeit schützen. Trend Micro™ Cloud One™ – Conformity ist ein Cloud Security and Compliance Posture Management Service, der automatisierte Sicherheits- und Compliance-Überprüfungen bietet, sowie Übersicht und einfaches Reporting.

Für Unternehmen, die Sicherheit als Software für Runtime-Workloads, Container-Images sowie Datei- und Objektspeicher suchen, können Deep Security™ und Deep Security Smart Check Workloads und Container-Images in jedem beliebigen Intervall in der Entwicklungs-Pipeline auf Malware und Schwachstellen überprüfen.

Weitere Informationen finden Interessierte im Originalbeitrag.