Was ist IaC-Sicherheit (Infrastructure as Code)?

• Infrastructure as Code (IaC) ist eine Methode, bei der Cloud-Infrastruktur anstatt durch manuelle Konfiguration mittels Code bereitgestellt und verwaltet wird.
• IaC-Sicherheit trägt dazu bei, Fehlkonfigurationen in der Cloud zu erkennen und zu beheben, bevor Anwendungen in die Produktionsumgebung gelangen.
• Konfigurationsdrift kann Schwachstellen hervorrufen, wenn Cloud-Infrastruktur im Live-Betrieb nicht mit den Vorlagen des Unternehmens übereinstimmt.
• Policy-as-Code (PaC) macht es möglich, Sicherheits- und Compliance-Vorgaben automatisiert durchzusetzen – über den gesamten Softwareentwicklungszyklus (SDLC) hinweg.
• Durch die Umstellung auf Shift-Left-Sicherheitsverfahren können Unternehmen IaC-Scanning innerhalb der CI/CD-Pipeline anwenden, was Behebungskosten reduziert.
• Moderne Exposure Management-Lösungen verknüpfen IaC-Sicherheitserkenntnisse mit Risiken, Angriffspfaden, Identitäten und Cloud-Assets.

Eine einzige Fehlkonfiguration in einer Infrastrukturvorlage kann sich binnen Sekunden auf Tausende von Cloud-Ressourcen ausbreiten. Genau diesem zentralen Risiko soll IaC-Sicherheit Rechnung tragen.

Mit IaC sind Teams in der Lage, Server, Storage, Netzwerke und Sicherheitseinstellungen durch maschinenlesbare Konfigurationsdateien zu definieren und bereitzustellen, anstatt sie manuell einzurichten. Mithilfe von Tools wie Terraform, CloudFormation, Kubernetes und Ansible können Cloud-Infrastrukturen schneller und einheitlicher bereitgestellt werden.

Unternehmen profitieren dadurch von Konsistenz, Skalierbarkeit, Wiederholbarkeit und Geschwindigkeit. Infrastruktur lässt in wenigen Minuten statt mehreren Tagen bereitstellen.

Doch diese Geschwindigkeit, die den Mehrwert von IaC ausmacht, birgt auch Risiken. Ein Fehler in einer einzigen IaC-Konfiguration kann sich binnen Sekunden leicht auf Hunderte oder gar Tausende von Cloud-Instanzen ausbreiten. 

Eine zu laxe IAM-Richtlinie, ein offengelegter Storage-Bucket oder eine fehlende Verschlüsselungseinstellung könnte aus der Entwicklung unbemerkt in die Produktion gelangen.

Bei IaC-Sicherheit geht es darum, diese Fehlkonfigurationen abzufangen, bevor sie ausnutzbar sind – durch Scans von Vorlagen, Richtliniendurchsetzung und kontinuierliche Transparenz in sämtlichen Cloud-Umgebungen.

Viele der schwerwiegendsten Cloud-Sicherheitsvorfälle, die heutzutage eintreten, sind auf einen einfachen Konfigurationsfehler zurückzuführen.

Zu den gängigsten Risiken zählen fehlerhaft konfigurierte Cloud-Speicher, Netzwerkberechtigungen und IAM-Richtlinien, die unmittelbar in Infrastrukturvorlagen eingebettet werden. Sind diese Vorlagen einmal in die Produktion gelangt, weisen sämtliche Bereitstellungen dieselbe Schwachstelle auf.

Ein weiteres häufiges Problem sind zu laxe Standardberechtigungen. Das Entwicklungsteam legt bei Tests in der Regel mehr Wert auf Geschwindigkeit und vergisst dabei möglicherweise, Zugriffsrechte bei der Bereitstellung in der Produktionsumgebung zu straffen. Übermäßige Berechtigungen, die im Rahmen von Tests vergeben wurden, können über den gesamten Bereitstellungszyklus bestehen bleiben.

