Bedrohungen im Bauplan: Threat Modeling für Infrastructure as Code

Wer ein Haus baut, schaut sich zuerst den Bauplan genau an, bevor die ersten Mauern hochgezogen werden. Niemand will nachträglich feststellen, dass das Fundament wackelt oder die Tür direkt in eine Wand führt. Mit Infrastructure as Code ist es ähnlich: Schon eine kleine Fehlkonfiguration, wie etwa ein offener Port hier oder ein zu weit gefasster Datenbankzugriff dort, kann später zum Backdoor für Angreifer:innen werden.

Threat Modeling ist dabei der Sicherheitsbauplan. Es zeigt, wo Schwachstellen liegen könnten: Wo könnte ein:e Einbrecher:in eindringen? Ist die Tür sicher genug? Gibt es offene Fenster? Es schafft Transparenz über mögliche Risiken, noch bevor das „Haus“, also die Cloud-Infrastruktur, steht. So entstehen stabile und sichere Umgebungen, in denen Sicherheit nicht erst nachträglich angebaut wird, sondern von Anfang an Teil des Fundaments ist.

Besondere Sicherheitsherausforderungen von IaC

Während die klassische Softwareentwicklung sich meist auf User-Interaktionen und Anwendungslogik konzentriert, beschreibt Infrastructure as Code die gesamte technische Basis, wie Netzwerke, Zugriffsrechte oder Cloud-Dienste. Eine einzelne Codezeile entscheidet plötzlich darüber, ob eine Datenbank öffentlich zugänglich oder korrekt abgesichert ist. Fehlerhafte Konfigurationen verbreiten sich nicht mehr schleichend, sondern können mit einem einzigen terraform apply oder kubectl apply sofort zahlreiche Systeme betreffen. Aus einer kleinen Unachtsamkeit kann schnell eine flächendeckende Sicherheitslücke werden.

Hinzu kommen versteckte Abhängigkeiten zwischen Ressourcen: IaC-Templates koppeln viele Dienste und Konfigurationen – oft implizit und schwer nachvollziehbar. Schon eine kleine Anpassung an einer Security-Group-Regel kann ungewollt ganze Serviceketten öffnen. Solche verdeckten Effekte überfordern klassische Code Reviews und erschweren auch Threat Modeling. Infrastructure as Code bringt spezifische Sicherheitsherausforderungen mit sich, die traditionelle Bedrohungsmodelle oft nicht vollständig abdecken.

API-Schlüssel, Zugangstoken oder Passwörter landen häufig unbeabsichtigt und in Klartext in IaC-Repos, Moduldateien oder CI/CD-Pipelines. Werden diese Secrets häufig über mehrere Systeme hinweg wiederverwendet oder liegen zu großzügig vergebene Identity- und Access-Management-Berechtigungen vor, können sich Angreifer:innen lateral bewegen und im schlimmsten Fall ganze Systemlandschaften übernehmen. Es ist besonders kritisch, wenn ein Modul mit übermäßigen Rechten mehrfach eingesetzt wird, da dadurch die Angriffsfläche vervielfacht wird. Das wird als „Secret Sprawl“ bezeichnet.

Sollten nach der automatisierten Bereitstellung per IaC manuelle Änderungen an der Infrastruktur vorgenommen werden, entstehen Diskrepanzen zwischen dem deklarativen Zustand der IaC-Definitionen und dem tatsächlichen Laufzeitzustand – ein Phänomen, das als „Configuration Drift“ bezeichnet wird. Dies öffnet neue Sicherheitslücken, die nicht durch eine Analyse der IaC-Templates ersichtlich werden. Auch die Nutzung öffentlicher Drittanbieter-IaC-Module oder -Templates birgt Gefahren, da veraltete oder unsichere Voreinstellungen unbemerkt in die Produktionsinfrastruktur gelangen können.

