Sophos Email: configurare TLS e Secure Message in sicurezza

Una Secure Message policy definisce come Sophos Email protegge i messaggi e cosa accade se il metodo scelto non è disponibile. Per la maggior parte delle connessioni TLS, Preferred TLS 1.3 è il punto di partenza più robusto: Sophos tenta TLS 1.3 e, se necessario, passa a TLS 1.2. Imporre Required TLS 1.3 o Required TLS 1.2 solo ai partner il cui sistema di invio o ricezione soddisfa comprovabilmente il requisito esatto.

Percorso rapido: attivare prima TLS 1.3 e le cifrature necessarie sul proprio server o servizio di posta e testare il flusso verso Sophos. In My Products > Email Security > Policies, creare una policy Secure Message, definire l’ambito interno ed eventualmente esterno, scegliere direzione e metodo in Settings e impostare un piccolo gruppo pilota su Policy is enforced. Per i messaggi in uscita, decidere prima se un errore TLS possa consentire la consegna non cifrata o debba attivare Fallback to push encrypt the entire message. Verificare quindi in Message History versione TLS e stato di consegna per ogni partner e direzione.

Avviso: TLS deve essere attivo sul proprio server o servizio di posta prima di configurare qualsiasi metodo Secure Message. In particolare, il gateway deve supportare TLS 1.3 prima di scegliere Required TLS 1.3. In caso contrario, la connessione con Sophos può interrompersi e bloccare la posta in entrata e in uscita.

Registrare prerequisiti e rollback prima della modifica

Questa guida riguarda Sophos Email in Sophos Central, non Mail Protection eseguito su Sophos Firewall. In EMS mode non è possibile configurare Secure Message Policies.

Prima della modifica, registrare:

nome, ambito, ordine, direzione e stato di applicazione attuali della policy, oltre all’eventuale orario di disattivazione;
utenti, gruppi o domini interni e indirizzi o domini esterni interessati;
versioni TLS e cifrature del proprio server e dei peer pilota;
se il peer presenta un certificato per il proprio dominio destinatario;
la decisione di fallback autorizzata per ciascun partner;
mittenti e destinatari di test, Message-ID, finestra di modifica e responsabili delle due piattaforme.

Sophos raccomanda TLS 1.3. La stringa di cifratura documentata è esattamente TLSv1.2+FIPS:kRSA+FIPS:!eNULL:!aNULL. TLS 1.0 e TLS 1.1 non sono supportati per la consegna in entrata o in uscita dal 1° gennaio 2024. Il server non deve quindi essere limitato a queste vecchie versioni.

Per il rollback conservare screenshot o dati esportati della policy precedente. Una nuova policy pilota o clonata può tornare a Policy Bypassed, ripristinando l’ordine precedente. Non eliminare una policy funzionante prima di completare tutti i test.

Scegliere consapevolmente metodo e comportamento in caso di errore

TLS: cifratura del trasporto nel normale client di posta

Secure using TLS protegge la connessione SMTP durante il trasporto; mittente e destinatario continuano a usare il client abituale. Non significa che il messaggio rimanga in un contenitore cifrato dopo la consegna alla casella.

I livelli TLS hanno effetti differenti:

Preferred TLS 1.3 tenta TLS 1.3 e usa TLS 1.2 se il peer non supporta TLS 1.3. Sophos raccomanda questa scelta più flessibile perché riduce il rischio di interrompere lo scambio.
Required TLS 1.3 accetta solo TLS 1.3. Se il peer non lo supporta, il messaggio non viene scambiato con un’altra versione TLS.
Required TLS 1.2 accetta solo TLS 1.2. In questa modalità TLS 1.3 non sostituisce la versione selezionata.

Senza tale imposizione, Sophos tenta TLS per impostazione predefinita quando una connessione TLS è possibile. Questo comportamento opportunistico favorisce la compatibilità, ma non garantisce la cifratura con ogni peer. Se una versione o verifica del certificato è un requisito contrattuale, assegnare al partner un ambito Required ristretto ed eseguire un test di errore documentato.

