Snapshots¶

Snapshots sind Point-in-Time-Erfassungen von Tenant-Konfigurationen. Sie bilden das Fundament von TCM365s Configuration Lifecycle Management und ermöglichen Vergleiche, Drift-Erkennung, Baseline-Evaluation und Rollback-Operationen.

Übersicht¶

TCM365 erfasst Konfigurations-Snapshots von mehreren Anbietern über eine vendor-agnostische Architektur. Für Microsoft 365 werden je nach Workload zwei unterschiedliche Capture-Strategien eingesetzt. Für Zscaler rufen direkte API-Calls die ZIA- und ZPA-Konfigurationen ab.

Alle Snapshot-Operationen laufen über den SnapshotService, der an die entsprechende VendorAdapter-Implementierung basierend auf dem Tenant-Typ delegiert.

Kernfunktionen¶

• Point-in-Time-Erfassung von Tenant-Konfigurationen über alle unterstützten Anbieter
• Zwei M365-Capture-Strategien optimiert für unterschiedliche Workload-Typen
• 52 Microsoft 365 Resource Types über 7 Workload-Bereiche
• Zscaler ZIA (12 Endpoint Groups) und ZPA (9 Endpoint Groups) Unterstützung
• Atlassian Cloud (28 Resource Types) über Jira, Confluence und Org Security (v2.5.0)
• 24 spezialisierte Renderer zur Anzeige von Snapshot-Inhalten
• Bulk-Delete-Modus zur Verwaltung der Snapshot-Historie (v2.2.0)
• Capture Lock Service zur Verhinderung gleichzeitiger Snapshot-Operationen
• Fortschrittsverfolgung während Capture-Operationen

Capture-Strategien (Microsoft 365)¶

Microsoft 365-Konfigurationen werden je nach Workload mit zwei verschiedenen Strategien erfasst. Dieser duale Ansatz ist notwendig, weil Microsoft unterschiedliche API-Oberflächen für verschiedene Dienste bereitstellt.

Strategie 1: UTCM Snapshot Job API¶

Verwendet für: Teams, Exchange Online

Die UTCM (Unified Tenant Configuration Management) API bietet einen dedizierten Snapshot-Mechanismus für Teams- und Exchange-Konfigurationen. Diese Strategie erstellt einen asynchronen Snapshot Job, den Microsoft serverseitig verarbeitet.

sequenceDiagram
    participant C as Client
    participant B as TCM365 Backend
    participant G as Microsoft Graph

    C->>B: POST /snapshots
    B->>G: POST /tenantManagement/snapshotJobs
    G-->>B: 202 Accepted (jobId)
    B-->>C: { status: capturing }
    loop Polling
        B->>G: GET /snapshotJobs/{jobId}
        G-->>B: { status: running }
    end
    B->>G: GET /snapshotJobs/{jobId}
    G-->>B: { status: completed, data }
    B-->>C: { status: completed }

Voraussetzungen:

• Der UTCM Service Principal (App ID: 03b07b79-c5bc-4b5e-9bfa-13acf4a99998) muss im Ziel-Tenant provisioniert sein
• Entsprechende Microsoft Graph Permissions müssen gewaehrt sein

API-Limits:

• Maximal 4 gleichzeitige Snapshot Jobs pro Tenant
• Snapshot Jobs verfallen nach 24 Stunden
• Rate Limits gelten gemaess dem UTCM API-Quotensystem (verfolgt via UTCMQuotaUsage-Entity)

Strategie 2: Direct Graph API GET¶

Verwendet für: Entra ID, Intune, Defender, SharePoint, Cloud PC, Purview, Security

Für Workloads, die nicht von der UTCM Snapshot Job API abgedeckt werden, führt TCM365 direkte GET-Anfragen an die Microsoft Graph API aus, um den aktuellen Konfigurationszustand abzurufen.

sequenceDiagram
    participant C as Client
    participant B as TCM365 Backend
    participant G as Microsoft Graph

    C->>B: POST /snapshots
    B->>G: GET /beta/identity/conditionalAccessPolicies
    G-->>B: 200 OK (policies[])
    B->>G: GET /beta/deviceManagement/deviceConfigurations
    G-->>B: 200 OK (configs[])
    Note over B,G: Wiederholt für jeden Resource Type
    B-->>C: { status: completed }

Diese Strategie iteriert durch die ausgewaehlten Resource Types und ruft jeden einzeln ab. Der GraphService (1.704 Zeilen) verarbeitet alle direkten Graph API-Interaktionen.

Microsoft 365 Resource Types¶

TCM365 unterstützt 52 Resource Types, organisiert nach Workload-Bereichen. Resource-Definitionen werden in der Resource Registry unter backend-js/src/config/resource-registry/ gepflegt.

Resource Types verwenden die Vendor-Prefixed-Namenskonvention:

microsoft.entra.conditionalAccess
microsoft.intune.deviceConfigurations
microsoft.exchange.transportRules
microsoft.teams.messagingPolicies

Zscaler Resource Types¶

Zscaler ZIA (Internet Access)¶

12 Endpoint Groups werden für die ZIA-Konfigurationserfassung unterstützt:

Zscaler ZPA (Private Access)¶

9 Endpoint Groups werden für die ZPA-Konfigurationserfassung unterstützt:

Atlassian Cloud Resource Types (v2.5.0)¶

TCM365 unterstützt 28 Resource Types für Atlassian Cloud, organisiert nach Produktbereich.

Jira (16 Resource Types)¶

Confluence (5 Resource Types)¶

Org Security (7 Resource Types)¶

