Recapitare Sophos Phish Threat in modo sicuro in Google Workspace

Google Workspace può filtrare, riscrivere o classificare come spam i messaggi di phishing simulati come se fossero attacchi reali. Pertanto, per ottenere campagne Sophos Phish Threat significative, è necessario considerare gli indirizzi IP di invio documentati, i domini dei mittenti e l’intestazione X-PT-TOKEN. Tuttavia, le eccezioni non devono né esentare tutti i mittenti esterni né essere confuse con il collegamento produttivo di Sophos Email Gateway a Google Workspace.

Percorso rapido sicuro: Registrate i valori di spedizione attuali e verificate prima l’impatto a livello di tenant. Email allowlist e Inbound gateway vengono configurati per l’organizzazione principale e non possono essere limitati a un’unità organizzativa pilota. Assegnate inizialmente solo la regola Spam dedicata con Address list e la regola Content compliance a una piccola unità organizzativa pilota con destinatari di test. Successivamente verificate, con una campagna controllata, i casi corrispondenti e non corrispondenti all’interno e al di fuori del pilota. Assegnate a ogni eccezione un responsabile, uno scopo e una data di revisione.

Importante: Questa configurazione disattiva miratamente i controlli di protezione Gmail per i messaggi di simulazione corrispondenti. Non protegge alcun dominio email produttivo, non sostituisce alcuna configurazione MX, SPF, DKIM o DMARC e non è il collegamento di Google Workspace di Sophos Email Gateway. Utilizzate esclusivamente i valori della documentazione Sophos Phish Threat corrente e della campagna effettivamente avviata.

Prerequisiti e portata delle modifiche

Occorrono:

Accesso amministratore su Sophos Fusion (in precedenza Sophos Central) e su Console di amministrazione Google;
una licenza Sophos Phish Threat e un amministratore di campagna autorizzato;
un piccolo gruppo pilota con destinatari di test appositamente nominati;
una finestra di modifica disponibile e accesso a Email Log Search e ai risultati della campagna Phish Threat;
la possibilità di documentare le impostazioni Gmail esistenti prima di modificarle;
un owner ciascuno per campagna, regole di Google Workspace e successiva pulizia.

Raccogliete in anticipo screenshot o esportazioni delle impostazioni interessate. Salvate Email allowlist e Inbound gateway come stato iniziale a livello di tenant dell’organizzazione principale, inclusi tutti gli IP, TLS e le opzioni Message Tagging. Documentate inoltre, per Spam e Content compliance, l’unità organizzativa e lo stato di ereditarietà. Non modificate alcuna lista di indirizzi condivisa i cui altri utilizzi non siano completamente noti.

Gli indirizzi IP di invio Phish Threat attualmente documentati sono:

54.240.51.52
54.240.51.53

Verificate nuovamente entrambi i valori immediatamente prima della modifica nelle informazioni Sophos IP addresses and domains. Solo se il tenant utilizza effettivamente Sophos Mailflow, aggiungete gli indirizzi IP del flusso di posta indicati da Sophos per la propria regione. Non rendete questi valori regionali disponibili in modo generico per tenant senza flusso di posta e non assumete nulla da un tenant estraneo o da un vecchio ticket.

Le informazioni di Sophos elencano letteralmente i valori amazonses.com, ~eu-west-1.awstrack.me~ e ~sophos-phish-threat.go-vip.co~ come domini o URL da autorizzare. Solo awstrack.me viene descritta esplicitamente come percorso di tracciamento clic. Documentate questi valori di origine senza modificarli e utilizzate, durante l’inserimento, la sintassi del rispettivo sistema di destinazione; non ricavate dalle tilde né una semantica di wildcard né un ruolo tecnico. Per la Address list di Gmail, invece, utilizzate esclusivamente i domini del mittente indicati in Sending domains and IPs o nei dettagli della campagna specifica. I valori URL non costituiscono una prova di un dominio mittente.

Pianificare prima la modifica come progetto pilota

