Wie sichert man Infrastructure as Code in der Pipeline?
Kurzantwort
IaC-Scanning analysiert Terraform-, CloudFormation-, Kubernetes- und ähnliche Definitionen statisch gegen eine Richtlinie, um Fehlkonfigurationen zu finden — öffentliche S3-Buckets, offene Security Groups, fehlende Verschlüsselung — bevor sie überhaupt bereitgestellt werden. Da dieselbe Vorlage viele Ressourcen bereitstellt, verhindert eine einmalige Korrektur wiederkehrende Drift, und das Erkennen vor dem Anwenden ist weitaus günstiger als das Beheben aktiver Cloud-Ressourcen. Zu den Tools gehören Checkov, tfsec und KICS, idealerweise als Policy-as-Code-Gates durchgesetzt.
Die meisten Cloud-Breaches lassen sich auf Fehlkonfiguration zurückführen, nicht auf exotische Exploits. Da Infrastruktur nun als Code definiert wird, können Sie diese Fehlkonfigurationen genauso erkennen wie Bugs — indem Sie den Code scannen.
Was IaC-Scanning tut
Ein IaC-Scanner analysiert Infrastrukturdefinitionen statisch — Terraform, CloudFormation, ARM/Bicep, Kubernetes-Manifeste, Helm-Charts — gegen eine Bibliothek von Sicherheitsregeln und Ihre eigenen Richtlinien. Er kennzeichnet die Klassiker: öffentlich zugängliche Storage-Buckets, Security Groups offen für 0.0.0.0/0, unverschlüsselte Volumes, zu weit gefasste IAM-Rollen, fehlendes Logging. Tools wie Checkov, tfsec und KICS lassen sich direkt in die CI einbinden und laufen bei jedem Pull Request.
Warum die Vorlage scannen, nicht die Ressource
Das ist die zentrale Erkenntnis. Ein einzelnes Modul kann Dutzende von Ressourcen über viele Umgebungen hinweg bereitstellen. Korrigieren Sie die Vorlage einmal und jedes künftige Deployment ist korrekt; beheben Sie die aktive Ressource und sie driftet zurück, sobald jemand das nächste Mal die Pipeline ausführt. Das Scannen vor dem Anwenden ist außerdem dramatisch günstiger — Sie bearbeiten eine Datei, statt im Wettlauf eine bereits öffentlich exponierte Datenbank abzuriegeln, die schon Traffic bedient.
Policy as Code und Ausnahmen
Reife Teams drücken ihre Leitplanken als Policy-as-Code aus (z. B. OPA/Rego oder die eigene Richtliniensprache des Scanners), damit Regeln versioniert und konsistent sind. Wenn ein Befund eine legitime Ausnahme ist, deaktivieren Sie nicht den Scanner — Sie erfassen eine dokumentierte, zeitlich begrenzte, geprüfte Unterdrückung, damit die Ausnahme prüfbar statt still ist.
Kombinieren Sie es mit Laufzeit-Checks
IaC-Scanning sieht nur, was in den Vorlagen steht. Kombinieren Sie es mit Cloud Security Posture Management (CSPM), um Drift und außerhalb der Pipeline erstellte Ressourcen zu erkennen.
Worauf Interviewer achten
Sie wollen die Argumentation «die Vorlage korrigieren, nicht die Ressource», das Bewusstsein für reale Tools und einen vernünftigen Umgang mit Ausnahmen, der das Gate aussagekräftig hält.
Wahrscheinliche Anschlussfragen
- Warum ist das Korrigieren der Vorlage besser als das Korrigieren der bereitgestellten Ressource?
- Was ist Policy-as-Code und wie passt es hier hinein?
- Wie behandeln Sie eine legitime Ausnahme von einer Richtlinie?