Optimierung des Microsoft‑365-Datenverkehrs mit einer Sophos XGS Firewall

Der Einsatz von Microsoft 365 (M365) stellt Unternehmensnetzwerke vor besondere Herausforderungen: Die Cloud-Services sollen für Benutzer schnell und zuverlässig erreichbar sein, ohne dabei die IT-Sicherheit zu gefährden. Eine Sophos XGS-Firewall kann dabei helfen, den Datenverkehr zu M365 sowohl performant als auch sicher zu gestalten. Im Folgenden werden alle relevanten Aspekte beleuchtet – von Performanceoptimierungen über Sicherheitsmaßnahmen bis hin zu QoS-Priorisierungen, Integrationstipps und Best Practices.

1. Performanceoptimierung für M365-Verkehr

Lokaler Internet-Breakout & SD-WAN-Routing: Microsoft empfiehlt, Office-365-Datenverkehr möglichst lokal ins Internet auszulagern (“local breakout”), um unnötige Umwege über zentrale Gateways zu vermeiden. Insbesondere sollte man Backhauling (das Zurückleiten des Traffics an einen zentralen Standort) reduzieren, da jede zusätzliche Strecke die Latenz erhöht. Wichtig ist auch eine lokale DNS-Auflösung: Nur so verbinden sich Clients mit dem nächstgelegenen Microsoft-Einstiegspunkt und profitieren vom global verteilten Netzwerk Microsofts. In der Praxis bedeutet dies, dass Zweigstellen möglichst direkt – und nicht über das Hauptquartier – auf M365 zugreifen sollten. Sophos XGS-Firewalls verfügen über integrierte SD-WAN-Funktionen, mit denen sich solche direkten Internet-Breakouts einfach umsetzen lassen. Über SD-WAN Policy-Based Routing kann die Firewall spezifischen M365-Traffic erkennen und bevorzugt über einen definierten Internetanschluss leiten. Dabei misst Sophos laufend Qualitätsparameter der WAN-Leitungen (Laufzeit, Jitter, Paketverlust) und kann anhand definierter SLA-Kriterien automatisch den besten Link auswählen. Verschlechtert sich die Leistung einer Leitung, kann aktiver Datenverkehr – z. B. ein laufendes Teams-Meeting – in Echtzeit ohne Unterbrechung auf eine bessere Verbindung umgeroutet werden. Dieses dynamische Lastverteilungs- und Failover-Verhalten stellt sicher, dass wichtige M365-Anwendungen stets die optimale Verbindung nutzen.

DNS-Optimierung: Zusammen mit lokalem Breakout ist DNS entscheidend. Lokale DNS-Server oder Forwarder in der Nähe der Clients sollten die Microsoft-Cloud-URLs auflösen, damit die Benutzer über das nächstgelegene Microsoft-Rechenzentrum verbunden werden. Eine zu langsame oder falsch positionierte DNS-Instanz kann dazu führen, dass z.B. Teams einen weiter entfernten Server anspricht, was Latenz und Antwortzeiten verschlechtert. Daher empfiehlt es sich, gegebenenfalls die Firewall als DNS-Forwarder einzusetzen und die von Microsoft empfohlenen DNS-Praktiken (wie EDNS0-Client-Subnet) zu unterstützen. In komplexen Topologien müssen lokaler Breakout und lokale DNS immer zusammengedacht werden.

Direct Routing spezifischer M365-Dienste: Microsoft kategorisiert seine Dienste in Optimize, Allow und Default. Optimize-Endpunkte (etwa Exchange Online, SharePoint Online, Microsoft Teams) sind besonders latenzsensibel und sollen laut Microsoft ohne Umwege und Filter behandelt werden. In der Praxis kann man diese Kategorie identifizieren und priorisiert direkt routen. Ein Beispiel aus der Praxis: Ein Unternehmen hat per Gruppenrichtlinie alle Ziele der Optimize-Kategorie (z. B. *.sharepoint.com, outlook.office365.com) vom Proxy ausgenommen, sodass diese Verbindungen direkt ins Internet gehen – genau wie von Microsoft empfohlen. Konkret wurde das Konstrukt so umgesetzt, dass Office-365-Optimize-Traffic direkt geroutet wird, während sonstiger HTTP/HTTPS-Verkehr weiterhin den Proxy bzw. zentrale Filter passiert. Diese Strategie reduzierte die Latenz deutlich. Allerdings zeigte sich auch, wie wichtig eine vollständige Pflege der Zieladressen ist: In dem genannten Fall traten anfänglich Outlook-Verbindungsprobleme auf, da nicht alle tatsächlich genutzten IP-Adressen in Microsofts offizieller Endpoint-Liste enthalten waren. Die Lösung bestand darin, temporär jeglichen HTTPS-Outbound zu erlauben – ein unsicherer Workaround, der die Notwendigkeit einer besseren Automatisierung verdeutlicht (siehe Integration, Abschnitt 4). Fazit: Um optimale Performance zu erzielen, sollten Unternehmen M365-Traffic identifizieren und möglichst ohne Umwege und Zusatzlatenz in die Cloud schicken. Die Sophos XGS bietet mit SD-WAN-Regeln hierfür die nötigen Werkzeuge, um z.B. Office-365-Verkehr gezielt über einen bestimmten WAN-Port (lokaler Internetzugang) zu leiten, während anderer Traffic ggf. über zentrale Gateways geht.

