Wenn sich die Infrastruktur außerhalb Ihrer Pipeline ändert: Drift, Richtlinien und praktische Governance

Stellen Sie sich vor: Sie haben Bereitschaftsdienst um 2 Uhr morgens. Ein Produktionsvorfall läuft, und jemand im Team muss vorübergehend einen Port in einer Security Group öffnen, um ein Konnektivitätsproblem zu debuggen. Die Person meldet sich in der Cloud-Konsole an, nimmt die Änderung vor, und der Vorfall ist behoben. Alle atmen erleichtert auf.

Drei Wochen später, bei einer routinemäßigen Sicherheitsüberprüfung, stellen Sie fest, dass dieser Port immer noch für das gesamte Internet offen ist. Niemand hat daran gedacht, ihn zu schließen. Niemand hat die Änderung dokumentiert. Und Ihre Infrastructure-as-Code-Pipeline geht immer noch davon aus, dass diese Security Group geschlossen ist.

Das ist Infrastructure Drift. Es passiert in jeder Organisation, die echte Systeme betreibt. Die Frage ist nicht, ob es passieren wird, sondern wie Sie damit umgehen, wenn es passiert.

Warum ein Verbot manueller Änderungen nicht funktioniert

Die naheliegende Antwort scheint zu sein: Verbieten Sie einfach alle manuellen Änderungen. Alles muss durch die Pipeline gehen. Keine Ausnahmen.

In der Praxis scheitert dieser Ansatz aus drei Gründen.

Erstens: Notfälle passieren. Wenn ein Produktionssystem ausgefallen ist, ist es nicht akzeptabel, 15 Minuten auf einen Pipeline-Durchlauf zu warten. Ingenieure werden einen Weg finden, die Änderung direkt vorzunehmen – und das sollten sie auch können.

Zweitens: Nicht alle Änderungen sind gleich. Das Hinzufügen eines Tags zu einer Ressource oder das Aktualisieren einer Beschreibung unterscheidet sich grundlegend von der Änderung einer Datenbank-Security-Group. Beides gleich zu behandeln, schafft unnötige Reibung für risikoarme Änderungen.

Drittens: Durchsetzung ist schwierig. Sie können jemanden mit Zugriff auf die Cloud-Konsole nicht physisch daran hindern, auf einen Button zu klicken. Und wenn Sie den Konsolenzugriff vollständig entfernen, schaffen Sie Engpässe für legitime Fehlerbehebungen.

Der bessere Ansatz ist nicht, manuelle Änderungen zu verbieten, sondern sie zu steuern.

Policy as Code: Regeln, die sich tatsächlich selbst durchsetzen

Die meisten Organisationen haben Richtlinien für Infrastrukturänderungen. Sie sind normalerweise irgendwo in einem Dokument festgehalten: „Alle Änderungen an der Produktion müssen den Change-Management-Prozess durchlaufen.“ Aber Dokumente setzen nichts durch. Sie existieren einfach nur.

Policy as Code ändert das. Tools wie Open Policy Agent (OPA) oder HashiCorp Sentinel ermöglichen es Ihnen, Regeln in Code zu schreiben und an Durchsetzungspunkte zu binden. Wenn jemand versucht, eine Ressource über die Cloud-Konsole zu ändern, oder wenn ein API-Aufruf direkt eingeht, bewertet die Policy-Engine die Anfrage anhand Ihrer Regeln, bevor sie sie zulässt.

Hier ist ein konkretes Beispiel. Sie schreiben eine Richtlinie, die besagt: „Keine Security Group darf Port 22 für 0.0.0.0/0 geöffnet haben, es sei denn, die Änderung kommt über die genehmigte Pipeline.“ Wenn ein Ingenieur in Panik während eines Vorfalls versucht, SSH von der AWS-Konsole aus für die Welt zu öffnen, blockiert die Richtlinie die Änderung. Oder zumindest protokolliert sie den Versuch und fordert eine zusätzliche Genehmigung an.

Hier ist zum Beispiel eine HashiCorp-Sentinel-Richtlinie, die für jede Ressource ein managed-by-Tag vorschreibt und so sicherstellt, dass Änderungen außerhalb der Pipeline nachvollziehbar sind:

# Require all resources to have a "managed-by" tag
import "tfplan/v2" as tfplan

# Get all resources that will be created or updated
all_resources = tfplan.resource_changes.all

# Rule: every resource must have a "managed-by" tag
mandatory_tag = "managed-by"

main = rule {
  all all_resources as _, rc {
    rc.applied.tags[mandatory_tag] else null != null
  }
}

Diese Richtlinie wird als Wächter in Ihre CI/CD-Pipeline integriert. Wenn eine Ressource ohne das Tag bereitgestellt wird, schlägt die Pipeline fehl und verhindert so, dass unverfolgte Änderungen die Produktion erreichen.

Dieser Ansatz liefert Ihnen zwei Dinge. Erstens: klare Grenzen, die nicht von menschlicher Disziplin abhängen. Zweitens: automatische Prüfpfade. Jede Policy-Entscheidung wird aufgezeichnet: wer was wann von wo aus ändern wollte und ob dies erlaubt oder verweigert wurde.

Richtlinien entwerfen, die unter Druck nicht versagen

Ein häufiger Fehler ist, Richtlinien zu starr zu gestalten. Wenn Ihre Richtlinie jede manuelle Änderung ohne Ausnahme blockiert, schaffen Sie eine Situation, in der Ingenieure Wege finden, sie vollständig zu umgehen. Oder schlimmer noch: Sie haben Angst, in echten Notfällen zu handeln.

