Sophos XGS Firewall in Microsoft-Umgebungen: Der Praxisleitfaden

Kompetenzbereich Sophos auf boddenberg.de 

Eine Firewall kauft man nicht, weil sie hübsch blinkt, sondern weil sie in der eigenen Umgebung funktionieren muss. Und die eigene Umgebung heißt in den meisten deutschen Unternehmen: Active Directory, Entra ID, Microsoft 365, Exchange, SharePoint, ein paar Azure-Workloads – und mittendrin eine Sophos XGS, die das alles absichern soll. Genau um diese Kombination geht es hier.

Dieser Leitfaden ist kein Datenblatt-Nacherzähler und keine Werbebroschüre. Er ist das, was ich meinen Kunden in Workshops an die Wand male – nur eben aufgeschrieben: Wie die XGS-Plattform tickt, welches Modell Sie wirklich brauchen, wie Sie TLS-Inspection einführen, ohne dass der Betriebsrat die Barrikaden hochzieht, und wo die Firewall mit Entra ID, Microsoft 365 und Azure zusammenspielt.

FAKTENKASTEN · Worum es hier geht Thema: Sophos XGS Firewall im Zusammenspiel mit Microsoft-Infrastrukturen (AD, Entra ID, Microsoft 365, Exchange, Azure). Zielgruppe: IT-Verantwortliche und Administratoren im Mittelstand und in Konzern-Standorten. Besonderheit: Beide Welten aus einer Hand – Firewall-Praxis plus rund 30 Jahre Microsoft-Enterprise-Erfahrung. Format: Praxisleitfaden mit Architektur-Skizzen, Sizing-Faustwerten, Compliance-Einordnung und FAQ.

 

Warum Sophos und Microsoft zusammen gedacht werden müssen

In vielen Projekten treffe ich auf dieselbe Konstellation: Das Systemhaus hat die Firewall verkauft und eingerichtet – sauber, nach Handbuch. Die interne IT betreibt die Microsoft-Landschaft – ebenfalls sauber, ebenfalls nach Handbuch. Nur reden die beiden Händbücher nicht miteinander. Das Ergebnis: Die Firewall kennt keine AD-Gruppen, Microsoft-365-Traffic quält sich durch die TLS-Inspection, Teams ruckelt, und die Ursachensuche wird zum Schwarzer-Peter-Spiel zwischen zwei Dienstleistern.

Dabei ist die XGS ein ausgesprochen Microsoft-freundliches Gerät – wenn man beide Seiten kennt. Benutzerbasierte Regeln über AD-Gruppen, Single Sign-on gegen Entra ID, sauberer Umgang mit den Microsoft-365-Endpunkten, IPsec nach Azure: Das ist alles vorgesehen. Man muss es nur richtig verdrahten. Und genau diese Verdrahtung ist mein Feld: Ich mache seit Jahren beides – Sophos-Firewalls und Microsoft-Infrastruktur – und muss deshalb nicht raten, was auf der jeweils anderen Seite passiert.

AUS DER BERATUNGSPRAXIS · Das klassische Zwei-Dienstleister-Problem Ein Kunde klagte über miserable Teams-Telefonie. Das Systemhaus tippte auf Microsoft, Microsoft-seitig war alles grün. Des Rätsels Lösung: Der komplette Teams-Medienverkehr lief durch die DPI-Engine, inklusive TLS-Inspection – entgegen den Microsoft-Konnektivitätsprinzipien. Zwei Ausnahmen für die Optimize-Endpunkte, ein SD-WAN-Routing für den lokalen Breakout – und die Telefonie war störungsfrei. Aufwand: unter einem Tag. Vorher gesucht: mehrere Wochen.

 

Die XGS-Plattform verstehen: Xstream, FastPath und DPI