Xstream FastPath (Sophos Firewall Beschleunigung): Ein weiterer Performance-Hebel in der XGS-Architektur ist der Xstream Network Flow FastPath. Dabei handelt es sich um eine Technik, die “vertrauenswürdigen” Datenverkehr abseits der normalen Prüfkette direkt und beschleunigt durch die Firewall schleust. So werden Latenzen minimiert und die Last auf die Prüf-Engine reduziert. Wann ist Datenverkehr vertrauenswürdig? – Zum Beispiel, wenn SophosLabs anhand des TLS-Servernamens (SNI) erkennt, dass es sich um sichere und manipulationsgeschützte Streams handelt, z.B. Video-/Audio-Streaming oder feste Updates direkt vom Hersteller. Auch Echtzeit-Kommunikation wie VoIP- und Kollaborationsdienste (z.B. Microsoft Teams Calls) zählen dazu. Solche Streams können kaum Schadcode enthalten (bei reinen Audio/Video-Daten ist eine Malware-Einschleusung technisch nicht möglich), weshalb sie ideale Kandidaten für den FastPath sind. Die Sophos XGS beschleunigt solche Verbindungen automatisch, sofern keine sicherheitsrelevante Prüfung erforderlich ist. Alternativ kann der Admin auch aktiv steuern, was in den FastPath darf: Erzeugt man eine Firewall-Regel ohne Security-Scanning (d.h. Webfilter, AV, IPS etc. deaktiviert) für bestimmte M365-Dienste oder Server, wird dieser Traffic gezielt auf den FastPath gelegt. Best Practice ist es, Streaming- und Sprachverkehr von M365 (Teams-Meetings, -Telefonie) auf diese Weise zu beschleunigen, während downloads von ausführbaren Dateien oder allgemeinen Web-Inhalten nicht unbesehen ins FastPath sollten. So schafft man einen guten Kompromiss: Wichtige Echtzeitdienste profitieren von minimaler Latenz, während potenziell riskante Transfers weiterhin geprüft werden. Zusammengefasst bietet die XGS-Firewall also mehrere Funktionen – von intelligentem SD-WAN-Routing über lokales DNS bis hin zum FastPath-Beschleuniger –, um die Performance von Microsoft 365 signifikant zu verbessern, ohne den gesamten Internetverkehr pauschal durchzulassen.

2. Sicherheitsaspekte bei M365-Traffic

Trotz Performance-Fokus darf die IT-Sicherheit nicht vernachlässigt werden. M365-Anwendungen transportieren sensible Unternehmensdaten und können Einfallstor für Bedrohungen sein. Daher muss eine ausgewogene Sicherheitsstrategie her: Gewisse Microsoft-Verbindungen gelten als vertrauenswürdig und können aus Performancegründen freier passieren, während an anderer Stelle gezielte Prüfungen stattfinden. Die Sophos XGS-Firewall bietet dafür verschiedene Module:

TLS-Inspection (HTTPS-Entschlüsselung): Standardmäßig ist ein Großteil des M365-Datenverkehrs TLS-verschlüsselt (HTTPS). Um diesen Verkehr inhaltlich auf Bedrohungen zu prüfen (z.B. Malware in heruntergeladenen Dateien, verdächtige Payloads in OneDrive-Uploads, etc.), kann die XGS eine TLS-Inspection durchführen. Dabei agiert die Firewall als Man-in-the-Middle, entschlüsselt den Traffic und ermöglicht nachgelagerte Scans (AV, IPS, Sandboxing). Vorteil: Bedrohungen, die in verschlüsselten Streams verborgen sind, können erkannt und blockiert werden. Nachteil: Dies erzeugt Latenz und erfordert, dass die Clients das von der Firewall verwendete Stammzertifikat vertrauen – sonst kommt es zu Zertifikatswarnungen (z.B. in Outlook). Microsoft selbst rät, bei sensiblen O365-Diensten Intrusion der Verbindung möglichst zu vermeiden („Eliminate Intrusive Network Security“), da zusätzliche Inspektionsgeräte die Performance beeinträchtigen können. Sophos bietet hier einen pragmatischen Weg: In der Webfilter-Konfiguration gibt es bereits vordefinierte Ausnahmen für Microsoft 365. Durch Aktivieren der Ausnahme „Microsoft 365“ unter Web > Exceptions werden die wichtigsten M365-Domains von HTTPS-Decrypt, Malware-Scan und sonstigen Web-Policies ausgenommen. Das bedeutet, diese Verbindungen passieren die Firewall ohne Inhaltsprüfung (nur grundlegende Paketfilter und IPS greifen noch). Dies entspricht den Empfehlungen, kritischen O365-Traffic nicht unnötig zu verlangsamen. In vielen Fällen ist dies vertretbar, da Microsofts eigene Sicherheitsmechanismen (z.B. Antiviren-Scan in Exchange Online, Safe Attachments, etc.) bereits einen Grundschutz bieten. Trotzdem sollte man bewusst entscheiden, welche Teile des M365-Verkehrs man nicht inspizieren will. Beispielsweise kann man reine Teams-Sprach-/Videoverbindungen gefahrlos unverschlüsselt durchwinken, während man Downloads aus SharePoint/OneDrive oder E-Mail-Anhänge vielleicht doch prüfen möchte. Die Sophos-Firewall erlaubt feingranulare Regeln: So könnte man z.B. nur bestimmte Domains oder URL-Pfade von der Entschlüsselung ausschließen. Wichtig: Falls man TLS-Inspection für M365 aktiviert, müssen die Client-Rechner das Sophos-CA-Zertifikat als vertrauenswürdig installiert haben. Ein häufiger Fehler ist es, dies zu vergessen – was sich in Outlook durch Zertifikatsfehler äußert. In einem bekannten Fall zeigten Outlook-Clients sporadisch Zertifikatswarnungen, weil der Datenverkehr von der Sophos XG entschlüsselt wurde, das Sophos-Zertifikat aber nicht im Trust Store der Clients lag; durch Deaktivieren der HTTPS-Prüfung verschwanden die Fehler, was den fehlenden Zertifikattrust als Ursache bestätigte. Best Practice ist daher: Entweder TLS-Prüfung für O365 gezielt ausschließen oder sicherstellen, dass alle Geräte der Domäne das benötigte Zertifikat eingespielt haben.

