Ich erinnere mich an den Moment, als mir klar wurde, dass Infrastructure as Code nicht nur Probleme löst, sondern auch neue schafft.
Ein Team hatte Standards über die gesamte Infrastruktur gezogen. Alles lief über CDK. Alles war automatisiert. Alles schien perfekt.
Bis ein Security-Audit aufdeckte, dass grundlegende Sicherheitsfeatures fehlten. Nicht weil das Team inkompetent war. Sondern weil sie blind auf Standardimplementationen vertraut hatten.
Das ist das Paradox von IaC: Die gleiche Automation, die Konsistenz und Geschwindigkeit bringt, multipliziert auch Fehler. Ein kleiner Fehler in einem Template kann zur Erstellung von Hunderten ungesicherter Assets führen.
Lass mich dir zeigen, wo die echten Fallen liegen.
CDK macht vieles richtig. Die High-Level Constructs (L2 und L3) bringen tatsächlich Security Best Practices mit. Aber eben nur teilweise.
Nimm S3-Buckets als Beispiel. SSL-Enforcement ist in CDK simpel zu konfigurieren:
const bucket = new s3.Bucket(this, 'Bucket', {
enforceSSL: true,
});Eine Zeile Code. Fertig.
Aber es passiert trotzdem nicht. Warum?
Weil Teams davon ausgehen, dass CDK "schon alles richtig macht". Niemand liest die komplette Dokumentation durch. Niemand checkt systematisch, welche Security-Features optional sind. Man nimmt das Default-Verhalten und deployed.
Erst wenn ein Security-Audit kommt – oder schlimmer, ein Vorfall passiert – fällt auf, dass grundlegende Dinge fehlen.
Das Security-Bewusstsein ist da. Es wird nur zu spät aktiviert. Nach dem Deployment, nicht davor.
2025 wurden 22,8 Millionen hardcodierte Secrets in öffentlichen GitHub-Repositories gefunden. Ein Anstieg von 25% gegenüber dem Vorjahr.
Noch alarmierender: 70% der Secrets, die 2022 exponiert wurden, sind heute noch gültig.
Das sind keine theoretischen Risiken. Das sind offene Türen für Angreifer.
Wie passiert das überhaupt noch?
Es sind echte Versehen mit strukturellen Ursachen. Ein Entwickler testet lokal, braucht schnell einen API-Key, hardcoded das "nur zum Testen" in die Config-Datei – und vergisst, es vor dem Commit rauszunehmen.
Besonders kritisch: .env-Dateien oder Terraform tfvars, die aus Bequemlichkeit committed werden. Oder Beispiel-Configs mit echten Secrets, weil "ist ja nur Development".
Strukturell fehlt oft ein klarer Prozess für Secrets Management. Statt AWS Secrets Manager oder Parameter Store zu nutzen, wird der einfache Weg gegangen.
Und wenn kein Pre-Commit-Hook da ist, der Secrets erkennt, landet das Zeug im Repository.
Einmal drin, für immer in der Git-History.
Selbst wenn du die History mit git filter-branch oder BFG Repo-Cleaner bereinigst, kannst du nicht sicher sein, wer das Repo schon gecloned hat oder ob CI/CD-Systeme das Secret bereits geloggt haben.
Die einzig sichere Maßnahme: Das Secret sofort rotieren. API-Key widerrufen, neuen generieren, Passwort ändern. Bei AWS-Keys checkst du CloudTrail-Logs auf verdächtige Aktivitäten.
Aufwendig. Stressig. Genau deshalb ist Prävention so wichtig.
Viele Teams denken nicht daran, dass State Files alle Ressourcen-Details enthalten. Inklusive Secrets, Passwörter, Connection Strings.
Im Klartext.
Wenn der State File lokal liegt oder in einem unverschlüsselten S3-Bucket ohne Zugriffskontrolle, ist das ein massives Risiko.
Remote State mit Encryption und strikten IAM-Policies ist Pflicht.
Aber ich sehe immer wieder Projekte, wo das vernachlässigt wird. Standardmäßig verwendet Terraform lokale State Files (terraform.tfstate). Diese sind weniger sicher und können versehentlich von unbefugten Nutzern abgerufen werden.
Wenn State Files in die falschen Hände geraten, können Angreifer Informationen über fehlkonfigurierte Assets erhalten und sie zur Datenexfiltration nutzen.
Configuration Drift entsteht, wenn jemand manuelle Änderungen direkt in der Cloud-Konsole macht, statt über IaC.
Ein klassisches Beispiel: Ein Entwickler braucht schnell Zugriff auf eine Datenbank, öffnet kurz eine Security Group in der AWS Console – "nur für heute" – und vergisst, das rückgängig zu machen.
Plötzlich weicht die tatsächliche Infrastruktur vom IaC-Code ab.
Dein Terraform- oder CDK-State kennt diese Änderung nicht.
Beim nächsten Deployment kann die manuelle Änderung überschrieben werden. Oder schlimmer: Sie bleibt bestehen und niemand weiß davon.
Shadow Infrastructure ist noch kritischer. Das sind Ressourcen, die komplett außerhalb des IaC-Prozesses erstellt wurden. Jemand spinnt mal eben eine EC2-Instanz hoch oder erstellt einen S3-Bucket manuell, weil's schneller geht.
Diese Ressourcen tauchen in keinem Code auf. Werden nicht überwacht. Nicht gepatcht. Fallen oft erst bei Security-Audits oder der Kostenkontrolle auf.
Zum Sicherheitsproblem wird das, weil du keine Kontrolle mehr hast.
Du kannst nicht sicherstellen, dass Security-Policies greifen. Du hast keine Audit-Trail. Im Worst Case läuft da eine komplett ungesicherte Ressource mit Produktionsdaten.
Der direkteste Weg ist Cloud Asset Inventory. Bei AWS nutze ich Tools wie AWS Config oder Resource Groups Tagging API, um alle Ressourcen aufzulisten und mit dem IaC-State abzugleichen.
Noch besser: Spezialisierte Tools wie Driftctl oder Infracost, die automatisch Drift erkennen und reporten.
Der Prozess:
Tagge alle IaC-verwalteten Ressourcen mit "ManagedBy: Terraform" oder "ManagedBy: CDK"
Scanne regelmäßig – am besten automatisiert – alle Cloud-Ressourcen
Filtere nach denen ohne dieses Tag
Was übrig bleibt, ist potenzielle Shadow Infrastructure
Das allein reicht nicht. Du brauchst auch eine Kultur, in der klar ist: Manuelle Änderungen sind tabu.
Am Anfang eines Projekts liegt der Fokus auf "schnell produktiv werden", nicht auf "alles perfekt absichern".
Teams wollen erst mal Features ausrollen und Infrastruktur zum Laufen bringen.
Security-Tools wie cdk-nag einzubinden bedeutet: Pipeline anpassen, verstehen wie das Tool funktioniert, und dann mit den ganzen Findings umgehen, die plötzlich auftauchen.
Das kann am Anfang überwältigend sein. Hunderte Warnings, die man erst mal durcharbeiten muss.
Viele denken sich: "Das machen wir später, wenn die Basis steht."
Aber dieses "später" kommt oft nie, weil dann schon das nächste Feature Priorität hat.
Es fehlt die Disziplin oder das Mandat von oben, Security von Tag 1 an nicht verhandelbar zu machen.
Die Frage ist doch nur: Wann muss sich das Team um seine Findings kümmern?
Bei einem meiner früheren Projekte ging ich in ein Team rein, das sich nicht proaktiv um OS-Patches gekümmert hat. Im CDK-Code waren auch einige Findings vorhanden.
Das Team des CISO kam irgendwann aufs Projektteam zu: Deren Cloud Account fällt negativ auf.
Das Team hatte gar keine Handhabe mehr, ob es sich darum kümmern will. Es wurde gezwungen unter der Androhung, dass ihnen sonst der Cloud Account weggenommen wird.
Wenn sich Teams früh genug um ihre technischen Schulden kümmern, verlieren sie die Möglichkeit, selbst die Zeit einzuplanen. Sie reagieren auf Druck von außen. Das kann vom CISO ausgehen oder schlimmer – von einem echten Sicherheitsvorfall.
Ich würde mit einem gestaffelten Ansatz arbeiten.
Am Anfang nur die kritischen Blocker:
Secrets-Scanning mit Tools wie git-secrets oder truffleHog. Das ist non-negotiable, weil ein eingechecktes Secret sofort ein Risiko ist.
Dann ein Basis-Set an Policy-Checks, zum Beispiel mit cdk-nag, aber nur auf "Error"-Level, nicht "Warning".
Das heißt: Nur die wirklich harten Verstöße wie fehlende Encryption at Rest oder komplett offene Security Groups stoppen die Pipeline.
Alles andere läuft als Warning durch und wird geloggt, aber blockiert nicht.
So können Teams weiterarbeiten, sehen aber ihre technische Schuld wachsen.
Nach ein paar Sprints würde ich dann schrittweise mehr Checks auf "Error" hochziehen – aber immer mit dem Team abgestimmt, nicht von oben diktiert.
Wichtig: Die Findings müssen verständlich sein. Wenn ein Tool nur kryptische Fehlermeldungen ausspuckt, ignorieren Teams das.
Es braucht klare Erklärungen und idealerweise direkt einen Link zur Lösung.
So bleibt das Team handlungsfähig, aber Security wird von Anfang an sichtbar gemacht.
Teams loggen alles, um Probleme zu debuggen. Dabei landen oft sensible Daten in CloudWatch, Datadog oder anderen Monitoring-Tools.
Personenbezogene Daten. API-Responses mit Credentials. Datenbankabfragen mit Nutzerdaten.
Wenn diese Logs nicht richtig geschützt sind oder zu lange aufbewahrt werden, hast du ein Datenschutzproblem.
Security und Observability müssen zusammen gedacht werden, nicht getrennt.
Das ist eine der am meisten unterschätzten Fallen. Neben Terraform State Files.
Wenn ich die wichtigsten Datenschutz- und Sicherheitsfallen in IaC zusammenfassen müsste, stehen ganz oben:
Secrets im Code – 22,8 Millionen in GitHub allein 2025
Fehlende Encryption at Rest und in Transit – Grundlegende Absicherung fehlt
Zu offene Security Groups und IAM-Policies – Least Privilege wird ignoriert
Öffentlich zugängliche S3-Buckets oder Datenbanken – Fehlkonfigurationen als häufigste Ursache von Cloud-Breaches
Fehlende Logging und Monitoring – Keine Visibility, keine Kontrolle
Ungesicherte Terraform State Files – Secrets im Klartext
Keine Policy-as-Code für Compliance – Manuelle Checks reichen nicht
Konfigurationsdrift durch manuelle Änderungen – Shadow Infrastructure entsteht
Fehlende Container-Security bei Base Images – Supply Chain Risks
Mangelnde Zugriffskontrolle in GitOps-Workflows – Wer darf was deployen?
Harte Regeln allein funktionieren nicht. Sie werden umgangen, sobald der Druck groß genug ist.
Stattdessen muss der IaC-Prozess so schnell und reibungslos sein, dass manuelle Änderungen keinen Vorteil mehr bieten.
Wenn ein Entwickler eine Security Group ändern muss und das über IaC genauso schnell geht wie über die Console – oder sogar schneller – dann gibt's keinen Grund mehr für manuelle Eingriffe.
Das heißt:
Kurze Feedback-Loops in der Pipeline
Self-Service-Möglichkeiten über gut dokumentierte IaC-Module
Klare Prozesse für Notfälle
Gleichzeitig brauchst du Transparenz: Automatische Drift-Detection, die täglich läuft und Reports generiert – nicht um Leute zu bestrafen, sondern um sichtbar zu machen, wo Probleme entstehen.
Wenn ein Team sieht, dass ihre manuellen Änderungen immer wieder Drift verursachen und Mehraufwand schaffen, ändert sich das Verhalten von selbst.
Für kritische Produktionsumgebungen würde ich technische Guardrails setzen: Eingeschränkte Console-Rechte, sodass Deployments nur über CI/CD möglich sind.
Aber das kommunizierst du als Sicherheitsnetz, nicht als Misstrauensvotum.
Die Kultur entsteht, wenn Teams verstehen, dass IaC sie schneller macht, nicht langsamer.
IaC ist nicht das Problem. Die Art, wie wir es einsetzen, ist das Problem.
Automation multipliziert Effizienz. Aber sie multipliziert auch Fehler.
Die Lösung liegt nicht darin, langsamer zu werden. Sondern darin, Security von Anfang an einzubauen.
Secrets-Scanning. Policy-as-Code. Drift-Detection. Remote State Management. Observability mit Datenschutz.
Keine dieser Maßnahmen ist komplex. Aber jede einzelne verhindert die Blindstellen, die aus Automation entstehen.
Der IaC-Markt wächst von 0,8 Milliarden Dollar (2022) auf 2,3 Milliarden Dollar (2027). Das sind 24% jährliches Wachstum.
Die Frage ist nicht, ob du IaC nutzt. Sondern ob du es sicher nutzt.
Fang heute an. Mit einem Tool. Mit einem Check. Mit einem Prozess.
Bevor das "später" nie kommt.