Rollback¶

Rollback ist TCM365s Fähigkeit, Tenant-Konfigurationen auf einen vorherigen bekannten Zustand wiederherzustellen. Durch Nutzung erfasster Snapshots als Referenz können Administratoren unautorisierte Änderungen zurücksetzen, Fehlkonfigurationen beheben oder fehlgeschlagene Deployments rückgängig machen -- mit vollstaendigem Audit Trail.

Übersicht¶

Das Rollback-Feature operiert über das vendor-agnostische VendorAdapter.apply()-Interface und ermöglicht konsistentes Rollback-Verhalten über alle unterstützten Anbieter. Jede Rollback-Operation wird in der RollbackHistory-Entity erfasst und bietet einen vollständigen Audit Trail darueber, was wann und von wem geändert wurde.

Kernfunktionen¶

• Kontrollierter Rollback auf jede frühere Snapshot-Konfiguration
• 52 Microsoft 365 Resource Types mit Write-Back-Unterstützung
• Zscaler ZIA/ZPA Rollback mit Staging- und Direct-Modi
• Atlassian Cloud Rollback via Direct Write Methods (v2.5.0)
• Granulare Resource-Type-Auswahl (nur bestimmte Einstellungen zurücksetzen)
• Capability Matrix mit unterstützten Rollback-Operationen pro Resource Type
• Vollständige Rollback-Historie mit Vorher/Nachher-Zustandsverfolgung
• Integration mit Change Management für Genehmigungsworkflows
• Vendor-agnostisch via VendorAdapter Pattern

Rollback-Architektur¶

VendorAdapter.apply()¶

Alle Rollback-Operationen laufen über die VendorAdapter.apply()-Methode:

interface VendorAdapter {
  apply(tenant: VendorTenant, config: ConfigPayload): Promise<ApplyResult>;
}

Rollback-Ablauf¶

sequenceDiagram
    participant A as Administrator
    participant B as TCM365 Backend
    participant V as Vendor API

    A->>B: POST /rollback
    Note over B: Snapshot-Konfiguration laden
    Note over B: Aktuellen Zustand erfassen (Pre-Rollback Snapshot)
    B->>V: VendorAdapter.apply()
    V-->>B: 200 OK
    Note over B: In RollbackHistory erfassen
    B-->>A: { status: completed, rollbackId: uuid }

Pre-Rollback-Sicherheit¶

Vor der Ausführung eines Rollbacks führt TCM365 automatisch folgende Schritte durch:

1. Aktuellen Zustand erfassen -- Snapshot der aktuellen Konfiguration als Sicherheitsnetz
2. Berechtigungen validieren -- Prüfung der Write Permissions der Azure AD App Registration
3. Konflikte prüfen -- Identifikation laufender Operationen auf demselben Tenant

Microsoft 365 Rollback¶

Unterstützte Resource Types¶

TCM365 unterstützt Rollback für alle 52 Microsoft 365 Resource Types. Die CapabilityMatrix-Komponente im Frontend zeigt die unterstützten Operationen pro Resource Type an.

Write App Registration (v2.2.0)¶

Ab v2.2.0 unterstützt TCM365 getrennte Read- und Write-App-Registrations für Microsoft 365. Dies ermöglicht Organisationen:

• Eine Read-Only App Registration für taegliche Snapshot-Operationen
• Write Permissions auf eine separate App Registration nur für Rollback beschränken
• Dem Prinzip der geringsten Berechtigung für API-Zugriff folgen

Die Write App Registration wird über den M365 Setup Wizard konfiguriert und verschlüsselt im M365VendorTenant-Entity-Feld write_credentials gespeichert.

Erforderliche Permissions (Write)¶

Zscaler Rollback¶

Rollback-Modi¶

Zscaler Rollback unterstützt zwei Modi:

ZIA Rollback¶

Der ZscalerZiaClient verarbeitet Write-Operationen für ZIA-Konfigurationen:

• URL Filtering Rules, Firewall Rules, DLP Rules
• SSL Inspection Rules, Security Policies
• Location Management, Bandwidth Control

ZPA Rollback¶

Der ZscalerZpaClient verarbeitet Write-Operationen für ZPA-Konfigurationen:

• Application Segments, Access Policies
• Server Groups, Segment Groups, Connector Groups

Rollback-API¶

Rollback ausführen¶

