Exchange Server Security 2025 – Gemeinsame Empfehlungen von NSA, CISA, ACSC und dem kanadischen Cyber Centre

Microsoft Exchange bleibt für viele Organisationen die zentrale Kommunikationsplattform – und ein Dauerziel für Cyberangriffe. Zahlreiche Schwachstellen und Zero-Day-Exploits der letzten Jahre haben gezeigt, wie wichtig eine systematische Härtung von Exchange-Umgebungen ist.

Im Oktober 2025 haben vier führende Sicherheitsbehörden – die National Security Agency (NSA), die Cybersecurity and Infrastructure Security Agency (CISA), das Australian Cyber Security Centre (ACSC) sowie das Canadian Centre for Cyber Security – ihre gemeinsamen Microsoft Exchange Server Security Best Practices veröffentlicht.
Ziel ist es, Administratoren klare Handlungsempfehlungen zu geben, um On-Premises-Exchange-Server nachhaltig abzusichern.

Microsoft Exchange bleibt für viele Organisationen die zentrale Kommunikationsplattform – und ein Dauerziel für Cyberangriffe. Zahlreiche Schwachstellen und Zero-Day-Exploits der letzten Jahre haben gezeigt, wie wichtig eine systematische Härtung von Exchange-Umgebungen ist.

Im Oktober 2025 haben vier führende Sicherheitsbehörden – die National Security Agency (NSA), die Cybersecurity and Infrastructure Security Agency (CISA), das Australian Cyber Security Centre (ACSC) sowie das Canadian Centre for Cyber Security – ihre gemeinsamen Microsoft Exchange Server Security Best Practices veröffentlicht.
Ziel ist es, Administratoren klare Handlungsempfehlungen zu geben, um On-Premises-Exchange-Server nachhaltig abzusichern.

1. Präventionsstrategie als Grundprinzip

Die Leitlinie aller Empfehlungen ist eine konsequente „Prevention-first“-Strategie. Das bedeutet, Angriffe gar nicht erst zu ermöglichen, statt nur auf Vorfälle zu reagieren.
Zentrale Prinzipien dabei sind:

  • Deny-by-default: Nur das erlauben, was unbedingt nötig ist.
  • Least privilege: Benutzer- und Adminrechte auf das Minimum beschränken.
  • Timely updates: Sicherheitsupdates ohne Verzögerung installieren.
  • Attack surface minimization: Nicht benötigte Dienste und Ports deaktivieren oder isolieren.

Diese Maßnahmen senken das Risiko eines erfolgreichen Angriffs erheblich und bilden die Grundlage für jede weitere Absicherung.

2. Sicherheitsupdates und Patchmanagement priorisieren

Die wichtigste Verteidigung gegen Exploits bleibt konsequentes Patchmanagement.
Microsoft veröffentlicht:

  • Zwei Cumulative Updates (CUs) pro Jahr
  • Monatliche Sicherheitsupdates und Hotfixes

Angreifer entwickeln oft innerhalb weniger Tage nach Veröffentlichung eines Patches neue Exploits. Administratoren sollten deshalb:

  • Den Exchange Health Checker regelmäßig ausführen
  • Die Exchange Team Blog Updates abonnieren
  • Updates automatisiert und zeitnah einspielen

Nur Systeme mit aktuellem Patchstand sind wirklich geschützt.

3. End-of-Life-Versionen abschalten

Seit Oktober 2025 ist ausschließlich die Exchange Server Subscription Edition (SE) offiziell unterstützt.
Ältere Versionen wie Exchange 2016 oder Exchange 2019 sind „End of Life“ und stellen ein erhebliches Risiko dar, da sie keine Sicherheitsupdates mehr erhalten.

Empfohlene Maßnahmen:

  • Migration auf Exchange SE oder eine alternative, unterstützte E-Mail-Plattform
  • Alte Server vom Internet trennen und nur intern verwenden
  • Optional: Mail-Gateway als Schutzschicht für eingehenden und ausgehenden Datenverkehr einsetzen

Für Unternehmen gilt: Je schneller die Migration, desto geringer das Risiko.

4. Emergency Mitigation Service aktiv lassen

Der Exchange Emergency Mitigation (EM) Service ist ein automatischer Schutzmechanismus von Microsoft. Er erkennt und blockiert bekannte Angriffsmuster, bevor ein offizielles Update verfügbar ist.

Beispiele für Schutzmaßnahmen sind das Sperren gefährlicher HTTP-Anfragen oder das automatische Deaktivieren kompromittierter Dienste.

Wichtig:
Der EM-Service ersetzt keine regulären Sicherheitsupdates, bietet aber einen wertvollen temporären Schutz und sollte stets aktiviert bleiben.

5. Sicherheitsbaselines konsequent anwenden

Sicherheitsbaselines schaffen Einheitlichkeit in der Konfiguration und erleichtern das Erkennen von Schwachstellen.
Empfohlene Quellen für Baselines:

  • DISA STIG (Security Technical Implementation Guide)
  • CIS Benchmarks
  • Microsoft Security Baselines

Diese Standards sollten sowohl für Exchange Server, Windows Server als auch für Office-/Outlook-Clients umgesetzt werden.
Einheitliche Baselines ermöglichen schnelle Audits und reduzieren die Angriffsfläche.

6. Eingebaute Schutzfunktionen nutzen

Wenn keine Drittanbieter-Tools verwendet werden, sollten alle integrierten Microsoft-Sicherheitsfunktionen aktiviert sein:

  • Microsoft Defender Antivirus (MDAV)
  • Antimalware Scan Interface (AMSI)
  • Attack Surface Reduction (ASR)
  • AppLocker / App Control for Business
  • Endpoint Detection and Response (EDR)
  • Exchange Anti-Spam und Anti-Malware

Ergänzend sollten Organisationen DMARC, SPF und DKIM konfigurieren – entweder manuell über DNS oder mithilfe externer Gateways, da Exchange On-Prem diese Standards nicht nativ unterstützt.

7. Administrative Zugriffe beschränken

Administrationsschnittstellen wie Exchange Admin Center (EAC) und PowerShell sind beliebte Einfallstore.
Empfehlungen:

  • Zugriff nur über dedizierte Administrator-Workstations
  • EAC-Zugriff extern über Client Access Rules sperren
  • Zugriff über Firewall-Regeln auf autorisierte IPs begrenzen

So bleibt der Verwaltungszugang geschützt, auch wenn der Rest des Systems kompromittiert wird.

8. Authentifizierung und Verschlüsselung härten

Transport Layer Security (TLS)

Nutzen Sie immer aktuelle TLS-Versionen für interne und externe Kommunikation.
Konsistente TLS-Konfigurationen verhindern Downgrades und stellen sicher, dass Verbindungen verschlüsselt bleiben.

Extended Protection (EP)

EP schützt vor Relay- und Man-in-the-Middle-Angriffen.
Die Funktion ist ab Exchange 2019 CU14 standardmäßig verfügbar und setzt korrekt konfigurierte TLS- und Kerberos-Einstellungen voraus.

Kerberos statt NTLM

NTLM ist veraltet und wird künftig entfernt.
Empfohlen wird der vollständige Umstieg auf Kerberos, das in Exchange SE (CU1) bereits als Standard gilt.

Modern Authentication und MFA

Ab Exchange 2019 CU13 steht Modern Authentication (OAuth 2.0) mit Unterstützung für Multi-Faktor-Authentifizierung (MFA) über ADFS oder Entra ID zur Verfügung.
Nach der Aktivierung sollte Basic Authentication vollständig deaktiviert werden.