Ein weiteres wiederkehrendes Problem sind hartcodierte Zugangsdaten und Secrets in Konfigurationsdateien. Hartcodierte Zugangsdaten, API-Schlüssel und Zugriffstoken gewähren Angreifern unbefugten Zugriff, sobald Einblick in das Repository oder die Bereitstellungspipeline besteht.

Module von Drittanbietern und wiederverwendbare Code-Bibliotheken finden bei der Softwareentwicklung breite Anwendung. Diese Tools beschleunigen zwar Entwicklungsprozesse, bergen jedoch oftmals „übernommene“ Risiken, wie etwa unsichere Abhängigkeiten und veraltete Konfigurationen.

Darüber hinaus führen Lücken in der Verschlüsselung zu riskanten Cloud-Fehlkonfigurationen. Fehlen Verschlüsselungseinstellungen (für Daten im Ruhezustand, bei der Übertragung oder in Backups), sind kritische Daten gefährdet, was zu Compliance-Problemen im Zusammenhang mit Frameworks wie PCI-DSS, DSGVO, HIPAA, PSD2, SOC 2, CIS-Benchmarks und NIST führt.

Und nicht zuletzt können fehlerhafte Konfigurationen bei der Protokollierung und Überwachung dazu führen, dass Teams nach der Bereitstellung die nötige Sichtbarkeit fehlt und sie verdächtige Aktivitäten nicht erkennen oder Vorfälle nicht ordnungsgemäß untersuchen können.

Konfigurationsdrift tritt auf, wenn Live-Infrastruktur allmählich von der ursprünglichen, genehmigten IaC-Vorlage abweicht.

Infrastruktur könnte anfangs noch den Vorgaben entsprechen, doch mit der Zeit häufen sich Änderungen. Engineers nehmen in der Cloud-Konsole Notfallkorrekturen vor und Administratoren richten vorübergehende Richtlinienausnahmen ein. 

Teams ändern Berechtigungen vorübergehend, vergessen später aber, sie zu widerrufen.

Diese manuellen Änderungen führen zu Abweichungen zwischen der genehmigten Vorlage und der tatsächlichen Produktionsumgebung.

Dies hat zur Folge, dass die Baseline immer unzuverlässiger wird. Die Konfiguration in einer IaC-Vorlage kann von der tatsächlichen Konfiguration in der Produktionsinfrastruktur abweichen. 

Möglicherweise gibt es offene Ports, gelockerte Zugriffskontrollen, deaktivierte Protokollierung oder Dienste, die ganz ohne Dokumentation oder Genehmigung ausgeführt werden.

Konfigurationsdrift tritt nur selten als verheerendes Einzelereignis auf. Vielmehr häufen sich Abweichungen mit der Zeit an. Jede Änderung erscheint für sich genommen harmlos, doch im Verbund nimmt die entsprechende Exposure über Monate oder Jahre stetig zu.

Diese Herausforderung ist mit Modelldrift in KI-Systemen vergleichbar: Die Leistung verschlechtert sich nach und nach, ohne dass ein offensichtlicher Single Point of Failure vorliegt. Wenn das Problem dann offensichtlich wird, bestehen möglicherweise bereits erhebliche Risiken.

Bei herkömmlichen Sicherheitsevaluierungen, die zu bestimmten Zeitpunkten erfolgen, wird Drift übersehen, da sie lediglich eine Momentaufnahme erfassen. Echtzeitüberwachung ist weitaus effektiver, da Abweichungen sofort erkannt und Warnungen ausgegeben werden, sobald Infrastruktur von festgelegten Benchmarks abweicht.

Wenn Unternehmen Exposure-Bewertungen und Exposure Management implementieren möchten, ist Konfigurationsdrift ein entscheidender Faktor, da dieser Aspekt vorhandene Sicherheitskontrollen kompromittiert.

Durch Policy as Code (PaC) wird manuelle Governance zu einer automatisierten, skalierbaren Funktion.

Anstatt sich auf routinemäßige Checks oder Genehmigungen durch Mitarbeiter zu verlassen, versetzt PaC Unternehmen in die Lage, Sicherheits- und Compliance-Vorgaben als maschinenlesbare Richtlinien zu definieren, die von Systemen automatisch durchgesetzt werden.

