Distribuer Sophos Phish Threat en toute sécurité dans Google Workspace

Google Workspace peut filtrer, réécrire ou classer comme spam les messages de phishing simulés comme de véritables attaques. Pour des campagnes Sophos Phish Threat significatives, il faut donc prendre en compte les adresses IP d’envoi, les domaines expéditeurs et l’en-tête X-PT-TOKEN documentés. Cependant, les exceptions ne doivent en aucun cas exempter ou placer sur liste d’autorisation l’ensemble des expéditeurs externes, ni être confondues avec l’intégration en production de Sophos Email Gateway à Google Workspace.

Procédure rapide et sûre : Relevez les valeurs d’envoi actuelles et évaluez d’abord l’impact à l’échelle du tenant. Email allowlist et Inbound gateway sont configurés pour l’organisation racine et ne peuvent pas être limités à une unité organisationnelle pilote. Seules la règle Spam dédiée avec son Address list et la règle Content compliance sont initialement attribuées à une petite unité organisationnelle pilote avec des destinataires de test. Ensuite, avec une campagne contrôlée, vérifier les cas correspondants et non correspondants à l’intérieur et en dehors du pilote. Chaque exception reçoit un propriétaire, un objectif et une date de révision.

Important : Cette configuration désactive spécifiquement les contrôles de protection Gmail pour les messages de simulation correspondants. Elle ne protège aucun domaine de messagerie en production, ne remplace pas la configuration MX, SPF, DKIM ou DMARC et n’est pas la connexion Google Workspace de Sophos Email Gateway. Utilisez uniquement les valeurs de la documentation Sophos Phish Threat actuelle et de la campagne réellement lancée.

Prérequis et étendue des modifications

Nécessaire :

un accès administrateur à Sophos Fusion (anciennement Sophos Central) et à la console d’administration Google ;
une licence Sophos Phish Threat et un administrateur de campagne autorisé ;
un petit groupe pilote avec des destinataires de test spécialement désignés ;
une fenêtre de changement approuvée ainsi qu’un accès à Email Log Search et aux résultats de la campagne Phish Threat ;
la possibilité de documenter les paramètres Gmail existants avant la modification ;
un propriétaire désigné pour la campagne, les règles Google Workspace et le nettoyage ultérieur.

Capturez au préalable des captures d’écran ou des exportations des paramètres concernés. Sauvegardez Email allowlist et Inbound gateway comme état initial à l’échelle du tenant de l’organisation supérieure, y compris toutes les IP, TLS et options Message Tagging. Documentez également, pour Spam et Content compliance, l’unité organisationnelle et le statut d’héritage. Ne modifiez aucune liste d’adresses partagée dont les autres usages ne sont pas entièrement connus.

Les adresses IP d’envoi Phish Threat actuellement documentées sont :

54.240.51.52
54.240.51.53

Vérifiez à nouveau les deux valeurs immédiatement avant la modification dans les informations Sophos IP addresses and domains. Ce n’est que si le locataire utilise réellement Sophos Mailflow que vous devez ajouter les adresses IP de flux de messagerie indiquées par Sophos pour votre propre région. N’autorisez pas ces valeurs régionales de manière générale pour les tenants sans Mailflow et ne reprenez aucune valeur provenant d’un autre tenant ou d’un ancien ticket.

Les informations Sophos listent littéralement les valeurs amazonses.com, ~eu-west-1.awstrack.me~ et ~sophos-phish-threat.go-vip.co~ comme des domaines ou URL à autoriser. Seul le awstrack.me y est explicitement décrit comme un chemin de suivi de clics. Documentez ces valeurs sources sans les modifier et utilisez, lors de l’entrée, la syntaxe du système cible respectif ; ne déduisez ni une sémantique de caractère générique ni un rôle technique des tildes. Pour la Address list de Gmail, reprenez en revanche uniquement les domaines expéditeurs issus de Sending domains and IPs ou des détails de la campagne concernée. Les valeurs URL ne constituent pas une preuve d’un domaine expéditeur.

Planifier d’abord le changement comme pilote

