Sophos Email: Architektur wählen und Onboarding planen

Bei Sophos Email fällt die wichtigste Entscheidung vor der ersten Domain: Sophos Mailflow oder Sophos Gateway. Beide Varianten werden in Sophos Fusion (ehemals Sophos Central) verwaltet, greifen aber an unterschiedlichen Stellen in den Mailfluss ein. Wenn man die Architektur früh festlegt, lassen sich Zuständigkeiten, Pilot, Umschaltung und Rückweg sauber planen.

Schnellentscheidung: Wenn man ausschliesslich Microsoft 365 verwendet und die vorhandenen MX-Einträge nicht umstellen will, prüft man zuerst Sophos Mailflow. Soll Sophos der vorgelagerte Mail-Gateway sein, benötigt man Kontrolle über die DNS- und MX-Routingstrecke. Das gilt auch, wenn man Google Workspace beziehungsweise einen lokalen Mailserver verwendet; in diesen Fällen plant man Sophos Gateway. Für dieselbe Domain konfiguriert man nie beide Verarbeitungsarten gleichzeitig.

Produktgrenze: Sophos Fusion statt Firewall-Mail-Proxy

Dieser Artikel behandelt Sophos Email in Sophos Fusion. Die lokale Mail Protection auf einer Sophos Firewall ist ein anderes Produkt- und Betriebsmodell. Deshalb überträgt man keine Firewall-Mail-Proxy-Regeln, Ausnahmen oder Menüpfade auf Sophos Email. Eine Ablösung der Firewall Mail Protection benötigt ein eigenes Migrationsprojekt mit getrenntem Routing- und Rollback-Plan.

Die Architektur auswählen

Sophos Mailflow für Microsoft 365

Sophos Mailflow integriert sich über Microsoft APIs sowie Exchange-Online-Connectors und Mailflow-Regeln in Microsoft 365. Nachrichten werden zwischen Microsoft 365 und Sophos zur Prüfung geroutet; eine MX-Umleitung und eine DNS-Änderung zur Domain-Verifizierung sind für dieses Modell nicht nötig. Die Domains verwaltet man in Sophos Fusion unter Products and Services > Email > M365 Mailflow Domains.

Mailflow passt, wenn Microsoft 365 das vorgelagerte System bleiben soll und eine Änderung des öffentlichen Mail-Routings unerwünscht ist. Vorab prüft man, ob das Abonnement für Microsoft 365 eingehende Connectors unterstützt und ob das verwendete Administratorkonto die nötigen Zustimmungen und Exchange-Online-Mailflow-Berechtigungen erteilen kann.

Die Betriebsgrenze ist wichtig: Microsoft verarbeitet Nachrichten weiterhin an seiner Front Door. Bestimmte Microsoft-Filter, insbesondere für besonders sicher eingestuftes Phishing, lassen sich durch Mailflow-Regeln nicht vollständig abschalten. Eine Nachricht kann daher in der Microsoft-Quarantäne landen, bevor sie in Sophos sichtbar wird. Bei Mailflow plant man die Kontrolle beider Quarantänen und den Microsoft Message Trace als zusätzlichen Prüfweg ein.

Sophos Gateway für Microsoft 365, Google Workspace und lokale Mailserver

Sophos Gateway ist der vorgeschaltete Secure Email Gateway. Der öffentliche MX-Eintrag zeigt auf Sophos; Sophos prüft eingehende Nachrichten und stellt sie anschliessend an Microsoft 365, Google Workspace oder einen lokalen Mailserver zu. Für ausgehende Prüfung führt der Mailserver den Versand über Sophos. Die Domains verwaltet man unter Products and Services > Email > Gateway Domains.

Gateway passt, wenn Sophos den ersten SMTP-Kontakt aus dem Internet übernehmen soll, wenn man eigene Routing- oder TLS-Entscheidungen benötigt oder wenn die Plattform nicht Microsoft 365 ist. Dafür benötigt man Zugriff auf DNS und MX sowie auf die Routing-Konfiguration des Mail-Providers oder Mailservers. Den MX-Wechsel führt man erst aus, wenn Domains, Ziele, Mailboxen und Richtlinien vorbereitet sind.

Die genauen Provider-Schritte für Microsoft 365, Google Workspace und lokale Mailserver gehören in die jeweiligen Einrichtungsanleitungen. In dieser Architekturentscheidung werden bewusst keine regionalen Hosts, IP-Adressen, Ports, Connector-Namen oder DNS-Werte vorweggenommen.

Voraussetzungen und Zuständigkeiten klären

Vor dem Pilot erfasst man mindestens:

• eine gültige Sophos-Email-Lizenz und administrativen Zugriff auf Sophos Fusion;
• Mailplattform, zu schützende Domains und gewünschte Architektur pro Domain;
• alle zu schützenden Mailboxen, Aliase, Verteilerlisten und öffentlichen Ordner;
• die verbindliche Quelle für Mailboxen, etwa Verzeichnissynchronisation oder gepflegter Import;
• Besitzer für DNS, Microsoft 365 oder Google Workspace, lokalen Mailserver und Sophos Fusion;
• fachliche Owner für Email Security, Data Control und Secure Message Policies;
• Anforderungen an Verschlüsselung, Aufbewahrung, Quarantäne und Berichte;
• Cutover-Zeitfenster, Abnahmekriterien, Eskalationsweg und entscheidungsbefugte Rollback-Kontakte.

Fehlende Empfängerobjekte sind kein Schönheitsfehler: Sophos Email benötigt den vollständigen Empfängerbestand, damit Nachrichten korrekt verarbeitet werden. Deshalb vergleicht man Aliase und Gruppen ebenso sorgfältig wie persönliche Mailboxen. Änderungen an synchronisierten Objekten nimmt man im führenden Verzeichnis vor, nicht als dauerhafte Korrektur in Sophos Fusion.

Onboarding in Phasen durchführen

1. Bestand und Mailpfad dokumentieren

Man zeichnet den heutigen eingehenden und ausgehenden Weg pro Domain auf. Dabei hält man fest, wo MX endet, welche Systeme direkt versenden, welche Weiterleitungen existieren und wer DNS, Provider-Regeln und Mailserver ändern darf. Pilot-, Produktions- und Sonderdomänen hält man getrennt.

2. Domain und Empfänger vorbereiten

Man legt die Domain im gewählten Modus an und bindet die Mailboxquelle an. Danach synchronisiert oder importiert man Mailboxen samt Aliasen, Verteilerlisten und öffentlichen Ordnern. Den Bestand kontrolliert man, bevor man Routing ändert oder Schutz breit aktiviert.

3. Richtlinien vor dem Cutover festlegen

Mindestens für Email Security, Data Control und bei Bedarf Secure Message definiert man Zuständigkeit und Zielgruppe. Man beginnt mit nachvollziehbaren Regeln und dokumentierten Ausnahmen. Über Quarantänebenachrichtigungen, Verschlüsselung und ausgehende Schutzanforderungen entscheidet man vor dem Produktivwechsel, nicht erst nach einer blockierten Geschäftsmail.

4. Mit einer begrenzten Gruppe pilotieren

Man wählt repräsentative interne und externe Testpartner sowie, falls die Architektur es erlaubt, eine klar begrenzte Pilotgruppe. Normale Nachrichten, Anhänge und Antworten prüft man in beide Richtungen. Der Pilot deckt auch einen Alias oder eine Verteilerliste ab. Bei Mailflow darf man eine Teilmenge von Mailboxen schützen; die genaue Gruppenzuweisung wird später in der dedizierten Mailflow-Anleitung beschrieben.

5. Kontrolliert produktiv schalten

Pro Domain aktiviert man nur eine Architektur. Bei Gateway ist die MX-Änderung der letzte Schritt, nachdem interne Ziele, ausgehender Weg, Empfänger und Policies bereit sind. Bei Mailflow müssen die von Sophos eingerichteten Connectors und Mailflow-Regeln in Microsoft 365 vollständig vorhanden und konfliktfrei sein. Parallele Routing-Änderungen friert man während der Abnahme ein.

Verhalten bei einer Serviceunterbrechung festlegen

Je nach Email-Konfiguration zeigt Account preferences entweder Selectively scan oder Enforce scan, niemals beide gleichzeitig. Bei einer seltenen Serviceunterbrechung stellt Selectively scan Nachrichten ohne Verzögerung zu und führt dabei nur wesentliche Scans aus. Enforce scan hält Nachrichten bis zur Wiederherstellung in der Warteschlange, damit alle Scans ausgeführt werden; dafür verzögert sich die Zustellung.

Vor dem Produktiv-Cutover dokumentiert man die gewählte Haltung zwischen Verfügbarkeit und vollständiger Prüfung, den verantwortlichen Owner und messbare Abnahmekriterien. Selectively scan priorisiert die Zustellung, nimmt aber in Kauf, dass nicht alle Scans laufen; Enforce scan priorisiert die vollständige Sicherheitsprüfung, nimmt aber eine Zustellverzögerung in Kauf.

