Configurare la crittografia email SPX su Sophos Firewall

Con Secure PDF Exchange, o SPX, Sophos Firewall converte un’email in uscita e i relativi allegati in un file PDF protetto da password. Il destinatario non ha bisogno di un proprio client di crittografia. A seconda del modello scelto, riceve una password monouso, utilizza una password memorizzata oppure ne registra una autonomamente.

Per un funzionamento affidabile devono cooperare quattro elementi: un template SPX, un trigger inequivocabile, un canale sicuro per la password e, se necessario, lo SPX Reply Portal. In seguito si testano un flusso positivo e uno negativo. La sola consegna di un PDF non dimostra né che sia scattata la policy corretta né che la registrazione della password e la risposta sicura funzionino.

SPX in otto passaggi

1. Verificare la licenza Email Protection, il flusso di posta MTA, il supporto del modello e il certificato.
2. Decidere se la crittografia viene attivata da un dominio protetto, una corrispondenza Data Control o dal mittente.
3. Creare un template personalizzato in Email > Encryption > SPX templates > Add.
4. Scegliere consapevolmente il tipo di password, la crittografia PDF, la notifica e il Reply Portal.
5. Proteggere FQDN, reti consentite e porta in Email > Encryption > SPX portal settings.
6. Assegnare il template nella policy SMTP route and scan o come template predefinito scelto consapevolmente.
7. Testare PDF, canale della password, registrazione e risposta con un destinatario esterno.
8. Eseguire un test negativo senza trigger SPX e documentare Mail logs, log MTA e rollback.

⚠️ Un campo Allowed networks vuoto nello SPX Portal non significa «nessun accesso», ma torna a Any. Sophos consiglia inoltre una porta dedicata per il Reply Portal. FQDN del portale, certificato, origini consentite e canale della password devono quindi essere definiti prima del test in produzione.

Quando SPX è adatto

SPX è utile quando destinatari esterni devono ricevere contenuti riservati come PDF protetti senza installare un client di crittografia. Può essere utilizzato sia in MTA mode sia in Legacy mode. Questa procedura usa MTA mode perché consente di collegare in modo chiaro dominio, Data Control e routing nella policy SMTP.

SPX non è una crittografia del trasporto tra server di posta e non è una crittografia end-to-end tra due client email. Il firewall elabora il testo in chiaro, genera il PDF e controlla la password o la registrazione. Il PDF può poi continuare a esistere fuori dal firewall in caselle di posta, archivi o download. Ambito dei destinatari, conservazione e trasmissione della password fanno quindi parte del progetto di sicurezza.

I prerequisiti sono:

• una licenza Email Protection valida;
• un flusso di posta in uscita già testato attraverso Sophos Firewall;
• un destinatario esterno di test documentato;
• un FQDN attendibile e un certificato corrispondente per i portali SPX utilizzati;
• un canale sicuro separato per le password quando non vengono registrate dal destinatario;
• una via di ripristino con cui rimuovere nuovamente le assegnazioni di template e policy.

Secondo l’attuale documentazione Sophos, SPX non è disponibile su XGS 87/87w. Inoltre, MTA mode completo non è disponibile su XGS 88/88w. Configurare Mail Protection in MTA mode spiega flusso di posta, licenza, relay e limiti dei modelli.

Definire trigger e priorità

SPX può essere attivato in tre modi. Se sono configurati più metodi, Sophos Firewall applica questo ordine in MTA mode:

1. Dominio protetto: Il template SPX selezionato in Domains and routing target si applica ai messaggi in uscita del dominio protetto corrispondente.
2. Data control list: Solo se non è impostato alcun template SPX a livello di dominio, una corrispondenza Data Control può applicare il template selezionato per la lista.
3. Trigger del mittente: Solo quando né il dominio né Data Control forniscono un template, si applica il metodo del mittente configurato in Default SPX template.