Diese Richtlinien greifen über den gesamten Lebenszyklus der Infrastruktur hinweg.

Über Pre-Commit-Checks in der IDE erhalten Entwickler Feedback, bevor Code in die Quellcodeverwaltung gelangt. Konfigurationschecks aus CI/CD-Pipelines verifizieren Konfigurationen noch vor der Zusammenführung und Bereitstellung. Systeme zur kontinuierlichen Überwachung validieren Konfigurationen nach der Bereitstellung.

Dadurch wird die Durchsetzung auf den Zeitpunkt der Code-Erstellung vorverlegt. Teams erkennen Probleme bereits, während Entwickler die Infrastruktur erstellen, und nicht erst nach der Bereitstellung von Cloud-Ressourcen.

Policy-as-Code gewährleistet zudem Konsistenz in Multi-Cloud-Umgebungen. Unabhängig davon, ob die Umgebung mit AWS, Azure oder Google Cloud betrieben wird: Unternehmen setzen Sicherheitsrichtlinien ganz ohne zusätzliche manuelle Prüfungen durch.

Dasselbe gilt für Compliance. Bei jeder Ausführung einer Richtlinie wird ein Audit-Trail erstellt, aus dem hervorgeht, welche Kontrollen zum Einsatz kamen, welches Teammitglied die Kontrollen ausgeführt hat und ob die Selbstvalidierung der Infrastruktur erfolgreich war. Zu den von PaC unterstützten Compliance-Vorgaben zählen SOC 2, CIS-Benchmarks, NIST, PCI-DSS, DSGVO, PSD2 und HIPAA.

Noch wichtiger ist aber, dass PaC es Teams ermöglicht, Konfigurationsdrift in großem Maßstab zu erkennen und zu kontrollieren. Ohne Automatisierung fällt es deutlich schwerer, Governance in dynamischen Cloud-Umgebungen aufrechtzuerhalten.

Je früher Teams Sicherheitsprobleme in Cloud-Infrastruktur erkennen, desto schneller und kostengünstiger die Behebung.

Ist eine Fehlkonfiguration einmal in die Produktionsumgebung gelangt, erfordert die Behebung oftmals zusätzliche Tests, Änderungsmanagementprozesse, Serviceunterbrechungen sowie Koordination zwischen mehreren Teams. Und mit jeder weiteren Phase im SDLC steigen die Behebungskosten drastisch an.

Shift-Left-Sicherheit löst dieses Problem, indem IaC-Scanning unmittelbar in die CI/CD-Pipeline eingebunden wird.

Anstatt abzuwarten, bis Sicherheitsteams nach erfolgter Bereitstellung Überprüfungen vornehmen, erhalten Entwickler bereits während der Entwicklung sofortiges Feedback. Sie beheben Sicherheitsprobleme, noch bevor Code in den Produktionszweigen zusammengeführt wird.

Durch diesen Ansatz durchläuft Sicherheit eine Entwicklung – von einer nachgelagerten Audit-Funktion hin zu einem vollständig integrierten Bestandteil der Entwicklungsprozesse.

Moderne Frameworks für DevSecOps-Sicherheit müssen IaC-Scanning sowie Static Application Security Testing (SAST) und Dynamic Application Security Testing (DAST) umfassen, sodass ein kontinuierliches Bild der Sicherheitslage entsteht – über Software, Infrastruktur und Bereitstellungspipelines hinweg.

Mit der zunehmenden Cloud-Nutzung in Unternehmen verschwimmen die Grenzen zwischen Anwendungssicherheit und Infrastruktursicherheit immer mehr. Infrastruktur bildet die Grundlage für Anwendungen und in den meisten Fällen besteht diese Infrastruktur aus Code. Für effektives Exposure Management sollten beide Aspekte sichtbar sein.

KI-Programmierassistenten und agentische KI verändern die Art und Weise, wie Entwicklungsteams ihre Infrastruktur aufbauen.