Viele IaC-Templates setzen aus Bequemlichkeit unsichere Standardkonfigurationen, die bei wiederholter Verwendung zu systematischen Sicherheitslücken führen. Manche IaC-Tools speichern sogar sensible Informationen wie Ressourcen-IDs oder Konfigurationsdaten in State-Files. Ich überlasse es euch, herauszufinden, was passiert, wenn diese Dateien exponiert werden.

Die Identifizierung dieser Bedrohungen ist nur der erste Schritt. Die eigentliche Herausforderung besteht darin, sie gezielt zu adressieren und die Infrastruktur von Anfang an sicher, transparent und auditierbar zu gestalten. Das gilt insbesondere bei Verwendung von modernen DevOps-Pipelines, da mithilfe von Continuous Delivery Änderungen an der Infrastruktur schnell und automatisiert ausgerollt werden können. Für Entwicklerteams ist das ein Produktivitätsgewinn, für Sicherheitsteams aber ein Albtraum. Je häufiger Rollouts stattfinden, desto schwieriger wird es, Bedrohungsanalysen rechtzeitig durchzuführen. Punktuelle Sicherheitsworkshops reichen in dieser Dynamik nicht aus [2].

Diese drei Dimensionen – Skalierung, Abhängigkeiten und Geschwindigkeit – erfordern ein Umdenken beim IaC Threat Modeling. Statt sporadischer Workshops muss Threat Modeling zu einem festen Bestandteil des DevOps-Lebenszyklus werden. Nur so ist es möglich, Bedrohungen direkt in den IaC Templates zu identifizieren. Tools und Automatisierungen helfen dabei, potenzielle Angriffsvektoren sichtbar zu machen, Prioritäten zu setzen und Risiken bereits beim Entwurf zu erkennen.

Shift-Left Security in IaC

Infrastructure as Code ist ein zentraler Bestandteil moderner DevOps-Prozesse. Allerdings wird in DevOps Sicherheit nicht fest verankert, wodurch sie oftmals erst am Ende des Entwicklungsprozesses berücksichtigt wird. DevSecOps erweitert DevOps dahingehend, dass Security nicht nachträglich, sondern von Anfang an in Prozesse, Systeme und Infrastruktur eingebettet wird. Security wird somit „nach links“ verschoben: Tests, Sicherheitsprüfungen und weitere Maßnahmen werden so früh wie möglich im Software Development Lifecycle (SDLC) angewendet. Auf diese Weise wird Sicherheit nicht als Hindernis, sondern als integraler Bestandteil des DevOps Workflows mit Automatisierung, klaren Prozessen und geteilter Verantwortung etabliert.

Führt man Sicherheitsprüfungen am Ende einer Pipeline durch, werden Schwachstellen häufig erst in bereits ausgerollten Umgebungen entdeckt, wodurch der Aufwand zur Behebung steigt oder womöglich diese Schwachstellen bereits von Angreifenden ausgenutzt wurden. Der Shift-Left-Ansatz kehrt dieses Vorgehen um: Statt nachträglicher, teurer Korrekturen wird Sicherheit bereits beim Schreiben von Terraform-Code, Ansible Playbooks oder Kubernetes Manifests berücksichtigt. Developer prüfen beim Erstellen von Templates, ob Richtlinien eingehalten werden. Auf diese Weise wird Security Teil des Codes selbst.

DevSecOps ist vor allem ein Kulturwandel. Sicherheit wird zur Teamaufgabe, Developer übernehmen mehr Verantwortung und Security Teams rücken näher an die Entwicklungspraxis. Gemeinsame Workshops und Trainings verteilen Wissen und Best Practices über Teams hinweg.

In IaC-Umgebungen ist Shift Left Security keine optionale Ergänzung, sondern eine Notwendigkeit. Fehlkonfigurationen, unsichtbare Abhängigkeiten und die Geschwindigkeit von Continuous Delivery erfordern, dass Sicherheit von Anfang an in den Prozess integriert wird.

Kontinuierliches Threat Modeling & Threat Modeling as Code

