Wie überprüfe ich meinen Microsoft-365-Tenant regelmäßig, um Sicherheit, Kosten und Struktur im Griff zu behalten?

Sicherheitsreview: Identitäten, Conditional Access, privilegierte Rollen, Geräte- und App-Zugriffe belastbar prüfen

Ein Sicherheitsreview in Microsoft 365 scheitert selten an „offensichtlichen“ Fehlkonfigurationen, sondern an Drift: neue Konten, zusätzliche Identitätsquellen, nachträglich eingeführte Ausnahmen, temporäre Admin-Rechte, neue Unternehmensgeräte und App-Integrationen, die den Kontrollrahmen schrittweise aushebeln. Ein belastbares Review konzentriert sich deshalb auf Identitäten (menschlich und nicht-menschlich), auf Conditional Access als Policy-Schicht, auf privilegierte Rollen sowie auf Geräte- und App-Zugriffe inklusive OAuth- und Consent-Pfade.

Als Datenbasis dienen Microsoft Entra ID (Identity), Conditional Access Reports, Entra Audit- und Sign-in-Logs sowie Workbooks und „Insights“ aus Microsoft Defender for Cloud Apps und Microsoft Defender for Identity, sofern verfügbar. Für Stichproben empfiehlt sich die Korrelation einzelner Sign-ins mit CA-Entscheidungen, Gerätestatus, Token-Details und App-ID, um Ausnahmegründe nachvollziehbar zu belegen.

Identitäten prüfen: Kontolebenszyklus, Authentifizierung, „Non-Human Identities“

Im Identitätsreview stehen zunächst Hygiene und Lebenszyklus im Vordergrund: verwaiste Konten, fehlende Deprovisionierung, uneinheitliche Namenskonventionen, unklare Ownership von Service-Accounts und ein Wildwuchs an Gastbenutzern. Parallel muss die Authentifizierungslage realistisch bewertet werden: Welche Anmeldearten kommen tatsächlich vor, wo greifen MFA- und Phishing-resistente Verfahren, und welche Legacy-Protokolle erzeugen unkontrollierbare Ausnahmen?

Kritisch sind nicht-menschliche Identitäten: App-Registrierungen, Service Principals, verwaltete Identitäten (in Azure), Automationen, Zertifikats- oder Secret-basierte Zugriffe. Diese Identitäten verursachen häufig langfristige Berechtigungen, die aus Projektphasen stammen und später niemand mehr verantwortet. Ein Review verlangt daher Ownership, Rotation, Ablaufdaten und eine Minimierung von Berechtigungen (Graph, Exchange, SharePoint) auf das benötigte Maß.

• Inaktive und riskante Konten: Get-MgUser -All -Property Id,UserPrincipalName,AccountEnabled,CreatedDateTime,SignInActivity
Get-MgRiskyUser -All (Identity Protection erforderlich; je nach Lizenz/Policy nicht in jedem Tenant verfügbar)
• Legacy-Authentifizierung identifizieren: Get-MgReportAuthenticationMethodUserRegistrationDetail -All (Registrierungsstatus) und Auswertung der Sign-in-Logs nach ClientAppUsed (z. B. IMAP4, POP3, Other clients)
• Gastbenutzer und Sponsoren: Get-MgUser -Filter "userType eq 'Guest'" -All (mit Prüfung von Einladungsdatum, letzter Anmeldung, Sponsor/Owner über geeignete Directory-Attribute/Prozesse und Access Reviews)
• App-Identitäten und Credentials: Get-MgApplication -All -Property AppId,DisplayName,PasswordCredentials,KeyCredentials
Get-MgServicePrincipal -All -Property AppId,DisplayName,AppRoleAssignments (OAuth-Scopes/Grants separat über OAuth2PermissionGrants/AppRoleAssignments auswerten)

Conditional Access: Policy-Design, Coverage, Ausnahmen und reale Wirksamkeit

Conditional Access (CA) wirkt nur so gut wie seine Abdeckung. Im Review zählt weniger die Anzahl der Policies als die Frage, ob alle relevanten Benutzer- und App-Pfade kontrolliert werden: Admin-Zugriffe, externe Zugriffe, Gastzugriffe, Legacy-Clients, risikobasierte Entscheidungen und der Zugriff auf sensible Cloud-Apps. Jede Ausnahme (Exclusions) muss einen dokumentierten Grund, einen Owner und ein Ablaufdatum besitzen; dauerhaft offene Ausnahmen sind ein wiederkehrender Befund.