PowerShell absichern

Seit dem Sicherheitsupdate vom November 2023 ist die Zertifikat-basierte Signierung von PowerShell-Serialisierungen standardmäßig aktiv.
Diese Funktion schützt vor Manipulationen und sollte auf allen Exchange-Servern aktiviert bleiben.

9. Weitere empfohlene Schutzmaßnahmen

  • HTTP Strict Transport Security (HSTS): Erzwingt HTTPS-Verbindungen und verhindert Man-in-the-Middle-Angriffe.
  • Download Domains: Trennt Outlook-Web-Sitzungen von Dateidownloads und schützt vor CSRF-Angriffen.
  • RBAC und Split Permissions: Trennen Sie Exchange-Administrationsrechte von Active-Directory-Privilegien, um eine Kompromittierung von Domain- oder Enterprise-Admin-Konten zu verhindern.
  • Tiering: Ordnen Sie Exchange-Server konsequent dem Tier-1-Segment zu. Damit bleibt der Server in einer kontrollierten Verwaltungsschicht und ist getrennt von Tier-0-Komponenten wie Domänencontrollern oder Schema-Administratoren.
    In Kombination mit Split Permissions wird so verhindert, dass Exchange-Administratoren unbeabsichtigt oder böswillig erweiterte Active-Directory-Rechte erlangen.
  • P2 FROM Header Detection: Erkennt und blockiert E-Mail-Spoofing-Angriffe automatisch.

Ein klar definiertes Admin-Tiering-Modell ist entscheidend, um die laterale Bewegung von Angreifern in der Infrastruktur zu verhindern.
Tier-1-Systeme (wie Exchange oder Fileserver) sollten immer durch dedizierte Admin-Konten und separate Workstations verwaltet werden, die keinen Zugriff auf Tier-0-Systeme besitzen.

10. Fazit: Zero Trust als dauerhafte Sicherheitsstrategie

Die beteiligten Behörden betonen: Zero Trust ist keine Option, sondern Pflicht.
Das bedeutet, jedes System – auch interne Server – wird als potenziell kompromittierbar betrachtet.

Durch konsequentes Patchmanagement, Minimierung von Berechtigungen, klare Tiering-Trennung und verschlüsselte Kommunikation lässt sich das Risiko deutlich senken.
Ein sicher konfigurierter Exchange-Server schützt nicht nur E-Mails, sondern die gesamte Kommunikationsinfrastruktur eines Unternehmens.

Die zehn wichtigsten Sofortmaßnahmen

  1. Immer auf neueste Cumulative und Security Updates upgraden
  2. Exchange 2016/2019 außer Betrieb nehmen
  3. Emergency Mitigation Service aktiv halten
  4. Security Baselines anwenden
  5. Defender, AMSI, ASR und EDR aktivieren
  6. TLS und Extended Protection korrekt konfigurieren
  7. Kerberos statt NTLM verwenden
  8. Modern Authentication und MFA erzwingen
  9. RBAC, Tiering und Split Permissions nutzen
  10. Zero Trust als Sicherheitsgrundlage umsetzen

Quelle:
Gemeinsames Dokument von NSA, CISA, Australian Cyber Security Centre (ACSC) und Canadian Centre for Cyber Security:
„Microsoft Exchange Server Security Best Practices“, Oktober 2025

https://www.nsa.gov/Portals/75/documents/resources/cybersecurity-professionals/CSI_Microsoft_Exchange_Server_Security_Best_Practices.pdf

CoPhish: Neue Angriffsmethode über Microsoft Copilot Studio zeigt, warum wir echte Zero-Trust-Architekturen brauchen

n den letzten Wochen wurde eine neue, besonders raffinierte Phishing-Technik bekannt, die zeigt, wie Angreifer selbst modernste KI-Tools und Cloud-Plattformen für ihre Zwecke missbrauchen können. Sicherheitsforscher von Datadog entdeckten eine Kampagne namens „CoPhish“, die Microsofts Copilot Studio-Agenten nutzt, um OAuth-Tokens zu stehlen – also digitale Schlüssel, mit denen sich Nutzer gegenüber Cloud-Diensten authentifizieren.

Der Fall ist nicht nur ein Beispiel für geschicktes Social Engineering, sondern auch ein Weckruf: Sicherheit durch Vertrauen reicht nicht mehr. Nur eine konsequent umgesetzte Zero-Trust-Architektur kann solchen Angriffen standhalten.

Wie funktioniert der CoPhish-Angriff?

Der Angriff nutzt aus, dass in Microsoft Copilot Studio Agenten (Chatbots) erstellt werden können, die über eine öffentliche, legitime Microsoft-Domain erreichbar sind.
Ein Angreifer erstellt dabei einen „bösartigen“ Copilot-Agenten, der scheinbar harmlose Aufgaben erfüllt – etwa das Abrufen von Informationen oder die Anmeldung bei einem Cloud-Service.

Im Hintergrund ist der Agent aber mit einer bösartigen Multi-Tenant-App verknüpft.
Wenn ein ahnungsloser Nutzer auf den Link klickt, öffnet sich ein bekannter Microsoft-Login-Dialog und der Nutzer wird gebeten, einer App Zugriff zu gewähren.
Die URL, das Layout und die Domain wirken absolut vertrauenswürdig – denn sie stammen von Microsoft selbst.

Doch hinter dieser Fassade steckt ein Phishing-Flow, der nach dem Login das OAuth-Token des Benutzers an den Angreifer überträgt. Dieses Token erlaubt dem Angreifer, sich als der Benutzer auszugeben – ohne Passwort, MFA oder sichtbare Anomalien.

Das Perfide: Es handelt sich nicht um einen klassischen Phishing-Link oder eine gefälschte Domain, sondern um Missbrauch einer legitimen Plattformfunktion.

Warum klassische Schutzmaßnahmen hier versagen

Traditionelle Sicherheitsansätze verlassen sich auf Vertrauen in bekannte Marken, Zertifikate und Domains.
Doch genau dieses Vertrauen wird hier ausgenutzt.

Selbst Firewalls, Secure Web Gateways oder MFA können nur eingeschränkt helfen, wenn der Nutzer bewusst (aber ahnungslos) einer legitimen App Berechtigungen erteilt.
Der Angriffsvektor liegt nicht in einem Exploit, sondern in einem Missbrauch der Zustimmungskette – etwas, das sich technisch kaum verhindern lässt, solange jeder Benutzer eigenständig Apps autorisieren darf.

Zero Trust als Antwort: Vertrauen ist keine Sicherheitsstrategie

Hier zeigt sich der wahre Wert von Zero Trust.
Zero Trust bedeutet nicht „Misstrauen gegenüber allem“, sondern: Jede Anfrage muss kontinuierlich geprüft, kontextualisiert und autorisiert werden – unabhängig von Quelle oder Identität.

Ein echter Zero-Trust-Ansatz hätte mehrere Verteidigungsschichten gegen CoPhish geboten:

  1. Strikte Kontrolle über App-Zustimmungen:
    Nur bestimmte Benutzergruppen dürfen OAuth-Zustimmungen erteilen oder neue Anwendungen registrieren.
  2. Identitätsbasierte Segmentierung:
    Selbst wenn ein Token kompromittiert wird, sind dessen Berechtigungen auf das Minimum reduziert (Least Privilege).
    Der Zugriff auf sensible Systeme wäre damit ausgeschlossen.
  3. Adaptive Authentifizierung und Kontextprüfung:
    Wird ein Token von einem unbekannten Agenten oder ungewöhnlichem Ort verwendet, schlägt eine automatische Re-Authentifizierung oder Policy-Blockade an.
  4. Monitoring & Alerting in Echtzeit:
    Zero-Trust-Architekturen setzen auf Telemetrie – ungewöhnliche OAuth-Zustimmungen oder App-Registrierungen werden erkannt und gemeldet.
  5. Klar definierte Vertrauenszonen:
    Nur Anwendungen und Agenten, die durch Governance-Prozesse geprüft und zertifiziert sind, dürfen Zugriff auf Unternehmensdaten haben.

