Przejdz do tresci
Avanet

Sophos Email: bezpieczna konfiguracja TLS i Secure Message

Sophos Email

Secure Message policy określa, jak Sophos Email zabezpiecza wiadomości i co robi, gdy wybrana metoda jest niedostępna. Dla większości połączeń TLS dobrym punktem wyjścia jest Preferred TLS 1.3: Sophos próbuje TLS 1.3, a w razie potrzeby przechodzi na TLS 1.2. Required TLS 1.3 lub Required TLS 1.2 należy wymuszać wyłącznie dla partnerów, których system wysyłający lub odbierający rzeczywiście spełnia dokładnie ten wymóg.

Szybka ścieżka: najpierw włącz TLS 1.3 i wymagane szyfry na własnym serwerze lub w usłudze pocztowej, po czym przetestuj przepływ do Sophos. W My Products > Email Security > Policies utwórz policy Secure Message, określ zakres wewnętrzny i ewentualnie zewnętrzny, wybierz kierunek oraz metodę w Settings i ustaw dla małej grupy pilotażowej Policy is enforced. Dla wiadomości wychodzących zawczasu zdecyduj, czy błąd TLS może pozwolić na dostarczenie bez szyfrowania, czy ma uruchomić Fallback to push encrypt the entire message. Następnie sprawdź wersję TLS i status dostarczenia w Message History dla każdego partnera i kierunku.

Ostrzeżenie: TLS musi działać na własnym serwerze lub w usłudze pocztowej przed skonfigurowaniem metody Secure Message. W szczególności brama pocztowa musi obsługiwać TLS 1.3 przed wybraniem Required TLS 1.3. W przeciwnym razie połączenie z Sophos może zostać przerwane, zatrzymując pocztę przychodzącą i wychodzącą.

Zapisz wymagania i rollback przed zmianą

Instrukcja dotyczy Sophos Email w Sophos Fusion (dawniej Sophos Central), a nie Mail Protection działającego na Sophos Firewall. W EMS mode nie można konfigurować Secure Message Policies.

Przed zmianą zapisz:

  • bieżącą nazwę policy, zakres, kolejność, kierunek i stan wymuszania oraz ewentualny czas wyłączenia;
  • użytkowników, grupy lub domeny wewnętrzne oraz objęte adresy lub domeny zewnętrzne;
  • wersje TLS i szyfry własnego serwera oraz partnerów pilotażowych;
  • czy partner przedstawia certyfikat dla swojej domeny odbiorcy;
  • zatwierdzony fallback dla każdego partnera;
  • nadawców i odbiorców testowych, Message-ID, okno zmiany i właścicieli obu platform.

Sophos zaleca TLS 1.3. Udokumentowany ciąg szyfrów to dokładnie TLSv1.2+FIPS:kRSA+FIPS:!eNULL:!aNULL. TLS 1.0 i TLS 1.1 nie są obsługiwane dla poczty przychodzącej ani wychodzącej od 1 stycznia 2024 r. Serwer nie może więc być ograniczony do tych starych wersji.

Do rollbacku zachowaj zrzuty ekranu lub eksport poprzedniej policy. Nową lub sklonowaną policy pilotażową można ustawić z powrotem na Policy Bypassed i przywrócić poprzednią kolejność. Nie usuwaj działającej policy przed zakończeniem testów.

Świadomie wybierz metodę i obsługę błędów

TLS: szyfrowanie transportu w zwykłym kliencie pocztowym

Secure using TLS zabezpiecza połączenie SMTP w transporcie; nadawca i odbiorca nadal korzystają ze zwykłego klienta. Nie oznacza to, że po dostarczeniu wiadomość pozostaje w zaszyfrowanym kontenerze w skrzynce.

Poziomy TLS mają różne skutki:

  • Preferred TLS 1.3 próbuje TLS 1.3 i używa TLS 1.2, gdy partner nie obsługuje TLS 1.3. Sophos zaleca tę elastyczniejszą opcję, ponieważ rzadziej przerywa wymianę.
  • Required TLS 1.3 akceptuje tylko TLS 1.3. Jeśli partner go nie obsługuje, inna wersja TLS nie zostanie użyta.
  • Required TLS 1.2 akceptuje tylko TLS 1.2. W tym trybie TLS 1.3 nie zastępuje wybranej wersji.

Bez wymuszania Sophos domyślnie próbuje TLS, gdy połączenie TLS jest możliwe. To zachowanie oportunistyczne zapewnia zgodność, lecz nie gwarantuje szyfrowania z każdym partnerem. Jeśli konkretna wersja lub weryfikacja certyfikatu jest wymogiem umownym, nadaj partnerowi wąski zakres Required i wykonaj udokumentowany test negatywny.