Das Marketing-Wort der XGS-Serie heißt Xstream. Dahinter steckt eine erfreulich handfeste Idee: Nicht jedes Paket verdient dieselbe Aufmerksamkeit. Traffic, der bereits klassifiziert und als unkritisch eingestuft ist, wird per Hardware-Beschleunigung (NPU) am Hauptprozessor vorbeigeleitet – der sogenannte FastPath. Alles, was Prüfung braucht, läuft durch die DPI-Engine: ein einziger Scan-Durchlauf für IPS, Virenschutz, Webfilter und Applikationskontrolle statt fünf Engines hintereinander.

Skizze 1: Der Weg eines Pakets durch die XGS – FastPath für Vertrautes, DPI für alles Prüfwürdige.

Für die Praxis bedeutet das zweierlei. Erstens: Die Performance-Angaben der Datenblätter beziehen sich auf Idealbedingungen – sobald TLS-Inspection und IPS ernsthaft arbeiten, relativiert sich das Zahlenwerk deutlich. Zweitens: Die Architektur belohnt saubere Konfiguration. Wer seine Regeln so baut, dass unkritischer Massenverkehr (etwa Backup-Traffic zwischen bekannten Servern) den FastPath nehmen darf, holt spürbar Leistung heraus.

PRAXISTIPP · Erst denken, dann scannen Nicht jede Regel braucht das volle Programm. Interner Backup- und Replikationsverkehr zwischen bekannten Servern muss nicht durch Webfilter und Virenscan – das kostet nur Durchsatz und bringt nichts. Umgekehrt gilt: Überall dort, wo Benutzer ins Internet gehen, gibt es keine Ausrede für abgeschaltete Prüfung.

 

Sizing: Welche XGS für wie viele User?

Die häufigste Frage überhaupt – und die, bei der am meisten schiefgeht. Der Klassiker: Es wird nach Datenblatt-Durchsatz gekauft, dann werden TLS-Inspection und IPS aktiviert, und plötzlich ist die stolze Firewall der Flaschenhals der Internetanbindung. Die Datenblattwerte sind Laborwerte; im echten Leben zählen die Werte mit aktivierten Schutzfunktionen.

Skizze 2: Sizing-Faustwerte für typische Unternehmensgrößen – mit aktivierter TLS-Inspection und IPS.

Die Treppe oben ist bewusst eine Faustregel, kein Naturgesetz. Wer viel Server-Publishing betreibt, eine große DMZ fährt oder mehrere Standorte terminiert, rutscht eine Stufe nach oben. Wer primär Microsoft 365 nutzt und den Optimize-Traffic sauber am Scan vorbeiroutet, hat mehr Luft als gedacht. Entscheidend sind drei Fragen: Wie viel Traffic muss wirklich entschlüsselt werden? Wie viele gleichzeitige VPN-Tunnel und Remote-User? Und wie sieht die Wachstumsplanung der nächsten fünf Jahre aus – denn so lange lebt so eine Box in der Regel.

Kriterium	Wirkung aufs Sizing	Typischer Fehler
TLS-Inspection-Anteil	Der größte einzelne Performance-Faktor	Nach Roh-Durchsatz gekauft, nach Aktivierung gebremst
Server-Publishing / WAF	Zusätzliche Dauerlast, auch nachts	DMZ-Last im Sizing schlicht vergessen
VPN & Remote-User	Tunnel-Terminierung kostet CPU	Homeoffice-Spitzen nicht eingeplant
Standort-Terminierung	Zentrale trägt die Last aller Filialen	Zentrale und Filiale gleich dimensioniert
Laufzeit ~5 Jahre	Wachstum + steigender TLS-Anteil	Auf Kante gekauft, nach 2 Jahren zu klein

 

VORSICHT · Der teuerste Sparfuchs Eine zu kleine XGS ist die teuerste Variante von allen: Erst leidet die Performance, dann werden „zur Entlastung“ Schutzfunktionen abgeschaltet – und am Ende steht ein vorgezogener Neukauf plus ein Sicherheitsniveau, für das man die Box gar nicht gebraucht hätte. Eine Nummer größer kostet beim Kauf ein paar hundert Euro mehr. Abgeschaltete TLS-Inspection kann Sie den ganzen Laden kosten.

 

Lizenzierung ohne Kopfschmerzen

