Sophos Phish Threat in Google Workspace sicher zustellen

Google Workspace kann simulierte Phishing-Nachrichten wie echte Angriffe filtern, umschreiben oder als Spam einstufen. Für aussagekräftige Sophos-Phish-Threat-Kampagnen müssen deshalb die dokumentierten Versand-IP-Adressen, Absenderdomains und der Header X-PT-TOKEN berücksichtigt werden. Die Ausnahmen dürfen aber weder alle externen Absender freistellen noch mit der produktiven Anbindung von Sophos Email Gateway an Google Workspace verwechselt werden.

Sicherer Schnellweg: Aktuelle Versandwerte erfassen und zuerst die tenantweite Auswirkung prüfen. Email allowlist und Inbound gateway werden für die oberste Organisation konfiguriert und lassen sich nicht auf eine Pilot-Organisationseinheit begrenzen. Nur die eigene Spam-Regel mit Address list und die Content compliance-Regel werden zunächst einer kleinen Pilot-Organisationseinheit mit Testempfängern zugewiesen. Danach mit einer kontrollierten Kampagne Matching- und Non-Matching-Fälle innerhalb und ausserhalb des Piloten prüfen. Jede Ausnahme erhält Owner, Zweck und Reviewdatum.

Wichtig: Diese Konfiguration setzt Gmail-Schutzkontrollen für passende Simulationsnachrichten gezielt ausser Kraft. Sie schützt keine produktive Maildomain, ersetzt keine MX-, SPF-, DKIM- oder DMARC-Konfiguration und ist nicht die Google-Workspace-Anbindung von Sophos Email Gateway. Verwenden Sie ausschliesslich Werte der aktuellen Sophos-Phish-Threat-Dokumentation und der tatsächlich gestarteten Kampagne.

Voraussetzungen und Änderungsumfang

Benötigt werden:

Administratorzugriff auf Sophos Fusion (ehemals Sophos Central) und auf die Google Admin-Konsole;
eine Sophos-Phish-Threat-Lizenz und ein berechtigter Kampagnenadministrator;
eine kleine Pilotgruppe mit eigens benannten Testempfängern;
ein freigegebenes Change-Fenster sowie Zugriff auf Email Log Search und die Phish-Threat-Kampagnenergebnisse;
die Möglichkeit, bestehende Gmail-Einstellungen vor der Änderung zu dokumentieren;
je ein Owner für Kampagne, Google-Workspace-Regeln und spätere Bereinigung.

Erfassen Sie vorab Screenshots oder Exporte der betroffenen Einstellungen. Sichern Sie Email allowlist und Inbound gateway als tenantweiten Ausgangszustand der obersten Organisation, einschliesslich aller IPs, TLS- und Message Tagging-Optionen. Dokumentieren Sie bei Spam und Content compliance zusätzlich Organisationseinheit und Vererbungsstatus. Ändern Sie keine gemeinsam genutzte Adressliste, deren andere Verwendungszwecke nicht vollständig bekannt sind.

Die aktuell belegten Phish-Threat-Versand-IP-Adressen sind:

54.240.51.52
54.240.51.53

Prüfen Sie beide Werte unmittelbar vor der Änderung erneut in der Sophos-Information IP addresses and domains. Nur wenn der Tenant tatsächlich Sophos Mailflow verwendet, ergänzen Sie die von Sophos für die eigene Region genannten Mailflow-IP-Adressen. Geben Sie diese regionalen Werte nicht pauschal für Tenants ohne Mailflow frei und übernehmen Sie nichts aus einem fremden Tenant oder einem alten Ticket.

Die Sophos-Information führt die Werte amazonses.com, ~eu-west-1.awstrack.me~ und ~sophos-phish-threat.go-vip.co~ wörtlich als freizugebende Domains beziehungsweise URLs auf. Nur awstrack.me wird dort ausdrücklich als Klick-Trackingpfad beschrieben. Dokumentieren Sie diese Quellwerte unverändert und verwenden Sie beim Eintragen die Syntax des jeweiligen Zielsystems; leiten Sie aus den Tilden weder eine Wildcard-Semantik noch eine technische Rolle ab. Für die Gmail-Address list übernehmen Sie dagegen ausschliesslich die Absenderdomains aus Sending domains and IPs beziehungsweise aus der konkreten Kampagnenanzeige. URL-Werte sind kein Beleg für eine Absenderdomain.

