Wenn sich die Infrastruktur außerhalb Ihrer Pipeline ändert: Drift-Erkennung für Policy-Compliance

Sie haben Richtlinien definiert. Sie haben automatisierte Prüfungen in Ihrer CI/CD-Pipeline. Jedes Deployment durchläuft eine Validierung, bevor es in die Produktion geht. Ihr Team ist zuversichtlich, dass die Infrastruktur die Regeln einhält.

Dann muss jemand im Team um 22 Uhr ein Produktionsproblem debuggen. Sie loggen sich in die Cloud-Konsole ein, öffnen einen Port in einer Security Group für ihre Heim-IP, beheben das Problem und gehen ins Bett. Sie vergessen, die Änderung rückgängig zu machen. Am nächsten Morgen ist diese Security Group immer noch offen. Ihre Pipeline hat nie davon erfahren. Ihre Richtlinien haben es nie bemerkt.

Dieses Szenario ist nicht selten. Es passiert, wenn Ingenieure bei Incidents Abkürzungen nehmen, wenn ein anderes Team Ressourcen manuell erstellt, weil Ihre Pipeline zu langsam erscheint, oder wenn Auto-Scaling neue Instanzen mit Standardkonfigurationen startet, die gegen Ihre Richtlinien verstoßen. All diese Änderungen finden außerhalb Ihrer CI/CD-Pipeline statt, sodass die Policy-Prüfungen, die Sie sorgfältig in Ihre Plan- und Apply-Schritte eingebaut haben, sie nie zu sehen bekommen.

Was Drift-Erkennung eigentlich bedeutet

Drift-Erkennung ist der Prozess, bei dem der tatsächliche Zustand Ihrer Infrastruktur mit dem verglichen wird, was Ihre Richtlinien vorgeben. Sie läuft regelmäßig – jede Stunde, jeden Tag oder in einem für Ihr Team sinnvollen Rhythmus – und meldet, welche Ressourcen von den Regeln abgewichen sind.

Das Ziel ist nicht, Änderungen zu verhindern. Das erledigen bereits Ihre Pipeline-Richtlinien, indem sie nicht-konforme Deployments blockieren, bevor sie stattfinden. Die Drift-Erkennung fängt Änderungen auf, die bereits außerhalb Ihrer Pipeline stattgefunden haben. Sie ist Ihr Sicherheitsnetz für die Infrastruktur, die Sie nicht allein durch Automatisierung kontrollieren können.

Wie Drift-Erkennung in der Praxis funktioniert

Die Mechanik ist einfach. Ein Tool oder Skript ruft die API Ihres Cloud-Anbieters auf, um alle vorhandenen Ressourcen aufzulisten. Dann prüft es jede Ressource einzeln gegen Ihre definierten Richtlinien.

Hier ist ein einfaches Bash-Skript, das einen Terraform-Plan ausführt und alarmiert, wenn Drift erkannt wird:

#!/bin/bash
# Scheduled drift detection script (run via cron every hour)
cd /path/to/terraform/project
terraform init -input=false > /dev/null 2>&1
terraform plan -detailed-exitcode -input=false -no-color > plan_output.txt 2>&1
EXIT_CODE=$?
if [ $EXIT_CODE -eq 2 ]; then
  echo "Drift detected at $(date)" >> drift_alerts.log
  # Send notification (e.g., Slack webhook)
  curl -s -X POST -H 'Content-type: application/json' \
    --data "{\"text\":\"Drift detected in production infrastructure. Check plan_output.txt for details.\"}" \
    https://hooks.slack.com/services/YOUR/WEBHOOK/URL
elif [ $EXIT_CODE -eq 1 ]; then
  echo "Terraform plan failed at $(date)" >> drift_alerts.log
fi

Ihre Richtlinie besagt zum Beispiel, dass keine Security Group Port 22 für 0.0.0.0/0 geöffnet haben darf. Die Drift-Erkennung scannt jede Security Group und markiert jeden Verstoß. Oder Ihre Richtlinie verlangt einen owner-Tag auf jeder Ressource. Die Drift-Erkennung inventarisiert alle Ressourcen und markiert diejenigen, denen der Tag fehlt.

Die Ergebnisse müssen an einem Ort landen, den Ihr Team auch tatsächlich einsehen kann. Ein Dashboard funktioniert. Slack- oder E-Mail-Benachrichtigungen funktionieren. Ein automatisiertes Ticket in Ihrem Tracking-System funktioniert. Was nicht funktioniert, ist das Erstellen eines Berichts, den niemand liest. Jemand muss für das Follow-up verantwortlich sein, sonst wird die Drift-Erkennung zu Rauschen.

Tools, die Ihnen bei der Drift-Erkennung helfen

Mehrere Tools bieten bereits Drift-Erkennungsfunktionen. Terraform hat terraform plan, das Unterschiede zwischen Ihrer Statusdatei und der tatsächlichen Infrastruktur anzeigen kann. Dies hilft jedoch nur bei Ressourcen, die über Terraform verwaltet werden. Ressourcen, die außerhalb von Terraform erstellt wurden, erfordern einen anderen Ansatz.

