Zero Trust in der Praxis: Policy-Drift erkennen und schnell beheben

Zero Trust ist in vielen Unternehmen inzwischen mehr als ein Buzzword — doch im Alltag schleichen sich oft unbemerkt Abweichungen ein. Policies werden gelockert, Ausnahmen gehäuft, und plötzlich steht das gesamte Sicherheitskonzept auf wackligen Beinen. In diesem Beitrag zeige ich, wie sich Policy-Drift frühzeitig erkennen und gezielt beheben lässt.

Was ist „Policy-Drift“ im Zero-Trust-Kontext?

In den meisten Umgebungen ist „Zero Trust“ kein einzelnes Produkt, sondern ein Bündel aus Policies: Conditional Access, Firewall-Regeln, EDR-Ausnahmen, Device-Compliance, Admin-Rollen, Secrets-Handling usw.

Policy-Drift bedeutet: Diese Policies verändern sich über Zeit (oft gut gemeint), bis der ursprüngliche Sicherheitszustand nicht mehr gewährleistet ist.

Typische Ursachen:

• „Temporäre“ Ausnahmen werden nie entfernt
• Hotfixes im Incident bleiben als Dauerzustand
• Teams kopieren Policies („Copy/Paste Security“)
• Shadow-IT oder „neue“ SaaS-Integrationen umgehen Kontrollpunkte

Drei Drift-Muster, die ich häufig sehe

1) Ausnahmen wachsen schneller als Regeln

Wenn eine Policy zu strikt wirkt, wird eine Ausnahme hinzugefügt. Passiert das häufig, entsteht eine schleichende Entwertung der Kontrolle.

2) Identitäten werden „weicher“

Service Accounts, Break-Glass-Accounts, API-Tokens: Alles wird irgendwann „dringend“ und bekommt Rechte. Ohne Ablaufdatum.

3) Endpoints werden „Sonderfälle“

Device-Compliance wird gelockert, weil ein Legacy-Agent Probleme macht. Danach ist die Ausnahme de facto Standard.

Ein einfacher Compliance-Loop (ohne Big-Bang)

Ich halte es bewusst pragmatisch: Ein wöchentlicher Loop ist besser als ein halbjährliches Audit.

1. Guardrails definieren (was darf nie passieren?)
2. Telemetry einsammeln (wo weichen wir ab?)
3. Abweichungen bewerten (Risk/Impact)
4. Fix oder Exception mit Ablaufdatum
5. Review (wiederkehrende Muster in Standards überführen)

Guardrails als „Invarianten“ formulieren

Beispiele:

• Kein Admin-Login ohne MFA
• Kein Zugriff auf M365 von unmanaged Devices
• Keine Egress-Exceptions ohne Ticket-Referenz

Drift sichtbar machen (mit Git-Workflow)

Wenn Policies als Code verfügbar sind (z.B. Terraform/Bicep/JSON), ist die Lösung banal: Drift ist ein Diff.

Minimalvariante: Export, versionieren, vergleichen.

# Beispiel: täglicher Export in ein Git-Repo (Pseudo-Workflow)
mkdir -p exports && cd exports
az account show >/dev/null

# Conditional Access (Beispielhaft; je nach Tooling / Tenant-Berechtigungen)
# Export als JSON und versionieren
python3 export_ca_policies.py > ca-policies.json

git add ca-policies.json
git commit -m "export: $(date -Iseconds)" || true

Wenn ihr kein IaC habt, könnt ihr trotzdem ein „Export-and-Diff“ fahren. Wichtig ist die Routine.

„Policy Budget“ statt „Exception Sprawl”

Ein Trick aus der Betriebsführung: Gebt euch ein Budget für Ausnahmen.

• Max. 5 aktive Ausnahmen pro Control
• Jede Ausnahme hat:
  • Owner
  • Grund
  • Ticket/Change-ID
  • Ablaufdatum

Damit wird Drift nicht „verboten“, sondern steuerbar.

Takeaways

• Zero Trust wird im Alltag durch kleine Ausnahmen ausgehöhlt, nicht durch große Architekturfehler.
• Ein wöchentlicher Compliance-Loop schlägt jedes halbjährliche Audit.
• Wenn möglich: Policies exportieren und in Git diffen.
• Ausnahmen brauchen Owner und Ablaufdatum.
• Definiert wenige, harte Guardrails, die nicht verhandelbar sind.