· Methode

Best Practices per Klick: Warum wir M365-Sicherheit als Code behandeln

Ein Microsoft-365-Tenant hat Dutzende Sicherheitseinstellungen, die jemand einmal von Hand gesetzt hat. Wir behandeln sie wie Quellcode: als Vorlage, versioniert, prüfbar, mit Audit-Log.

Fragen Sie einen Administrator, welche Anti-Spam-Einstellungen in seinem Tenant gelten, und Sie bekommen eine ehrliche Antwort: „Die, die wir damals gesetzt haben.“ Das ist kein Vorwurf. Microsoft 365 hat Hunderte Schalter, verteilt auf mehrere Portale, und die Voreinstellungen ändern sich mit der Zeit. Wer fünf, zwanzig oder fünfzig Tenants betreut, hat fünfzig leicht verschiedene Zustände – und keinen Weg, das zu sehen.

Das Problem ist nicht das Wissen

Was eine gute Konfiguration ist, ist weitgehend bekannt: Spoof-Intelligence an, DMARC respektieren, Quarantäne mit klaren Benutzerrechten, gefährliche Dateitypen blockieren, Zero-Hour Auto Purge, MFA für Administratoren, Legacy-Authentifizierung blockieren. Das Problem ist, dass dieses Wissen in Köpfen und Checklisten steckt statt in etwas, das man ausführen und vergleichen kann.

Sicherheit als Code

Deshalb behandeln wir die Konfiguration eines Tenants wie Quellcode. Konkret heißt das:

  1. Eine Vorlage. Der Sollzustand ist eine Datei: Anti-Phishing, Anti-Spam, Anti-Malware, Alert-Policies, zwei Quarantäne-Policies mit definierten Rechten. Sie ist benannt, versioniert und dokumentiert – mit der Begründung, warum jede Einstellung so ist.
  2. Parametrisiert statt kopiert. Domain, Admin-Adresse, Ausnahmegruppen sind Platzhalter. Die Vorlage ist für alle Tenants dieselbe, nur die Werte unterscheiden sich. Pro Tenant lässt sich eine angepasste Fassung speichern.
  3. Ausführbar. Aus der Vorlage entsteht ein PowerShell-Skript – oder das Werkzeug rollt sie direkt aus, app-only über ein Zertifikat, ohne dass jemand ein Admin-Passwort eintippt.
  4. Prüfbar. Ein Verifikationslauf vergleicht den Ist-Zustand mit der Vorlage. Abweichungen werden sichtbar, nicht vermutet.
  5. Protokolliert. Jede schreibende Aktion landet in einem Audit-Log: wer, wann, welcher Tenant, welche Einstellung.

Ein Beispiel: Quarantäne

Die Standard-Quarantäne-Policies von Microsoft haben unklare Benutzerrechte und eine Freigabelogik, die niemand erklären kann. Unsere Vorlage kennt zwei: eine für Spam, Bulk und gewöhnliches Phishing, bei der Benutzer selbst Freigabe anfordern, Absender blockieren und Nachrichten löschen dürfen; und eine strengere für Phishing mit hoher Sicherheit und Malware, bei der nur ein Administrator freigibt. Zwei Policies, zwei Rechtesätze, ein Satz Benachrichtigungen. Das ist in jedem Tenant gleich – und weil es in der Vorlage steht, ist es auch in einem Jahr noch gleich.

Was wir bewusst nicht automatisieren

Conditional-Access-Policies können einen Tenant aussperren. Unsere Vorlagen – 10 Policies als Minimum, 33 mit Entra ID P1, 53 mit P2 – werden deshalb grundsätzlich im Nur-Bericht-Modus angelegt. Das Werkzeug zeigt, was die Policy tun würde; scharf schaltet ein Mensch, nachdem er die Berichte gelesen hat. Dieselbe Logik gilt für die Schnittstelle, über die KI-Agenten mit dem Werkzeug arbeiten: Jede Berechtigung ist pro Tenant einzeln freizuschalten, und die Voreinstellung ist „aus“.

Was das bringt

Ein neuer Tenant ist in einer Stunde auf dem Standard, nicht in einem Tag. Ein bestehender Tenant lässt sich gegen den Standard prüfen, bevor die Revision fragt. Und wenn sich der Standard ändert – weil Microsoft eine Empfehlung anpasst oder ein Vorfall etwas lehrt –, ändert sich eine Datei, und alle Tenants lassen sich nachziehen. Das ist der eigentliche Grund, Sicherheit als Code zu behandeln: nicht der erste Tenant wird schneller, sondern der fünfzigste wird gleich.