POST /api/v1/rollback

{
  "vendorTenantId": "uuid-of-vendor-tenant",
  "snapshotId": "uuid-of-target-snapshot",
  "resourceTypes": [
    "microsoft.entra.conditionalAccess",
    "microsoft.entra.namedLocations"
  ],
  "reason": "Unautorisierte CA Policy-Änderungen zurücksetzen, erkannt durch Drift Monitor",
  "changeRequestId": "uuid-of-approved-change-request"
}

Response¶

{
  "rollbackId": "uuid",
  "status": "completed",
  "resourcesProcessed": 2,
  "resourcesSucceeded": 2,
  "resourcesFailed": 0,
  "preRollbackSnapshotId": "uuid-of-safety-snapshot",
  "results": [
    {
      "resourceType": "microsoft.entra.conditionalAccess",
      "status": "success",
      "itemsReverted": 3,
      "details": "3 Conditional Access Policies auf Baseline-Zustand zurückgesetzt"
    }
  ]
}

API-Endpoints¶

RollbackHistory Entity¶

Jede Rollback-Operation wird für Audit-Zwecke erfasst:

Rollback-Vorschau¶

Vor der Ausführung eines Rollbacks können Administratoren vorschauen, welche Änderungen vorgenommen werden:

POST /api/v1/rollback/preview

{
  "vendorTenantId": "uuid",
  "snapshotId": "uuid",
  "resourceTypes": ["microsoft.entra.conditionalAccess"]
}

Die Vorschau-Response zeigt einen Diff zwischen aktuellem Zustand und dem Ziel-Snapshot, sodass Administratoren Änderungen vor dem Commit überprüfen können.

Change Management-Integration¶

Rollback-Operationen können mit Change Management-Antraegen für Compliance verknüpft werden:

1. Change Request erstellen -- Rollback-Bedarf mit Begründung dokumentieren
2. Genehmigung einholen -- Durch die Approval Chain leiten
3. Rollback ausführen -- Genehmigte Change Request ID referenzieren
4. Ergebnisse dokumentieren -- Rollback-Ergebnisse werden automatisch mit dem Change Request verknüpft
5. Audit Trail -- Vollständige Kette von Drift-Erkennung über Genehmigung bis Ausführung

Fehlerbehandlung¶

Partieller Rollback¶

Wenn ein Rollback für einige Resource Types fehlschlägt aber für andere erfolgreich ist, wird die Operation als partial markiert:

{
  "status": "partial",
  "resourcesProcessed": 3,
  "resourcesSucceeded": 2,
  "resourcesFailed": 1,
  "results": [
    { "resourceType": "microsoft.entra.conditionalAccess", "status": "success" },
    { "resourceType": "microsoft.entra.namedLocations", "status": "success" },
    { "resourceType": "microsoft.intune.deviceConfigurations", "status": "failed",
      "error": "Unzureichende Berechtigungen: DeviceManagementConfiguration.ReadWrite.All erforderlich" }
  ]
}

Rollback eines Rollbacks¶

Wenn ein Rollback unerwartete Probleme verursacht, kann der Pre-Rollback-Sicherheits-Snapshot verwendet werden, um den Zustand vor dem Rollback wiederherzustellen. Dies bietet ein doppeltes Sicherheitsnetz für die Konfigurationswiederherstellung.

Best Practices¶

1. Immer zuerst vorschauen -- Vorschau-Endpoint nutzen um Änderungen vor Ausführung zu prüfen
2. Change Management nutzen -- Rollbacks mit genehmigten Change Requests für Audit-Compliance verknüpfen
3. Spezifische Resource Types wählen -- Nur betroffene Resource Types zurücksetzen, nicht alles
4. Nach Rollback verifizieren -- Neuen Snapshot erstellen und Drift-Erkennung ausführen zur Bestätigung
5. Getrennte Read/Write Apps -- Separate App Registrations (v2.2.0) verwenden um Write-Zugriff zu beschränken
6. Zuerst in Nicht-Produktion testen -- Wenn möglich, Rollback in einem Entwicklungs-Tenant vor Produktion testen
7. Gruende dokumentieren -- Immer einen klaren Grund für den Rollback im Request angeben
8. Rate Limits beachten -- Bei grossen Rollbacks mit vielen Resource Types die Vendor API Rate Limits beachten