Änderung zuerst als Pilot planen

Legen Sie eine Pilot-Organisationseinheit mit wenigen Testkonten für Spam und Content compliance fest oder wählen Sie eine bereits dafür vorgesehene Einheit.
Dokumentieren Sie dort Vererbung und lokalen Zustand dieser beiden Regeltypen.
Führen Sie für die tenantweiten Änderungen an Email allowlist und Inbound gateway eine Auswirkungsanalyse durch. Erfassen Sie insbesondere bestehende Gateways, direkte Zustellpfade, andere Systeme auf denselben IPs und den globalen Rücksetzstand.
Erfassen Sie Kampagnen-ID, Versandzeitraum, erwartete Absenderdomain, Empfänger, Landingpage und aktuelle Versand-IP-Adressen.
Definieren Sie einen positiven Test, einen ähnlichen, aber nicht passenden externen Absender und einen Empfänger ausserhalb der Pilot-Organisationseinheit.
Vereinbaren Sie Abbruchkriterien: unerwartete Bypässe innerhalb oder ausserhalb des Piloten, eine zu breit wirkende Ausnahme, fehlendes TLS oder nicht erklärbare Header- beziehungsweise Tracking-Ergebnisse.

Die vier Google-Konfigurationen unten gehören zum von Sophos dokumentierten Ablauf, haben in Google aber unterschiedliche Geltungsbereiche und sind nicht vier unabhängig wirksame Schutzstufen. Fassen Sie die OU-begrenzbaren Regeln nicht weiter als nötig und ergänzen Sie keine unbekannten Netze oder Domains, nur um einen fehlgeschlagenen Test zu umgehen.

IP-Wechselwirkung: Google behandelt eine IP in Inbound gateway als Gateway und sucht in den Received:-Zeilen nach der ursprünglichen öffentlichen Quell-IP. Steht dieselbe IP zusätzlich in Email allowlist, wirkt dieser Allowlist-Eintrag deshalb nicht auf Zustellung oder Spamfilter. Sophos nennt dennoch beide Schritte. Verifizieren Sie nach der Einrichtung anhand von Email Log Search und der vollständigen Received:-Kette, welche Quell-IP Google ermittelt und welche Regel tatsächlich greift. Leiten Sie aus dem Vorhandensein beider Einträge keinen doppelten Schutz ab.

Versand-IP-Adressen in Email allowlist aufnehmen

Melden Sie sich an der Google Admin-Konsole an.
Öffnen Sie Menu > Apps > Google Workspace > Gmail.
Wählen Sie Spam, Phishing and Malware.
Wählen Sie links ausdrücklich die oberste Organisation. Die Einstellung gilt trotzdem immer für die gesamte Domain und kann nicht auf eine Organisationseinheit begrenzt werden.
Öffnen Sie bei Email allowlist das Bearbeitungssymbol.
Tragen Sie ausschliesslich die aktuell bestätigten Sophos-Phish-Threat-Versand-IP-Adressen ein.
Speichern Sie mit Save.

Übernehmen Sie keine CIDR-Netze, wenn Sophos nur einzelne Adressen nennt. Bestehende Einträge werden nicht ersetzt, bevor Zweck und Owner geklärt sind. Halten Sie fest, welche beiden tenantweiten Werte durch diesen Change hinzugefügt wurden, damit der globale Rückbau nicht versehentlich fremde Ausnahmen entfernt. Beachten Sie die oben beschriebene Wechselwirkung, wenn dieselben IPs auch als Gateway eingetragen werden.

Inbound gateway für Phish Threat konfigurieren