Die gute Nachricht: Sophos hat die Lizenzierung mit dem Xstream-Protection-Bundle deutlich entwirrt. Die Zeiten, in denen man sich aus einem halben Dutzend Einzelmodulen etwas zusammenstellen musste, sind weitgehend vorbei. Für die allermeisten Unternehmen ist das Bundle die richtige Wahl – es enthält Netzwerkschutz, Webschutz, Zero-Day Protection, zentrales Management über Sophos Central und den erweiterten Support.

Wichtiger als die Modulfrage ist das Verständnis, was ohne Lizenz übrig bleibt: eine solide Stateful-Firewall mit VPN – aber ohne IPS, ohne Webfilter, ohne ATP, ohne Sandboxing. Eine XGS mit abgelaufener Lizenz ist also kein Sicherheitsprodukt mehr, sondern ein besserer Router. Deshalb gehört das Lizenz-Ablaufdatum in jedes Monitoring – und zwar mit Vorwarnzeit, nicht als Überraschung am Montagmorgen.

FAKTENKASTEN · Lizenzierung XGS – das Wesentliche Xstream Protection: das übliche Rundum-Bundle (Netzwerk-, Web-, Zero-Day-Schutz, Central-Management, Enhanced Support). Ohne aktive Lizenz: Basis-Firewall und VPN funktionieren weiter – sämtliche Schutz-Engines nicht. Laufzeiten: typischerweise 1, 3 oder 5 Jahre; längere Laufzeit senkt den Jahrespreis spürbar. Hardware und Lizenz getrennt kalkulieren – die Lizenz macht über die Laufzeit oft mehr aus als das Blech. Virtuelle XGS (VMware, Hyper-V, Azure) werden nach Kernen/Ressourcen lizenziert, nicht nach Appliance-Modell.

 

Segmentierung: Das Zonenmodell richtig nutzen

Das flache Netz ist der beste Freund jedes Angreifers: einmal drin, überall drin. Ransomware-Vorfälle der letzten Jahre erzählen fast immer dieselbe Geschichte – ein kompromittierter Client, und von dort ungehindert weiter zu Servern, Backups und Domain Controllern. Die XGS ist das Werkzeug, mit dem Sie diese Geschichte umschreiben: Zonen definieren, VLANs sauber trennen, und jeder Übergang läuft über eine explizite Regel.

Skizze 3: Die XGS als Drehkreuz – Clients, Server, DMZ, OT und Gastnetz sauber getrennt.

Der Punkt, an dem Segmentierungsprojekte scheitern, ist übrigens selten die Technik – es ist die Bestandsaufnahme. Wer weiß schon auswendig, welcher Client mit welchem Server auf welchem Port spricht? Hier hilft ein pragmatisches Vorgehen: Zonen anlegen, Regeln zunächst beobachtend (mit Logging) fahren, aus den Logs die tatsächlichen Kommunikationsbeziehungen ablesen – und dann schrittweise scharf schalten. Big Bang funktioniert hier nie, und wer es versucht, telefoniert eine Woche lang mit wütenden Fachabteilungen.

PRAXISTIPP · Die Microsoft-Perspektive mitdenken Active Directory braucht eine erstaunlich lange Portliste (Kerberos, LDAP, RPC, SMB, DNS – inklusive dynamischer RPC-Ports). Wer die Server-Zone abriegelt, ohne diese Abhängigkeiten zu kennen, legt die Anmeldung lahm. Genau hier zahlt sich die Kombination aus: Ich kenne beide Seiten – die Firewall-Regeln und das, was AD, Exchange und SQL Server tatsächlich zum Leben brauchen.

 

Multi-Site: VPN, SD-WAN und der Weg nach Azure

Sobald mehr als ein Standort im Spiel ist, wird die Firewall zur Verkehrszentrale. Die XGS bietet dafür den kompletten Baukasten: klassisches IPsec zwischen Standorten, RED-Tunnel für Kleinstandorte ohne eigene IT, SSL-VPN und ZTNA für Remote-User – und SD-WAN-Routing, um mehrere Uplinks intelligent zu nutzen. Dazu kommt heute fast immer ein vierter Standort, der in keinem Gebäudeplan auftaucht: das Azure vNet.

