Zum Inhalt

Monatlicher Health Check der Plattform

Ein monatlicher Check zeigt, ob die Plattform gesund und konform ist und ob der Service wie vereinbart geliefert wird. Er gibt dem Plattform-Team einen festen Zeitpunkt, um alles anzusehen, was kein Alert abdeckt, und gibt dem Kunden einen Bericht, den er im taktischen Meeting besprechen kann.

Der Check ist in beiden Betriebsmodellen derselbe. Im managed-service-Modell erstellt das Plattform-Team (XMMS) den Bericht und der Kunde prüft ihn. Im Eigenbetrieb erstellt ihn dein eigenes Plattform-Team und berichtet an seine Stakeholder (Security Officer, Service Owner, Management).

Beispiele, keine Einstellungen

Die folgenden Checks stammen aus Berichten, die auf echten Managed Platforms verwendet werden. Schwellenwerte, Vorlaufzeiten und Subscription-Namen sind Beispiele. Lege deine eigenen in deinen Service Levels fest.

Wann und wer

Punkt Vorgeschlagener Wert
Häufigkeit Monatlich, in der ersten Woche nach Monatsende, für den vorherigen Kalendermonat
Ersteller Das Plattform-Team
Leser <service owner>, <security officer>, Teamleiter von workload-Teams, die ihn haben möchten
Ablageort <documentation space>, eine Seite pro Monat, jedes Mal dieselbe Struktur
Nachverfolgung Jede Feststellung wird zu einem Work Item oder mit Begründung akzeptiert. Offene Punkte im nächsten Bericht prüfen

Automatisiere die Datenerhebung, wenn du kannst (ein Skript oder eine geplante pipeline, die den Bericht schreibt). Die Struktur ist wichtiger als das Tool: Ein Bericht, der jeden Monat gleich ist, macht Trends sichtbar. Ein Muster für die Automatisierung steht unter Den Bericht erstellen.

Was zu prüfen ist

1. Gesundheit der Plattform

Check Worauf du schaust Was normal ist
Verfügbarkeit des Application Gateway Verfügbarkeit in Prozent pro Gateway über den Monat und der aktuelle Status Verfügbar, auf oder über deinem Verfügbarkeitsziel
Modus der WAF-Policy Modus jeder WAF-Policy, pro Plattform-Umgebung Prevention. Eine Policy im Modus Detection braucht einen dokumentierten Grund
Zustand der Azure Firewall Durchschnittlicher Health-Prozentsatz pro firewall (canary und prod) Auf oder über deinem Verfügbarkeitsziel
Virtual-WAN-, VPN- und ExpressRoute-Verbindungen Verbindungsstatus und ob Verkehr fließt Verbunden, mit Verkehr. Siehe Incident-Management, warum der Status allein nicht reicht
Hub-Alerts Im Monat ausgelöste Alerts, nach Schweregrad, und wie viele handlungsrelevant waren. Compliance der Alert-Policies Keine ungeklärten Alerts, und die Alert-Initiativen sind konform. Laute Regeln werden angepasst (Monitoring-Regeln, So funktioniert Alerting)
Drift Ergebnis eines hub-Laufs im Modus Plan (Betriebsverantwortlichkeiten) Keine Änderungen. Jede Änderung, die du nicht committet hast, ist Drift. Für spokes nutze den Report der spoke drift detection

Vergleiche canary und prod. Ein Unterschied, den niemand angefragt hat, ist eine Feststellung.

2. Compliance und Sicherheit

Check Worauf du schaust
Secure Score Defender-for-Cloud-Secure-Score pro Plattform-Subscription und der Trend gegenüber dem Vormonat
Top-Maßnahmen Die drei Empfehlungen, die den Score am stärksten anheben, mit der Zahl betroffener Ressourcen
Regulatory Compliance Pro zugewiesener initiative (zum Beispiel CIS und ISO 27001): Zahl der nicht konformen Controls, Prozentsatz konform, und die nicht konformen Policies mit der Zahl der Ressourcen. Siehe Governance
Empfehlungen mit hohem Schweregrad Alle Defender-for-Cloud-Empfehlungen mit Schweregrad High, pro Subscription
Policy-Ausnahmen Ausnahmen, die abgelaufen sind oder im nächsten Monat ablaufen (Policy-Zuweisungen)
Ablauf von Secrets und Zertifikaten App-Registrierungen und Service Principals mit einem Secret oder Zertifikat, das innerhalb von <n> Tagen abläuft (zum Beispiel 60). Schließe die eigenen Deployment-Identitäten der Plattform und die Spoke-Identitäten ein (Spoke ändern). Ein wöchentlicher Secret watcher fängt Abläufe zwischen den Berichten ab
Advisor Neue Azure-Advisor-Empfehlungen, in Backlog-Einträge umgewandelt

3. Service-Management

Check Worauf du schaust
Incidents Jeder im Monat geschlossene Incident: Kennung, Titel, Lösungszeit (Stunden und Tage) und Schweregrad, plus der Durchschnitt
Standardänderungen Jede im Monat geschlossene Standardänderung: Kennung, Titel, Lösungszeit, plus der Durchschnitt
Kommentare Warum eine Lösungszeit lang war. Markiere Zeit, die mit Warten auf den Kunden oder auf ein Plattform-Update verbracht wurde, separat, damit sie den Durchschnitt nicht verzerrt
Severity 1 und Major Incidents Link zum Post-Mortem für jeden einzelnen
Offene Punkte Aus früheren Berichten übernommene Work Items

Lösungszeiten sind nur vergleichbar, wenn du sie jeden Monat gleich misst. Entscheide, von welchem Moment bis zu welchem Moment du misst, und halte es in den Service Levels fest.

4. Managed VMs (nur wenn deine Plattform sie anbietet)