Öffnen Sie unter Menu > Apps > Google Workspace > Gmail > Spam, Phishing and Malware links ausdrücklich die oberste Organisation und danach die Einstellung Inbound gateway. Diese Konfiguration gilt tenantweit; es gibt keinen Pilot-OU-Override. Aktivieren Sie sie erst nach Auswirkungsanalyse und Sicherung der vollständigen globalen Ausgangskonfiguration.

Unter Gateway IPs:

Klicken Sie auf Add und fügen Sie jede bestätigte Phish-Threat-IP-Adresse hinzu.
Aktivieren Sie Automatically detect external IP (recommended).
Deaktivieren Sie Reject all mail not from gateway IPs. Diese Phish-Threat-Konfiguration darf nicht alle anderen legitimen Zustellpfade des Tenants verwerfen.
Aktivieren Sie Require TLS for connections from the email gateways listed above.

Unter Message Tagging:

Wählen Sie Message is considered spam if the following header regexp matches.
Tragen Sie unter Regexp einen bewusst nicht passenden Wert ein, beispielsweise 344jedjs=-0sdfee3.
Wählen Sie Message is spam if regexp matches.
Aktivieren Sie Disable Gmail spam evaluation on mail from this gateway; only use header value.
Speichern Sie mit Save.

Der reguläre Ausdruck ist absichtlich kein Merkmal einer echten Nachricht. Prüfen Sie vor dem Speichern, dass er weder in vorhandenen Headern noch in eigenen Mail-Gateway-Tags vorkommt. Er darf nicht durch .*, einen leeren Ausdruck oder ein allgemeines Firmenmerkmal ersetzt werden. Die IP-Begrenzung und verpflichtendes TLS sind die wesentlichen Grenzen dieser Gateway-Ausnahme.

Eigene Address list für Sophos-Absenderdomains anlegen

Öffnen Sie Menu > Apps > Google Workspace > Gmail > Spam, Phishing and Malware.
Wählen Sie links ausdrücklich die Pilot-Organisationseinheit. Benutzer in untergeordneten Einheiten können die Einstellung erben; kontrollieren Sie daher deren tatsächlichen Scope.
Klicken Sie unter Spam auf Configure.
Benennen Sie die Einstellung eindeutig, beispielsweise Phish Threat bypass.
Wählen Sie Bypass spam filters for messages from senders or domains in selected lists.
Öffnen Sie Create or edit list und klicken Sie unter Manage address lists auf Add address list.
Legen Sie eine ausschliesslich für Sophos Phish Threat verwendete Liste an, beispielsweise Sophos Phish Threat.
Tragen Sie nur die aktuell bestätigten Absenderdomains aus Sophos beziehungsweise der konkreten Kampagnenanzeige ein; übernehmen Sie keine URL-Werte als Absenderdomain.
Schalten Sie für diese dokumentierte Phish-Threat-Liste die Authentifizierungsanforderung aus und speichern Sie mit Save.
Kehren Sie zur Spam-Einstellung der Pilot-Organisationseinheit zurück und wählen Sie Use existing list.
Wählen Sie Bypass spam filters and hide warnings for messages from senders or domains in selected lists, danach erneut Use existing list und die soeben erstellte Liste.
Speichern Sie mit Save.

Das Ausschalten der Authentifizierungsanforderung ist eine eng begrenzte Herstelleranforderung für diese Simulationsliste, keine Empfehlung für allgemeine Allow-Listen. Mischen Sie keine Lieferanten-, Partner- oder eigene Firmen-Domains in diese Liste. Fällt eine Kampagnendomain weg, wird genau dieser Eintrag entfernt.

Content compliance mit IP und Token konfigurieren