Web Filtering & Application Control: Die Sophos XGS-Firewall besitzt ein Web- und Anwendungsfilter-Modul, das auch für M365-Traffic relevant ist. Über Webfilter-Policies lassen sich Kategorien von Webseiten/Services zulassen oder blockieren. Office-365-Dienste fallen zumeist in Business-/Produktivitäts-Kategorien, die standardmäßig erlaubt sein sollten. Dennoch ist es sinnvoll, eine dedizierte Policy für Microsoft 365 zu definieren. So kann man etwa nur die offiziellen M365-URLs zulassen und alles andere blockieren oder strenger prüfen, wenn eine Regel speziell für diesen Traffic greift. Auch Application Control kann eingesetzt werden: Die Firewall erkennt viele Microsoft-365-Anwendungen (z.B. „Microsoft Teams“, „Office 365 Portal“, „OneDrive“ etc.) als eigene Applikations-Signaturen. Dadurch kann man in den Firewall-Regeln steuern, ob bestimmte M365-Apps erlaubt sind oder ggf. eingeschränkt werden. Aus Sicherheitssicht könnte man z.B. unterbinden, dass unerwünschte Dienste (z.B. der nicht verwaltete persönliche OneDrive oder Skype wenn nicht gewünscht) im Firmennetz laufen, während die geschäftlichen M365-Dienste erlaubt sind. Ferner können über Application Control auch Datenabflüsse verhindert werden – etwa indem man Datei-Uploads zu nicht autorisierten Cloud-Speichern blockiert, während SharePoint/OneDrive for Business zulässig sind. Ein nützlicher Nebeneffekt: Applikationsfilter ermöglichen auch gezielte Traffic-Priorisierung (siehe Abschnitt 3), was bei Teams/VoIP wesentlich ist. Insgesamt helfen Web- und App-Filter dabei, den M365-Traffic einzurahmen – also Good Traffic (Office 365) gezielt durchzulassen und Bad Traffic (Phishing-Seiten, unbekannte Cloud-Dienste) abzuwehren.

Zero-Day-Schutz (Sophos Sandstorm): Selbst wenn Standard-Antivirenfilter aktiv sind, besteht immer ein Restrisiko durch neuartige, noch unbekannte Bedrohungen. Hier kommt Sophos Zero-Day-Protection (früher „Sandstorm“)】 zum Einsatz – eine Cloud-Sandbox, in der verdächtige Dateien detoniert und analysiert werden. Wenn etwa ein Benutzer ein Office-Dokument aus SharePoint herunterlädt oder ein E-Mail-Anhang durch die Firewall fließt, kann die XGS diese Datei zunächst in die Sandbox hochladen und prüfen lassen, bevor sie dem Empfänger freigegeben wird. Wichtig: Um Zero-Day-Schutz für M365-Daten zu ermöglichen, muss die Firewall den Traffic einsehen können. Das heißt konkret: Zero-Day-Scanning greift nur bei HTTP oder entschlüsseltem HTTPS. Wenn man also – wie oben beschrieben – M365-URLs generell von der TLS-Inspection ausnimmt, kann Sandstorm diesen Verkehr nicht analysieren. Man verlässt sich dann auf Microsofts integrierten Schutz (Defender, etc.). Alternativ kann man gezielt für bestimmte Downloads die Entschlüsselung einschalten. Die Zero-Day-Protection ist integraler Bestandteil der Sophos-XGS (in entsprechenden Lizenz-Bundles enthalten) und nutzt dieselbe Detektions-Engine wie Sophos Intelix (Threat Intelligence von SophosLabs). Aus Security-Sicht stellt Sandstorm eine zusätzliche Verteidigungslinie dar, um Advanced Persistent Threats und unbekannte Malware abzufangen, bevor sie ins Netzwerk gelangen. In der Konfiguration der Firewall sollte man sicherstellen, dass in den relevanten Regeln „Zero-Day-Schutz mit Sandstorm“ aktiviert ist und – falls Web Proxy genutzt wird – „HTTPS entschlüsseln“ eingeschaltet** ist. Dadurch werden Web-Downloads zu M365 über die Sandbox geschleust, ohne dass der Benutzeraktivität stark beeinträchtigt wird (bei größeren Dateien kann es jedoch zu kurzer Verzögerung kommen, bis das Sandbox-Ergebnis vorliegt).

