Infrastructure-as-Code Security-Scanning: Fehlkonfigurationen vor dem Deployment finden

1. Das Shift-Left-Prinzip für Infrastruktur-Sicherheit

Shift-Left bedeutet, eine Prüfung so früh wie möglich im Entwicklungsprozess durchzuführen, statt sie erst am Ende, kurz vor oder sogar nach dem Deployment, vorzunehmen. Bei Infrastructure as Code bedeutet das konkret, eine Terraform-Konfiguration bereits während der Entwicklung und spätestens im Pull-Request automatisiert auf Sicherheitsprobleme zu prüfen, statt auf einen vierteljährlichen, manuellen Infrastruktur-Audit zu warten.

Der Unterschied ist in der Praxis erheblich: Eine Fehlkonfiguration, die im Pull-Request auffällt, kostet den Autor wenige Minuten zur Korrektur. Dieselbe Fehlkonfiguration, die erst Monate später bei einem manuellen Audit entdeckt wird, läuft möglicherweise längst produktiv, hat unter Umständen bereits echten Traffic verarbeitet und erfordert eine koordinierte, risikobehaftete Änderung an laufender Infrastruktur.

2. Typische Fehlkonfigurationen, die Scanner zuverlässig finden

Zu den häufigsten Funden gehören Security-Groups oder Firewall-Regeln, die einen Port für den Zugriff aus 0.0.0.0/0 öffnen, obwohl nur ein internes Netzwerk zugreifen sollte. Ebenso häufig sind Storage-Ressourcen wie S3-Buckets oder Datenbank-Instanzen, bei denen Verschlüsselung im Ruhezustand nicht aktiviert ist, obwohl der jeweilige Cloud-Anbieter diese Option ohne Mehrkosten anbietet.

Weitere klassische Funde sind IAM-Rollen mit übermäßig breiten Berechtigungen, etwa ein Wildcard in der Resource-Angabe einer Policy, sowie fehlende Logging-Konfigurationen, die im Ernstfall eine forensische Aufklärung erschweren würden. Jede dieser Fehlkonfigurationen lässt sich anhand einer klar formulierten Regel automatisiert erkennen, ohne dass ein Mensch die Konfiguration manuell durchlesen muss.

3. tfsec und Checkov im Vergleich

tfsec, mittlerweile Teil von Trivy, ist auf Terraform spezialisiert und analysiert die Konfiguration statisch, ohne dass ein terraform plan ausgeführt werden muss. Es bringt einen umfangreichen, direkt einsatzbereiten Regelsatz für alle großen Cloud-Anbieter mit und lässt sich mit wenig Konfigurationsaufwand in eine Pipeline einbinden.

Checkov von Bridgecrew deckt neben Terraform zusätzlich Formate wie CloudFormation, Kubernetes-Manifeste, Docker-Compose und Dockerfiles ab, was es zu einem geeigneteren Werkzeug macht, wenn ein Team mehrere Infrastruktur-Formate parallel pflegt. Checkov erlaubt zudem eigene Regeln in Python zu definieren, während tfsec eigene Regeln über eine einfachere, deklarative Struktur ermöglicht.

# GitLab CI: Checkov als Pflicht-Stufe vor dem Terraform-Apply
stages:
  - security-scan
  - plan
  - apply

checkov-scan:
  stage: security-scan
  image: bridgecrew/checkov:latest
  script:
    - checkov -d ./infrastructure
        --framework terraform
        --compact
        --soft-fail-on LOW,MEDIUM
        --hard-fail-on HIGH,CRITICAL
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

terraform-plan:
  stage: plan
  needs: ["checkov-scan"]
  script:
    - terraform init
    - terraform plan -out=tfplan

4. Policy-as-Code mit Open Policy Agent

Während tfsec und Checkov mit vorgefertigten Regeln arbeiten, erlaubt Policy-as-Code mit Open Policy Agent und der Regelsprache Rego, unternehmensspezifische Richtlinien als Code zu formulieren, die über die Standardregeln hinausgehen. Ein Beispiel wäre eine interne Vorgabe, dass alle Ressourcen in der Produktionsumgebung ein bestimmtes Tag-Schema tragen müssen, was kein generischer Sicherheitsscanner von sich aus prüft.

Der Vorteil von Policy-as-Code liegt darin, dass diese unternehmensspezifischen Regeln versioniert, getestet und im selben Pull-Request-Workflow ausgewertet werden können wie generische Sicherheitsregeln. So entsteht ein einheitlicher Prüfprozess, der sowohl branchenweite Best Practices als auch individuelle Compliance-Vorgaben abdeckt, ohne zwei getrennte Werkzeuge parallel pflegen zu müssen.

5. Terraform-spezifische Prüfungen im Detail

Bei Terraform prüfen Scanner nicht nur einzelne Ressourcenblöcke isoliert, sondern zunehmend auch den Kontext zwischen Ressourcen, etwa ob eine öffentlich erreichbare Load-Balancer-Regel tatsächlich auf eine private Subnetz-Konfiguration trifft. Diese kontextbezogene Prüfung reduziert False Positives erheblich, weil eine auf den ersten Blick offene Regel im Gesamtkontext harmlos sein kann, wenn sie durch eine andere Ressource bereits eingeschränkt wird.