Un’assegnazione per dominio è ampia ed è adatta solo quando ogni messaggio in uscita corrispondente deve effettivamente essere cifrato. Data Control è adatto a tipi di contenuto definiti, ma deve essere testato con esempi positivi e negativi reali per individuare falsi positivi. Il trigger del mittente lascia a quest’ultimo la decisione, ma richiede una procedura del client di posta chiaramente documentata.

Prima della configurazione si definisce un solo trigger primario per ogni flusso di posta. Un secondo metodo non deve prevalere silenziosamente su un altro.

Creare il template SPX

L’esempio utilizza il template Finance-SPX-Recipient. Il nome è un valore di documentazione da adattare allo scopo e all’organizzazione.

1. Aprire Email > Encryption > SPX templates.
2. Selezionare Add.
3. Immettere un nome, ad esempio Finance-SPX-Recipient.
4. Impostare il nome dell’organizzazione per le notifiche.
5. Selezionare Encryption standard e PDF page size secondo i requisiti interni.
6. In Password type, selezionare il modello di password previsto.
7. Controllare oggetto, corpo del messaggio e istruzioni per il destinatario e adattarli se necessario.
8. Se sono necessarie risposte sicure, attivare Enable SPX reply portal.
9. Attivare Include original body into reply solo se il messaggio originale può essere incluso nella risposta.
10. Salvare il template.

Scegliere consapevolmente il modello di password

Sophos Firewall offre quattro modelli:

• Specified by sender: Il mittente imposta la password. Il firewall la rimuove prima dell’invio e non la memorizza. La password deve raggiungere il destinatario tramite un canale sicuro separato.
• Generate one-time password for every email: Il firewall genera una nuova password per ogni messaggio e la invia al mittente. Quest’ultimo la comunica separatamente al destinatario. La password non viene memorizzata.
• Generated and stored for recipient: Il firewall genera una password specifica per il destinatario, la invia al mittente e la riutilizza fino alla scadenza.
• Specified by recipient: Un destinatario non ancora registrato riceve un link di registrazione, imposta la propria password e la utilizza fino alla scadenza per ulteriori messaggi SPX dell’organizzazione.

Per un rapporto continuativo con un partner, Specified by recipient è spesso il processo più facile da comprendere. Una password monouso può essere più adatta per un singolo invio particolarmente sensibile. Non è opportuno mescolare senza pianificazione diversi modelli di password memorizzate per lo stesso destinatario, perché dovrebbe identificare la password corrispondente a ogni messaggio.

Con Specified by sender, l’oggetto può usare il formato [secure:<password>]<subject text>. Il mittente deve poi comunicare la password separatamente. Per Microsoft Outlook, Sophos fornisce un Outlook Add-in in Authentication > Client downloads.

L’attuale documentazione Sophos utilizza due grafie diverse dell’header per altri client di posta: X-Sophos-SPXEncrypt: yes nella pagina del template e X-Sophos-SPX-Encrypt: yes nella pagina generale Encryption. Questa discrepanza non viene trattata come una ricetta da copiare e incollare. Prima di un rollout in produzione va verificata la grafia funzionante sul build SFOS utilizzato. Dove possibile, una policy, Data Control o il Sophos Outlook Add-in rappresentano un trigger più tracciabile.

Progettare la notifica senza creare un’altra fuga di dati

Le variabili disponibili per le notifiche includono:

• ENVELOPE_TO
• PASSWORD
• ORGANIZATION_NAME
• SENDER
• REG_LINK

Sono supportati formattazione HTML semplice e link. Il testo deve spiegare chi ha inviato il messaggio, come ottenere la password in modo sicuro e per quanto tempo sono possibili registrazione o risposta. Credenziali o contenuti email riservati non devono essere ripetuti in una notifica non protetta.

Proteggere i portali SPX

La registrazione delle password e l’accesso al portale sono definiti in Email > Encryption > SPX portal settings:

