Dein Microsoft 365 Tenant ist Cloud-Infrastruktur: Hunderte sicherheitsrelevante Einstellungen über Entra ID, Exchange Online, SharePoint und Teams hinweg, und sie driften genau wie ein unverwalteter AWS-Account. Ein Admin ändert während eines Incidents eine Einstellung und stellt sie nie zurück. Microsoft ändert in einem Service-Update einen Default. Ein Anbieter bekommt Gastzugriff für ein Pilotprojekt, das vor zwei Quartalen endete. Niemand prüft irgendetwas davon, weil der Tenant "ein IT-Thema" ist, kein "Infrastruktur-Thema". Posture Scanning ist der langweilige, wirksame Fix: die tatsächliche Konfiguration des Tenants kontinuierlich mit einer veröffentlichten Security-Baseline vergleichen und die Lücken berichten. Und 2026 ist der praktikable Weg, diesen Scanner zu betreiben, SaaS, was bedeutet: Du prüfst Cloud mit Cloud. Dieser Post ist das 101, mit Aether365 als Beispiel. Volle Transparenz: Aether365 ist mein Produkt.

Ein Grundsatz vorab: Read-only ist der Standard. Nichts erhält Schreibzugriff auf deinen Tenant ohne eine separate, ausdrückliche Zustimmung.

Behandle den Tenant wie einen Produktions-Account

Würde jemand produktives AWS ohne Config-Audit, ohne Drift-Erkennung und ohne Änderungshistorie betreiben, würdest du es Fahrlässigkeit nennen. Die meisten Organisationen betreiben Microsoft 365 genau so, während es ihren Identity Provider, ihre gesamte E-Mail und die meisten ihrer Dateien hält. Der Tenant ist die Identitätsebene für alles andere, das du betreibst; eine Conditional Access Fehlkonfiguration dort ist für einen Angreifer mehr wert als ein öffentlicher S3 Bucket.

Die Infrastruktur-Denkweise überträgt sich direkt. Du willst eine deklarierte Baseline, einen geplanten Abgleich der Realität dagegen und einen Alarm, wenn beide auseinanderlaufen. In der AWS-Welt würdest du zu Config Rules oder Security Hub Standards greifen. Für Microsoft 365 sind die Entsprechungen Posture-Benchmarks.

Die drei Benchmarks, die man kennen sollte

Drei Baselines decken das meiste ab, was zählt, und jeder ernsthafte Scanner mappt auf mindestens eine davon:

  • CIS Microsoft 365 Foundations Benchmark: die breiteste Baseline, 800+ Checks über die gesamte Suite, von MFA-Durchsetzung über Mailbox-Auditing bis zu Sharing-Policies. Die Standardantwort auf die Frage "geprüft wogegen?"
  • EIDSCA (Entra ID Security Configuration Analyzer): komplett auf Entra ID fokussiert, also die Einstellungen, die entscheiden, wer sich authentifizieren, Consent erteilen und Anwendungen registrieren darf. Kleine Oberfläche, größter Wirkungsradius.
  • CISA ScuBA (Secure Cloud Business Applications): die Baseline der US-Bundesregierung für M365. Strenger und meinungsstärker; auch außerhalb von Behörden nützlich als Referenz für die Frage, was ein hartes Ziel tun würde.

Die Benchmarks überlappen sich, und das ist in Ordnung. Überlappung bei Identity-Controls zeigt dir, wo der Konsens liegt, und Konsens-Findings sind die, die du zuerst behebst.

Skripte oder SaaS: der echte Trade-off

Du kannst diese Checks absolut selbst fahren. Die Graph API liegt direkt vor dir, Community-Tooling wie Maester kapselt vieles davon, und ein geplanter PowerShell-Lauf gegen einen Tenant ist ein Wochenendprojekt. Ich mag diesen Ansatz, um zu lernen, was die Checks tatsächlich tun.

