Hoppa till innehållet
Avanet

Sophos Email: konfigurera TLS och Secure Message säkert

Sophos Email

En Secure Message policy anger hur Sophos Email skyddar meddelanden och vad som händer när den valda metoden inte kan användas. För de flesta TLS-anslutningar är Preferred TLS 1.3 en robust utgångspunkt: Sophos försöker använda TLS 1.3 och växlar vid behov till TLS 1.2. Framtvinga bara Required TLS 1.3 eller Required TLS 1.2 för partner vars sändande eller mottagande system bevisligen uppfyller just det kravet.

Snabbväg: Aktivera först TLS 1.3 och nödvändiga chiffersviter på den egna e-postservern eller e-posttjänsten och testa e-postflödet till Sophos. Skapa sedan en Secure Message policy under My Products > Email Security > Policies, ange internt och vid behov externt omfång, välj riktning och metod under Settings och ställ in Policy is enforced för en liten pilotgrupp. Bestäm i förväg om ett TLS-fel för utgående meddelanden får medge okrypterad leverans eller ska hanteras med Fallback to push encrypt the entire message. Kontrollera därefter TLS-version och leveransstatus i Message History för varje partner och riktning.

Varning: TLS måste vara aktivt på den egna e-postservern eller e-posttjänsten innan en Secure Message-metod konfigureras. E-postgatewayen måste i synnerhet stödja TLS 1.3 innan du väljer Required TLS 1.3. Annars kan anslutningen till Sophos brytas så att både inkommande och utgående e-post stoppas.

Dokumentera förutsättningar och återställning före ändringen

Den här guiden gäller Sophos Email i Sophos Fusion (tidigare Sophos Central), inte Mail Protection som körs på en Sophos Firewall. Secure Message Policies kan inte konfigureras i EMS mode.

Dokumentera följande före ändringen:

  • aktuellt policynamn, omfång, ordning, riktning och tillämpningsstatus samt eventuell inställd inaktiveringstid;
  • interna användare, grupper eller domäner och berörda externa adresser eller domäner;
  • TLS-versioner och chiffersviter på den egna e-postservern och pilotpartnernas system;
  • om partnern presenterar ett certifikat för sin mottagardomän;
  • godkänt val av reservåtgärd för varje kommunikationspartner;
  • testavsändare, testmottagare, Message-ID:n, ändringsfönster och ansvariga för båda e-postplattformarna.

Sophos rekommenderar TLS 1.3. Den dokumenterade chiffersträngen är exakt TLSv1.2+FIPS:kRSA+FIPS:!eNULL:!aNULL. TLS 1.0 och TLS 1.1 stöds inte för inkommande eller utgående e-postleverans sedan den 1 januari 2024. Servern får därför inte vara begränsad till dessa äldre versioner.

Spara skärmbilder eller exporterade uppgifter från den tidigare policyn för återställning. En ny eller klonad pilotpolicy kan återställas till Policy Bypassed, varefter den tidigare ordningen återställs. Ta inte bort en fungerande policy innan alla tester är klara.

Välj metod och felbeteende medvetet

TLS: transportkryptering i den vanliga e-postklienten

Secure using TLS skyddar SMTP-anslutningen under transporten. Avsändare och mottagare fortsätter att använda sina vanliga e-postklienter. Det innebär inte att meddelandet ligger kvar i en krypterad behållare efter leverans till postlådan.

TLS-nivåerna får olika konsekvenser:

  • Preferred TLS 1.3 försöker använda TLS 1.3 och använder TLS 1.2 om partnern inte stöder TLS 1.3. Sophos rekommenderar detta flexiblare alternativ eftersom det mer sällan avbryter meddelandeutbytet.
  • Required TLS 1.3 accepterar endast TLS 1.3. Om partnern inte stöder versionen utbyts meddelandet inte via någon annan TLS-version.
  • Required TLS 1.2 accepterar endast TLS 1.2. TLS 1.3 ersätter inte den valda versionen i detta läge, utan TLS 1.2 framtvingas.

Utan sådan framtvingning försöker Sophos som standard använda TLS när en TLS-anslutning är möjlig. Detta opportunistiska beteende ger kompatibilitet men garanterar inte kryptering till varje partner. Om en viss version eller certifikatkontroll är ett avtalskrav ska partnern få en Required-policy med snävt omfång och ett dokumenterat negativt test ska genomföras.

För utgående anslutningar med Required TLS 1.3 eller Required TLS 1.2 kan du även aktivera Verify certificate. Sophos kontrollerar då att certifikatet utfärdats för mottagardomänen. Meddelandet levereras inte om kontrollen misslyckas. Det externa omfånget måste därför innehålla den faktiska mottagardomänen. Kontrollera också vilken värd och vilket certifikat dess MX-väg presenterar; en partnerdomän med liknande namn är inte en ersättning.