Skizze 4: Zentrale, Niederlassungen und Azure als ein Verbund – mit lokalem Microsoft-365-Breakout.

Der häufigste Planungsfehler in Multi-Site-Umgebungen: aller Internetverkehr der Filialen wird durch die Zentrale geschleift – auch der zu Microsoft 365. Das war in der On-Premises-Welt eine gute Idee, heute ist es Gift: Microsoft empfiehlt ausdrücklich den lokalen Breakout für die Optimize-Endpunkte, und Teams-Telefonie quittiert Umwege über die Zentrale mit Latenz und Gesprächsabbrüchen. Die richtige Architektur: interner Verkehr durch die Tunnel, Microsoft-365-Verkehr direkt vor Ort ins Internet – die XGS kann genau diese Unterscheidung per SD-WAN-Routing treffen.

AUS DER BERATUNGSPRAXIS · Azure ist ein Standort wie jeder andere – fast Für die Anbindung ans Azure vNet gibt es zwei Wege: IPsec von der XGS zum Azure VPN Gateway (der Normalfall) oder eine XGS als VM direkt im vNet (wenn dort die volle Firewall-Funktionalität gebraucht wird, etwa als Hub in einer Hub-Spoke-Architektur). In der Praxis scheitern Azure-Tunnel selten an der XGS – sondern an den Details auf Azure-Seite: Gateway-SKU, BGP ja/nein, überlappende Adressräume. Auch hier gilt: Wer beide Konsolen lesen kann, ist schneller fertig.

 

TLS-Inspection: Technik, Ausnahmen – und der Betriebsrat

Hier trennt sich die Spreu vom Weizen. Weit über 90 Prozent des Web-Traffics sind heute verschlüsselt – eine Firewall, die TLS nicht aufmacht, prüft nur noch Briefumschläge und lobt sich dafür, dass keine verdächtigen Briefmarken dabei waren. Malware, Phishing-Nachladungen, Command-and-Control-Verkehr: alles verschlüsselt. Wer IPS und Virenschutz lizenziert, aber TLS-Inspection scheut, bezahlt für Wächter, die vor verschlossenen Türen stehen.

Skizze 5: Entschlüsseln oder nicht? Bypass-Kategorien, Microsoft-365-Sonderfall und die organisatorische Seite.

Gleichzeitig ist TLS-Inspection kein Schalter, den man freitags um 16 Uhr umlegt. Es braucht eine saubere Zertifikatsverteilung (die Inspection-CA per GPO oder Intune auf alle Clients), durchdachte Bypass-Kategorien (Banking, Gesundheit, Behörden – aus Datenschutz- und Vertrauensgründen) und die Microsoft-365-Ausnahmen nach den offiziellen Konnektivitätsprinzipien. Und es braucht – das wird technisch orientierten Kollegen ungern erzählt – den Betriebsrat: Die Inspektion von Mitarbeiter-Traffic ist mitbestimmungsrelevant. Eine saubere Betriebsvereinbarung vorab erspart Ihnen das Projekt-Aus in Monat drei.

FAKTENKASTEN · TLS-Inspection einführen – die Reihenfolge 1. Betriebsvereinbarung und Bypass-Konzept klären (Betriebsrat, Datenschutzbeauftragter). 2. Inspection-CA erzeugen und per GPO/Intune an alle Clients verteilen – vor der Aktivierung. 3. Microsoft-365-Optimize-Endpunkte und sensible Kategorien vom Scan ausnehmen. 4. Pilotgruppe fahren, Fehlerbilder sammeln (Apps mit Certificate Pinning!), Ausnahmen dokumentieren. 5. Schrittweiser Rollout – nicht Big Bang, nicht freitags.

 

