Acht Verwaltungsportale in einer Wochenmail

Ausgangslage

Der Projektordner dokumentiert die Ausgangslage nicht. Kein README, keine Dokumentation, keine aussagekräftige Historie. Was vorher gemacht wurde, wie oft etwas übersehen wurde oder was ein abgelaufenes Zertifikat gekostet hat, steht nirgends im Code.

Ableitbar ist nur, was das System ersetzt: acht Quellen mit jeweils eigener Portalansicht. Dass diese Prüfung vorher manuell erfolgte, ist plausibel — belegt ist es nicht.

Ansatz

Der Dienst läuft als Function, gestartet von einem Zeitplan: montags früh, einmal pro Woche. Ein zweiter, per Schlüssel geschützter Einstiegspunkt erlaubt einen manuellen Lauf zum Testen.

Ein Orchestrator holt zunächst zwei Zugriffstoken über die verwaltete Identität — es liegen keine Passwörter in der Anwendung. Dann ruft er sieben spezialisierte Sammler auf, die jeweils genau eine Quelle kennen und ihr Ergebnis auf drei einheitliche Datenstrukturen abbilden. Abgefragt werden: Secrets, Zertifikate und Signaturzertifikate von App-Registrierungen, Zertifikate und Secrets aus dem Schlüsseltresor, TLS-Zertifikate aus dem App Service, Service-Health-Ereignisse und Abkündigungen über Resource Graph, Meldungen aus dem Message Center sowie ein öffentlicher Update-Feed, per Stichwortliste auf Abkündigungen und Breaking Changes gefiltert.

Jeder Sammler läuft in eigener Fehlerbehandlung: Fällt eine Quelle aus, wird der Fehler gesammelt und im Report als Warnhinweis ausgewiesen — der Versand findet trotzdem statt. Die Funde werden nach Schwellwerten eingestuft, einem Zuständigen zugeordnet, und der Renderer baut daraus eine eigenständige HTML-Seite mit Kennzahlkarten und drei Tabellen.

Der Punkt, an dem es anders hätte laufen können

Die Zuordnung „wer ist für dieses Zertifikat zuständig“ wird bewusst nicht aus dem Verzeichnisdienst gezogen, sondern aus einer von Hand gepflegten Datei.

Der naheliegende Weg wäre gewesen, die im Verzeichnis hinterlegten technischen Objekt-Owner per Schnittstelle mitzulesen. Der Kopfkommentar des zuständigen Moduls begründet, warum das verworfen wurde: Verteiler und Funktionspostfächer können dort gar nicht als Owner eingetragen werden — und ein Owner-Eintrag würde zugleich Rechte zur Verwaltung der Zugangsdaten mitgeben.

Die Entscheidung trennt damit „wen benachrichtigen wir“ von „wer darf das ändern“ und verhindert, dass eine Benachrichtigungsanforderung stillschweigend Berechtigungen ausweitet.

Der Preis ist explizit benannt: Die Zuordnung muss von Hand gepflegt werden und veraltet, wenn niemand sie anfasst. Fehlt die Datei, bleibt die Spalte leer und der Report läuft trotzdem — ein fehlender Eintrag legt nichts lahm.

Ergebnis

18 Module, rund 1.385 Zeilen, größtes davon der HTML-Renderer. Acht lesende Datenquellen, ein Versandweg, zwei Einstiegspunkte plus ein lokales Vorschauskript, das denselben Report erzeugt, ohne zu versenden.

Bewusst reines Melden: Das System erneuert nichts, rotiert nichts, öffnet kein Ticket. Jede Reaktion ist manuell.

Offen benannte Grenzen, und sie sind ehrlich: Es gibt keine Zustandshaltung. Jeder Lauf beginnt bei null — keine Quittierung, kein „schon bearbeitet“, keine Eskalation bei Nichtreaktion. Dieselbe Meldung erscheint wöchentlich unverändert, bis das Problem behoben ist. Der Wochentakt bedeutet außerdem, dass ein Zertifikat, das dienstags kritisch wird, bis Montag auffällt; die Vorwarnzeit federt das ab, ist aber eine Einstellung, kein Mechanismus.

Und die Einstufung „Handlungsbedarf“ oder „zur Kenntnis“ entscheiden Stichwortlisten. Das produziert absehbar Fehlklassifikationen in beide Richtungen — ein Mensch muss den Report weiterhin lesen, nicht nur die Ampel.