Er skaliert auf drei Achsen nicht weiter. Wartung: Benchmarks bekommen neue Versionen, Graph-Endpoints ändern sich, und deine Skriptsammlung wird still und leise zu einem Produkt, das du besitzt. Historie: ein Punkt-in-der-Zeit-Skript sagt dir den heutigen Zustand, aber Posture-Fragen sind Trend-Fragen, wann ist dieses Control zurückgefallen und was hat sich drumherum geändert. Mandanten: sobald du mehr als einen Tenant verwaltest, etwa als MSP mit dreißig Kunden, werden Skripte und Credentials pro Tenant selbst zum Risiko.

Ein SaaS-Scanner dreht den Tausch um: Du erteilst ihm read-only Microsoft Graph Consent, er fährt Compliance- und Exposure-Scans nach Zeitplan, täglich, wöchentlich oder monatlich, und er behält die Historie. Das Consent-Modell ist der Teil, den du genau prüfen musst, denn du verdrahtest einen externen Dienst mit deiner Identitätsebene. Read-only sollte der Default sein, und alles darüber hinaus sollte ein separater, expliziter Consent sein, den du ablehnen kannst. Diese eine Eigenschaft macht Cloud-prüft-Cloud für einen regulierten EU-Tenant akzeptabel.

Was Aether365 abdeckt

Aether365 ist meine Version dieses Scanners. Der Kern ist Compliance-Scanning gegen alle drei Benchmarks oben plus Exposure-Scanning, geplant pro Tenant, mit Multi-Tenant-Verwaltung für MSPs, Teams- und E-Mail-Benachrichtigungen und einer REST API plus eingebautem MCP Server, falls dein AI-Assistent Scan-Ergebnisse abfragen soll. Der Dienst sitzt in der EU und ist DSGVO-konform, du wählst deine Datenregion bei der Registrierung, und Scan-Daten werden nie zum Trainieren irgendeines Modells verwendet.

Zwei Fähigkeiten gehen über die Innensicht des Tenants hinaus. External Attack Surface prüft, was der Tenant nach außen exponiert: SPF-, DKIM- und DMARC-Records, die für M365-Mail tragend sind, Zertifikatsablauf mit 90-Tage-Warnungen, dangling DNS und Subdomain-Takeover-Risiko, offen gelassene Legacy-Authentication-Endpoints und öffentliche SharePoint- und OneDrive-Freigaben. Und AI Pilot, Opt-in und nur in Pro und Enterprise, macht aus Findings konkrete Microsoft Graph Fixes, die du pro Eintrag freigibst, bevor irgendetwas angewendet wird, mit verifiziertem Audit-Trail. Read-only bleibt der Default; der Schreibpfad ist ein separater Microsoft Consent, den du nur aktivierst, wenn du ihn willst. Es gibt einen Free-Tier mit monatlichen Scans auf einem Tenant, was reicht, um deinen ersten CIS-Score zu sehen, und dieser erste Score ist meist der Motivator.

Das Fazit

Das 101 ist simpel: Dein Microsoft 365 Tenant verdient dieselbe Posture-Disziplin wie deine Cloud-Accounts, die Benchmarks zum Messen existieren bereits, und die operative Frage ist nur, ob du den Scanner selbst betreibst oder einem SaaS per Consent erlaubst, das read-only nach Zeitplan zu tun. Skripte lehren dich die Controls; ein Dienst hält dich über die Zeit ehrlich. So oder so, der Failure Mode, den du vermeiden willst, ist der aktuelle Default: dass überhaupt niemand prüft.

Lies das als Nächstes

Für die AI-Seite derselben Plattform, warum Remediation ein Freigabe-Gate braucht und wofür AI-generiertes Reporting tatsächlich da ist, siehe M365 Security 101: AI Pilot und Business Impact Reports auf ercan.ai. Für Consulting zu Cloud, Security Posture und Plattform-Arbeit, oder einfach zum Hallosagen, starte auf ercanermis.com.