Sicherheits-Settings per Klick: M365 empfiehlt Best Practices

Im Microsoft 365 Admin Center gibt es seit Kurzem ein Feature, das sich anfühlt wie ein „Sicherheits-Tempomat“: empfohlene Sicherheitskonfigurationen, gebündelt als Baseline Security Mode. Die Idee dahinter ist simpel (und endlich mal nicht sadistisch): Statt dass man sich durch fünf Portale, drei PowerShell-Module und ein halbes Dutzend „Wo war das nochmal?“-Momente wühlt, bekommt man eine zentrale Oberfläche, die typische Schwachstellen erkennt, Auswirkungen vorab durchrechnet und anschließend zentrale Schutzmaßnahmen mit wenigen Klicks durchsetzt.

Wie das Tool funktioniert: von „Aha, da brennt’s“ bis „Klick – und dicht“

1) Erkennen: Wo ist der Tenant weich wie Butter?
Im Dashboard siehst du eine Sammlung empfohlener Einstellungen über mehrere Kern-Workloads hinweg (Office, Exchange, Teams, SharePoint/OneDrive, Entra). In der ersten Ausbaustufe sind es 18 Konfigurationen – nicht tausend Kleinigkeiten, sondern bewusst ausgewählte Klassiker, die Angreifer lieben und Security-Teams hassen.
Das Tool zeigt dir für jede Einstellung den Status (aktiv, inaktiv, bereits „secure-by-default“) und macht transparent, wo du noch mit „historisch gewachsen“ unterwegs bist.

2) Simulation/Impact Reports: erst messen, dann schrauben
Der Clou: Für Einstellungen, die erfahrungsgemäß eher „Produktivität trifft Wand“ auslösen können, sollst du Impact Reports bzw. Simulationen nutzen. Das System sammelt dafür Telemetrie und Hinweise auf Abhängigkeiten (welche Apps/Clients/Workflows betroffen wären). So bekommst du vorab ein Gefühl: „Null Impact“ heißt oft: einschalten, fertig. „Meaningful Impact“ heißt: nicht blind drücken, sondern sauber planen (Change, Kommunikation, Ausnahmen, Umstellung).

3) One-Click-Hardening: umsetzen, ohne die halbe Nacht zu opfern
Wenn du dich entschieden hast, kannst du die empfohlenen Maßnahmen zentral aktivieren. Der Ansatz ist bewusst gestaffelt: Viele Einstellungen gelten als „low/no impact“ und lassen sich schnell durchsetzen, während die kniffligeren Kandidaten erst nach Simulation und abgestimmtem Rollout folgen.
Praktisch ist auch: Das Tool bringt Einstellungen in die Oberfläche, die früher teils nur per PowerShell komfortabel erreichbar waren – weniger Skript-Zoo, weniger Tippfehler-Lotterie.

Was wird konkret automatisch umgesetzt?1

Das Paket ist nicht „ein großes Ding“, sondern eine Reihe gezielter Stellschrauben – grob in drei Themenblöcke gegliedert: Authentifizierung, Dateisicherheit und Raumgeräte.

A) Authentifizierung: Angriffsfläche schrumpfen, Konten härten

Hier geht es um die üblichen Einfallstore: Passwort-Spraying, Credential Stuffing, Phishing, Consent-Fallen und alte Protokolle.

• Phishing-resistente MFA für Admin-Zugänge: Privilegierte Konten sind Premium-Beute. Das Feature kann für Admin-Portale eine phishing-resistente mehrstufige Anmeldung erzwingen – ein massiver Hebel gegen Kontoübernahmen.

• Blockieren von Legacy-Authentifizierungsflüssen: Alte Protokolle, die MFA nicht sauber unterstützen, sind ein Lieblingskanal für automatisierte Angriffe (Password Spray, Credential Stuffing). Das Abschalten reduziert die Angriffsfläche spürbar.