Belastbar wird die Prüfung erst, wenn Policies gegen echte Sign-ins verifiziert werden: Wurden Block- oder Require-Controls tatsächlich angewendet? Sind „Report-only“-Policies seit Monaten ohne Umstellung? Treten häufige „Not Applied“-Entscheidungen auf, etwa wegen fehlender Zielgruppen, nicht unterstützter Clients oder weil die Policy-Bedingungen nicht zutrafen? Die Korrelation von Sign-in-Details mit CA-Entscheidungen reduziert Interpretationsspielräume.

• Policy-Inventar und Zielgruppen: Get-MgIdentityConditionalAccessPolicy -All (Abgleich von IncludeUsers/ExcludeUsers, IncludeApplications, Locations, Device Filters)
• Wirksamkeit über Sign-ins: Analyse der Entra Sign-in-Logs (Felder conditionalAccessStatus, appliedConditionalAccessPolicies, authenticationRequirement, isInteractive) und Stichproben für kritische Apps
• Ausnahmen mit Ablauf: Review aller Exclusions gegen Ticket/Change-Referenz; technische Durchsetzung über gruppenbasierte Exclusion-Gruppen mit dokumentiertem Ablauf-/Rezertifizierungsprozess (z. B. regelmäßige Access Reviews/Owner-Bestätigung)

Privilegierte Rollen: PIM, Rollenminimierung und Admin-Pfade absichern

Privilegien sind der Multiplikator jedes Identitätsvorfalls. Im Review wird daher nicht nur gezählt, wie viele Global Admins existieren, sondern ob Rollen zweckmäßig zugeschnitten sind und ob Aktivierung, Laufzeiten, Genehmigungen und Nachweise konsistent sind. Microsoft Entra Privileged Identity Management (PIM) sollte für Entra-Rollen und – soweit im Einsatz – für Azure-Ressourcenrollen die Regel sein: „Eligible“ statt „Permanent Active“, kurze Aktivierungsfenster, Begründungspflicht und Alarmierung bei Rollenänderungen.

Zusätzlich gehören Break-Glass-Konten in den Prüfrahmen: stark abgesichert, selten verwendet, dokumentiert, mit überwachten Sign-ins und klaren Aufbewahrungs- und Testprozessen. Häufige Findings sind übersehene Administratoren aus Altprojekten, privilegierte Gruppen mit unklarem Owner oder Admins, die dauerhaft ohne starke Authentifizierung arbeiten, weil CA-Ausnahmen historisch gewachsen sind.

• Rollenbesetzung und Dauerrechte: Get-MgDirectoryRole -All und Auflösung der Mitglieder (Rollenmitgliedschaften, gruppenbasierte Zuweisungen) mit Fokus auf Global Administrator, Privileged Role Administrator, Security Administrator, Exchange Administrator (Hinweis: nur aktivierte DirectoryRoles; zusätzlich RoleDefinitions/RoleAssignments auswerten)
• PIM-Status und Aktivierungsparameter: PIM-Auswertung in Entra (Eligible vs. Active, Activation max duration, Approval, MFA/Authentication Strength bei Aktivierung) und Alarmregeln für Rollenänderungen
• Admin-Pfade absichern: Separate CA-Policy für Admin-Portale und Admin-Aktionen, starke Authentifizierung, compliant device oder trusted locations, Block für riskante Sign-ins

Geräte- und App-Zugriffe: Compliance, Token-Rechte, Consent und OAuth-Governance

Geräte- und App-Zugriffe verbinden Identity und Datenebene. Im Review wird deshalb geprüft, ob Unternehmensanforderungen technisch durchgesetzt werden: Geräte müssen registriert und – je nach Schutzbedarf – als compliant bewertet sein; MDM/MAM-Policies dürfen nicht nur existieren, sondern in den Sign-ins als Device State sichtbar greifen. Parallel muss der App-Zugriffskanal kontrolliert werden: Benutzer-Consent, Admin-Consent-Workflows, Publisher Verification, sowie die Überwachung von OAuth-Berechtigungen, insbesondere für weitreichende Graph-Scopes.

