Wenn Infrastruktur das Produkt ist: IaC-Governance und Drift-Erkennung

Stellen Sie sich vor, Sie sind verantwortlich für Hunderte oder Tausende von Servern, verteilt über mehrere Cloud-Anbieter und Regionen. Ihr Unternehmen könnte ein Cloud-Service-Provider, eine große E-Commerce-Plattform oder ein Tech-Unternehmen sein, dessen Infrastruktur gleichzeitig in Singapur, Frankfurt und Virginia läuft.

In dieser Umgebung ist Infrastruktur nicht nur der Ort, an dem Anwendungen laufen. Infrastruktur ist das Produkt. Jede Konfigurationsänderung – das Hinzufügen einer Firewall-Regel, das Skalieren einer Datenbank-Instanz, das Anpassen eines Load-Balancer-Parameters – kann Dutzende von Diensten auf einmal betreffen. Eine falsche Konfiguration bringt nicht nur eine Anwendung zum Absturz. Sie bringt Hunderte von Diensten zu Fall, die von dieser gemeinsamen Infrastruktur abhängen.

Das ist eine andere Welt als die Bereitstellung einer einzelnen Webanwendung. Die Risiken sind höher, der Schadensradius ist größer, und die Fehlertoleranz liegt nahe Null.

Das Konsistenzproblem, das zu IaC führt

Wenn Infrastruktur manuell über SSH-Sitzungen oder Cloud-Dashboards verwaltet wird, schleichen sich schnell Inkonsistenzen ein. Ihre Staging-Umgebung hat leicht andere Firewall-Regeln als die Produktion. Ihr Produktionssetup in Asien unterscheidet sich von dem in Europa. Niemand kann mit Sicherheit sagen, welche Konfiguration gerade tatsächlich läuft.

In diesem Moment greifen Teams zu Infrastructure as Code (IaC). Sie schreiben die gesamte Infrastrukturkonfiguration als Code, speichern sie in Git und wenden sie automatisch über Pipelines an. Terraform, Pulumi, AWS CDK oder CloudFormation werden zu Ihren primären Werkzeugen. Jeder Server, jede Netzwerkregel und jeder Storage-Bucket ist in der Versionskontrolle definiert.

Aber das Schreiben von Konfiguration als Code ist nur der erste Schritt. Sobald Ihre Infrastruktur in Code lebt, stellt sich eine neue Frage: „Wie stellen wir sicher, dass jede Änderung unseren Richtlinien folgt, bevor sie in die Produktion gelangt?“

IaC-Governance: Automatisierte Richtlinien, keine Bürokratie

Governance klingt nach einem Wort, das Dinge verlangsamt. In der Praxis ist IaC-Governance das Gegenteil. Es sind automatisierte Leitplanken, die jede Änderung prüfen, bevor sie in die Produktion gelangt – ohne dass ein Mensch jede einzelne Konfigurationszeile lesen muss.

So funktioniert es in der Praxis. Ihr Sicherheitsteam legt fest, dass alle Storage-Buckets verschlüsselt sein müssen. Ihr Compliance-Team schreibt vor, dass alle Datenbank-Instanzen einen bestimmten Instanztyp verwenden. Ihr Netzwerkteam verlangt, dass keine Firewall-Regel die Ports 22 oder 3306 für das öffentliche Internet öffnet.

Das folgende Diagramm zeigt den automatisierten Governance-Pipeline-Ablauf vom Code-Commit über die Bereitstellung bis zur Drift-Erkennung:

flowchart TD A[Commit IaC Code] --> B[Run Policy Checks] B --> C{Policy Pass?} C -->|Yes| D[Deploy to Infrastructure] C -->|No| E[Block Change & Notify] E --> A D --> F[Monitor for Drift] F --> G{Drift Detected?} G -->|No| H[Infrastructure Stable] G -->|Yes| I[Alert Team] I --> J{Auto-Remediate?} J -->|Yes| K[Reconcile to Code State] J -->|No| L[Manual Review] K --> F L --> M[Update Code or Accept Drift] M --> A

Diese Regeln werden als automatisierte Richtlinien geschrieben, die in Ihrer CI/CD-Pipeline laufen. Wenn jemand einen Pull-Request einreicht, der Infrastrukturcode ändert, wendet die Pipeline die Änderung nicht einfach an. Sie prüft zunächst jede Ressource gegen Ihre Richtlinien. Wenn eine Änderung gegen eine Richtlinie verstößt, schlägt die Pipeline fehl. Die Änderung erreicht nie die Produktion.

Hier ist ein einfaches Open Policy Agent (OPA)-Regelbeispiel, das einen Tagging-Standard durchsetzt und von jeder Ressource einen cost-center-Tag verlangt:

package terraform

# Deny any resource that doesn't have a 'cost-center' tag
violation[msg] {
  resource := input.resource_changes[_]
  resource.type in ["aws_s3_bucket", "aws_instance", "aws_db_instance"]
  not resource.change.after.tags.cost-center
  msg := sprintf("%v %v is missing required tag 'cost-center'", [resource.type, resource.address])
}

Wenn diese Richtlinie in Ihrer CI/CD-Pipeline läuft, führt jede Ressourcenänderung, der der erforderliche Tag fehlt, zum Fehlschlagen der Pipeline und verhindert, dass die fehlkonfigurierte Infrastruktur jemals die Produktion erreicht.

Hier geht es nicht darum, Genehmigungsschritte aus reiner Kontrollsucht hinzuzufügen. Es geht darum, Probleme zu erkennen, bevor sie zu Incidents werden. Ein falsch konfigurierter, öffentlich lesbarer Storage-Bucket wird nicht zum Datenleck. Eine zu kleine Datenbank-Instanz verursacht keinen Performance-Ausfall. Die Richtlinie fängt es in der Pipeline ab, und das Team behebt es, bevor es jemals läuft.