Définissez une unité organisationnelle pilote avec quelques comptes test pour Spam et Content compliance ou choisissez une unité déjà prévue à cet effet.
Documentez-y l’héritage et l’état local de ces deux types de règles.
Effectuez une analyse d’impact pour les modifications à l’échelle du locataire sur Email allowlist et Inbound gateway. Recueillez en particulier les passerelles existantes, les chemins de livraison directs, les autres systèmes sur les mêmes IP et l’état de réinitialisation global.
Enregistrez l’ID de la campagne, la période d’envoi, le domaine expéditeur prévu, le destinataire, la page de destination et les adresses IP d’envoi actuelles.
Définissez un test positif, un expéditeur externe similaire mais non correspondant et un destinataire en dehors de l’unité organisationnelle pilote.
Convenez de critères d’abandon : des dérivations inattendues à l’intérieur ou en dehors du pilote, une exception ayant un effet trop large, l’absence de TLS ou des résultats de suivi ou d’en-tête inexpliqués.

Les quatre configurations Google ci-dessous font partie du processus documenté par Sophos, mais ont des portées différentes dans Google et ne constituent pas quatre niveaux de protection indépendants. N’élargissez pas les règles limitées à l’OU au-delà du nécessaire et n’ajoutez aucun réseau ou domaine inconnu simplement pour contourner un test échoué.

Interaction IP : Google traite une IP dans Inbound gateway comme une passerelle et recherche dans les lignes Received: l’IP source publique d’origine. Si la même IP figure également dans Email allowlist, cette entrée de liste autorisée n’a donc aucun effet sur la livraison ou le filtre anti-spam. Sophos mentionne néanmoins les deux étapes. Vérifiez après la configuration, à partir de Email Log Search et de la chaîne complète Received:, quelle IP source Google identifie et quelle règle s’applique réellement. Ne déduisez pas une protection double de la présence des deux entrées.

Inclure les adresses IP d’expédition dans Email allowlist

Connectez-vous à la console d’administration Google.
Ouvrez Menu > Apps > Google Workspace > Gmail.
Sélectionnez Spam, Phishing and Malware.
Sélectionnez explicitement l’organisation la plus haute à gauche. Le paramètre reste néanmoins toujours valable pour l’ensemble du domaine et ne peut pas être limité à une unité organisationnelle.
Ouvrez l’icône de modification chez Email allowlist.
Saisissez uniquement les adresses IP d’expédition Sophos Phish Threat actuellement confirmées.
Enregistrez avec Save.

Ne reprenez pas les réseaux CIDR si Sophos ne mentionne que des adresses individuelles. Les entrées existantes ne sont pas remplacées avant que le but et le propriétaire ne soient clarifiés. Notez quelles deux valeurs à l’échelle du locataire ont été ajoutées par ce changement afin que la suppression globale n’élimine pas accidentellement des exceptions étrangères. Prenez en compte l’interaction décrite ci-dessus si les mêmes IP sont également enregistrées en tant que passerelle.

Configurer Inbound gateway pour Phish Threat

Sous Menu > Apps > Google Workspace > Gmail > Spam, Phishing and Malware, ouvrez explicitement l’organisation la plus haute à gauche, puis le paramètre Inbound gateway. Cette configuration s’applique à l’ensemble du tenant ; il n’y a pas de contournement de l’OU pilote. Ne l’activez qu’après analyse des impacts et sauvegarde de la configuration globale initiale complète.

Sous Gateway IPs :

Cliquez sur Add et ajoutez chaque adresse IP Phish Threat confirmée.
Activez Automatically detect external IP (recommended).
Désactivez Reject all mail not from gateway IPs. Cette configuration Phish Threat ne doit pas rejeter tous les autres chemins de livraison légitimes du locataire.
Activez Require TLS for connections from the email gateways listed above.

Sous Message Tagging :

Sélectionnez Message is considered spam if the following header regexp matches.
Saisissez sous Regexp une valeur qui ne correspond volontairement à rien, par exemple 344jedjs=-0sdfee3.
Sélectionnez Message is spam if regexp matches.
Activez Disable Gmail spam evaluation on mail from this gateway; only use header value.
Enregistrez avec Save.

L’expression régulière n’est intentionnellement pas une caractéristique d’un vrai message. Vérifiez avant de l’enregistrer qu’elle ne figure ni dans les en-têtes existants ni dans vos propres balises de passerelle de messagerie. Elle ne doit pas être remplacée par .*, une expression vide ou une caractéristique générale de l’entreprise. La limitation par IP et le TLS obligatoire sont les limites essentielles de cette exception de passerelle.