• Blockieren von Basic-Auth-Prompts: Diese klassischen Login-Abfragen sind phishbar wie ein Aufkleber am Laternenpfahl. Wenn Basic Auth rausfliegt, sinkt das Risiko, dass Anmeldedaten über unsichere Pfade abgegriffen werden.

• Unsichere Protokolle beim Dateiöffnen blockieren (HTTP/FTP): Wenn Dateien über Klartext-Protokolle geöffnet werden, freut sich jeder Man-in-the-Middle. Das Blocken erzwingt sichere Übertragungspfade.

• FPRPC blockieren: Ein betagtes Protokoll aus der „FrontPage war mal eine Idee“-Ära. Alt, selten nötig, aber als Angriffsfläche nicht totzukriegen.

• SharePoint/OneDrive: Legacy-Browser- und Client-Auth (RPS/IDCRL) unterbinden: Auch hier gilt: weniger alte Auth-Mechanik, weniger Brute-Force- und Phishing-Risiko – plus Reporting, wer es noch nutzt.

• EWS (Exchange Web Services) organisationsweit deaktivieren: EWS kann bei Missbrauch Zugriff auf Maildaten geben und ist für Angreifer interessant. Das Abschalten reduziert Legacy-App-Nutzung – erfordert aber Prüfung wegen Add-ins und Hybrid-Szenarien.

• App-Hygiene: Blockieren neuer Passwort-Credentials in Apps (weg von „App-Passwort in irgendeiner Wiki-Seite“) und Einschränkung des Endbenutzer-Consents auf vertrauenswürdigere App-Klassen. Das hilft gegen Consent-Phishing und Schatten-Integrationen.

• SharePoint-Governance: Neue Custom Scripts verhindern und Zugriff auf den SharePoint Store einschränken – weniger Wildwuchs, weniger „huch, wer hat das denn installiert?“.

Wichtig, weil es häufig missverstanden wird: Dieses Paket macht vor allem Admin- und Basis-Härtung sehr bequem. Für „MFA für alle Benutzer in jeder Lage“ bleibt Conditional Access (mit sauberem Design) weiterhin das Werkzeug der Wahl – das Feature nimmt dir aber die grobe Basisarbeit ab und zieht die schlimmsten Nägel aus dem Reifen.

B) Dateisicherheit: weniger „Office als Exploit-Launcher“

Angriffe kommen gern als Datei daher: alte Formate, ActiveX, DDE, OLE-Objekte – alles schon in realen Kampagnen missbraucht worden.

• Protected View für sehr alte/alte Dateiformate (teilweise ohne Bearbeitung): So kann man Inhalte noch ansehen, aber die gefährlichsten Kanten werden abgeschliffen.

• ActiveX blockieren: ActiveX ist funktional wie ein Schweizer Taschenmesser – nur leider oft in der Hand des Einbrechers. Blocken reduziert eine bekannte Exploit-Fläche.

• OLE Graph/OrgChart blockieren und DDE-Serverstarts in Excel blockieren: Beides zielt auf Techniken, mit denen Codeausführung oder Befehlsstarts „durch die Hintertür“ passieren können, ohne dass Makros nötig sind.

• Microsoft Publisher blockieren: Publisher hat eine große Angriffsfläche und wird perspektivisch aus Microsoft 365 herauslaufen; das frühe Blocken ist Risikoabbau und Zukunftsvorsorge.

Das schützt vor einer ganzen Klasse „Dokument-als-Waffe“-Angriffe: Du nimmst dem Angreifer Werkzeuge weg, die er gern benutzt, weil sie in vielen Umgebungen historisch einfach noch an sind.

C) Teams-Raumgeräte: Konferenzräume sind auch IT (ja, wirklich)

Teams Rooms und Raumgeräte laufen oft unter Resource Accounts, stehen physisch öffentlich herum und haben regelmäßig Sonderregeln. Genau deshalb sind sie sicherheitstechnisch spannend.

• Nur verwaltete, konforme Geräte dürfen sich anmelden