Stabilite un’unità organizzativa pilota con pochi account di test per Spam e Content compliance o selezionate un’unità già prevista a tale scopo.
Documentate lì l’ereditarietà e lo stato locale di questi due tipi di regole.
Eseguite un’analisi degli impatti per le modifiche a livello di tenant su Email allowlist e Inbound gateway. Registrate in particolare i gateway esistenti, i percorsi di consegna diretta, altri sistemi sugli stessi IP e lo stato globale di reset.
Rilevate l’ID della campagna, il periodo di invio, il dominio del mittente previsto, i destinatari, la landing page e gli indirizzi IP di invio attuali.
Definite un test positivo, un mittente esterno simile ma non corrispondente e un destinatario al di fuori dell’unità organizzativa pilota.
Stabilite criteri di interruzione: bypass imprevisti all’interno o all’esterno del pilota, un’eccezione che agisce troppo ampiamente, mancanza di TLS o risultati di header o tracking non spiegabili.

Le quattro configurazioni di Google riportate di seguito fanno parte della procedura documentata da Sophos, ma in Google hanno ambiti di applicazione diversi e non costituiscono quattro livelli di protezione indipendenti. Non estendete le regole limitabili alle OU oltre il necessario e non aggiungete reti o domini sconosciuti solo per superare un test fallito.

Interazione IP: Google tratta un IP in Inbound gateway come gateway e cerca nelle righe Received: l’IP pubblico originale di origine. Se lo stesso IP è presente anche in Email allowlist, tale voce nella lista consentiti non influisce quindi sulla consegna o sul filtro antispam. Tuttavia, Sophos menziona entrambi i passaggi. Verificate dopo l’impostazione, tramite Email Log Search e l’intera catena Received:, quale IP di origine Google rileva e quale regola viene effettivamente applicata. Non deducete una protezione doppia dalla presenza di entrambe le voci.

Inserire gli indirizzi IP di spedizione in Email allowlist

Accedete alla Console di amministrazione Google.
Aprite Menu > Apps > Google Workspace > Gmail.
Selezionate Spam, Phishing and Malware.
Selezionate espressamente l’organizzazione principale a sinistra. L’impostazione vale comunque sempre per l’intero dominio e non può essere limitata a un’unità organizzativa.
Aprite il simbolo di modifica su Email allowlist.
Inserite esclusivamente gli indirizzi IP di spedizione Sophos Phish Threat attualmente confermati.
Salvate con Save.

Non adottate reti CIDR se Sophos menziona solo indirizzi singoli. Non sostituite le voci esistenti prima di averne chiarito lo scopo e il proprietario. Annotate quali due valori a livello di tenant sono stati aggiunti con questa modifica, in modo che la rimozione globale non elimini accidentalmente eccezioni di terzi. Prestate attenzione all’interazione descritta sopra se gli stessi IP sono anche registrati come gateway.

Configurare Inbound gateway per Phish Threat

Aprite sotto Menu > Apps > Google Workspace > Gmail > Spam, Phishing and Malware a sinistra esplicitamente l’organizzazione più alta e poi l’impostazione Inbound gateway. Questa configurazione vale per l’intero tenant; non esiste alcun override per l’OU pilota. Attivatela solo dopo un’analisi dell’impatto e la sicurezza della configurazione globale completa iniziale.

Sotto Gateway IPs:

Fate clic su Add e aggiungete ogni indirizzo IP Phish Threat confermato.
Attivate Automatically detect external IP (recommended).
Disattivate Reject all mail not from gateway IPs. Questa configurazione Phish Threat non deve scartare tutti gli altri percorsi di consegna legittimi del tenant.
Attivate Require TLS for connections from the email gateways listed above.

Sotto Message Tagging:

Selezionate Message is considered spam if the following header regexp matches.
Inserite sotto Regexp un valore volutamente non corrispondente, ad esempio 344jedjs=-0sdfee3.
Selezionate Message is spam if regexp matches.
Attivate Disable Gmail spam evaluation on mail from this gateway; only use header value.
Salvate con Save.

L’espressione regolare non è intenzionalmente una caratteristica di un messaggio reale. Prima di salvare, verificate che non appaia nelle intestazioni esistenti o nei vostri tag del gateway di posta. Non deve essere sostituita da .*, un’espressione vuota o una caratteristica aziendale generica. Il limite IP e il TLS obbligatorio sono i limiti principali di questa eccezione gateway.

