Jede Infrastruktur driftet. Nicht weil Teams schlechte Arbeit leisten, sondern weil produktive Systeme leben: Hotfixes werden eingespielt, Konfigurationen manuell angepasst, Abhängigkeiten aktualisiert und Notfalllösungen in laufende Umgebungen gebracht – oft ohne sofortige Dokumentation im zugehörigen Infrastructure-as-Code-Repository. Das Ergebnis ist ein wachsender Graben zwischen dem, was im Code steht, und dem, was tatsächlich auf den Servern läuft.
Genau dieser Graben ist eine der häufigsten Ursachen für schwer reproduzierbare Incidents, gescheiterte Rollbacks und Sicherheitslücken. Und er ist systematisch vermeidbar – wenn die richtigen Werkzeuge konsequent eingesetzt werden.
Was Infrastruktur-Drift bedeutet
Infrastruktur-Drift bezeichnet den Zustand, in dem der tatsächlich konfigurierte Zustand eines Systems von der definierten Baseline abweicht. Diese Baseline kann ein Terraform-State, ein Ansible-Playbook, ein Helm-Chart oder ein CloudFormation-Template sein – entscheidend ist, dass eine definierte Erwartung existiert, mit der der Ist-Zustand verglichen werden kann.
Drift entsteht auf verschiedenen Wegen: durch manuelle Eingriffe, durch automatisierte Prozesse, die nicht alle Zustandsänderungen erfassen, durch Systemaktualisierungen mit Seiteneffekten oder durch kurzfristige Notfallanpassungen, die nie rückgebaut wurden. In Kubernetes-Umgebungen ist Drift besonders heimtückisch, weil der deklarative Ansatz von außen betrachtet scheinbar Kontrolle gibt – während einzelne Pods, ConfigMaps oder Secrets manuell verändert werden können, ohne dass die Änderung im GitOps-Flow sichtbar ist.
Herkömmliche Drift-Detection und ihre Grenzen
Klassische IaC-Tools bieten rudimentäre Drift-Detection: terraform plan zeigt Abweichungen zwischen State-Datei und tatsächlichem Infrastrukturzustand. Kubernetes-native Tools wie kubectl diff oder ArgoCD vergleichen laufende Workloads mit der definierten Konfiguration. Das Problem liegt nicht in der Erkennung selbst, sondern in der Klassifizierung und Reaktion.
Ein terraform plan-Output mit hundert Änderungen sagt einem Team nicht, welche Änderungen kritisch sind, welche bewusst vorgenommen wurden und welche durch externe Einflüsse entstanden. Ohne diesen Kontext bleibt Drift-Detection ein manueller Review-Prozess, der bei Zeitdruck regelmäßig abgekürzt wird.
Wo KI den Unterschied macht
KI-gestützte Drift-Detection geht einen Schritt weiter als das bloße Aufzeigen von Unterschieden. Sprachmodelle können in den Analyse-Workflow integriert werden und dabei helfen, Abweichungen zu priorisieren und zu kontextualisieren. Ein LLM, dem der aktuelle Diff sowie Metadaten über den betroffenen Service, seine Kritikalität und seine Änderungshistorie übergeben werden, kann in Sekunden einschätzen, ob eine Konfigurationsänderung ein bekanntes, unproblematisches Muster darstellt oder ein unerwartetes Sicherheitsrisiko.
Dieser Ansatz hat sich in mehreren Open-Source-Projekten und kommerziellen Plattformen durchgesetzt. Werkzeuge wie Driftctl (inzwischen unter dem Dach von Snyk), AWS Config in Kombination mit Config Rules oder ArgoCD Sync-Policies bieten strukturierte Diff-Erkennung. Erste Integrationen ergänzen dies mit LLM-basierten Erklärungen und Priorisierungsvorschlägen, die Teams direkt in Tickets oder Slack-Nachrichten erhalten.
Automatisierte Remediation: Wann sie sinnvoll ist
Auto-Remediation – also das automatische Zurücksetzen von Drift auf den definierten Soll-Zustand – ist verlockend, aber nicht immer die richtige Antwort. Folgende Faustregel hat sich bewährt: Stateless, idempotent und low-impact bedeutet Automatisierung; stateful, kritisch oder potenziell datenverlustreich bedeutet Eskalation.
Konkret: Wenn ein Nginx-Konfigurationsparameter auf einem Staging-Server abweicht, ist ein automatischer Reset über Ansible sinnvoll und sicher. Wenn eine Datenbankverbindung auf einem Produktivsystem manuell angepasst wurde, will ein Team zuerst verstehen warum – bevor eine Automatisierung sie überschreibt und möglicherweise einen Incident verursacht.
Moderne Ansätze verbinden beides: Ein Agent erkennt Drift, klassifiziert dessen Kritikalität per KI und löst entweder einen automatischen Reset aus oder erstellt ein Ticket mit dem vollständigen Kontext für menschliche Prüfung. Dieser Prozess lässt sich gut mit Monitoring-Systemen verbinden: Der Remediation-Agent sendet nach erfolgreicher Korrektur ein Heartbeat-Signal – bleibt es aus, schlägt das Monitoring automatisch Alarm.
Praktisches Setup: Drift-Detection mit KI-Klassifizierung
Ein pragmatisches Setup für Teams, die KI-gestützte Drift-Detection einführen wollen, besteht aus drei Schichten:
- Erkennung: Terraform Plan, AWS Config, ArgoCD oder Driftctl liefern strukturierte Diffs im maschinenlesbaren Format (JSON/YAML).
- Klassifizierung: Ein LLM erhält den Diff sowie Kontext über den betroffenen Service und gibt eine strukturierte Einschätzung zurück: Kategorie (sicherheitsrelevant / funktional / kosmetisch), Herkunftsvermutung (manuell / automatisiert / extern) und empfohlene Aktion.
- Reaktion: Abhängig von der Klassifizierung wird automatisch remediert, ein Alert ausgelöst oder ein strukturiertes Ticket erstellt – inklusive Kontext und Begründung vom LLM.
Dieser dreistufige Ansatz lässt sich gut in bestehende CI/CD-Pipelines integrieren. Die Klassifizierung per LLM erhöht den Aufwand minimal, reduziert aber den manuellen Review-Anteil erheblich und verbessert die Signalqualität für On-Call-Teams deutlich.
Sicherheitsaspekte: Wer darf was korrigieren?
Automatisierte Remediation braucht klare Berechtigungsstrukturen. Der Agent, der Drift erkennt und behebt, sollte im Principle of Least Privilege operieren: nur die Rechte haben, die für den jeweiligen Ressourcentyp notwendig sind. Ein Agent, der Nginx-Konfigurationen zurücksetzen kann, braucht keinen Datenbankzugriff.
Ebenso wichtig ist ein vollständiges Audit-Log aller automatisierten Korrekturen. In Umgebungen mit Compliance-Anforderungen (SOC 2, ISO 27001) ist Nachvollziehbarkeit keine optionale Ergänzung, sondern eine Voraussetzung dafür, dass automatisierte Systeme überhaupt eingesetzt werden dürfen.
Fazit: Kontrolle zurückgewinnen
Infrastruktur-Drift ist kein Zeichen schlechter Arbeit – er ist ein strukturelles Merkmal produktiver Systeme. Die Frage ist nicht, ob Drift entsteht, sondern ob er erkannt und bewertet wird, bevor er zum Problem wird. KI-gestützte Klassifizierung macht Drift-Detection von einer Pflichtübung zu einem echten Kontrollwerkzeug: einem, das zwischen kritischer Abweichung und harmlosem Konfigurationsrauschen unterscheidet und die richtigen Maßnahmen anstößt.
Teams, die diesen Ansatz etablieren, gewinnen nicht nur mehr Sicherheit in ihren produktiven Umgebungen – sie bauen auch ein besseres Verständnis dafür auf, warum ihre Systeme sind, wie sie sind. Und das ist die Grundlage für jede sinnvolle Automatisierung, die darüber hinausgeht.
Quellen: HashiCorp Terraform Drift Detection Docs (developer.hashicorp.com), Snyk Infrastructure as Code Dokumentation, ArgoCD Sync Status Docs (argo-cd.readthedocs.io), NIST SP 800-128 Configuration Management Security.
