Infrastructure-as-Code Penetration Testing

Infrastructure-as-Code Penetration Testing ist eine spezialisierte Form des Penetration Testing, die sich auf die Templates, Module und Pipelines konzentriert, mit denen Infrastruktur programmatisch provisioniert und verwaltet wird. Während ein klassischer Cloud-Pentest die laufende Umgebung untersucht, prüft ein IaC-Pentest den Code, der sie erzeugt – Terraform, CloudFormation, Pulumi, Ansible, Helm Charts und die CI/CD-Pipelines, die sie deployen. Das Ziel ist es, unsichere Konfigurationen, hartkodierte Secrets und überprivilegierte Defaults abzufangen, bevor sie auf Produktionssysteme angewendet werden.

Diese Disziplin liegt an der Schnittstelle zwischen DevSecOps und Offensive Security. Sie kombiniert statische Analyse von IaC-Templates mit Runtime-Validierung gegen den tatsächlichen Cloud-Zustand und identifiziert sowohl die in Templates kodierten Schwachstellen als auch den Configuration Drift, der sich nach dem Deployment ansammelt.

Wer beauftragt diesen Test?

IaC Penetration Tests werden von Platform-Engineering-Leads, DevOps-Managern, Cloud-Architekten und CISOs in cloudnativen Organisationen beauftragt. Das Engagement ist typisch für Teams, die IaC im großen Maßstab einführen, Organisationen, die interne Developer-Plattformen bauen, und Unternehmen, die DevSecOps-Reifegradbewertungen durchlaufen. Compliance-Treiber (SOC 2, ISO 27001) verlangen zunehmend den Nachweis, dass Infrastrukturprovisionierung auf Sicherheit getestet wird, nicht nur auf Funktionalität.

Ziel des Tests

Ziel ist die Feststellung, ob die IaC-Codebasis und die zugehörigen Pipelines Sicherheitsschwächen in die provisionierte Infrastruktur einbringen. Konkrete Ziele umfassen die Identifikation hartkodierter Secrets und sensibler Werte in Templates, die Validierung, dass in Code definierte IAM-Policies dem Least-Privilege-Prinzip folgen, die Bewertung der Sicherheit von CI/CD-Pipeline-Konfigurationen, die Erkennung von Drift zwischen deklariertem IaC-Zustand und tatsächlichem Cloud-Zustand sowie die Prüfung, ob Policy-as-Code-Leitplanken wirksam sind.

Was wird getestet?

Getestet werden mehrere Schichten des IaC-Stacks: Templates und Module – Terraform-HCL, CloudFormation-YAML/JSON, Pulumi-Programme und Ansible-Playbooks werden auf Sicherheitsfehlkonfigurationen geprüft: öffentliche Netzwerkexposition, fehlende Verschlüsselung, übermäßig permissive IAM-Policies, unsichere Defaultwerte und deaktiviertes Logging. State- und Secrets-Management – Terraform-State-Files, Parameter-Stores und Secrets-Management-Konfigurationen werden auf Zugriffskontrollen, Verschlüsselung und Expositionsrisiko untersucht. CI/CD-Pipelines – Pipeline-Definitionen (GitHub Actions, GitLab CI, Jenkins, Azure DevOps) werden auf Secret-Leakage, fehlende Branch-Protections, unsignierte Artefakte und überprivilegierte Service Accounts getestet. GitOps-Workflows – ArgoCD, Flux und ähnliche Tools werden auf Repository-Zugriffskontrollen, Drift-Detection-Konfiguration und Deployment-Approval-Gates geprüft. Runtime-Validierung – der tatsächliche Cloud-Zustand wird mit den IaC-Deklarationen verglichen, um Drift, verwaiste Ressourcen und Out-of-Band-Änderungen zu identifizieren.

Übliche Schwachstellen und Findings

Hartkodierte Secrets (API-Keys, Datenbank-Passwörter, TLS-Private-Keys) in IaC-Templates, die in die Versionskontrolle committed wurden
Übermäßig permissive IAM-Policies in Terraform oder CloudFormation mit *:*- oder admin-äquivalenten Berechtigungen
Fehlende Verschlüsselungskonfigurationen für Storage, Datenbanken und Transit
Öffentliche Netzwerkexposition, definiert in Terraform-Security-Groups oder CloudFormation-Ressourcen
CI/CD-Pipeline-Konfigurationen, die Secrets über Umgebungsvariablen, Logs oder Artefakt-Stores leaken
Fehlende Branch-Protection-Rules, die direkte Pushes auf Main/Production-Branches erlauben
Drift zwischen IaC-Definitionen und tatsächlichem Cloud-Zustand, der ungetrackte Sicherheitslücken schafft
Fehlende State-File-Verschlüsselung oder übermäßig breite Zugriffskontrollen auf Terraform-State-Backends
Unsichere Defaultwerte in geteilten Modulen, die organisationsweit propagiert werden
Fehlende Security-Group-Einschränkungen in Helm-Chart-Values oder Kubernetes-Manifesten
Unsignierte Container-Images, die über unvalidierte Pipeline-Stufen deployt werden

