Wie sichern wir Infrastructure-as-Code-Tools ab?

Wie der Name schon sagt, ist Infrastructure as Code (IaC) die Praxis, die Infrastruktur, auf der Ihre Anwendungen ausgeführt werden, in Code und Konfigurationsdateien zu definieren. So können wir nicht nur die Bereitstellung von Ressourcen automatisieren, sondern auch dieselben Lebenszyklusprozesse darauf anwenden, die bisher nur für den Anwendungscode galten. Wenn Sie IaC noch nicht kennen, lesen Sie diesen Artikel. Darin erfahren Sie, was Infrastructure as Code (IaC) genau ist und welche Auswirkungen der Einsatz von IaC in der Praxis auf die Sicherheit hat.

Für die Implementierung von IaC gibt es zahlreiche Tools zur Infrastrukturautomatisierung. Viele davon stammen von Public-Cloud-Anbietern wie CloudFormation von Amazon Web Services und Resource Manager (ARM) von Azure. Daneben gibt es Projekte, die verschiedene Infrastrukturplattformen unterstützen, etwa Hashicorp Terraform und Pulumi.

Diese IaC-Tools, die auf deklarativen Sprachen basieren, eignen sich hervorragend für statische Analysetechniken. So lassen sich Sicherheitsprobleme besser erkennen und beheben, bevor die definierte Infrastruktur überhaupt bereitgestellt wird. Im IaC-Bereich werden ständig neue Best Practices für die Sicherheit entwickelt. Während wir das Snyk IaC-Produkt weiterentwickeln, möchten wir Unternehmen die Einführung von IaC so einfach wie möglich machen. Dazu versetzen wir Entwickler in die Lage, Probleme nicht nur zu erkennen, sondern auch den nötigen Kontext und Empfehlungen zu ihrer Behebung zu erhalten.

Sehen wir uns einige beliebte Infrastructure-as-Code-Tools und die Sicherheitsmaßnahmen an, die Sie auf Code-Ebene zum Schutz Ihrer Anwendungen und Plattformen ergreifen können.

Infrastructure-as-Code-Tools

Cloud-Lösungen

AWS CloudFormation, Azure Resource Manager (ARM), & Google Deployment Manager (GDM)Alle großen Cloud-Anbieter haben eigene IaC-Tools für die automatisierte Infrastruktur-Bereitstellung. Mit JSON- oder YAML-Vorlagen definieren sie deklarativ den gewünschten Zustand Ihrer Deployments. Bei Google Deployment Manager können außerdem Jinja und Python verwendet werden.

Amazon Cloud Development Kit (CDK)Das 2019 veröffentlichte Amazon Cloud Development Kit (CDK) ermöglicht Entwicklern, ihre Deployments in höheren Programmiersprachen wie JavaScript, Python oder C# zu definieren (die vollständige Liste der Sprachen finden Sie hier). Die Syntax ist nicht nur vertrauter, sondern ermöglicht auch die IDE-Integration und das Bündeln von Mustern in wiederverwendbare Bibliotheken und geprüfte Code-Strukturen – statt JSON- oder YAML-Code zwischen Projekten zu kopieren und einzufügen. CDK gibt tatsächlich CloudFormation-JSON aus. Amazon hat also eine entwicklerorientierte Umgebung geschaffen, die weiterhin die bewährten CloudFormation-Tools zur Infrastruktur-Orchestrierung nutzt.

Cloud-übergreifende Lösungen

Hashicorp TerraformTerraform ist ein Tool für die automatisierte Bereitstellung, mit dem sich Ressourcen mithilfe von Provider-Plugins auf einer Vielzahl von Plattformen und Produkten bereitstellen und konfigurieren lassen.

PulumiPulumi ist ein Open-Source-IaC-Projekt mit SDKs in mehreren Programmiersprachen, mit denen sich Ressourcen auf zahlreichen Plattformen bereitstellen und verwalten lassen.

Worauf Sie achten sollten und Beispiele für Scans

Unabhängig davon, welchen Cloud-Anbieter oder welches IaC-Tool Sie verwenden, gibt es aus Sicherheitssicht einige allgemeine Bereiche, auf die Sie sich konzentrieren sollten. Sehen wir uns einige davon zusammen mit Beispielen für Terraform und AWS an. Alle Beispiele finden Sie in diesem GitHub-Repository. Außerdem sehen Sie hier einige Screenshots davon, wie das Snyk IaC-Scan-Tool potenzielle Probleme darstellt.

Zugangsdaten

Im Stammverzeichnis unseres Git-Repositorys befindet sich die Datei main.tf, in der einige häufige Probleme auftreten. Der Snyk-Scan meldet ein Problem mit hohem und fünf mit mittlerem Schweregrad, wie unten dargestellt.