VORSICHT · Certificate Pinning – der Spaßverderber Manche Anwendungen (Banking-Apps, einzelne Fachanwendungen, diverse Updater) akzeptieren grundsätzlich kein aufgebrochenes TLS – sie erwarten exakt ihr eigenes Zertifikat. Symptom: Die App verweigert kommentarlos den Dienst. Solche Kandidaten gehören auf eine gepflegte, dokumentierte Ausnahmeliste – nicht in eine Sammelausnahme „ganzes Internet“, die nach drei Monaten Frust entsteht und die ganze Inspection entwertet.

 

Reverse Proxy und WAF: Interne Webdienste sicher veröffentlichen

Fast jedes Unternehmen hat Webdienste, die von außen erreichbar sein müssen: Outlook Web App, ein Intranet, der Webclient der Fachanwendung, RD Web Access. Der bequeme Weg ist ein simples Port-Forwarding – und genau das ist der Weg, den ich in Sicherheitsanalysen am häufigsten bemängele. Ein nacktes Port-Forwarding stellt den internen Server ungefiltert ins Internet: jeder Scanner, jeder Exploit-Versuch, jeder Passwort-Sprayer landet direkt auf dem IIS.

Skizze 6: Die XGS als Web Application Firewall – nur saubere, authentifizierte Anfragen erreichen die internen Systeme.

Die XGS bringt die bessere Alternative bereits mit: den Webserver-Schutz als Reverse Proxy mit WAF-Funktionen. TLS wird an der Firewall terminiert, Anfragen laufen durch Schutzregeln gegen die üblichen Angriffsmuster, auf Wunsch schaltet sich eine Vorab-Authentifizierung davor – erst wer sich ausweist, sieht überhaupt den dahinterliegenden Dienst. Kombiniert mit Geo-Blocking (warum soll das Intranet aus Übersee erreichbar sein?) sinkt die Angriffsfläche dramatisch – mit Bordmitteln, die Lizenz ist ohnehin da.

PRAXISTIPP · Exchange-Publishing mit Augenmaß Exchange-Dienste (OWA, ActiveSync, EWS, Autodiscover) haben unterschiedliche Anforderungen – eine pauschale Regel für alles führt entweder zu Störungen oder zu Löchern. Pro Pfad eine passende Regel, dazu Vorab-Authentifizierung wo möglich. Und ehrlich prüfen: Muss dieser Dienst überhaupt noch veröffentlicht werden, oder ist der Zugriff längst über Microsoft 365 abgelöst?

 

IPS, ATP und Zero-Day-Schutz richtig scharf stellen

Das Intrusion Prevention System ist der Klassiker unter den vernachlässigten Funktionen: aktiviert ist es fast immer, sinnvoll konfiguriert selten. Die Standardrichtlinien sind bewusst breit angelegt – wer sie unverändert auf allen Regeln fährt, verschenkt Performance und erzeugt Alarmrauschen, in dem der eine relevante Treffer untergeht. Die Kunst liegt im Zuschneiden: Auf einer Regel Richtung Windows-Server-Zone gehören Windows-relevante Signaturen scharf geschaltet – Exploits gegen Unix-Mailserver dürfen dort getrost ignoriert werden.

• IPS-Richtlinien pro Regel zuschneiden: Signaturen passend zur Zielzone (Windows-Server, Clients, DMZ) statt Einheitsbrei überall.
• ATP (Advanced Threat Protection) konsequent aktiv lassen: Sie erkennt Command-and-Control-Kommunikation bereits infizierter Geräte – das Frühwarnsystem schlechthin.
• Zero-Day Protection nutzen: Verdächtige Dateien wandern in die Cloud-Analyse (statische und dynamische Analyse mit ML), bevor sie den Client erreichen.
• Alarme mit Empfänger versehen: Ein IPS, dessen Meldungen niemand liest, ist Dekoration. Wenige, gut definierte Alarme schlagen hundert ungelesene Reports.

Und weil die Frage in jedem Workshop kommt: Ja, Sie brauchen IPS auf der Firewall auch dann, wenn auf den Endpunkten Defender oder ein anderes EDR läuft. Die Firewall sieht Dinge, die der Endpunkt nicht sieht – etwa Angriffe auf Geräte ohne Agent (Drucker, OT, Appliances) und laterale Bewegungen zwischen den Zonen. Netzwerk- und Endpunktschutz sind Kollegen, keine Konkurrenten.

 