Was haben wir in der klassischen Softwareentwicklung gemacht? Zu Beginn eines Projekts haben wir uns in einem Workshop zusammengesetzt und einmalig ein Threat Model entworfen. Klingt vernünftig. Doch seit agilen Methoden, Microservices-Architekturen und Continuous-Delivery-Pipelines zum Standard geworden sind, reicht das nicht mehr aus. Mit jedem Commit, jedem neuen Container-Image und jeder aktualisierten Kubernetes-Konfiguration verändert sich die Angriffsfläche.

Genau deswegen ist kontinuierliches Threat Modeling gefragt. Sicherheitsmodelle dürfen nicht mehr nur Snapshots sein, sondern müssen sich mit dem Code weiterentwickeln. Das bedeutet, dass Bedrohungsanalysen in die CI/CD-Pipelines integriert werden müssen. Bei jedem Commit laufen dadurch nicht nur klassische Unit- oder Integrationstests, sondern auch Prüfungen gegen definierte Sicherheitsmodelle.

Ja, ich weiß, manuelles Threat Modeling ist aus mehreren Gründen schwierig. Gute Threat Models brauchen erfahrene Fachleute, die Angriffsvektoren aufdecken können. Systeme wachsen und ändern sich ständig. Jede Technologie und Abhängigkeit bringen neue Schwachstellen mit sich. Aufgrund der Vielzahl an Tools, Frameworks und Dokumentationsformen ist es schwierig, dabei konsistent zu bleiben.

Hier setzt die Idee der Automatisierung an. Software kann Systeme dynamisch darstellen, Abhängigkeiten prüfen und Regeln evaluieren. So wie Infrastruktur mit IaC definiert wird, lassen sich auch Bedrohungsszenarien, Annahmen und Risiken in JSON oder YAML abbilden, versionieren und validieren. Statt ein Diagramm manuell anzupassen, lebt das Modell direkt im Repository. Jede Änderung kann automatisiert geprüft werden, wodurch Threat Modeling nicht nur reproduzierbar, sondern auch skalierbar wird.

Man unterscheidet hier zwei Ansätze: Threat Modeling from Code und Threat Modeling with Code.

Bei Threat Modeling from Code werden Quelltext, Konfigurationen oder Infrastrukturdefinitionen analysiert, um ein Threat Model abzuleiten. Beispielsweise vergleichen Werkzeuge diese Eingabedateien mit bekannten Risiken oder Regeln und erzeugen Berichte über mögliche Schwachstellen und Bedrohungen. Es handelt sich also um einen interpretativen Ansatz, bei dem Code oder Konfigurationen selbst als Input für die Bedrohungsidentifikation dienen. Schwachstellen werden somit im Code erkannt.

Bei Threat Modeling with Code werden bestehende Systeme mit ihren Entitäten, Datenflüssen, Abhängigkeiten oder Ereignisfolgen in Code-Form beschrieben. Developer modellieren Systeme in Programmiersprachen oder in Architektur-Beschreibungssprachen (ADLs) wie AADL oder Acme. Diese Modelle können daraufhin interpretiert werden, um automatisiert Bedrohungen zu identifizieren. Schwachstellen werden somit mit Code erkannt.

Die Qualität der Ergebnisse hängt bei beiden Ansätzen stark von der Qualität des Inputs ab. Garbage In – Garbage Out. Wenn die Eingabedaten aber sauber sind und die Regeln valide, fallen zwei große Pain Points weg: Die Notwendigkeit hochspezialisierter Expertise und die manuelle Pflege von Systemmodellen.

Wenn man diese Ansätze mit modernen IaC- und DevOps-Praktiken kombiniert, entsteht das Konzept „Threat Modeling as Code“. Bedrohungsmodelle werden in maschinenlesbaren Formaten wie YAML oder JSON beschrieben, als Quellcode versioniert und können automatisch aus bestehendem Code abgeleitet werden. Diese Modelle lassen sich in CI/CD Pipelines integrieren. So wird Bedrohungsmodellierung kontinuierlich, automatisierbar und kollaborativ. Teams können, ähnlich wie bei Infrastructure as Code, konsistente Modelle gemeinsam pflegen und frühzeitig Sicherheitslücken erkennen. Bedrohungsmodelle sind Code.

