Drift-Erkennung¶

Die Drift-Erkennung ist TCM365s kontinuierliche Ueberwachungsfunktion, die identifiziert, wenn Tenant-Konfigurationen von einer bekannten Baseline abweichen. Sie arbeitet über automatisierte Configuration Monitors, die periodisch den aktuellen Zustand mit einem Referenz-Snapshot vergleichen.

Übersicht¶

Configuration Drift tritt auf, wenn Einstellungen in einem Cloud-Tenant sich ändern -- sei es durch manuelle Administrator-Aktionen, automatisierte Skripte oder Policy-Propagierung. TCM365 erkennt diese Änderungen automatisch und alarmiert Administratoren, um eine schnelle Behebung zu ermöglichen, bevor Drift Sicherheitsluecken oder Compliance-Verstöße verursacht.

Kernfunktionen¶

• Automatisierte Konfigurationsueberwachung über die UTCM Configuration Monitor API
• Vendor-agnostische Drift-Erkennung durch das VendorAdapter.detectDrift()-Interface
• Visuelle Drift-Berichte mit detaillierten Aenderungsaufschluesselungen
• Drift-Resolution-Workflow mit Baseline-Update-Optionen
• Multi-Channel-Benachrichtigungen bei Drift-Erkennung
• Drift-Historienverfolgung für Audit und Trendanalyse
• Unterstützung für Microsoft 365, Zscaler und Atlassian Cloud-Umgebungen
• Atlassian Drift-Erkennung basiert auf deep-diff-Vergleich (v2.5.0)

Architektur¶

Die Drift-Erkennung in TCM365 operiert auf zwei Ebenen:

Ebene 1: UTCM Configuration Monitors (Microsoft 365)¶

Für Microsoft 365 Tenants nutzt TCM365 die UTCM Configuration Monitor API, um serverseitige Monitors zu erstellen, die Microsoft kontinuierlich auswertet.

sequenceDiagram
    participant B as TCM365 Backend
    participant G as Microsoft Graph (UTCM)

    B->>G: POST /tenantManagement/configurationMonitors
    G-->>B: 201 Created (monitorId)
    Note over G: Microsoft wertet periodisch aus
    B->>G: GET /configurationMonitors/{id}/drift
    G-->>B: 200 OK (driftResults[])
    Note over B: Drift-Ergebnisse verarbeiten & speichern
    Note over B: Benachrichtigungen senden falls konfiguriert

Der UtcmService (1.438 Zeilen) verwaltet alle Interaktionen mit der UTCM Monitor API, einschliesslich Monitor-Lifecycle-Management und Drift-Ergebnisabruf.

Ebene 2: VendorAdapter Drift-Erkennung¶

Für Anbieter ohne serverseitiges Monitoring (wie Zscaler) und als ergaenzender Mechanismus für M365 führt TCM365 die Drift-Erkennung durch, indem der aktuelle Konfigurationszustand mit einem gespeicherten Baseline-Snapshot verglichen wird.

sequenceDiagram
    participant S as Scheduler
    participant V as VendorAdapter
    participant A as Vendor API

    S->>V: detectDrift(baseline)
    V->>A: capture(current)
    A-->>V: currentConfig
    Note over V: compare(baseline, current)
    V-->>S: DriftResult

Configuration Monitors¶

Monitor erstellen¶

Monitors werden über die TCM365 API erstellt, wobei angegeben wird, welche Resource Types überwacht und welcher Snapshot als Baseline dient.

API-Endpoint:

POST /api/v1/configuration-drift/monitors

Request Body:

{
  "vendorTenantId": "uuid-of-vendor-tenant",
  "name": "Production CA Policy Monitor",
  "description": "Conditional Access Policies auf unautorisierte Änderungen überwachen",
  "baselineSnapshotId": "uuid-of-baseline-snapshot",
  "resourceTypes": [
    "microsoft.entra.conditionalAccess",
    "microsoft.entra.namedLocations"
  ],
  "schedule": {
    "interval": "hourly",
    "enabled": true
  },
  "notificationChannels": ["email", "teams"]
}

Monitor Entity¶

Die ConfigurationMonitor-Entity verfolgt aktive Ueberwachungskonfigurationen:

Monitor-Lifecycle¶

stateDiagram-v2
    [*] --> Active: Erstellt
    Active --> DriftDetected: Drift erkannt
    DriftDetected --> AlertSent: Benachrichtigung
    AlertSent --> DriftResolved: Behoben
    DriftResolved --> BaselineUpdated: Baseline aktualisiert
    BaselineUpdated --> Active
    Active --> Paused: Manuell pausiert
    Paused --> Active: Fortgesetzt

Monitors können:

• Pausiert werden -- Überwachung voruebergehend stoppen (nuetzlich bei geplanten Änderungen)
• Fortgesetzt werden -- Überwachung nach einer Pause neu starten
• Aktualisiert werden -- Ueberwachte Resource Types oder Benachrichtigungskanäle ändern
• Re-Baselined werden -- Baseline-Snapshot nach Akzeptanz von Änderungen aktualisieren
• Geloescht werden -- Monitor vollständig entfernen

