Infrastructure as Code hat einen einfachen Vorteil: Server, Netzwerke und Datenbanken entstehen nicht mehr per Klick in einer Weboberfläche, sondern aus versioniertem Code. Wer Terraform einsetzt, bekommt reproduzierbare Umgebungen und einen nachvollziehbaren Verlauf. Der gleiche Mechanismus verteilt aber auch Fehler zuverlässig. Eine falsch gesetzte Zeile landet nicht auf einem Server, sondern auf allen. Die folgenden Fehlkonfigurationen tauchen in echten Pipelines am häufigsten auf.
Der State liegt ungeschützt
Der Terraform-State beschreibt den kompletten Ist-Zustand der Infrastruktur, inklusive Passwörtern, Zugangsschlüsseln und Verbindungsdaten, die Ressourcen bei der Erstellung ausgeben. Wer diesen State im Git-Repo ablegt oder in einem öffentlich lesbaren S3-Bucket, gibt damit oft mehr preis als in jeder Konfigurationsdatei. Der State gehört in ein verschlüsseltes Remote-Backend mit Zugriffskontrolle und State-Locking. Lokale State-Dateien haben in einer geteilten Umgebung nichts verloren.
Secrets stehen im Klartext im Code
Ein Datenbank-Passwort als Default-Wert in einer Variable ist bequem und bleibt für immer in der Git-Historie. Selbst wenn es später entfernt wird, lässt es sich aus alten Commits rekonstruieren. Zugangsdaten kommen zur Laufzeit aus einem Secret-Manager oder aus Umgebungsvariablen, nie aus dem Repo. Wer Terraform-Variablen für Geheimnisse nutzt, markiert sie mindestens als sensitive, damit sie nicht in Logs und Plan-Ausgaben erscheinen.
Zu weit geöffnete Netzwerkregeln
Eine Security-Group mit Freigabe von 0.0.0.0/0 auf Port 22 oder 3306 ist schnell geschrieben und öffnet SSH oder die Datenbank für das gesamte Internet. In der Entwicklung fällt das nie auf, weil alles funktioniert. Genau darin liegt das Problem: Fehlkonfigurationen bei Zugriffsrechten machen keinen Fehler sichtbar, sie erweitern nur still die Angriffsfläche. Eingehende Regeln gehören auf konkrete Quell-Adressen oder interne Netze begrenzt, offene Ports brauchen eine Begründung.
Provider und Module ohne feste Versionen
Ohne Versionsbindung zieht Terraform beim nächsten Init die neueste verfügbare Version eines Providers oder Moduls. Das kann Verhalten ändern, das gestern noch stabil war, und öffnet die Tür für kompromittierte Fremd-Module. Provider-Versionen gehören gepinnt, das Lock-File wird eingecheckt, und externe Module bezieht man aus einer vertrauenswürdigen Quelle mit fester Referenz statt aus einem beliebigen main-Branch.
Kein automatischer Check vor dem Apply
Die meisten dieser Fehler lassen sich vor dem Deployment finden. Werkzeuge wie tfsec, Checkov oder terrascan prüfen den Code statisch gegen bekannte Fehlkonfigurationen und laufen in wenigen Sekunden. Wer diese Prüfung in die Pipeline hängt, sodass ein Apply bei kritischen Befunden blockiert, verhindert dass eine offene Datenbank überhaupt erst entsteht. Ein manueller Blick reicht bei wachsender Codebasis nicht mehr aus.
Drift zwischen Code und Realität
Sobald jemand eine Ressource manuell in der Cloud-Konsole ändert, weicht der reale Zustand vom Code ab. Der nächste Apply macht die Änderung entweder unbemerkt rückgängig oder scheitert. Regelmäßiger Drift-Check über terraform plan im reinen Lesemodus macht solche Abweichungen sichtbar, bevor sie zum Problem werden. Die Regel dahinter ist simpel: Änderungen laufen über den Code, nicht über die Konsole.
Fazit
Infrastructure as Code verschiebt Sicherheit nach links, in den Code und in die Pipeline. Das ist ein Vorteil, solange die Prüfungen dort auch stattfinden. Ungeschützter State, Secrets im Repo, offene Netzwerkregeln und ungepinnte Versionen sind keine exotischen Randfälle, sondern die Standardbefunde. Sie kosten wenig Aufwand in der Behebung und viel im Schadensfall.
Sie wollen wissen, ob Ihre Terraform-Konfiguration und Ihre Pipeline diese Befunde enthalten? Der GitSecOps QuickCheck prüft Ihre Delivery-Kette systematisch und liefert in 3 Werktagen einen konkreten Befundbericht. Festpreis 1.990 Euro netto. Kontakt: mm@crank.zone.
Dein Blog zum Thema digitales Business 
Hinterlasse einen Kommentar