Als logische Weiterentwicklung von Threat Modeling as Code entsteht Continuous Threat Modeling. Dieser moderne Ansatz für Threat Modeling basiert auf einigen zentralen Prinzipien:

1. Teamkenntnis schlägt Fremdwissen: Niemand kennt ein System so gut wie das eigene Produktteam.
2. Agil, zugänglich und praxisnah: Threat Modeling muss sich dem Workflow anpassen, zugänglich und agil sein.
3. Lernkurve in Echtzeit: Die Qualität der Analysen wächst mit der Erfahrung des Teams. Je mehr sich ein Team mit dem eigenen System und seinen Risiken auseinandersetzt, desto besser werden die Ergebnisse („increasing-returns learning curve“).
4. Modell und Realität müssen übereinstimmen: Das Threat Model muss immer den aktuellen Zustand des Systems widerspiegeln.
5. Kontinuierliche Verbesserung: Das heutige Modell soll besser sein als das von gestern. Kontinuierliches Lernen, Skalierbarkeit und Praxisnähe stehen im Vordergrund.
6. Nützlichkeit und Nutzen: Die gewonnenen Erkenntnisse müssen zum System passen und helfen, Risiken zu erkennen und zu beheben.

Mit diesen Prinzipien wird Threat Modeling zu einem kontinuierlichen, teamgetragenen Prozess, der IaC-Sicherheit von Anfang an gewährleistet und die Resilienz moderner Infrastrukturen nachhaltig stärkt. Produktteams übernehmen Verantwortung für das Threat Model, anstatt sich von externen Wissensträgern abhängig zu machen.

Gängige Threat-Modeling-Methoden im Kontext von IaC

Nicht alle Threat-Modeling-Methoden sind gleichermaßen für Infrastructure as Code geeignet. In der Praxis haben sich insbesondere zwei Ansätze bewährt: STRIDE und DREAD. Zusammen bieten sie ein pragmatisches, automationsfreundliches Fundament für IaC Threat Modeling.

Ein kleines Recap: was sind STRIDE und DREAD?

STRIDE steht für Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service und Elevation of Privilege. Diese Methodik hilft systematisch und rollenbasiert potenzielle Angriffsvektoren zu identifizieren. Im Kontext von IaC eignet sich STRIDE gut, weil sie auf unterschiedlichste Infrastrukturkomponenten (z. B. Storage, Netzwerk, Zugriffsmanagement) angewendet und in Policy-Definitionen übersetzt werden kann.

DREAD ist ein scoringbasiertes Framework, das Risiken nach Damage Potential, Reproducibility, Exploitability, Affected Users und Discoverability bewertet. IaC eignet sich insbesondere zur Priorisierung: Scores lassen sich automatisiert sammeln, in Dashboards visualisieren und in SLAs oder Runbooks überführen. Gerade in großen Multi-Cloud-Infrastrukturen hilft DREAD kritische Schwachstellen zu identifizieren und knappe Ressourcen effektiv zu verteilen.

Also, welche Methode passt zu IaC und warum? In IaC-typischen Szenarien haben wir meist eine Kombination: STRIDE liefert die strukturierte, qualitative Analyse und DREAD wandelt die Befunde in priorisierte, operationalisierbare Maßnahmen um. Kleine Teams starten deswegen häufig mit pragmatischen STRIDE Workshops auf Template oder Modulebene. Größere Organisationen ergänzen diese Basis durch DREAD Scoring und automatisierte Auswertungen in CI/CD Pipelines, um skalierbare und nachvollziehbare Prozessketten zu etablieren.

Beispiel für Threat Modelling mit IaC

Ich halte es für sinnvoll, ein einfaches Threat-Modeling-Beispiel mit IaC durchzuführen, um ein Gefühl für die Methoden zu bekommen. Unsere Beispielsystemarchitektur ist in der Azure Cloud bereitgestellt und mit Terraform definiert und konfiguriert. Die Methodik funktioniert aber für jede Cloud-Umgebung und jedes IaC Tool. Probiert es gerne aus!