Resource Types verwenden die Vendor-Prefixed-Namenskonvention:

atlassian.jira.projects
atlassian.jira.workflows
atlassian.confluence.spaces
atlassian.orgSecurity.authenticationPolicies

Snapshot-Erstellungsablauf¶

API-Endpoint¶

POST /api/v1/snapshots

Request Body¶

{
  "vendorTenantId": "uuid-of-vendor-tenant",
  "name": "Pre-Change Baseline - Maerz 2026",
  "description": "Snapshot vor Anwendung neuer CA Policies",
  "resourceTypes": [
    "microsoft.entra.conditionalAccess",
    "microsoft.entra.namedLocations",
    "microsoft.intune.deviceConfigurations"
  ]
}

Fortschrittsverfolgung¶

Während der Erfassung zeigt das Frontend Echtzeit-Fortschritt über die SnapshotProgress-Komponente an. Das Backend sendet Fortschrittsaktualisierungen wenn jeder Resource Type abgeschlossen wird:

{
  "status": "capturing",
  "progress": {
    "total": 12,
    "completed": 7,
    "current": "microsoft.intune.compliancePolicies",
    "errors": []
  }
}

Capture Lock Service¶

Um gleichzeitige Snapshot-Operationen auf demselben Tenant zu verhindern, implementiert TCM365 einen Capture Lock Service:

• Mit Redis: Verwendet Redis NX (Set-if-not-exists) für verteiltes Locking
• Ohne Redis: Fällt zurück auf eine In-Memory Lock Map

Die Sperre wird automatisch freigegeben, wenn die Erfassung abgeschlossen ist oder fehlschlägt. Dies verhindert doppelte Snapshots und schuetzt vor API Rate Limit-Erschoepfung.

Snapshot-Anzeige¶

24 spezialisierte Renderer¶

Snapshot-Inhalte werden mit spezialisierten Renderern angezeigt, die auf jeden Resource Type zugeschnitten sind. Diese Renderer befinden sich in frontend/src/components/snapshots/viewer/ und bieten strukturierte, menschenlesbare Ansichten der Konfigurationsdaten.

SnapshotViewer-Komponente¶

Die SnapshotViewer-Komponente bietet eine einheitliche Oberfläche zur Exploration von Snapshot-Inhalten:

• Baumbasierte Navigation nach Workload und Resource Type
• Suche und Filter über alle erfassten Konfigurationen
• Auf-/zuklappbare Bereiche für grosse Konfigurationssaetze
• Copy-to-Clipboard für einzelne Einstellungen
• Export nach JSON für Offline-Analyse

Bulk Delete (v2.2.0)¶

Ab v2.2.0 unterstützt die Snapshots-Seite einen Bulk-Delete-Modus für die effiziente Verwaltung der Snapshot-Historie:

• Bulk-Delete-Modus über die Snapshot-Listenansicht umschalten
• Mehrere Snapshots über Checkboxen auswählen
• Löschung mit einem Zusammenfassungsdialog bestätigen
• Kaskadierendes Löschen entfernt zugehörige Daten (Diffs, Drift-Records)

API-Endpoint¶

DELETE /api/v1/snapshots/bulk

{
  "snapshotIds": [
    "uuid-1",
    "uuid-2",
    "uuid-3"
  ]
}

Snapshot Entity¶

Die Snapshot-Entity speichert erfasste Konfigurationsdaten:

Snapshot-Vergleich¶

Snapshots können verglichen werden, um Konfigurationsänderungen über die Zeit zu identifizieren. Der Vergleich wird vom DiffService durchgeführt und mit den Komponenten DiffTree und DiffViewer visualisiert.

Vergleichsablauf¶

1. Zwei Snapshots desselben Tenants auswählen
2. Das Backend führt einen Deep Comparison der Konfigurationsdaten durch
3. Änderungen werden als hinzugefügt, geändert oder entfernt kategorisiert
4. Ergebnisse werden in einer Side-by-Side-Diff-Ansicht dargestellt

Exportformate¶

Change Attribution¶

Beim Vergleich von M365-Snapshots kann TCM365 Änderungen bestimmten Benutzern zuordnen, indem Azure AD Directory Audit Logs abgefragt werden. Dies erfordert die Graph API Permission AuditLog.Read.All.

Konfiguration¶

Erforderliche Permissions (Microsoft 365)¶

Die Snapshot-Erfassung erfordert, dass die Azure AD App Registration die folgenden Microsoft Graph API Permissions (Application-Typ) hat:

Für eine vollständige Liste siehe die UTCM-Referenz.

Erforderliche Zugangsdaten (Zscaler)¶

Alle Zugangsdaten werden verschlüsselt gespeichert über den Per-Tenant EncryptionService mit austauschbarem SecretBackend (LocalAES für Entwicklung, Azure Key Vault für Produktion).

Best Practices¶

1. Snapshots beschreibend benennen -- Zweck und Datum angeben (z.B. "Pre-CA-Rollout Maerz 2026")
2. Vor Änderungen erfassen -- Immer einen Snapshot vor Konfigurationsänderungen erstellen
3. Relevante Resource Types auswählen -- Nur benötigte Typen erfassen reduziert Zeit und API-Quota-Verbrauch
4. UTCM-Quota überwachen -- Teams/Exchange-Snapshots verbrauchen UTCM API-Quota (automatisch verfolgt)
5. Bulk Delete nutzen -- Regelmäßig alte Snapshots aufraeumen zur Speicherverwaltung
6. Vergleiche nutzen -- Nach Änderungen Diff/Compare verwenden um erwartete Ergebnisse zu verifizieren