1. In Hostname, inserire il FQDN con cui i destinatari esterni raggiungono effettivamente il portale.
2. In Allowed networks, impostare solo le reti di origine necessarie. Any è appropriato solo quando destinatari esterni arbitrari devono raggiungere il portale e il rischio viene accettato consapevolmente.
3. Documentare la porta. Il Password Registration Portal usa per impostazione predefinita TCP 8094.
4. Utilizzare una porta dedicata per lo SPX Reply Portal.
5. Impostare i periodi di validità per password non utilizzate, risposte sicure e link di registrazione.
6. Inserire i destinatari delle notifiche di errore SPX.

Se Allowed networks rimane vuoto, SFOS usa Any, perché lo SPX Reply Portal è attivo per impostazione predefinita nella zona WAN. Se il Reply Portal non è necessario, Sophos documenta l’uso di un indirizzo privato attendibile non utilizzato, ad esempio 169.254.0.1, come unica rete consentita per disattivarlo. Questo valore di documentazione non deve corrispondere a un indirizzo usato in produzione.

CAPTCHA è sempre attivo sullo SPX Portal e non può essere disattivato. Gestire consapevolmente CAPTCHA su Sophos Firewall spiega i limiti delle impostazioni CAPTCHA degli altri portali.

WebAdmin, User Portal, VPN Portal, Captive Portal e i due portali SPX utilizzano la stessa selezione centrale del certificato. Una modifica può quindi influire contemporaneamente su più servizi. Certificato, SAN, via di ripristino e URL reale del portale vanno pianificati con Gestire i certificati su Sophos Firewall. Un certificato Let’s Encrypt su Sophos Firewall può essere adatto a un nome pubblico.

Collegare il template alla policy SMTP

Per MTA mode, il template SPX viene selezionato nella policy SMTP route and scan corrispondente in Email > Policies and exceptions.

Utilizzare un dominio come trigger

In Domains and routing target, il template viene assegnato al dominio protetto. Si applica quindi ai messaggi in uscita corrispondenti. Un’assegnazione ampia per dominio viene prima testata con un mittente pilota e un destinatario esterno di test.

Utilizzare Data Control come trigger

1. Creare una lista con un nome chiaro in Email > Data control list oppure controllare quella esistente.
2. Attivare Data protection nella policy SMTP route and scan.
3. Assegnare il template SPX previsto alla Data Control List.
4. Eseguire un test positivo del contenuto e un test negativo simile.

Se è già impostato un template SPX in Domains and routing target, questo ha priorità sul template Data Control. Inoltre, una corrispondenza della Data Control List dimostra solo il match del contenuto configurato. Il flusso di posta reale deve confermare che sia stato cifrato il messaggio corretto.

Utilizzare un trigger del mittente

In Email > Encryption > SPX configuration, selezionare un Default SPX template. Si applica alla crittografia SPX attivata dal mittente solo quando la policy SMTP non fornisce già un template a livello di dominio o Data Control. None disattiva questo percorso predefinito.

Verificare il flusso di posta cifrato

Annotare ora del test, mittente, destinatario, oggetto e trigger atteso. Poi testare almeno questi casi:

1. Test positivo: Un messaggio in uscita attiva esattamente il template SPX previsto.
2. Test della password: Il destinatario riceve la password o il link di registrazione tramite il canale previsto e può aprire il PDF.
3. Test del contenuto: Oggetto, corpo e allegati compaiono nel PDF come previsto e sono leggibili.
4. Test della risposta: Se attivato, il link di risposta conduce al FQDN previsto e una risposta di test raggiunge il mittente originale.
5. Test negativo: Un messaggio simile senza trigger non viene inviato come PDF SPX.
6. Test della scadenza: Registrazione, password memorizzata e periodo di risposta si comportano in modo prevedibile dopo la validità definita.
7. Test del certificato: Browser e destinatario esterno ricevono una catena di certificati completa e attendibile per il FQDN del portale utilizzato.

Per la prima correlazione utilizzare Email > Mail logs, Log Viewer e i file MTA smtpd_main.log, smtpd_error.log e smtpd_panic.log. Correlare un messaggio di errore con la stessa email di test e lo stesso orario. Servizi e log di Sophos Firewall spiega l’accesso e gli altri file di log.

