Sophos Firewall SPX E-Mail-Verschlüsselung einrichten

Mit Secure PDF Exchange, kurz SPX, wandelt Sophos Firewall eine ausgehende E-Mail samt Anhängen in eine passwortgeschützte PDF-Datei um. Der Empfänger braucht keinen eigenen Verschlüsselungsclient. Je nach gewähltem Passwortmodell erhält er ein einmaliges Passwort, verwendet ein gespeichertes Passwort oder registriert selbst eines.

Für einen verlässlichen Betrieb müssen vier Teile zusammenpassen: ein SPX-Template, ein eindeutiger Auslöser, ein sicherer Passwortweg und bei Bedarf das SPX Reply Portal. Danach werden ein positiver und ein negativer Mailflow getestet. Eine zugestellte PDF allein beweist weder, dass die richtige Policy ausgelöst hat, noch dass Passwortregistrierung und sichere Antwort funktionieren.

SPX in acht Schritten

1. Email-Protection-Lizenz, MTA-Mailflow, Modellunterstützung und Zertifikat prüfen.
2. Festlegen, ob eine geschützte Domain, ein Data-Control-Treffer oder der Absender die Verschlüsselung auslöst.
3. Unter Email > Encryption > SPX templates > Add ein eigenes Template erstellen.
4. Passworttyp, PDF-Verschlüsselung, Benachrichtigung und Reply Portal bewusst wählen.
5. Unter Email > Encryption > SPX portal settings FQDN, erlaubte Netze und Port absichern.
6. Das Template in der SMTP route and scan Policy oder als bewusstes Default-Template zuweisen.
7. Mit einem externen Testempfänger PDF, Passwortweg, Registrierung und Antwort prüfen.
8. Einen Negativtest ohne SPX-Trigger durchführen und Mail logs, MTA-Logs sowie Rollback dokumentieren.

⚠️ Ein leeres Feld Allowed networks bedeutet beim SPX Portal nicht „kein Zugriff“, sondern fällt auf Any zurück. Sophos empfiehlt für das Reply Portal zudem einen eigenen Port. Portal-FQDN, Zertifikat, erlaubte Quellen und Passwortweg müssen deshalb vor dem produktiven Test feststehen.

Wann SPX passt

SPX eignet sich, wenn externe Empfänger ohne eigenen Verschlüsselungsclient vertrauliche Inhalte als geschützte PDF erhalten sollen. Es kann sowohl im MTA Mode als auch im Legacy Mode eingesetzt werden. Dieser Ablauf verwendet den MTA Mode, weil sich Domain, Data Control und Routing dort nachvollziehbar in der SMTP-Policy verbinden lassen.

SPX ist keine Transportverschlüsselung zwischen Mailservern und auch keine durchgängige Ende-zu-Ende-Verschlüsselung zwischen zwei Mailclients. Die Firewall verarbeitet den Klartext, erzeugt die PDF und steuert Passwort beziehungsweise Registrierung. Die PDF kann danach ausserhalb der Firewall in Postfächern, Archiven oder Downloads weiterbestehen. Empfängerkreis, Aufbewahrung und Passwortübermittlung gehören daher zum Sicherheitsdesign.

Vorausgesetzt werden:

• eine gültige Email-Protection-Lizenz;
• ein bereits getesteter ausgehender Mailflow über Sophos Firewall;
• ein dokumentierter externer Testempfänger;
• ein vertrauenswürdiger FQDN und ein passendes Zertifikat für die verwendeten SPX-Portale;
• ein getrennter, sicherer Kanal für Passwörter, wenn sie nicht vom Empfänger registriert werden;
• ein Rückweg, mit dem sich Template- und Policy-Zuweisungen wieder entfernen lassen.

SPX ist laut aktueller Sophos-Hilfe auf XGS 87/87w nicht verfügbar. Der vollständige MTA Mode ist zusätzlich auf XGS 88/88w nicht verfügbar. Mailflow, Lizenz, Relay und Modellgrenzen erklärt Mail Protection im MTA Mode einrichten.

Trigger und Priorität festlegen

SPX kann aus drei Richtungen ausgelöst werden. Werden mehrere Wege konfiguriert, wendet Sophos Firewall im MTA Mode diese Reihenfolge an:

1. Geschützte Domain: Das unter Domains and routing target ausgewählte SPX-Template gilt für ausgehende Nachrichten der passenden geschützten Domain.
2. Data control list: Nur wenn auf Domain-Ebene kein SPX-Template gesetzt ist, kann ein Data-Control-Treffer das bei der Liste ausgewählte Template anwenden.
3. Absender-Trigger: Erst wenn weder Domain noch Data Control ein Template liefern, greift das unter Default SPX template vorgesehene Senderverfahren.