Secure Web Gateway Funktionen: Die Sophos XGS agiert de facto als Secure Web Gateway (SWG) für ausgehenden Traffic. Das heißt, sie kombiniert URL-Filter, Malware-Schutz, Inhaltsprüfung und DLP-Fähigkeiten. Für Microsoft 365 sollte der SWG-Modus so eingestellt sein, dass Balance zwischen Sicherheit und Performance herrscht. Beispielsweise kann man Dateitypenfilter einsetzen: Office-Dateien und PDFs scannen, während Video-Streams von Teams ungeprüft passieren dürfen. Zudem bietet Sophos einen „SafeSearch“ und „Sophos Labs Site Reputation“ Check – auch M365-URLs werden in der Regel als vertrauenswürdig eingestuft, sodass kein Alarm erfolgt. Dennoch können SWG-Funktionen nützlich sein, um etwa Benutzer beim Aufruf von falschen Microsoft-Seiten (Phishing-Domains, die Microsoft imitieren) zu schützen. Die Webfilter-Datenbank der XGS erkennt solche Bedrohungen in der Regel und blockiert sie kategorisch, was eine wichtige Ergänzung zur Microsoft-Cloud-Security darstellt. Nicht zuletzt kann man über Richtlinien für unterschiedliche Benutzer/Gruppen festlegen, wer z.B. welche Teile von M365 nutzen darf (etwa externe Partner im Gastnetz haben nur Web-Zugriff auf Office.com, aber kein VPN/Exchange-Zugang, etc.). Zusammenfassend lässt sich sagen: Die Sophos XGS bietet umfangreiche Sicherheitskontrollen für M365-Traffic – von Verschlüsselungsinspektion über Inhaltsfilter bis hin zur Sandbox. Allerdings sollte man diese zielgerichtet einsetzen, um die in Abschnitt 1 gewonnenen Performancevorteile nicht zunichte zu machen. Oft bewährt sich ein hybrider Ansatz: Kritische Echtzeitdienste werden ausgenommen und beschleunigt, während potentiell riskante Inhaltsdaten mit moderater Tiefeninspektion überwacht werden.

3. Priorisierung und QoS für Office 365

Gerade bei limitierter Bandbreite oder starker Netzlast ist es essenziell, wichtigen Anwendungen Vorrang zu geben. Microsoft 365 umfasst neben E-Mail auch Echtzeitkommunikation wie Teams-Calls/Meetings – diese reagieren empfindlich auf Jitter, Paketverlust und Verzögerungen. Die Sophos XGS-Firewall bietet hierfür Quality of Service (QoS)-Mechanismen über Traffic Shaping. Damit lässt sich bestimmten Traffic-Klassen eine garantierte Bandbreite reservieren oder eine höhere Priorität im Ausgabepuffer zuweisen.

Traffic Shaping auf Applikationsbasis: Anstatt statische Ports oder IPs zu limitieren, kann die XGS Anwendungs-basiertes QoS verwenden. In den Einstellungen kann man eigene Traffic-Shaping-Profile definieren (z.B. „Teams High Priority“ mit hoher Prioritätsstufe und garantiertem Minimum an kb/s). Anschließend weist man dieses Profil den erkannten Teams-Verbindungen zu. Ein effizienter Ansatz ist es, in der Anwendungssteuerung gezielt die Microsoft-365-Dienste zu markieren. So empfahl ein Sophos-Experte, nicht mühsam alle Teams-Subnetze per Hand in Regeln einzutragen, sondern Application Traffic Shaping zu nutzen: In SFOS v19+ kann man unter System Services > Traffic Shaping ein entsprechendes Policy-Profil anlegen und dann in der Applikationsliste alle Einträge, die „Teams“ beinhalten, mit dieser Policy verknüpfen. Anschließend wird in der Firewallregel das Häkchen „Application-based traffic shaping“ aktiviert, sodass die Regel die hinterlegten QoS-Parameter auf erkannte Teams-Pakete anwendet. Der Vorteil dieser Methode liegt darin, dass neue IP-Adressen oder dynamische Ports von Teams automatisch erfasst werden – man ist nicht darauf angewiesen, jedes Subnetz manuell zu pflegen.

