Naar de inhoud
Avanet

Sophos Email: TLS en Secure Message veilig configureren

Een Secure Message policy bepaalt hoe Sophos Email berichten beveiligt en wat er gebeurt als de gekozen methode niet mogelijk is. Voor de meeste TLS-verbindingen is Preferred TLS 1.3 het robuuste uitgangspunt: Sophos probeert TLS 1.3 en schakelt zo nodig over op TLS 1.2. Dwing Required TLS 1.3 of Required TLS 1.2 alleen af voor partners van wie het verzendende of ontvangende systeem aantoonbaar precies aan die eis voldoet.

Snelle route: activeer eerst TLS 1.3 en de benodigde ciphers op uw eigen mailserver of -dienst en test de mailstroom naar Sophos. Maak onder My Products > Email Security > Policies een Secure Message policy, leg de interne en zo nodig externe scope vast, kies richting en methode onder Settings en zet een kleine pilotgroep op Policy is enforced. Beslis voor uitgaande berichten vooraf of een TLS-fout onversleutelde bezorging mag toestaan of door Fallback to push encrypt the entire message moet worden afgehandeld. Controleer daarna per partner en richting de TLS-versie en bezorgstatus in Message History.

Waarschuwing: TLS moet op uw eigen mailserver of -dienst actief zijn voordat u een Secure Message-methode configureert. Vooral uw e-mailgateway moet TLS 1.3 ondersteunen voordat u Required TLS 1.3 kiest. Anders kan de verbinding met Sophos wegvallen en kan inkomende én uitgaande e-mail stoppen.

Leg voorwaarden en rollback vóór de wijziging vast

Deze handleiding geldt voor Sophos Email in Sophos Fusion (voorheen Sophos Central), niet voor Mail Protection op een Sophos Firewall. In EMS mode kunt u geen Secure Message Policies configureren.

Leg vóór de wijziging vast:

  • huidige policynaam, scope, volgorde, richting en afdwingstatus, plus een eventuele uitschakeltijd;
  • interne gebruikers, groepen of domeinen en betrokken externe adressen of domeinen;
  • TLS-versies en ciphers van uw mailserver en pilotpartners;
  • of de partner een certificaat voor het ontvangende domein presenteert;
  • de toegestane fallbackbeslissing per communicatiepartner;
  • testafzenders, ontvangers, Message-ID’s, wijzigingsvenster en eigenaren van beide mailplatforms.

Sophos adviseert TLS 1.3. De gedocumenteerde cipherstring is exact TLSv1.2+FIPS:kRSA+FIPS:!eNULL:!aNULL. TLS 1.0 en TLS 1.1 worden sinds 1 januari 2024 niet meer ondersteund voor inkomende of uitgaande e-mailbezorging. Uw server mag daarom niet tot deze oude versies beperkt zijn.

Bewaar voor rollback screenshots of geëxporteerde gegevens van de vorige policy. Een nieuwe of gekloonde pilotpolicy kan terug naar Policy Bypassed, waarna u de oude volgorde herstelt. Verwijder geen werkende policy voordat alle tests klaar zijn.

Kies methode en foutgedrag bewust

TLS: transportversleuteling in de normale e-mailclient

Secure using TLS beschermt de SMTP-verbinding tijdens transport; afzender en ontvanger blijven hun gebruikelijke e-mailclient gebruiken. Het betekent niet dat het bericht na bezorging in de mailbox in een versleutelde container blijft.

De TLS-niveaus hebben verschillende gevolgen:

  • Preferred TLS 1.3 probeert TLS 1.3 en gebruikt TLS 1.2 als de partner TLS 1.3 niet ondersteunt. Sophos adviseert deze flexibelere keuze omdat berichtuitwisseling minder snel uitvalt.
  • Required TLS 1.3 accepteert uitsluitend TLS 1.3. Zonder ondersteuning bij de partner wordt geen andere TLS-versie gebruikt.
  • Required TLS 1.2 accepteert uitsluitend TLS 1.2. TLS 1.3 is in deze modus geen vervanging; de gekozen versie wordt afgedwongen.

Zonder die afdwinging probeert Sophos standaard TLS wanneer een TLS-verbinding mogelijk is. Dit opportunistische gedrag biedt compatibiliteit, maar garandeert geen versleuteling naar iedere partner. Is een versie of certificaatcontrole contractueel vereist, geef die partner dan een nauw begrensde Required-scope en voer een gedocumenteerde negatieve test uit.