Schutzmaßnahmen in der Praxis

Wer Microsoft- oder andere Cloud-Dienste betreibt, sollte folgende Punkte prüfen:

  • App-Consent Policies aktivieren: Nur Administratoren dürfen neuen Apps Berechtigungen erteilen.
  • Überwachung von App-Registrierungen: Regelmäßig prüfen, welche Anwendungen Zugriff auf Entra ID (ehemals Azure AD) haben.
  • Rollen und Berechtigungen reduzieren: Least-Privilege konsequent umsetzen.
  • Schulungen und Awareness-Programme: Nutzer sollten OAuth-Zustimmungsdialoge kritisch prüfen.
  • Zero-Trust-Governance etablieren: Kein System, keine Identität und kein Agent sollte per se als vertrauenswürdig gelten.

Fazit

Der CoPhish-Angriff zeigt eindrucksvoll, wie Angreifer legitime Plattformen als trojanische Pferde nutzen.
Die Lösung liegt nicht in noch mehr Firewalls oder Filtern, sondern in einem Paradigmenwechsel: Vertrauen muss ersetzt werden durch überprüfbare Sicherheit.

Zero Trust ist kein Buzzword mehr, sondern eine Notwendigkeit.
In einer Welt, in der sogar Microsoft-Domains zum Einfallstor werden können, gilt:

„Never trust, always verify.“

Kontrolle vs. Komfort: Passwort-Synchronisation in Microsoft Edge auf nicht verwalteten Geräten sicher gestalten

In vielen Unternehmen gehört Microsoft Edge mittlerweile zum festen Bestandteil der modernen Arbeitsplatzumgebung. Der Browser bietet zahlreiche Komfortfunktionen – von der nahtlosen Anmeldung mit dem Entra ID-Konto (ehemals Azure AD) bis hin zur Synchronisation von Passwörtern, Favoriten und Einstellungen über verschiedene Geräte hinweg.

Doch genau dieser Komfort kann schnell zum Risiko werden. Denn was für den privaten Nutzer bequem ist, stellt im Unternehmenskontext eine potenzielle Sicherheitslücke dar – insbesondere, wenn Mitarbeitende sich mit ihrem Arbeitskonto auf nicht verwalteten Geräten anmelden.

Warum Passwort-Synchronisation zum Risiko werden kann

Die Passwort-Synchronisation in Edge sorgt dafür, dass gespeicherte Anmeldeinformationen verschlüsselt in der Cloud abgelegt und auf allen Geräten eines Nutzers verfügbar sind. Das ist im privaten Umfeld praktisch – im Unternehmenskontext jedoch heikel.

Meldet sich ein Mitarbeitender mit seinem Arbeitskonto auf einem privaten Laptop an, kann die Synchronisation dazu führen, dass sensible Zugangsdaten auf einem Gerät landen, welches weder durch das Unternehmen verwaltet noch gehärtet ist. Selbst wenn dort lokale Sicherheitsmaßnahmen aktiv sind, bleibt unklar, ob das Gerät den Compliance-Anforderungen entspricht oder Malware-frei ist.

Hinzu kommt: Wird der integrierte Passwort-Manager des Browsers genutzt, bleiben die Daten auch lokal abrufbar – selbst wenn das Unternehmen zentral Richtlinien zur Deaktivierung oder Löschung setzt.

Meine persönliche Empfehlung aus der Praxis:
In meinen Projekten sensibilisiere ich Kunden regelmäßig dafür, dass der Browser nach wie vor das Hacker-Tool Nummer 1 ist – und somit eines der größten Einfallstore in moderne IT-Umgebungen darstellt. Daher sollte der Browser genauso konsequent gehärtet werden wie Betriebssystem, Endpoint-Schutz oder Identitätsmanagement.

Besonders kritisch sehe ich die Nutzung der integrierten Passwort-Manager in Browsern. Sie widersprechen in vielen Fällen den gängigen Sicherheitsvorgaben führender Institutionen:

  • Das Bundesamt für Sicherheit in der Informationstechnik (BSI) empfiehlt in seinen IT-Grundschutz-Bausteinen (z. B. APP.4.4 Webbrowser und SYS.1.6 Clients) ausdrücklich, Komfortfunktionen wie automatische Passwortspeicherung oder Formularausfüllung zu deaktivieren.
  • Auch die CIS Benchmarks (Center for Internet Security) für Microsoft Edge und Google Chrome listen das Deaktivieren des Passwort-Managers als empfohlene Sicherheitsmaßnahme (Level 1 Control).
  • Entsprechende Anforderungen finden sich ebenso in der ISO 27001/27002 unter dem Themenkomplex „Access Control“ (A.9) und in den Microsoft Security Baselines für Edge, die ebenfalls eine restriktive Browserkonfiguration vorsehen.

Aus diesen Gründen empfehle ich grundsätzlich, die integrierten Passwort-Manager über geeignete Hardening-Maßnahmen – etwa per Gruppenrichtlinien, MDM-Profilen oder Edge Management Policies – vollständig zu deaktivieren.

So lässt sich sicherstellen, dass Browser keine Passwörter speichern oder synchronisieren dürfen, und das Risiko wird erheblich reduziert, dass Unternehmenszugangsdaten außerhalb der kontrollierten und geschützten Umgebung abgelegt werden.

Steuerungsmechanismen: So lässt sich Passwort-Sync sicher einschränken

Um den Spagat zwischen Sicherheit und Benutzerfreundlichkeit zu schaffen, stehen zwei zentrale Werkzeuge zur Verfügung:

1. Conditional Access in Microsoft Entra ID

Mit Conditional Access lässt sich präzise steuern, unter welchen Bedingungen ein Nutzer Daten synchronisieren oder sich überhaupt anmelden darf.
Beispielsweise kann eine Richtlinie definiert werden, die das „Edge Sync“-App-Objekt in Entra ID einbindet und die Synchronisation nur dann erlaubt, wenn das Gerät compliant oder hybrid Azure AD-joined ist.

Das bedeutet:

  • Unternehmens-Konten können sich nur dann mit Edge synchronisieren, wenn das Gerät verwaltet wird.
  • BYOD-Geräte (Bring Your Own Device), die nicht compliant sind, werden automatisch ausgeschlossen.

Das sorgt für eine klare Trennung zwischen verwalteter Unternehmensumgebung und privater Nutzung.

2. Microsoft Edge Management Service

Das Edge Management Service ist eine relativ neue Möglichkeit, Browser-Richtlinien cloudbasiert zu verteilen – auch auf nicht verwalteten Windows-Geräten.
Damit lassen sich beispielsweise folgende Richtlinien umsetzen:

  • Deaktivieren des Passwort-Managers
  • Einschränken oder Zulassen bestimmter Erweiterungen
  • Blockieren der Synchronisation für bestimmte Kontotypen

Gerade für Unternehmen, die BYOD zulassen oder flexible Arbeitsumgebungen fördern, ist das ein sehr wirksamer Ansatz.
Einziger Nachteil: Die Unterstützung für macOS und mobile Plattformen ist aktuell noch eingeschränkt.