Creare un proprio Address list per i domini del mittente di Sophos

Aprite Menu > Apps > Google Workspace > Gmail > Spam, Phishing and Malware.
Selezionate espressamente a sinistra l’unità organizzativa pilota. Gli utenti nelle unità subordinate possono ereditare l’impostazione; controllarne quindi l’effettiva portata.
Fate clic su Configure sotto Spam.
Assegnate un nome chiaro all’impostazione, ad esempio Phish Threat bypass.
Selezionate Bypass spam filters for messages from senders or domains in selected lists.
Aprite Create or edit list e fate clic su Add address list sotto Manage address lists.
Create una lista utilizzata esclusivamente per Sophos Phish Threat, ad esempio Sophos Phish Threat.
Inserite solo i domini mittente attualmente confermati da Sophos o dalla specifica visualizzazione della campagna; non adottate valori URL come dominio mittente.
Disattivate la richiesta di autenticazione per questo elenco documentato Phish Threat e salvate con Save.
Tornate all’impostazione Spam dell’unità organizzativa pilota e selezionate Use existing list.
Selezionate Bypass spam filters and hide warnings for messages from senders or domains in selected lists, poi nuovamente Use existing list e la lista appena creata.
Salvate con Save.

La disattivazione della richiesta di autenticazione è un requisito del produttore strettamente limitato a questa lista di simulazioni, non una raccomandazione per elenchi consentiti generali. Non mescolate domini di fornitori, partner o della vostra azienda in questa lista. Se un dominio della campagna viene rimosso, verrà rimosso esattamente questo elemento.

Configurare Content compliance con IP e token

Aprite Menu > Apps > Google Workspace > Gmail > Compliance.
Selezionate esplicitamente a sinistra l’unità organizzativa pilota e verificate quali unità subordinate ereditano questa impostazione.
Fate clic su Configure sotto Content compliance.
Assegnate un nome univoco, ad esempio Phish Threat content compliance.
Selezionate sotto Email messages to affect la direzione Inbound.
Fate clic su Add sotto If any of the following match the message.
Selezionate Metadata match.
Impostate Attribute su Source IP e Match type su Source IP is within the following range.
Inserite un indirizzo IP Phish Threat confermato e salvate l’espressione. Ripetete questo procedimento per ogni altro indirizzo confermato.
Aggiungete un’altra espressione sotto If any of the following match the message.
Selezionate Advanced content match, quindi Location > Full headers e Match type > Contains text.
Inserite sotto Content esattamente X-PT-TOKEN e salvate l’espressione.
Sotto If the above expressions match, selezionate l’azione Bypass spam filter for this message in Spam.
Selezionate sotto Encryption (onward delivery only) l’azione Require secure transport (TLS).
Salvate l’intera regola con Save.

Confine di sicurezza: La regola documentata di Google utilizza If any of the following match the message. Ciò consente di far scattare l’azione sia con un IP sorgente appropriato sia con il nome header X-PT-TOKEN. L’header non rappresenta quindi una prova di origine crittografica. Limitate la regola tramite unità organizzativa pilota, direzione e ciclo di vita; non utilizzate X-PT-TOKEN in altre regole di bypass e verificate nel test di non corrispondenza che i messaggi esterni normali non ricevano eccezioni. Non modificate any autonomamente in all, poiché ciò diverge dal processo documentato di Sophos e può alterare la consegna delle campagne.

Secondo l’interfaccia utente, l’opzione Require secure transport (TLS) in questa sezione riguarda solo la consegna successiva. Il requisito TLS per le connessioni in ingresso viene configurato separatamente in Inbound gateway; nessuna delle due opzioni sostituisce l’altra.

Verificare attentamente la configurazione

Attendete che le modifiche a livello di tenant e le regole dell’unità organizzativa pilota diventino effettive. Avviate quindi una piccola campagna pilota Phish Threat con un nome chiaro. Non richiedete credenziali reali e non inviate messaggi senza controllo a liste di distribuzione utilizzate in produzione.