Immer mehr Softwareingenieure setzen auf KI-gestützte Automatisierung, um Terraform-Vorlagen, Kubernetes-Konfigurationen, Skripts zur Cloud-Bereitstellung und weitere Infrastrukturkomponenten zu erstellen. 

Diese Tools steigern zwar die Effizienz, bringen aber auch neue Schwachstellen mit sich.

KI kann Infrastrukturcode binnen Sekunden generieren, doch Sicherheitsfragen bleiben unbeantwortet. Eine Vorlage mag einwandfrei funktionieren – und kann dennoch Storage offenlegen, übermäßige Berechtigungen gewähren, Verschlüsselungsmechanismen überspringen oder Dienste über das Internet zugänglich machen. 

Wenn Unternehmen sich ohne gründliche Prüfung auf KI-Output verlassen, können diese Probleme schnell in die Produktion gelangen.

Auch Sicherheitsteams sehen sich zunehmend mit Schatten-IaC konfrontiert. Wenn KI-Tools zum Einsatz kommen, um Infrastruktur außerhalb genehmigter Workflows zu erstellen und bereitzustellen, entstehen Umgebungen, von deren Existenz Unternehmen möglicherweise gar nichts wissen.

Unterschiede ergeben sich bei KI in Sachen Geschwindigkeit: Eine fehlerhafte Konfiguration erfordert inzwischen keine monatelangen manuellen Änderungen mehr, um sie in der gesamten Umgebung zu verteilen. Eine mängelbehaftete KI-generierte Vorlage kann kopiert und in Hunderten von Ressourcen wiederverwendet werden, bevor das Problem bemerkt wird.

Das gleiche Prinzip gilt für die Durchsetzung von Sicherheitsmaßnahmen. Das KI-gestützte Vulnerability Priority Rating (VPR) von Tenable grenzt die 60 % der CVEs, die nach dem CVSS als „kritisch“ oder „hoch“ eingestuft werden, auf die 1,6 % ein, die ein tatsächliches Geschäftsrisiko darstellen.

In IaC-Umgebungen hat diese Art der Priorisierung zur Folge, dass Teams keine irrelevanten Meldungen mehr bei der Triage sichten müssen. Stattdessen können sie sich auf die Fehlkonfigurationen konzentrieren, die tatsächlich ausgenutzt werden könnten.

Sicherheitsfachkräfte nutzen KI-basiertes Cloud Security Posture Management (CSPM), Policy-as-Code-Verfahren und automatisierte Validierungstools, um diese Bedrohungen zu verwalten.

Mithilfe von kontextbezogenen KI-Leitplanken werden Least-Privilege-Regeln, zulässige Ressourcentypen, Namenskonventionen sowie Verschlüsselungs- und Unternehmensrichtlinien direkt in Entwickler-Workflows durchgesetzt. Sichere Standardeinstellungen bilden so den Weg des geringsten Widerstands.

Durch agentische KI gewinnen diese Kontrollmechanismen noch mehr an Bedeutung. 

Autonome Systeme stellen Infrastrukturen bereit, modifizieren Cloud-Umgebungen und führen Workflows aus, ohne dass jeder Einzelschritt von einer Person genehmigt werden muss. Das bedeutet, dass Teams Governance-Mechanismen von Beginn an – und nicht erst nachträglich – in Entwicklungs- und Bereitstellungsprozesse einbetten müssen.

Frontier-KI-Modelle sind zunehmend in der Lage, Infrastruktur bereitzustellen und Cloud-Betriebsabläufe autonom auszuführen. Dadurch können Governance-Richtlinien von Unternehmen schneller ins Hintertreffen geraten, als durch manuelle Prozesse ausgeglichen werden kann.

Governance-Richtlinien müssen mit Systemen Schritt halten, die Aktionen ohne vorherige Genehmigungen durch Mitarbeiter durchführen.

KI-Funktionen, die Risiken in großem Umfang hervorrufen, können auch Sicherheitsmechanismen in großem Umfang durchsetzen. Entscheidend ist hier die Frage, ob Sicherheitsrichtlinien von Grund auf in den Entwicklungsprozess eingebunden oder erst im Nachhinein hinzugefügt wurden.

