Microsoft 365 Tenant-Review: Die 7 Prüfpunkte, an denen Audits scheitern
Über 30 Tenant-Reviews in Banken, Versicherungen, bei KRITIS-Betreibern und Mittelständlern zeigen ein erstaunlich stabiles Bild: Es sind fast immer dieselben Findings, unabhängig von Branche, Größe und IT-Reife. Dieser Artikel listet die sieben Prüfpunkte, die in fast jedem Bericht auftauchen, jeweils mit einem Selbsttest, den Sie heute in Ihrem eigenen Tenant durchführen können.
Warum gut laufende Tenants trotzdem durchfallen
Die meisten Tenants, die wir prüfen, laufen seit Jahren stabil. E-Mails gehen raus, Teams funktioniert, niemand beschwert sich. Genau das ist die Falle: Ein Tenant wurde irgendwann eingerichtet, oft unter Zeitdruck, und seitdem kaum systematisch angefasst. Die Defaults von damals gelten noch heute, obwohl sich Nutzung, Bedrohungslage und Regulatorik längst verändert haben.
Ein Audit prüft aber nicht, ob der Tenant läuft. Es prüft, ob die Kontrollen wirksam sind und nachgewiesen werden können. Der Unterschied zwischen "läuft" und "besteht" liegt fast immer in den folgenden sieben Punkten.
Privilegierte Rollen und Global Admins
Der Klassiker in jedem Bericht: 8, 11, manchmal 14 dauerhafte Global Admins, darunter regelmäßig Konten ehemaliger Mitarbeiter, die technisch noch aktiv sind. Microsoft empfiehlt weniger als 5 Global Admins, alle weiteren privilegierten Zugriffe gehören über PIM mit zeitlich begrenzter Aktivierung abgebildet.
Oft übersehen werden dabei die stillen privilegierten Rollen. Global Reader etwa klingt harmlos, sieht aber die komplette Tenant-Konfiguration inklusive Conditional Access und Identity Protection und steht nicht ohne Grund auf Microsofts Liste der privilegierten Entra-Rollen.
Selbsttest: Entra Admin Center, Rollen und Administratoren, Global Administrator öffnen. Mehr als 5 dauerhafte Zuweisungen oder Namen, die das Unternehmen verlassen haben, sind ein Finding.
MFA-Lücken und Legacy Authentication
MFA für alle ist in vielen Tenants beschlossen, aber nicht durchgesetzt. Typische Lücken: einzelne Admin-Konten mit Ausnahmen, Service-Konten ohne moderne Authentifizierung, und Legacy-Protokolle wie SMTP Auth, POP3 oder IMAP, die MFA komplett umgehen.
Für privilegierte Rollen reicht App-Push-MFA in regulierten Umgebungen nicht mehr aus. NIS2 und die BaFin-Prüfpraxis erwarten phishing-resistente Verfahren, also FIDO2-Keys oder Passkeys, mindestens für Tier-0-Rollen.
Selbsttest: Im Entra Admin Center die Sign-in Logs nach Legacy Authentication filtern. Jeder Treffer ist ein aktives Einfallstor, das eine Conditional-Access-Policy schließen sollte.
Conditional-Access-Abdeckung und Break-Glass
Häufiges Bild: eine Handvoll Policies, historisch gewachsen, niemand weiß mehr, warum sie so konfiguriert sind. Es fehlt eine Baseline (Legacy Auth blockiert, MFA für alle, Geo-Blocking, Device Compliance für sensible Apps), und es fehlen dokumentierte Break-Glass-Accounts, die von allen Policies ausgenommen und überwacht sind.
Ohne Break-Glass-Konzept ist jede scharfe Policy ein Lockout-Risiko. Mit undokumentierten Ausnahmen ist jede Policy ein Audit-Finding. Beides sehen wir regelmäßig gleichzeitig.
Selbsttest: Existieren zwei dokumentierte, Cloud-only Break-Glass-Accounts mit FIDO2, ausgenommen von allen Policies, mit Alert bei Anmeldung? Wenn die Antwort zögert, lautet sie Nein.
SharePoint-Sharing und Gastkonten
Der Default "Anyone" im SharePoint-Sharing bedeutet: Jeder Mitarbeiter kann jedes Dokument mit jeder externen Person teilen, ohne Genehmigung, ohne Ablaufdatum. Dazu kommen Gastkonten aus beendeten Projekten, die ihren Zugriff über nie aufgelöste Teams-Mitgliedschaften und gewachsene SharePoint-Rechte geerbt haben.
Solange niemand hinschaut, sind das schlafende Konten. Nach einem Copilot-Rollout sind es aktive Datenzugänge. Access Reviews sind in Entra ID P2 enthalten und bei jedem E5-Kunden längst bezahlt, konfiguriert sind sie in den wenigsten Tenants.
Selbsttest: SharePoint Admin Center, Policies, Sharing prüfen (Ziel: "New and existing guests", Default-Link "Specific people"). Parallel im Entra Admin Center Gäste nach letzter Anmeldung älter als 180 Tage filtern.
Audit Log Retention
Die Standard-Aufbewahrung des Unified Audit Log liegt je nach Lizenz und Tenant-Alter bei 90 oder 180 Tagen. Für NIS2, ISO 27001 und die BaFin-Prüfpraxis braucht es mindestens ein Jahr. Wenn ein Vorfall heute entdeckt wird und vor acht Monaten begann, sind die Logs mit Standard-Retention weg.
Mit E5 ist die Verlängerung auf ein Jahr über eine Audit Retention Policy in Minuten konfiguriert, für ausgewählte Konten sind bis zu 10 Jahre möglich. In 8 von 10 Tenants, die wir reviewen, ist diese Einstellung nie angefasst worden.
Selbsttest: Im Purview-Portal unter Audit die Retention Policies öffnen. Existiert keine Policy mit 365 Tagen, läuft Ihre Nachweisfähigkeit auf Standardfrist.
Bezahlte, nie aktivierte Compliance-Features
Der teuerste Befund steht selten im Risikobericht, sondern in der Lizenzrechnung. E5-Tenants bezahlen Sensitivity Labels, DLP, Insider Risk Management, Communication Compliance und eDiscovery Premium jeden Monat mit. Aktiv ist davon oft: nichts. Keine Labels in echter Nutzung, DLP im Testmodus oder gar nicht vorhanden, Insider Risk nie konfiguriert.
Im Audit zählt eine DLP-Policy als Word-Datei nicht als Kontrolle. Eine aktive Policy mit 90 Tagen Audit-Historie schon. Genau dieser Unterschied entscheidet, ob die Prüfung in drei Wochen durch ist oder in Nachforderungen endet.
Selbsttest: Purview-Portal öffnen und drei Fragen beantworten: Wie viele Dokumente tragen ein Label? Welche DLP-Policies laufen im Enforce-Modus? Ist Insider Risk Management konfiguriert? Dreimal Nein bei vorhandener E5-Lizenz ist bezahlter, ungenutzter Schutz.
Service Accounts und Workload Identities
Ein typischer Tenant hat 5 bis 25 Service Accounts: für Backup, Drucker, Migrationstools, die seit Jahren nicht mehr laufen. Was wir finden: Global-Admin-Rechte "weil es damals schneller ging", Passwörter, die seit Jahren nicht geändert wurden, keine MFA, kein Inventar.
Das Argument "Service Accounts können kein MFA" stimmt. Aber sie können Certificate-based Authentication oder Managed Identities, und Conditional Access kann sie auf feste IP-Bereiche einschränken. Service Accounts sind die häufigste Tür für laterale Bewegung nach einer initialen Kompromittierung.
Selbsttest: Alle Konten mit privilegierten Rollen und letzter Anmeldung älter als 90 Tage exportieren. Jedes Konto ohne dokumentierten Owner und Zweck gehört deaktiviert oder gehärtet.
Faustregel: Ein Partner-Assessment ist Vertrieb. Ein unabhängiges Audit ist Prüfung. Wer beides vom selben Anbieter bezieht, der anschließend die Lizenzen oder das Projekt verkauft, hat keins von beidem.
Das Ernüchternde und zugleich Ermutigende an dieser Liste: Die Punkte 1, 4 und 5 sind in 30 Minuten prüfbar und in wenigen Stunden behebbar. Die Punkte 2, 3 und 7 brauchen wenige Tage strukturierter Arbeit. Nur Punkt 6 ist ein echtes Projekt. Ein vollständiges Review mit Bericht, Risikobewertung und priorisierter Roadmap dauert bei einem mittleren Tenant wenige Tage. Der Unterschied im nächsten Audit ist erheblich.
Unabhängiges M365 Risiko-Audit
Wir prüfen Ihren Tenant gegen genau diese Punkte und den regulatorischen Rahmen Ihrer Branche. Sie erhalten einen Bericht mit Risikobewertung und priorisierter Roadmap, unabhängig von Lizenz- oder Projektvertrieb.
Zum Risiko-Audit