Was der Tenant-Check täglich abdeckt
Microsoft 365 ist kein Produkt, sondern ein Ökosystem aus über zwanzig Diensten mit eigenen Admin-Portalen. Entra ID verwaltet Identitäten, Intune die Geräte, Exchange Online die Postfächer, Defender die Bedrohungen, Purview die Compliance. Jeder Dienst hat eigene Konfigurationspunkte, eigene Drift-Quellen und eigene Sicherheits-Implikationen. Wer alle gleichzeitig im Blick behalten will, klickt sich jede Woche durch Hunderte von Settings.
Genau hier setzt der Tenant-Check an. clarios prüft täglich automatisch 280+ konkrete Konfigurationspunkte über alle relevanten Microsoft-365-Dienste hinweg, vergleicht sie mit CIS-Benchmarks und einer hauseigenen, auf deutsche Mittelständler optimierten Baseline, priorisiert die Befunde nach Risiko und liefert für jeden eine konkrete Handlungsempfehlung - inklusive eines Fix-It-Buttons, der die Empfehlung mit einem Klick umsetzt.
Im Folgenden vier reale Szenarien aus dem Alltag deutscher M365-Administratoren, die zeigen, wo der Tenant-Check seinen Wert entfaltet.
Szenario 1 - Conditional Access Drift um 02:14 Uhr
Trigger
Ein Admin deaktiviert versehentlich eine MFA-Richtlinie um 02:14 Uhr nachts.
Der Hintergrund
Conditional Access ist das Rückgrat moderner Microsoft-365-Sicherheit. Ein gutes Setup hat 15 bis 30 Policies, die zusammen ein dichtes Netz aus Bedingungen weben: MFA für privilegierte Accounts, Geo-Blocking, Session-Controls für unmanaged Devices, Risk-basierte Authentifizierung. Diese Policies werden in der Praxis von mehreren Personen gepflegt - IT-Leitung, externe Berater, manchmal auch ein freier Admin, der mal eben am Wochenende ein Ticket abarbeitet.
Genau diese Multi-Editor-Realität ist gefährlich. Eine Policy „MFA für alle Admins” zu deaktivieren dauert drei Klicks. Sie wieder zu aktivieren ebenfalls. Aber zwischen Deaktivierung und Wieder-Aktivierung können Tage liegen - und niemandem fällt es auf, weil das Microsoft-Admin-Portal keine prominente Drift-Anzeige hat. Microsoft Secure Score zeigt zwar einen Punktabzug, aber erst nach mehreren Stunden Verzögerung, und nur als aggregierter Score-Punkt, nicht als sofortiger Alert.
Was clarios konkret macht
Beim nächsten Tages-Scan (in der Regel innerhalb von 24 Stunden) erkennt clarios die Änderung über einen Vergleich der aktuellen Policy-Konfiguration mit der gespeicherten Baseline der Vortags-Konfiguration. Im Dashboard erscheint die Policy als „Drift” mit einer Diff-Ansicht: vorher/nachher, geänderte Felder farblich markiert, Zeitstempel der Änderung, Username des Admins, der die Änderung vorgenommen hat (sofern in den Sign-In-Logs nachvollziehbar). Eine Mail geht an die hinterlegten Verantwortlichen - IT-Leitung und Geschäftsführung, je nach Konfiguration.
Der Fix-It-Knopf direkt im Finding reaktiviert die korrekte Konfiguration mit einem Klick. Die Operation wird im clarios-Audit-Log protokolliert (wer hat zurückgesetzt, wann, mit welchem Begründungstext) und parallel im Microsoft-365-Audit-Log dokumentiert.
Das Ergebnis
Mittlere Reaktionszeit-Fenster wird von „mehrere Tage bis jemand es merkt” auf „spätestens am Folgetag um die übliche Scan-Zeit” reduziert. Bei kritischen Policies (Break-Glass-Accounts, Admin-MFA) liefert clarios zusätzlich Real-Time-Alerts. Versuche, das Drift-Window aktiv für Angriffe auszunutzen, werden so deutlich erschwert.
Szenario 2 - Drei Service-Accounts mit IMAP-Basic-Auth
Trigger
Drei Service-Accounts nutzen noch IMAP-Basic-Auth.
Der Hintergrund
Microsoft hat Basic Authentication für die meisten Exchange-Online-Protokolle schon vor mehreren Jahren deprecated. Trotzdem leben Basic-Auth-Konfigurationen in vielen Tenants weiter: ein altes Multifunktionsgerät, das Mails per IMAP versendet. Ein Buchhaltungsscript, das nachts Reports abruft. Ein historischer Service-Account, der schon vor zehn Jahren angelegt wurde und seither niemand mehr anfasst.
Diese Accounts sind Angriffsziel Nummer eins. Sie haben in der Regel statische Passwörter ohne MFA, oft mit erweiterten Berechtigungen, und sie tauchen nur sporadisch in Sign-In-Logs auf - weil sie automatisiert laufen und niemand auf ihre Aktivität schaut.
Was clarios konkret macht
clarios analysiert alle Sign-In-Logs der letzten 90 Tage und identifiziert alle Anmeldungen, die mit Legacy-Auth-Protokollen erfolgten (IMAP, POP3, SMTP-Auth, ältere ActiveSync-Versionen). Das Ergebnis ist eine konkrete Liste: betroffener Account, letztes Sign-In-Datum, Source-IP, genutztes Protokoll, ggf. Hinweis auf den verbundenen Service (Multifunktionsgerät, Cron-Job, etc.) - sofern aus den Logs ableitbar.
Für jeden Account gibt es eine Migrations-Empfehlung: Wechsel auf Modern Auth mit App-Passwort (für simple SMTP-Sender), Migration auf Graph API mit OAuth-Client-Credentials (für Buchhaltungsscripts), Übergang auf einen Managed Identity-Ansatz (für Azure-basierte Workloads). Wo Microsoft Modern Auth bereits erzwingt und die Verbindung deshalb fehlschlägt, listet clarios das als „blockiertes Konto” und schlägt sofortige Deaktivierung vor.
Das Ergebnis
Statt einer vagen „Legacy Auth aktiv”-Warnung im Secure Score haben Sie eine konkrete To-Do-Liste mit drei bis fünf Einträgen. Jeder Eintrag ist priorisiert und kommt mit einer technischen Empfehlung, die Ihr Admin in 30 Minuten umsetzen kann.
Szenario 3 - Break-Glass-Account ohne MFA
Trigger
Ein Break-Glass-Account hat keine MFA, ist aber privilegiert.
Der Hintergrund
Break-Glass-Accounts sind eine Sicherheits-Best-Practice: hochprivilegierte Notfall-Accounts, die bewusst von der allgemeinen MFA-Pflicht ausgenommen sind, damit sie auch dann funktionieren, wenn die normalen MFA-Mechanismen ausfallen (z.B. Azure MFA Service down). Korrekt umgesetzt bedeutet das: Account ohne MFA, aber stark abgesichert durch FIDO2-Hardware-Token oder eine Trusted-Location-Restriction in Conditional Access, kombiniert mit Sign-In-Alerting an die Geschäftsführung.
Falsch umgesetzt heißt: ein normaler User-Account, der zufällig Global-Administrator-Rechte hat, aus irgendeinem Grund keine MFA-Aufforderung bekommt, und niemandem fällt es auf. Genau diese Konstellation ist das beliebteste Einfallstor für ATO-Angriffe (Account Takeover) im Microsoft-365-Umfeld.
Was clarios konkret macht
clarios identifiziert alle Accounts mit privilegierten Rollen (Global Admin, Privileged Role Administrator, Application Administrator, weitere) und gleicht sie mit den aktivierten Authentifizierungs-Methoden ab. Ergibt sich für einen privilegierten Account, dass weder MFA aktiv ist noch eine sicherheitsstarke Alternative (FIDO2, Certificate-based Auth) hinterlegt ist, wird das als kritisches Finding markiert.
Der Workflow im Cockpit fragt: Ist das ein gewollter Break-Glass-Account? Wenn ja, schlägt clarios eine dokumentierte Konfiguration vor (Conditional Access mit Trusted Location + FIDO2 Token + Sign-In-Alerting an definierte Mail-Empfänger) und protokolliert die bewusste Entscheidung im Audit-Log. Wenn nein, wird MFA-Aktivierung vorgeschlagen und kann per Fix-It-Workflow direkt umgesetzt werden.
Das Ergebnis
Privileged Accounts ohne MFA sind entweder bewusst und dokumentiert konfiguriert oder werden zeitnah abgesichert. Versteckte Risiko-Konstellationen, in denen ein Admin-Account stillschweigend ohne MFA existiert, werden sichtbar und auditierbar.
Szenario 4 - Offene B2B-Gast-Einladungen
Trigger
B2B-Gast-Einladungen sind für alle User möglich.
Der Hintergrund
Microsoft Teams und SharePoint Online erlauben es by Default jedem User, externe Gäste einzuladen. Was als Produktivitäts-Feature gedacht ist, wird in der Praxis schnell zur Schatten-IT: nach drei Jahren hat ein typischer Mittelstands-Tenant mehrere Hundert B2B-Gast-Konten, viele davon inaktiv, einige davon mit erstaunlich weitreichenden Zugriffsrechten auf Teams-Channels und SharePoint-Bibliotheken.
Das Problem ist nicht der Mechanismus selbst, sondern die mangelnde Übersicht. Niemand weiß, wer eingeladen wurde, von wem, mit welchen Berechtigungen, und ob die Einladung überhaupt noch sinnvoll ist. Wenn ein externer Partner aus dem Unternehmen ausscheidet, bleibt sein Gast-Account fast immer aktiv - niemand teilt das proaktiv mit.
Was clarios konkret macht
clarios meldet die offene B2B-Einladungs-Konfiguration als Finding mit konkreter Datenbasis: aktuelle Anzahl der B2B-Gäste, Verteilung nach Mail-Domain (z.B. „142 Gäste, davon 38 @kunde-a.de, 27 @partner-b.com, 19 @gmail.com”), letzte Aktivität pro Gast, ungenutzte Gäste (>90 Tage kein Sign-In).
Der Fix-It-Workflow bietet drei Optionen, die je nach Unternehmens-Realität wählbar sind: Restriktion auf Admins (nur IT lädt externe Gäste ein), Restriktion auf definierte Domains (nur eingetragene Partner-Unternehmen), Beibehaltung mit Approval-Workflow (User können einladen, ein Admin muss bestätigen). Parallel dazu wird ein Bereinigungs-Lauf vorgeschlagen, der inaktive Gäste markiert und nach einer definierten Frist deaktiviert.
Das Ergebnis
Shadow-Collaboration-Risiko sinkt deutlich, ohne dass laufende Projekt-Kollaborationen abrupt unterbrochen werden. Die B2B-Gäste-Liste wird strukturiert und überschaubar. Bei künftigen Audits oder DSGVO-Anfragen können Sie konkret beantworten, welche externen Identitäten welchen Zugriff hatten.