Dla połączeń wychodzących z Required TLS 1.3 lub Required TLS 1.2 można włączyć Verify certificate. Sophos sprawdza wtedy, czy certyfikat wystawiono dla domeny odbiorcy. W przypadku błędu wiadomość nie jest dostarczana. W zakresie zewnętrznym podaj zatem rzeczywistą domenę odbiorcy i sprawdź host oraz certyfikat prezentowane przez jej trasę MX; podobna nazwa domeny partnera nie wystarczy.

Nie myl Push Encryption ani Portal Encryption z TLS

Push Encryption działa tylko wychodząco. Sophos przekształca treść w dokument chroniony hasłem; załączniki Microsoft Office, ZIP i PDF używają własnego szyfrowania, a inne formaty mogą zostać dostarczone jako PDF. Przy pierwszej wiadomości odbiorca tworzy hasło Sophos Secure Message z powiadomienia, którego link wygasa po 30 dniach. Hasło działa tylko dla wiadomości z tego samego regionu co wiadomość pierwotna. Otwieranie przez odbiorcę, używanie hasła i bezpieczne odpowiedzi opisano w artykule Obsługa szyfrowania Portal i Push w Sophos Email.

Portal Encryption również działa tylko wychodząco i wymaga licencji Sophos Email z Portal Encryption Add-on. Odbiorca czyta wiadomość i odpowiada w Sophos Secure Message, tworząc konto przy pierwszej wiadomości. Branding, administracja odbiorcami, wygaśnięcie i recall stanowią osobny proces portalowy; tutaj jedynie wybiera się metodę w policy.

Secure using S/MIME wymaga wcześniej skonfigurowanych CA, certyfikatów użytkowników i odbiorców oraz kluczy prywatnych. S/MIME może podpisywać bez szyfrowania. Wydawanie, zaufanie, ekstrakcja i reset certyfikatów należą więc do osobnej procedury S/MIME i nie są zastępowane przez TLS Verify certificate.

Dla wychodzącego TLS do partnera bez TLS Sophos oferuje Allow unencrypted delivery albo Fallback to push encrypt the entire message i zaleca fallback Push. Gdy fallback Push jest skonfigurowany, a negocjacja TLS kończy się niepowodzeniem, Sophos wysyła wiadomość za pomocą Push Encryption zamiast umieszczać ją w kolejce do kolejnych prób TLS. Dostarczenie bez szyfrowania dopuszczaj tylko wtedy, gdy klasyfikacja danych wyraźnie na to zezwala. Push ma sens tylko, gdy odbiorcy mogą otwierać chronione dokumenty i akceptują rejestrację początkową. Bez zatwierdzonego fallbacku i udanej negocjacji TLS nie należy oczekiwać cichego przejścia do tekstu jawnego.

Utwórz i ogranicz Secure Message policy

  1. Otwórz My Products > Email Security > Policies i kliknij Add Policy.
  2. Wybierz Secure Message oraz Continue. Podaj czytelną nazwę, np. SM-Outbound-Partner-TLS13.
  3. W Internal dodaj użytkowników, grupy lub domeny. Wystarczy dopasowanie na jednej liście. Najedź na użytkownika, aby sprawdzić adres.
  4. Dla reguły partnera otwórz External i dodaj dokładny adres lub domenę ręcznie albo z pliku. Sprawdź dołączenie lub wykluczenie; domyślne jest Include all. Policy działa, gdy wpis wewnętrzny komunikuje się z zewnętrznym.
  5. Otwórz Settings, wybierz Inbound albo Outbound i włącz Secure inbound messages lub Secure outbound messages.
  6. W Select the method to secure messages wybierz zatwierdzoną metodę. Dla TLS ustaw Preferred TLS 1.3, Required TLS 1.3 lub Required TLS 1.2.
  7. Jeśli wymagane dla wychodzącego partnera Required TLS, włącz Verify certificate. Jawnie określ sposób działania fallbacku lub zachowanie w razie błędu; nie wyprowadzaj go z nazwy.
  8. Dla Push lub Portal Encryption wybierz język powiadomień i wiadomości rejestracyjnych do odbiorcy.
  9. W Choose how to secure zdecyduj, czy chronić wszystkie wiadomości, czy pozwolić użytkownikom uruchamiać ochronę tagiem tematu. Stały tag secure: zawsze włącza szyfrowanie, nawet przy własnych triggerach. secureTest: lub secureFull: muszą znaleźć się w całości i dokładnie na początku tematu; fragment nie wystarczy.
  10. Ustaw policy pilotażową na Policy is enforced, zapisz i sprawdź priorytet. Opcjonalnie ustaw datę i czas automatycznego wyłączenia.

Dla podobnych zakresów użyj Clone. Klon zaczyna jako Policy Bypassed, klon Base Policy nie ma użytkowników, grup ani domen, a domyślnie ma wyższy priorytet niż oryginał. Sprawdź zakres, ustawienia i kolejność przed Policy is enforced.