Klassisches QoS (bandwidth management): Alternativ oder ergänzend kann man natürlich auch herkömmliche bandwidth Pools und Limits definieren. Beispielsweise könnte eine Firma festlegen, dass M365-Verkehr mindestens 40% der WAN-Bandbreite garantiert bekommt, während weniger wichtige Dienste notfalls gedrosselt werden. In der XGS-Firewall lässt sich via Traffic Shaping Policies sowohl Garantien als auch Limits konfigurieren. Dabei kann man pro Regel oder sogar pro Nutzergruppe unterschiedliche Profile anwenden. So ist es denkbar, Office-365-Datenverkehr für die Führungskräfte mit hoher Priorität zu versehen. Praktisch ist auch die Option, den DSCP-Wert (Differentiated Services Code Point) von Paketen zu markieren. Microsoft Teams setzt z.B. für Audio/Video bereits DSCP-Markierungen (Audio meist 46 – EF, Video 34 – AF41). Die Firewall kann entweder diese Markierungen aus dem LAN übernehmen und im WAN erhalten, oder – falls intern nicht markiert – per Regel entsprechende DSCP-Tags setzen. Ein Anwenderbeispiel war das Vorhaben, Teams-Pakete (Ports 3478-3481 UDP, 80/443) mit DSCP 46 zu markieren, um sie im Upstream bevorzugt zu behandeln. Sophos XGS unterstützt das prinzipiell; allerdings muss man dafür FQDN-Hostobjekte der Teams-Dienste oder Application Patterns verwenden, da Wildcards in Zielangaben nur über FQDN-Objekte abgedeckt werden können. Hier zeigt sich wieder der Nutzen der oben erwähnten Application-Based Rules – es vereinfacht QoS erheblich, wenn man auf die eingebauten Signaturen für „Office 365“ zurückgreift.

Policy-basierendes Forwarding nach Priorität: Über SD-WAN-Funktionen lässt sich QoS auch auf die WAN-Lastverteilung ausdehnen. So kann die Sophos-Firewall beispielsweise so konfiguriert werden, dass zeitkritischer Office-365-Verkehr bevorzugt über die schnellste Internetleitung geht (z.B. Glasfaser) und weniger wichtiger Traffic (Windows-Updates, YouTube etc.) eine zweite Leitung (z.B. DSL) nutzt. Dieser Ansatz – auch als Application Routing bekannt – stellt sicher, dass M365 nicht nur intern Vorrang hat, sondern auch nach außen hin die bestmögliche Route nimmt. Moderne Firewalls wie Sophos oder Barracuda implementieren hierfür vordefinierte Policies: Barracuda SecureEdge etwa wählt bei mehreren Uplinks automatisch diejenige mit der besten Latenz für Microsoft 365-Traffic und behandelt M365 stets als hochpriorisiert. Ebenso kann Sophos XGS mit SD-WAN-Profilen für Office 365 ausgestattet werden, die beispielsweise Latenzschwellen definieren – wird die Latenz auf WAN 1 zu hoch, schwenkt M365-Verkehr auf WAN 2 um, sofern dort besser. Die Synchronized SD-WAN-Funktion von Sophos (sofern Sophos Endpoints verwendet werden) kann die Erkennung und Umschaltung noch weiter optimieren, indem Client- und Firewall-Informationen ausgetauscht werden. Insgesamt ist es mit Sophos XGS möglich, Quality-of-Service über alle Ebenen sicherzustellen: Priorisierung auf Paketebene (Queue Management), Reservierung von Mindestbandbreiten und intelligente Wegwahl im WAN. Unternehmen sollten für M365 – speziell für Lync/Teams (Audio, Video, Screensharing) und Exchange Online (SMTP, Outlook-Verkehr) – entsprechende QoS-Regeln definieren. So wird vermieden, dass etwa ein großer OneDrive-Sync oder eine Hintergrundinstallation von Office-Updates die Leitung verstopft und wichtige Meetings beeinträchtigt. Richtig konfiguriert, gewährleistet die Firewall, dass geschäftskritischer M365-Traffic immer Vorfahrt hat.

4. Integration der Firewall mit Microsoft 365

Eine besondere Herausforderung bei Cloud-Diensten ist die dynamische Natur der Zieladressen. Microsoft 365 nutzt eine Vielzahl an URLs und IP-Adressbereichen, die sich regelmäßig ändern oder erweitern. Eine Optimierung des M365-Traffics gelingt nur, wenn die Firewall diese Ziele kennt und aktuell hält. Hier einige Integrationspunkte und Tipps, wie Sophos XGS mit Microsoft 365 zusammenspielt:

Microsoft-Endpoints (IPs, FQDNs) nutzen: Microsoft publiziert alle erforderlichen URLs und IP-Ranges für Office 365 in einem regelmäßigen Turnus über einen Webservice. Sophos-Firewalls können diese Information auf zwei Arten verwenden: 1. FQDN-Hostobjekte: In der XGS lassen sich DNS-basierte Hostobjekte anlegen, z.B. für outlook.office365.com oder *.teams.microsoft.com. Die Firewall wird diese Domains auflösen und in Regeln berücksichtigen. Vorteil: Man kann Regeln erstellen wie „erlaube Traffic zu .office365.com über WAN Direkt“ ohne jede einzelne IP zu kennen. Nachteil: FQDN-Objekte aktualisieren sich nur periodisch und könnten bei sehr vielen Einträgen die Firewall etwas belasten. Zudem gelten sie primär für TCP/UDP, nicht unbedingt für ICMP. 2. IP-Adresslisten:* Alternativ (oder ergänzend) kann man die von Microsoft bereitgestellten IP-Netze als Network Hosts/Groups in der Firewall anlegen. Beispielsweise alle Exchange-Online-Netze in eine Gruppe „O365_Exchange_IPs“. Dies kann man dann in Firewall- und SD-WAN-Regeln benutzen. Hier liegt jedoch der Pflegeaufwand darin, diese Listen aktuell zu halten.

Automatisierung der Endpoint-Pflege: Da die manuelle Aktualisierung der IP-Listen fehleranfällig ist, bietet Sophos Möglichkeiten zur Automatisierung. Ein Community-Experte hat etwa eine Lösung veröffentlicht, die per Script/Pipeline die Office-365-Webservice-Daten ausliest und direkt in die Sophos-Firewall einspeist. Ab SFOS Version 20 (XGS-Firmware) besteht sogar die Möglichkeit, eine vorbereitete Konfigurationsdatei zu importieren, welche alle Microsoft-365-IP-Objekte enthält. Der empfohlene Community-Guide dazu generiert 36 Host-Objekte und 1 Host-Gruppe, welche sämtliche von Microsoft veröffentlichten Adressen umfasst. Diese Host-Gruppe kann man dann bequem in Regeln verwenden („M365 Services“ als Zielnetz). Das Paket wird regelmäßig aktualisiert (z.B. stand 31.05.2024) und kann entweder manuell geladen oder über die Sophos API bzw. Sophos Factory automatisiert eingespielt werden. Sophos Factory ist ein neues Automatisierungs-Tool, mit dem sich Workflows definieren lassen – ein veröffentlichter Factory-Workflow kann z.B. die M365-Liste regelmäßig abrufen und die Firewall automatisch updaten. Kurzum: Die Integration der jeweils aktuellen M365-Endpunkte in die Firewall ist entscheidend, um einerseits Performance-Routing (siehe oben) korrekt anzuwenden und andererseits keine Verbindungen fälschlich zu blockieren.

Sophos Central und Azure-Integration: Die Sophos XGS lässt sich über Sophos Central (Cloud-Management) steuern. Hier gibt es Schnittstellen zu Azure AD und M365 auf anderer Ebene: Beispielsweise kann man die Firewall-Verwaltung mit Azure AD SSO absichern (Admin-Login via M365-Konto). Für den Datenverkehr selbst bietet Central insofern Vorteile, als man mehrere Firewalls zentral konfigurieren und z.B. konsistente Office-365-Regeln ausrollen kann. Denkbar ist auch die Anbindung an Microsoft Graph API für Logging und Reporting – so könnte man in Zukunft M365-Nutzungsanalysen in Sophos Central sehen. Ein weiterer Integrationspunkt ist Sophos CASB/Email Security: Sophos bietet z.B. Email Security, das direkt in O365 per API integriert (Mailflow-Regeln). Das tangiert die Firewall nur indirekt, zeigt aber, dass Sophos ein ganzheitliches Konzept für M365-Sicherheit verfolgt (Netzwerk + Cloud). An der Firewall selbst wichtig ist, dass man Azure AD als Auth-Server einbinden kann – so können etwa VPN-Nutzer sich mit ihren O365-Credentials authentifizieren oder eine Benutzeridentifizierung am WLAN/Firewall über SAML/OAuth gegen Azure AD erfolgen. Diese Identitätsintegration erleichtert die Verwaltung von Richtlinien (z.B. webfilter nach Gruppen) ohne separate On-Prem-Accounts.

API-gesteuerte Regelanpassung: Eine fortgeschrittene Möglichkeit ist es, die REST-API der Sophos Firewall zu nutzen, um Regeln dynamisch anzupassen. Beispielsweise könnte ein Skript wöchentlich die neuesten JSON-Daten von Microsoft (endpoints.office.com) abrufen und per API die entsprechenden Host-Objekte in der Firewall aktualisieren. Die XGS-API erlaubt das Hinzufügen, Ändern und Löschen von Objekten und Regeln programmatisch. Für größere Umgebungen mit DevOps-Ausrichtung kann dies sinnvoll sein, um die Firewall-Konfiguration as code zu behandeln. In den meisten Fällen wird jedoch die oben erwähnte vorgefertigte Lösung ausreichen, da Sophos hier bereits viel Arbeit abnimmt.