Unsere Architektur umfasst die folgenden Komponenten:

• Resource Group: Container für alle Ressourcen
• Azure AD: Identitätsmanagement und Role-Based Access Control
• Azure DNS: Namensauflösung im Netzwerk
• Virtual Network (VNet): Virtuales Netzwerk mit zwei Subnetzen
  • App Subnet: Enthält die Application-VM
  • DB Subnet: Enthält die Datenbank
• Network Security Groups (NSG): Netzwerk‑Firewalls für App‑ und DB‑Subnetz
• Azure Load Balancer: Verteilung des HTTPS‑Traffics
• Virtual Machine (VM): Anwendungskomponente, die per HTTPS auf die DB zugreift
• Azure Database (z. B. PostgreSQL): Persistente Speicherung der Anwendungsdaten
• Managed Identity: Gewährleistet Zugriff auf die Datenbank über Azure AD
• DNS-Zonen und Records: Für Namensauflösung zwischen den Komponenten

Eine verallgemeinerte Architektur sieht also so aus:

Wir schauen jetzt unsere Terraform-Konfiguration an, definieren Trust Boundaries und wenden STRIDE und DREAD Methoden auf sie an. Data-Flow-Diagram wird in diesem Beispiel weggelassen, da wir schon wissen wie das funktioniert und für IaC das Prozess ist genau gleich. Hier ist ein Beispiel, wie das aussehen kann. Natürlich gibt es mehrere Trust Boundaries und Schwachstellen, aber wenn wir sie alle beschreiben, werden wir den ganzen Tag hier sein:

VNet-Subnets und Network Security Groups

STRIDE:

• Spoofing: Wenn externe Hosts das AppSubnetz erreichen können, ist Identitätsfälschung möglich.
• Tampering: Zu weit geöffnete NSG-Regeln erlauben Manipulation von Datenpaketen.
• Information Disclosure: Eine zu offene NSG erhöht das Risiko der Offenlegung sensibler Daten.

DREAD: Öffentlicher SSH-Zugang zur VM (NSG-Regel mit source_address_prefix = „*“, Port 22)

• Damage Potential: 8

Ein erfolgreicher SSH-Zugriff kann Root-Rechte auf der VM bedeuten und zur vollständigen Systemübernahme führen.

• Reproducibility: 10

Der offene SSH-Port ist leicht über Portscanning zu finden. Angriffe lassen sich beliebig oft wiederholen.

• Exploitability: 9

SSH ist weit verbreitet und es existieren automatisierte Exploits sowie Brute-Force-Tools, um ungesicherte SSH-Zugänge auszunutzen.

• Affected Users: 10

Alle auf der VM laufenden Nutzer und Dienste wären potenziell betroffen.

• Discoverability: 9

Port 22 ist der Standardport für SSH und daher einfach zu entdecken.

Score: 9,2 (Hoch)

Es macht natürlich viel Spaß, sowas manuell zu machen. Leider ist das Leben zu kurz und schlaue Menschen haben den Prozess mit Automatisierungstools viel schneller, einfacher und weniger fehleranfällig gemacht.

Tools und Best Practices

Es gibt viele Open-Source- und Enterprise-Tools, die IaC Threat Modeling vereinfachen. Einige Beispiele:

• threatcl: Eine Konfigurationssprache für Threat-Modeling-Workflows.
• TerraScan: Open-Source-Tool für die statische Codeanalyse von IaC. Es prüft Terraform-, Kubernetes- und CloudFormation-Konfigurationen auf Sicherheitslücken und Compliance-Verstöße.
• tfsec: Open-Source-Tool zur statischen Analyse von Terraform-Code. Es erkennt unsichere Konfigurationen, gefährliche Muster und fehlende Verschlüsselung.
• Checkov: Prüft anhand vordefinierter und benutzerdefinierter Regeln auf typische Fehlkonfigurationen. Unterstützt Terraform, AWS CloudFormation, Azure Resource Manager und Kubernetes-Manifeste.
• kube-review & kubeval: Tools speziell für Kubernetes, die Manifeste auf Richtlinienkonformität und strukturelle Schwächen scannen – gut geeignet für Microservices- und Container-Umgebungen.
• OWASP Threat Dragon: Ein umfassendes Threat-Modeling-Tool, das sich nicht nur für IaC eignet, sondern allgemein in DevSecOps-Prozessen nützlich ist.

