Automatisierte Infrastruktur: Regulatorische Sicherheit durch IaC

Infrastructure as Code (IaC) bedeutet, dass IT-Infrastruktur (Server, Netzwerke, Datenbanken etc.) nicht manuell, sondern mittels Code definiert und verwaltet wird. Ziel ist es, Infrastruktur reproduzierbar, versionierbar und automatisierbar zu machen – ähnlich wie Softwareentwicklung.

Config Management Systeme gibt es schon deutlich länger. Damit erfolgt die Konfiguration und Verwaltung von Software und Systemen, nachdem die Infrastruktur bereits existiert.

Im Zuge der Verwaltung von Cloud Systemen haben Tools für Infrastructure as Code eine starke Verbreitung erhalten bzw. sind Config Management Systeme für IaC erweitert worden. IaC bedeutet die Bereitstellung und Verwaltung der Infrastruktur selbst (Server, Netzwerke, Datenbanken, Cloud-Ressourcen).

Die Vorteile von IaC sind:

Konsistenz und Wiederholbarkeit
Schnellere Bereitstellung
Versionskontrolle (z.B. über Git)
Skalierbarkeit
Reduzierung menschlicher Fehler
Für die Revision prüfbare Änderungen

Infrastructure as Code ist ein zentraler Bestandteil moderner IT-Automatisierung. Die Wahl des richtigen Tools hängt stark von der Umgebung, den Anforderungen und dem Personal ab. Kostenlose Open-Source-Tools bieten einen guten Einstieg und sind meist sehr ausgereift, während Enterprise-Versionen zusätzliche Features und Support bieten.

Bevor man sich ein IaC System auswählt, sollte man sich folgendes überlegen:

Welche Infrastruktur möchte man verwalten?
Welches Tools bringt eine Unterstützung von der Infrastruktur mit?
Soll mit dem gleichen Tool auch Config Management erfolgen?
Benötigt man einen Supportvertrag?
Wie ist der technische Hintergrund des Teams?
Wie ist die Komplexität der Umgebung?
Wie gut ist die Dokumentation und Community?
Wie ist die verwendete Sprache (YAML, DSL, echte Programmiersprachen)?
Ist ein State-Management gewünscht?
Wie hoch sind die Lizenz- bzw. Betriebskosten?

Grundsätzlich empfiehlt sich ein IaC Tool zu wählen, das nicht Cloud-spezifisch ist. AWS CloudFormation, Azure ARM oder GCP Deployment Manager funktionieren nur in der jeweiligen Cloud.

Natürlich ist die Erstellung eines virtuellen Linux Host in jeder Cloud anders. Also muss man die Cloud-spezifischen Provider oder Module nutzen, aber das Grundkonzept ist bei Cloud unabhängigen Tools gleich.

Die drei wichtigsten IoC Tools

Terraform (HashiCorp)

Deklaratives IaC-Tool.
Multi-Cloud und On-Premises fähig.
Nutzt HCL (HashiCorp Configuration Language).
State-Management für Infrastruktur.
Provisionierung von VMs, Netzwerken, Datenbanken in AWS, Azure, GCP, VMware, etc.
Support möglich, sonst kostenlos.
Opensource Möglichkeit mit OpenTofu.
Custom Provider werden in Go geschrieben.
Umgebungsspezifische Variablen bedeuten in Terraform in größeren Umgebungen die Nutzung von Zusatzprodukten wie Terragrunt.
Sehr komplex bei großen Umgebungen.

Pulumi

Code-basiertes IaC-Tool.
Multi-Cloud und Kubernetes-fähig.
Nutzt Programmiersprachen wie Python, TypeScript, Go, C# statt einer eigenen DSL.
State-Management für Infrastruktur.
Einsatz: Ideal für Teams, die lieber „richtigen Code“ statt deklarativer Templates schreiben.
Support möglich, sonst kostenlos nutzbar.
Custom Provider werden in Python, TypeScript, Go, C# geschrieben.
Stacks pro Umgebung sind intuitiv.

Ansible (RedHat)

Automatisierung & IaC (oft als Hybrid zwischen Config Management und IaC gesehen).
Multi-Cloud und On-Premises.
Nutzt YAML für Playbooks.
Kann sowohl Infrastruktur bereitstellen (über Module) als auch konfigurieren.
Einsatz: Häufig für Provisionierung + Konfiguration in einem Schritt.
Support möglich, sonst kostenlos.
Eigene Module werden in Python geschrieben.
Umgebungsspezifische Variablen sind leicht über entsprechende yaml Dateien zu lösen.
Inventories für jede Umgebung leicht verständlich und Variablen sind gut skalierbar.