Cloud-native Tools können breit scannen. AWS Config, Azure Policy und Google Cloud Asset Inventory durchsuchen Ressourcen mit ihren nativen APIs. Sie verstehen das Ressourcenmodell des Cloud-Anbieters tiefgehend und können die Compliance über alles in Ihrem Konto hinweg prüfen.

Es gibt auch Open-Source-Optionen. Open Policy Agent (OPA) kann als Policy-Engine ausgeführt werden, die Sie regelmäßig gegen Ihre Infrastruktur auslösen. Sie schreiben Richtlinien in Rego, und OPA wertet sie gegen die von Ihnen bereitgestellten Ressourcendaten aus.

Der schwierige Teil: Was tun, wenn Sie Drift finden?

Drift zu finden ist nur die halbe Arbeit. Die schwierigere Frage ist, was als nächstes passiert.

Gute Drift-Berichte enthalten genügend Informationen, um das Problem zu beheben. Sie sagen Ihnen, welche Ressource gegen welche Richtlinie verstoßen hat und idealerweise, wie Sie sie korrigieren können. Einige Teams gehen noch weiter und implementieren eine automatische Behebung – wenn Drift erkannt wird, setzt das System die Ressource automatisch wieder in den konformen Zustand zurück.

Automatische Behebung klingt großartig, bis sie Ihnen auf die Füße fällt. Wenn ein Ingenieur während der Fehlersuche an einem Produktionsincident vorübergehend einen Port geöffnet hat, könnte die automatische Behebung diesen Port schließen, während er noch daran arbeitet. Das Tool würde einen Policy-Verstoß beheben, während es eine aktive Untersuchung stört. Sie müssen unterscheiden zwischen Drift, die versehentlich entstanden ist, und Drift, die absichtlich für einen kurzfristigen Zweck vorgenommen wurde.

Ein praktischer Ansatz ist, mit Alarmierung und manueller Behebung zu beginnen. Lassen Sie das Team wissen, wenn Drift auftritt, geben Sie ihm die Details, und lassen Sie es entscheiden, ob es sofort behoben oder als temporäre Ausnahme dokumentiert werden soll. Sobald Sie die Muster der Drift in Ihrer Umgebung verstehen, können Sie eine Automatisierung für die Fälle in Betracht ziehen, die immer falsch und niemals gerechtfertigt sind.

Drei Schutzebenen

Die Drift-Erkennung vervollständigt Ihren Policy-Durchsetzungszyklus. Betrachten Sie es als drei Ebenen, die sich gegenseitig blinde Flecken abdecken:

Das folgende Diagramm zeigt, wie diese drei Ebenen interagieren:

flowchart TD A[Code Change] --> B[Plan Time Policy Check] B -->|Pass| C[Apply Time Policy Check] B -->|Fail| D[Block Deployment] C -->|Pass| E[Deploy to Production] C -->|Fail| D E --> F[Running Infrastructure] F --> G[Manual Change / Incident Fix] G --> H[Drift Detection Scan] H -->|Compliant| I[No Action] H -->|Drift Found| J[Alert Team] J --> K[Manual Remediation] K --> F J --> L[Automatic Remediation] L --> F
  1. Policy-Prüfung zur Planungszeit – Verhindert Verstöße, bevor sie die Produktion erreichen
  2. Policy-Prüfung zur Ausführungszeit – Fängt alles ab, was durch die Planung gerutscht ist
  3. Regelmäßige Drift-Erkennung – Findet Änderungen, die außerhalb der Pipeline stattgefunden haben

Keine einzelne Ebene ist ausreichend. Pipeline-Prüfungen können manuelle Konsolenänderungen nicht abfangen. Die Drift-Erkennung kann Verstöße nicht von vornherein verhindern. Zusammen ergeben sie eine Abdeckung, die Ihre Infrastruktur im Einklang mit Ihren Richtlinien hält, selbst wenn sich Dinge außerhalb Ihrer automatisierten Workflows ändern.

Praktische Checkliste

  • Wählen Sie einen Rhythmus für Drift-Scans basierend darauf, wie schnell sich Ihre Infrastruktur ändert
  • Wählen Sie Tools, die sowohl verwaltete als auch nicht verwaltete Ressourcen in Ihrer Umgebung abdecken
  • Senden Sie Drift-Berichte an einen Kanal, den Ihr Team tatsächlich überwacht
  • Weisen Sie die Verantwortung für das Nachverfolgen von Drift-Ergebnissen zu
  • Beginnen Sie mit manueller Behebung, bevor Sie Automatisierung in Betracht ziehen
  • Dokumentieren Sie temporäre Ausnahmen, damit Ihr Team weiß, welche Drifts beabsichtigt sind

Was das für Ihr Team bedeutet

Ihre Richtlinien sind nur so stark wie Ihre Fähigkeit, sie überall dort durchzusetzen, wo sich die Infrastruktur ändert. Pipeline-Prüfungen kümmern sich um die Änderungen, die Sie kontrollieren. Die Drift-Erkennung kümmert sich um die Änderungen, die Sie nicht kontrollieren. Ohne beides ist Ihre Richtlinie ein Dokument, das beschreibt, was wahr sein sollte, und kein Mechanismus, der es wahr hält. Bauen Sie die Drift-Erkennung in Ihren Betrieb ein, und Ihre Infrastruktur bleibt konform, selbst wenn das Unerwartete eintritt.