Kombination bringt den größten Effekt

In der Praxis hat sich gezeigt, dass keine dieser Maßnahmen allein ausreicht. Erst die Kombination aus Conditional Access und Edge Management Policies bietet den notwendigen Schutz:

  • Conditional Access stellt sicher, dass nur compliant Geräte Zugriff haben.
  • Edge-Richtlinien verhindern, dass selbst auf zulässigen Geräten unnötige Risiken durch Passwort- oder Sync-Funktionen entstehen.

Dieses zweistufige Modell schafft eine klare Sicherheitsarchitektur, ohne den Anwender unnötig einzuschränken.

Mein Fazit aus der Beratungspraxis

Die Balance zwischen Kontrolle und Komfort ist kein theoretisches Problem – sie entscheidet im Alltag, ob ein Unternehmen wirklich sicher arbeitet.
Die Passwort-Synchronisation in Microsoft Edge ist eine wertvolle Funktion, aber sie gehört nicht unkontrolliert in Unternehmensumgebungen.

Ich empfehle daher:

  1. Edge-Passwort-Manager konsequent deaktivieren (Hardening).
  2. Conditional Access-Richtlinien einrichten, um den Zugriff auf den Sync-Dienst nur für verwaltete Geräte zuzulassen.
  3. Edge Management Policies einsetzen, um Richtlinien auch auf BYOD-Geräten durchzusetzen.
  4. Mitarbeitende aktiv sensibilisieren, warum Passwort-Manager im Browser ein Sicherheitsrisiko darstellen können.

Adopting a Zero Trust Architecture – Nutzen, Risiken und die Rolle von Data Tiering

In der heutigen Bedrohungslandschaft kann sich keine Organisation mehr leisten, auf Vertrauen zu bauen. Der Ansatz der „Zero Trust Architecture“ (ZTA) ist längst kein Trendthema mehr, sondern eine strategische Notwendigkeit. Zero Trust basiert auf dem Grundsatz „Vertraue niemandem, überprüfe alles“ und ersetzt das veraltete Sicherheitsmodell, bei dem interne Akteure automatisch als vertrauenswürdig galten.

Dieser Artikel beleuchtet, warum der Zero-Trust-Ansatz so entscheidend ist, welche Vorteile und Risiken damit verbunden sind und welche zentrale Rolle die Datenklassifizierung – auch bekannt als Data Tiering – bei der erfolgreichen Umsetzung spielt.

Was ist Zero Trust?

Zero Trust ist kein Produkt, sondern ein umfassendes Sicherheitskonzept. Im Kern geht es darum, jedem Zugriff – egal ob von innen oder außen – grundsätzlich zu misstrauen. Jeder Nutzer, jedes Gerät und jede Verbindung wird kontinuierlich überprüft.

Wichtige Prinzipien sind:

  • Assume Breach: Es wird davon ausgegangen, dass ein Angriff bereits stattgefunden hat – dadurch wird jedes System grundsätzlich hinterfragt.
  • Least Privilege: Nutzer und Anwendungen erhalten nur die minimal notwendigen Berechtigungen.
  • Kontinuierliche Verifikation: Zugriffe werden nicht einmalig, sondern dauerhaft überprüft – abhängig von Kontext, Gerät, Standort und Verhalten.
  • Mikrosegmentierung: Netzwerke und Systeme werden in kleine Sicherheitszonen unterteilt, um Angriffe einzudämmen.
  • Transparenz und Überwachung: Sämtliche Aktivitäten werden protokolliert, analysiert und auf Anomalien geprüft.

Zero Trust bricht damit das alte Modell der „sicheren Perimeter“ auf – in einer Zeit, in der Daten, Geräte und Mitarbeiter zunehmend dezentral agieren, ist das unverzichtbar.

Vorteile einer Zero Trust Architektur

Die Einführung von Zero Trust bringt zahlreiche Vorteile – sowohl in technischer als auch in organisatorischer Hinsicht:

  • Erhöhte Sicherheit: Durch kontinuierliche Überprüfung und restriktive Zugriffsrechte sinkt das Risiko erfolgreicher Angriffe erheblich.
  • Bessere Sichtbarkeit: IT-Teams erhalten volle Transparenz darüber, wer wann auf welche Ressourcen zugreift. Das erleichtert die Früherkennung von Bedrohungen.
  • Reduziertes Insider-Risiko: Selbst interne Benutzer müssen sich regelmäßig authentifizieren. Dadurch werden kompromittierte Konten weniger gefährlich.
  • Compliance und Datenschutz: Der Schutz sensibler Daten wird gezielter gesteuert – wichtig für regulatorische Anforderungen und Vertrauen bei Kunden.
  • Flexibilität für moderne Arbeitsformen: Ob Remote Work, Cloud oder BYOD – Zero Trust erlaubt sicheren Zugriff unabhängig vom Standort.

Kurz gesagt: Zero Trust stärkt die Sicherheit, erhöht die Kontrolle und ermöglicht gleichzeitig moderne, agile Arbeitsweisen.

Risiken und Herausforderungen

Die Umsetzung einer Zero Trust Architektur ist anspruchsvoll und bringt eigene Herausforderungen mit sich:

  • Hohe Komplexität: Bestehende Systeme, Rollen und Zugriffsmodelle müssen neu bewertet und oft umgestaltet werden.
  • Benutzerakzeptanz: Häufige Authentifizierungen oder Sicherheitsprüfungen können Mitarbeitende frustrieren, wenn sie schlecht umgesetzt sind.
  • Ressourcenbedarf: Die Einführung erfordert neue Tools, Fachwissen und Zeit – insbesondere für kontinuierliches Monitoring und Regelpflege.
  • Fehlalarme: Zu strenge Richtlinien können legitime Aktionen blockieren und Geschäftsprozesse stören.
  • Kulturelle Umstellung: Zero Trust ist kein „Tool“, sondern ein Mindset – Unternehmen müssen lernen, Sicherheit als fortlaufenden Prozess zu verstehen.

Diese Hürden lassen sich durch klare Kommunikation, iterative Umsetzung und gezieltes Change Management deutlich reduzieren.

Häufige Missverständnisse

Bei der Einführung von Zero Trust begegnet man oft falschen Annahmen:

  • „Zero Trust ist ein Produkt.“ Falsch – es ist eine Strategie, die mehrere Technologien integriert.
  • „Es geht nur um Identität.“ Nicht nur – Geräte, Netzwerke und Daten spielen eine ebenso wichtige Rolle.
  • „Zero Trust ist zu kompliziert.“ Mit einem schrittweisen Ansatz kann es schmerzfrei und effektiv eingeführt werden.
  • „Das bedeutet, wir vertrauen unseren Mitarbeitern nicht.“ Nein – das Vertrauen gilt Personen, nicht Systemzugriffen. Sicherheit soll schützen, nicht misstrauen.
  • „Zero Trust löst alle Sicherheitsprobleme.“ Es ist ein mächtiger Ansatz, aber kein Allheilmittel. Schulung, Monitoring und Incident Response bleiben unverzichtbar.

Die Rolle von Data Tiering

Ein entscheidender Erfolgsfaktor für Zero Trust ist das Verständnis der eigenen Daten. Genau hier setzt Data Tiering – also die Klassifizierung von Informationen – an.

Datenklassifizierung teilt Informationen nach Sensitivität und Wert in Kategorien ein, beispielsweise „Öffentlich“, „Intern“, „Vertraulich“ oder „Streng vertraulich“.