Typische Drift-Signale sind: viele „unknown“ Geräte in Sign-ins, CA-Policies ohne Device Condition, langfristig gültige Refresh Tokens durch fehlende Sitzungssteuerung, sowie App-Registrierungen mit breit vergebenen Application Permissions ohne Rezertifizierung. Eine belastbare Prüfung kombiniert Entra-Daten (Enterprise Apps, Permissions, Sign-ins) mit Defender for Cloud Apps (App Governance / OAuth App Insights, sofern lizenziert), um ungewöhnliche Datenzugriffe und riskante Apps sichtbar zu machen.

• Geräteabdeckung und Status: Auswertung in Intune und Entra (registriert, compliant, Hybrid Joined/Azure AD Joined) sowie Sign-in-Log-Felder deviceDetail und isCompliant
• Consent-Governance: Prüfung der Einstellungen für User Consent und Admin Consent Workflow in Entra; Review neuer Consent-Ereignisse in Audit Logs (z. B. Consent to application)
• Enterprise Apps und Berechtigungen: Get-MgServicePrincipal -All sowie Review von App-Rollen-Zuweisungen und OAuth-Grants (z. B. über oauth2PermissionGrants); Fokus auf hochprivilegierte Scopes wie Directory.ReadWrite.All oder Mail.Read in Kombination mit externen Publishern
• Sitzungs- und Token-Kontrollen: CA Session Controls (Sign-in frequency, Persistent browser session) sowie regelmäßige Token-Invalidierung bei Incident/Offboarding über Revoke-MgUserSignInSession (wirkt auf Refresh Tokens/Sessions; Apps können je nach Token-/Cache-Verhalten verzögert reagieren)

Kosten- und Lizenzreview: Lizenzzuordnung, Add-ons, Inaktivität, Self-Service und Schatten-IT finanziell einordnen

Ein Kosten- und Lizenzreview in Microsoft 365 zielt nicht auf „günstiger um jeden Preis“, sondern auf nachvollziehbare, regelkonforme Lizenzzuordnung und auf das Erkennen von schleichenden Kostentreibern: ungenutzte Pläne, Add-ons ohne Bedarf, doppelte Abdeckung durch ähnliche Produkte sowie Self-Service-Käufe, die am zentralen Beschaffungsprozess vorbeilaufen. In der Praxis entstehen Mehrkosten häufig nicht durch einzelne Fehlentscheidungen, sondern durch fehlende Korrekturzyklen bei Personalwechseln, Projektenden, Tool-Einführungen und geänderten Funktionsanforderungen.

Review-Umfang und Datenbasis: belastbare Zahlen statt Bauchgefühl

Die wichtigste Vorarbeit besteht darin, die betrachteten Kostenstellen und Lizenzfamilien sauber zu definieren: Basispläne (z. B. E3/E5, Business-Pläne), Add-ons (z. B. Telefonie, Security, Compliance), nutzungsabhängige Services sowie Drittanbieter-Abonnements, die über Marketplace oder Kreditkarte beschafft wurden. Die Datengrundlage sollte aus dem Microsoft 365 Admin Center (Abrechnung und Lizenzen), Microsoft Entra ID (Benutzerstatus, Gastkonten), Nutzungsberichten sowie – falls im Unternehmen etabliert – aus FinOps-/Beschaffungsdaten stammen. Ein Review ist nur dann auditierbar, wenn für jede Abweichung nachvollziehbar bleibt, ob sie aus einem fachlichen Bedarf oder aus Governance-Lücken resultiert.

Für die technische Erhebung haben sich zwei Zugänge bewährt: Erstens eine Portal-basierte Sicht für Abrechnung, Self-Service und Marketplace; zweitens eine reproduzierbare Auswertung per Microsoft Graph, um Zuweisungen, Pläne und Statuswerte systematisch zu erfassen. Graph-Auswertungen sollten auf wiederholbare Filter (z. B. „directly assigned“, „inactive“, „disabled“) und einen festen Stichtag gesetzt werden, um Trends über mehrere Zyklen zu erkennen.