Zunächst sollten Sie niemals Zugangsdaten jeglicher Art in die Versionsverwaltung einchecken. Das klingt selbstverständlich, doch Internetforen sind voll von Beispielen für Code-Repositorys, die solche Daten enthalten – viele davon sind öffentlich zugänglich! Leider wurden viele dieser Beispiele erst entdeckt, nachdem sie bereits ausgenutzt worden waren. Oft geschieht das durch einen versehentlichen Commit eines unachtsamen Benutzers. Besonders heimtückisch ist es, wenn Zugangsdaten committet und anschließend in einem weiteren Commit wieder entfernt werden: Entwickler bemerken das vielleicht nicht, aber die Zugangsdaten bleiben in der Repository-Historie erhalten. Es gibt Verfahren, um dieses Problem abzufangen, etwa mit .gitignore-Dateien oder Pre-Commit-Hook-Skripten, zum Beispiel mit AWS Labs „git-secrets“.

Außerdem sehen wir mehrere Findings zu IAM-Kontopasswörtern. Wichtig ist, dass Sie pro AWS-Konto eine Richtlinie erhalten. Wenn Sie eine eigene einrichten, überschreiben Sie die von Amazon bereitgestellte Standardrichtlinie. Achten Sie deshalb darauf, alle Optionen explizit festzulegen.

Verschlüsselung bei Speicherdiensten

EBS-Volumes sind standardmäßig verschlüsselt, S3-Buckets hingegen nicht. Prüfen Sie beides, um die Einhaltung Ihrer Unternehmensrichtlinien und geltender regulatorischer Vorgaben sicherzustellen. In unserem Demo-Repository haben wir in der Datei modules/storage/main.tf einige Speicherressourcen definiert, die unten gescannt werden:

Hier sehen Sie, dass beide Verstöße gekennzeichnet sind. Außerdem gibt es eine Warnung mit niedrigerer Priorität, weil das S3-Serverzugriffs-Logging nicht aktiviert ist. Wenn Sie eines der Probleme genauer untersuchen, finden Sie Details zum Problem, seinen Auswirkungen und eine Empfehlung zur Behebung.

Die Einstufung der Richtlinien in hohe, mittlere und niedrige Priorität lässt sich optional an die Richtlinien Ihres Unternehmens anpassen.

Ingress- und Egress-Bereiche von Security Groups und Firewalls

In der Datei modules/vpc/main.tf finden wir ein weiteres häufiges Problem: Der eingehende Zugriff ist weiter gefasst, als vermutlich beabsichtigt.

Ähnlich wie bei fest codierten Zugangsdaten entsteht dieses Problem häufig bei der Entwicklung oder Fehlerbehebung und wird versehentlich zusammen mit anderen Änderungen in die Versionsverwaltung übernommen. In diesem Beispiel möchte wahrscheinlich niemand Port 22 für das gesamte Internet öffnen – genau das könnte hier jedoch passieren. Es ist entscheidend, den ein- und ausgehenden Netzwerkverkehr einzuschränken und nur den IP-Bereichen Zugriff zu gewähren, die ihn unbedingt benötigen.

Schlüsselrotation

In unserem letzten Beispiel geht es um die Datei modules/pki/main.tf, in der ein Schlüssel ohne Schlüsselrotation eingerichtet wird.

Auch hier ist das Standardverhalten aus Sicht der Sicherheitshärtung oft nicht die beste Wahl. Diese Empfehlung setzt natürlich voraus, dass Ihr Unternehmen keinen separaten Prozess für die Schlüsselrotation hat. Wenn Sie jedoch den Schlüsselverwaltungsdienst Ihres Cloud-Anbieters verwenden, ist es sehr wahrscheinlich die beste Wahl, diese Aufgaben von ihm übernehmen zu lassen.

Wie sicher sind Ihre IaC-Projekte?

Nachdem Sie nun einige Beispiele für Probleme gesehen haben, die sich leicht in IaC-Code einschleichen können: Wie sicher sind Sie, dass Ihr eigener Code geschützt ist? Denken Sie daran: Sicherheit sollte kein nachträglicher Gedanke sein. Sie können dieselben Prüfungen sowie Prüfungen für andere Cloud-Anbieter und Kubernetes sofort kostenlos für Ihr Repository ausführen und Probleme erkennen, bevor sie bereitgestellt oder ausgenutzt werden.

Erstellen Sie ein kostenloses Snyk-Konto und folgen Sie der Anleitung, um ein Projekt aus Ihrem Repository anzulegen. Innerhalb weniger Minuten erhalten Sie konkrete Empfehlungen zu den gefundenen Problemen.