Um Cloud-Infrastruktur in Maschinengeschwindigkeit zu steuern, müssen Sicherheitsrichtlinien von Anfang an in den Prozess integriert werden. Tenable trägt IaC-Sicherheit als Teil einer breiter aufgestellten Exposure Management-Strategie Rechnung.

Tenable One Cloud Exposure scannt IaC-Vorlagen vor der Bereitstellung und identifiziert dabei Fehlkonfigurationen in Terraform, CloudFormation, Kubernetes, Ansible und weiteren gängigen Formaten.

Tenable One Cloud Exposure überwacht Cloud-Umgebungen im Live-Betrieb kontinuierlich anhand genehmigter Baselines und erkennt Konfigurationsdrift, sobald es zu Abweichungen kommt. Das KI-gestützte Vulnerability Priority Rating (VPR) von Tenable grenzt dann Aspekte ein, die Aufmerksamkeit erfordern, und reduziert die 60 % der CVEs, die nach dem CVSS mit „kritischem“ oder „hohem“ Schweregrad eingestuft werden, auf die 1,6 %, die ein tatsächliches Geschäftsrisiko darstellen.

Die Durchsetzung von Policy as Code erfolgt über AWS, Azure und Google Cloud hinweg, was eine konsistente Compliance-Lage gewährleistet – ganz ohne manuelle Überprüfungszyklen.

Die Tenable One-Plattform ordnet jede IaC-Fehlkonfiguration den damit verbundenen Angriffspfaden, Identitäten und Assets zu. Für Teams ist dadurch erkennbar, welche Sicherheitslücken Sofortmaßnahmen erfordern und welche warten können.

Die Plattform geht über einzelne Feststellungen hinaus. Anstatt Cloud-Fehlkonfigurationen einfach nur zu melden, bildet Tenable ab, in welcher Verbindung diese Sicherheitslücke zu breiter gefassten Angriffspfaden, Identitäten, Berechtigungen und den kritischen Assets im Unternehmen steht.

Im Zuge der Nutzung von KI-gestützten Entwicklungsworkflows und der Verwaltung von immer größeren Cloud-Beständen ist dieser Kontext wichtiger denn je. Unternehmen muss klar sein, welche Sicherheitslücken ein echtes Geschäftsrisiko darstellen und welche unmittelbare Reaktions- und Behebungsmaßnahmen erfordern.

Mit der Exposure Management-Plattform Tenable One können Unternehmen IaC-Feststellungen mit Schwachstellendaten, Informationen zu Cloud-Assen, Erkenntnissen zu Identity-Risiken und Angriffspfad-Analysen verknüpfen, um sich ein vollständigeres Bild der Risiken zu verschaffen. 

Wenn Sicherheitsteam eine Bewertung der Exposure benötigen, die Feststellungen realen geschäftlichen Auswirkungen zuordnet, liefert ihnen Tenable One die für Maßnahmen notwendige einheitliche Übersicht.

Darüber hinaus unterstützt Tenable die Einbindung von DevSecOps-Verfahren über APIs und CI/CD-Pipeline-Integrationen, sodass die Sicherheitsvalidierung nahtlos in moderne Entwicklungs-Workflows eingebunden wird.

Bei den meisten IaC-Fehlkonfigurationen handelt es sich nicht um ausgefeilte Angriffe, sondern vielmehr um Versäumnisse. Eine aus der Testphase übrig gebliebene übermäßige Berechtigung, hartcodierte Zugangsdaten, die niemand entfernt hat, oder eine Vorlage, die noch vor der Prüfung durch einen Mitarbeiter kopiert wurde: Für sich genommen sind all das Kleinigkeiten. Doch in Hunderten von Bereitstellungen entsteht daraus die entsprechende Angriffsfläche.

Sicherheitslücken sollten direkt in Vorlagen abgefangen werden und nicht erst in Berichten über Sicherheitsverletzung Erwähnung finden. Genau dafür wurde Tenable One konzipiert.

