Sophos Email: Portalverschlüsselung, Branding und Rückruf einrichten

Portal Encryption hält eine verschlüsselte Nachricht im Webportal bereit; Push Encryption verwendet empfängerbezogene Verschlüsselungsdaten. Branding, Zugangsfunktionen, Ablauf und Absenderstatus werden über einen Bereitstellungsantrag konfiguriert und danach in einem separaten Administrationsportal betrieben. Das ist kein gewöhnlicher Sofort-Schalter in einer E-Mail-Richtlinie.

Produktgrenze: Dieser Ablauf behandelt das Sophos-Email-Portal und dessen Betrieb. TLS für SMTP-Verbindungen, S/MIME und die Bereitstellung des Sophos Outlook Add-in sind eigenständige Verfahren. Auch ein von Data Control gesetzter Verschlüsselungs-Header ist ein separater Auslöser; er konfiguriert weder Branding noch Rückruf.

Voraussetzungen und Ausgangszustand

Vor der Änderung benötigt man:

eine Sophos-Email-Lizenz mit Portal Encryption Add-on;
freigegebenes Portal-Logo, Portalname, Farben, Footertext und Supportkontakt;
mindestens einen genehmigten Portaladministrator und eine geprüfte Systemadresse;
Entscheidungen zu Administrator-MFA, Empfängeranmeldung, Nachrichtenablauf, Sender Notification, Rückruf und gegebenenfalls One-Way Submission;
Test-Absender und externe Test-Empfänger für Portal Encryption und, falls genutzt, Push Encryption.

Unter Global Settings > Products and Services > Email > Encryption hält man den bestehenden Zustand fest. Ist EMS mode aktiv und die Einstellung deshalb nicht konfigurierbar, wird dieser Ablauf nicht durch Umgehungen erzwungen. Vorhandene Portalnamen, Administratoren, Zugangsfunktionen, Ablaufwerte und Benachrichtigungen gehören in das Change-Protokoll. Bestehende Empfänger informiert man vor einer Umstellung, weil sie sich am neu gebrandeten Portal erneut registrieren müssen; alte Nachrichten bleiben höchstens während der bis zu 30 Tage dauernden Übergangsphase im bisherigen Portal erreichbar und laufen dort ab.

Branding-Antrag vorbereiten

Encryption öffnen und Download Branding Guidelines wählen. Die aktuelle Richtlinie ist massgeblich.
Unter Portal Branding in Portal Name den freigegebenen Namen eintragen. Account Name, Region und Email Domains kontrollieren; diese Felder sind automatisch befüllt und nicht editierbar. Fehler werden an Sophos Support gegeben.
Unter Portal Logo > Upload Portal Logo ein eigenes Organisationslogo hochladen. Zulässig sind JPEG, PNG oder GIF bis 5 MB bei festen 450 × 204 Pixeln; PNG erhält Transparenz. Fremde Marken können zum Entzug des Brandings und zur Zurückweisung verschlüsselter E-Mails führen.
Unter Portal Colors die Werte für Background Color und Foreground Color per RGB, HSL oder Hexadezimalwert setzen.
Mit Preview Branding Anmeldeseite und Aktivierungs-E-Mails prüfen und mit Confirm Branding zurückkehren.

Manche Tenants zeigen während des Rollouts noch ein einziges Formular statt der getrennten Bereiche Portal Branding und Feature Configuration. Die Möglichkeiten sind gleich; man dokumentiert die tatsächlich sichtbare Variante, statt einen fehlenden Abschnitt als Lizenzfehler zu deuten.

Administratoren und Empfängerzugriff konfigurieren

Unter Feature Configuration werden die Funktionen bewusst getrennt:

In Administrators nur Personen auswählen, die Empfängerkonten, Passwort-Resets und Berichte verwalten dürfen. Dieser beantragte Administrator Access ist Voraussetzung für das Administrationsportal.
Multi-factor Authentication schützt die ausgewählten Administratoren per TOTP-App.
Unter Time Zone die Zeitzone für Portal- und Benachrichtigungsdaten festlegen.
Unter System Email Address eine dedizierte Absenderadresse wie no-reply@example.com wählen. Diese Adresse nie zum Versand verschlüsselter E-Mails verwenden: Das kann eine Mail-Schleife und Zustellfehler auslösen.
Für Aktivierungs-E-Mails nur die benötigten Standardsprachen auswählen; ein oder zwei Sprachen wirken für Empfänger plausibler als eine lange Liste.
Reply All, Social Connector Sign-In to Secure Message web-portal, Passkey Login, Challenge Questions und Alternate Address nur gemäss freigegebenem Zugangskonzept aktivieren.
Mit 2-Step Verification via TOTP (Authenticator Apps) die Empfängerabsicherung erzwingen oder auf Optional setzen. Diese Empfängeroption ist nicht dasselbe wie Administrator-MFA.

Bei Alternate Address geht eine Wiederherstellungsnachricht an die bei der Registrierung angegebene alternative Adresse. Social Connector Sign-In unterstützt die im Formular genannten Connectoren Facebook, Google, Windows Live und Office 365. Vor der Aktivierung prüft man, ob diese Identitäten und Wiederherstellungswege zur Unternehmensrichtlinie passen.

Ablauf, Benachrichtigung und Rückruf festlegen

Unter Customize sender features:

In Message Expiry Period den genehmigten Verfügbarkeitszeitraum wählen.
Sender Notification aktivieren, wenn Absender Zustellungs-, Abruf- und Ablaufstatus mit Zeitstempeln sehen und Nachrichten zurückrufen können sollen.
In Customize Message Template nur den freigegebenen Footer, etwa Supporthinweise, ergänzen.
Einen benötigten One-Way-Submission-Betrieb als explizite Anforderung aufnehmen und nach der Bereitstellung gegen die Bestätigung und einen Testfall prüfen. Nicht aus einem Branding-Preview ableiten, dass diese Funktion aktiv ist.
Abweichende Anforderungen unter Special Instructions beschreiben. Sophos sagt nur zu, sie nach Möglichkeit zu berücksichtigen; daher sind sie erst nach schriftlicher Bestätigung und Abnahme als eingerichtet zu behandeln.

Der Rückruf setzt Sender Notification im Branding-Antrag voraus. Die Benachrichtigungs-E-Mail enthält den Portallink, über den der Absender die Statushistorie und Recall erreicht. Die Produktdokumentation beschreibt nicht, ob oder wie Recall einen späteren Portalzugriff, ein erneutes Öffnen oder externe Kopien beeinflusst. Daraus darf keine entsprechende Schutzwirkung abgeleitet werden. Message Expiry Period und Recall sind unterschiedliche Funktionen: Die erste legt den konfigurierten Verfügbarkeitszeitraum fest, Recall ist eine Aktion des Absenders.

Auswirkungen der Data-Control-Verschlüsselungs-Header

Eine passende Data-Control-Regel kann die folgenden Header pro Nachricht setzen oder ändern. Diese Overrides ändern weder den tenantweiten Branding-Antrag noch Message Expiry Period, Sender Notification oder Recall:

X-SophosEmailEncrypt-NoAuth = true|false: true stellt einen Link zur Portalnachricht ohne Empfängerauthentifizierung bereit; false hebt diese Anforderung nicht auf. Dieser Header erfordert das Portal Encryption Add-on.
X-SophosEmailEncrypt-VerificationCode = true|false: Bei true erhält der Absender nach dem Versand der portalverschlüsselten Nachricht den Code und muss ihn dem Empfänger mitteilen. Der Empfänger kann einen Ersatzcode erzeugen, der erneut an den Absender gesendet wird; false fordert diesen Code nicht an. Auch dieser Header erfordert das Portal Encryption Add-on.
X-SophosEmailEncrypt-ExpiryPeriod = today|fiveDays|oneWeek|twoWeeks: Nur diese vier Werte sind zulässig, und der gewählte Zeitraum darf das Kontomaximum nicht überschreiten. Das Standardmaximum beträgt 30 Tage und kann durch Custom Branding geändert worden sein. Bei Push Encryption läuft damit nur die Registrierungsnachricht ab, nicht die Push-Nachricht beziehungsweise deren geschützte Dokumente.
X-SophosEmailEncrypt-SendNotification = true|false: true benachrichtigt den Absender, wenn die verschlüsselte Nachricht gesendet wurde; false erzeugt diese Benachrichtigung nicht.
X-SophosEmailEncrypt-ReadNotification = true|false: true benachrichtigt den Absender beim Lesen; false erzeugt diese Benachrichtigung nicht. Bei Push Encryption zählt nur das Lesen der Registrierungsnachricht, nicht das Öffnen eines geschützten Dokuments.