Das ermöglicht:

  • Gezielten Schutz: Besonders sensible Daten erhalten stärkere Sicherheitsmaßnahmen.
  • Präzise Zugriffskontrolle: Nur berechtigte Personen können auf bestimmte Daten zugreifen – abhängig von Klassifikation und Kontext.
  • Vermeidung von Datenlecks: Automatische Schutzmechanismen können verhindern, dass vertrauliche Daten versehentlich geteilt werden.
  • Effizientere Governance: Unternehmen wissen, wo ihre kritischen Daten liegen, wie lange sie aufbewahrt werden und wer sie nutzt.

Ohne klare Datenklassifizierung bleibt Zero Trust unvollständig – denn man kann nur schützen, was man kennt.

Bedeutung für Cloud- und KI-Strategien

Data Tiering ist nicht nur ein Sicherheitsinstrument, sondern auch eine Grundlage für Innovation:

  • Cloud-Migration: Klassifizierung hilft zu entscheiden, welche Daten sicher in die Cloud verschoben werden können und welche besondere Schutzanforderungen haben.
  • Compliance in der Cloud: Daten lassen sich gezielt in bestimmten Regionen oder mit bestimmten Verschlüsselungsniveaus speichern.
  • Kosteneffizienz: Weniger sensible oder selten genutzte Daten können in günstigere Speicherklassen ausgelagert werden.
  • KI und maschinelles Lernen: Nur geeignete, nicht vertrauliche Datensätze werden für das Training genutzt – was Datenschutz und Qualität verbessert.

So entsteht eine Balance zwischen Innovation und Sicherheit.

Fazit

Zero Trust ist kein Modewort, sondern ein langfristiger Paradigmenwechsel in der IT-Sicherheit. Der Ansatz stärkt Organisationen gegen moderne Bedrohungen und schafft gleichzeitig die Basis für sichere digitale Transformation.

Doch Zero Trust funktioniert nur, wenn Unternehmen ihre Daten kennen und verstehen. Data Tiering liefert diese Grundlage – es verbindet Sicherheit, Compliance und Effizienz.

Wer Zero Trust mit konsequenter Datenklassifizierung kombiniert, schafft nicht nur Schutz, sondern auch Vertrauen und Agilität. Es ist der Weg zu einer sicheren, modernen und zukunftsfähigen IT-Architektur.

Versteckte bösartige OAuth-Apps in Microsoft 365 entdecken – mit dem Tool Cazadora

Die Nutzung von Cloud- und Identitätsdiensten wie Microsoft 365 nimmt ständig zu – damit steigt auch das Risiko neuer Angriffswege. Ein besonders heimtückischer Ansatz: Angreifer nutzen OAuth-Apps, die in Azure/Entra ID registriert wurden, um Zugriffe auf Daten zu erlangen – oft ohne dass es die Administratoren oder Nutzer merken. In einem aktuellen Blogbeitrag erklärt Huntress Labs, wie solche Apps funktionieren, wie häufig sie auftreten – und stellt mit Cazadora ein Open-Source-Skript vor, mit dem sich verdächtige Anwendungen aufspüren lassen. BleepingComputer
Als IT-Consultant lohnt es sich, dieses Thema im Blick zu behalten, denn selbst gut verwaltete Microsoft-365-Tenants sind nicht immun.

Was sind OAuth Apps in Azure/Entra ID – und warum sind sie relevant?

In der Welt von Azure AD / Entra ID und Microsoft 365 gibt es zwei zentrale Kategorien von Apps:

  • Application Registrations: Anwendungen, die innerhalb des eigenen Tenants entwickelt oder registriert wurden. BleepingComputer+1
  • Enterprise Applications: Instanzen von Anwendungen, die von anderen Tenants registriert wurden, aber in Ihrer Tenant-Umgebung verwendet werden. BleepingComputer

Der typische Ablauf sieht so aus: Ein Benutzer oder Administrator erlaubt einer App, sich mit ihrem Konto (Authentifizierung) zu verbinden und über OAuth entsprechende Rechte (Autorisierung) zu erteilen. Sobald das geschehen ist, wird in Ihrem Tenant ein Service-Principal für diese App angelegt, über den die App im Namen der Nutzer agieren kann. BleepingComputer

Warum ergeben sich daraus Risiken?

  • Die Funktionalität ist legitim und zentraler Bestandteil moderner Cloudanwendungen – das macht sie attraktiv für Angreifer, da sie wenig auffällig ist. BleepingComputer+1
  • Manche Einstellungen erlauben es, dass jeder Nutzer ohne Überprüfung Apps registrieren bzw. ihnen Rechte geben kann – je nach Tenant-Konfiguration. BleepingComputer
  • Eine bösartige oder kompromittierte App kann somit Zugriff auf sensible Daten erlangen, ohne dass klassische Malware- oder Endpoint-Kontrollen sie zwingend aufdecken.

Angriffstypen: „Traitorware“ und „Stealthware“

Huntress unterscheidet zwei relevante Kategorien von missbräuchlichen OAuth-Apps:

Traitorware

Hierbei handelt es sich um eigentlich legitime Apps oder weit verbreitete Tools, die allerdings von Angreifern für bösartige Zwecke genutzt werden. Die App selbst ist nicht zwangsläufig bösartig designt, aber ihre Nutzung erscheint ungewöhnlich und riskant.

  • Huntress fand z. B., dass ca. 10 % der ausgewerteten Tenants mindestens eine solche App installiert hatten. BleepingComputer
  • Merkmale: bekannte App-Namen, aber oft ungewöhnliche Berechtigungen oder eine ungewöhnliche Nutzerzuordnung.

Stealthware

Diese Kategorie umfasst echt bösartige oder speziell für Angriffe erstellte OAuth-Apps – klein, maßgeschneidert, selten und damit schwer zu entdecken.

  • Sie haben oft sehr geringe Verbreitung (z. B. < 1 % aller Tenants) und hohe Delegated-Berechtigungen auf einzelne Nutzer. BleepingComputer
  • Da die Namen willkürlich oder unerkennbar sind („…………“, „Test App“, Domain-Name etc.), entziehen sie sich oft automatisierten Erkennungsmechanismen.

Warum sollte man auditieren?

Die Daten zeigen: Selbst bei Organisationen mit etabliertem Sicherheits­rahmen tauchen solche Apps auf – teilweise seit Jahren unentdeckt. BleepingComputer
Ein (zu) beruhigender Befund: Wenn eine App nicht automatisch gefunden wird, heißt das noch nicht, dass keine bösartige App vorhanden ist. Vigilanz bleibt erforderlich.

Vorstellung von Cazadora

Um Administratoren und Sicherheitsverantwortlichen zu helfen, hat Huntress das Werkzeug Cazadora veröffentlicht. BleepingComputer

Was macht Cazadora?

  • Es handelt sich um ein Open-Source-Skript, das über die Microsoft Graph API Daten über alle Application Registrations und Enterprise Applications im Tenant abruft. BleepingComputer
  • Es führt eine automatisierte Analyse durch und markiert Applikationen mit auffälligen Merkmalen (z. B. ungewöhnlicher Name, seltene Verbreitung, starke Berechtigungen, Loopback-Reply-URL etc.). BleepingComputer
  • Ziel ist nicht, alle bösen Apps sicher aufzuspüren, sondern einen schnellen Überblick zu geben und potenzielle „Rauchzeichen“ sichtbar zu machen.