Die Lösung besteht darin, Richtlinien unter Berücksichtigung der betrieblichen Realität zu entwerfen.

Ein Muster ist der Break-Glass-Mechanismus. In bestimmten definierten Notfallsituationen kann ein Ingenieur eine Richtlinie außer Kraft setzen. Die Außerkraftsetzung wird mit einem Grund protokolliert, und nach dem Vorfall überprüft das Team, ob die Änderung in IaC übernommen oder zurückgesetzt werden soll. Das gibt Ihnen Sicherheit ohne Lähmung.

Ein weiteres Muster ist die Klassifizierung von Änderungen nach Risiko. Risikoarme Änderungen wie das Hinzufügen von Tags, das Aktualisieren von Beschreibungen oder das Ändern nichtkritischer Konfigurationen können frei erlaubt werden. Hochriskante Änderungen wie das Ändern von Netzwerkzugriffen, Sicherheitsrichtlinien oder Datenbankkonfigurationen müssen durch die Pipeline gehen. Die Policy-Engine setzt diese Unterscheidung automatisch durch, sodass Sie nicht jedes Mal einen Menschen entscheiden lassen müssen.

Verbindung von Richtlinien und Drift-Erkennung

Richtlinien und Drift-Erkennung funktionieren am besten, wenn sie miteinander verbunden sind. So sieht der Ablauf in der Praxis aus.

Ihr Drift-Scanner läuft regelmäßig und findet Unterschiede zwischen Ihren IaC-Definitionen und der tatsächlichen Infrastruktur. Anstatt jede Abweichung als Problem zu kennzeichnen, überprüft das System jede Abweichung gegen Ihre Richtlinien.

Das folgende Diagramm zeigt, wie Policy-Durchsetzung und Drift-Erkennung in einer kontinuierlichen Governance-Schleife interagieren.

flowchart TD A[IaC Pipeline] -->|Deploy| B[Infrastructure] C[Manual Change] -->|Emergency or direct action| B B -->|Drift Scanner| D{Drift Detected?} D -->|Yes| E[Policy Engine] D -->|No| F[No Action] E --> G{Policy Check} G -->|Approved Exception| H[Mark as Known & Allowed] G -->|Violation| I[Flag for Remediation] G -->|No Match| J[Queue for Manual Review] H --> K[Post-Incident Review] I --> K J --> K K -->|Adopt into IaC| A K -->|Roll back| B

Wenn die Änderung über eine genehmigte Policy-Ausnahme vorgenommen wurde, wird sie als „bekannt und erlaubt“ markiert. Wenn die Änderung gegen eine Richtlinie verstößt, wird sie zur sofortigen Behebung gekennzeichnet. Wenn die Änderung keiner Policy-Regel entspricht, wird sie zur manuellen Überprüfung in eine Warteschlange gestellt.

Das verändert die Sichtweise Ihres Teams auf Drift. Drift ist nicht länger nur ein Fehler, der behoben werden muss. Es ist ein Signal, das interpretiert werden muss. Handelt es sich um eine legitime Notfalländerung, die noch nicht in Code übernommen wurde? Handelt es sich um einen Policy-Verstoß? Handelt es sich um eine Änderung, die durch die Pipeline hätte gehen sollen, es aber nicht getan hat?

Mit Richtlinien und Governance können Sie diese Fälle unterscheiden, ohne jeden einzelnen manuell untersuchen zu müssen. Und da Richtlinien als Code geschrieben sind, können sie wie jeder andere Code überprüft, versioniert und getestet werden. Sie sind keine verstaubten Dokumente in einem freigegebenen Ordner.

Praktische Checkliste für Policy-gesteuerte Governance

Wenn Sie Richtlinien und Governance für Infrastrukturänderungen einrichten, finden Sie hier eine kurze Checkliste:

  • Identifizieren Sie die Arten von Änderungen, die in Ihrer Umgebung am riskantesten sind (Security Groups, Datenbankkonfigurationen, IAM-Rollen)
  • Schreiben Sie Richtlinien, die diese Änderungen außerhalb der Pipeline blockieren, mit klaren Ausnahmepfaden
  • Implementieren Sie einen Break-Glass-Mechanismus für Notfälle mit obligatorischer Überprüfung nach dem Vorfall
  • Verbinden Sie Ihre Policy-Engine mit Ihren Drift-Erkennungstools
  • Klassifizieren Sie Änderungen nach Risikostufe und wenden Sie entsprechend unterschiedliche Regeln an
  • Richten Sie eine automatische Audit-Protokollierung für jede Policy-Entscheidung ein
  • Überprüfen Sie Policy-Ausnahmen regelmäßig und übernehmen Sie sie in IaC oder setzen Sie sie zurück

Das Fazit

Infrastructure Drift ist kein Problem, das Sie einmal lösen. Es ist ein Zustand, den Sie kontinuierlich managen. Das Ziel ist nicht, alle manuellen Änderungen zu eliminieren, sondern von ihnen zu wissen, sie zu steuern und zu entscheiden, welche dauerhafte Bestandteile Ihrer Infrastruktur werden sollen.

Policy as Code gibt Ihnen die Möglichkeit, Grenzen durchzusetzen, ohne legitime Arbeit zu blockieren. Drift-Erkennung gibt Ihnen Einblick in das, was tatsächlich passiert. Zusammen verwandeln sie das Infrastrukturmanagement von einem reaktiven Feuergefecht in ein System, dem Sie vertrauen können – selbst wenn um 2 Uhr morgens etwas schiefgeht.