Nach einer Unterbrechung prüft man selektiv gescannte Nachrichten in den Nachrichtendetails von Message History. Bei Enforce scan kontrolliert man Zustellverzögerung und Wiederabbau der Warteschlange anhand der üblichen Nachrichten- und Provider-Traces und bestätigt, dass der Rückstau zugestellt wurde und die vereinbarten Abnahmekriterien erfüllt sind.

Cutover und Rollback absichern

Ein Rückweg besteht nicht nur aus einem alten MX-Wert. Vor der Umschaltung erstellt und genehmigt man ein Rollback-Blatt mit:

• Ausgangswerten und Verantwortlichen für DNS, MX, Connectors, Regeln und Smart Hosts;
• Bedingung für den Abbruch, zum Beispiel nicht zustellbare externe Nachrichten oder eine Routing-Schleife;
• Reihenfolge, in der altes Routing wiederhergestellt und neues Routing deaktiviert wird;
• Kontrollnachrichten nach jedem Rückschritt;
• Ansprechpartnern für Sophos Fusion, Provider, DNS und internen Mailserver.

Auf Grundlage dieser Übersicht löscht man weder die Microsoft-/Sophos-Anwendung noch Connectors oder Mailflow-Regeln manuell. Sobald ein dokumentierter und freigegebener providerspezifischer Offboarding-Ablauf vorliegt, hält man zuerst den Ausgangszustand fest, führt ausschliesslich dessen autorisierte Änderungen aus und prüft nach jeder Änderung das Nachrichtenrouting. Bis dieses Verfahren etabliert ist, eskaliert man den Rückbau, statt zu improvisieren. Auch bei Gateway dient der oben beschriebene Rollback nur der Planung; die Ausführung richtet sich nach einem dokumentierten und freigegebenen providerspezifischen Ablauf.

Erfolg nachweisen

Domain- und Mailboxstatus

In M365 Mailflow Domains oder Gateway Domains prüft man, ob die erwartete Domain als geschützt angezeigt wird. Danach vergleicht man den Bestand der geschützten Mailboxen mit der Soll-Liste. Stichproben reichen nicht, wenn Aliase, Verteilerlisten oder öffentliche Ordner geschäftskritisch sind.

Eingehende und ausgehende Testnachrichten

Je Domain sendet man mindestens eine eingehende Nachricht von einem kontrollierten externen Konto und eine ausgehende Nachricht an dieses Konto. Man prüft Absender, Empfänger, Zeitpunkt und endgültige Zustellung und verfolgt beide Nachrichten in Message History. Bei Mailflow ergänzt man die Prüfung mit Microsoft Message Trace; bei Gateway kontrolliert man zusätzlich den Provider- oder Mailserver-Trace.

Wenn eine Nachricht nur auf einer Seite sichtbar ist, ändert man nicht sofort die Filterpolicy. Zuerst grenzt man ein, ob Domain- oder Mailboxstatus, Routing, Connector, DNS, Empfängerbestand oder Zustellung betroffen ist. So vermeidet man Sicherheitsausnahmen für ein reines Routingproblem.

Berichte und Quarantäne

Man öffnet Message History, erzeugt oder plant einen Email Report und prüft die Administrator-Quarantäne. Bei Mailflow gehört auch die Microsoft-Quarantäne in das Betriebsverfahren. Zudem legt man fest, wer Nachrichten freigeben, Fehlklassifizierungen melden und Trends in Berichten prüfen darf. Erst wenn Verlauf, Berichte und Quarantäne im Alltag einen Owner haben, ist das Onboarding betrieblich abgeschlossen.

Wenn die Abnahme fehlschlägt

• Domain oder Mailbox nicht geschützt: Man prüft Mailboxquelle, Synchronisationslauf, Domain-Zuordnung und Lizenz.
• Eingehend fehlt, ausgehend funktioniert: Man prüft den öffentlichen Mailpfad, MX beziehungsweise Mailflow-Regeln und Provider-Trace.
• Ausgehend fehlt, eingehend funktioniert: Man prüft ausgehende Route, Connector oder Smart Host.
• Nachricht nur bei Microsoft quarantäniert: Man prüft Microsoft Message Trace und Microsoft-Quarantäne und schliesst nicht aus Sophos Message History auf eine Zustellung.
• Doppelte Verarbeitung oder Schleife: Man kontrolliert sofort, ob Mailflow und Gateway oder alte und neue Connectors gleichzeitig aktiv sind, und löst falls nötig den freigegebenen Rollback aus.

Provider-spezifische Connector-, DNS-, Lizenz- und Verzeichnissynchronisationsfehler werden in eigenen Detailanleitungen behandelt. Dafür sammelt man Zeitstempel, Absender, Empfänger, Message-ID und die Ergebnisse beider Traces, statt unsichere Einstellungen auszuprobieren.