Sophos × Microsoft: Entra ID, Microsoft 365, Azure und Defender

Jetzt zum Kern dieses Kompetenzbereichs – dem Teil, den reine Firewall-Dienstleister meist links liegen lassen und reine Microsoft-Häuser gar nicht erst anfassen. Die XGS hat eine ganze Reihe von Andockpunkten an die Microsoft-Welt, und jeder einzelne davon entscheidet mit darüber, ob die Firewall im Alltag hilft oder nervt.

Skizze 7: Die Integrationspunkte zwischen XGS und Microsoft-Stack – Identität, M365-Traffic, Azure, Endpoint.

Die Identitätsseite zuerst: Firewall-Regeln auf Basis von AD-Gruppen („die Buchhaltung darf, das Lager nicht“) sind das, was Fachabteilungen tatsächlich verstehen – dafür braucht es eine saubere Verzeichnisanbindung und transparente Authentifizierung. Für Admin- und User-Portal lässt sich Single Sign-on gegen Entra ID einrichten, inklusive der dort hinterlegten MFA-Richtlinien. Der Effekt: kein separates Passwort-Silo auf der Firewall, Offboarding wirkt sofort auch dort.

Die Traffic-Seite: Microsoft veröffentlicht seine Endpunkte in Kategorien – und die Kategorie Optimize (unter anderem Teams-Medienverkehr und Exchange Online) gehört am Scan vorbei direkt ins Internet. Die XGS kann diese Unterscheidung abbilden; man muss es nur konfigurieren und aktuell halten. Die Azure-Seite haben wir im Multi-Site-Kapitel behandelt. Bleibt Defender und Intune: Hier geht es weniger um Integration als um Rollenklarheit – wer meldet was, wohin fließen die Logs, und wer verteilt eigentlich das Inspection-CA-Zertifikat? (Antwort: Intune, und zwar bevor die Inspection scharf geht.)

FAKTENKASTEN · Sophos × Microsoft – die Andockpunkte Identität: benutzerbasierte Firewall-Regeln über AD-Gruppen; SSO gegen Entra ID für Portale und VPN. Microsoft 365: Endpunkt-Kategorien respektieren – Optimize-Traffic ohne TLS-Inspection, lokaler Breakout je Standort. Azure: IPsec zum VPN Gateway oder XGS-VM im vNet; Hub-Spoke-Absicherung möglich. PKI/AD CS: Zertifikate für Portale, VPN und Inspection aus der eigenen CA statt selbstsignierter Provisorien. Endpoint: Defender/EDR und Firewall als komplementäre Schichten – klare Zuständigkeiten statt Doppelarbeit.

 

Compliance: NIS2, DSGVO, ISO 27001 und TISAX

Firewalls werden gern rein technisch diskutiert – dabei ist die XGS in jedem Compliance-Rahmenwerk ein Hauptdarsteller. NIS2 verlangt Risikomanagement und technische Maßnahmen nach Stand der Technik: Segmentierung, Angriffs­erkennung, Verfügbarkeit – alles Themen, die auf dieser Box zusammenlaufen. Die DSGVO wiederum schaut von der anderen Seite auf dasselbe Gerät: Firewall-Logs mit IP-Adressen und Benutzernamen sind personenbezogene Daten, TLS-Inspection berührt das Fernmeldegeheimnis – hier braucht es Aufbewahrungskonzepte und Betriebsvereinbarungen statt Bauchgefühl.

Skizze 8: Was die XGS zu NIS2, DSGVO und ISO 27001/TISAX beiträgt – und was organisatorisch dazugehört.

Für ISO-27001- und TISAX-Kandidaten gilt: Der Auditor will nicht nur sehen, dass eine Firewall existiert – er will das dokumentierte Regelwerk, den Review-Prozess und die Change-Historie sehen. Wer seine XGS-Konfiguration nur im Kopf des einen Kollegen dokumentiert hat, bekommt spätestens hier ein Problem. Die gute Nachricht: Mit sauberer Regel-Benennung, Kommentaren und regelmäßigen Reports lässt sich die Nachweisbarkeit weitgehend aus dem laufenden Betrieb heraus erzeugen, statt vor jedem Audit eine Doku-Hauruck-Aktion zu starten.