Voor uitgaande verbindingen met Required TLS 1.3 of Required TLS 1.2 kunt u Verify certificate activeren. Sophos controleert dan of het certificaat voor het ontvangende domein is uitgegeven. Bij een fout wordt niet bezorgd. Zet daarom het werkelijke ontvangende domein in de externe scope en controleer welke host en welk certificaat het MX-pad presenteert; een gelijkend partnerdomein is geen vervanging.

Verwar Push Encryption of Portal Encryption niet met TLS

Push Encryption is alleen uitgaand beschikbaar. Sophos zet de berichtinhoud om in een document met wachtwoord; Microsoft Office-, ZIP- en PDF-bijlagen gebruiken hun eigen versleuteling, andere formaten kunnen als PDF worden geleverd. Bij het eerste bericht maakt de ontvanger via de melding een Sophos Secure Message-wachtwoord aan. De link verloopt na 30 dagen. Het wachtwoord geldt alleen voor berichten uit dezelfde regio als het oorspronkelijke bericht. Raadpleeg Sophos Email Portal- en Push-versleuteling beheren voor het openen door de ontvanger, wachtwoordgebruik en beveiligde antwoorden.

Portal Encryption is eveneens alleen uitgaand en vereist een Sophos Email-licentie met Portal Encryption Add-on. De ontvanger leest en beantwoordt het bericht in Sophos Secure Message en maakt bij het eerste bericht een account. Branding, ontvangerbeheer, verval en recall zijn een afzonderlijke portalworkflow; dit artikel kiest alleen de methode in de policy.

Secure using S/MIME vereist vooraf geconfigureerde CA’s, gebruikers- en ontvangercertificaten en privésleutels. S/MIME kan ondertekenen zonder noodzakelijkerwijs te versleutelen. Uitgifte, vertrouwen, extractie en reset van certificaten horen daarom in een aparte S/MIME-workflow en worden niet vervangen door TLS Verify certificate.

Voor uitgaande TLS naar een partner zonder TLS biedt Sophos Allow unencrypted delivery of Fallback to push encrypt the entire message; Sophos adviseert Push-fallback. Als Push-fallback is ingesteld en de TLS-onderhandeling mislukt, verzendt Sophos het bericht met Push Encryption in plaats van het in de wachtrij te zetten voor nieuwe TLS-pogingen. Sta onversleutelde bezorging alleen toe als de gegevensclassificatie dat uitdrukkelijk toestaat. Push past alleen als ontvangers wachtwoordbeveiligde documenten mogen openen en de eerste registratie acceptabel is. Zonder toegestane fallback en werkende TLS-onderhandeling mag u geen stille terugval naar platte tekst verwachten.

Maak en begrens de Secure Message policy

  1. Open My Products > Email Security > Policies en klik op Add Policy.
  2. Kies Secure Message en Continue. Geef een duidelijke naam, bijvoorbeeld SM-Outbound-Partner-TLS13.
  3. Voeg onder Internal gebruikers, groepen of domeinen toe. Een match in een van de lijsten volstaat. Beweeg over een gebruikersnaam om het e-mailadres te controleren.
  4. Open voor een partnerregel External en voeg exact adres of domein handmatig of uit een bestand toe. Controleer in- of uitsluiting; standaard is Include all. De policy geldt wanneer een interne invoer met een externe communiceert.
  5. Open Settings, kies Inbound of Outbound en activeer Secure inbound messages of Secure outbound messages.
  6. Kies onder Select the method to secure messages de goedgekeurde methode. Stel voor TLS Preferred TLS 1.3, Required TLS 1.3 of Required TLS 1.2 in.
  7. Activeer zo nodig voor een uitgaande Required TLS-partner Verify certificate. Leg fallback of foutgedrag expliciet vast; leid dit niet af uit de naam.
  8. Kies voor Push of Portal Encryption de taal van meldings- en registratieberichten aan ontvangers.
  9. Bepaal onder Choose how to secure of elk bericht wordt beveiligd of gebruikers dit met een onderwerp-tag starten. De vaste tag secure: activeert altijd versleuteling, ook met eigen triggers. secureTest: of secureFull: moeten volledig en exact aan het begin van het onderwerp staan; een deel is niet genoeg.
  10. Zet de pilotpolicy op Policy is enforced, sla op en controleer de prioriteit. U kunt optioneel datum en tijd voor automatische uitschakeling instellen.

Gebruik Clone voor vergelijkbare scopes. Een kloon begint als Policy Bypassed, een kloon van de Base Policy heeft geen gebruikers, groepen of domeinen en krijgt standaard prioriteit boven het origineel. Controleer scope, instellingen en volgorde vóór Policy is enforced.