Lizenzzuordnung prüfen: Rollenmodelle, Servicepläne und „zu viel des Guten“

Ein belastbares Lizenzmodell orientiert sich an Rollenprofilen (Persona- oder Job-Role-Modell) und nicht an historischen Einzelentscheidungen. Im Review wird daher je Rolle definiert, welche Funktionen zwingend benötigt werden, welche optional sind und welche nicht zugewiesen werden dürfen. Ein häufiger Befund ist die pauschale Vergabe hochpreisiger Pläne an Benutzergruppen, die nur Teilfunktionen nutzen. Der Gegenentwurf ist nicht „Downgrade nach Gefühl“, sondern ein Abgleich zwischen Funktionsbedarf, aktivierten Serviceplänen und gemessener Nutzung.

Wichtig ist die Unterscheidung zwischen Lizenzplan und einzelnen Serviceplänen innerhalb der Lizenz. In vielen Umgebungen bleiben Servicepläne ungenutzt, verursachen aber indirekte Kosten, etwa durch Folgeaufwände im Betrieb oder durch zusätzliche Datenhaltung. Eine gezielte Deaktivierung einzelner Servicepläne kann Governance unterstützen (z. B. Einschränkung bestimmter Apps), ersetzt aber keine korrekte Wahl des übergeordneten Lizenzpakets. Bei Änderungen müssen Abhängigkeiten berücksichtigt werden, etwa Postfachfunktionen, Archivierung/Retention oder Telefoniekomponenten, die sich nicht rein technisch „abschalten“, ohne fachliche Prozesse zu berühren.

• Lizenz- und SKU-Übersicht (Graph): GET https://graph.microsoft.com/v1.0/subscribedSkus
• Zuweisungen je Benutzer (Graph): GET https://graph.microsoft.com/v1.0/users?$select=id,displayName,userPrincipalName,accountEnabled,assignedLicenses
• Anmeldeaktivität für Inaktivitätsscreening (Graph): GET https://graph.microsoft.com/v1.0/users?$select=id,displayName,userPrincipalName,signInActivity (SignInActivity erfordert passende Berechtigungen und ist nicht in jedem Tenant/Plan verfügbar)
• Lizenzbereinigung nach Rollenwechsel: POST https://graph.microsoft.com/v1.0/users/{id}/assignLicense
{"addLicenses":[...],"removeLicenses":[...]}

Add-ons und doppelte Abdeckung: Überschneidungen sichtbar machen

Add-ons sind der klassische Kostentreiber, weil sie oft projektbezogen eingeführt und später nicht konsequent zurückgebaut werden. Im Review sollten Add-ons in drei Kategorien fallen: (1) zwingend aufgrund regulatorischer oder technischer Anforderungen, (2) sinnvoll für klar definierte Rollen, (3) historisch gewachsen ohne aktuelle Nutzungs- oder Bedarfsnachweise. Besonders sorgfältig ist bei Überschneidungen zu prüfen, wenn Funktionen aus Suite-Plänen (z. B. Security/Compliance-Funktionen) parallel als Einzelprodukte oder Drittprodukte beschafft wurden. Der Nachweis erfolgt über konkrete Nutzungssignale und Konfigurationen, nicht über Installationszahlen.

Für Add-ons ist zudem die Lizenzierungslogik relevant: Einige Komponenten werden pro Benutzer, andere pro Ressource oder Kapazität abgerechnet. Das Review sollte daher technische Konfigurationen (z. B. aktivierte Telefonie-Features, Archivierung, erweiterte Schutzfunktionen) mit der Abrechnungssicht zusammenführen. Eine häufige Ursache für „Phantomkosten“ sind nachträglich aktivierte Zusatzpakete, die nicht mit dem Rollenmodell synchronisiert wurden.

Inaktivität, verwaiste Identitäten und Lifecycle: Kosten sauber zuordnen

Inaktivität ist kein rein sicherheitsrelevantes Thema, sondern ein Kostenindikator. Lizenzen für deaktivierte Benutzer, technische Konten ohne klare Owner-Zuordnung, ehemalige Dienstleister oder dauerhaft inaktive Gastkonten binden Budget und verschleiern die tatsächliche Lizenznachfrage. Ein Review sollte Inaktivität nicht nur als „keine Anmeldung“, sondern als Lifecycle-Problem verstehen: Fehlt ein Prozess, der bei Austritt/Projektende automatisch Lizenzen entzieht, Konten sperrt, Postfächer und Daten rechtssicher behandelt und Verantwortlichkeiten dokumentiert, entstehen regelmäßig wiederkehrende Kosten.