Drift-Erkennungsergebnisse¶

ConfigurationDrift Entity¶

Wenn Drift erkannt wird, wird ein ConfigurationDrift-Record erstellt:

Drift-Kategorien¶

Severity-Klassifizierung¶

Die Drift-Severity wird durch den Resource Type und die Art der Änderung bestimmt:

Drift-Visualisierung¶

TCM365 bietet fuenf spezialisierte Visualisierungskomponenten für die Drift-Analyse unter frontend/src/components/drift/:

Drift Dashboard¶

Das Haupt-Drift-Dashboard bietet einen Ueberblick über alle erkannten Drifts über ueberwachte Tenants hinweg:

• Drift-Zusammenfassungskarten -- Anzahl aktiver Drifts nach Severity
• Drift-Timeline -- Chronologische Ansicht der Drift-Events
• Tenant Drift Map -- Visuelle Anzeige des Drift-Status pro Tenant
• Resource Type-Aufschlüsselung -- Drift-Anzahl nach Resource Type

Drift-Detailansicht¶

Für einzelne Drift-Records zeigt die Detailansicht:

• Side-by-Side-Vergleich von Baseline- vs. aktuellem Wert
• Hervorgehobene Änderungen mit farbcodierten Hinzufuegungen, Änderungen und Entfernungen
• Change Attribution (wer die Änderung vorgenommen hat, falls Audit-Log-Daten verfügbar)
• Empfohlene Behebungsmassnahmen

Drift-Resolution-Workflow¶

Wenn Drift erkannt wird, folgen Administratoren einem strukturierten Behebungsworkflow:

Schritt 1: Überprüfen¶

Drift-Details überprüfen, einschliesslich der spezifischen Änderungen, betroffenen Resource Types und moeglichen Auswirkungen.

Schritt 2: Klassifizieren¶

Bestimmen, ob der Drift:

• Unautorisiert ist -- Änderung wurde nicht genehmigt und muss zurückgesetzt werden
• Autorisiert ist -- Änderung war beabsichtigt und die Baseline sollte aktualisiert werden
• Erwartet ist -- Änderung ist Teil eines geplanten Rollouts (bestätigen und überwachen)

Schritt 3: Beheben¶

Basierend auf der Klassifizierung:

Schritt 4: Verifizieren¶

Nach der Behebung einen manuellen Drift-Check auslösen, um die Behebung zu bestätigen:

POST /api/v1/configuration-drift/monitors/{id}/check

Baseline-Update bei Resolution¶

Wenn Drift durch Akzeptanz der Änderungen behoben wird, kann der Baseline-Snapshot des Monitors automatisch aktualisiert werden, um den neuen Soll-Zustand widerzuspiegeln:

{
  "resolution": "accepted",
  "updateBaseline": true,
  "notes": "CA Policy Update genehmigt in CR-2026-042"
}

Geplante Überwachung¶

Scheduler-Integration¶

Der SchedulerService verwaltet periodische Drift-Checks mit NestJS @nestjs/schedule:

Manueller Drift-Check¶

Zusätzlich zu geplanten Checks können Administratoren eine On-Demand-Drift-Erkennung auslösen:

POST /api/v1/configuration-drift/monitors/{id}/check

Dies wertet sofort die aktuelle Konfiguration gegen die Baseline aus und liefert Drift-Ergebnisse.

Benachrichtigungen bei Drift¶

Wenn Drift erkannt wird, kann TCM365 Benachrichtigungen über konfigurierte Kanäle senden:

Benachrichtigungsinhalte umfassen:

• Monitor-Name und Tenant-Bezeichner
• Resource Type und Drift-Severity
• Zusammenfassung der Änderungen (Added/Modified/Removed-Zähler)
• Direktlink zur Drift-Detailseite in TCM365

Siehe Benachrichtigungen für Kanal-Konfigurationsdetails.

API-Endpoints¶

Best Practices¶

1. Mit kritischen Ressourcen beginnen -- CA Policies und MFA-Einstellungen zuerst überwachen, dann Abdeckung erweitern
2. Angemessene Intervalle setzen -- Häufige Checks für sicherheitskritische Einstellungen, seltener für stabile Konfigurationen
3. Benachrichtigungen aktivieren -- Mindestens einen Benachrichtigungskanal für Drift-Alerts konfigurieren
4. Change Management-Integration nutzen -- Drift-Resolution mit Change Requests für Audit Trails verknüpfen
5. Bewusst re-baselinen -- Baselines nur nach Verifizierung der Autorisierung aktualisieren
6. Drift-Trends überprüfen -- Periodische Überprüfung der Drift-Historie zeigt Konfigurationsmanagement-Lücken auf
7. Während Wartung pausieren -- Monitors während geplanter Aenderungsfenster pausieren um False Positives zu vermeiden