Change Management¶
Hier erfahren Sie, wie Sie in TCM365 Change Requests erstellen, durch eine Genehmigungskette führen und die Umsetzung dokumentieren.
Warum Change Management?¶
Unkontrollierte Änderungen an Cloud-Konfigurationen sind eine der häufigsten Ursachen für Sicherheitsvorfälle und Compliance-Verstöße. Ein formaler Change-Management-Prozess stellt sicher, dass:
- Jede Änderung geplant und genehmigt wird, bevor sie umgesetzt wird
- Die Auswirkung einer Änderung vorab bewertet wird
- Ein Audit-Trail entsteht, der bei Prüfungen vorgelegt werden kann
- NIS2-Anforderungen an die Aenderungskontrolle (Art. 21) erfüllt werden
Change Request erstellen¶
1. Neuen Change Request anlegen¶
- Navigieren Sie in der Sidebar zu KRITIS/NIS2 > Change Management
- Klicken Sie auf Neuer Change Request
2. Change-Details eingeben¶
Füllen Sie das Formular aus:
- Titel -- Kurze Beschreibung der geplanten Änderung (z.B. "MFA für alle Benutzer erzwingen")
- Beschreibung -- Detaillierte Beschreibung der geplanten Änderung
- Begründung -- Warum ist die Änderung notwendig? (z.B. Compliance-Anforderung, Risikominderung)
- Betroffener Tenant -- Welcher Tenant ist betroffen?
- Betroffene Bereiche -- Welche Resource Types werden geändert?
- Geplantes Datum -- Wann soll die Änderung umgesetzt werden?
- Risikobewertung -- Wie hoch ist das Risiko der Änderung? (Niedrig, Mittel, Hoch)
3. Rollback-Plan definieren¶
Beschreiben Sie, wie die Änderung im Fehlerfall rückgängig gemacht werden kann:
- Welcher Snapshot dient als Fallback?
- Welche Schritte sind für den Rollback nötig?
- Wie wird verifiziert, ob der Rollback erfolgreich war?
Tipp
Erstellen Sie vor der Umsetzung eines Change Requests immer einen Snapshot, um im Notfall einen sauberen Rollback-Punkt zu haben.
4. Change Request einreichen¶
- Prüfen Sie die eingegebenen Daten
- Klicken Sie auf Einreichen
- Der Change Request geht in den Genehmigungsprozess
Genehmigungskette¶
Wie funktioniert die Genehmigung?¶
Change Requests durchlaufen eine mehrstufige Genehmigungskette. Je nach Konfiguration können ein oder mehrere Genehmiger erforderlich sein:
| Schritt | Rolle | Aktion |
|---|---|---|
| 1. Einreichung | Antragsteller | Change Request wird erstellt und eingereicht |
| 2. Technische Prüfung | Tenant Admin / Workflow Manager | Technische Machbarkeit und Risiko bewerten |
| 3. Genehmigung | Tenant Admin / Super Admin | Formale Genehmigung erteilen |
| 4. Umsetzung | Antragsteller / zugewiesener Bearbeiter | Änderung durchführen |
| 5. Verifikation | Genehmiger | Erfolgreiche Umsetzung bestätigen |
Genehmigung erteilen oder ablehnen¶
Als Genehmiger:
- Öffnen Sie den Change Request
- Prüfen Sie die geplante Änderung, die Begründung und den Rollback-Plan
- Wählen Sie eine Aktion:
- Genehmigen -- Die Änderung darf umgesetzt werden
- Ablehnen -- Die Änderung wird nicht genehmigt (Begründung erforderlich)
- Rueckfrage -- Weitere Informationen vom Antragsteller anfordern
- Fügen Sie einen Kommentar hinzu
- Klicken Sie auf die gewählte Aktion
Umsetzung dokumentieren¶
Nach der Genehmigung und Umsetzung:
1. Snapshot vor der Änderung¶
- Erstellen Sie einen Snapshot des aktuellen Zustands (Pre-Change Snapshot)
- Vermerken Sie den Snapshot im Change Request
2. Änderung durchführen¶
- Führen Sie die geplante Änderung im Azure Portal, Intune Admin Center oder in der Zscaler-Konsole durch
- Aktualisieren Sie den Status des Change Requests auf In Umsetzung
3. Snapshot nach der Änderung¶
- Erstellen Sie einen neuen Snapshot (Post-Change Snapshot)
- Vergleichen Sie Pre- und Post-Change Snapshot, um die Änderung zu verifizieren
- Vermerken Sie den Snapshot im Change Request
4. Verifikation¶
- Prüfen Sie, ob die Änderung korrekt umgesetzt wurde
- Prüfen Sie, ob keine ungewollten Nebeneffekte aufgetreten sind
- Aktualisieren Sie den Status auf Verifiziert oder Abgeschlossen
Change-Request-Status¶
| Status | Beschreibung |
|---|---|
| Entwurf | Change Request wird vorbereitet, noch nicht eingereicht |
| Eingereicht | Wartet auf Genehmigung |
| Genehmigt | Genehmigung erteilt, bereit zur Umsetzung |
| Abgelehnt | Genehmigung verweigert |
| In Umsetzung | Änderung wird gerade durchgeführt |
| Verifiziert | Änderung wurde umgesetzt und geprüft |
| Abgeschlossen | Alle Schritte abgeschlossen, Change dokumentiert |
| Zurueckgezogen | Antragsteller hat den Request zurueckgezogen |
Best Practices¶
- Jeden Change dokumentieren: Auch vermeintlich kleine Änderungen sollten als Change Request erfasst werden
- Snapshots als Nachweis: Pre- und Post-Change Snapshots sind der beste Nachweis für Auditoren
- Rollback-Plan immer definieren: Planen Sie für jede Änderung ein Rollback-Szenario
- Drift-Monitor pausieren: Pausieren Sie den Drift-Monitor während geplanter Changes, um Fehlalarme zu vermeiden
- Referenz-Snapshot aktualisieren: Aktualisieren Sie nach genehmigten Changes den Referenz-Snapshot des Drift-Monitors
Nächster Schritt¶
- BC/DR-Tests -- Testen Sie die Wiederherstellungsfaehigkeit Ihrer Konfigurationen
- Rollback ausführen -- Falls ein Change schiefgeht