Für die Bewertung eignet sich ein abgestufter Kriterienkatalog, etwa „deaktiviert, aber lizenziert“, „aktiviert, jedoch seit X Tagen keine interaktive Anmeldung“, „Gast ohne Sponsor“, „Shared-/Ressourcenkonto mit Benutzerlizenz“. Schwellenwerte sollten organisationsintern festgelegt werden, da sie von Betriebsmodellen (Schichtbetrieb, saisonale Nutzung) und Compliance-Anforderungen abhängen. Entscheidend bleibt, dass jede Ausnahme einen dokumentierten Grund und einen Owner hat.

Self-Service, Marketplace und Schatten-IT: finanzielle Governance statt Verbotskultur

Self-Service-Käufe und Marketplace-Subscriptions verschieben Kosten aus dem zentralen Lizenzmanagement in dezentrale Budgets oder Kreditkartenabrechnungen. Dadurch gehen Vergleichbarkeit, Mengenrabatte und einheitliche Sicherheitsprüfungen verloren. Im Kostenreview steht weniger die pauschale Deaktivierung im Vordergrund als die Transparenz: Welche Produkte wurden beschafft, über welche Identitäten, mit welchen Laufzeiten, und wie werden sie Kostenstellen zugeordnet? Besonders relevant sind Abonnements, die parallel zu vorhandenen Microsoft-365-Funktionen beschafft wurden (doppelte Abdeckung) oder die Daten in externe Tenants/Clouds verlagern.

Ein praxistaugliches Vorgehen kombiniert Richtlinien (wer darf kaufen, wer genehmigt), technische Kontrollen (Einschränkung von Self-Service, klare Rollen für Beschaffung) und einen schlanken Ausnahmeprozess. Damit bleibt Innovation möglich, während Kosten und Risiken nachvollziehbar werden. Im Review sollten alle gefundenen Self-Service-Produkte mit Owner, fachlichem Nutzen, Datenklassifizierung, Vertragslaufzeit und Alternativen im Standardportfolio erfasst werden. Erst daraus lassen sich belastbare Entscheidungen ableiten: Konsolidierung, Weiterbetrieb mit Governance, oder kontrollierte Ablösung.

Architektur- und Betriebsreview: SharePoint/Teams/Exchange-Strukturen, Datenhaltung, Governance, Monitoring und Dokumentation in den Alltag überführen

Ein Architektur- und Betriebsreview ergänzt Security- und Lizenzprüfungen um die Frage, ob die Kollaborations- und Messaging-Plattform noch steuerbar bleibt: Informationsarchitektur, Namens- und Lebenszyklusregeln, Datenorte, Berechtigungsmodelle, Backup-/Wiederherstellungsfähigkeit, Monitoring und eine Dokumentation, die im Betrieb tatsächlich genutzt wird. Im Fokus stehen wiederkehrende Drift-Effekte, etwa unkontrollierte Teams-Erstellung, wachsende SharePoint-Site-Sammlungen ohne Eigentümer, oder Exchange-Objekte, die historisch gewachsen sind und sich in keinem Betriebsmodell wiederfinden.

SharePoint und OneDrive: Informationsarchitektur, Berechtigungen und Datenorte

Bei SharePoint entscheidet sich die spätere Beherrschbarkeit oft an drei Stellen: der Site-Struktur (Hub Sites, Kommunikations- vs. Teamsites), dem Berechtigungsmodell (Gruppen statt Einzelrechte, restriktives Sharing) und dem Datenlebenszyklus (Aufbewahrung, Archivierung, Löschkonzepte). Ein Review betrachtet deshalb nicht nur technische Einstellungen im SharePoint Admin Center, sondern auch Stichproben aus produktiven Sites: Welche Vorlagen werden genutzt, wie konsistent sind Owner hinterlegt, wie häufig werden eindeutige Berechtigungen gebrochen, und wie viele externe Freigaben sind tatsächlich begründet.