VORSICHT · Logs: zu viel ist genauso falsch wie zu wenig „Wir loggen alles, für immer“ klingt nach Sicherheit, ist aber ein DSGVO-Problem: Firewall-Logs sind personenbezogen und brauchen definierte Aufbewahrungsfristen und Zugriffsregeln. „Wir loggen fast nichts“ ist das NIS2-Problem: Ohne verwertbare Logs keine Vorfallsanalyse und keine Meldung binnen Frist. Die Wahrheit liegt in einem dokumentierten Logging-Konzept – was, wie lange, wer darf ran.

 

Betrieb: Firmware, Backup, Monitoring – das unspektakuläre Fundament

Die meisten Firewall-Notfälle, die auf meinem Tisch landen, haben keine spektakuläre Ursache. Es sind: eine Firmware, die drei Jahre niemand angefasst hat (inklusive der längst geschlossenen Sicherheitslücken); ein Konfigurations-Backup, das es nicht gibt – was man beim Hardware-Defekt dann sehr plötzlich merkt; und ein HA-Cluster, dessen Failover seit der Einrichtung nie getestet wurde und der im Ernstfall genau das tut, was ungetestete Dinge tun.

• Firmware-Strategie: geplante Wartungsfenster statt Panik-Updates nach Security-Advisories. Release Notes lesen – nicht jede neue Version muss sofort sein, keine darf jahrelang warten.
• Konfigurations-Backups: automatisiert, versioniert, und vor jeder Änderung ein zusätzlicher Stand. Die fünf Minuten sind die beste Versicherung im Portfolio.
• HA und Failover: einmal jährlich kontrolliert testen. Ein Failover, der nur auf dem Papier funktioniert, ist keiner.
• Monitoring: Lizenzablauf, Tunnel-Status, CPU unter Last, Speicherfüllstand der Logs – wenige, richtige Messpunkte mit echten Empfängern.
• Regel-Reviews: halbjährlich entrümpeln. Jede vergessene „temporäre“ Ausnahme von 2023 ist ein offenes Fenster.

 

FAQ: Häufige Fragen zur Sophos XGS in Microsoft-Umgebungen

Welche Sophos XGS ist die richtige für mein Unternehmen?

Als Faustwert mit aktivierten Schutzfunktionen: XGS 108/118 bis etwa 25 User, XGS 128/138 für den klassischen Mittelstand bis 75 User, XGS 2100/2300 für 75 bis 300 User, darüber die 3000er- und 4000er-Serie. Entscheidend sind TLS-Inspection-Anteil, Server-Publishing, VPN-Last und fünf Jahre Wachstum – im Zweifel eine Nummer größer.

Reicht die Firewall, oder brauche ich zusätzlich Endpoint-Schutz wie Microsoft Defender?

Beides – es sind komplementäre Schichten. Die Firewall sieht Netzwerkverkehr, Zonenübergänge und Geräte ohne Agent (Drucker, OT, Appliances); der Endpoint-Schutz sieht Prozesse und Dateien auf dem Gerät. Wichtig ist Rollenklarheit statt Doppelarbeit – etwa bei Logs, Alarmen und Ausnahmen.

Muss Microsoft-365-Traffic durch die TLS-Inspection?

Nein – im Gegenteil. Microsoft empfiehlt in seinen Konnektivitätsprinzipien, die Optimize-Endpunkte (unter anderem Teams-Medienverkehr und Exchange Online) von Inspection und Proxy auszunehmen und lokal ins Internet auszuleiten. Wer das ignoriert, bezahlt mit Teams-Störungen und Performance-Problemen.

Brauche ich für TLS-Inspection wirklich den Betriebsrat?