Für die Abnahme setzt man jeweils nur einen exakten Headerwert in einer begrenzten ausgehenden Pilotregel und verwendet unkritische Nachrichten. Bei Portal Encryption prüft man die getroffene Regel und Aktion sowie wahlweise die normale Authentifizierung, den Zugriff ohne Authentifizierung oder den Versand und Ersatz des Codes über den Absender. Einen Ablaufwert prüft man gegen das Kontomaximum; beim Push-Test muss nachgewiesen werden, dass nur die Registrierungsnachricht abläuft. Für SendNotification=true und ReadNotification=true kontrolliert man die erwarteten Absenderbenachrichtigungen getrennt; beim Push-Test darf nur das Lesen der Registrierungsnachricht eine Lesebenachrichtigung auslösen. Eine Versandbenachrichtigung aktiviert weder Branding noch Recall.

Antrag einreichen und bereitstellen

Mit Submit speichern und im Dialog Confirm wählen. Danach kann der Antrag nicht selbst geändert werden; Korrekturen laufen über Sophos Support. Die Bereitstellung dauert typischerweise zwei Arbeitstage, ist aber kein garantierter Fertigstellungstermin.

Nach Abschluss erhält der Administrator eine Benachrichtigung mit Portallink und Zugangsdaten. Das temporäre Passwort läuft nach einem Tag ab. Die Einrichtung sofort abschliessen; bei Bedarf im Administrationsportal Forgot Password verwenden. Erst die anschliessende Bestätigung und die technische Abnahme erlauben den Produktivstart.

Empfänger- und Administratorablauf testen

Für die Abnahme sendet man eine unkritische Testnachricht an einen neuen externen Empfänger und eine weitere an einen bereits bekannten Empfänger:

Absender erhält bei aktivierter Sender Notification den erwarteten Statuslink.
Neuer Empfänger erhält die Aktivierung im richtigen Branding und registriert sich am richtigen Portal.
Anmeldung, TOTP beziehungsweise Optional, Passkey, Social Connector oder Passwort-Wiederherstellung verhalten sich exakt gemäss Freigabe.
Antworten und Reply All entsprechen der Konfiguration.
Zustellung, Abruf und Ablauf erscheinen mit plausiblen Zeitstempeln; die Zeitzone stimmt.
Einen zweiten, unkritischen Test über Recall zurückrufen und danach nur den beobachteten Status sowie das Verhalten beim Öffnen im Portal protokollieren. Das Testergebnis nicht als Produktgarantie oder als Aussage über externe Kopien behandeln.
Der gewählte Message Expiry Period wird mit einem geeigneten Test beziehungsweise Bericht belegt. Produktive Daten nicht nur zum Erreichen eines Ablaufdatums offen lassen.

Push Encryption aus Empfängersicht

Eine pushverschlüsselte Zustellung enthält passwortgeschützte Anhänge und kann zusätzlich den Nachrichtentext als PDF enthalten. Inhalte, die Sophos in ein geschütztes Dokument legt, verwenden das registrierte Passwort des Empfängers für Sophos Secure Message; bereits vor dem Versand verschlüsselte Anhänge bleiben unverändert. Eine einzelne Zustellung kann Dateien der Formate PDF, Microsoft Office und ZIP kombinieren. Der Empfänger öffnet sie mit einem kompatiblen Dokumentenbetrachter, beispielsweise Adobe Reader, und seinem registrierten Passwort. Nach dem Öffnen der verschlüsselten Nachricht in diesem Betrachter kann er sicher antworten.