Per connessioni in uscita con Required TLS 1.3 o Required TLS 1.2 si può attivare Verify certificate. Sophos verifica che il certificato sia stato emesso per il dominio destinatario; in caso contrario non consegna. Inserire quindi nell’ambito esterno il vero dominio destinatario e verificare host e certificato presentati dal percorso MX; un dominio dal nome simile non è equivalente.

Non confondere Push Encryption o Portal Encryption con TLS

Push Encryption è disponibile solo in uscita. Sophos converte il contenuto in un documento protetto da password; gli allegati Microsoft Office, ZIP e PDF usano la cifratura nativa, mentre altri formati possono essere forniti come PDF. Al primo invio, il destinatario crea una password Sophos Secure Message tramite la notifica, il cui link scade dopo 30 giorni. La password vale solo per messaggi della stessa regione del messaggio originale. Per l’apertura da parte del destinatario, l’uso della password e le risposte sicure, consultare Gestire la cifratura Portal e Push di Sophos Email.

Portal Encryption è anch’esso solo in uscita e richiede una licenza Sophos Email con Portal Encryption Add-on. Il destinatario legge e risponde in Sophos Secure Message e crea un account al primo messaggio. Branding, amministrazione destinatari, scadenza e recall sono un flusso operativo separato; qui si seleziona soltanto il metodo nella policy.

Secure using S/MIME richiede CA, certificati di utenti e destinatari e chiavi private già configurati. S/MIME può firmare senza necessariamente cifrare. Provisioning, trust, estrazione e reset dei certificati appartengono quindi a una procedura S/MIME separata e non sono sostituiti da Verify certificate per TLS.

Per TLS in uscita verso un peer senza TLS, Sophos offre Allow unencrypted delivery o Fallback to push encrypt the entire message e raccomanda il fallback Push. Se il fallback Push è configurato e la negoziazione TLS non riesce, Sophos invia il messaggio con Push Encryption anziché metterlo in coda per nuovi tentativi TLS. Consentire la consegna non cifrata solo se la classificazione dei dati lo permette espressamente. Push è adatto solo se i destinatari possono aprire documenti protetti e accettano la registrazione iniziale. Senza fallback autorizzato e senza negoziazione TLS, non aspettarsi un passaggio silenzioso al testo in chiaro.

Creare e limitare la Secure Message policy

Aprire My Products > Email Security > Policies e fare clic su Add Policy.
Selezionare Secure Message e Continue. Usare un nome chiaro, ad esempio SM-Outbound-Partner-TLS13.
In Internal, aggiungere utenti, gruppi o domini. Basta una corrispondenza in una qualsiasi lista. Passare sul nome utente per verificarne l’indirizzo.
Per una regola partner, aprire External e aggiungere indirizzo o dominio esatto, manualmente o da file. Verificare inclusione o esclusione; il valore predefinito è Include all. La policy si applica quando una voce interna comunica con una esterna.
Aprire Settings, scegliere Inbound o Outbound e attivare Secure inbound messages o Secure outbound messages.
In Select the method to secure messages, scegliere il metodo approvato. Per TLS impostare Preferred TLS 1.3, Required TLS 1.3 o Required TLS 1.2.
Se necessario per un partner Required TLS in uscita, attivare Verify certificate. Definire esplicitamente il comportamento di fallback o in caso di errore, senza dedurlo dal nome.
Per Push o Portal Encryption, scegliere la lingua dei messaggi di notifica e registrazione inviati al destinatario.
In Choose how to secure, decidere se proteggere tutti i messaggi o lasciare che gli utenti attivino la protezione con un tag nell’oggetto. Il tag fisso secure: attiva sempre la cifratura, anche con trigger personalizzati. secureTest: o secureFull: devono essere completi ed esatti all’inizio dell’oggetto; una sottostringa non basta.
Impostare la policy pilota su Policy is enforced, salvare e verificarne la priorità. È possibile definire data e ora per la disattivazione automatica.

Usare Clone per ambiti simili. Un clone nasce in Policy Bypassed, un clone della Base Policy non contiene utenti, gruppi o domini e per impostazione predefinita ha priorità sull’originale. Verificare ambito, impostazioni e ordine prima di Policy is enforced.