• Resource Accounts werden so eingeschränkt, dass sie nicht als „Universal-Schlüssel“ für Microsoft-365-Apps missbraucht werden

• Zugriff von Resource Accounts auf Microsoft-365-Dateien in Meetings wird begrenzt

Damit minimierst du das Risiko, dass über Raumtechnik oder falsch behandelte Geräteidentitäten Daten abfließen oder Konten zweckentfremdet werden.

Warum das gegen reale Bedrohungen hilft

Wenn man es herunterbricht, ist das Feature ein großer Angriff-auf-die-Angriffsfläche:

• Credential Stuffing / Password Spray werden unattraktiver, wenn Legacy-Auth und Basic Auth nicht mehr als Hintertür taugen.

• Phishing verliert Wirkung, wenn Admin-Zugänge phishing-resistente MFA verlangen und „Basic Prompt“-Tricks wegfallen.

• Man-in-the-Middle wird erschwert, wenn Dateiöffnungen nicht mehr über Klartext-Protokolle erlaubt sind.

• Malware via Office-Dokumente wird deutlich ausgebremst, wenn ActiveX, DDE, riskante OLE-Objekte und unsichere Legacy-Formate nicht mehr frei laufen.

• Schatten-Apps und Consent-Angriffe verlieren Boden, wenn Benutzer-Consent stärker eingeschränkt wird und App-Passwörter als Auth-Methode aus der Mode kommen.

Erleichtert das den Alltag von Security-Teams?

Ja – und zwar nicht nur „ein bisschen“, sondern an den Stellen, die täglich Zeit fressen:

• Zentralität: weniger „wo ist diese Einstellung versteckt?“

• Standardisierung: ein konsistenter Baseline-Stand statt individueller Bastelkonfigurationen

• Tempo: für low-impact Maßnahmen ist es wirklich ein „Klick, erledigt“

• Transparenz: Impact Reports/Telemetrie fördern bessere Entscheidungen als Bauchgefühl

• Weniger Drift: wenn ein Baseline-Set klar definiert ist, fällt „schleichende Abschwächung“ schneller auf

Das ist besonders hilfreich in Umgebungen, in denen Security nicht aus 30 Spezialisten besteht, sondern aus „zwei Leuten und einem sehr tapferen Kaffeeautomaten“.

Warum es trotzdem kein Allheilmittel ist

So verlockend „secure-by-default“ klingt: Das Feature ist eine Baseline, kein magischer Schutzschild.

• Individuelle Anforderungen: Hybrid-Exchange, Spezial-Add-ins, alte Scanner, Branchensoftware, Drittanbieter-Mail-Gateways – all das kann an Legacy-Stellen hängen. Simulation hilft, aber entscheiden und umstellen musst du trotzdem.

• Ausnahmen sind gefährlich, aber manchmal nötig: Ausnahmen sollten sauber begründet, dokumentiert und regelmäßig geprüft werden (sonst werden sie zum Dauerloch).

• Überwachung bleibt Pflicht: Nach dem Hardening ist vor dem Hardening. Du willst weiter Logs, Alarme, Secure Score/Defender-Signale, Admin-Aktivitäten und Anmeldeauffälligkeiten im Blick behalten – sonst merkst du erst beim Vorfall, dass irgendwo doch noch ein Umweg offen ist.

• Erweiterte Kontrollen bleiben wichtig: Conditional Access (für alle Benutzer, risikobasiert), Rollen- und Admin-Härtung (z. B. JIT/PIM), Gerätemanagement, Datenklassifizierung, DLP, Incident Response – das bleibt der Werkzeugkasten für „richtig erwachsen“. Baseline Security Mode ist eher der solide Fundamentguss.

Unterm Strich: Dieses Feature macht es viel leichter, den Tenant auf ein sinnvolles Mindestniveau zu bringen – schnell, nachvollziehbar und mit weniger Handarbeit. Aber wie bei jeder guten Sicherheitsmaßnahme gilt: Autopilot ist super, solange jemand die Hände in Reichweite des Lenkrads lässt.