Infrastructure as Code (IaC)

Infrastructure as Code beschreibt Server, Netze und Cloud-Ressourcen in versionierten Konfigurationsdateien, aus denen Umgebungen automatisiert entstehen. Der Artikel erklärt deklarative und imperative Ansätze, den Umgang mit Drift und Security-Scans für Templates, inklusive der Abgrenzung zum Konfigurationsmanagement.

Wer eine Umgebung von Hand aufbaut, erzeugt ein Unikat: schwer zu reproduzieren, und nach zwei Jahren kann niemand mehr erklären, warum eine bestimmte Firewallregel existiert. Infrastructure as Code (IaC) beendet dieses Modell. Infrastruktur wird in Konfigurationsdateien beschrieben und automatisiert erzeugt, mit denselben Methoden, die sich in der Softwareentwicklung bewährt haben, allen voran Versionierung und Review. Durchgesetzt hat sich der Ansatz mit der Cloud, er wirkt inzwischen aber weit darüber hinaus, bis in Netzwerk- und Sicherheitsrichtlinien hinein.

Was ist Infrastructure as Code?

Infrastructure as Code bezeichnet die Praxis, Infrastruktur in maschinenlesbaren Dateien zu definieren und über Werkzeuge automatisiert bereitzustellen. Das umfasst virtuelle Maschinen und Kubernetes-Cluster ebenso wie Netzwerke, Firewallregeln oder DNS-Einträge. Die Definitionen liegen in einem Versionskontrollsystem und durchlaufen vor jeder Änderung ein Review. Aus derselben Beschreibung entstehen identische Umgebungen, ob Test- oder Produktionsumgebung. Damit wird Infrastruktur prüfbar wie Quellcode: Jede Änderung hat Autor und Zeitstempel, fehlerhafte Stände lassen sich auf einen früheren Zustand zurücksetzen. Der Code wird damit zur verlässlichen Dokumentation: Er beschreibt keine Absicht von gestern, er ist die Quelle, aus der die Umgebung tatsächlich entstanden ist.

So funktioniert es

Deklarativ oder imperativ: Deklarative Werkzeuge beschreiben den Zielzustand, das Werkzeug ermittelt die nötigen Schritte selbst. Imperative Ansätze definieren die Schritte explizit, etwa als Skriptfolge. Für Infrastruktur haben sich deklarative Ansätze weitgehend durchgesetzt, weil sie idempotent arbeiten: Mehrfache Ausführung führt zum selben Ergebnis.
Versionierung als Fundament: Jede Änderung läuft als Pull Request mit Review. Die Historie dokumentiert, wer was wann geändert hat und warum.
Plan vor Ausführung: Gängige Werkzeuge zeigen vor der Anwendung an, welche Ressourcen entstehen, sich ändern oder wegfallen. Dieser Plan ist die letzte Kontrollinstanz vor dem Eingriff in reale Umgebungen.
Drift-Erkennung: Weicht die reale Umgebung von der Definition ab, etwa durch manuelle Änderungen in einer Cloud-Konsole, macht der Abgleich das sichtbar. Drift wird zurückgerollt oder bewusst in den Code übernommen.
Security-Scans für Templates: Spezialisierte Scanner prüfen IaC-Definitionen vor dem Rollout auf Fehlkonfigurationen, etwa offene Netzwerkzugriffe oder zu weit gefasste Berechtigungen. Fehler werden gestoppt, bevor sie eine Umgebung erreichen.

Warum es wichtig ist

Reproduzierbarkeit: Umgebungen entstehen aus Code statt aus Erinnerung. Eine zusätzliche Testumgebung oder ein neuer Standort wird zur Routineaufgabe, kein eigenes Projekt.
Weniger manuelle Fehler: Automatisierte Abläufe vermeiden Tippfehler und vergessene Schritte, die bei Handarbeit zwangsläufig passieren.
Nachvollziehbarkeit für Audits: Die Versionshistorie beantwortet Prüferfragen direkt: Wer hat die Änderung veranlasst, wer hat sie freigegeben, wann wurde sie wirksam?
Schnelle Wiederherstellung: Nach einem Ausfall wird die Umgebung aus der Definition neu aufgebaut, statt aus Backups und Gedächtnisprotokollen rekonstruiert.
Sicherheit vor dem Rollout: Scans prüfen Konfigurationen, bevor sie live gehen. Das wirkt früher und verlässlicher als jede nachträgliche Kontrolle laufender Systeme.
Grundlage für Weiteres: GitOps und automatisierte Compliance-Prüfungen setzen auf sauber definierter Infrastruktur auf.

Typische Szenarien

Der häufigste Einstieg ist die Cloud-Migration: Neue Umgebungen werden von Beginn an als Code aufgebaut, weil das Zusammenklicken hunderter Ressourcen weder skaliert noch dokumentierbar ist. Ein zweites Szenario ist der Gleichlauf mehrerer Umgebungen: Test und Produktion sollen sich ausschließlich in definierten Parametern unterscheiden, damit Testergebnisse aussagekräftig bleiben. Drittens Disaster Recovery: Der Wiederaufbau am Ausweichstandort gelingt in verlässlicher Zeit, wenn die komplette Umgebung als Code vorliegt. Und schließlich das Netzwerk selbst: Firewallregeln und Segmentierungsrichtlinien profitieren als Code von Review-Pflicht und Historie, gerade weil manuelle Regeländerungen erfahrungsgemäß fehleranfällig sind. Auch bei Übernahmen und Ausgründungen zahlt sich der Ansatz aus, weil sich definierte Umgebungen sauber duplizieren oder herauslösen lassen.