Öffnen Sie Menu > Apps > Google Workspace > Gmail > Compliance.
Wählen Sie links ausdrücklich die Pilot-Organisationseinheit und prüfen Sie, welche untergeordneten Einheiten diese Einstellung erben.
Klicken Sie unter Content compliance auf Configure.
Vergeben Sie einen eindeutigen Namen, beispielsweise Phish Threat content compliance.
Wählen Sie unter Email messages to affect die Richtung Inbound.
Klicken Sie unter If any of the following match the message auf Add.
Wählen Sie Metadata match.
Stellen Sie Attribute auf Source IP und Match type auf Source IP is within the following range.
Tragen Sie eine bestätigte Phish-Threat-IP-Adresse ein und speichern Sie den Ausdruck. Wiederholen Sie dies für jede weitere bestätigte Adresse.
Fügen Sie unter If any of the following match the message einen weiteren Ausdruck hinzu.
Wählen Sie Advanced content match, danach Location > Full headers und Match type > Contains text.
Tragen Sie unter Content exakt X-PT-TOKEN ein und speichern Sie den Ausdruck.
Wählen Sie unter If the above expressions match bei Spam die Aktion Bypass spam filter for this message.
Wählen Sie unter Encryption (onward delivery only) die Aktion Require secure transport (TLS).
Speichern Sie die gesamte Regel mit Save.

Sicherheitsgrenze: Die dokumentierte Google-Regel verwendet If any of the following match the message. Damit kann entweder eine passende Quell-IP oder der Headername X-PT-TOKEN die Aktion auslösen. Der Header ist deshalb kein kryptografischer Herkunftsnachweis. Begrenzen Sie die Regel über Pilot-Organisationseinheit, Richtung und Lebenszyklus; verwenden Sie X-PT-TOKEN nicht in anderen Bypass-Regeln und prüfen Sie im Non-Matching-Test, dass normale externe Nachrichten keine Ausnahme erhalten. Ändern Sie any nicht eigenmächtig in all, weil dies vom dokumentierten Sophos-Ablauf abweicht und die Kampagnenzustellung verändern kann.

Die Option Require secure transport (TLS) in diesem Abschnitt betrifft laut UI nur die Weiterzustellung. Die eingehende TLS-Anforderung wird separat in Inbound gateway gesetzt; keine der beiden Optionen ersetzt die andere.

Konfiguration kontrolliert abnehmen

Warten Sie, bis die tenantweiten Änderungen und die Regeln der Pilot-Organisationseinheit wirksam sind. Starten Sie danach eine kleine, eindeutig benannte Phish-Threat-Pilotkampagne. Verwenden Sie keine reale Zugangsdatenabfrage und senden Sie nicht unkontrolliert an produktive Verteiler.

Führen Sie mindestens diese Prüfungen durch:

Passender Pilotempfänger: Die Simulationsmail wird im Posteingang zugestellt. Absenderdomain, Empfänger, Zeit und Kampagnen-ID stimmen.
Herkunft und Regelwirkung: Die vollständigen Header enthalten die erwartete Received:-Kette und X-PT-TOKEN. Email Log Search und Header werden gemeinsam ausgewertet, um die von Google bestimmte Quell-IP und die tatsächlich greifende Gateway-, Allowlist-, Spam- oder Compliance-Regel zu belegen.
Transport: Prüfen Sie eingehendes TLS in Email Log Search und/oder am konkreten Received:- beziehungsweise Transportnachweis. Das blosse Vorhandensein vollständiger Header ist kein pauschaler TLS-Beleg. Die Compliance-Option Require secure transport (TLS) betrifft separat die Weiterzustellung.
Sophos-Ereignisse: Versand, Zustellung sowie ein kontrollierter Klick beziehungsweise eine Meldung erscheinen nur für den richtigen Testbenutzer in der Kampagne.
Ähnlicher Non-Matching-Absender: Eine normale externe Testmail ohne bestätigte Sophos-IP und ohne X-PT-TOKEN durchläuft die regulären Gmail-Prüfungen. Sie darf nicht allein wegen einer zu breiten Domain- oder Wildcard-Regel den Bypass erhalten.
Empfänger ausserhalb des Piloten: Die OU-begrenzten Spam- und Content compliance-Regeln dürfen dort nicht greifen. Die tenantweiten Email allowlist- und Inbound gateway-Effekte können dagegen auch diesen Empfänger betreffen und müssen separat anhand von Email Log Search und Headern bewertet werden.
Nicht passender Headerinhalt: Der absichtlich unmögliche Wert aus Message Tagging darf normale Nachrichten nicht als Phish-Threat-Simulation klassifizieren.