Praxisbeispiel – Automatisierter O365-Hostgroup Import: Ein Administrator berichtet, dass er mittels des bereitgestellten XML/TAR-Files von Sophos Community in wenigen Minuten alle relevanten Office-365-Netze in seiner XGS hatte. Die importierte Host Group deckte lückenlos alle öffentlichen IPs von Microsoft 365 ab. Danach konnte er in den Firewallregeln einfach diese Gruppe nutzen, anstatt einzelne IPs oder Wildcards einzutragen. In Kombination mit FQDN-Definitions (für Dienste, die nur über Domainnamen erreichbar sind) und den anwendungsbasierten Filtern war die Einrichtung damit erheblich vereinfacht. Dies verdeutlicht: Eine enge Integration – sprich das Verständnis der Firewall für M365-Adressen – bildet die Grundlage für alle Optimierungen.

5. Best Practices und typische Fallstricke

Abschließend sollen die wichtigsten Best Practices von Sophos und Microsoft zusammengefasst werden, um M365-Traffic optimal zu managen, sowie einige häufige Fehler, die es zu vermeiden gilt:

• Proxy vermeiden / Direktverbindungen bevorzugen: Microsoft betont, dass traditionelle Proxy- oder Tunnel-Lösungen den Office-365-Traffic ausbremsen und problematisch sein können. Der erste Ratschlag lautet oft, jegliche nicht notwendige Proxy-Station zwischen User und Microsoft-Cloud zu entfernen. Stattdessen sind direkte, lokale Verbindungen mit minimaler Inspektion anzustreben. Unternehmen sollten daher ihre Netzwerkarchitektur dahingehend überprüfen: Falls M365-Daten bislang z.B. über zentrale Web-Proxys oder VPN-Tunnel geschickt wurden, ist ein Umstieg auf lokales Breakout ratsam. Sophos XGS kann dabei als sicherer Direktgateway fungieren, der zwar grundlegende Sicherheitsfilter bietet, aber den Traffic nicht so stark verzögert wie ein mehrstufiger Proxy-Aufbau.
• Office-365-Traffic eindeutig identifizieren und behandeln: Netzwerkteams sollten M365-Flows klar abgrenzen können. Wie oben beschrieben, ist das Differenzieren des Office-Traffics der erste Schritt, um ihn speziell zu behandeln. Es empfiehlt sich, in der Firewall separate Regelwerke für M365 anzulegen – zum Beispiel eine dedizierte Regel ganz oben, die „Allow & Optimize Office 365“ implementiert (mit Quellen, Zielen, Diensten eingeschränkt auf M365). Diese Regel kann dann etwa keine Deep Scans haben und hohe Priorität genießen. Alles was dort nicht reinfällt, wird von nachrangigen allgemeinen Regeln erfasst. So verhindert man, dass Microsoft-Traffic im Wust des restlichen Internetverkehrs untergeht. Nutzen Sie die von Sophos bereitgestellten vordefinierten Ausnahmen und Kategorien, um nichts Wichtiges zu vergessen. (Beispielsweise die Web-Exception „Microsoft 365“, Application Category „Unified Communications“ für Teams/Skype etc.).
• Latenz und nächste PoP beachten: Da die Round-Trip-Time zur Microsoft-Cloud ein ausschlaggebender Faktor für Performance ist, sollte jeder unnötige Millisekunde vermieden werden. Best Practice ist, vom Client zum Microsoft Entry-Point unter 50 ms Latenz anzustreben (für Echtzeitdienste). Erreichen kann man das durch verteilte Internet-Ausgänge, Peering mit lokalen ISPs und möglichst kurze DNS- und Firewall-Processing-Zeiten. Die Sophos XGS mit FastPath hilft dabei, die interne Latenz durch die Firewall auf ein Minimum zu senken. Zudem kann sie beim Routing dafür sorgen, dass z.B. ein deutscher Standort auch wirklich das deutsche Microsoft-Rechenzentrum anspricht und nicht versehentlich über ein anderes Land geht (Stichwort: GeoDNS-Unterstützung durch lokalen DNS-Server).
• Sicherheitsausnahmen nur wo vertretbar: So wichtig Performance ist, komplett ungeschützt sollte man Office-365-Datenverkehr nicht lassen. Ein häufiger Fehler wäre es, großzügig „any any allow“ für alle Microsoft-Netze zu konfigurieren und sämtliche Inspektion abzuschalten. Zwar läuft dann alles schnell, aber man könnte Angriffe übersehen (z.B. wenn ein Benutzer auf einen Phishing-Link klickt, der über Office.com gehostet wird, würde die Firewall es durchwinken). Besser ist es, gezielte Ausnahmen einzurichten: Etwa TLS-Inspection für bekannte O365-Domains deaktivieren (um Zertifikatsprobleme und Breakage zu vermeiden), aber dennoch IPS und Application Control aktiviert lassen, damit auffällige Patterns (z.B. Exploits oder unbekannte Protokolle) erkannt werden. Microsoft selbst spricht davon, „intrusive network inspection“ für O365 zu eliminieren – damit sind vor allem SSL-Proxies und redundante Malware-Filter gemeint. Klassische Netzwerk-Firewall und IPS können und sollten weiterhin verwendet werden, da sie auf Paketebene arbeiten und die Latenz kaum beeinflussen. Sophos bietet hier mit IPS-Signaturen auch Schutz speziell für Microsoft-Dienste (z.B. Erkennung bekannter Exploits in Exchange-Protokollen).
• Kontinuierliche Aktualisierung der Endpunkte: Ein typischer Stolperstein ist es, die Microsoft-Endpoint-Listen nicht regelmäßig zu aktualisieren. Microsoft ändert gelegentlich IP-Adressen oder FQDNs, fügt neue hinzu (z.B. für neue Dienste) oder wechselt CDN-Anbieter. Wenn die Firewall-Regeln hier nicht Schritt halten, kommt es zu plötzlich auftretenden Verbindungsabbrüchen oder unerklärlichen Blockierungen. Daher unbedingt den in Abschnitt 4 beschriebenen Automatismus nutzen – sei es der Sophos Factory Workflow, ein eigenes Skript oder manuelles Importieren des regelmäßigen Updates aus der Community. Auch sollte man IPv6-Adressen nicht vergessen: Viele Office-365-Dienste unterstützen IPv6; wenn das eigene Netz IPv6 aktiviert hat, müssen die Regeln sowohl IPv4 als auch IPv6 abdecken. Im Sophos-Endpoint-Paket sind IPv6-Netze enthalten, diese sollte man ebenfalls einspielen.
• QoS nicht zu knapp bemessen: Bei der Priorisierung ist es wichtig, ausreichend Puffer zu lassen. Ein Fehler wäre, Teams-Traffic nur minimal etwas mehr Bandbreite zu geben, aber bei starker Last reicht es dann doch nicht. Besser ist es, großzügige Guarantees für M365 zu setzen – schließlich betrifft es geschäftskritische Kommunikation. Sophos erlaubt auch eine „Realtime Optimization“ Einstellung global (z.B. VoIP-Traffic begünstigen). Nutzen Sie diese Optionen, um z.B. Echtzeitverkehr strikt vor Bulktrafic zu priorisieren. Überwachen Sie zudem nach Implementierung die Leitenauslastung: Die XGS bietet Reporting, in dem man sehen kann, ob die QoS-Regeln greifen und wie viel Bandbreite z.B. für Teams verwendet wurde. Justieren Sie die Parameter nach, falls Meetings immer noch unterbrochen werden.
• Benutzererfahrung testen nach Änderungen: Jede Änderung an Firewall-Regeln (sei es Einführen von TLS-Inspection oder neuen Routing-Regeln) sollte mit Pilot-Usern getestet werden. Achten Sie auf Benutzer-Feedback, ob Outlook reibungslos funktioniert, ob OneDrive-Synchronisation schnell läuft und ob Teams-Calls stabil sind. Insbesondere TLS-Inspection kann versteckte Effekte haben – z.B. bei SMTP Auth (Outlook via smtp.office365.com auf Port 587). Es wurde berichtet, dass mit aktivierter SSL-Prüfung das Senden von Mails via SMTP bis zu 5 Minuten Verzögerung hatte. Solche Dinge entdeckt man nur durch Tests. Ggf. muss man zusätzliche Ausnahmen hinzufügen (im Beispiel war die Lösung, smtp.office365.com vom Scan auszunehmen). Also: Stetiges Fein-Tuning gehört zu den Best Practices, bis wirklich alle M365-Komponenten sauber laufen.