Infrastructure as Code kann bei unerfahrenen wie auch erfahrenen Sicherheitsfachkräften eine Vielzahl an Fragen aufwerfen – je nach Sicherheitsansatz, Stack und Funktionen. Ganz gleich, in welcher Phase sich der Sicherheitsbetrieb im Unternehmen gerade befindet: Nachfolgend gehen wir auf einige der am häufigsten gestellten Fragen ein und vermitteln Teams ein besseres Verständnis bestimmter Grundlagen.

Was ist Infrastructure as Code (IaC)? 

Infrastructure as Code (IaC) ist ein Verfahren, bei dem Computing-Infrastruktur (Server, Netzwerke, Datenbanken, Load Balancer usw.) mithilfe von maschinenlesbaren Konfigurationsdateien verwaltet und bereitgestellt wird, anstatt per Mausklick durch Konsolen zu navigieren oder einzelne Befehle auszuführen. Gängige Beispiele sind Terraform, CloudFormation, Kubernetes-Manifeste und Ansible.

Was sind die gängigsten IaC-Sicherheitsrisiken? 

Die meisten IaC-Sicherheitsprobleme sind auf Fehlkonfigurationen zurückzuführen. Zu laxe Berechtigungen, offengelegter Storage, hartcodierte Zugangsdaten, fehlende Verschlüsselung und unsichere Module von Drittanbietern – all das kann bei fehlender frühzeitiger Erkennung in die Produktion gelangen.

Was ist Konfigurationsdrift in Cloud-Infrastruktur? 

Konfigurationsdrift tritt auf, wenn sich eine Cloud-Umgebung mit der Zeit verändert und nicht mehr mit der IaC-Vorlage übereinstimmt, auf deren Grundlage sie erstellt wurde. Manuelle Aktualisierungen, Schnellkorrekturen und einmalige Änderungen sind in der Regel die Ursache.

Wie entstehen Schwachstellen durch Konfigurationsdrift? 

Drift stellt ein Problem dar, weil genehmigte Konfigurationen nicht mehr der Realität entsprechen. Unternehmen könnten davon ausgehen, ein System sei auf eine bestimmte Weise konfiguriert, doch die Produktionsumgebung sieht völlig anders aus. Dadurch entstehen unbeabsichtigte Sicherheitslücken, von denen Teams nichts wissen.

Was ist Policy as Code (PaC)? 

Policy as Code steht für die Implementierung von Sicherheits- und Compliance-Richtlinien in maschinenlesbarer Form, die dann von Systemen innerhalb der Infrastruktur automatisch durchgesetzt werden.

Inwiefern unterscheidet sich Policy as Code von klassischen Compliance-Prüfungen? 

Prüfungen erfolgen in regelmäßigen Abständen und umfassen in der Regel manuelle Inspektion. Policy-as-Code hingegen validiert Infrastruktur kontinuierlich.

Welche IaC-Formate und -Tools unterstützt Tenable? 

Tenable One Cloud Exposure unterstützt Terraform, CloudFormation, Kubernetes-Dateien, Ansible und weitere bekannte IaC-Tools.

Wie lässt sich Shift-Left-Sicherheit in IaC einbinden? 

Durch Shift-Left-Sicherheit wird IaC-Scanning in die frühesten Phasen des Softwareentwicklungszyklus integriert, sodass Teams Fehlkonfigurationen erkennen können, bevor sie in die Produktion gelangen.

Können IaC-Fehlkonfigurationen zu Datenpannen führen? 

Ja, fehlerhaft konfigurierte Storage-Einstellungen, überprivilegierte Benutzerkonten, fehlende Sicherheitskontrollen und offene Ports können allesamt zu unbefugtem Zugriff und potenziellen Datenpannen führen.

Wie erkennt Tenable Konfigurationsdrift in Live-Umgebungen? 

Tenable scannt Cloud-Assets im Live-Betrieb kontinuierlich, erkennt Unstimmigkeiten zwischen diesen Assets und genehmigten Baseline-Konfigurationen und gibt bei potenziellen Schwachstellen Warnmeldungen aus.