Eine zugestellte Nachricht allein beweist nicht, dass die richtige Ausnahme gegriffen hat. Sichern Sie für die Abnahme Message-ID, Zeitstempel, vollständige Header, Google-Protokollergebnis und Sophos-Kampagnenergebnis. Dokumentieren Sie keine echten Kennwörter oder vertraulichen Nachrichteninhalte.

Fehler gezielt eingrenzen

Die Simulation kommt nicht an: Prüfen Sie zuerst Kampagnenstatus und Empfängeradresse, dann Email Log Search. Gibt es keinen Google-Eintrag, vergleichen Sie die tatsächlich sendende IP mit der aktuellen Sophos-Liste. Gibt es einen Eintrag, unterscheiden Sie den tenantweiten Gateway-/Allowlist-Zustand vom OU-Scope und der Vererbung der Spam-/Compliance-Regeln. Prüfen Sie danach Spam-/Quarantäneaktion und TLS-Fehler.
Die Nachricht landet im Spam: Vergleichen Sie Quell-IP, sichtbare beziehungsweise Envelope-Absenderdomain, Address list, X-PT-TOKEN und den Scope der Content compliance-Regel. Legen Sie keinen breiteren Domain-Bypass an, bevor die Abweichung erklärt ist.
Gmail lehnt die Verbindung ab: Kontrollieren Sie beide Gateway IPs, die wirksame Regel und Require TLS for connections from the email gateways listed above. TLS nicht dauerhaft abschalten; bei einem reproduzierbaren Transportfehler mit Message-ID, Zeit und SMTP-Ergebnis eskalieren.
Legitime Mail wird unerwartet umgangen: Stoppen Sie die Pilotkampagne. Prüfen Sie anhand von Email Log Search und vollständigen Headern, ob eine tenantweite Gateway-/Allowlist-Änderung oder eine OU-begrenzte Spam-/Compliance-Regel gegriffen hat. Deaktivieren Sie die identifizierte neue Ausnahme nach dem dokumentierten Rücksetzplan. Kontrollieren Sie danach, ob die Nachricht X-PT-TOKEN enthält, aus einer eingetragenen IP kommt oder auf eine zu breite Absenderdomain passt.
Klicks fehlen trotz Zustellung: Kontrollieren Sie, ob Browser-Erweiterungen oder Webfilter Zugriffe auf awstrack.me blockieren. Sophos verwendet diesen AWS-Trackingpfad für Klickereignisse. Ändern Sie nicht den Gmail-Absender-Bypass, wenn nur das Web-Tracking betroffen ist.
Die Kampagne verwendet eine andere Absenderdomain: Gleichen Sie den in Sending domains and IPs beziehungsweise in der Kampagnenanzeige ausgewiesenen Absenderwert mit der dedizierten Address list ab. Ergänzen Sie nur den belegten Absenderscope; leiten Sie ihn nicht aus einer URL oder deren Tilden ab.
Google Connection schlägt fehl: Prüfen Sie die Project Creation Settings in der Google Admin-Konsole. Das ist eine Berechtigungs- beziehungsweise Google-Cloud-Einstellung und wird nicht durch zusätzliche Gmail-Allow-Listen behoben.
Tracking zeigt falsche Benutzer oder automatische Klicks: Prüfen Sie zuerst Weiterleitungen, Gruppenempfänger, vorgeschaltete Linkscanner und Header. Erweitern Sie die Ausnahme nicht; automatische Sicherheitsprüfungen können Links vor dem Benutzer öffnen.

Bleibt ein Fehler reproduzierbar, übergeben Sie Sophos Support Kampagnen-ID, Message-ID, UTC-Zeitstempel, Absender und Empfänger, Quell-IP, relevante Header sowie das Google-Protokollergebnis. Entfernen oder maskieren Sie nicht benötigte personenbezogene Inhalte.