Drift: Wenn die Realität vom Code abweicht

IaC gibt Ihnen eine einzige Quelle der Wahrheit für Ihre Infrastruktur. Aber diese Wahrheit gilt nur, wenn das, was tatsächlich läuft, mit dem übereinstimmt, was in Ihrem Code steht. In der Praxis bricht diese Übereinstimmung ständig.

Drift entsteht, wenn die reale Infrastrukturkonfiguration von dem abweicht, was in Ihrem IaC-Code definiert ist. Jemand meldet sich während eines Incidents im Cloud-Dashboard an und ändert manuell eine Security-Group-Regel. Ein Teammitglied fügt über die Konsole einen Load-Balancer-Listener hinzu, weil es dringend benötigt wurde. Ein automatisierter Prozess eines anderen Teams ändert eine Ressource, ohne Ihre Pipeline zu durchlaufen.

Drift ist gefährlich, weil es Ihr IaC unzuverlässig macht. Wenn Ihr Code für einen Server Konfiguration A vorsieht, die Realität aber Konfiguration B hat, dann führen Wiederherstellung, Skalierung oder das Erstellen einer neuen Umgebung zu unerwarteten Ergebnissen. Sie können Infrastruktur nicht aus Code neu aufbauen, wenn der Code nicht der Realität entspricht.

Drift-Erkennung löst dieses Problem, indem sie periodisch den tatsächlichen Infrastrukturzustand mit Ihrem Code vergleicht. Die Pipeline führt dieselben Befehle aus, die sie zum Anwenden der Infrastruktur verwendet, jedoch im „Plan“- oder „Preview“-Modus. Sie ändert nichts. Sie vergleicht nur. Wenn sie Unterschiede findet, meldet sie diese.

Einige Teams gehen noch weiter. Wenn Drift erkannt wird, kann die Pipeline die Infrastruktur automatisch wieder in den im Code definierten Zustand versetzen. Andere ziehen es vor, das verantwortliche Team zu benachrichtigen und entscheiden zu lassen, ob der Code aktualisiert oder der Drift als beabsichtigt akzeptiert werden soll.

Umgang mit risikoreichen Änderungen

Einige Infrastrukturänderungen sind riskanter als andere. Das Ändern einer Produktionsdatenbank-Konfiguration, das Modifizieren einer Firewall-Regel, die den Hauptverkehr betrifft, oder das Verändern eines Load-Balancers, der Millionen von Anfragen bedient – diese erfordern besondere Sorgfalt.

Für solche Änderungen brauchen Sie mehr als nur automatisierte Richtlinien. Sie benötigen integrierte Genehmigungsprozesse, die innerhalb der Pipeline stattfinden, nicht außerhalb. Der Workflow sieht so aus:

  1. Ein Entwickler erstellt einen Pull-Request mit der Infrastrukturänderung.
  2. Automatisierte Richtlinien laufen und prüfen auf Verstöße.
  3. Wenn die Richtlinien bestanden werden, benachrichtigt die Pipeline die relevanten Prüfer – vielleicht einen DBA für Datenbankänderungen oder einen Netzwerkingenieur für Firewall-Änderungen.
  4. Die Prüfer genehmigen die Änderung oder fordern Änderungen direkt im Pull-Request an.
  5. Erst nachdem alle Genehmigungen vorliegen, wird die Änderung angewendet.

Der entscheidende Punkt ist, dass Genehmigung nicht Verlangsamung bedeutet. Es bedeutet, dass die richtigen Leute die richtigen Änderungen zur richtigen Zeit prüfen, mit dem gesamten Kontext, der in der Pipeline verfügbar ist. Kein Hinterherlaufen im Chat. Keine Last-Minute-Genehmigungen kurz vor Schließung eines Release-Fensters.

Praxis-Checkliste für IaC-Governance

  • Schreiben Sie automatisierte Richtlinien für jede Sicherheits- und Compliance-Regel, die für Ihre Infrastruktur gilt
  • Führen Sie Richtlinienprüfungen in Ihrer Pipeline durch, bevor eine Infrastrukturänderung angewendet wird
  • Richten Sie die Drift-Erkennung ein, die nach einem Zeitplan läuft (täglich oder wöchentlich, je nach Risikobereitschaft)
  • Entscheiden Sie, ob Drift automatisch behoben oder das Team benachrichtigt werden soll
  • Definieren Sie, welche Änderungen eine zusätzliche Genehmigung erfordern und wer die Genehmiger sind
  • Machen Sie die Genehmigung zu einem Teil der Pipeline, nicht zu einem separaten Prozess außerhalb

Das Fazit

Wenn Infrastruktur Ihr Produkt ist, sind Konsistenz und Kontrolle keine Option. IaC gibt Ihnen die Grundlage, aber Governance und Drift-Erkennung machen diese Grundlage vertrauenswürdig. Automatisierte Richtlinien fangen Probleme ab, bevor sie die Produktion erreichen. Drift-Erkennung sagt Ihnen, wann die Realität von Ihrem Code abgewichen ist. Und integrierte Genehmigungen stellen sicher, dass risikoreiche Änderungen die richtige Aufmerksamkeit erhalten, ohne zu Engpässen zu werden.

Das Ziel ist nicht, Infrastrukturänderungen zu verlangsamen. Es ist, sie sicher genug zu machen, dass Sie schnell handeln können, ohne Angst zu haben.