Unsere Null-Drift-Politik: Warum Configuration Drift bei uns nicht vorkommt

Configuration Drift passiert nicht durch Fahrlässigkeit. Er passiert durch die normalen Vorgänge im IT-Betrieb: ein Hotfix, der unter Zeitdruck direkt auf dem System gemacht wurde. Eine Konfigurationsänderung, die in einem Ticket dokumentiert ist, aber nie ins Repository übernommen wurde. Zwei Umgebungen, die aus derselben Vorlage entstanden sind und sich über 18 Monate auseinanderentwickelt haben.

In einer nicht-regulierten Umgebung ist das ein operatives Problem. In einer regulierten Umgebung - Banken, Versicherungen, KRITIS-Betreiber - ist es ein Compliance-Ereignis.

Was Configuration Drift konkret bedeutet

Drift beschreibt den Zustand, in dem ein System nicht mehr dem definierten Sollzustand entspricht. Das kann sich zeigen als:

ein manuell gesetzter Parameter, der einer Security-Policy widerspricht
ein Dienst, der nach einem manuellen Eingriff anders läuft als konfiguriert
zwei Systeme in einem Cluster mit unterschiedlichen TLS-Konfigurationen, weil ein Patch auf einem nicht vollständig angewendet wurde
eine Konfigurationsdatei, die nach einem Notfall-Eingriff vor Ort nicht zurückgesetzt wurde

Das Problem bei Drift ist nicht nur das, was abweicht. Es ist, dass der abweichende Zustand oft nicht bekannt ist. Der nächste Auditor findet einen Systemzustand, der keine dokumentierte Herkunft hat. Das ist schwer zu erklären.

Warum manuelle Prüfungen nicht ausreichen

Die klassische Antwort auf Drift ist ein regelmäßiges Compliance-Review: jemand geht in definierten Abständen durch die Systeme und prüft, ob alles noch stimmt. Das funktioniert bis zu einem gewissen Systemumfang.

Sobald die Anzahl der Systeme steigt, versagt dieses Modell aus zwei Gründen. Erstens ist es ressourcenintensiv: Wer bei 40 JBoss-Instanzen manuell prüfen will, bindet erhebliche Engineering-Kapazität für eine Prüftätigkeit, die auch automatisiert werden könnte. Zweitens ist es fehleranfällig: Manuelle Prüfungen hängen an Personen, an deren Aufmerksamkeit und daran, was im Checklistenformat abfragbar ist. Was nicht auf der Checkliste steht, wird nicht geprüft.

In regulierten Umgebungen müssen Controls wiederholbar, nachweisbar und unabhängig von einzelnen Personen sein. Ein manuelles Verfahren erfüllt das per Definition nicht zuverlässig.

Baseline-Enforcement als erster Schritt

Unser Ansatz beginnt mit einer maschinenlesbaren Definition des Sollzustands. Jede Konfigurationsentscheidung - welche TLS-Version erlaubt ist, welche Audit-Events geloggt werden, wie Dateirechte auf kritischen Verzeichnissen gesetzt sind - ist in einem Ansible-Playbook abgebildet.

Dieses Playbook ist nicht nur ein Installations-Script. Es ist die normative Beschreibung des Sollzustands. Wenn das Playbook läuft, stellt es diesen Zustand her - unabhängig davon, was vorher manuell geändert wurde. Idempotenz ist hier kein technisches Detail, sondern die Grundlage dafür, dass Baseline-Enforcement funktioniert.

Der erste Schutzwall gegen Drift ist damit präventiv: nach jedem Deployment, nach jedem Patch-Zyklus, bei definiertem Anlass läuft das Playbook und korrigiert Abweichungen.

Scheduled Drift Detection

Präventiver Enforcement reicht nicht, wenn manuelle Eingriffe zwischen zwei Playbook-Läufen passieren. Dafür gibt es automatisierte Drift-Detection-Läufe.

In SPAS werden Drift-Detection-Runs als planbare Ansible-Jobs ausgeführt. Sie vergleichen den Istzustand eines Systems mit dem definierten Sollzustand und erzeugen einen Bericht: welche Controls erfüllt sind, welche abweichen, seit wann die Abweichung besteht. Der Bericht landet automatisch - als JSON für die SIEM-Integration oder als PDF für das Compliance-Team.

Das Ergebnis ist eine zeitliche Dokumentation des Konfigurationszustands. Wenn ein Auditor fragt, welchen Konfigurationsstand ein System an einem bestimmten Datum hatte, ist das eine lösbare Frage, keine Rechercheaufgabe.

Immutable Deployment Patterns

Ein weiterer Baustein ist die Kontrolle über den Ausgangspunkt. Wenn ein neues System aus einem nicht geprüften, nicht dokumentierten Image deployt wird, beginnt Drift nicht erst nach dem ersten manuellen Eingriff - er beginnt mit dem Deployment.

Deshalb setzen wir auf Golden Images. Jedes Image, das in produktiven Umgebungen eingesetzt wird, entsteht aus einer kontrollierten Pipeline: CIS-Level-2-Hardening, automatische Konfigurationsvalidierung, Signatur und Versionierung. Das Ergebnis ist ein Image mit bekanntem Zustand, dokumentierter Herkunft und einem Referenzpunkt für alle nachgelagerten Drift-Detection-Läufe.

Kein System läuft aus einer ungeprüften Basis. Das eliminiert eine ganze Klasse von Drift-Ursachen.

Audit Trails als erste Klasse

In vielen Umgebungen entstehen Audit-Nachweise nachträglich: Logs werden exportiert, Tickets rekonstruiert, Screenshots zusammengesucht. Das ist fehleranfällig und bindet Kapazität genau dann, wenn ein Audit ansteht.

Unser Ansatz behandelt Audit-Trails als integralen Bestandteil des Betriebs, nicht als Nebenprodukt. Jeder Playbook-Lauf erzeugt einen signierten, zeitgestempelten Bericht. Jede Konfigurationsänderung ist im Repository versioniert. Jeder Deployment-Lauf hat eine nachvollziehbare Herkunft.

Das ist kein zusätzlicher Aufwand. Es ist der normale Betriebsprozess, so gestaltet, dass Nachweise automatisch entstehen.