Sicherheits-Scanning für Infrastructure as Code

Infrastructure-as-Code-(IaC)-Tools wie Terraform, AWS CloudFormation, Ansible und Helm ermöglichen es, Infrastruktur in versionierten Konfigurationsdateien zu definieren. Das bietet enorme Vorteile – Wiederholbarkeit, Überprüfbarkeit und Automatisierung –, birgt aber auch ein kritisches Sicherheitsrisiko: Fehlkonfigurationen in IaC-Dateien erzeugen in großem Maßstab unsichere Infrastruktur. Ein einziges falsch konfiguriertes Terraform-Modul, das in 50 Umgebungen bereitgestellt wird, erzeugt gleichzeitig 50 verwundbare Systeme. IaC-Sicherheitsscans wirken dem entgegen, indem sie Konfigurationsdateien vor ihrer Anwendung prüfen und die Sicherheit in den Entwickler-Workflow verlagern.

Sicherheitsscanning-Tools suchen nach den häufigsten IaC-Fehlkonfigurationen, die in realen Cloud-Umgebungen vorkommen: S3-Buckets mit aktiviertem öffentlichem Zugriff oder ohne Verschlüsselung im Ruhezustand; Sicherheitsgruppen mit eingehenden 0.0.0.0/0-Regeln auf sensiblen Ports (22, 3389, 1433); Datenbanken ohne Verschlüsselung oder mit öffentlicher Erreichbarkeit; IAM-Richtlinien mit Platzhaltern * für Ressourcen oder Aktionen; in einer Region deaktiviertes CloudTrail; KMS-Schlüssel ohne Schlüsselrotation; sowie Load Balancer mit HTTP-Listenern statt HTTPS. Diese Ergebnisse entsprechen weitgehend den Prüfungen von Cloud-Security-Benchmarks wie CIS AWS Foundations.

Checkov (von Bridgecrew/Prisma Cloud) ist ein beliebtes Open-Source-Tool zur statischen Analyse von IaC. Es unterstützt Terraform, CloudFormation, Kubernetes-Manifeste, Helm-Charts und Dockerfiles. Es enthält über 1.000 integrierte Richtlinien, die den CIS-Benchmarks, der DSGVO, SOC 2 und HIPAA zugeordnet sind. Mit checkov -d . werden alle IaC-Dateien im aktuellen Verzeichnis geprüft. Das Ergebnis ist ein farbcodierter Bericht über bestandene, fehlgeschlagene und übersprungene Prüfungen einschließlich Ressourcenpfaden und Anleitungen zur Behebung. Checkov lässt sich in CI/CD-Pipelines integrieren, um Bereitstellungen zu blockieren, wenn kritische Prüfungen fehlschlagen.

tfsec (jetzt Bestandteil der IaC-Scan-Funktion von Trivy) ist ein speziell entwickelter Sicherheitsscanner für Terraform, der die HCL-Syntax besonders umfassend versteht. Dadurch kann er Werte über Module und Variablendateien hinweg nachverfolgen. Anders als einfachere Scanner erkennt tfsec auch Fehlkonfigurationen, bei denen sich das Problem über mehrere Dateien erstreckt – beispielsweise eine Sicherheitsgruppenregel, die isoliert betrachtet sicher wirkt, aber in einer anderen Datei an eine Ressource gebunden ist. tfsec erstellt Findings mit Schweregraden (CRITICAL, HIGH, MEDIUM, LOW), CWE-IDs und direkten Links zur Dokumentation zur Behebung, sodass Entwickler die Findings unmittelbar bearbeiten können.

Eines der kritischsten IaC-Sicherheitsprobleme sind hartcodierte Secrets in Konfigurationsdateien – Passwörter, API-Schlüssel, private TLS-Schlüssel und Datenbankverbindungszeichenfolgen, die in Git eingecheckt werden. Da IaC-Repositorys häufig teamübergreifend genutzt und in der Versionsverwaltung gespeichert werden, ist ein auch nur einmal eingechecktes Secret praktisch dauerhaft kompromittiert (die Git-Historie ist unveränderlich). Tools wie Checkov, detect-secrets, git-secrets und TruffleHog suchen nach Secret-Mustern. Die Lösung besteht darin, Eingabevariablen zu verwenden, deren Werte aus Umgebungsvariablen oder Secret-Speichern stammen – niemals hartcodierte Werte.

Policy-as-Code-(PaC)-Frameworks ermöglichen es Sicherheitsteams, benutzerdefinierte Regeln als Code zu formulieren und konsistent durchzusetzen. Mit Open Policy Agent (OPA) und Conftest lassen sich Rego-Richtlinien schreiben, die beliebige strukturierte Daten – Terraform-Pläne, Kubernetes-Manifeste oder Helm-Werte – in CI/CD-Pipelines validieren. HashiCorp Sentinel ist in Terraform Enterprise und Cloud integriert und ermöglicht Richtlinien wie „Alle S3-Buckets müssen Verschlüsselung aktiviert haben“ bereits bei der Planerstellung durchzusetzen. Jeder Apply-Vorgang, der gegen die Richtlinie verstoßen würde, wird blockiert. Mit diesen Tools lassen sich Sicherheitsanforderungen als Code festhalten und zusammen mit der von ihnen gesteuerten Infrastruktur versionieren.

