Wer mehrere Microsoft-365-Tenants betreut, kennt das Problem: Jeder Tenant wurde zu einer anderen Zeit von einer anderen Person eingerichtet, und niemand weiß genau, welche Anti-Phishing-Policy wo gilt. Der M365 Security Policy Manager ist die Antwort darauf: ein Standard, der sich auf jeden Tenant anwenden und dort nachprüfen lässt.
Ausgangslage
Begonnen hat das Projekt als statische HTML-Seite, die PowerShell-Skripte für Exchange Online erzeugte. Das funktionierte, hatte aber Grenzen: Die Skripte mussten von Hand ausgeführt werden, es gab keinen Überblick über den Ist-Zustand, und Conditional Access oder Intune waren gar nicht abgedeckt. Der Wunsch war ein Werkzeug, das den ganzen Einrichtungsweg eines Tenants führt – in der richtigen Reihenfolge, nachvollziehbar, mehrmandantenfähig.
Lösung
Heute besteht das Werkzeug aus einem Svelte-Frontend und einem Node-Backend, in dessen Container auch PowerShell 7 mit dem Exchange-Online-Modul läuft. Die Verbindung zum Tenant läuft app-only über ein Zertifikat; das Onboarding eines neuen Tenants geschieht per Device-Code. Die Oberfläche ist in zwölf Bereiche gegliedert, die dem Arbeitsablauf folgen: Tenants und Vorlage, Mail-Security mit Ausrollen und Audit, Conditional Access, Intune, Autopilot, Laufwerks- und Druckerzuordnungen, Agents, Lizenzen, Tickets und eine Wissensdatenbank.
Die Mail-Security umfasst Anti-Phishing, Anti-Spam, Anti-Malware mit über 47 blockierten Dateitypen, Alert-Policies und zwei eigene Quarantäne-Policies mit klar definierten Benutzerrechten. Für Conditional Access gibt es Vorlagen in drei Stufen – 10 Policies als Minimum ohne Geräteanforderung, 33 mit Entra ID P1, 53 mit P2 – die beim Ausrollen grundsätzlich im Nur-Bericht-Modus angelegt werden. Scharf schaltet ein Mensch, nie das Werkzeug.
Neu hinzugekommen ist eine Schnittstelle für KI-Agenten: API-Keys, die pro Tenant einzeln freigeschaltet werden (alles standardmäßig aus), zehn Werkzeuge von Lizenzbericht bis MFA-Reset, und ein Audit-Log, in dem jede schreibende Aktion landet. Ein Ticket-Copilot zieht Lizenz- und Policy-Daten des betroffenen Tenants zusammen und schlägt einen Lösungsweg vor.
Ergebnis
- Ein Tenant wird nach demselben Standard eingerichtet wie der vorherige – und der Unterschied zum Ist-Zustand ist sichtbar
- Vorlage pro Tenant speicherbar, Export als PowerShell, JSON und Markdown-Dokumentation
- Diagnose-Bereich erkennt abgelaufene Zertifikate und inaktive Tenants, bevor ein Deployment scheitert
- Versionsstand 2.5 nach einem halben Jahr Entwicklung, mit dokumentiertem Changelog
Was wir daraus gelernt haben
Sicherheitsrelevante Vorlagen kopiert man nicht ab, man übernimmt sie maschinell. Die Conditional-Access-Vorlagen stammen aus einem offenen, MIT-lizenzierten Projekt und wurden programmatisch abgerufen, weil ein Tippfehler in einer Ausschlussgruppe einen ganzen Tenant aussperren kann. Und: Ein Werkzeug, das auf fremde Tenants schreibt, braucht eine Voreinstellung von „aus“. Die Freischaltung pro Tenant und das Audit-Log waren mehr Arbeit als die Werkzeuge selbst – und sind der Grund, warum wir sie Agenten überhaupt in die Hand geben.