Warum MFA allein nicht reicht
Multi-Faktor-Authentifizierung ist gut. Aber MFA beantwortet nur eine Frage: „Ist die Person die, die sie vorgibt zu sein?" Sie beantwortet nicht:
- Meldet sie sich von einem sicheren Gerät an?
- Ist das Gerät verschlüsselt und aktuell gepatcht?
- Kommt die Anmeldung aus einem Land, in dem Ihr Unternehmen Mitarbeiter hat?
- Ist es 3 Uhr nachts und der Benutzer normalerweise um 9 im Büro?
- Versucht jemand, auf Daten zuzugreifen, die er für seine Arbeit nicht braucht?
All diese Fragen beantwortet Conditional Access – die mächtigste Security-Funktion in Microsoft 365. Und die am meisten ignorierte.
Was ist Zero Trust?
Zero Trust ist kein Produkt, das Sie kaufen können. Es ist ein Prinzip: Vertraue niemandem, verifiziere alles, gewähre minimale Rechte.
In der klassischen IT-Sicherheit gab es einen Perimeter – die Firewall. Alles innerhalb der Firewall war „sicher", alles außerhalb „unsicher". Dieses Modell ist tot. Ihre Mitarbeiter arbeiten von überall, Ihre Daten liegen in der Cloud, Ihre Geräte verlassen das Firmennetzwerk.
Zero Trust bedeutet: Jeder Zugriff wird geprüft. Jedes Mal. Egal ob der Benutzer im Büro sitzt oder im Café in Bangkok.
Microsoft 365 bietet alle Bausteine für Zero Trust:
- Entra ID als Identitäts-Provider (wer bist du?)
- Conditional Access als Policy Engine (darfst du das, unter diesen Umständen?)
- Intune als Geräte-Compliance (ist dein Gerät vertrauenswürdig?)
- Defender for Endpoint als Risiko-Signal (ist dein Gerät gerade kompromittiert?)
Die 6 Conditional Access Policies die jedes Unternehmen braucht
1. MFA für alle Benutzer, alle Apps
Klingt selbstverständlich, ist es nicht. In vielen Umgebungen ist MFA nur für „wichtige" Benutzer aktiviert. Das ist wie ein Schloss an der Haustür, aber die Hintertür steht offen.
Policy: Alle Benutzer → Alle Cloud Apps → MFA erforderlich.
Ausnahme: Emergency Access Accounts (Break Glass) – aber die müssen dokumentiert und überwacht sein.
2. Geräte-Compliance erforderlich
MFA sagt: „Du bist wer du sagst." Geräte-Compliance sagt: „Und dein Gerät ist sauber." Nur Geräte die in Intune registriert sind, verschlüsselt, aktuell gepatcht und mit aktivem Defender dürfen auf Unternehmensdaten zugreifen.
Policy: Alle Benutzer → Office 365 Apps → Compliant Device OR MFA erforderlich.
3. Blockierung unsicherer Anmeldungen
Entra ID berechnet für jede Anmeldung ein Risiko-Level: Low, Medium, High. Ein „High Risk Sign-In" bedeutet: Anmeldung aus einem Land, in dem noch nie jemand war, mit einem neuen Gerät, über ein VPN das auf einer Blacklist steht.
Policy: High Risk Sign-In → Zugriff blockieren.
Medium Risk Sign-In → MFA + Passwort-Änderung erforderlich.
4. Standort-basierte Einschränkungen
Wenn Ihr Unternehmen nur in Deutschland operiert, gibt es keinen Grund, Anmeldungen aus Nordkorea, Russland oder Brasilien zuzulassen.
Policy: Named Locations definieren (Deutschland + ggf. Reiseländer). Alle Zugriffe außerhalb → Blockieren oder zusätzliche Verifizierung.
5. Legacy Authentication blockieren
Alte Protokolle wie IMAP, POP3 und SMTP Basic Auth unterstützen kein MFA. Angreifer nutzen genau diese Protokolle, um MFA zu umgehen.
Policy: Alle Benutzer → Bedingung: Client Apps = „Other Clients" → Blockieren.
Das ist die Policy mit dem besten Aufwand-Nutzen-Verhältnis. Sie schließt ein Scheunentor, das in den meisten Umgebungen sperrangelweit offen steht.
6. Admin-Konten besonders schützen
Global Admins, Exchange Admins, Security Admins – diese Konten sind die Kronjuwelen. Für sie gelten verschärfte Regeln: MFA immer (auch aus dem Büro), nur von bestimmten Geräten, nur aus bestimmten Netzwerken, Session-Timeout nach 1 Stunde.
Policy: Directory Role = Admin → Compliant Device + MFA + Named Location.
Die 5 häufigsten Fehler bei Conditional Access
- Security Defaults und Conditional Access gleichzeitig. Security Defaults sind die Basis-Sicherheit von Microsoft. Sobald Sie eigene Conditional Access Policies erstellen, müssen Security Defaults deaktiviert werden. Sonst kommen sich die Regeln in die Quere.
- Keine Emergency Access Accounts. Wenn Ihre MFA-Lösung ausfällt (kommt vor) und alle Admins ausgesperrt sind, brauchen Sie einen Notfall-Account: Ohne MFA, mit komplexem 40-stelligem Passwort, im Safe. Wird nur bei Notfällen benutzt und jede Nutzung wird alarmiert.
- Exclude statt Include. Erstellen Sie Policies im „Include"-Modus: Definieren Sie, wer WAS darf. Nicht im „Exclude"-Modus: Alle außer… Denn wenn ein neuer User angelegt wird und nicht in der Exclude-Liste steht, hat er plötzlich keinen Zugriff. Oder schlimmer: Wenn er nicht in der Include-Liste für MFA steht, hat er Zugriff OHNE MFA.
- Policies nicht testen. Conditional Access hat einen „Report-Only" Modus. Nutzen Sie ihn. Jede neue Policy erst 2 Wochen im Report-Only Modus laufen lassen und die Logs prüfen. Erst dann aktivieren.
- Keine Dokumentation. In 6 Monaten weiß niemand mehr, warum Policy Nr. 7 existiert und was sie tut. Jede Policy braucht einen Namen der beschreibt was sie tut: „CA007 – Block Legacy Auth – All Users" statt „Policy 7".
Was passiert wenn Sie Conditional Access nicht konfigurieren?
Dann haben Sie MFA als einzige Verteidigungslinie. Und die wird regelmäßig umgangen:
- Adversary-in-the-Middle Angriffe: Der Angreifer setzt sich zwischen Benutzer und Microsoft. Der Benutzer gibt MFA ein, der Angreifer fängt den Session-Token ab. Conditional Access mit Geräte-Compliance hätte das verhindert.
- Token Theft: Ein Access Token wird vom Gerät gestohlen (z.B. durch Malware) und auf einem anderen Gerät wiederverwendet. Conditional Access mit „Require compliant device" hätte das verhindert.
- Password Spray: Der Angreifer probiert ein häufiges Passwort bei tausenden Accounts. Bei Accounts ohne MFA reicht das. Conditional Access hätte die ungewöhnlichen Anmeldungen blockiert.
Das sind keine theoretischen Szenarien. Das passiert jeden Tag. Die meisten Unternehmen erfahren es nur nie, weil sie die Logs nicht lesen.
Wir prüfen Ihre Microsoft 365 Umgebung auf offene Flanken und geben Ihnen einen konkreten Maßnahmenplan. Kostenlos und unverbindlich.