Mehrere dieser Tools werden oft parallel genutzt, um unterschiedliche Aspekte, wie Cloud-Spezifikationen, Container und Rechteverwaltung abzudecken.

Bevor wir allerdings loslegen und die automatisierte Bedrohungsmodellierung in unsere CI/CD Pipeline integrieren, sollten wir einige Best Practices betrachten, die uns und unseren Teamkollegen das Leben erheblich erleichtern. Techvzero schlägt folgendes Framework zur Integration von Threat Modeling in IaC Workflows vor:

• Abgrenzung und Inventarisierung von Assets: Klare IaC-Grenzen definieren, Modulgrenzen als Vertrauenszonen betrachten, Entwicklungs-, Test- und Produktionsumgebungen segmentieren und kritische Assets (Cloud-Konten, IAM-Entities, CI/CD-Infrastruktur) erfassen.
• Sensiblen Datenfluss identifizieren: Regulierte Daten, geistiges Eigentum und Betriebsgeheimnisse im Infrastruktur-Setup erkennen und deren Fluss dokumentieren.
• Threat-Modeling-Methoden anwenden: STRIDE zur Identifikation technischer Risiken nutzen; DREAD zur Priorisierung (Damage, Reproducibility, Exploitability, Affected Users, Discoverability). PASTA, welches in diesem Artikel nicht erwähnt wurde, verbindet Bedrohungsanalyse mit Geschäftszielen und wird meist ergänzend eingesetzt.
• Mitigation als Code umsetzen: Sicherheitsrichtlinien in Infrastruktur-Templates einbetten, sichere, wiederverwendbare Module verwenden und Sicherheitsscanner (z. B. Checkov, Terrascan) früh in die Pipeline integrieren.
• Sicherheitskontrollen über den gesamten IaC-Lebenszyklus: Pre-Commit-Hooks und IDE-Plugins für frühe Erkennung, CI/CD-Pipeline-Quality-Gates mit statischer Analyse und Policy-Validierung sowie Post-Deployment-Monitoring, dynamische Tests und Compliance-Überwachung.

Denkanstöße

Das waren viele Informationen. Anstelle des Fazits nun noch ein paar Denkanstöße, was wir als Plattform Engineers und Developers tun können, um Systeme besser abzusichern:

• Sicherheitsüberprüfungen bereits während der Entwicklung durchführen, nicht erst im Review.
• Alle Stakeholder einbeziehen: von DevOps über Entwicklung bis hin zu Security. Gemeinsame Workshops und offene Kommunikation sind entscheidend.
• Prüfungen und Policy-Checks bei jeder Code-Änderung automatisiert ausführen.
• Sicherheits-Policies nicht als Einmalaufgabe behandeln, sondern sie regelmäßig überprüfen und anpassen.
• CI/CD-Pipeline so konfigurieren, dass instabile oder unsichere IaC-Änderungen automatisch das Deployment blockieren, bis die Risiken adressiert sind.
• Klare Richtlinien, Versionierung und regelmäßige Audits etablieren – so wird Sicherheit ein dauerhafter Prozess.

Und das war’s. Threat Modeling für Infrastructure as Code endet nicht bei Terraform-Konfigurationsdateien oder Kubernetes-Manifesten. Das Thema umfasst viele unterschiedliche Methoden und Einblicke in DevSecOps und lässt sich jederzeit erweitern. Viel Erfolg beim Überzeugen des Product Owners, dass Threat Modeling für euer Projekt wichtig ist!

Dieser Artikel erschien zuerst im Java Magazin 1.2026.