Daniel AcarMicrosoft-365-Security-Audit für MSPs
Ein Microsoft-365-Security-Audit sollte kein einmaliges Bauchgefühl sein, sondern ein wiederholbarer Prozess: gleiche Prüfpunkte, gleiche Reihenfolge, gleiches Reporting – bei jedem Kunden. Genau so wird aus der Sicherheitsüberprüfung eine standardisierte, abrechenbare MSP-Leistung statt unbezahlter Feuerwehr. Diese Checkliste führt durch die Prüfung eines Kunden-Tenants.
1. Drittanbieter-Apps und OAuth-Zugriffe
Der am häufigsten übersehene Bereich. Jede App, der ein Nutzer einmal Zugriff erteilt hat, behält ihn – oft an MFA vorbei. Prüfe: Welche Apps haben Zugriff? Mit welchen Berechtigungen (besonders Mail.ReadWrite, Files.ReadWrite.All, full_access_as_app)? Von wem freigegeben – Admin oder einzelner Nutzer? Details im Leitfaden zu riskanten OAuth-Apps.
2. Anmelde- und Risiko-Signale
Ein Blick ins Anmeldeprotokoll zeigt, ob es bereits verdächtige Muster gibt: Anmeldungen aus ungewöhnlichen Ländern, Impossible Travel, anonyme IPs, gehäufte Fehlversuche. Risikobasierte Signale aus Identity Protection sind aussagekräftig, brauchen aber Entra ID P2. Worauf du achtest, vertieft der Leitfaden zu verdächtigen Anmeldungen.
3. Härtungs-Checks der Grundeinstellungen
Das Herzstück des Audits ist der Zustand der zentralen Sicherheitseinstellungen. Diese Punkte gehören bei jedem Kunden geprüft:
- MFA-Abdeckung je Nutzer: Ist wirklich jedes Konto durch einen zweiten Faktor geschützt? Siehe MFA erzwingen.
- Legacy-Authentifizierung: per Conditional-Access-Block unterbunden? (setzt Entra ID P1 voraus)
- Security Defaults bzw. äquivalente CA-Richtlinien: aktiv? Siehe Conditional Access.
- Privilegierte Rollen: Wie viele globale Administratoren gibt es, und sind es wirklich so wenige wie möglich?
- Break-Glass-Konto: vorhanden, ausgenommen und überwacht?
- Nutzer-Zustimmung: eingeschränkt, damit nicht jeder Klick neue App-Zugriffe erzeugt?
4. Mail-Weiterleitungsregeln
Eine heimliche Weiterleitung ist zugleich Symptom einer Übernahme und eigenes Risiko. Prüfe Inbox-Regeln, Postfach-Weiterleitung und organisationsweite Transportregeln auf externe Zieladressen – und ob automatische externe Weiterleitung überhaupt blockiert ist. Vorgehen im Leitfaden zu Mail-Weiterleitungsregeln.
5. Reporting und Nachweis
Ein Audit ohne Bericht verpufft. Am Ende steht ein verständlicher Report je Kunde: Was wurde geprüft, was ist offen, was ist die Empfehlung – idealerweise im White-Label mit deinem Firmennamen. Dieser Report ist zugleich ein Baustein der laufenden NIS2-Dokumentation.
Ehrlich bei Lizenzen und Grenzen bleiben
Nicht jeder Check ist ohne Zusatzlizenz voll aussagekräftig. Das Blockieren von Legacy-Auth über Conditional Access setzt Entra ID P1 voraus, risikobasierte Anmelde-Signale Entra ID P2. Fehlt die Lizenz, gehört der Check ehrlich als „Unbekannt“ markiert – nicht als „erfüllt“. Sonst verkaufst du dem Kunden eine Sicherheit, die gar nicht messbar ist.
Vom einmaligen Audit zum wiederkehrenden Service
Der Wert entsteht durch Wiederholung: Beim Onboarding einmal vollständig, danach quartalsweise – und die risikoreichen Signale laufend, nicht nur zum Termin. So wird der Security-Audit zu einem planbaren, abrechenbaren Baustein deines MSP-Angebots. Wie sich derselbe Zielzustand über alle Kunden halten lässt, zeigt der Leitfaden zur Sicherheits-Baseline über mehrere Mandanten.
Wie TenantSecure den Prozess automatisiert
TenantSecure gießt genau diese Checkliste in einen automatisierten Ablauf: Es erfasst Drittanbieter-Apps, wertet Anmeldungen aus, erkennt Weiterleitungsregeln und prüft acht Härtungs-Checks je Mandant – über alle Kunden in einer Ansicht. Das Ergebnis fließt in einen Härtungs-Score (Details in der Doku zu Härtung und Score) und in einen White-Label-Report je Kunde. Für Teams gibt es abgestufte Rollen – Owner, Admin und Readonly (Nur-Lesen) – damit jeder nur so viel kann, wie er soll.
Mit TenantSecure
Führe den Audit nicht fünfzigmal von Hand aus, sondern einmal automatisiert über dein ganzes Portfolio. Sieh dir an, was ein strukturierter Audit über deine Mandanten zutage fördert: die Live-Demo ansehen.
Häufige Fragen
- Wie oft sollte ein Microsoft-365-Security-Audit stattfinden?
- Ein vollständiger Audit als Momentaufnahme lohnt beim Onboarding eines Kunden und danach mindestens quartalsweise. Die risikoreichen Signale – verdächtige Anmeldungen, neue Weiterleitungsregeln, neue OAuth-Apps – gehören dagegen laufend überwacht, nicht nur zum Audit-Termin, weil sich ein Tenant zwischen zwei Prüfungen kompromittieren lässt.
- Brauche ich für den Audit Entra ID P1 oder P2?
- Der Grundprozess läuft ohne Zusatzlizenz. Einige Härtungs-Checks – vor allem das Blockieren von Legacy-Authentifizierung über Conditional Access – setzen jedoch Entra ID P1 beim Kunden voraus, risikobasierte Anmelde-Signale (Identity Protection) Entra ID P2. Fehlt die Lizenz, sollte der Check ehrlich „Unbekannt“ zeigen statt fälschlich „erfüllt“.
- Wie mache ich aus einem Audit eine wiederkehrende Leistung?
- Indem der Prüfprozess standardisiert und automatisiert ist und in einen wiederkehrenden Report je Kunde mündet. Statt jeden Tenant manuell durchzuklicken, prüft ein Cross-Tenant-Tool die Punkte automatisch und liefert einen White-Label-Bericht, den du als abrechenbaren Security-Service verkaufst.
Weiterführende Links
Den Security-Audit über alle Kunden automatisieren?
TenantSecure prüft OAuth-Apps, Anmeldungen, Weiterleitungen und acht Härtungs-Checks je Mandant automatisch – und liefert den Report im White-Label pro Kunde.