Zusätzlich prüfen moderne Scanner den geplanten Zustand eines terraform plan, nicht nur den statischen Code, was Fehlkonfigurationen aufdeckt, die erst durch die Kombination von Variablen und Modulen im Zusammenspiel entstehen und im isolierten Quellcode allein nicht sichtbar wären.

6. Docker-Compose-Konfigurationen auf Fehlkonfigurationen prüfen

Auch Docker-Compose-Dateien enthalten häufig Sicherheitsprobleme, etwa Container, die mit privilegiertem Modus laufen, obwohl das für die Anwendung nicht notwendig ist, oder Volumes, die sensible Host-Pfade wie den Docker-Socket ungeschützt in den Container einhängen. Checkov deckt genau diese Muster ab und kann in derselben Pipeline laufen, die auch die Terraform-Konfiguration prüft.

Besonders in Entwicklungsumgebungen schleichen sich solche Konfigurationen leicht ein, weil ein privilegierter Container das Debugging kurzfristig vereinfacht. Wird eine solche Compose-Datei jedoch unverändert als Vorlage für eine produktive Umgebung übernommen, entsteht daraus ein reales Sicherheitsrisiko, das ein automatisierter Scan zuverlässig aufdeckt, bevor es so weit kommt.

7. Integration in den Pull-Request-Workflow

Damit Infrastructure-as-Code-Scanning tatsächlich wirkt, muss das Ergebnis dort sichtbar werden, wo Entwickler ohnehin arbeiten: direkt als Kommentar im Pull Request, mit konkreter Zeilenangabe und einer verständlichen Erklärung, warum eine bestimmte Konfiguration als problematisch eingestuft wird. Ein reiner Log-Eintrag in einem CI-Dashboard, den niemand aktiv aufruft, entfaltet in der Praxis kaum Wirkung.

Viele Teams konfigurieren den Scan zusätzlich als verpflichtenden Statuscheck, der einen Merge blockiert, solange kritische Funde offen sind, während niedrigere Schweregrade als Warnung im Kommentar erscheinen, ohne den Merge zu verhindern. Dieses abgestufte Vorgehen verhindert, dass das Team das Gate als reines Hindernis wahrnimmt und nach Wegen sucht, es systematisch zu umgehen.

8. Umgang mit Ausnahmen und bewusster Risikoakzeptanz

Nicht jede gemeldete Fehlkonfiguration ist im konkreten Kontext tatsächlich ein Risiko. Ein offener Port kann etwa gerechtfertigt sein, wenn er ausschließlich für einen öffentlichen, ohnehin unauthentifizierten Health-Check-Endpunkt gedacht ist. Für solche Fälle unterstützen tfsec und Checkov Inline-Kommentare direkt im Terraform-Code, die eine bestimmte Regel für eine bestimmte Ressource gezielt und nachvollziehbar ausschließen.

Entscheidend ist, dass jede Ausnahme eine kurze Begründung im selben Kommentar trägt und im Code-Review sichtbar bleibt. Eine Ausnahme ohne Begründung sieht im Nachhinein identisch aus wie eine schlicht übersehene Fehlkonfiguration, was die spätere Unterscheidung zwischen bewusster Risikoakzeptanz und echtem Versehen praktisch unmöglich macht.

9. Vom einmaligen Scan zum kontinuierlichen Compliance-Monitoring

Ein Scan im Pull Request deckt nur Änderungen ab, die tatsächlich über Code eingebracht werden. In der Praxis entstehen Abweichungen jedoch auch durch manuelle Änderungen direkt in der Cloud-Konsole, etwa wenn jemand im Notfall schnell eine Regel anpasst und vergisst, die Änderung anschließend in Terraform nachzuziehen.

Ein kontinuierliches Compliance-Monitoring, das den tatsächlichen Zustand der Cloud-Umgebung regelmäßig gegen dieselben Regeln prüft, die auch im Pull-Request-Scan gelten, deckt genau diese Drift zwischen Code und Realität auf. So bleibt sichergestellt, dass Sicherheitsstandards nicht nur beim Deployment gelten, sondern dauerhaft, unabhängig davon, auf welchem Weg eine Änderung tatsächlich vorgenommen wurde.

In der Praxis lohnt es sich, ein solches Monitoring als eigenen, wiederkehrenden Job zu betreiben, der unabhängig von jedem einzelnen Pull Request mehrmals täglich läuft und Abweichungen in einem zentralen Dashboard sichtbar macht. Wird dort eine neue Abweichung entdeckt, sollte automatisch ein Ticket mit klarer Verantwortlichkeit entstehen, damit die Lücke zwischen Code und tatsächlichem Zustand nicht unbemerkt über Wochen bestehen bleibt, sondern zeitnah wieder geschlossen wird.

10. Zusammenfassung

11. FAQ: IaC Security-Scanning: Das Wichtigste auf einen Blick