Wichtige Hinweise

  • Kein Tool ersetzt eine vollständige manuelle Prüfung oder eine laufende Sicherheitsüberwachung – Cazadora ist ein Sprungbrett, keine Garantie. BleepingComputer
  • Ergebnisse sollten von einem Administrator oder Sicherheitsanalysten bewertet werden.
  • Anpassungen im Tenant (z. B. Benutzerrechte bei App-Registrierung) können helfen, den Angriffs­raum zu reduzieren.

Achtung: Neue Phishing-Welle nutzt Azure Blob Storage – so schützen Sie Ihr Microsoft 365 mit Passwordless Authentication

Cyberkriminelle sind heute kreativer denn je – und sie nutzen sogar Microsoft-Dienste selbst, um Nutzer zu täuschen.
Ein aktueller Fall zeigt, wie Angreifer über Azure Blob Storage glaubwürdige Microsoft-Login-Seiten fälschen, um Zugangsdaten zu stehlen.

Doch wer Passwordless Authentication einsetzt, schließt genau diese Lücke – und eliminiert Passwörter als Einfallstor.

Phishing über Azure Blob Storage – so funktioniert der Angriff

Die aktuelle Angriffswelle nutzt legitime Microsoft-Domains wie *.blob.core.windows.net.
Betroffene erhalten Links, die auf den ersten Blick harmlos wirken, z. B.:

forms.office.com/<zufälliger-wert>

Nach dem Klick wird man auf eine Seite weitergeleitet, die wie eine echte Microsoft-Login-Seite aussieht – aber in Wahrheit gefälscht ist.
Die Domain endet oft auf:

https://<zufälliger-name>.blob.core.windows.net/<datei>.pdf

Sobald man sich dort mit seinem Microsoft-365-Konto anmeldet, werden Passwort und Authentifizierungstoken abgefangen.
Damit erhalten Angreifer Zugriff auf den gesamten Microsoft-365-Mandanten des Unternehmens.

Besonders perfide:
Da die Domain windows.net zu Microsoft gehört, halten viele Benutzer sie für sicher.

Warum herkömmliche Schutzmaßnahmen nicht ausreichen

Auch wenn Unternehmen heute Firewalls, MFA, Webfilter und Awareness-Trainings einsetzen – Phishing bleibt ein Problem.
Denn Angreifer täuschen vertraute Umgebungen perfekt nach.

Selbst Multi-Faktor-Authentifizierung (MFA) hilft nur bedingt:
Bei Token-Phishing oder Session Hijacking kann sie umgangen werden.

Das Kernproblem bleibt: Passwörter sind phishbar.

Passwordless Authentication – Sicherheit durch den Wegfall des Passworts

Mit Passwordless Authentication löst Microsoft das Problem elegant:
Anstelle eines Passworts nutzt der Benutzer starke kryptografische Schlüssel, die an sein Gerät oder seinen Authenticator gebunden sind.

Beispiele für Passwordless-Login-Methoden

  • Windows Hello for Business – Anmeldung per PIN oder Gesichtserkennung
  • Microsoft Authenticator – Anmeldung durch Push-Bestätigung
  • FIDO2-Sicherheits-Keys – z. B. YubiKey oder Feitian-Key

Damit entfällt die Notwendigkeit, ein Passwort einzugeben – und somit das Risiko, dass es abgefangen wird.

So funktioniert Passwordless technisch

Passwordless basiert auf einem sicheren Public/Private-Key-Verfahren:

  1. Der Private Key bleibt sicher auf dem Gerät oder Token des Benutzers.
  2. Der Public Key wird bei Microsoft Entra ID (ehemals Azure AD) gespeichert.
  3. Beim Login signiert das Gerät eine Challenge – ohne dass ein Passwort übertragen wird.

👉 Selbst eine täuschend echte Phishing-Seite kann diese Anmeldung nicht nachahmen,
weil der Private Key das Gerät niemals verlässt.

Vorteile von Passwordless Authentication

VorteilBeschreibung
🛡️ Phishing-resistentKeine Passwörter = kein Angriffsziel
🚀 Schneller LoginKein Eintippen, kein „Passwort vergessen“
💼 Weniger SupportaufwandReduziert Helpdesk-Tickets
🔑 Stärkere SicherheitBasierend auf Kryptografie, nicht Wissen
🔗 Microsoft 365 integriertUnterstützt in Entra ID, Windows & Azure

Fazit: Phishing verhindern, bevor es passiert

Der Phishing-Angriff über Azure Blob Storage verdeutlicht, dass Angreifer heute legitime Dienste nutzen, um Vertrauen zu missbrauchen.

Mit Passwordless Authentication nehmen wir ihnen das wichtigste Werkzeug –
das Passwort – einfach weg.

💬 „You can’t phish what doesn’t exist.“
– Microsoft Security Engineering Team

Passwordless ist keine Zukunftstechnologie mehr,
sondern der nächste logische Schritt in der Sicherheitsstrategie moderner Microsoft-Umgebungen.

Cloud-verwaltete Remote Postfächer – It’s finally happening!

Time to say goodbye… Jedenfalls zum letzten Exchange in eurer Umgebung!

Wenn du bisher gewartet hast, um den „letzten Exchange Server“ endlich loszuwerden, haben wir gute Nachrichten für dich:
Cloud-verwaltete Remote-Postfächer sind ab sofort allgemein verfügbar (GA)!

Am 20. August 2025 wurde die öffentliche Vorschau dieser Funktion angekündigt. Nun ist es endlich so weit!

Was sich seit der Vorschau verbessert hat

In der Public Preview war es noch nötig, Hybrid Identity Admin– oder Global Admin-Rechte zu haben, um die Eigenschaft isExchangeCloudManaged eines Postfachs zu ändern. Wenn man nur Exchange Admin-Rechte genutzt hat, wurde stillschweigend nichts geändert – ohne Fehlermeldung.

Das ist jetzt Geschichte
Ab sofort reicht die Exchange Admin-Berechtigung völlig aus, um die Einstellung zu ändern. Ein kleines, aber sehr willkommenes Update.

Was erwartet uns noch demnächst?

1. Mandantenweites LES-Flag

Damit kannst du künftig zentral festlegen, dass alle neuen, verzeichnissynchronisierten Postfächer automatisch ohne Exchange-Attribute in die Cloud synchronisiert und dort verwaltet werden.
Das spart dir die Konfiguration pro Postfach und beschleunigt die Einführung deutlich.

  • Private Preview: Ende dieses Monats
  • Allgemein verfügbar: Nächster Monat

2. Writeback von Exchange-Attributen

Manche Unternehmen haben lokale Anwendungen, die auf bestimmte Exchange-Attribute im AD angewiesen sind. Um hier einen reibungslosen Übergang zu ermöglichen, wird es bald möglich sein, wichtige Exchange-Attribute aus der Cloud zurück ins lokale AD zu schreiben – über Entra Cloud Sync.

  • Private Preview: November
  • Allgemein verfügbar: Anfang nächsten Jahres

Für alle, die on-prem ganz abschaffen wollen

Die oben genannten Features richten sich an Organisationen, die ihr lokales AD weiter betreiben, aber den letzten lokalen Exchange Server abschalten möchten.

Wenn du allerdings planst, komplett in die Cloud zu wechseln, hat Microsoft ebenfalls spannende Optionen für dich: den Objektbasierten Source-of-Authority (SOA)-Transfer. Damit kannst du Benutzer, Gruppen und Kontakte vollständig in Entra ID verschieben und dort verwalten.

  • Gruppen-SOA ist schon in der öffentlichen Vorschau
  • Benutzer-SOA ebenfalls
  • Kontakt-SOA ist jetzt als Vorschau verfügbar