Das State File ist ein zentrales Konzept bei Tools wie Terraform und Pulumi. Sie speichert den aktuellen Zustand der Infrastruktur, damit das IaC-Tool weiß, was bereits existiert und was geändert werden muss. Ein Verlust oder Korruption der State File bedeutet, das IaC-Tool „vergisst“ die Infrastruktur. D.h. der State File muss besondere Aufmerksamkeit gelt und die muss ich vor Zugriff geschützt sein, da dort sensible Daten stehen können. Ggf. muss man auch mit mehreren State Files arbeiten.

Im Gegensatz dazu muss Ansible jedes Mal den aktuellen Zustand mit dem Code vergleichen, was etwas mehr Zeit kostet. Aber man erspart sich den Aufwand des State File.

CI/CD

Das Tool für IaC sollte in CI/CD integriert werden. Infrastrukturänderungen sind genauso kritisch wie Softwareänderungen.

CI/CD sorgt für:

Versionierung (über Git).
Automatisierte Tests (z.  Policy Checks, Sicherheitsprüfungen).
Genehmigungsprozesse (z.  „Plan anzeigen, bevor Apply“).
Erstellung eines Change Requests
Reproduzierbarkeit (kein manuelles Klicken in der Cloud-Konsole).

Continuous Integration (CI)

Entwickler pushen Code (oder IaC) in ein Git-Repository.

Eine CI-Pipeline prüft automatisch:
- Syntax und Formatierung (z.  terraform validate, ansible-lint).
- Tests (Unit-, Integrationstests).
- Planung (z.  terraform plan zeigt Änderungen, ohne sie anzuwenden).
Ziel: Fehler früh erkennen, Qualität sichern.

Continuous Delivery/Deployment (CD)

Nach erfolgreicher CI-Prüfung wird der Code automatisiert ausgerollt:
- Für IaC bedeutet das: Infrastrukturänderungen werden angewendet (terraform apply, pulumi up, ansible-playbook).
Delivery = Änderungen sind vorbereitet, aber erfordern manuellen Freigabe-Click.
Deployment = Änderungen werden vollautomatisch live umgesetzt.

Entscheidend für die Finanzbranche

In der Finanzbranche ist Infrastructure as Code (IaC) aus regulatorischer Perspektive besonders entscheidend – hier die wichtigsten Gründe:

Mit IaC wird jede Infrastrukturänderung als Code im Versionssystem dokumentiert, inklusive Zeitstempel, Autor und Änderungsdetails. Das erleichtert das Rechenschafts- und Audit-Reporting erheblich.
Richtlinien zu Zugangsbeschränkungen, Verschlüsselung oder Datenhaltung können direkt im IaC-Code als Maschinenvorschriften hinterlegt werden.
Verstöße gegen Vorgaben werden bereits, während der CI/CD-Pipeline erkannt und blockiert – Compliance wird proaktiv und in Echtzeit umgesetzt.
Standardisierte IaC-Vorlagen (Templates, Module) verhindern Konfigurationsabweichungen – menschliche Fehler wie offene Ports oder fehlerhafte Verschlüsselung werden stark reduziert.
Einheitliche Umgebungen (Dev, Test, Prod) senken Risiken und helfen, regulatorische Anforderungen konsistent einzuhalten.
Digital Operational Resilience Act (DORA) verlangt u.a. automatisierte ICT‑Risikokontrolle, systematisches Incident‑Management und Testing digitaler Resilienz. IaC liefert dafür die notwendige Struktur.
Infrastruktur wird reproduzierbar und valide testbar – ein klarer Vorteil bei regulatorischer Überprüfung.

Wenn Sie Ihre Infrastruktur zukunftssicher, automatisiert und revisionssicher gestalten möchten, unterstützen wir Sie von der Analyse bis zur Implementierung von Infrastructure as Code. Unsere Experten begleiten Sie bei der Auswahl der richtigen Tools, dem Aufbau von CI/CD‑Pipelines und der erfolgreichen Einführung moderner Betriebsverfahren.

Über den Autor:

Andreas Dvorak ist bei Be Shaping The Future als Senior Technical Analyst beschäftigt und bringt langjährige Erfahrung im Bereich von Betrieb, Automatisierung und Monitoring von On-Premises und Cloud Umgebungen mit.