Für OneDrive steht die Datenhaltung bei Offboarding und Rechtsfällen im Vordergrund. Typische Abweichungen entstehen durch zu kurze oder zu lange Aufbewahrungsfristen, fehlende Stellvertretungsregelungen sowie unklare Übergabepfade in SharePoint. Zusätzlich sollte geprüft werden, ob Sharing-Links mit „Jeder mit dem Link“ (sofern überhaupt erlaubt) als Standard vermieden werden und ob das Reporting zu externem Sharing regelmäßig ausgewertet wird.

• Site- und Hub-Inventar: Get-PnPTenantSite -IncludeOneDriveSites:$false (Stichprobe, Owner, Storage, LastContentModifiedDate)
• Externe Freigaben prüfen: SharePoint Admin Center → Richtlinien → Freigabe sowie Site-Level-Ausnahmen; Stichprobe über Unified Audit Log (z. B. „SharingSet“, „AnonymousLinkCreated“)
• OneDrive-Aufbewahrung bei Offboarding: Microsoft Purview → Data lifecycle management (Retention) und OneDrive Admin-Einstellungen für Zugriff durch Manager/Delegierte; Abgleich mit HR-Offboarding-Prozess
• Gastzugriffe und Cross-Tenant-Kollaboration: Entra External Identities + SharePoint Sharing-Policies; Abgleich, ob B2B direct connect oder klassische Gäste genutzt werden und wie Ownership sichergestellt wird

Teams: Sprawl eindämmen, Lebenszyklen festlegen, Compliance-Anforderungen abbilden

Teams-Wildwuchs ist selten ein reines „Teams“-Problem; meist fehlt ein konsistentes Modell für Microsoft-365-Gruppen, Namenskonventionen, Genehmigungsprozesse und die Stilllegung inaktiver Arbeitsräume. Im Review werden daher sowohl Teams-Richtlinien (Erstellung, Apps, Gastzugriff) als auch die dahinterliegenden Gruppen-Objekte untersucht. Entscheidend ist die Trennung zwischen Arbeitsräumen mit klaren Ownership-Regeln und temporären Kollaborationen, die nach Projektende automatisch auslaufen.

Für Datenhaltung und Auffindbarkeit werden außerdem Private Channels und Shared Channels betrachtet, weil sie zusätzliche SharePoint-Sites erzeugen oder Cross-Tenant-Szenarien ermöglichen. Ohne dokumentierte Leitplanken entstehen Schattenstrukturen, die eDiscovery und Aufbewahrung erschweren. Ein Review sollte daher Teams-Templates, Sensitivity Labels (Teams/Groups) und die Zuordnung zu DLP-/Retention-Policies als prüfbare Kriterien festhalten.

Exchange Online: Identitäten, Mailfluss, Postfachtypen und Aufbewahrung

Ein Exchange-Review fokussiert Betriebsrisiken: unklare Mailflussregeln, gewachsene Verteiler- und Ressourcenstrukturen, fehlende Verantwortlichkeiten bei Shared Mailboxes sowie inkonsistente Aufbewahrung. Besonders häufig fallen Weiterleitungen (intern/extern), veraltete Transportregeln, zu weit gefasste Connectoren oder SPF/DKIM/DMARC-Abweichungen auf, die Spoofing-Risiken erhöhen. Auch bei scheinbar „kleinen“ Änderungen, etwa neuen SaaS-Anbindungen, entstehen schnell Ausnahmen, die dauerhaft im Tenant verbleiben.

Zusätzlich gehört die betriebliche Wiederherstellungsfähigkeit auf die Prüfliste: Wie werden gelöschte Postfächer, Mails oder öffentliche Ordner (falls vorhanden) wiederhergestellt, wie lange reichen Standard-Retention-Zeiten, und ist der Zugriff auf Audit-Daten ausreichend lang verfügbar. Purview-Policies (Retention, eDiscovery) sollten mit Exchange-Konfigurationen konsistent sein, damit Aufbewahrungsanforderungen nicht durch lokale Ausnahmen unterlaufen werden.