Damit kannst du Identitäten vollständig in die Cloud heben, ohne Verwaltungsfunktionen einzubüßen – ein entscheidender Baustein, wenn du Exchange On-Prem endgültig abschalten willst.

Wie werde ich also meinen letzten Exchange los? Da wir hier das Rad natürlich auch nicht neu erfinden müssen, findet ihr hier den Link zum Learning Artikel von Microsoft:

https://learn.microsoft.com/en-us/exchange/hybrid-deployment/enable-exchange-attributes-cloud-management

End of Support für Exchange 2016 und 2019 – was bedeutet das konkret?

Viele Unternehmen setzen heute noch auf Exchange 2016 oder 2019. Am 14. Oktober 2025 endet der Extended Support für Exchange Server 2016 und Exchange Server 2019. Ab diesem Zeitpunkt stellt Microsoft keine Sicherheitsupdates, Bugfixes oder technische Unterstützung mehr für diese Versionen bereit.

Das bedeutet: Systeme, die nach dem 14. Oktober 2025 weiterhin betrieben werden, laufen ohne Schutz vor neu entdeckten Schwachstellen – eine Situation, die insbesondere sicherheitskritische Hybrid‑Szenarien gegenüber Exchange Online zu einem ernsthaften Risiko macht.

Microsoft setzt seit einiger Zeit auf ein neues Sicherheitskonzept für Hybrid-Szenarien: ungepatchte oder veraltete Exchange-Server werden aktiv überwacht. Sobald ein System dauerhaft nicht mehr dem aktuellen Patchstand entspricht, kann Microsoft die Kommunikation zwischen On-Premises und Exchange Online gezielt drosseln oder sogar blockieren. Ziel ist es, unsichere Server schneller aus dem Verkehr zu ziehen und Unternehmen damit zum Handeln zu bewegen.

Die Maßnahme zielt auf Systeme, die ein dauerhaftes Sicherheitsrisiko darstellen – insbesondere, wenn sie über längere Zeit nicht mehr mit den aktuellen CUs (Cumulative Updates) und SUs (Security Updates) versorgt wurden.

Der Grund ist klar: Veraltete und ungepatchte Systeme sind ein massives Sicherheitsrisiko – sowohl für deine eigene Infrastruktur als auch für die Cloud.

Drosselung und Blockierung – was heißt das für mich?

Wenn das System nicht auf einem aktuellen Stand ist, wird man mit Einschränkungen rechnen müssen. Microsoft kann den Datenverkehr zwischen deinem Exchange-Server und Exchange Online drosseln oder ganz unterbinden.

30 Tage Schonfrist – aber nur begrenzt

Du kannst die Drosselung zwar für 30 Tage pausieren, aber:

  • Diese „Grace Period“ steht nur drei Mal pro Kalenderjahr zur Verfügung.
  • Danach bleibt dir keine andere Wahl, als dein System zu aktualisieren oder eine Migration zu planen.

Kurz gesagt: Das ist nur eine Notlösung, keine Strategie.

Mit dem nahenden End of Support stellt sich die Frage: Wird Microsoft diese Systeme direkt blockieren?

Die gute Nachricht: Nein, nicht sofort!! Microsoft hat klargestellt:

„We do not plan to throttle a ‘fully up to date’ Exchange 2016/2019 immediately starting end of support, no. The throttling / blocking is to address persistently vulnerable servers (servers that are out of date significantly). We do not have ‘a date’ when we would start throttling those versions after they go out of support as that depends on vulnerabilities found / updates released. And yes, you’ll still have the usual time to pause the throttling / blocking.“

Das heißt für mich:

  • Wenn der Exchange 2016 oder 2019 bis zum Supportende aktuell gehalten wird, ist man zunächst auf der sicheren Seite.
  • Kritisch wird es erst, wenn nach Supportende neue Schwachstellen auftauchen – denn dann kannst du diese Systeme nicht mehr patchen.
  • Spätestens in diesem Moment riskierst man, in die Drosselung oder Blockierung zu laufen.
  • Auch hier gibt es die Option, die Drosselung temporär zu pausieren – aber nur begrenzt und nicht als Dauerlösung.

Microsoft macht aber unmissverständlich klar: Nur aktuelle Systeme dürfen im Hybrid-Betrieb laufen. Heißt zusammengefasst:

  • Nur vollständig gepatchte und unterstützte Systeme dürfen dauerhaft mit Exchange Online kommunizieren.
  • Das bedeutet für dich: Planung statt Reaktion – ob durch Migration nach Exchange Online oder ein rechtzeitiges Upgrade.
  • Wer wartet, bis die Drosselung greift, läuft Gefahr, den Mailfluss für 30 Tage nur noch künstlich „freischalten“ zu können – und spätestens nach drei Verlängerungen steht die Infrastruktur still.

Fazit

Mit dem Ende des Extended Supports am 14. Oktober 2025 ist klar: Exchange 2016 und 2019 werden zur tickenden Zeitbombe, sobald keine Sicherheitsupdates mehr verfügbar sind. Microsoft duldet im Hybrid-Betrieb nur Systeme, die auf dem aktuellen Patchstand sind. Alles andere führt über kurz oder lang zu Drosselung, Blockierung und eingeschränkter Kommunikation mit Exchange Online.

Heißt für euch: Warte nicht, bis Microsoft eingreift. Plane jetzt deine Strategie – ob Migration nach Exchange Online oder ein rechtzeitiges Upgrade auf Exchange Subscription Edition. Nur so wird sichergestellt, dass der Mailfluss stabil bleibt und du nicht auf Notlösungen wie die begrenzte 30-Tage-Pause angewiesen bist.

Cloud-Managed Remote Mailboxes – der nächste Schritt zur finalen Exchange-Server-Stilllegung

Hintergrund: Das „Last Exchange Server“-Problem

Viele Unternehmen, die mittlerweile sämtliche Postfächer in Exchange Online betreiben, behalten dennoch einen lokalen Exchange-Server – allein zur Verwaltung von Empfängerattributen. In Hybrid-Szenarien ist das Bearbeiten von Remote-Mailbox-Eigenschaften in der Cloud standardmäßig blockiert, da die Quelle der Autorität (Source of Authority, SOA) in der On-Premises-Exchange-Umgebung liegt (techcommunity.microsoft.com).

Die neue Cloud-Management-Funktion

Microsoft hat ein neues Feature in Exchange Online (aktuell im Preview-Status) angekündigt, das es ermöglicht, die Exchange-Attribute synchronisierter Benutzerkonten mit Remote-Postfächern direkt aus der Cloud zu bearbeiten. Identitätsattribute wie Name oder Telefon bleiben dabei nach wie vor On-Premises-verwaltet (techcommunity.microsoft.com).

Zentrales Element ist der neue Parameter IsExchangeCloudManaged. Setzt man diesen auf True, übernimmt Exchange Online die Quelle der Autorität für die betreffenden Exchange-Attribute eines Benutzers (techcommunity.microsoft.com).