Créer son propre Address list pour les domaines expéditeurs Sophos

Ouvrez Menu > Apps > Google Workspace > Gmail > Spam, Phishing and Malware.
Sélectionnez explicitement l’unité organisationnelle pilote à gauche. Les utilisateurs des unités subordonnées peuvent hériter du paramètre ; contrôlez donc leur portée réelle.
Sous Spam, cliquez sur Configure.
Nommez le réglage de manière claire, par exemple Phish Threat bypass.
Sélectionnez Bypass spam filters for messages from senders or domains in selected lists.
Ouvrez Create or edit list et cliquez sous Manage address lists sur Add address list.
Créez une liste utilisée exclusivement pour Sophos Phish Threat, par exemple Sophos Phish Threat.
Ne saisissez que les domaines d’expéditeur actuellement confirmés par Sophos ou dans les détails de la campagne concernée ; ne reprenez aucune valeur d’URL comme domaine d’expéditeur.
Désactivez la demande d’authentification pour cette liste documentée Phish Threat et enregistrez avec Save.
Revenez aux paramètres Spam de l’unité organisationnelle pilote et sélectionnez Use existing list.
Sélectionnez Bypass spam filters and hide warnings for messages from senders or domains in selected lists, puis à nouveau Use existing list et la liste que vous venez de créer.
Enregistrez avec Save.

Désactiver la demande d’authentification est une exigence très limitée du fabricant pour cette liste de simulation, et non une recommandation pour des listes blanches générales. Ne mélangez pas les domaines de fournisseurs, partenaires ou de votre propre entreprise dans cette liste. Si un domaine de campagne n’est plus utilisé, supprimez uniquement l’entrée correspondante.

Configurer Content compliance avec une IP et un jeton

Ouvrez Menu > Apps > Google Workspace > Gmail > Compliance.
Sélectionnez explicitement à gauche l’unité organisationnelle pilote et vérifiez quelles unités subordonnées héritent de ce paramètre.
Cliquez sous Content compliance sur Configure.
Donnez un nom unique, par exemple Phish Threat content compliance.
Sélectionnez sous Email messages to affect la direction Inbound.
Cliquez sous If any of the following match the message sur Add.
Sélectionnez Metadata match.
Mettez Attribute sur Source IP et Match type sur Source IP is within the following range.
Saisissez une adresse IP Phish Threat confirmée et enregistrez l’expression. Répétez cela pour chaque autre adresse confirmée.
Ajoutez une autre expression sous If any of the following match the message.
Sélectionnez Advanced content match, puis Location > Full headers et Match type > Contains text.
Saisissez exactement X-PT-TOKEN sous Content et enregistrez l’expression.
Sous If the above expressions match, sélectionnez l’action Bypass spam filter for this message dans Spam.
Sélectionnez l’action Require secure transport (TLS) sous Encryption (onward delivery only).
Enregistrez la règle entière avec Save.

Limite de sécurité : La règle documentée de Google utilise If any of the following match the message. Cela permet soit une IP source appropriée, soit le nom du header X-PT-TOKEN pour déclencher l’action. Le header n’est donc pas une preuve cryptographique d’origine. Limitez la règle par l’unité organisationnelle pilote, la direction et le cycle de vie ; n’utilisez pas X-PT-TOKEN dans d’autres règles de contournement et vérifiez dans le test de non-correspondance que les messages externes normaux ne reçoivent aucune exception. Ne changez pas any arbitrairement en all, car cela dévie du processus Sophos documenté et peut modifier la livraison des campagnes.

Selon l’interface utilisateur, l’option Require secure transport (TLS) de cette section concerne uniquement la livraison ultérieure. L’exigence de TLS entrant est configurée séparément dans Inbound gateway ; aucune des deux options ne remplace l’autre.

Vérification contrôlée de la configuration

Attendez que les modifications à l’échelle du tenant et les règles de l’unité organisationnelle pilote prennent effet. Lancez ensuite une petite campagne pilote Phish Threat clairement nommée. Ne demandez pas de véritables identifiants et n’envoyez pas de messages sans contrôle aux listes de distribution utilisées en production.

Effectuez au minimum ces tests :