In aller Regel ja. Die Inspektion von Mitarbeiter-Datenverkehr ist mitbestimmungsrelevant und berührt zudem die DSGVO. Eine Betriebsvereinbarung mit klaren Bypass-Kategorien (Banking, Gesundheit, Behörden) vorab kostet wenig Zeit – ein gestopptes Projekt in Monat drei kostet deutlich mehr.

Kann die XGS Benutzer aus dem Active Directory in Firewall-Regeln verwenden?

Ja – das ist einer der größten Praxisvorteile. Über die Verzeichnisanbindung lassen sich Regeln auf AD-Gruppen stützen („Vertrieb darf, Produktion nicht“). Voraussetzung ist eine saubere, transparente Benutzer-Authentifizierung – genau die Stelle, an der Firewall- und Microsoft-Wissen zusammenkommen müssen.

Wie verbinde ich die XGS mit Azure?

Der Normalfall ist ein IPsec-Tunnel von der XGS zum Azure VPN Gateway – damit wird das vNet ein Standort wie jeder andere. Für Hub-Spoke-Architekturen oder volle Firewall-Funktionen in der Cloud kann alternativ eine XGS als VM direkt im vNet laufen. Die Stolpersteine liegen meist auf Azure-Seite: Gateway-SKU, BGP, Adressräume.

Was passiert, wenn die Lizenz abläuft?

Die XGS fällt auf Basis-Firewall und VPN zurück – IPS, Webfilter, ATP, Zero-Day-Schutz und Sandboxing stellen die Arbeit ein. Sie merken es nicht sofort, und genau das ist die Gefahr. Das Lizenz-Ablaufdatum gehört deshalb mit ordentlicher Vorwarnzeit ins Monitoring.

Ist die WAF der XGS ein vollwertiger Ersatz für ein Port-Forwarding?

Sie ist deutlich mehr als das: TLS-Terminierung, Schutzregeln gegen gängige Web-Angriffe, Vorab-Authentifizierung und Geo-Blocking – statt eines nackten Durchreichens an den internen Server. Für OWA, Intranet, Fachanwendungen und RD Web Access ist sie das Mittel der Wahl; ein blankes Port-Forwarding auf einen IIS sollte 2026 niemand mehr betreiben.

Wir haben ein Systemhaus für die Firewall und eine interne IT für Microsoft – wofür dann noch Sie?

Genau für die Schnittstelle. Die typischen Dauerbaustellen – Teams-Qualität, AD-Anbindung, TLS-Ausnahmen, Azure-Tunnel – liegen exakt zwischen beiden Zuständigkeiten. Ich übernehme keine Betriebsverträge und ersetze niemanden; ich sorge dafür, dass Architektur und Verdrahtung stimmen und beide Seiten mit klaren Vorgaben arbeiten können.

Multi-Site: RED-Gerät oder richtige XGS in der Filiale?

Kommt auf die Filiale an. Ein RED-Gerät ist ideal für Kleinstandorte ohne lokale Server und ohne eigene IT – Tunnel einstecken, fertig. Sobald ein Standort lokale Server, lokalen Internet-Breakout (Stichwort Microsoft 365) oder eigene Sicherheitsanforderungen hat, gehört eine eigene XGS hin, zentral verwaltet über Sophos Central.

Was bringt die XGS für NIS2?

Sie deckt zentrale technische Anforderungen ab: Segmentierung, Angriffserkennung (IPS/ATP), Verfügbarkeit über HA und SD-WAN-Failover sowie die Log-Basis für Meldepflichten. NIS2 erledigt sich damit nicht von selbst – aber ohne sauber betriebene Firewall fehlt dem Risikomanagement schlicht das Fundament.

Wir haben die XGS schon – lohnt sich eine Überprüfung der Konfiguration?

Fast immer. Die typischen Befunde nach ein paar Jahren Betrieb: TLS-Inspection nie aktiviert oder per Sammelausnahme entwertet, IPS im Einheitsmodus, vergessene „temporäre“ Regeln, kein getesteter Failover, M365-Ausnahmen veraltet. Ein fokussierter Review deckt das in wenigen Tagen auf – inklusive priorisierter Maßnahmenliste.