Zusammenfassend lässt sich sagen, dass durch beherzigung dieser Leitlinien – lokale Ausleitung, intelligente Firewall-Regeln ohne unnötige Hürden, gezielte Sicherheitsfilter und Priorisierung – ein Unternehmen die Nutzung von Microsoft 365 erheblich verbessern kann. Die Sophos XGS-Firewall bietet hierfür ein leistungsfähiges Werkzeugset, um Performance und Sicherheit in Einklang zu bringen. Wichtig ist, die Konfiguration ganzheitlich anzugehen: Netzwerk, Security und Microsoft-Empfehlungen greifen ineinander. Mit regelmäßiger Pflege (Updates der Regeln/Listen) und Monitoring schafft man eine robuste, schnelle Umgebung für alle M365-Anwendungen – vom E-Mail-Versand bis zur Videokonferenz.

Quellen: Sowohl die Sophos Knowledgebase als auch die Microsoft-Dokumentation bieten detaillierte Informationen zu diesem Thema. Insbesondere die Microsoft-365-Netzwerkprinzipien und die Empfehlungen der Sophos-Community (z.B. zum Anlegen von M365-Host-Gruppen oder Webfilter-Ausnahmen) sind hilfreich. Die genannten Best Practices stützen sich auf offizielle Leitfäden und Praxiserfahrungen aus Sophos-Foren. Unternehmen sollten diese Hinweise an die eigene Umgebung anpassen und kontinuierlich auf dem Laufenden bleiben, da sich sowohl Bedrohungslage als auch Cloud-Infrastruktur weiterentwickeln. Mit der richtigen Konfiguration wird die Sophos XGS jedoch zum Enabler, der schnellen und sicheren Zugang zu Microsoft 365 garantiert – ein entscheidender Faktor für die Produktivität moderner Unternehmen.

Weitere Beiträge zum Thema Sophos