Blanda inte ihop Push Encryption eller Portal Encryption med TLS

Push Encryption är endast tillgängligt för utgående meddelanden. Sophos omvandlar meddelandeinnehållet till en lösenordsskyddad dokumentfil. Bilagor i Microsoft Office-, ZIP- och PDF-format använder sin inbyggda kryptering, medan andra format kan tillhandahållas som PDF. Vid första användningen skapar mottagaren ett lösenord för Sophos Secure Message via aviseringen. Länken i aviseringen upphör att gälla efter 30 dagar. Lösenordet gäller endast för meddelanden från samma region som det ursprungliga meddelandet. För mottagarens öppning, lösenordsanvändning och säkra svar, se Hantera Sophos Email Portal- och Push-kryptering.

Portal Encryption är också endast tillgängligt för utgående meddelanden och kräver en Sophos Email-licens med Portal Encryption Add-on. Mottagaren läser och besvarar meddelandet i Sophos Secure Message och skapar ett konto vid det första meddelandet. Varumärkesanpassning, mottagaradministration, giltighetstid och återkallande är ett separat arbetsflöde för portalen. Den här artikeln väljer bara metoden i policyn.

Secure using S/MIME kräver förkonfigurerade certifikatutfärdare, användar- och mottagarcertifikat samt privata nycklar. S/MIME kan signera utan att nödvändigtvis kryptera. Certifikattilldelning, förtroende, extrahering och återställning hör därför till ett separat S/MIME-arbetsflöde och ersätts inte av TLS-inställningen Verify certificate.

För utgående TLS till en partner utan TLS-stöd erbjuder Sophos Allow unencrypted delivery eller Fallback to push encrypt the entire message. Sophos rekommenderar Push som reservåtgärd. När Push-reservåtgärden är konfigurerad och TLS-förhandlingen misslyckas skickar Sophos meddelandet med Push Encryption i stället för att placera det i kö för nya TLS-försök. Välj endast okrypterad leverans om dataklassificeringen uttryckligen tillåter det. Push är bara lämpligt om mottagarna får öppna lösenordsskyddade dokument och den första registreringsprocessen är acceptabel. Om varken en reservåtgärd är godkänd eller TLS-förhandlingen fungerar ska du inte förvänta dig en tyst återgång till klartext.

Skapa och avgränsa en Secure Message policy

  1. Öppna My Products > Email Security > Policies och klicka på Add Policy.
  2. Välj Secure Message och sedan Continue. Ange ett tydligt namn, till exempel SM-Outbound-Partner-TLS13.
  3. Lägg till användare, grupper eller domäner under Internal. En träff i någon av listorna räcker. Håll pekaren över en användares namn för att kontrollera e-postadressen.
  4. För en partnerspecifik regel öppnar du External och lägger till exakt e-postadress eller domän manuellt eller från en fil. Kontrollera om listan inkluderas eller exkluderas; standardvärdet är Include all. Policyn gäller när en intern post kommunicerar med en extern post.
  5. Öppna Settings, välj Inbound eller Outbound och aktivera Secure inbound messages eller Secure outbound messages.
  6. Välj den godkända metoden under Select the method to secure messages. För TLS väljer du sedan Preferred TLS 1.3, Required TLS 1.3 eller Required TLS 1.2.
  7. Aktivera vid behov Verify certificate för en utgående Required TLS-partner. Ange uttryckligen reservåtgärd eller felbeteende; härled det inte från policynamnet.
  8. För Push eller Portal Encryption väljer du språk för aviserings- och registreringsmeddelandena till mottagaren.
  9. Under Choose how to secure bestämmer du om alla meddelanden ska skyddas eller om användarna ska aktivera skyddet med en ämnestagg. Den fasta standardtaggen secure: aktiverar alltid kryptering, även när anpassade utlösare har definierats. Anpassade utlösare som secureTest: eller secureFull: måste anges fullständigt och exakt i början av ämnesraden; en delsträng räcker inte.
  10. Ställ in pilotpolicyn på Policy is enforced, spara och kontrollera dess prioritet. Du kan även ange datum och tid för automatisk inaktivering.

Använd Clone för flera liknande omfång. En klon börjar som Policy Bypassed, en klon av Base Policy har inga användare, grupper eller domäner och klonen får som standard högre prioritet än originalet. Kontrollera omfång, inställningar och ordning innan du väljer Policy is enforced.

Migrerade tenantmiljöer kan ha policies vars namn börjar med Migrated. De innehåller tidigare TLS- och krypteringsinställningar från Global Settings samt de användare och domäner som skyddades när migreringen genomfördes. De kan redigeras, byta namn, slås samman eller tas bort, men först efter att omfång, metod, reservåtgärd och prioritet jämförts med dagens avsedda konfiguration.

