In vielen Unternehmen ist Microsoft-365 längst keine Office-Suite mehr, sondern die zentrale Plattform für Identitäten, E-Mail, Zusammenarbeit, Geräteverwaltung und geschäftskritische Daten. Diese Konzentration macht den Arbeitsalltag effizient. Sie sorgt aber auch dafür, dass eine einzelne Fehlkonfiguration weitreichende Folgen haben kann: Ein zu großzügiger Gastzugriff, eine dauerhaft privilegierte Rolle oder eine unkontrollierte Anwendung reicht unter Umständen aus, um mehrere Schutzebenen zu umgehen.
Ein Microsoft-365-Security-Assessment muss deshalb mehr leisten als eine Liste aktivierter Funktionen. Ob die Prüfung intern Security-Review, Security-Audit oder Tenant-Check genannt wird, ändert nichts am Qualitätsmaßstab: Sie sollte zeigen, welche Risiken im konkreten Tenant tatsächlich relevant sind, welche Kontrollen sie begrenzen und wo zwischen Konfiguration und gelebtem Betrieb eine Lücke besteht. Erst daraus entsteht eine belastbare Reihenfolge für die Härtung.
Ein Security-Assessment ist keine Checkliste
Eine Checkliste beantwortet, ob eine Einstellung vorhanden ist. Ein Audit muss zusätzlich prüfen, ob sie für die richtigen Benutzer, Geräte, Anwendungen und Daten gilt. Dieser Unterschied ist entscheidend. Eine Richtlinie kann im Portal korrekt aussehen und trotzdem kaum Wirkung entfalten, weil Ausnahmegruppen über Jahre gewachsen sind, Dienstkonten unberücksichtigt bleiben oder der geplante Rollout nie abgeschlossen wurde.
Deshalb beginnt eine Sicherheitsprüfung nicht mit dem Urteil „aktiv“ oder „nicht aktiv“, sondern mit dem Schutzbedarf: Welche Identitäten besitzen besonders weitreichende Rechte? Welche Daten wären bei einem Abfluss kritisch? Welche Anwendungen sind von einem Ausfall oder einer Kontenübernahme besonders betroffen? Erst wenn diese Fragen beantwortet sind, lässt sich bewerten, ob die vorhandenen Maßnahmen zum Risiko passen.
Secure-Score ist eine Datenquelle, kein Prüfergebnis
Microsoft-Secure-Score macht Empfehlungen sichtbar und hilft dabei, Fortschritt über die Zeit zu verfolgen. Der Wert eignet sich gut als Orientierung, darf aber nicht mit einer Risikobewertung verwechselt werden. Microsoft weist selbst darauf hin, dass der Score keine absolute Aussage darüber trifft, wie wahrscheinlich eine Kompromittierung ist. Er beschreibt vor allem, in welchem Umfang verfügbare Kontrollen umgesetzt wurden.
Für ein Assessment ist der Secure-Score daher ein Einstiegspunkt. Er liefert Hinweise auf mögliche Lücken, kennt aber weder die Geschäftsprozesse noch die technischen Abhängigkeiten eines Unternehmens. Eine Maßnahme mit vielen Score-Punkten kann für einen bestimmten Tenant weniger dringlich sein als eine unscheinbare Ausnahme in einer Richtlinie, die privilegierte Konten betrifft.
Prüffeld 1: Identitäten und privilegierte Rollen
Identitäten bilden das Fundament der meisten Microsoft-365-Sicherheitsmaßnahmen. Geprüft werden sollte nicht nur, ob Multi-Faktor-Authentifizierung grundsätzlich vorgesehen ist. Entscheidend ist die tatsächliche Abdeckung: Welche Konten können sich noch mit schwachen Methoden anmelden? Nutzen Administratoren phishingresistente Verfahren? Sind Notfallkonten sauber überwacht und von den üblichen Richtlinien sinnvoll abgegrenzt?
Ebenso wichtig sind privilegierte Rollen. Dauerhafte Zuweisungen, gemeinsam genutzte Administratorkonten und fehlende Wiedervorlagen erhöhen den Schadensradius eines erfolgreichen Angriffs. Ein belastbares Audit verbindet deshalb Rollen, Anmeldeverfahren, Conditional-Access und Identitätsrisiken zu einem gemeinsamen Befund.
Prüffeld 2: Geräte, Anwendungen und Zugriffsbedingungen
Ein gut abgesichertes Benutzerkonto reicht nicht aus, wenn der Zugriff von einem unbekannten oder kompromittierten Gerät möglich bleibt. Das Assessment sollte prüfen, ob der Gerätestatus in relevante Zugriffsentscheidungen einfließt, ob Compliance-Regeln technisch durchgesetzt werden und wie mit nicht verwalteten Endgeräten umgegangen wird.
Hinzu kommen registrierte Anwendungen und erteilte Berechtigungen. OAuth-Anwendungen können dauerhaft auf Postfächer, Dateien oder Verzeichnisdaten zugreifen, ohne dass sich ein Benutzer bei jedem Zugriff erneut anmeldet. Deshalb gehören App-Registrierungen, Einwilligungen und überprivilegierte Service Principals in dieselbe Prüfung wie Benutzerkonten und Geräte.
Prüffeld 3: Datenflüsse in Exchange, Teams, Sharepoint und Onedrive
Sicherheitslücken entstehen häufig nicht innerhalb eines einzelnen Dienstes, sondern an den Übergängen. Automatische Weiterleitungen, offene Freigabelinks, großzügige Gastrechte und unklare Aufbewahrungsregeln können sich gegenseitig verstärken. Ein Security-Assessment sollte diese Dienste daher nicht isoliert betrachten.
Bei Exchange-Online geht es unter anderem um Schutz vor Identitätsmissbrauch und schädlichen Inhalten. In Teams und Sharepoint stehen Gastzugriffe, externe Freigaben und die Reichweite von Berechtigungen im Vordergrund. Onedrive ergänzt die persönliche Datenablage und mögliche Synchronisationspfade. Das Ziel ist kein pauschales Verbot externer Zusammenarbeit, sondern eine nachvollziehbare Entscheidung darüber, welche Daten auf welchem Weg geteilt werden dürfen.
Prüffeld 4: Erkennung, Reaktion und Wiederherstellung
Prävention allein verhindert keinen Sicherheitsvorfall. Ein Tenant muss verdächtige Aktivitäten erkennen und eine Reaktion ermöglichen. Dafür braucht es die richtigen Protokolle, eine angemessene Aufbewahrung und geklärte Zuständigkeiten. Wer prüft Warnungen? Wer darf ein kompromittiertes Konto sperren? Wie wird verhindert, dass bei der Bereinigung wichtige Spuren verloren gehen?
Zur Widerstandsfähigkeit gehört außerdem die Wiederherstellung. Das Audit sollte deshalb klären, welche Daten und Konfigurationen wiederhergestellt werden können, welche Abhängigkeiten bestehen und ob die vorgesehenen Abläufe bereits praktisch getestet wurden. Eine dokumentierte Backup-Funktion ist noch kein Nachweis dafür, dass ein Geschäftsprozess nach einem Vorfall rechtzeitig wieder arbeitsfähig wird.
Nachweise statt Richtlinienabsicht
Der entscheidende Qualitätssprung entsteht, wenn das Assessment nicht nur Einstellungen liest, sondern ihre Wirksamkeit belegt. Bei Conditional-Access kann das beispielsweise bedeuten, Richtlinien zunächst im Berichtmodus auszuwerten, typische Anmeldeszenarien zu testen und Ausnahmen einzeln nachzuvollziehen. Bei privilegierten Rollen reicht eine Liste der Zuweisungen nicht aus; zusätzlich muss erkennbar sein, ob Aktivierungen protokolliert, begründet und regelmäßig überprüft werden.
Auch der Gegenbeweis gehört dazu: Welche Konten oder Anwendungen fallen nicht unter die erwartete Kontrolle? Welche Richtlinie wird durch eine andere Einstellung abgeschwächt? Solche Zusammenhänge bleiben in standardisierten Portalauswertungen häufig unsichtbar, bestimmen aber das reale Risiko.
Der Betrieb entscheidet über die Haltbarkeit
Ein Tenant verändert sich laufend. Neue Mitarbeitende, Gäste, Anwendungen und Projekte verändern Berechtigungen und Datenflüsse; technische Änderungen schaffen neue Ausnahmen. Ein Bericht, der nur den Stichtag beschreibt, verliert deshalb schnell an Wert.
Ein gutes Assessment bewertet auch das Betriebsmodell: Wer verantwortet Ausnahmen? Haben sie ein Ablaufdatum? Werden privilegierte Rollen und App-Berechtigungen turnusmäßig überprüft? Gibt es nach größeren Änderungen einen Re-Test? Hilfreich ist ein kleiner, wiederholbarer Satz an Nachweisen, etwa zur MFA-Abdeckung, zu offenen Hochrisiko-Befunden, dauerhaften Admin-Zuweisungen und überfälligen Zugriffsprüfungen.
Was ein belastbarer Abschlussbericht enthalten sollte
Ein guter Bericht übersetzt technische Beobachtungen in Entscheidungen. Jeder wesentliche Befund braucht einen Risikobezug, die betroffenen Schutzobjekte, eine empfohlene Maßnahme und ein Kriterium für den späteren Wirksamkeitsnachweis. Außerdem sollten Sofortmaßnahmen von strukturellen Verbesserungen getrennt werden.
Die Reihenfolge richtet sich nicht nach der bequemsten Umsetzung. Kritische Identitätslücken kommen vor Komfortoptimierungen. Änderungen mit Lockout-Risiko werden zunächst ausgewertet, dann an Pilotgruppen getestet und erst anschließend breiter ausgerollt. Zu jeder größeren Änderung gehört ein Rückfallweg. Ein späterer Re-Check belegt, ob die beschlossene Maßnahme tatsächlich greift oder nur auf dem Papier abgeschlossen wurde.
Wer eine solche Standortbestimmung mit priorisiertem Maßnahmenkatalog benötigt, kann einen Microsoft-365-Hardening-Check von Siller.consulting als Ausgangspunkt nutzen. Der Wert eines Assessments liegt am Ende nicht in einer möglichst hohen Punktzahl, sondern in belastbaren Antworten auf drei Fragen: Wo besteht ein relevantes Risiko, welche Maßnahme senkt es und woran lässt sich ihre Wirkung nachweisen?
Von Aaron Siller, Microsoft MVP für Security und Gründer von siller.consulting
Über den Autor: Aaron Siller ist Microsoft MVP für Security, Fachbuchautor („Microsoft 365 absichern“, Rheinwerk Verlag) und Gründer von Siller.consulting. Er prüft und härtet Microsoft-365-Tenants in mittelständischen Organisationen – vom Identitätsfundament bis zum Betriebsmodell.