Eseguite almeno questi controlli:

Destinatario pilota idoneo: L’e-mail di simulazione viene consegnata nella posta in arrivo. Dominio del mittente, destinatario, orario e ID della campagna corrispondono.
Origine e effetto della regola: Le intestazioni complete contengono la catena Received: e X-PT-TOKEN attese. Email Log Search e le intestazioni vengono valutate insieme per dimostrare l’IP sorgente determinato da Google e la regola del gateway, della whitelist, dello spam o della conformità effettivamente applicata.
Trasporto: Controllate il TLS in entrata in Email Log Search e/o nella specifica prova di trasporto Received:. La semplice presenza di header completi non costituisce una prova TLS generale. L’opzione di conformità Require secure transport (TLS) riguarda separatamente l’inoltro.
Eventi Sophos: L’invio, la consegna e un clic controllato o una segnalazione appariranno solo per l’utente di test corretto nella campagna.
Mittente non corrispondente simile: Una normale e-mail di test esterna senza un IP Sophos confermato e senza X-PT-TOKEN passa i controlli regolari Gmail. Non deve ricevere il bypass solo a causa di una regola di dominio o jolly troppo ampia.
Destinatari al di fuori del pilota: Le regole limitate all’OU Spam e Content compliance non devono applicarsi lì. Gli effetti a livello di tenant Email allowlist e Inbound gateway, invece, possono riguardare anche questo destinatario e devono essere valutati separatamente in base a Email Log Search e agli header.
Contenuto dell’intestazione non appropriato: Il valore intenzionalmente impossibile di Message Tagging non deve classificare i messaggi normali come simulazione Phish Threat.

Un messaggio consegnato, da solo, non dimostra che sia stata applicata l’eccezione corretta. Ai fini dell’accettazione, conservate come prove l’ID del messaggio, il timestamp, le intestazioni complete, il risultato del log Google e il risultato della campagna Sophos. Non documentate password reali né contenuti riservati dei messaggi.

Limitare gli errori in modo mirato

La simulazione non arriva: Controllate prima lo stato della campagna e l’indirizzo del destinatario, poi Email Log Search. Se non esiste una voce su Google, confrontate l’IP effettivamente inviato con l’elenco Sophos attuale. Se esiste una voce, distinguete tra lo stato del gateway/Allowlist a livello tenant e quello a livello OU e l’ereditarietà delle regole spam/compliance. Successivamente, controllate l’azione di spam/quarantena e gli errori TLS.
Il messaggio finisce nello spam: Confrontate l’IP sorgente, il dominio mittente visibile o di envelope, Address list, X-PT-TOKEN e l’ambito della regola Content compliance. Non impostate un bypass di dominio più ampio finché la discrepanza non è stata spiegata.
Gmail rifiuta la connessione: Controllate entrambi i Gateway IPs, la regola efficace e Require TLS for connections from the email gateways listed above. Non disattivate TLS in modo permanente; in caso di errore di trasporto riproducibile con ID messaggio, ora e risultato SMTP, procedete all’escalation.
Mail legittima bypassata inaspettatamente: Interrompete la campagna pilota. Verificate tramite Email Log Search e header completi se è intervenuta una modifica della gateway/allowlist a livello tenant o una regola di spam/compliance limitata a OU. Disattivate la nuova eccezione identificata secondo il piano di ripristino documentato. Controllate successivamente se il messaggio contiene X-PT-TOKEN, proviene da un IP registrato o corrisponde a un dominio mittente troppo ampio.
Mancanza di clic nonostante la consegna: Controllate se le estensioni del browser o i filtri web bloccano l’accesso a awstrack.me. Sophos utilizza questo percorso di tracciamento AWS per gli eventi di clic. Non modificate il bypass del mittente Gmail se è interessato solo il tracciamento web.
La campagna utilizza un dominio mittente diverso: Confrontate il valore del mittente indicato in Sending domains and IPs o nei dettagli della campagna con la Address list dedicata. Aggiungete solo l’ambito del mittente documentato; non ricavatelo da un URL o dalle relative tilde.
Connessione a Google non riuscita: Controllate Project Creation Settings nella Console di amministrazione Google. Si tratta di un’impostazione di autorizzazione o di Google Cloud e non viene risolta tramite liste di permessi Gmail aggiuntive.
Il tracking mostra utenti falsi o clic automatici: Controllate prima di tutto reindirizzamenti, destinatari di gruppi, scanner di link intermedi e header. Non ampliate l’eccezione; i controlli di sicurezza automatici possono aprire i link prima dell’utente.