Samverkan med Data Control

En utgående krypteringsåtgärd i en Data Control policy åsidosätter krypteringsmetoden som valts i Secure Message-policyn. Om ett meddelande oväntat använder Push eller Portal i stället för TLS ska du därför kontrollera både Secure Message-policyn och matchande Data Control-regler. Kontrollera omfång och ordning separat, eftersom policyfamiljerna har olika uppgifter.

Validera med representativa mottagare

Skicka kontrollerade, icke-konfidentiella meddelanden till minst en mottagare inom policyomfånget och en jämförelsemottagare utanför omfånget för godkännandet. En partnerspecifik TLS-testplan omfattar:

  • en partner som stöder den valda TLS-versionen och, när Verify certificate är aktiverat, presenterar ett matchande certifikat;
  • en partner som stöder TLS 1.2 men inte TLS 1.3 för att testa Preferred TLS 1.3;
  • ett godkänt negativt test där TLS- eller certifikatkravet inte uppfylls;
  • vid konfigurerad Push-reservåtgärd en mottagare som slutför avisering, lösenordsskapande och öppning av meddelandet;
  • vid ämnestaggar ett meddelande med exakt utlösare, ett med ofullständig utlösare och ett utan utlösare.

Öppna Filter till vänster i Message History, välj kategorin Secure message och filtrera på TLS-version. Öppna ämnesraden. Om du håller pekaren över ellipsen med tre punkter under Status i Message Details visas om anslutningen skyddades med TLS och vilken TLS-version som autentiserades. Om Sophos inte kunde kontrollera den utfärdande certifikatutfärdarens signatur anger SMTP Text att TLS-leveransen inte var betrodd.

Ett godkänt testprotokoll innehåller policynamn och prioritet, interna och externa omfångsvärden, Message-ID, tidsstämpel, mottagare, vald metod, observerad TLS-version, certifikatresultat, reservåtgärd och slutligt resultat hos mottagaren. En post i Message History bevisar inte i sig att mottagaren kunde läsa meddelandet.

Undersök TLS-fel, kö och certifikat

Om Sophos Email inte kan upprätta en obligatorisk TLS-anslutning och ingen konfigurerad reservåtgärd hanterar meddelandet skickas det inte. Sophos placerar det i kö för nya leveransförsök i upp till sju dagar och tar sedan bort det. Varje TLS-relaterat sändningsförsök skapar en historikpost i formatet Processing: Check TLS. Efter det sista felet loggas att meddelandet togs bort på grund av TLS-policyn. Detta är inte en lämplig mekanism för att testa en felaktig Required-inställning i produktion i sju dagar.

Kontrollera i följande ordning:

  1. Är den förväntade Secure Message-policyn inställd på Policy is enforced, med rätt internt och externt omfång och avsedd prioritet?
  2. Åsidosätter en Data Control-åtgärd metoden, eller aktiverar den fasta taggen secure: kryptering?
  3. Stöder den egna e-postservern och partnern den valda versionen? TLS 1.0 och TLS 1.1 är inte reservversioner.
  4. Är TLS och nödvändiga chiffersviter aktiva, i synnerhet den dokumenterade strängen TLSv1.2+FIPS:kRSA+FIPS:!eNULL:!aNULL?
  5. Matchar det presenterade certifikatet den faktiska mottagardomänen när Verify certificate används, och kan Sophos verifiera den utfärdande certifikatutfärdaren?
  6. Visar Message History, Processing: Check TLS och SMTP Text ett versions-, förtroende- eller förhandlingsfel?

Om orsaken fortfarande är oklar samlar du in policynamn, omfång, prioritet, Message-ID, tidsstämpel, riktning, mottagardomän, förväntad och observerad TLS-version samt relevanta historik- och SMTP-texter för Sophos Email Support. Ta inte med privata nycklar, lösenord eller konfidentiellt meddelandeinnehåll i supportärendet.

Återställ säkert

Om e-postflödet beter sig oväntat ställer du först tillbaka den nya policyn på Policy Bypassed eller använder den förberedda inaktiveringstiden och återställer den tidigare prioriteten. Testa båda riktningarna igen och bekräfta den tidigare vägen i Message History och hos mottagaren. Lätta inte samtidigt på TLS-versionen, certifikatverifieringen och omfånget, eftersom det döljer orsaken.

En tillfällig reservlösning med Preferred TLS 1.3, Push Encryption eller okrypterad leverans är bara tillåten om dataägaren och ändringsansvarig uttryckligen godkänner alternativet. Om klartext är förbjuden är det säkrare att hålla kvar meddelandet medan partnern korrigerar TLS-version, chiffersviter eller certifikatkedja. Utöka omfånget eller rensa en gammal Migrated policy först efter godkända pilot- och negativa tester.