Eine Domain-Zuweisung ist breit und passt nur, wenn wirklich jede passende ausgehende Nachricht verschlüsselt werden soll. Data Control eignet sich für definierte Inhaltstypen, muss aber mit echten positiven und negativen Beispielen auf False Positives geprüft werden. Der Sender-Trigger gibt dem Absender die Entscheidung, setzt jedoch einen sauber dokumentierten Mailclient-Ablauf voraus.

Vor der Konfiguration wird pro Mailflow genau ein primärer Trigger festgelegt. Eine zweite Methode darf nicht unbemerkt eine andere übersteuern.

SPX-Template erstellen

Das Beispiel verwendet das Template Finance-SPX-Recipient. Der Name ist ein Dokumentationswert und wird an Zweck und Organisation angepasst.

1. Email > Encryption > SPX templates öffnen.
2. Add wählen.
3. Als Namen zum Beispiel Finance-SPX-Recipient eintragen.
4. Den Organisationsnamen für die Benachrichtigungen setzen.
5. Encryption standard und PDF page size entsprechend der eigenen Vorgabe wählen.
6. Unter Password type das geplante Passwortmodell auswählen.
7. Betreff, Nachrichtentext und Empfängerhinweise prüfen und bei Bedarf anpassen.
8. Bei benötigter sicherer Antwort Enable SPX reply portal aktivieren.
9. Include original body into reply nur aktivieren, wenn die ursprüngliche Nachricht in der Antwort erscheinen darf.
10. Speichern.

Passwortmodell bewusst wählen

Sophos Firewall bietet vier Modelle:

• Specified by sender: Der Absender setzt das Passwort. Die Firewall entfernt es vor dem Versand und speichert es nicht. Das Passwort muss über einen getrennten sicheren Kanal zum Empfänger gelangen.
• Generate one-time password for every email: Die Firewall erzeugt für jede Nachricht ein neues Passwort und sendet es an den Absender. Dieser übermittelt es separat an den Empfänger. Das Passwort wird nicht gespeichert.
• Generated and stored for recipient: Die Firewall erzeugt ein empfängerspezifisches Passwort, sendet es an den Absender und verwendet es bis zum Ablauf weiter.
• Specified by recipient: Ein noch nicht registrierter Empfänger erhält einen Registrierungslink, legt sein Passwort selbst fest und verwendet es bis zum Ablauf für weitere SPX-Nachrichten der Organisation.

Für ein wiederkehrendes Partnerverhältnis ist Specified by recipient häufig der verständlichste Ablauf. Für einen einzelnen besonders sensiblen Versand kann ein Einmalpasswort besser passen. Verschiedene gespeicherte Passwortmodelle für denselben Empfänger sollten nicht ungeplant gemischt werden, weil der Empfänger sonst je Nachricht das zugehörige Passwort erkennen muss.

Bei Specified by sender kann der Betreff das Muster [secure:<password>]<subject text> verwenden. Der Absender muss das Passwort danach getrennt übermitteln. Für Microsoft Outlook stellt Sophos einen Outlook Add-in unter Authentication > Client downloads bereit.

Die aktuelle Sophos-Hilfe verwendet für andere Mailclients zwei unterschiedliche Header-Schreibweisen: X-Sophos-SPXEncrypt: yes auf der Template-Seite und X-Sophos-SPX-Encrypt: yes in der allgemeinen Encryption-Seite. Diese Abweichung wird nicht als Copy-paste-Rezept behandelt. Vor einem produktiven Client-Rollout wird die tatsächlich funktionierende Schreibweise auf dem eingesetzten SFOS-Build geprüft. Wo möglich, sind Policy, Data Control oder der Sophos Outlook Add-in der besser nachvollziehbare Auslöser.

Benachrichtigung ohne neue Datenlücke gestalten

Für Benachrichtigungen stehen unter anderem diese Variablen zur Verfügung:

• ENVELOPE_TO
• PASSWORD
• ORGANIZATION_NAME
• SENDER
• REG_LINK

Einfache HTML-Formatierung und Links sind möglich. Texte müssen erklären, von wem die Nachricht stammt, wie das Passwort sicher bezogen wird und wie lange Registrierung beziehungsweise Antwort möglich sind. Zugangsdaten oder vertrauliche Mailinhalte gehören nicht zusätzlich in einen ungeschützten Benachrichtigungstext.

SPX-Portale absichern

Unter Email > Encryption > SPX portal settings werden Passwortregistrierung und Portalzugriff festgelegt:

1. Unter Hostname den FQDN eintragen, unter dem externe Empfänger das Portal tatsächlich erreichen.
2. Bei Allowed networks nur die benötigten Quellnetze setzen. Any ist nur sinnvoll, wenn beliebige externe Empfänger das Portal erreichen müssen und das Risiko bewusst akzeptiert ist.
3. Den Port dokumentieren. Das Password Registration Portal verwendet standardmässig TCP 8094.
4. Für das SPX Reply Portal einen eigenen Port verwenden.
5. Gültigkeitsdauer für unbenutzte Passwörter, sichere Antworten und Registrierungslinks festlegen.
6. Empfänger der SPX-Fehlerbenachrichtigungen eintragen.

Bleibt Allowed networks leer, verwendet SFOS Any, weil das SPX Reply Portal standardmässig in der WAN-Zone aktiv ist. Wird das Reply Portal nicht benötigt, beschreibt Sophos als Abschaltung eine unbenutzte vertrauenswürdige private Adresse, zum Beispiel 169.254.0.1, als einziges erlaubtes Netz. Dieser Dokumentationswert darf nicht einer produktiv genutzten Adresse entsprechen.

CAPTCHA ist am SPX Portal immer aktiv und lässt sich nicht deaktivieren. Die Grenzen anderer Portal-CAPTCHAs erklärt CAPTCHA auf Sophos Firewall bewusst steuern.

WebAdmin, User Portal, VPN Portal, Captive Portal und die beiden SPX-Portale verwenden dieselbe zentrale Zertifikatsauswahl. Ein Wechsel kann deshalb mehrere Dienste gleichzeitig betreffen. Zertifikat, SANs, Rückweg und echte Portal-URL werden nach Zertifikate auf Sophos Firewall verwalten geplant. Für einen öffentlichen Namen kann ein Let’s-Encrypt-Zertifikat auf Sophos Firewall passen.

Template mit der SMTP-Policy verbinden

Für MTA Mode wird das SPX-Template unter Email > Policies and exceptions in der passenden SMTP route and scan Policy ausgewählt.

Domain als Auslöser

Unter Domains and routing target wird das Template der geschützten Domain zugewiesen. Danach gilt es für die passenden ausgehenden Nachrichten. Eine breite Domain-Zuweisung wird zuerst mit einem Pilotabsender und einem externen Testempfänger geprüft.

Data Control als Auslöser

1. Unter Email > Data control list eine klar benannte Liste erstellen oder die bestehende Liste prüfen.
2. In der SMTP-route-and-scan-Policy Data protection aktivieren.
3. Der Data Control List das vorgesehene SPX-Template zuweisen.
4. Einen positiven Inhaltstest und einen ähnlichen negativen Test durchführen.

Ist bereits ein SPX-Template unter Domains and routing target gesetzt, hat dieses Vorrang vor dem Data-Control-Template. Ein Treffer der Data Control List beweist zudem nur den konfigurierten Inhaltsmatch. Ob die richtige Nachricht verschlüsselt wurde, muss im realen Mailflow geprüft werden.

Absender-Trigger verwenden

Unter Email > Encryption > SPX configuration wird ein Default SPX template ausgewählt. Es greift für senderseitig ausgelöste SPX-Verschlüsselung nur dann, wenn die SMTP-Policy nicht bereits ein Template auf Domain- oder Data-Control-Ebene liefert. None schaltet diesen Defaultpfad aus.

Verschlüsselten Mailflow abnehmen

Für die Abnahme werden Testzeit, Absender, Empfänger, Betreff und erwarteter Trigger notiert. Dann folgen mindestens diese Fälle:

1. Positivtest: Eine ausgehende Nachricht löst genau das vorgesehene SPX-Template aus.
2. Passworttest: Der Empfänger erhält Passwort oder Registrierungslink über den geplanten Weg und kann die PDF öffnen.
3. Inhaltstest: Betreff, Body und Anhänge sind in der PDF erwartungsgemäss vorhanden und lesbar.
4. Reply-Test: Wenn aktiviert, führt der Reply-Link zum erwarteten FQDN und eine Testantwort erreicht den ursprünglichen Absender.
5. Negativtest: Eine ähnliche Nachricht ohne Trigger wird nicht als SPX-PDF versendet.
6. Ablauftest: Registrierung, gespeichertes Passwort und Reply-Zeitraum verhalten sich nach der festgelegten Gültigkeit nachvollziehbar.
7. Zertifikatstest: Browser und externer Empfänger erhalten am Portal eine vollständige vertrauenswürdige Zertifikatskette für den verwendeten FQDN.

Für die erste Korrelation dienen Email > Mail logs, der Log Viewer und die MTA-Dateien smtpd_main.log, smtpd_error.log und smtpd_panic.log. Ein Fehlertext wird mit derselben Testmail und demselben Zeitpunkt abgeglichen. Zugriff und weitere Logdateien beschreibt Sophos Firewall Services und Logs.