Siehe auch den wöchentlichen Patch-Check im Managed-VM-Modul.

Der MCP-Core deployt und patcht keine VMs für workload-Teams (Verantwortlichkeiten). Wenn deine Plattform ein Managed-VM-Angebot darauf aufsetzt, prüfe monatlich:

Check Worauf du schaust
VM-Inventar Liste der Managed VMs, nach Umgebung. Mit der Konfiguration vergleichen
Patching Pro VM: Patch-Status, ausstehende, fehlgeschlagene, installierte und ausgeschlossene Patches und Datum der letzten Installation. Den Status kannst du nur bei laufenden VMs lesen. Erstelle für jeden fehlgeschlagenen Patch-Lauf einen Incident
Backup Pro VM und pro Backup-Lösung (Backup Vault und Recovery Services vault): Status und Zeitpunkt des letzten Backups. Zähle die VMs pro vault und vergleiche mit dem Inventar. Eine VM ohne Backup ist eine Feststellung

Den Bericht erstellen

Ein Muster, das auf Managed-Plattformen funktioniert:

Schritt Was
Zeitplan Eine pipeline läuft in den ersten Tagen des Monats und nimmt den Vormonat als Standardzeitraum, mit einem Parameter, um einen anderen Monat oder eine einzelne Plattform auszuführen
Zugriff Ein schreibgeschützter Service Principal pro tenant, mit Leserechten auf die Plattform-Subscriptions, zum Beispiel an der Root Management Group (für Policy-Status, Secure Score und Empfehlungen) und, wo möglich, Lesezugriff auf App-Registrierungen (für den Ablauf von Secrets). Wenn du noch keine Rechte für den Ablauf von Secrets hast, sag das im Bericht, statt den Abschnitt wegzulassen
Erhebung Skripte fragen Azure Resource Graph, Defender for Cloud und das Ticketsystem ab und füllen die Tabellen des Berichts-Templates: Lösungszeiten, Secure Score, Empfehlungen, Ablauf von Secrets, Zustand und WAF-Modus des Application Gateways, Zustand der Firewall
Veröffentlichung Der Bericht ist eine Seite im Wiki, die der Kunde lesen kann (zum Beispiel eine Seite pro Monat unter Reports / Monthly checks). Wenn der Kunde eine eigene DevOps-Organisation hat, veröffentliche ihn dort
Review Eine Person liest den Bericht, ergänzt die Kommentare (zum Beispiel warum eine Lösungszeit lang war) und teilt ihn. Der Service Owner leitet die Nachverfolgung

Handle nach dem Ergebnis: Ein Secure Score unter deinem Schwellenwert (zum Beispiel 80 %) heißt, sieh dir die Empfehlungen im Portal an, besprich mit dem Service Owner, ob die Organisation handeln muss, und lege Work Items an. Ein Secret, das bald abläuft, wird von seinem Owner rotiert, oder vom Plattform-Team, wenn du die Rechte hast (Secret watcher).

Bewahre die Zugangsdaten der Leser-Identitäten in einem sicheren Store auf und rotiere sie nach Zeitplan: Auch sie sind Secrets, die ablaufen.

Struktur des Berichts

Verwende jeden Monat dieselben Überschriften:

# Monthly Platform Health Report - <month> <year>

## Executive summary
Period, date generated, three to five sentences: what is fine, what needs attention, decisions needed.

## Platform health
Application Gateway availability, WAF policy mode, Azure Firewall health, connections, alerts, drift

## Compliance and security
Secure scores, top actions, compliance per initiative, high-severity recommendations,
exemptions, secret and certificate expiry

## Service management
Incidents, standard changes, resolve times, post-mortems

## Managed VMs (optional)
Inventory, patching, backups

## Findings and actions
Table: finding, severity, owner, work item, due date, status

Halte Kundendaten aus geteilten Kopien heraus

Ein Monatsbericht nennt Subscriptions, Konten, Anwendungen und Secrets. Speichere ihn dort, wo nur die Personen, die ihn brauchen, Zugriff haben, und entferne die Details, bevor du einen Bericht anderswo als Beispiel verwendest.

Wiederkehrende Feststellungen

Diese Feststellungen kamen in den meisten Berichten wieder. Suche zuerst nach ihnen.

Feststellung Was zu tun ist
Gastkonten oder deaktivierte Konten, die weiterhin read-, write- oder owner-Rechte auf Azure-Ressourcen halten Das Identity-Team entfernt sie. Zugriff soll über Gruppen und PIM kommen (Zugriff und PIM), eine direkte Zuweisung, die niemand erklären kann, braucht also einen Owner oder wird entfernt
Niedriger Secure Score bei den Management- und Identity-Subscriptions Wähle jeden Monat die drei wichtigsten Maßnahmen und plane sie ein. Versuche nicht, alles auf einmal zu beheben
Dieselbe nicht konforme Policy in jeder Plattform-Subscription Behebe sie einmal im Code oder dokumentiere eine befristete Ausnahme mit Begründung
Secrets und Zertifikate kurz vor dem Ablauf, oft bei App-Registrierungen, an die sich niemand erinnert Finde den Owner. Rotiere, ersetze durch Federated Credentials oder lösche die Registrierung
Der Storage Container mit den Activity Logs ist öffentlich zugänglich, oder ein Defender-Plan ist nicht aktiviert Im Plattform-Code oder in der Konfiguration beheben, dann im nächsten Bericht prüfen
Lange Lösungszeiten, die durch das Warten auf ein Plattform-Release entstehen Verfolge sie als eigene Kategorie (Service-Level-Management)
Das Patching schlägt bei einer VM immer wieder fehl Schau dir die VM an (Speicherplatz, Agent, ausstehender Neustart), nicht den Zeitplan