Se un errore rimane riproducibile, fornite a Sophos Support l’ID della campagna, l’ID del messaggio, il timestamp UTC, il mittente e il destinatario, l’IP di origine, gli header rilevanti e il risultato del protocollo Google. Rimuovete o mascherate i contenuti personali non necessari.

Eseguire il rollback in sicurezza

Un rollback ripristina lo stato originale documentato. Interrompete o mettete in pausa prima le campagne pilota attive, in modo che durante il rollback non si verifichino risultati ambigui. Trattate Inbound gateway e Email allowlist come modifiche a livello di tenant; solo Spam e Content compliance vengono ripristinate nell’unità organizzativa pilota.

Disattivate o rimuovete nell’unità organizzativa pilota la nuova regola Content compliance.
Rimuovete lì la nuova regola Spam e ripristinate lo stato di ereditarietà originale. Eliminate la Address list dedicata solo quando nessun’altra regola la utilizza.
Selezionate l’organizzazione principale e ripristinate esattamente la configurazione tenant-wide precedente Inbound gateway, inclusi stato di attivazione, IP, TLS e Message Tagging. Se in precedenza nessun gateway era attivo, ripristinate questo stato globale; non esiste un override locale per l’OU.
Rimuovete nell’organizzazione principale da Email allowlist esclusivamente gli indirizzi IP Phish Threat aggiunti tramite questa modifica e ripristinate così lo stato iniziale sicuro a livello di tenant.
Attendete che le modifiche diventino effettive. Testate un normale messaggio esterno destinato a un precedente destinatario pilota e a un destinatario al di fuori del pilota; controllate Email Log Search e le intestazioni per verificare lo stato globale e locale ripristinato.
Registrate il motivo, il momento, la persona esecutrice e il risultato del controllo nella modifica.

Non eliminate alcuna lista condivisa e non sovrascrivete alcuna regola esistente di Google solo per reimpostare il pilota. Se lo stato iniziale globale non è chiaramente documentato, non rimuovete voci altrui e non tentate di indovinare lo stato precedente del gateway. Fermate la campagna, annullate solo le aggiunte chiaramente riconducibili a questa modifica dopo una verifica a quattro occhi e chiarite il resto del ripristino con l’amministratore responsabile di Google Workspace.

Gestire le eccezioni sul funzionamento della campagna

La configurazione non è un passaggio unico «Consenti per sempre». Verificate prima di ogni serie di campagne e almeno una volta ogni trimestre:

indirizzi IP di spedizione Sophos Phish Threat attuali e, solo se Sophos Mailflow è effettivamente utilizzato, i valori della propria regione di flusso di posta;
i domini mittente specificati concretamente in Sending domains and IPs oppure nei dettagli della campagna;
Proprietario, scopo a livello di tenant di Email allowlist e Inbound gateway, scopo OU di Spam e Content compliance e la data di revisione di ogni regola Google;
colpi inaspettati su X-PT-TOKEN, caratteri jolly troppo ampi e voci di elenco degli indirizzi orfane;
Risultati TLS, registri di Google e la qualità degli eventi delle campagne Sophos.

Rimuovete gli IP e i domini non più necessari dopo un test controllato. In una campagna di sensibilizzazione permanente, rimangono attivi solo i valori ancora utilizzati; i domini temporanei della campagna vengono rimossi al termine. Ogni estensione viene nuovamente sottoposta ad analisi degli impatti, test di corrispondenza, non corrispondenza e ambito. Un pilota può limitare solo le regole Spam e Content compliance, non Email allowlist o Inbound gateway. In questo modo la consegna rimane misurabile, senza trasformare una simulazione di phishing in un bypass generale permanente.