Ablauf eines Infrastructure-as-Code Penetrationstests

Ein IaC Penetrationstest folgt einem strukturierten Prozess, der auf Infrastructure-as-Code-Umgebungen zugeschnitten ist:

Interesse und Erstanfrage – der Auftraggeber meldet sich, typischerweise getrieben durch eine DevSecOps-Reifegrad-Initiative, eine Compliance-Anforderung oder einen Sicherheitsvorfall mit fehlkonfigurierter Infrastruktur. Erstgespräch zum Verständnis der Kundenziele – der Testanbieter trifft sich mit Platform-Engineering- und Sicherheitsteams, um den IaC-Stack zu verstehen: eingesetztes Tooling (Terraform, CloudFormation, Ansible, Helm), Repository-Struktur, CI/CD-Plattform, Deployment-Ziele und etwaiges bestehendes Policy-as-Code-Tooling. Angebotserstellung und Freigabe – der Anbieter erstellt ein Angebot mit Methodik (statische Analyse, Pipeline-Review, Runtime-Validierung), Repository- und Pipeline-Scope, Zeitplan und Kosten. Scope-Definition – beide Seiten einigen sich auf zu prüfende Repositories, Module, Pipeline-Definitionen und Cloud-Accounts. Zugriffsanforderungen werden besprochen: Lesezugriff auf IaC-Repositories, CI/CD-Konfigurationen und optional Read-only-Cloud-Credentials für die Runtime-Validierung. Letter of Engagement – die formale Autorisierung wird unterzeichnet und deckt Code-Repository-Zugriff und Cloud-Account-Bewertung ab. Erstellung weiterer Freigaben – Repository-Zugriff wird provisioniert, Cloud-Read-only-Credentials werden erstellt und Drittanbieter-Pipeline-Integrationen dokumentiert. Bereitstellung von Informationen – je nach Ansatz stellt der Auftraggeber Repository-Zugang, Architekturdokumentation, Modul-Dependency-Maps und Pipeline-Diagramme bereit (White-Box ist bei IaC-Assessments am häufigsten) oder begrenzt die Informationen für Gray-Box-Tests. Kick-Off Call – Testteam, Platform Engineers und Sicherheits-Stakeholder stimmen Zeitpläne, Kommunikationskanäle und den Prozess für die Meldung kritischer Findings wie exponierter Secrets ab. Durchführung – das Team führt statische Analysen von IaC-Templates und Modulen durch, prüft CI/CD-Pipeline-Konfigurationen, testet State-Management-Sicherheit und validiert den laufenden Cloud-Zustand gegen IaC-Deklarationen. Exponierte Secrets werden sofort zur Rotation gemeldet. Sammlung und Bewertung der Schwachstellen – alle Findings werden mit Code-Referenzen dokumentiert, nach Schweregrad und Blast Radius bewertet und auf DevSecOps-Reifegrade gemappt. Erstellung des Abschlussberichts – ein umfassender Bericht gliedert die Findings nach IaC-Schicht (Templates, Pipelines, State, Runtime) mit spezifischen Code-Level-Behebungsempfehlungen und Empfehlungen zur Policy-as-Code-Adoption. Vorstellung in einer Präsentation – die Ergebnisse werden Platform Engineering, DevOps und Sicherheitsverantwortlichen präsentiert. Projektabschluss – Behebungsprioritäten werden vereinbart, Retesting-Zeitfenster für kritische Findings gesetzt und Empfehlungen zur Integration von Sicherheitschecks in die CI/CD-Pipeline dokumentiert.

Wer sollte diesen Test wann durchführen lassen?

Organisationen, die IaC für Cloud-Provisionierung einsetzen, sollten diesen Test an entscheidenden Wendepunkten beauftragen: vor der organisationsweiten IaC-Einführung im großen Maßstab, nach signifikanten Änderungen an Pipeline-Konfigurationen oder Modul-Bibliotheken, beim Auf- oder Umbau einer internen Developer-Plattform, im Rahmen von DevSecOps-Reifegradprogrammen und nach Vorfällen, bei denen fehlkonfigurierte Infrastruktur die Ursache war. Teams, die geteilte Terraform-Module oder Helm Charts betreiben, die von mehreren Teams genutzt werden, sollten regelmäßig testen, da unsichere Defaults in geteilten Modulen Schwachstellen im organisationsweiten Maßstab verbreiten.