In HA, i log risiedono sul nodo che ha elaborato il traffico. Dopo un failover controllato, testare separatamente una nuova email SPX, la registrazione della password e la risposta. Non si presume che una sessione del portale esistente o una registrazione in corso continuino senza interruzioni. I concetti di base sono descritti in Cluster HA Sophos Firewall.

Circoscrivere gli errori in modo sistematico

Il messaggio non viene cifrato

Controllare direzione, dominio protetto, policy SMTP route and scan effettiva e priorità dei trigger. Per Data Control verificare anche Data protection, corrispondenza della lista e assegnazione del template. Per un trigger del mittente deve essere impostato un template predefinito e non deve essere sovrascritto da un template di dominio o Data Control. Le due grafie documentate dell’header non sono un motivo per distribuire entrambe senza test in produzione.

Il link di registrazione o il portale non è raggiungibile

Controllare FQDN, risoluzione DNS pubblica, porta, certificato, Allowed networks e validità del link. Un valore Allowed Networks vuoto viene trattato come Any e quindi non è uno stato di disattivazione sicuro. Se il client raggiunge un altro host o portale, URL, NAT o assegnazione del certificato non corrispondono al percorso pianificato.

Il PDF non si apre

Per prima cosa confrontare il tipo di password con il messaggio specifico. Una password monouso vale solo per quella email. Con password memorizzate o registrate, la causa può essere la scadenza o l’uso di più modelli. Dopo uno SPX Password Reset, il mittente deve comunicare nuovamente la nuova password al destinatario in modo sicuro.

La risposta sicura non arriva

Controllare Enable SPX reply portal nel template, periodo di risposta, FQDN del portale, porta, certificato e origini consentite. Poi esaminare Mail logs e i log MTA per la risposta specifica. L’apertura corretta del PDF non dimostra che il canale di ritorno funzioni.

La verifica DKIM fallisce dopo SPX

SPX modifica corpo e allegati. Se un messaggio viene firmato prima di questa modifica, la firma può risultare non valida al destinatario. Definire se il server di posta interno, Sophos Firewall o un gateway successivo firma dopo tutte le modifiche previste. La catena di elaborazione e un test esterno devono essere verificati insieme.

Eseguire un rollback sicuro

1. Rimuovere per prima cosa l’assegnazione SPX specifica da Domains and routing target o dalla Data Control List.
2. Se utilizzato, impostare Default SPX template su None.
3. Eseguire un test negativo in uscita e confermare che non venga generato alcun nuovo PDF SPX.
4. Ritirare Reply e Registration Portal solo se nessun’altra policy SPX attiva ne dipende.
5. Ripristinare gli accessi pubblici temporanei di porta, DNS o portale allo stato precedente documentato.
6. Eliminare il template solo quando nessuna policy o procedura operativa attiva vi fa più riferimento.
7. Conservare Mail logs e i log MTA dell’ultimo test cifrato e del primo non cifrato.

Creare un backup aggiornato di Sophos Firewall prima di modificare percorsi di posta e portali di produzione. SPX può continuare a funzionare in ambienti air gap, ma le dipendenze esterne DNS, certificati e portale devono restare raggiungibili separatamente. I limiti del prodotto sono descritti in Funzioni SFOS senza accesso a Internet.

Checklist operativa

• Licenza, modello, flusso di posta MTA e destinatario esterno sono stati verificati.
• Il trigger e la sua priorità sono documentati.
• Tipo di password e canale di consegna sicuro sono adatti al caso d’uso.
• FQDN del portale, certificato, porta e Allowed Networks hanno un ambito ristretto.
• L’assegnazione per dominio, Data Control o predefinita è inequivocabile.
• I test positivo, negativo, password, PDF e risposta sono riusciti.
• Mail logs e i log MTA possono essere correlati con il messaggio di test.
• Il failover HA e i log locali dei nodi sono inclusi nella procedura operativa.
• Responsabile, scadenze, data di revisione e rollback sono documentati.

FAQ