Tenant po migracji może mieć policies z nazwą zaczynającą się od Migrated. Zawierają dawne ustawienia TLS i szyfrowania z Global Settings oraz użytkowników i domeny chronione podczas migracji. Można je edytować, zmieniać nazwę, scalać lub usuwać, ale dopiero po porównaniu zakresu, metody, fallbacku i priorytetu ze stanem docelowym.

Interakcja z Data Control

Wychodząca akcja szyfrowania w policy Data Control zastępuje metodę wybraną w Secure Message policy. Jeśli wiadomość nieoczekiwanie używa Push lub Portal zamiast TLS, sprawdź obie policies i odpowiednie reguły Data Control. Zakres i kolejność sprawdzaj osobno, ponieważ rodziny policy mają inne zadania.

Waliduj na reprezentatywnych odbiorcach

Do odbioru wyślij kontrolowane, niepoufne wiadomości do co najmniej jednego odbiorcy w zakresie i jednego kontrolnego poza nim. Plan TLS dla partnera obejmuje:

  • partnera obsługującego wybraną wersję i przedstawiającego pasujący certyfikat przy Verify certificate;
  • partnera z TLS 1.2, lecz bez TLS 1.3, aby sprawdzić Preferred TLS 1.3;
  • zatwierdzony test negatywny, w którym wymóg TLS lub certyfikatu nie jest spełniony;
  • przy fallbacku Push odbiorcę testującego powiadomienie, utworzenie hasła i otwarcie;
  • przy tagach tematu wiadomość z dokładnym triggerem, niepełnym i bez triggera.

W Message History otwórz po lewej Filter, wybierz kategorię Secure message i filtruj według wersji TLS. Otwórz temat. W Message Details najechanie na wielokropek z trzema kropkami w Status pokazuje zabezpieczenie TLS i uwierzytelnioną wersję. Jeśli Sophos nie zweryfikował podpisu CA, SMTP Text wskazuje, że dostarczenie TLS było niezaufane.

Udany odbiór dokumentuje nazwę i priorytet policy, zakresy, Message-ID, czas, odbiorcę, metodę, obserwowaną wersję TLS, wynik certyfikatu, fallback i wynik końcowy. Sam wpis Message History nie dowodzi, że odbiorca odczytał wiadomość.

Badaj błędy TLS, kolejkę i certyfikaty

Jeśli Sophos Email nie może nawiązać wymaganego połączenia TLS i żaden skonfigurowany fallback nie obsłuży wiadomości, e-mail nie jest wysyłany. Sophos trzyma go w kolejce ponownego dostarczenia do siedmiu dni, a następnie usuwa. Każda próba TLS tworzy wpis Processing: Check TLS; po ostatnim błędzie log zapisuje usunięcie wiadomości z powodu TLS policy. Nie jest to właściwy sposób testowania przez siedem dni błędnego ustawienia Required na produkcji.

Sprawdź kolejno:

  1. Czy oczekiwana Secure Message policy ma Policy is enforced, właściwe zakresy i priorytet?
  2. Czy akcja Data Control zastępuje metodę albo stały tag secure: uruchamia szyfrowanie?
  3. Czy własny serwer i partner obsługują wybraną wersję? TLS 1.0 i 1.1 nie są fallbackiem.
  4. Czy TLS i wymagane szyfry są aktywne, zwłaszcza TLSv1.2+FIPS:kRSA+FIPS:!eNULL:!aNULL?
  5. Czy przy Verify certificate certyfikat odpowiada rzeczywistej domenie odbiorcy i Sophos może zweryfikować CA?
  6. Czy Message History, Processing: Check TLS i SMTP Text wskazują błąd wersji, zaufania lub negocjacji?

Jeśli przyczyna jest niejasna, zbierz nazwę, zakres i priorytet policy, Message-ID, czas, kierunek, domenę odbiorcy, oczekiwaną i obserwowaną wersję TLS oraz właściwe teksty History i SMTP dla Sophos Email Support. Nie dodawaj kluczy prywatnych, haseł ani poufnej treści do zgłoszenia.

Bezpiecznie wykonaj rollback

Przy nieoczekiwanym przepływie najpierw ustaw nową policy z powrotem na Policy Bypassed lub użyj przygotowanego czasu wyłączenia i przywróć wcześniejszy priorytet. Przetestuj oba kierunki i potwierdź starą trasę w Message History oraz u odbiorcy. Nie rozluźniaj równocześnie wersji TLS, weryfikacji certyfikatu i zakresu, bo ukryje to przyczynę.

Tymczasowy fallback do Preferred TLS 1.3, Push Encryption lub dostarczenia bez szyfrowania jest dozwolony tylko po jawnej zgodzie właściciela danych i zmiany. Jeśli tekst jawny jest zabroniony, lepiej zatrzymać wiadomość, aż partner poprawi wersję TLS, szyfry lub łańcuch certyfikatu. Rozszerz zakres lub usuń starą policy Migrated dopiero po udanych testach pilotażowych i negatywnych.