Sicher zurückrollen

Ein Rollback stellt den dokumentierten Ausgangszustand wieder her. Stoppen oder pausieren Sie zuerst aktive Pilotkampagnen, damit während des Rückbaus keine uneindeutigen Ergebnisse entstehen. Behandeln Sie Inbound gateway und Email allowlist als tenantweite Änderungen; nur Spam und Content compliance werden in der Pilot-Organisationseinheit zurückgebaut.

Deaktivieren oder entfernen Sie in der Pilot-Organisationseinheit die neu angelegte Content compliance-Regel.
Entfernen Sie dort die neue Spam-Regel und stellen Sie den ursprünglichen Vererbungsstatus wieder her. Löschen Sie die dedizierte Address list erst, wenn keine andere Regel sie verwendet.
Wählen Sie die oberste Organisation und stellen Sie die vorherige tenantweite Inbound gateway-Konfiguration exakt wieder her, einschliesslich Aktivierungszustand, IPs, TLS und Message Tagging. War zuvor kein Gateway aktiv, stellen Sie diesen globalen Zustand wieder her; einen lokalen OU-Override gibt es nicht.
Entfernen Sie in der obersten Organisation aus Email allowlist ausschliesslich die durch diesen Change hinzugefügten Phish-Threat-IP-Adressen und stellen Sie so den gesicherten tenantweiten Ausgangszustand wieder her.
Warten Sie auf die Wirksamkeit. Testen Sie eine normale externe Nachricht an einen früheren Pilotempfänger und an einen Empfänger ausserhalb des Piloten; kontrollieren Sie Email Log Search und Header auf den wiederhergestellten globalen und lokalen Zustand.
Halten Sie Grund, Zeitpunkt, ausführende Person und Prüfergebnis im Change fest.

Löschen Sie keine gemeinsam genutzte Liste und überschreiben Sie keine vorhandene Google-Regel, nur um den Pilot zurückzusetzen. Wenn der globale Ausgangszustand nicht eindeutig dokumentiert ist, entfernen Sie keine fremden Einträge und raten Sie den früheren Gateway-Zustand nicht. Stoppen Sie die Kampagne, nehmen Sie nur eindeutig diesem Change zuordenbare Ergänzungen nach Vier-Augen-Prüfung zurück und klären Sie den übrigen Rückbau mit dem verantwortlichen Google-Workspace-Administrator.

Ausnahmen über den Kampagnenbetrieb pflegen

Die Konfiguration ist kein einmaliger «Allow forever»-Schritt. Prüfen Sie vor jeder Kampagnenserie und mindestens quartalsweise:

aktuelle Sophos-Phish-Threat-Versand-IP-Adressen und, nur bei tatsächlich eingesetztem Sophos Mailflow, die Werte der eigenen Mailflow-Region;
die in Sending domains and IPs beziehungsweise der Kampagnenanzeige konkret ausgewiesenen Absenderdomains;
Owner, Zweck, tenantweiten Scope von Email allowlist und Inbound gateway, OU-Scope von Spam und Content compliance sowie das Reviewdatum jeder Google-Regel;
unerwartete Treffer auf X-PT-TOKEN, zu breite Wildcards und verwaiste Adresslisteneinträge;
TLS-Ergebnisse, Google-Protokolle und die Qualität der Sophos-Kampagnenereignisse.

Entfernen Sie nicht mehr benötigte IPs und Domains nach einem kontrollierten Test. Bei einer dauerhaften Awareness-Kampagne bleiben nur die weiterhin belegten Werte aktiv; temporäre Kampagnendomains werden nach Abschluss entfernt. Jede Erweiterung durchläuft erneut Auswirkungsanalyse, Matching-, Non-Matching- und Scope-Test. Ein Pilot kann dabei nur die Spam- und Content compliance-Regeln begrenzen, nicht Email allowlist oder Inbound gateway. So bleibt die Zustellung messbar, ohne aus einer Phishing-Simulation einen dauerhaften allgemeinen Bypass zu machen.