Gemigreerde tenants kunnen policies hebben waarvan de naam met Migrated begint. Ze bevatten de vroegere TLS- en versleutelingsinstellingen uit Global Settings en de destijds beschermde gebruikers en domeinen. U kunt ze wijzigen, hernoemen, samenvoegen of verwijderen, maar pas nadat scope, methode, fallback en prioriteit met de huidige gewenste situatie zijn vergeleken.

Wisselwerking met Data Control

Een uitgaande versleutelingsactie in een Data Control policy overschrijft de methode in de Secure Message policy. Gebruikt een bericht onverwacht Push of Portal in plaats van TLS, controleer dan beide policies en toepasselijke Data Control-regels. Controleer scope en volgorde afzonderlijk, omdat de policyfamilies andere taken hebben.

Valideer met representatieve ontvangers

Stuur voor acceptatie gecontroleerde, niet-vertrouwelijke berichten naar minimaal één ontvanger binnen en één buiten de scope. Een partnerspecifiek TLS-testplan bevat:

  • een partner met de gekozen TLS-versie en, bij Verify certificate, een passend certificaat;
  • een partner met TLS 1.2 maar zonder TLS 1.3 om Preferred TLS 1.3 te testen;
  • een goedgekeurde negatieve test waarin TLS- of certificaateis niet wordt gehaald;
  • bij Push-fallback een ontvanger die melding, wachtwoordaanmaak en openen doorloopt;
  • bij onderwerp-tags één bericht met exacte, één met onvolledige en één zonder trigger.

Open in Message History links Filter, kies de categorie Secure message en filter op TLS-versie. Open het onderwerp. In Message Details toont bewegen over de drie puntjes onder Status of TLS is gebruikt en welke versie is geauthenticeerd. Kon Sophos de handtekening van de uitgevende CA niet controleren, dan noemt SMTP Text de TLS-bezorging niet vertrouwd.

Een succesvolle acceptatie registreert policynaam en -prioriteit, interne en externe scope, Message-ID, tijdstip, ontvanger, methode, waargenomen TLS-versie, certificaatresultaat, fallback en eindstatus. Een Message History-item bewijst op zichzelf niet dat de ontvanger het bericht kon lezen.

Onderzoek TLS-fouten, wachtrij en certificaten

Kan Sophos Email een vereiste TLS-verbinding niet opbouwen en verwerkt geen ingestelde fallback het bericht, dan wordt de e-mail niet verzonden. Sophos zet hem maximaal zeven dagen in de wachtrij voor nieuwe bezorgpogingen en verwijdert hem daarna. Elke TLS-poging maakt een history-item in de vorm Processing: Check TLS; na de laatste fout meldt het log dat de e-mail door de TLS policy is verwijderd. Dit is geen geschikte manier om zeven dagen een foutieve Required-instelling in productie te testen.

Controleer in deze volgorde:

  1. Staat de verwachte Secure Message policy op Policy is enforced, met juiste scopes en prioriteit?
  2. Overschrijft een Data Control-actie de methode of activeert de vaste tag secure: versleuteling?
  3. Ondersteunen eigen server en partner de gekozen versie? TLS 1.0 en 1.1 zijn geen fallback.
  4. Zijn TLS en de benodigde ciphers actief, vooral TLSv1.2+FIPS:kRSA+FIPS:!eNULL:!aNULL?
  5. Past bij Verify certificate het certificaat bij het echte ontvangende domein en kan Sophos de uitgevende CA controleren?
  6. Tonen Message History, Processing: Check TLS en SMTP Text een versie-, vertrouwens- of onderhandelingsfout?

Blijft de oorzaak onduidelijk, verzamel dan policynaam, scope, prioriteit, Message-ID, tijdstip, richting, ontvangend domein, verwachte en waargenomen TLS-versie en relevante History- en SMTP-tekst voor Sophos Email Support. Plaats geen privésleutels, wachtwoorden of vertrouwelijke inhoud in het ticket.

Rol veilig terug

Bij onverwachte mailstroom zet u eerst de nieuwe policy terug op Policy Bypassed of gebruikt u het voorbereide uitschakeltijdstip en herstelt u de oude prioriteit. Test opnieuw in beide richtingen en bevestig het vorige pad in Message History en bij de ontvanger. Versoepel niet tegelijk TLS-versie, certificaatcontrole en scope, want dan blijft de oorzaak verborgen.

Een tijdelijke fallback naar Preferred TLS 1.3, Push Encryption of onversleutelde bezorging mag alleen als data- en change-eigenaar dit expliciet goedkeuren. Is platte tekst verboden, houd het bericht dan liever tegen terwijl de partner TLS-versie, ciphers of certificaatketen corrigeert. Breid de scope pas uit of ruim een oude Migrated policy pas op na geslaagde pilot- en negatieve tests.