In HA liegen Logs auf dem Node, der den Traffic verarbeitet hat. Nach einem kontrollierten Failover werden eine neue SPX-Mail, Passwortregistrierung und Reply separat geprüft. Eine bestehende Portal-Sitzung oder ein laufender Registrierungsprozess wird nicht als unterbrechungsfrei vorausgesetzt. Die HA-Grundlagen stehen unter Sophos Firewall HA-Cluster.

Fehler systematisch eingrenzen

Nachricht wird nicht verschlüsselt

Richtung, geschützte Domain, tatsächliche SMTP-route-and-scan-Policy und Triggerpriorität prüfen. Bei Data Control zusätzlich Data protection, Listenmatch und Template-Zuweisung kontrollieren. Beim Sender-Trigger muss ein Default-Template gesetzt sein und darf nicht durch ein Domain- oder Data-Control-Template übersteuert werden. Die zwei dokumentierten Header-Schreibweisen sind kein Grund, beide ungeprüft produktiv zu verteilen.

Registrierungslink oder Portal ist nicht erreichbar

FQDN, öffentliche DNS-Auflösung, Port, Zertifikat, Allowed networks und Gültigkeit des Links prüfen. Ein leerer Allowed-Networks-Wert wird als Any behandelt und ist daher kein sicherer Abschaltzustand. Erreicht der Client einen anderen Host oder ein anderes Portal, stimmen URL, NAT oder Zertifikatszuweisung nicht mit dem geplanten Pfad überein.

PDF lässt sich nicht öffnen

Passworttyp und konkrete Nachricht zuerst abgleichen. Bei Einmalpasswörtern gilt nur das Passwort dieser E-Mail. Bei gespeicherten beziehungsweise registrierten Passwörtern können Ablauf oder mehrere Passwortmodelle die Ursache sein. Nach einem SPX Password Reset muss der Absender das neue Passwort wieder sicher an den Empfänger übermitteln.

Sichere Antwort kommt nicht an

Im Template Enable SPX reply portal, Reply-Zeitraum, Portal-FQDN, Port, Zertifikat und erlaubte Quellen kontrollieren. Danach Mail logs und MTA-Logs für die konkrete Antwort prüfen. Das erfolgreiche Öffnen der PDF beweist nicht, dass der Rückkanal funktioniert.

DKIM-Prüfung schlägt nach SPX fehl

SPX verändert Body und Anhänge. Wird eine Nachricht vor dieser Änderung signiert, kann die Signatur beim Empfänger ungültig werden. Festlegen, ob interner Mailserver, Sophos Firewall oder ein späterer Gateway nach allen geplanten Änderungen signiert. Die Verarbeitungskette und ein externer Test gehören zusammen.

Sicher zurückrollen

1. Zuerst die konkrete SPX-Zuweisung aus Domains and routing target oder der Data Control List entfernen.
2. Falls verwendet, Default SPX template auf None setzen.
3. Einen ausgehenden Negativtest durchführen und prüfen, dass keine neue SPX-PDF erzeugt wird.
4. Reply- und Registration-Portal nur dann zurücknehmen, wenn keine andere aktive SPX-Policy darauf angewiesen ist.
5. Temporäre öffentliche Port-, DNS- oder Portal-Freigaben auf den dokumentierten Vorzustand setzen.
6. Template erst löschen, wenn keine Policy und kein laufender Betriebsablauf mehr darauf verweist.
7. Mail logs und MTA-Logs für den letzten verschlüsselten und den ersten unverschlüsselten Test sichern.

Vor Änderungen an produktiven Mail- und Portalpfaden wird ein aktuelles Sophos Firewall Backup erstellt. In Airgap-Umgebungen kann SPX zwar weiter funktionieren, externe DNS-, Zertifikats- und Portalabhängigkeiten müssen aber separat erreichbar sein. Die Produktgrenzen stehen unter SFOS-Funktionen ohne Internetzugriff.

Betriebscheckliste

• Lizenz, Modell, MTA-Mailflow und externer Empfänger sind geprüft.
• Trigger und Triggerpriorität sind dokumentiert.
• Passworttyp und sicherer Übermittlungskanal passen zum Anwendungsfall.
• Portal-FQDN, Zertifikat, Port und Allowed Networks sind eng geplant.
• Domain-, Data-Control- oder Default-Zuweisung ist eindeutig.
• Positiv-, Negativ-, Passwort-, PDF- und Reply-Test sind bestanden.
• Mail logs und MTA-Logs lassen sich zur Testmail korrelieren.
• HA-Failover und Node-lokale Logs sind im Betriebsablauf berücksichtigt.
• Owner, Ablaufzeiten, Review-Datum und Rollback sind dokumentiert.

FAQ