Configuration Drift im Endpoint Management

Überblick

Configuration Drift ist die Lücke zwischen dem, was die Sicherheitsrichtlinie eines Geräts sein soll, und dem, was sie gerade tatsächlich ist. Sie entsteht selten durch ein einzelnes dramatisches Ereignis. Sie sammelt sich aus kleinen, einzeln nachvollziehbaren Änderungen an, die niemand gegen die ursprüngliche Baseline zurückverfolgt. Eine Flotte, die am Tag der Richtlinienfestlegung vollständig konform war, kann wenige Monate später deutlich non-compliant sein, ohne dass es einen einzelnen Moment gab, in dem das geschah.

Wie Drift tatsächlich entsteht

Drift entsteht fast nie, weil jemand Sicherheit absichtlich abschwächt. Sie entsteht durch gewöhnliche betriebliche Tätigkeiten mit einem Nebeneffekt, den niemand verfolgt.

• Manuelle Fehlerbehebung. Ein Techniker deaktiviert eine Firewall-Regel oder eine Local-Admin-Beschränkung, um ein Ticket zu lösen, will sie zurücksetzen und tut es nicht.
• Betriebssystem- und Anwendungsupdates. Ein Update setzt eine Einstellung stillschweigend auf den Standardwert zurück und macht damit eine angepasste Baseline rückgängig.
• Ausnahmen, die ihren Grund überdauern. Eine temporäre Ausnahme für ein Gerät während einer Migration wird nach Abschluss der Migration nie entfernt.
• Neue Geräte, die leicht außerhalb der Spezifikation registriert werden. Ein Gerät, das über einen leicht abweichenden Prozess bereitgestellt wurde, übernimmt die vollständige Baseline nicht.
• Verdeckte Änderungen. Änderungen, die vollständig außerhalb des verwalteten Prozesses vorgenommen werden, etwa durch einen Benutzer mit lokalen Administratorrechten, der selbst eine Einstellung anpasst.

Warum das mehr zählt, als es zunächst scheint

Drift wird leicht unterschätzt, weil jeder einzelne Fall klein ist. Aber sie zählt aus zwei konkreten Gründen.

• Sie ist häufig der Ausgangspunkt echter Vorfälle. Ein kompromittierter Endpoint lässt sich häufig auf eine Kontrolle zurückführen, die eigentlich durchgesetzt werden sollte und still aus der Durchsetzung herausgedriftet ist, nicht auf eine Kontrolle, die von vornherein nie entworfen wurde. Angreifer brauchen nicht jedes Gerät exponiert; sie brauchen nur ein gedriftetes Gerät, das sie finden.
• Sie ist die Lücke zwischen Ihrer dokumentierten Richtlinie und Ihrer tatsächlichen Posture. Sicherheitsrichtliniendokumente und Compliance-Frameworks beschreiben, was gelten soll. Drift ist das, was diese Beschreibung mit der Zeit zunehmend ungenau macht, ohne dass jemand das so entschieden hätte. Eine Organisation kann gleichzeitig eine wirklich gut gestaltete Richtlinie und eine wirklich non-compliante Flotte haben, einfach weil niemand prüft, ob beide noch übereinstimmen.

Wie Drift typischerweise erkannt wird und woran das scheitert

Die meisten Organisationen erkennen Drift auf eine von zwei Arten: ein geplantes Audit oder ein Vorfall, der sie aufdeckt. Beide haben dasselbe strukturelle Problem. Sie finden Drift, nachdem sie bereits eine Weile bestanden hat, nicht in dem Moment, in dem sie entsteht.

Ein Quartalsaudit, das ein nicht konformes Gerät findet, kann Ihnen nicht sagen, ob dieses Gerät am Tag nach dem letzten Audit oder am Tag vor diesem gedriftet ist, und das ist relevant, denn das ist der Unterschied zwischen einem kleinen Expositionsfenster und einem mehrmonatigen. Und Audits stichproben; sie prüfen selten jedes Gerät gegen jede Kontrolle, sodass ein gewisser Anteil an Drift praktisch unsichtbar bleibt, bis er ein Problem verursacht.

Drift stattdessen kontinuierlich erkennen

Die Alternative besteht darin, Richtlinien-Compliance kontinuierlich gegen eine deklarierte Baseline zu prüfen, statt sie periodisch zu verifizieren. Dafür müssen drei Dinge gemeinsam vorliegen.

• Eine klare, versionierte Baseline. Eine konkrete, abrufbare Definition dessen, was „conform“ für ein bestimmtes Gerät oder eine Gruppe bedeutet, nicht ein allgemeines Richtliniendokument.
• Regelmäßiger, automatisierter Abgleich. Abgleich des tatsächlichen Gerätezustands gegen diese Baseline, statt sich darauf zu verlassen, dass jemand daran denkt zu prüfen.
• Ein Nachweis darüber, was gedriftet ist. Wann es erkannt und wie es behoben wurde, sodass die Erkennung Nachweise erzeugt, nicht nur ein repariertes Gerät ohne Spur dessen, was geschah.

Warum der Nachweis genauso wichtig ist wie die Behebung

Der dritte Punkt zählt genauso viel wie die ersten beiden. Ein Drift-Erkennungsprozess, der Probleme stillschweigend behebt, ohne sie zu protokollieren, löst die unmittelbare Exposition, lässt Sie aber außerstande, zu beantworten, wie oft das vorkommt und was üblicherweise die Ursache ist, genau das Muster, das Sie erkennen wollen, bevor es zu einem größeren Problem wird.

Wie gute Drift-Behandlung im Alltag aussieht

• Abweichungen werden häufig genug gegen die Baseline geprüft, dass das Expositionsfenster in Stunden gemessen wird, nicht in Wochen.
• Risikoarme, gut verstandene Drift, etwa eine durch ein Routine-Update zurückgesetzte Einstellung, wird automatisch korrigiert.
• Risikoreichere oder ungewöhnliche Drift, etwa eine unerwartete Änderung der Admin-Gruppenmitgliedschaft, wird zur Überprüfung markiert, statt still automatisch korrigiert zu werden.
• Jedes Drift-Ereignis, automatisch korrigiert oder markiert, wird als Nachweis aufbewahrt, sodass Muster über die Zeit sichtbar werden, statt dass jeder Fall eine isolierte Überraschung bleibt.

Warum das mit Policy-as-Code und Review zusammenhängt

Drift-Erkennung funktioniert am besten, wenn es eine klare, versionierte Baseline gibt, gegen die Drift erkannt werden kann, und genau das liefert die Deklaration von Richtlinien als strukturierte Konfiguration. Es ist deutlich schwerer zu erkennen, dass ein Gerät nicht mehr seiner beabsichtigten Richtlinie entspricht, wenn die beabsichtigte Richtlinie nur als institutionelles Wissen oder als Einstellungsseite ohne Historie existiert. Die beiden Praktiken verstärken sich gegenseitig: Deklarierte, überprüfte Richtlinien geben der Drift-Erkennung etwas Präzises, gegen das sie prüfen kann, und kontinuierliche Drift-Erkennung ist das, was eine deklarierte Richtlinie auch nach dem Tag ihrer Genehmigung bedeutsam hält.

Verwandte Ressourcen

• Siehe den Pillar-Guide GitOps for Endpoint Compliance dafür, wie deklarierte Richtlinien und Reconciliation zusammen diese Lücke schließen.
• Siehe Audit Evidence from Versioned Security Workflows dafür, wie Drift-Erkennungsnachweise zu Audit-Nachweisen werden.