Destinataire pilote correspondant : L’e-mail de simulation est livré dans la boîte de réception. Le domaine de l’expéditeur, le destinataire, l’heure et l’ID de la campagne correspondent.
Origine et effet de la règle : Les en-têtes complets contiennent la chaîne Received: et X-PT-TOKEN attendues. Email Log Search et les en-têtes sont évalués ensemble pour déterminer l’adresse IP source identifiée par Google ainsi que la règle de passerelle, de liste blanche, de spam ou de conformité effectivement appliquée.
Transport : Vérifiez le TLS entrant dans Email Log Search et/ou dans le Received: spécifique ou le justificatif de transport. La simple présence de tous les en-têtes complets n’est pas une preuve TLS générale. L’option de conformité Require secure transport (TLS) concerne séparément la retransmission.
Événements Sophos : L’envoi, la livraison ainsi qu’un clic contrôlé ou une notification n’apparaissent que pour le testeur correct dans la campagne.
Expéditeur non correspondant similaire : Un e-mail de test externe normal sans IP Sophos confirmée et sans X-PT-TOKEN passe les vérifications régulières Gmail. Il ne doit pas obtenir le contournement uniquement en raison d’une règle de domaine ou de caractère générique trop large.
Destinataires en dehors du pilote : Les règles limitées à l’OU Spam et Content compliance ne doivent pas s’appliquer là. En revanche, les effets à l’échelle du locataire Email allowlist et Inbound gateway peuvent également concerner ce destinataire et doivent être évalués séparément à l’aide de Email Log Search et des en-têtes.
Contenu d’en-tête inapproprié : La valeur délibérément impossible de Message Tagging ne doit pas classer les messages normaux comme une simulation Phish Threat.

Un message livré à lui seul ne prouve pas que la bonne exception a été appliquée. Pour la validation, conservez comme justificatifs l’ID du message, l’horodatage, les en-têtes complets, le résultat du journal Google et le résultat de la campagne Sophos. Ne consignez pas de véritables mots de passe ni de contenu confidentiel des messages.

Diagnostiquer les erreurs de manière ciblée

La simulation ne parvient pas : Vérifiez d’abord l’état de la campagne et l’adresse du destinataire, puis Email Log Search. S’il n’y a pas d’entrée Google, comparez l’adresse IP réellement utilisée pour l’envoi avec la liste Sophos actuelle. S’il y a une entrée, distinguez l’état de la passerelle et de l’allowlist au niveau du tenant de celui de l’OU et de l’héritage des règles de spam/conformité. Vérifiez ensuite l’action de spam/mise en quarantaine et les erreurs TLS.
Le message atterrit dans le spam : Comparez l’adresse IP source, le domaine de l’expéditeur visible ou de l’enveloppe, Address list, X-PT-TOKEN et le périmètre de la règle Content compliance. N’appliquez pas de contournement de domaine plus large avant que l’écart ne soit expliqué.
Gmail refuse la connexion : Vérifiez les deux Gateway IPs, la règle efficace et Require TLS for connections from the email gateways listed above. Ne désactivez pas TLS de manière permanente ; en cas d’erreur de transport reproductible avec ID de message, heure et résultat SMTP, escaladez.
Un e-mail légitime est contourné de manière inattendue : Arrêtez la campagne pilote. Vérifiez à l’aide de Email Log Search et des en-têtes complets si une modification de la passerelle/liste blanche à l’échelle du locataire ou une règle spam/conformité limitée à une OU a été appliquée. Désactivez la nouvelle exception identifiée selon le plan de réinitialisation documenté. Contrôlez ensuite si le message contient X-PT-TOKEN, provient d’une IP enregistrée ou correspond à un domaine expéditeur trop large.
Clics manquants malgré la livraison : Vérifiez si des extensions de navigateur ou des filtres web bloquent l’accès à awstrack.me. Sophos utilise ce chemin de suivi AWS pour les événements de clic. Ne modifiez pas le contournement de l’expéditeur Gmail si seul le suivi web est concerné.
La campagne utilise un autre domaine d’expéditeur : Comparez la valeur de l’expéditeur indiquée dans Sending domains and IPs ou dans les détails de la campagne avec la Address list dédiée. Ajoutez uniquement le périmètre d’expéditeur documenté ; ne le déduisez pas d’une URL ni de ses tildes.
Échec de la connexion Google : Vérifiez Project Creation Settings dans la console d’administration Google. Il s’agit d’un paramètre d’autorisation ou de Google Cloud et ne peut pas être résolu par des listes blanches Gmail supplémentaires.
Le suivi montre de faux utilisateurs ou des clics automatiques : Vérifiez d’abord les redirections, les destinataires groupés, les scanners de liens en amont et les en-têtes. N’élargissez pas l’exception ; les contrôles de sécurité automatiques peuvent ouvrir les liens avant l’utilisateur.