I tenant migrati possono avere policy con nome iniziante per Migrated. Contengono le precedenti impostazioni TLS e di cifratura di Global Settings e gli utenti e domini protetti durante la migrazione. Possono essere modificate, rinominate, unite o eliminate, ma solo dopo aver confrontato ambito, metodo, fallback e priorità con lo stato desiderato.

Interazione con Data Control

Un’azione di cifratura in uscita in una policy Data Control sostituisce il metodo scelto nella Secure Message policy. Se un messaggio usa inaspettatamente Push o Portal invece di TLS, controllare entrambe e le regole Data Control applicabili. Controllare separatamente ambito e ordine, perché le famiglie svolgono compiti distinti.

Convalidare con destinatari rappresentativi

Per l’accettazione, inviare messaggi controllati e non riservati ad almeno un destinatario nell’ambito e uno di confronto fuori. Il piano TLS per un partner include:

un peer che supporta la versione scelta e, con Verify certificate, presenta un certificato corrispondente;
un peer che supporta TLS 1.2 ma non TLS 1.3, per testare Preferred TLS 1.3;
un test negativo autorizzato in cui il requisito TLS o del certificato non è soddisfatto;
con fallback Push, un destinatario che completa notifica, creazione password e apertura;
con tag oggetto, un messaggio con trigger esatto, uno incompleto e uno senza trigger.

In Message History, aprire Filter a sinistra, scegliere la categoria Secure message e filtrare per versione TLS. Aprire l’oggetto. In Message Details, passando sui tre puntini in Status si vede se la connessione era protetta con TLS e la versione autenticata. Se Sophos non ha verificato la firma della CA emittente, SMTP Text segnala che la consegna TLS non era attendibile.

Un’accettazione riuscita registra nome e priorità policy, ambiti interno ed esterno, Message-ID, timestamp, destinatario, metodo, versione TLS osservata, risultato certificato, fallback ed esito finale. Una voce in Message History non prova da sola che il destinatario abbia potuto leggere il messaggio.

Analizzare errori TLS, coda e certificati

Se Sophos Email non stabilisce una connessione TLS richiesta e nessun fallback configurato gestisce il messaggio, l’e-mail non viene inviata. Sophos la mantiene in coda per nuovi tentativi fino a sette giorni, poi la elimina. Ogni tentativo TLS crea una voce Processing: Check TLS; dopo l’errore finale, il log indica che il messaggio è stato eliminato a causa della TLS policy. Non è un meccanismo adatto per testare per sette giorni in produzione un’impostazione Required errata.

Controllare nell’ordine:

La Secure Message policy prevista è su Policy is enforced, con ambiti corretti e priorità voluta?
Un’azione Data Control sostituisce il metodo o il tag fisso secure: attiva la cifratura?
Il proprio server e il peer supportano la versione scelta? TLS 1.0 e 1.1 non sono fallback.
TLS e le cifrature richieste sono attivi, in particolare TLSv1.2+FIPS:kRSA+FIPS:!eNULL:!aNULL?
Con Verify certificate, il certificato corrisponde al dominio destinatario reale e Sophos verifica la CA emittente?
Message History, Processing: Check TLS e SMTP Text indicano errore di versione, trust o negoziazione?

Se la causa resta incerta, raccogliere nome, ambito e priorità policy, Message-ID, timestamp, direzione, dominio destinatario, versioni attesa e osservata e testi History e SMTP pertinenti per Sophos Email Support. Non inserire chiavi private, password o contenuti riservati nel ticket.

Eseguire il rollback in sicurezza

Se il flusso è inatteso, riportare prima la nuova policy su Policy Bypassed oppure usare l’orario di disattivazione predisposto e ripristinare la priorità precedente. Ripetere i test in entrambe le direzioni e confermare il percorso precedente in Message History e presso il destinatario. Non allentare contemporaneamente versione TLS, verifica certificato e ambito, altrimenti la causa resta nascosta.

Un fallback temporaneo a Preferred TLS 1.3, Push Encryption o consegna non cifrata è ammesso solo con approvazione esplicita del data owner e del responsabile del change. Se il testo in chiaro è vietato, è meglio trattenere il messaggio mentre il partner corregge versione TLS, cifrature o catena del certificato. Ampliare l’ambito o ripulire una vecchia policy Migrated solo dopo test pilota e negativi riusciti.