{"id":65809,"date":"2026-02-06T10:59:29","date_gmt":"2026-02-06T09:59:29","guid":{"rendered":"https:\/\/www.inovex.de\/?p=65809"},"modified":"2026-02-06T11:33:58","modified_gmt":"2026-02-06T10:33:58","slug":"bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code","status":"publish","type":"post","link":"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/","title":{"rendered":"Bedrohungen im Bauplan: Threat Modeling f\u00fcr Infrastructure as Code"},"content":{"rendered":"<p>Wer ein Haus baut, schaut sich zuerst den Bauplan genau an, bevor die ersten Mauern hochgezogen werden. Niemand will nachtr\u00e4glich feststellen, dass das Fundament wackelt oder die T\u00fcr direkt in eine Wand f\u00fchrt. Mit Infrastructure as Code ist es \u00e4hnlich: Schon eine kleine Fehlkonfiguration, wie etwa ein offener Port hier oder ein zu weit gefasster Datenbankzugriff dort, kann sp\u00e4ter zum Backdoor f\u00fcr Angreifer:innen werden.<\/p>\n<p>Threat Modeling ist dabei der Sicherheitsbauplan. Es zeigt, wo Schwachstellen liegen k\u00f6nnten: Wo k\u00f6nnte ein:e Einbrecher:in eindringen? Ist die T\u00fcr sicher genug? Gibt es offene Fenster? Es schafft Transparenz \u00fcber m\u00f6gliche Risiken, noch bevor das \u201eHaus\u201c, also die Cloud-Infrastruktur, steht. So entstehen stabile und sichere Umgebungen, in denen Sicherheit nicht erst nachtr\u00e4glich angebaut wird, sondern von Anfang an Teil des Fundaments ist.<!--more--><\/p>\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_79_2 counter-hierarchy ez-toc-counter ez-toc-custom ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\"><p class=\"ez-toc-title\" style=\"cursor:inherit\"><\/p>\n<\/div><nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/#Besondere-Sicherheitsherausforderungen-von-IaC\" >Besondere Sicherheitsherausforderungen von IaC<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/#Shift-Left-Security-in-IaC\" >Shift-Left Security in IaC<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/#Kontinuierliches-Threat-Modeling-Threat-Modeling-as-Code\" >Kontinuierliches Threat Modeling &amp; Threat Modeling as Code<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/#Gaengige-Threat-Modeling-Methoden-im-Kontext-von-IaC\" >G\u00e4ngige Threat-Modeling-Methoden im Kontext von IaC<\/a><ul class='ez-toc-list-level-3' ><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/#Ein-kleines-Recap-was-sind-STRIDE-und-DREAD\" >Ein kleines Recap: was sind STRIDE und DREAD?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/#Beispiel-fuer-Threat-Modelling-mit-IaC\" >Beispiel f\u00fcr Threat Modelling mit IaC<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/#Tools-und-Best-Practices\" >Tools und Best Practices<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/#Denkanstoesse\" >Denkanst\u00f6\u00dfe<\/a><\/li><\/ul><\/nav><\/div>\n<h2><span class=\"ez-toc-section\" id=\"Besondere-Sicherheitsherausforderungen-von-IaC\"><\/span>Besondere Sicherheitsherausforderungen von IaC<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>W\u00e4hrend 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\u00f6tzlich dar\u00fcber, ob eine Datenbank \u00f6ffentlich zug\u00e4nglich oder korrekt abgesichert ist. Fehlerhafte Konfigurationen verbreiten sich nicht mehr schleichend, sondern k\u00f6nnen mit einem einzigen terraform apply oder kubectl apply sofort zahlreiche Systeme betreffen. Aus einer kleinen Unachtsamkeit kann schnell eine fl\u00e4chendeckende Sicherheitsl\u00fccke werden.<\/p>\n<p>Hinzu kommen versteckte Abh\u00e4ngigkeiten zwischen Ressourcen: IaC-Templates koppeln viele Dienste und Konfigurationen \u2013 oft implizit und schwer nachvollziehbar. Schon eine kleine Anpassung an einer Security-Group-Regel kann ungewollt ganze Serviceketten \u00f6ffnen. Solche verdeckten Effekte \u00fcberfordern klassische Code Reviews und erschweren auch <a href=\"https:\/\/techvzero.com\/iac-threat-modeling-best-practices-guide\/\">Threat Modeling<\/a>. Infrastructure as Code bringt spezifische Sicherheitsherausforderungen mit sich, die traditionelle Bedrohungsmodelle oft nicht vollst\u00e4ndig abdecken.<\/p>\n<p>API-Schl\u00fcssel, Zugangstoken oder Passw\u00f6rter landen h\u00e4ufig unbeabsichtigt und in Klartext in IaC-Repos, Moduldateien oder CI\/CD-Pipelines. Werden diese Secrets h\u00e4ufig \u00fcber mehrere Systeme hinweg wiederverwendet oder liegen zu gro\u00dfz\u00fcgig vergebene Identity- und Access-Management-Berechtigungen vor, k\u00f6nnen sich Angreifer:innen lateral bewegen und im schlimmsten Fall ganze Systemlandschaften \u00fcbernehmen. Es ist besonders kritisch, wenn ein Modul mit \u00fcberm\u00e4\u00dfigen Rechten mehrfach eingesetzt wird, da dadurch die Angriffsfl\u00e4che vervielfacht wird. Das wird als \u201eSecret Sprawl\u201c bezeichnet.<\/p>\n<p>Sollten nach der automatisierten Bereitstellung per IaC manuelle \u00c4nderungen an der Infrastruktur vorgenommen werden, entstehen Diskrepanzen zwischen dem deklarativen Zustand der IaC-Definitionen und dem tats\u00e4chlichen Laufzeitzustand &#8211; ein Ph\u00e4nomen, das als \u201eConfiguration Drift\u201c bezeichnet wird. Dies \u00f6ffnet neue Sicherheitsl\u00fccken, die nicht durch eine Analyse der IaC-Templates ersichtlich werden. Auch die Nutzung \u00f6ffentlicher Drittanbieter-IaC-Module oder -Templates birgt Gefahren, da veraltete oder unsichere Voreinstellungen unbemerkt in die Produktionsinfrastruktur gelangen k\u00f6nnen.<\/p>\n<p>Viele IaC-Templates setzen aus Bequemlichkeit unsichere Standardkonfigurationen, die bei wiederholter Verwendung zu systematischen Sicherheitsl\u00fccken f\u00fchren. Manche IaC-Tools speichern sogar sensible Informationen wie Ressourcen-IDs oder Konfigurationsdaten in State-Files. Ich \u00fcberlasse es euch, herauszufinden, was passiert, wenn diese Dateien exponiert werden.<\/p>\n<p>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 \u00c4nderungen an der Infrastruktur schnell und automatisiert ausgerollt werden k\u00f6nnen. F\u00fcr Entwicklerteams ist das ein Produktivit\u00e4tsgewinn, f\u00fcr Sicherheitsteams aber ein Albtraum. Je h\u00e4ufiger Rollouts stattfinden, desto schwieriger wird es, Bedrohungsanalysen rechtzeitig durchzuf\u00fchren. Punktuelle Sicherheitsworkshops reichen in dieser Dynamik nicht aus [2].<\/p>\n<p>Diese drei Dimensionen \u2013 Skalierung, Abh\u00e4ngigkeiten und Geschwindigkeit \u2013 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\u00f6glich, Bedrohungen direkt in den IaC Templates zu identifizieren. Tools und Automatisierungen helfen dabei, potenzielle Angriffsvektoren sichtbar zu machen, Priorit\u00e4ten zu setzen und Risiken bereits beim Entwurf zu erkennen.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Shift-Left-Security-in-IaC\"><\/span>Shift-Left Security in IaC<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>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\u00fccksichtigt wird. DevSecOps erweitert DevOps dahingehend, dass Security nicht nachtr\u00e4glich, sondern von Anfang an in Prozesse, Systeme und Infrastruktur eingebettet wird. Security wird somit \u201enach links\u201c verschoben: Tests, Sicherheitspr\u00fcfungen und weitere Ma\u00dfnahmen werden so fr\u00fch wie m\u00f6glich 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.<\/p>\n<p>F\u00fchrt man Sicherheitspr\u00fcfungen am Ende einer Pipeline durch, werden Schwachstellen h\u00e4ufig erst in bereits ausgerollten Umgebungen entdeckt, wodurch der Aufwand zur Behebung steigt oder wom\u00f6glich diese Schwachstellen bereits von Angreifenden ausgenutzt wurden. Der Shift-Left-Ansatz kehrt dieses Vorgehen um: Statt nachtr\u00e4glicher, teurer Korrekturen wird Sicherheit bereits beim Schreiben von Terraform-Code, Ansible Playbooks oder Kubernetes Manifests ber\u00fccksichtigt. Developer pr\u00fcfen beim Erstellen von Templates, ob Richtlinien eingehalten werden. Auf diese Weise wird Security Teil des Codes selbst.<\/p>\n<p>DevSecOps ist vor allem ein Kulturwandel. Sicherheit wird zur Teamaufgabe, Developer \u00fcbernehmen mehr Verantwortung und Security Teams r\u00fccken n\u00e4her an die Entwicklungspraxis. Gemeinsame Workshops und Trainings verteilen Wissen und Best Practices \u00fcber Teams hinweg.<\/p>\n<p>In IaC-Umgebungen ist Shift Left Security keine optionale Erg\u00e4nzung, sondern eine Notwendigkeit. Fehlkonfigurationen, unsichtbare Abh\u00e4ngigkeiten und die Geschwindigkeit von Continuous Delivery erfordern, dass Sicherheit von Anfang an in den Prozess integriert wird.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Kontinuierliches-Threat-Modeling-Threat-Modeling-as-Code\"><\/span><span lang=\"en-US\">Kontinuierliches Threat Modeling &amp; Threat Modeling as Code<\/span><span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>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\u00fcnftig. 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\u00e4ndert sich die Angriffsfl\u00e4che.<\/p>\n<p>Genau deswegen ist kontinuierliches Threat Modeling gefragt. Sicherheitsmodelle d\u00fcrfen nicht mehr nur Snapshots sein, sondern <a href=\"https:\/\/dev.to\/vaib\/continuous-threat-modeling-and-threat-modeling-as-code-tmasc-43c8\">m\u00fcssen sich mit dem Code weiterentwickeln<\/a>. Das bedeutet, dass Bedrohungsanalysen in die CI\/CD-Pipelines integriert werden m\u00fcssen. Bei jedem Commit laufen dadurch nicht nur klassische Unit- oder Integrationstests, sondern auch Pr\u00fcfungen gegen definierte Sicherheitsmodelle.<\/p>\n<p>Ja, ich wei\u00df, manuelles Threat Modeling ist aus mehreren Gr\u00fcnden schwierig. Gute Threat Models brauchen erfahrene Fachleute, die Angriffsvektoren aufdecken k\u00f6nnen. Systeme wachsen und \u00e4ndern sich st\u00e4ndig. Jede Technologie und Abh\u00e4ngigkeit bringen neue Schwachstellen mit sich. Aufgrund der Vielzahl an Tools, Frameworks und Dokumentationsformen ist es schwierig, dabei konsistent zu bleiben.<\/p>\n<p>Hier setzt die Idee der Automatisierung an. Software kann Systeme dynamisch darstellen, Abh\u00e4ngigkeiten pr\u00fcfen und Regeln evaluieren. So wie Infrastruktur mit IaC definiert wird, lassen sich auch Bedrohungsszenarien, Annahmen und Risiken in <a href=\"https:\/\/www.hashicorp.com\/en\/resources\/shifting-threat-modeling-left-automated-threat-modeling-using-terraform\">JSON oder YAML abbilden, versionieren und validieren<\/a>. Statt ein Diagramm manuell anzupassen, lebt das Modell direkt im Repository. Jede \u00c4nderung kann automatisiert gepr\u00fcft werden, wodurch Threat Modeling nicht nur reproduzierbar, sondern auch skalierbar wird.<\/p>\n<p><strong>Man unterscheidet hier zwei Ans\u00e4tze: Threat Modeling from Code und Threat Modeling with Code.<\/strong><\/p>\n<p>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 \u00fcber m\u00f6gliche Schwachstellen und Bedrohungen. Es handelt sich also um einen interpretativen Ansatz, bei dem Code oder Konfigurationen selbst als Input f\u00fcr die Bedrohungsidentifikation dienen. Schwachstellen werden somit im Code erkannt.<\/p>\n<p>Bei Threat Modeling with Code werden bestehende Systeme mit ihren Entit\u00e4ten, Datenfl\u00fcssen, Abh\u00e4ngigkeiten oder Ereignisfolgen in Code-Form beschrieben. Developer modellieren Systeme in Programmiersprachen oder in Architektur-Beschreibungssprachen (ADLs) wie AADL oder Acme. Diese Modelle k\u00f6nnen daraufhin interpretiert werden, um automatisiert Bedrohungen zu identifizieren. Schwachstellen werden somit mit Code erkannt.<\/p>\n<p>Die Qualit\u00e4t der Ergebnisse h\u00e4ngt bei beiden Ans\u00e4tzen stark von der Qualit\u00e4t des Inputs ab. Garbage In &#8211; Garbage Out. Wenn die Eingabedaten aber sauber sind und die Regeln valide, fallen zwei gro\u00dfe Pain Points weg: Die Notwendigkeit hochspezialisierter Expertise und die manuelle Pflege von Systemmodellen.<\/p>\n<p>Wenn man diese Ans\u00e4tze mit modernen IaC- und DevOps-Praktiken kombiniert, entsteht das Konzept \u201eThreat Modeling as Code\u201c. Bedrohungsmodelle werden in maschinenlesbaren Formaten wie YAML oder JSON beschrieben, als Quellcode versioniert und k\u00f6nnen automatisch aus bestehendem Code abgeleitet werden. Diese Modelle lassen sich in CI\/CD Pipelines integrieren. So wird Bedrohungsmodellierung kontinuierlich, automatisierbar und kollaborativ. Teams k\u00f6nnen, \u00e4hnlich wie bei Infrastructure as Code, konsistente Modelle gemeinsam pflegen und fr\u00fchzeitig Sicherheitsl\u00fccken erkennen. Bedrohungsmodelle sind Code.<\/p>\n<p>Als logische Weiterentwicklung von Threat Modeling as Code entsteht Continuous Threat Modeling. Dieser moderne Ansatz f\u00fcr Threat Modeling basiert auf einigen zentralen Prinzipien:<\/p>\n<ol>\n<li>Teamkenntnis schl\u00e4gt Fremdwissen: Niemand kennt ein System so gut wie das eigene Produktteam.<\/li>\n<li>Agil, zug\u00e4nglich und praxisnah: Threat Modeling muss sich dem Workflow anpassen, zug\u00e4nglich und agil sein.<\/li>\n<li>Lernkurve in Echtzeit: Die Qualit\u00e4t der Analysen w\u00e4chst mit der Erfahrung des Teams. Je mehr sich ein Team mit dem eigenen System und seinen Risiken auseinandersetzt, desto besser werden die Ergebnisse (\u201eincreasing-returns learning curve\u201c).<\/li>\n<li>Modell und Realit\u00e4t m\u00fcssen \u00fcbereinstimmen: Das Threat Model muss immer den aktuellen Zustand des Systems widerspiegeln.<\/li>\n<li>Kontinuierliche Verbesserung: Das heutige Modell soll besser sein als das von gestern. Kontinuierliches Lernen, Skalierbarkeit und Praxisn\u00e4he stehen im Vordergrund.<\/li>\n<li>N\u00fctzlichkeit und Nutzen: Die gewonnenen Erkenntnisse m\u00fcssen zum System passen und helfen, Risiken zu erkennen und zu beheben.<\/li>\n<\/ol>\n<p>Mit diesen Prinzipien wird Threat Modeling zu einem kontinuierlichen, teamgetragenen Prozess, der IaC-Sicherheit von Anfang an gew\u00e4hrleistet und die Resilienz moderner Infrastrukturen nachhaltig st\u00e4rkt. Produktteams \u00fcbernehmen Verantwortung f\u00fcr das Threat Model, anstatt sich von externen Wissenstr\u00e4gern abh\u00e4ngig zu machen.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Gaengige-Threat-Modeling-Methoden-im-Kontext-von-IaC\"><\/span>G\u00e4ngige Threat-Modeling-Methoden im Kontext von IaC<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Nicht alle Threat-Modeling-Methoden sind gleicherma\u00dfen f\u00fcr Infrastructure as Code geeignet. In der Praxis haben sich insbesondere zwei Ans\u00e4tze bew\u00e4hrt: STRIDE und DREAD. Zusammen bieten sie ein pragmatisches, automationsfreundliches Fundament f\u00fcr IaC Threat Modeling.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"Ein-kleines-Recap-was-sind-STRIDE-und-DREAD\"><\/span>Ein kleines Recap: was sind STRIDE und DREAD?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>STRIDE steht f\u00fcr 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 \u00fcbersetzt werden kann.<\/p>\n<p>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 \u00fcberf\u00fchren. Gerade in gro\u00dfen Multi-Cloud-Infrastrukturen hilft DREAD kritische Schwachstellen zu identifizieren und knappe Ressourcen effektiv zu verteilen.<\/p>\n<p>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\u00dfnahmen um. Kleine Teams starten deswegen h\u00e4ufig mit pragmatischen STRIDE Workshops auf Template oder Modulebene. Gr\u00f6\u00dfere Organisationen erg\u00e4nzen diese Basis durch DREAD Scoring und automatisierte Auswertungen in CI\/CD Pipelines, um skalierbare und nachvollziehbare Prozessketten zu etablieren.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"Beispiel-fuer-Threat-Modelling-mit-IaC\"><\/span>Beispiel f\u00fcr Threat Modelling mit IaC<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>Ich halte es f\u00fcr sinnvoll, ein einfaches Threat-Modeling-Beispiel mit IaC durchzuf\u00fchren, um ein Gef\u00fchl f\u00fcr die Methoden zu bekommen. Unsere Beispielsystemarchitektur ist in der Azure Cloud bereitgestellt und mit Terraform definiert und konfiguriert. Die Methodik funktioniert aber f\u00fcr jede Cloud-Umgebung und jedes IaC Tool. Probiert es gerne aus!<\/p>\n<p>Unsere Architektur umfasst die folgenden Komponenten:<\/p>\n<ul>\n<li><span lang=\"en-US\">Resource Group<\/span><span lang=\"en-US\">: Container f\u00fcr alle Ressourcen<\/span><\/li>\n<li><span lang=\"en-US\">Azure AD<\/span><span lang=\"en-US\">: Identit\u00e4tsmanagement und Role-Based Access Control<\/span><\/li>\n<li>Azure DNS: Namensaufl\u00f6sung im Netzwerk<\/li>\n<li>Virtual Network (VNet): Virtuales Netzwerk mit zwei Subnetzen\n<ul>\n<li>App Subnet: Enth\u00e4lt die Application-VM<\/li>\n<li>DB Subnet: Enth\u00e4lt die Datenbank<\/li>\n<\/ul>\n<\/li>\n<li><span lang=\"en-US\">Network Security Groups (NSG)<\/span><span lang=\"en-US\">: Netzwerk\u2011Firewalls f\u00fcr App\u2011 und DB\u2011Subnetz<\/span><\/li>\n<li><span lang=\"en-US\">Azure Load Balancer<\/span><span lang=\"en-US\">: Verteilung des HTTPS\u2011Traffics<\/span><\/li>\n<li>Virtual Machine (VM): Anwendungskomponente, die per HTTPS auf die DB zugreift<\/li>\n<li>Azure Database (z.\u202fB. PostgreSQL): Persistente Speicherung der Anwendungsdaten<\/li>\n<li>Managed Identity: Gew\u00e4hrleistet Zugriff auf die Datenbank \u00fcber Azure AD<\/li>\n<li>DNS-Zonen und Records: F\u00fcr Namensaufl\u00f6sung zwischen den Komponenten<\/li>\n<\/ul>\n<p><span id=\"Frame1\" dir=\"ltr\"><\/span>Eine verallgemeinerte Architektur sieht also so aus:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-65810 aligncenter\" src=\"https:\/\/www.inovex.de\/wp-content\/uploads\/azure.drawio.png\" alt=\"\" width=\"1542\" height=\"702\" srcset=\"https:\/\/www.inovex.de\/wp-content\/uploads\/azure.drawio.png 1542w, https:\/\/www.inovex.de\/wp-content\/uploads\/azure.drawio-300x137.png 300w, https:\/\/www.inovex.de\/wp-content\/uploads\/azure.drawio-1024x466.png 1024w, https:\/\/www.inovex.de\/wp-content\/uploads\/azure.drawio-768x350.png 768w, https:\/\/www.inovex.de\/wp-content\/uploads\/azure.drawio-1536x699.png 1536w, https:\/\/www.inovex.de\/wp-content\/uploads\/azure.drawio-400x182.png 400w, https:\/\/www.inovex.de\/wp-content\/uploads\/azure.drawio-360x164.png 360w\" sizes=\"auto, (max-width: 1542px) 100vw, 1542px\" \/><\/p>\n<p>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\u00fcr IaC das Prozess ist genau gleich. Hier ist ein Beispiel, wie das aussehen kann. Nat\u00fcrlich gibt es mehrere Trust Boundaries und Schwachstellen, aber wenn wir sie alle beschreiben, werden wir den ganzen Tag hier sein:<\/p>\n<p>VNet-Subnets und Network Security Groups<\/p>\n<pre>resource \"azurerm_subnet\" \"app_subnet\" {\r\n...\r\n}\r\nresource \"azurerm_subnet\" \"db_subnet\" {\r\n...\r\n}\r\nresource \"azurerm_network_security_group\" \"app_nsg\" {\r\n    security_rule {\r\n        name = \"HTTPS\"\r\n        source_address_prefix = \"*\" \r\n    }\r\n}\r\nresource \"azurerm_network_security_group\" \"db_nsg\" {\r\n    security_rule {\r\n        name = \"Internal-HTTPS\"\r\n        source_address_prefix = azurerm_subnet.app_subnet.address_prefixes[0]\r\n    }\r\n}<\/pre>\n<p>STRIDE:<\/p>\n<ul>\n<li>Spoofing: Wenn externe Hosts das AppSubnetz erreichen k\u00f6nnen, ist Identit\u00e4tsf\u00e4lschung m\u00f6glich.<\/li>\n<li>Tampering: Zu weit ge\u00f6ffnete NSG-Regeln erlauben Manipulation von Datenpaketen.<\/li>\n<li>Information Disclosure: Eine zu offene NSG erh\u00f6ht das Risiko der Offenlegung sensibler Daten.<\/li>\n<\/ul>\n<p>DREAD: \u00d6ffentlicher SSH-Zugang zur VM (NSG-Regel mit source_address_prefix = &#8222;*&#8220;, Port 22)<\/p>\n<ul>\n<li>Damage Potential: 8<\/li>\n<\/ul>\n<p>Ein erfolgreicher SSH-Zugriff kann Root-Rechte auf der VM bedeuten und zur vollst\u00e4ndigen System\u00fcbernahme f\u00fchren.<\/p>\n<ul>\n<li>Reproducibility: 10<\/li>\n<\/ul>\n<p>Der offene SSH-Port ist leicht \u00fcber Portscanning zu finden. Angriffe lassen sich beliebig oft wiederholen.<\/p>\n<ul>\n<li>Exploitability: 9<\/li>\n<\/ul>\n<p>SSH ist weit verbreitet und es existieren automatisierte Exploits sowie Brute-Force-Tools, um ungesicherte SSH-Zug\u00e4nge auszunutzen.<\/p>\n<ul>\n<li>Affected Users: 10<\/li>\n<\/ul>\n<p>Alle auf der VM laufenden Nutzer und Dienste w\u00e4ren potenziell betroffen.<\/p>\n<ul>\n<li>Discoverability: 9<\/li>\n<\/ul>\n<p>Port 22 ist der Standardport f\u00fcr SSH und daher einfach zu entdecken.<\/p>\n<p>Score: 9,2 (Hoch)<\/p>\n<p>Es macht nat\u00fcrlich viel Spa\u00df, sowas manuell zu machen. Leider ist das Leben zu kurz und schlaue Menschen haben den Prozess mit Automatisierungstools viel schneller, einfacher und weniger fehleranf\u00e4llig gemacht.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"Tools-und-Best-Practices\"><\/span>Tools und Best Practices<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>Es gibt viele Open-Source- und Enterprise-Tools, die IaC Threat Modeling vereinfachen. Einige Beispiele:<\/p>\n<ul>\n<li><a href=\"https:\/\/threatcl.github.io\">threatcl<\/a>: Eine Konfigurationssprache f\u00fcr Threat-Modeling-Workflows.<\/li>\n<li><a href=\"https:\/\/runterrascan.io\">TerraScan<\/a>: Open-Source-Tool f\u00fcr die statische Codeanalyse von IaC. Es pr\u00fcft Terraform-, Kubernetes- und CloudFormation-Konfigurationen auf Sicherheitsl\u00fccken und Compliance-Verst\u00f6\u00dfe.<\/li>\n<li><a href=\"https:\/\/aquasecurity.github.io\/tfsec\/v1.20.0\/\">tfsec<\/a>: Open-Source-Tool zur statischen Analyse von Terraform-Code. Es erkennt unsichere Konfigurationen, gef\u00e4hrliche Muster und fehlende Verschl\u00fcsselung.<\/li>\n<li><a href=\"https:\/\/www.checkov.io\">Checkov<\/a>: Pr\u00fcft anhand vordefinierter und benutzerdefinierter Regeln auf typische Fehlkonfigurationen. Unterst\u00fctzt Terraform, AWS CloudFormation, Azure Resource Manager und Kubernetes-Manifeste.<\/li>\n<li><a href=\"https:\/\/github.com\/anderseknert\/kube-review\">kube-review<\/a> &amp; <a href=\"https:\/\/github.com\/instrumenta\/kubeval\">kubeval<\/a>: Tools speziell f\u00fcr Kubernetes, die Manifeste auf Richtlinienkonformit\u00e4t und strukturelle Schw\u00e4chen scannen \u2013 gut geeignet f\u00fcr Microservices- und Container-Umgebungen.<\/li>\n<li><a href=\"https:\/\/owasp.org\/www-project-threat-dragon\/\">OWASP Threat Dragon<\/a>: Ein umfassendes Threat-Modeling-Tool, das sich nicht nur f\u00fcr IaC eignet, sondern allgemein in DevSecOps-Prozessen n\u00fctzlich ist.<\/li>\n<\/ul>\n<p>Mehrere dieser Tools werden oft parallel genutzt, um unterschiedliche Aspekte, wie Cloud-Spezifikationen, Container und Rechteverwaltung abzudecken.<\/p>\n<p>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\u00e4gt folgendes Framework zur Integration von Threat Modeling in IaC Workflows vor:<\/p>\n<ul>\n<li>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.<\/li>\n<li>Sensiblen Datenfluss identifizieren: Regulierte Daten, geistiges Eigentum und Betriebsgeheimnisse im Infrastruktur-Setup erkennen und deren Fluss dokumentieren.<\/li>\n<li>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\u00e4hnt wurde, verbindet Bedrohungsanalyse mit Gesch\u00e4ftszielen und wird meist erg\u00e4nzend eingesetzt.<\/li>\n<li>Mitigation als Code umsetzen: Sicherheitsrichtlinien in Infrastruktur-Templates einbetten, sichere, wiederverwendbare Module verwenden und Sicherheitsscanner (z. B. Checkov, Terrascan) fr\u00fch in die Pipeline integrieren.<\/li>\n<li>Sicherheitskontrollen \u00fcber den gesamten IaC-Lebenszyklus: Pre-Commit-Hooks und IDE-Plugins f\u00fcr fr\u00fche Erkennung, CI\/CD-Pipeline-Quality-Gates mit statischer Analyse und Policy-Validierung sowie Post-Deployment-Monitoring, dynamische Tests und Compliance-\u00dcberwachung.<\/li>\n<\/ul>\n<h2><span class=\"ez-toc-section\" id=\"Denkanstoesse\"><\/span>Denkanst\u00f6\u00dfe<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Das waren viele Informationen. Anstelle des Fazits nun noch ein paar Denkanst\u00f6\u00dfe, was wir als Plattform Engineers und Developers tun k\u00f6nnen, um Systeme besser abzusichern:<\/p>\n<ul>\n<li>Sicherheits\u00fcberpr\u00fcfungen bereits w\u00e4hrend der Entwicklung durchf\u00fchren, nicht erst im Review.<\/li>\n<li>Alle Stakeholder einbeziehen: von DevOps \u00fcber Entwicklung bis hin zu Security. Gemeinsame Workshops und offene Kommunikation sind entscheidend.<\/li>\n<li>Pr\u00fcfungen und Policy-Checks bei jeder Code-\u00c4nderung automatisiert ausf\u00fchren.<\/li>\n<li>Sicherheits-Policies nicht als Einmalaufgabe behandeln, sondern sie regelm\u00e4\u00dfig \u00fcberpr\u00fcfen und anpassen.<\/li>\n<li>CI\/CD-Pipeline so konfigurieren, dass instabile oder unsichere IaC-\u00c4nderungen automatisch das Deployment blockieren, bis die Risiken adressiert sind.<\/li>\n<li>Klare Richtlinien, Versionierung und regelm\u00e4\u00dfige Audits etablieren \u2013 so wird Sicherheit ein dauerhafter Prozess.<\/li>\n<\/ul>\n<p>Und das war\u2019s. Threat Modeling f\u00fcr Infrastructure as Code endet nicht bei Terraform-Konfigurationsdateien oder Kubernetes-Manifesten. Das Thema umfasst viele unterschiedliche Methoden und Einblicke in DevSecOps und l\u00e4sst sich jederzeit erweitern. Viel Erfolg beim \u00dcberzeugen des Product Owners, dass Threat Modeling f\u00fcr euer Projekt wichtig ist!<\/p>\n<p>&nbsp;<\/p>\n<p><em>Dieser Artikel erschien zuerst im <a href=\"https:\/\/entwickler.de\/magazine-ebooks\/java-magazin\/java-magazin-12026\">Java Magazin 1.2026<\/a>.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Wer ein Haus baut, schaut sich zuerst den Bauplan genau an, bevor die ersten Mauern hochgezogen werden. Niemand will nachtr\u00e4glich feststellen, dass das Fundament wackelt oder die T\u00fcr direkt in eine Wand f\u00fchrt. Mit Infrastructure as Code ist es \u00e4hnlich: Schon eine kleine Fehlkonfiguration, wie etwa ein offener Port hier oder ein zu weit gefasster [&hellip;]<\/p>\n","protected":false},"author":449,"featured_media":66024,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"ep_exclude_from_search":false,"footnotes":""},"tags":[71,66,116],"service":[879],"coauthors":[{"id":449,"display_name":"Larysa Bondar","user_nicename":"lbondar"}],"class_list":["post-65809","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","tag-cloud","tag-devops","tag-terraform","service-security"],"acf":[],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v26.5 - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<title>Bedrohungen im Bauplan: Threat Modeling f\u00fcr Infrastructure as Code - inovex GmbH<\/title>\n<meta name=\"description\" content=\"Sicherheitsl\u00fccken in IaC vermeiden: Erfahre, wie Threat Modeling, Shift-Left &amp; Methoden wie STRIDE deine Cloud-Infrastruktur sch\u00fctzen. Jetzt Best Practices &amp; Tools entdecken!\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/\" \/>\n<meta property=\"og:locale\" content=\"de_DE\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Bedrohungen im Bauplan: Threat Modeling f\u00fcr Infrastructure as Code - inovex GmbH\" \/>\n<meta property=\"og:description\" content=\"Sicherheitsl\u00fccken in IaC vermeiden: Erfahre, wie Threat Modeling, Shift-Left &amp; Methoden wie STRIDE deine Cloud-Infrastruktur sch\u00fctzen. Jetzt Best Practices &amp; Tools entdecken!\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/\" \/>\n<meta property=\"og:site_name\" content=\"inovex GmbH\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/inovexde\" \/>\n<meta property=\"article:published_time\" content=\"2026-02-06T09:59:29+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-02-06T10:33:58+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.inovex.de\/wp-content\/uploads\/Bedrohungen-im-Bauplan-Threat-Modeling-fuer-Infrastructure-as-Code.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1500\" \/>\n\t<meta property=\"og:image:height\" content=\"880\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Larysa Bondar\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:image\" content=\"https:\/\/www.inovex.de\/wp-content\/uploads\/Bedrohungen-im-Bauplan-Threat-Modeling-fuer-Infrastructure-as-Code-1024x601.png\" \/>\n<meta name=\"twitter:creator\" content=\"@inovexgmbh\" \/>\n<meta name=\"twitter:site\" content=\"@inovexgmbh\" \/>\n<meta name=\"twitter:label1\" content=\"Verfasst von\" \/>\n\t<meta name=\"twitter:data1\" content=\"Larysa Bondar\" \/>\n\t<meta name=\"twitter:label2\" content=\"Gesch\u00e4tzte Lesezeit\" \/>\n\t<meta name=\"twitter:data2\" content=\"14\u00a0Minuten\" \/>\n\t<meta name=\"twitter:label3\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data3\" content=\"Larysa Bondar\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/\"},\"author\":{\"name\":\"Larysa Bondar\",\"@id\":\"https:\/\/www.inovex.de\/de\/#\/schema\/person\/9624b6ba00a2cf412e72eed35d44eed0\"},\"headline\":\"Bedrohungen im Bauplan: Threat Modeling f\u00fcr Infrastructure as Code\",\"datePublished\":\"2026-02-06T09:59:29+00:00\",\"dateModified\":\"2026-02-06T10:33:58+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/\"},\"wordCount\":2719,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\/\/www.inovex.de\/de\/#organization\"},\"image\":{\"@id\":\"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.inovex.de\/wp-content\/uploads\/Bedrohungen-im-Bauplan-Threat-Modeling-fuer-Infrastructure-as-Code.png\",\"keywords\":[\"Cloud\",\"DevOps\",\"Terraform\"],\"inLanguage\":\"de\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/\",\"url\":\"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/\",\"name\":\"Bedrohungen im Bauplan: Threat Modeling f\u00fcr Infrastructure as Code - inovex GmbH\",\"isPartOf\":{\"@id\":\"https:\/\/www.inovex.de\/de\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.inovex.de\/wp-content\/uploads\/Bedrohungen-im-Bauplan-Threat-Modeling-fuer-Infrastructure-as-Code.png\",\"datePublished\":\"2026-02-06T09:59:29+00:00\",\"dateModified\":\"2026-02-06T10:33:58+00:00\",\"description\":\"Sicherheitsl\u00fccken in IaC vermeiden: Erfahre, wie Threat Modeling, Shift-Left & Methoden wie STRIDE deine Cloud-Infrastruktur sch\u00fctzen. Jetzt Best Practices & Tools entdecken!\",\"breadcrumb\":{\"@id\":\"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/#breadcrumb\"},\"inLanguage\":\"de\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/#primaryimage\",\"url\":\"https:\/\/www.inovex.de\/wp-content\/uploads\/Bedrohungen-im-Bauplan-Threat-Modeling-fuer-Infrastructure-as-Code.png\",\"contentUrl\":\"https:\/\/www.inovex.de\/wp-content\/uploads\/Bedrohungen-im-Bauplan-Threat-Modeling-fuer-Infrastructure-as-Code.png\",\"width\":1500,\"height\":880},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/www.inovex.de\/de\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Bedrohungen im Bauplan: Threat Modeling f\u00fcr Infrastructure as Code\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.inovex.de\/de\/#website\",\"url\":\"https:\/\/www.inovex.de\/de\/\",\"name\":\"inovex GmbH\",\"description\":\"\",\"publisher\":{\"@id\":\"https:\/\/www.inovex.de\/de\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.inovex.de\/de\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"de\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/www.inovex.de\/de\/#organization\",\"name\":\"inovex GmbH\",\"url\":\"https:\/\/www.inovex.de\/de\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\/\/www.inovex.de\/de\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/www.inovex.de\/wp-content\/uploads\/2021\/03\/inovex-logo-16-9-1.png\",\"contentUrl\":\"https:\/\/www.inovex.de\/wp-content\/uploads\/2021\/03\/inovex-logo-16-9-1.png\",\"width\":1921,\"height\":1081,\"caption\":\"inovex GmbH\"},\"image\":{\"@id\":\"https:\/\/www.inovex.de\/de\/#\/schema\/logo\/image\/\"},\"sameAs\":[\"https:\/\/www.facebook.com\/inovexde\",\"https:\/\/x.com\/inovexgmbh\",\"https:\/\/www.instagram.com\/inovexlife\/\",\"https:\/\/www.linkedin.com\/company\/inovex\",\"https:\/\/www.youtube.com\/channel\/UC7r66GT14hROB_RQsQBAQUQ\"]},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.inovex.de\/de\/#\/schema\/person\/9624b6ba00a2cf412e72eed35d44eed0\",\"name\":\"Larysa Bondar\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\/\/www.inovex.de\/de\/#\/schema\/person\/image\/30db1067a0beadd20d59a139d2567366\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/bde4ed59592dc7d77487a14deed457c3debce094cfec704a2753041471027bbd?s=96&d=retro&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/bde4ed59592dc7d77487a14deed457c3debce094cfec704a2753041471027bbd?s=96&d=retro&r=g\",\"caption\":\"Larysa Bondar\"},\"description\":\"Ich habe einen Masterabschluss in Cloud Applications and Security Engineering und arbeite als Cloud Platform Engineer bei inovex. Meine beruflichen Schwerpunkte sind Cloud-Architektur, Sicherheit und DevSecOps. Mein besonderes Interesse gilt Infrastructure as Code sowie weiteren Konzepten des Cloud Computing und der Cloud-Sicherheit.\",\"url\":\"https:\/\/www.inovex.de\/de\/blog\/author\/lbondar\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Bedrohungen im Bauplan: Threat Modeling f\u00fcr Infrastructure as Code - inovex GmbH","description":"Sicherheitsl\u00fccken in IaC vermeiden: Erfahre, wie Threat Modeling, Shift-Left & Methoden wie STRIDE deine Cloud-Infrastruktur sch\u00fctzen. Jetzt Best Practices & Tools entdecken!","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/","og_locale":"de_DE","og_type":"article","og_title":"Bedrohungen im Bauplan: Threat Modeling f\u00fcr Infrastructure as Code - inovex GmbH","og_description":"Sicherheitsl\u00fccken in IaC vermeiden: Erfahre, wie Threat Modeling, Shift-Left & Methoden wie STRIDE deine Cloud-Infrastruktur sch\u00fctzen. Jetzt Best Practices & Tools entdecken!","og_url":"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/","og_site_name":"inovex GmbH","article_publisher":"https:\/\/www.facebook.com\/inovexde","article_published_time":"2026-02-06T09:59:29+00:00","article_modified_time":"2026-02-06T10:33:58+00:00","og_image":[{"width":1500,"height":880,"url":"https:\/\/www.inovex.de\/wp-content\/uploads\/Bedrohungen-im-Bauplan-Threat-Modeling-fuer-Infrastructure-as-Code.png","type":"image\/png"}],"author":"Larysa Bondar","twitter_card":"summary_large_image","twitter_image":"https:\/\/www.inovex.de\/wp-content\/uploads\/Bedrohungen-im-Bauplan-Threat-Modeling-fuer-Infrastructure-as-Code-1024x601.png","twitter_creator":"@inovexgmbh","twitter_site":"@inovexgmbh","twitter_misc":{"Verfasst von":"Larysa Bondar","Gesch\u00e4tzte Lesezeit":"14\u00a0Minuten","Written by":"Larysa Bondar"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/#article","isPartOf":{"@id":"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/"},"author":{"name":"Larysa Bondar","@id":"https:\/\/www.inovex.de\/de\/#\/schema\/person\/9624b6ba00a2cf412e72eed35d44eed0"},"headline":"Bedrohungen im Bauplan: Threat Modeling f\u00fcr Infrastructure as Code","datePublished":"2026-02-06T09:59:29+00:00","dateModified":"2026-02-06T10:33:58+00:00","mainEntityOfPage":{"@id":"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/"},"wordCount":2719,"commentCount":0,"publisher":{"@id":"https:\/\/www.inovex.de\/de\/#organization"},"image":{"@id":"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/#primaryimage"},"thumbnailUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/Bedrohungen-im-Bauplan-Threat-Modeling-fuer-Infrastructure-as-Code.png","keywords":["Cloud","DevOps","Terraform"],"inLanguage":"de","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/","url":"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/","name":"Bedrohungen im Bauplan: Threat Modeling f\u00fcr Infrastructure as Code - inovex GmbH","isPartOf":{"@id":"https:\/\/www.inovex.de\/de\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/#primaryimage"},"image":{"@id":"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/#primaryimage"},"thumbnailUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/Bedrohungen-im-Bauplan-Threat-Modeling-fuer-Infrastructure-as-Code.png","datePublished":"2026-02-06T09:59:29+00:00","dateModified":"2026-02-06T10:33:58+00:00","description":"Sicherheitsl\u00fccken in IaC vermeiden: Erfahre, wie Threat Modeling, Shift-Left & Methoden wie STRIDE deine Cloud-Infrastruktur sch\u00fctzen. Jetzt Best Practices & Tools entdecken!","breadcrumb":{"@id":"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/#breadcrumb"},"inLanguage":"de","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/"]}]},{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/#primaryimage","url":"https:\/\/www.inovex.de\/wp-content\/uploads\/Bedrohungen-im-Bauplan-Threat-Modeling-fuer-Infrastructure-as-Code.png","contentUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/Bedrohungen-im-Bauplan-Threat-Modeling-fuer-Infrastructure-as-Code.png","width":1500,"height":880},{"@type":"BreadcrumbList","@id":"https:\/\/www.inovex.de\/de\/blog\/bedrohungen-im-bauplan-threat-modeling-fuer-infrastructure-as-code\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.inovex.de\/de\/"},{"@type":"ListItem","position":2,"name":"Bedrohungen im Bauplan: Threat Modeling f\u00fcr Infrastructure as Code"}]},{"@type":"WebSite","@id":"https:\/\/www.inovex.de\/de\/#website","url":"https:\/\/www.inovex.de\/de\/","name":"inovex GmbH","description":"","publisher":{"@id":"https:\/\/www.inovex.de\/de\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.inovex.de\/de\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"de"},{"@type":"Organization","@id":"https:\/\/www.inovex.de\/de\/#organization","name":"inovex GmbH","url":"https:\/\/www.inovex.de\/de\/","logo":{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/www.inovex.de\/de\/#\/schema\/logo\/image\/","url":"https:\/\/www.inovex.de\/wp-content\/uploads\/2021\/03\/inovex-logo-16-9-1.png","contentUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/2021\/03\/inovex-logo-16-9-1.png","width":1921,"height":1081,"caption":"inovex GmbH"},"image":{"@id":"https:\/\/www.inovex.de\/de\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.facebook.com\/inovexde","https:\/\/x.com\/inovexgmbh","https:\/\/www.instagram.com\/inovexlife\/","https:\/\/www.linkedin.com\/company\/inovex","https:\/\/www.youtube.com\/channel\/UC7r66GT14hROB_RQsQBAQUQ"]},{"@type":"Person","@id":"https:\/\/www.inovex.de\/de\/#\/schema\/person\/9624b6ba00a2cf412e72eed35d44eed0","name":"Larysa Bondar","image":{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/www.inovex.de\/de\/#\/schema\/person\/image\/30db1067a0beadd20d59a139d2567366","url":"https:\/\/secure.gravatar.com\/avatar\/bde4ed59592dc7d77487a14deed457c3debce094cfec704a2753041471027bbd?s=96&d=retro&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/bde4ed59592dc7d77487a14deed457c3debce094cfec704a2753041471027bbd?s=96&d=retro&r=g","caption":"Larysa Bondar"},"description":"Ich habe einen Masterabschluss in Cloud Applications and Security Engineering und arbeite als Cloud Platform Engineer bei inovex. Meine beruflichen Schwerpunkte sind Cloud-Architektur, Sicherheit und DevSecOps. Mein besonderes Interesse gilt Infrastructure as Code sowie weiteren Konzepten des Cloud Computing und der Cloud-Sicherheit.","url":"https:\/\/www.inovex.de\/de\/blog\/author\/lbondar\/"}]}},"_links":{"self":[{"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/posts\/65809","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/users\/449"}],"replies":[{"embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/comments?post=65809"}],"version-history":[{"count":4,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/posts\/65809\/revisions"}],"predecessor-version":[{"id":66026,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/posts\/65809\/revisions\/66026"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/media\/66024"}],"wp:attachment":[{"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/media?parent=65809"}],"wp:term":[{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/tags?post=65809"},{"taxonomy":"service","embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/service?post=65809"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/coauthors?post=65809"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}