Si une erreur reste reproductible, transmettez au support Sophos l’ID de campagne, l’ID du message, le timestamp UTC, l’expéditeur et le destinataire, l’IP source, les en-têtes pertinents ainsi que le résultat du protocole Google. Supprimez ou masquez les contenus personnels non nécessaires.

Revenir en arrière en toute sécurité

Un rollback restaure l’état documenté initial. Arrêtez ou mettez d’abord en pause les campagnes pilotes actives afin d’éviter des résultats ambigus pendant le retrait. Traitez Inbound gateway et Email allowlist comme des modifications à l’échelle du locataire ; seuls Spam et Content compliance seront retirés dans l’unité organisationnelle pilote.

Désactivez ou supprimez dans l’unité d’organisation pilote la règle nouvellement créée Content compliance.
À partir de là, retirez la nouvelle règle Spam et restaurez-la à son état d’héritage d’origine. Ne supprimez pas la Address list dédiée tant qu’aucune autre règle ne l’utilise.
Sélectionnez l’organisation principale et restaurez exactement la configuration précédente de l’ensemble du tenant Inbound gateway, y compris l’état d’activation, les IP, le TLS et Message Tagging. Si aucune passerelle n’était active auparavant, restaurez cet état global ; il n’existe pas de contournement local OU.
Supprimez dans l’organisation la plus élevée de Email allowlist uniquement les adresses IP Phish Threat ajoutées par ce changement et rétablissez ainsi l’état initial sécurisé à l’échelle du tenant.
Attendez l’efficacité. Testez un message externe normal envoyé à un ancien destinataire pilote et à un destinataire en dehors du pilote ; contrôlez Email Log Search et l’en-tête pour l’état global et local restauré.
Consignez la raison, le moment, la personne exécutante et le résultat de la vérification dans le changement.

Ne supprimez aucune liste partagée et ne remplacez aucune règle Google existante uniquement pour réinitialiser le pilote. Si l’état initial global n’est pas clairement documenté, ne supprimez aucun élément d’autrui et ne devinez pas l’état précédent de la passerelle. Arrêtez la campagne, ne retirez que les ajouts clairement attribuables à ce changement après un contrôle à quatre yeux et clarifiez le reste du démantèlement avec l’administrateur Google Workspace responsable.

Gérer les exceptions concernant le fonctionnement de la campagne

La configuration n’est pas une étape unique «Autoriser pour toujours». Vérifiez avant chaque série de campagnes et au moins une fois par trimestre :

adresses IP d’expédition Sophos Phish Threat actuelles et, uniquement en cas d’utilisation effective de Sophos Mailflow, les valeurs de sa propre région de flux de courrier ;
les domaines expéditeurs spécifiquement indiqués dans Sending domains and IPs ou dans les détails de la campagne ;
Propriétaire, objectif, portée au niveau du locataire de Email allowlist et Inbound gateway, portée OU de Spam et Content compliance, ainsi que la date de révision de chaque règle Google ;
des correspondances inattendues sur X-PT-TOKEN, des jokers trop larges et des entrées d’adresses orphelines ;
Résultats TLS, journaux Google et qualité des événements de campagne Sophos.

Supprimez les IP et les domaines qui ne sont plus nécessaires après un test contrôlé. Dans le cadre d’une campagne de sensibilisation permanente, seules les valeurs toujours utilisées restent actives ; les domaines temporaires de la campagne sont supprimés après la fin. Chaque extension subit à nouveau une analyse d’impact, un test de correspondance, un test de non-correspondance et un test de portée. Un pilote peut seulement limiter les règles Spam et Content compliance, pas Email allowlist ou Inbound gateway. Ainsi, la livraison reste mesurable, sans transformer une simulation de phishing en contournement général permanent.