• Weiterleitungen und Inbox-Regeln: Get-Mailbox -ResultSize Unlimited | Get-InboxRule (Stichprobe) sowie Get-Mailbox -ResultSize Unlimited | Select DisplayName,ForwardingSmtpAddress,DeliverToMailboxAndForward
• Transportregeln und Connectoren: Get-TransportRule
Get-InboundConnector
Get-OutboundConnector
• Authentifizierungsstatus der Domains: Get-DkimSigningConfig (DKIM aktiviert, korrekte Selector-DNS) sowie DMARC/SPF per DNS-Review
• Shared Mailboxes und Berechtigungen: Get-Mailbox -RecipientTypeDetails SharedMailbox plus Stichprobe Get-MailboxPermission und Get-RecipientPermission (Owner, Delegationen, MFA-Absicherung der zugreifenden Konten)

Governance und Betriebsmodell: Rollen, Prozesse, Change-Kontrollen

Technische Standards wirken nur, wenn sie in ein Betriebsmodell übersetzt werden. Ein Review prüft deshalb Rollen und Verantwortlichkeiten entlang der Plattform: Wer darf Teams/Sites anlegen, wer genehmigt Ausnahmen, wie wird Ownership geprüft, und wie werden Änderungen an Richtlinien nachvollziehbar freigegeben. Zentral ist die Verzahnung von Entra-Rollen, Admin-Rollen in den Workloads und operativen Runbooks, damit privilegierte Tätigkeiten nicht auf einzelne Personen konzentriert bleiben.

Zur Change-Kontrolle gehört, dass Konfigurationsänderungen in den Admin-Portalen nicht „still“ passieren. Wo möglich, sollten Änderungen über nachvollziehbare Pipelines (z. B. für Richtlinien als Code) oder mindestens über Change-Tickets mit Impact-Analyse laufen. Für Microsoft 365 empfiehlt sich außerdem ein definierter Prozess zur Bewertung von neuen Features (Message Center, Roadmap) und deren Einfluss auf Governance, Datenhaltung und Supportaufwand.

Monitoring, Audit und Dokumentation: vom Einmal-Review zur Routine

Monitoring im Microsoft-365-Kontext bedeutet mehr als Service Health. Ein belastbarer Betrieb verbindet Metriken (Nutzung, Storage, Aktivität), Security-Signale (Audit, Alerts), und Governance-Events (z. B. neue Teams, externe Freigaben, neue Connectoren). Reviews liefern die Kriterien und Schwellenwerte; der Alltag braucht daraus abgeleitete Dashboards, Verantwortliche und Reaktionspfade. Die Dokumentation sollte dabei nicht als Wissensablage verstanden werden, sondern als verbindlicher Referenzpunkt für Standards, Ausnahmen und die Entscheidungshistorie.

Praktisch bewährt hat sich eine „Minimum Documentation“ pro Workload: Soll-Zielbild, zentrale Policies, Ausnahmeregeln, Standardprozesse (Onboarding/Offboarding, Team-/Site-Lifecycle, Mailflussänderungen), sowie eine Liste der regelmäßig genutzten Reports und Logs inklusive Aufbewahrungsdauer. Ergänzend sollte ein Maßnahmenregister geführt werden, in dem Findings aus Reviews mit Eigentümer, Risiko, Aufwand, Zieltermin und Validierungsnachweis erfasst sind.

• Audit- und Aktivitätsdaten operationalisieren: Microsoft Purview Audit (Standard/Premium je nach Lizenz) mit definierten Abfragen für Ereignisse wie „TeamCreated“, „AddedToGroup“, „FileAccessed“, „SharingInvitation“; Ablage der Suchabfragen als wiederverwendbare Vorlagen
• Service- und Incident-Perspektive: Microsoft 365 admin center → Service health + Message center; Zuordnung von Kategorien zu internen Owners und Change-Fenstern
• Technische Basisreports: SharePoint/OneDrive Storage-Reports, Teams Usage Reports, Exchange Mailflow- und Anti-Spam-Reports; Definition von Schwellenwerten für Reviews (z. B. Top-Storage-Sites, inaktive Teams)
• Dokumentationsartefakte mit Verfallsdatum: Pro Policy/Standard ein „Review by“-Datum und ein Änderungslog; Maßnahmenregister als zentrales Backlog mit Status, Owner und Nachweislink (z. B. Screenshot/Export/Change-Ticket-ID)