So funktioniert es im Detail

  • Standardmäßig ist bei synchronisierten Benutzern IsExchangeCloudManaged = False, d. h. Exchange-Attribute werden in der On-Premises-AD verwaltet und in die Cloud repliziert.
  • Wird IsExchangeCloudManaged = True, kann man Exchange-Attribute wie E-Mail-Adressen, spezielle Attribute (z. B. CustomAttribute1–15, proxyAddresses) über Exchange Online PowerShell oder das Admin Center ändern. Diese Änderungen bleiben erhalten, da der On-Prem-Sync sie nicht mehr überschreibt (learn.microsoft.com).
  • Identitätsattribute – z. B. Name, Abteilung, Telefonnummer – verbleiben weiterhin unter der Kontrolle der lokalen Active Directory und sind von der Änderung nicht betroffen (techcommunity.microsoft.com).
  • In Phase 1 (aktuell verfügbar) kann pro Postfach entschieden werden, welches Attributset cloud-gesteuert wird. Eine Rückumstellung (Rollback) ist möglich (learn.microsoft.com).
  • In einer späteren Phase (Phase 2) ist geplant, dass Änderungen an Exchange-Attributen in der Cloud automatisch wieder zurück in das lokale AD geschrieben werden („Write-Back“), vorausgesetzt, Entra Cloud Sync wird genutzt (learn.microsoft.com).
  • Bereits verfügbar ist eine object-level SOA-Übertragung für Gruppen (Group SOA); künftig sollen Attribute auch für Benutzer- und Kontaktobjekte cloud-gesteuert werden können (learn.microsoft.com).

Vorteile dieser Entwicklung

  • Endlich Exchange-Server-frei – Der „Last Exchange Server“ wird überflüssig, selbst in Hybrid-Szenarien.
  • Weniger administrative Komplexität – Verwaltung über Exchange Online PowerShell, Admin Center oder Microsoft 365 Admin Center.
  • Sicherheitsgewinn – Reduzierter On-Prem-Fußabdruck bedeutet weniger Angriffsfläche und weniger Patchaufwand.
  • Zukunftssicher – Mit geplantem Write-Back und Cloud-SOA für Gruppen und Kontakte entsteht eine echte Cloud-Zielarchitektur.

Umsetzung: So hebst du IsExchangeCloudManaged auf

  1. In Exchange Online PowerShell: Set-Mailbox -Identity <User> -IsExchangeCloudManaged $true
  2. Status prüfen: Get-Mailbox -Identity <User> | Format-List Identity, IsExchangeCloudManaged

Meine Meinung als IT-Consultant

Für viele unserer Kunden ist dies ein Herzenswunsch, der nun endlich Realität wird: weg vom letzten lokalen Exchange-Server, hin zu einer komplett cloudbasierten Verwaltung. In zahlreichen Projekten haben wir immer wieder erlebt, dass die Pflicht, einen On-Premises-Server nur für die Exchange-Verwaltung stehen zu lassen, nicht nur technisch, sondern auch organisatorisch und sicherheitsrelevant ein großes Ärgernis war. Mit den Cloud-Managed Remote Mailboxes ist diese Hürde nun gefallen – und das macht den Weg zur echten „Cloud Only“-Strategie frei.

Fazit

Mit Cloud-Managed Remote Mailboxes macht Microsoft einen bedeutenden Schritt in Richtung endgültige Ablösung des lokalen Exchange Servers – auch für hybride Umgebungen. Diese neue Funktion bündelt Verwaltung, Sicherheit und Flexibilität in der Cloud und zeigt deutlich, wie die Zukunft der Exchange-Verwaltung aussieht.

Conditional Access und Microsoft Defender for Endpoint: Ein Teufelskreis?

Eine wirkungsvolle Möglichkeit, die Sicherheit innerhalb eines Unternehmens zu erhöhen, besteht darin, den Microsoft Defender for Endpoint Status über eine Compliance-Richtlinie in den Compliance-Status für Intune verwaltete Geräte einzubinden. Auf diese Weise können gefährdete Geräte schnell identifiziert und vom Zugriff auf Unternehmensdaten ausgeschlossen werden. Dieser Ansatz schafft eine zusätzliche Schutzebene. Zusätzlich stellt dieser sicher, dass nur Geräte mit einem sicheren Status auf sensible Informationen zugreifen können. Insbesondere bei schwerwiegenden Sicherheitslücken oder Sicherheitsvorfällen ist dies eine zuverlässige Methode die Geräte bis zur Mitigation der Ursache vom Zugriff auf Unternehmensdaten zu sperren.

Dender for Endpoint in Compliance Policy
Dender for Endpoint in Compliance Policy

Allerdings kann die Verknüpfung von Microsoft Defender for Endpoint und Conditional Access Richtlinien schnell in einen Teufelskreis führen. Das passiert , wenn eine Conditional Access Regel implementiert ist, die den Zugriff für nicht kompatible Geräte blockiert. Dadurch entsteht ein Dilemma: Die betroffenen Geräte können sich nicht erneut als kompatibel registrieren. Der Grund dafür ist die Conditional Access Policy die den Zugriff sperrt. Das macht es für den Administrator schwer das Gerät, ohne ein komplettes Zurücksetzen wieder kompatibel zu bekommen.

Wie der Teufelskreis entsteht?

Standardmäßig können die beiden Microsoft Defender for Endpoint Applikationen nicht direkt aus Conditional Access Richtlinien ausgenommen werden. Die Folge ist, dass Geräte, die durch den Conditional Access blockiert werden, keine Möglichkeit haben, sich wieder als kompatibel zu registrieren. Der Zugriff auf dafür notwendige Dienste wird gesperrt, wodurch der Status „nicht kompatibel“ bestehen bleibt. Standardmäßig stehen die beiden Applikationen „MicrosoftDefenderATP XPlat“ und „Microsoft Defender for Mobile TVM app“ nicht im Conditional Access zur Auswahl.

Wie kann der Teufelskreis durchbrochen werden?

Um diesen Teufelskreis zu durchbrechen, müssen die beiden Service Principals registriert werden: „MicrosoftDefenderATP XPlat app“ (a0e84e36-b067-4d5c-ab4a-3db38e598ae2) und Microsoft Defender for Mobile TVM app (e724aa31-0f56-4018-b8be-f8cb82ca1196).

Dies funktioniert mit der Powershell mit folgendem Code:

Install-Module Microsoft.Graph

Import-Module Microsoft.Graph.Applications

 

Connect-MgGraph

$params = @{

              appId = "a0e84e36-b067-4d5c-ab4a-3db38e598ae2"

}

New-MgServicePrincipal -BodyParameter $params

$params = @{

              appId = "e724aa31-0f56-4018-b8be-f8cb82ca1196"

}

New-MgServicePrincipal -BodyParameter $params

Nach der Registrierung können die Anwendungen aus den Conditional Access Richtlinien ausgeschlossen werden. Dieser Ausschluss sorgt dafür, dass die Geräte weiterhin Zugriff auf die notwendigen Dienste haben, selbst wenn sie als nicht kompatibel markiert sind. Dadurch wird es möglich, die Geräte wieder als kompatibel zu registrieren und den Zugriff zu normalisieren.

Defender for Endpoint aus Conditional Access Policy ausschließen.
Defender for Endpoint aus Conditional Access Regel ausschließen

Fazit

Mit diesem Trick kann der Teufelskreis durchbrochen werden und die Geräte erhalten wieder Zugriff auf die M365 Dienste, sobald die Compliance wiederhergestellt ist. Auch bleibt während der Non-Compliance die Kommunikation mit dem Defender for Endpoint bestehen und wird nicht „abgeschnitten“. Das erhöht die Sicherheit und hilft dabei das Potential des Defender for Endpoints bestmöglich zu nutzen. Der Defender for Endpoint Status kann unter anderem in den Compliance Policies für Windows, iOS und Android genutzt werden.

Cookie Consent mit Real Cookie Banner