Antworten aus einem Verschlüsselungsportal können bei einem nachgelagerten Provider als SPF-Fehler erscheinen, weil der sichtbare Übermittlungsweg nicht dem ursprünglichen Absender entspricht. Bei Google Workspace entweder Sophos Email als prüfende Grenze verwenden oder Googles automatische Erkennung externer IP-Adressen gemäss eigener Mailflow-Architektur konfigurieren; SPF nicht pauschal abschalten. Fehlt TLS 1.2, scheitern sowohl erzwungene als auch opportunistische TLS-Mailflows. Diese SMTP-Prüfung ist Troubleshooting an der Transportgrenze und keine Portal-Branding-Einstellung.

Empfänger verwalten und Berichte prüfen

Im Administrationsportal verwaltet Credential Management beide Verfahren:

Document Encryption Passwords für Push Encryption: Disable User 2-Step Verification, Migrate Encryption Keys beim Postfachwechsel und Expire Encryption Keys. Nach Ablauf registriert der Empfänger für künftige Push-Nachrichten ein neues Passwort.
Web Portal für Portal Encryption: Reset Password, Suspend Account und Disable User 2-Step Verification. Suspendieren blockiert den Zugriff, ohne das Konto zu löschen.

Die Berichte haben unterschiedliche Zwecke: Summary reports fassen den Austausch im Zeitraum zusammen, Policy reports zeigen unter anderem Nachrichten mit bevorstehendem Ablauf, und Message reports liefern Daten zu konkreten Nachrichten oder Empfängern. Vor administrativen Eingriffen Empfänger, Verfahren und betroffene Adresse doppelt prüfen; eine Push-Schlüsselmigration ist kein Portal-Passwort-Reset.

Fehlersuche und sicherer Rollback

Branding fehlt: Bereitstellungsbestätigung und Tenant-Daten prüfen, nicht während der typischen Bereitstellungszeit erneut einreichen. Falsche automatisch befüllte Felder oder ein Änderungswunsch gehen an Sophos Support.
Admin kann sich nicht anmelden: Ein-Tages-Frist des temporären Passworts, Forgot Password, beantragten Administrator Access, TOTP-Zeit und gewählten Administrator prüfen.
Empfänger kommt nicht hinein: zuerst Portal Encryption oder Push Encryption unterscheiden. Im Web Portal Passwort, Suspendierung und 2-Step Verification prüfen; unter Document Encryption Passwords Schlüsselzustand, Migration und Ablauf prüfen.
Rückruf fehlt: prüfen, ob Sender Notification im tatsächlich bereitgestellten Antrag enthalten ist. Eine normale Zustellmeldung oder eine Richtlinienaktion schaltet Recall nicht frei.
Zeit oder Status wirkt falsch: Time Zone, Empfängeradresse, Test-Message-ID und Statushistorie vergleichen. Berichte dienen der Gegenprüfung, ersetzen aber nicht den konkreten Portallink.
Antwort scheitert bei SPF oder TLS: Mailflow und empfangenden Provider getrennt vom Portal prüfen; keine Zugangsfunktion oder Verschlüsselung zum Kaschieren des Transportfehlers abschalten.

Da ein eingereichter Antrag nicht direkt bearbeitet werden kann, besteht der Rollback nicht aus einem unkontrollierten Zurückschalten. Bis Sophos die genehmigte Korrektur bereitstellt, stoppt man den produktiven Rollout, suspendiert bei einem Zugriffsrisiko gezielt betroffene Portalkonten und nutzt einen bereits freigegebenen sicheren Austauschweg. Keine fremden Logos hochladen, keine Systemadresse als Verschlüsselungsabsender verwenden und MFA nicht breit deaktivieren. Im Supportfall Tenant, Region, Einreichungszeit, Bestätigung, betroffene Absender und Empfänger, Message-ID, Zeitstempel, sichtbaren Portalstatus und anonymisierte Screenshots mitliefern.