IaC und Konfigurationsmanagement: die Abgrenzung

Beide Disziplinen automatisieren, setzen aber an unterschiedlichen Punkten an. IaC provisioniert Ressourcen: Es erzeugt Netze, virtuelle Maschinen, Load Balancer oder Datenbanken und verwaltet deren Lebenszyklus. Konfigurationsmanagement richtet Systeme ein, die bereits existieren: Es installiert Software und hält Konfigurationsdateien konsistent. In klassischen Umgebungen ergänzen sich beide, IaC stellt die Maschine bereit, Konfigurationsmanagement macht sie betriebsbereit. Container verschieben diese Grenze, weil die Konfiguration ins Image wandert und Systeme unveränderlich betrieben werden. Die Unterscheidung bleibt trotzdem wichtig, denn wer beide Aufgaben mit demselben Werkzeug erzwingt, landet häufig bei schwer wartbaren Konstrukten.

So unterstützt KAEMI

KAEMI wendet IaC-Prinzipien dort an, wo sie für sichere Unternehmensnetzwerke den größten Hebel haben: bei Konnektivität und Segmentierung. Anbindungen an Cloud-Umgebungen entstehen mit Cloud Connectivity reproduzierbar und nachvollziehbar statt als gewachsene Einzelkonfiguration. Segmentierungsrichtlinien werden im Rahmen der Mikrosegmentierung als deklarative Policies gepflegt: Sie beschreiben erlaubte Kommunikation, die Durchsetzung erfolgt automatisiert, und jede Änderung bleibt dokumentiert. Als Managed Service Provider übernimmt KAEMI den laufenden Betrieb, von der Pflege der Definitionen bis zur Kontrolle auf Abweichungen. Änderungen am Netzwerk verlieren damit ihren Schrecken, weil sie vor dem Rollout geprüft werden und umkehrbar bleiben. Wenn Sie Ihre Netzwerk- und Sicherheitskonfiguration in eine prüfbare, versionierte Form bringen wollen, sprechen Sie uns über Kontakt an.

Häufige Fragen zu Infrastructure as Code (IaC)

Was unterscheidet deklaratives von imperativem IaC?

Deklarative Ansätze beschreiben den gewünschten Endzustand, das Werkzeug berechnet die nötigen Schritte und gleicht wiederholt gegen die Realität ab. Imperative Ansätze legen die Schritte selbst fest, etwa als Skript, das Ressourcen in fester Reihenfolge anlegt. Deklarativ hat sich für Infrastruktur durchgesetzt, weil Läufe idempotent sind und der Code zugleich als Dokumentation des Sollzustands dient.

Was ist Konfigurationsdrift und wie gehe ich damit um?

Drift entsteht, wenn die reale Umgebung vom definierten Code abweicht, meist durch manuelle Eingriffe in Konsolen oder auf Systemen. Das macht Umgebungen unvorhersehbar und entwertet die Dokumentation. Dagegen helfen regelmäßige automatische Abgleiche, die Abweichungen melden, klare Regeln für Notfalleingriffe und deren Rückführung in den Code sowie restriktive Rechte für direkte Änderungen an produktiven Ressourcen.

Wie lässt sich IaC absichern?

Behandeln Sie Infrastruktur-Code wie Anwendungscode: verpflichtende Reviews, Scans auf Fehlkonfigurationen vor jedem Rollout und Secret-Prüfungen, damit keine Zugangsdaten in Templates landen. Die ausführende Pipeline erhält eng begrenzte Rechte, getrennt je Umgebung. Der Zustand der Werkzeuge, etwa State-Dateien, enthält sensible Daten und gehört verschlüsselt und zugriffsbeschränkt abgelegt.

Ist IaC ausschließlich für Cloud-Umgebungen relevant?

Nein. Der Ansatz stammt zwar aus der Cloud, wirkt aber überall dort, wo sich Ressourcen über Schnittstellen steuern lassen. Auch im Rechenzentrum lassen sich Netzwerkkonfigurationen, Firewallregeln und Segmentierungsrichtlinien als Code pflegen. Gerade Sicherheitsrichtlinien gewinnen dadurch Review-Pflicht und Historie, was manuelle Regelpflege auf einzelnen Geräten weder leisten kann noch soll.

Worin unterscheidet sich IaC von Konfigurationsmanagement?

IaC erzeugt und verwaltet Ressourcen: Netze, virtuelle Maschinen oder Cluster entstehen aus deklarativen Definitionen. Konfigurationsmanagement kümmert sich um das Innenleben bereits vorhandener Systeme, etwa installierte Software und Dienste. Beide ergänzen sich in klassischen Umgebungen. In Container-Plattformen verliert Konfigurationsmanagement an Gewicht, weil Konfiguration ins Image wandert und Systeme unveränderlich betrieben werden.