Konfigurationsdrift tritt auf, wenn der tatsächliche Zustand der bereitgestellten Infrastruktur von der IaC-Definition abweicht – häufig, weil jemand manuell eine Änderung über die Cloud-Konsole vorgenommen hat. Eine manuell hinzugefügte Regel für eine Sicherheitsgruppe, die einen Entwickler „vorübergehend“ freischalten soll, wird zu einer dauerhaften Sicherheitslücke. Tools zur Drift-Erkennung vergleichen kontinuierlich den gewünschten Zustand (IaC-Dateien) mit dem tatsächlich bereitgestellten Zustand und melden Abweichungen. AWS Config, die Drift-Erkennung von Terraform Cloud und CSPM-Tools (Prisma Cloud, Wiz) bieten diese Funktion. Sicherheitsfehlkonfigurationen, die durch Änderungen an der Konsole entstehen, werden erkannt, bevor Angreifer sie entdecken.

Immutable Infrastructure bedeutet, dass Server und Konfigurationen niemals direkt geändert werden. Stattdessen werden bei Änderungen neue Ressourcen (neue AMIs, neue Container-Images) erstellt und die alten ersetzt. In Kombination mit GitOps – bei dem alle Infrastrukturänderungen über einen Git-Pull-Request erfolgen müssen und dadurch IaC-Scans sowie Genehmigungsprozesse ausgelöst werden – wird Konfigurationsdrift konstruktionsbedingt verhindert: Was nicht manuell geändert werden kann, kann nicht driften. Tools wie ArgoCD für Kubernetes und Atlantis für Terraform implementieren GitOps-Workflows, bei denen jede Abweichung eine automatische Wiederherstellung des Sollzustands oder eine Warnung auslöst.

IaC-Sicherheitsscans werden manchmal mit SAST (Static Application Security Testing) verwechselt, doch beide prüfen unterschiedliche Artefakte. SAST analysiert den Quellcode von Anwendungen (Python, Java, JavaScript) auf Schwachstellen wie SQL-Injection oder Pufferüberläufe. IaC-Scanning analysiert Infrastruktur-Konfigurationsdateien auf Fehlkonfigurationen der Cloud-Sicherheit – Anwendungscode ist daran nicht beteiligt. Eine vollständige DevSecOps-Pipeline umfasst beides: SAST für Anwendungscode und IaC-Scanning für Infrastrukturdateien. Beide Prüfungen laufen vor jeder Bereitstellung in CI/CD. Einige einheitliche Plattformen (Snyk IaC, Prisma Cloud) kombinieren das Scannen von Anwendungen und Infrastruktur in einem einzigen Tool.

Effektives IaC-Sicherheits-Scanning muss automatisiert und verbindlich sein – nicht optional. Eine typische CI/CD-Integration sieht folgendermaßen aus: Bei jedem Pull-Request werden Checkov und tfsec ausgeführt; die Pipeline schlägt fehl, wenn CRITICAL-Findings vorhanden sind; Findings werden zur besseren Sichtbarkeit für Entwickler als Kommentare im Pull-Request veröffentlicht; eine Liste unterdrückter Findings mit dokumentierten Begründungen wird gepflegt; und jede Nacht wird ein Scan der bereitgestellten Ressourcen auf Drift ausgeführt. Pre-Commit-Hooks mit Tools wie pre-commit und Checkov können Probleme bereits erkennen, bevor der Code die Pipeline erreicht. Der Umgang mit False Positives ist wichtig: Entwickler, die zu viele irrelevante Findings sehen, beginnen, sie zu ignorieren.

Die Statusdatei von Terraform (terraform.tfstate) enthält das vollständige Inventar aller verwalteten Ressourcen und oft auch vertrauliche Ausgabewerte wie Datenbankpasswörter, private TLS-Schlüssel und IAM-Zugriffsschlüssel-IDs im Klartext. Statusdateien dürfen niemals in Git eingecheckt werden. Verwenden Sie stattdessen ein Remote-Backend (AWS S3 mit DynamoDB-Sperrung, Terraform Cloud oder einen von GitLab verwalteten Status) mit aktivierter serverseitiger Verschlüsselung. Der Zugriff auf das Status-Backend muss über IAM strikt kontrolliert werden: Jeder, der die Statusdatei lesen kann, kann alle Infrastrukturdetails erfassen und möglicherweise eingebettete Secrets extrahieren.

Testen Sie Ihr Verständnis der CompTIA-Security+-Konzepte (SY0-701) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: IaC-Fehlkonfigurationen wie öffentliche S3-Buckets, offene Sicherheitsgruppen und hartcodierte Secrets werden durch Tools wie Checkov und tfsec vor der Bereitstellung automatisch erkannt. Policy-as-Code-Frameworks (OPA/Conftest, HashiCorp Sentinel) ermöglichen es, benutzerdefinierte Sicherheitsanforderungen der Organisation als automatisierte Gates in der Pipeline durchzusetzen. Außerdem müssen Terraform-Statusdateien in verschlüsselten Remote-Backends mit strengen Zugriffskontrollen gespeichert werden, da sie vertrauliche Ressourcendetails enthalten können. Als Nächstes untersuchen wir den Lebenszyklus von APTs und wie sich fortgeschrittene Bedrohungen in Netzwerken festsetzen.