Konfiguracja szyfrowania poczty SPX na Sophos Firewall

Za pomocą Secure PDF Exchange, czyli SPX, Sophos Firewall przekształca wychodzącą wiadomość e-mail wraz z załącznikami w plik PDF chroniony hasłem. Odbiorca nie potrzebuje własnego klienta szyfrowania. Zależnie od wybranego modelu otrzymuje hasło jednorazowe, korzysta z zapisanego hasła albo samodzielnie je rejestruje.

Niezawodne działanie wymaga współpracy czterech elementów: szablonu SPX, jednoznacznego wyzwalacza, bezpiecznego kanału przekazania hasła oraz, w razie potrzeby, SPX Reply Portal. Następnie testowany jest pozytywny i negatywny przepływ poczty. Samo dostarczenie pliku PDF nie dowodzi, że zadziałała właściwa polityka ani że rejestracja hasła i bezpieczna odpowiedź funkcjonują.

SPX w ośmiu krokach

1. Sprawdzić licencję Email Protection, przepływ poczty MTA, obsługę modelu urządzenia i certyfikat.
2. Ustalić, czy szyfrowanie wyzwala chroniona domena, dopasowanie Data Control czy nadawca.
3. Utworzyć własny szablon w Email > Encryption > SPX templates > Add.
4. Świadomie wybrać typ hasła, szyfrowanie PDF, powiadomienie i Reply Portal.
5. Zabezpieczyć FQDN, dozwolone sieci i port w Email > Encryption > SPX portal settings.
6. Przypisać szablon w polityce SMTP route and scan albo świadomie ustawić go jako szablon domyślny.
7. Z zewnętrznym odbiorcą przetestować PDF, kanał hasła, rejestrację i odpowiedź.
8. Wykonać test negatywny bez wyzwalacza SPX oraz udokumentować Mail logs, logi MTA i wycofanie.

⚠️ Puste pole Allowed networks w SPX Portal nie oznacza „braku dostępu”, lecz powoduje powrót do Any. Sophos zaleca też osobny port dla Reply Portal. Dlatego FQDN portalu, certyfikat, dozwolone źródła i kanał hasła muszą być określone przed testem produkcyjnym.

Kiedy SPX jest odpowiedni

SPX sprawdza się, gdy zewnętrzni odbiorcy mają otrzymywać poufne treści w chronionym pliku PDF bez instalowania klienta szyfrowania. Można go używać zarówno w MTA mode, jak i Legacy mode. Ta procedura korzysta z MTA mode, ponieważ pozwala czytelnie połączyć domenę, Data Control i routing w polityce SMTP.

SPX nie jest szyfrowaniem transportowym między serwerami pocztowymi ani szyfrowaniem end-to-end między dwoma klientami poczty. Firewall przetwarza tekst jawny, tworzy plik PDF i zarządza hasłem lub rejestracją. Następnie PDF może nadal istnieć poza firewallem w skrzynkach, archiwach lub pobranych plikach. Zakres odbiorców, retencja i przekazywanie haseł są więc częścią projektu bezpieczeństwa.

Wymagane są:

• ważna licencja Email Protection;
• przetestowany przepływ poczty wychodzącej przez Sophos Firewall;
• udokumentowany zewnętrzny odbiorca testowy;
• zaufany FQDN i pasujący certyfikat dla używanych portali SPX;
• oddzielny bezpieczny kanał dla haseł, jeśli odbiorca ich nie rejestruje;
• ścieżka odzyskiwania umożliwiająca usunięcie przypisań szablonu i polityki.

Według aktualnej dokumentacji Sophos funkcja SPX nie jest dostępna na XGS 87/87w. Pełny MTA mode nie jest ponadto dostępny na XGS 88/88w. Konfiguracja Mail Protection w MTA mode wyjaśnia przepływ poczty, licencję, relay i ograniczenia modeli.

Ustalenie wyzwalacza i priorytetu

SPX można uruchomić na trzy sposoby. Jeśli skonfigurowano kilka metod, Sophos Firewall stosuje w MTA mode następującą kolejność:

1. Chroniona domena: Szablon SPX wybrany w Domains and routing target dotyczy wiadomości wychodzących z pasującej chronionej domeny.
2. Data control list: Dopiero gdy na poziomie domeny nie ustawiono szablonu SPX, dopasowanie Data Control może zastosować szablon wybrany dla listy.
3. Wyzwalacz nadawcy: Dopiero gdy ani domena, ani Data Control nie dostarczają szablonu, stosowana jest metoda nadawcy skonfigurowana w Default SPX template.

Przypisanie domenowe ma szeroki zakres i jest odpowiednie tylko wtedy, gdy rzeczywiście każda pasująca wiadomość wychodząca ma być szyfrowana. Data Control nadaje się do zdefiniowanych typów treści, lecz musi zostać sprawdzone pod kątem false positives na prawdziwych przykładach pozytywnych i negatywnych. Wyzwalacz nadawcy pozostawia decyzję nadawcy, ale wymaga jasno udokumentowanego procesu w kliencie poczty.

Przed konfiguracją dla każdego przepływu poczty definiuje się dokładnie jeden główny wyzwalacz. Druga metoda nie może niezauważenie zastąpić innej.

Tworzenie szablonu SPX

W przykładzie używany jest szablon Finance-SPX-Recipient. Nazwa jest wartością dokumentacyjną i należy ją dostosować do celu oraz organizacji.

1. Otworzyć Email > Encryption > SPX templates.
2. Wybrać Add.
3. Wprowadzić nazwę, na przykład Finance-SPX-Recipient.
4. Ustawić nazwę organizacji używaną w powiadomieniach.
5. Wybrać Encryption standard i PDF page size zgodnie z własnymi wymaganiami.
6. W polu Password type wybrać planowany model hasła.
7. Sprawdzić temat, treść wiadomości i instrukcje dla odbiorcy oraz w razie potrzeby je dostosować.
8. Jeśli potrzebne są bezpieczne odpowiedzi, włączyć Enable SPX reply portal.
9. Włączyć Include original body into reply tylko wtedy, gdy oryginalna wiadomość może znaleźć się w odpowiedzi.
10. Zapisać szablon.

Świadomy wybór modelu hasła

Sophos Firewall oferuje cztery modele:

• Specified by sender: Nadawca ustawia hasło. Firewall usuwa je przed wysłaniem i nie zapisuje go. Hasło musi dotrzeć do odbiorcy oddzielnym bezpiecznym kanałem.
• Generate one-time password for every email: Firewall generuje nowe hasło dla każdej wiadomości i wysyła je do nadawcy. Nadawca przekazuje je osobno odbiorcy. Hasło nie jest zapisywane.
• Generated and stored for recipient: Firewall generuje hasło właściwe dla odbiorcy, wysyła je nadawcy i ponownie wykorzystuje aż do wygaśnięcia.
• Specified by recipient: Niezarejestrowany odbiorca otrzymuje link rejestracyjny, ustawia własne hasło i używa go do wygaśnięcia dla kolejnych wiadomości SPX z organizacji.

W stałej relacji z partnerem Specified by recipient jest często najbardziej zrozumiałym procesem. Hasło jednorazowe może lepiej pasować do pojedynczej, szczególnie wrażliwej przesyłki. Nie należy bez planu mieszać różnych modeli zapisywanych haseł dla tego samego odbiorcy, ponieważ wówczas musi on rozpoznawać właściwe hasło dla każdej wiadomości.

Przy Specified by sender temat może mieć format [secure:<password>]<subject text>. Nadawca musi następnie przekazać hasło oddzielnie. Dla Microsoft Outlook Sophos udostępnia Outlook Add-in w Authentication > Client downloads.

Aktualna dokumentacja Sophos używa dwóch różnych zapisów nagłówka dla innych klientów poczty: X-Sophos-SPXEncrypt: yes na stronie szablonu i X-Sophos-SPX-Encrypt: yes na ogólnej stronie Encryption. Ta rozbieżność nie jest traktowana jako gotowy przepis do skopiowania. Przed wdrożeniem produkcyjnym trzeba sprawdzić, który zapis działa na używanym buildzie SFOS. Gdy to możliwe, łatwiejszym do prześledzenia wyzwalaczem jest polityka, Data Control lub Sophos Outlook Add-in.

Projektowanie powiadomienia bez tworzenia kolejnego wycieku danych

Dostępne zmienne powiadomień obejmują między innymi:

• ENVELOPE_TO
• PASSWORD
• ORGANIZATION_NAME
• SENDER
• REG_LINK

Obsługiwane są proste formatowanie HTML i linki. Tekst musi wyjaśniać, kto wysłał wiadomość, jak bezpiecznie uzyskać hasło i jak długo możliwe są rejestracja lub odpowiedź. Dane uwierzytelniające ani poufna treść wiadomości nie powinny być dodatkowo umieszczane w niezabezpieczonym powiadomieniu.

Zabezpieczanie portali SPX

Rejestrację hasła i dostęp do portalu określa się w Email > Encryption > SPX portal settings:

1. W Hostname wprowadzić FQDN, przez który zewnętrzni odbiorcy faktycznie docierają do portalu.
2. W Allowed networks ustawić tylko wymagane sieci źródłowe. Any jest właściwe tylko wtedy, gdy dowolni odbiorcy zewnętrzni muszą mieć dostęp do portalu i ryzyko jest świadomie zaakceptowane.
3. Udokumentować port. Password Registration Portal używa domyślnie TCP 8094.
4. Użyć osobnego portu dla SPX Reply Portal.
5. Ustawić okres ważności nieużywanych haseł, bezpiecznych odpowiedzi i linków rejestracyjnych.
6. Wprowadzić odbiorców powiadomień o błędach SPX.

Jeśli Allowed networks pozostanie puste, SFOS użyje Any, ponieważ SPX Reply Portal jest domyślnie aktywny w strefie WAN. Jeśli Reply Portal nie jest potrzebny, Sophos opisuje jako metodę wyłączenia ustawienie jednego nieużywanego, zaufanego prywatnego adresu, na przykład 169.254.0.1, jako jedynej dozwolonej sieci. Ta wartość dokumentacyjna nie może odpowiadać adresowi używanemu produkcyjnie.

CAPTCHA jest zawsze aktywna w SPX Portal i nie można jej wyłączyć. Świadome zarządzanie CAPTCHA na Sophos Firewall wyjaśnia ograniczenia ustawień CAPTCHA dla innych portali.

WebAdmin, User Portal, VPN Portal, Captive Portal i oba portale SPX używają tego samego centralnego wyboru certyfikatu. Zmiana może więc jednocześnie wpłynąć na kilka usług. Certyfikat, SAN, ścieżkę odzyskiwania i rzeczywisty adres portalu należy zaplanować zgodnie z instrukcją Zarządzanie certyfikatami na Sophos Firewall. Dla nazwy publicznej odpowiedni może być certyfikat Let’s Encrypt na Sophos Firewall.

Połączenie szablonu z polityką SMTP

W MTA mode szablon SPX wybiera się w odpowiedniej polityce SMTP route and scan pod Email > Policies and exceptions.

Użycie domeny jako wyzwalacza

W Domains and routing target przypisuje się szablon do chronionej domeny. Następnie obowiązuje on dla pasujących wiadomości wychodzących. Szerokie przypisanie domenowe najpierw testuje się z jednym nadawcą pilotażowym i jednym zewnętrznym odbiorcą testowym.

Użycie Data Control jako wyzwalacza

1. W Email > Data control list utworzyć jednoznacznie nazwaną listę albo sprawdzić istniejącą.
2. W polityce SMTP route and scan włączyć Data protection.
3. Przypisać planowany szablon SPX do Data Control List.
4. Wykonać jeden pozytywny test treści i jeden podobny test negatywny.

Jeśli szablon SPX jest już ustawiony w Domains and routing target, ma pierwszeństwo przed szablonem Data Control. Dopasowanie Data Control List dowodzi ponadto tylko skonfigurowanego dopasowania treści. Rzeczywisty przepływ poczty musi potwierdzić, czy zaszyfrowano właściwą wiadomość.

Użycie wyzwalacza nadawcy

W Email > Encryption > SPX configuration wybrać Default SPX template. Ma on zastosowanie do szyfrowania SPX uruchamianego przez nadawcę tylko wtedy, gdy polityka SMTP nie dostarcza już szablonu na poziomie domeny lub Data Control. None wyłącza tę domyślną ścieżkę.

Weryfikacja zaszyfrowanego przepływu poczty

Zapisać godzinę testu, nadawcę, odbiorcę, temat i oczekiwany wyzwalacz. Następnie wykonać co najmniej te testy:

1. Test pozytywny: Wiadomość wychodząca uruchamia dokładnie planowany szablon SPX.
2. Test hasła: Odbiorca otrzymuje hasło lub link rejestracyjny planowanym kanałem i może otworzyć PDF.
3. Test treści: Temat, treść i załączniki znajdują się w PDF zgodnie z oczekiwaniami i są czytelne.
4. Test odpowiedzi: Jeśli funkcja jest włączona, link odpowiedzi prowadzi do oczekiwanego FQDN, a odpowiedź testowa dociera do pierwotnego nadawcy.
5. Test negatywny: Podobna wiadomość bez wyzwalacza nie jest wysyłana jako PDF SPX.
6. Test wygaśnięcia: Rejestracja, zapisane hasło i okres odpowiedzi zachowują się przewidywalnie po zdefiniowanym czasie ważności.
7. Test certyfikatu: Przeglądarka i zewnętrzny odbiorca otrzymują pełny zaufany łańcuch certyfikatów dla używanego FQDN portalu.

Do pierwszej korelacji służą Email > Mail logs, Log Viewer oraz pliki MTA smtpd_main.log, smtpd_error.log i smtpd_panic.log. Komunikat błędu należy powiązać z tą samą wiadomością testową i godziną. Usługi i logi Sophos Firewall opisują dostęp i dodatkowe pliki logów.

W HA logi znajdują się na węźle, który przetworzył ruch. Po kontrolowanym failoverze osobno testuje się nową wiadomość SPX, rejestrację hasła i odpowiedź. Nie należy zakładać, że istniejąca sesja portalu lub trwający proces rejestracji będą kontynuowane bez przerwy. Podstawy opisano w Klastry HA Sophos Firewall.

Systematyczne zawężanie błędów

Wiadomość nie jest szyfrowana

Sprawdzić kierunek, chronioną domenę, faktycznie używaną politykę SMTP route and scan oraz priorytet wyzwalaczy. Dla Data Control dodatkowo sprawdzić Data protection, dopasowanie listy i przypisanie szablonu. Wyzwalacz nadawcy wymaga ustawionego szablonu domyślnego, którego nie zastępuje szablon domeny lub Data Control. Dwa udokumentowane zapisy nagłówka nie są powodem, aby wdrażać oba produkcyjnie bez testów.

Link rejestracyjny lub portal jest niedostępny

Sprawdzić FQDN, publiczne rozwiązywanie DNS, port, certyfikat, Allowed networks i ważność linku. Pusta wartość Allowed Networks jest traktowana jako Any, więc nie stanowi bezpiecznego stanu wyłączenia. Jeśli klient dociera do innego hosta lub portalu, URL, NAT albo przypisanie certyfikatu nie odpowiada planowanej ścieżce.

Nie można otworzyć PDF

Najpierw należy dopasować typ hasła do konkretnej wiadomości. Hasło jednorazowe obowiązuje tylko dla tej wiadomości. Przy hasłach zapisanych lub zarejestrowanych przyczyną może być wygaśnięcie albo wiele modeli haseł. Po SPX Password Reset nadawca musi ponownie bezpiecznie przekazać nowe hasło odbiorcy.

Bezpieczna odpowiedź nie dociera

Sprawdzić w szablonie Enable SPX reply portal, okres odpowiedzi, FQDN portalu, port, certyfikat i dozwolone źródła. Następnie sprawdzić Mail logs i logi MTA dla konkretnej odpowiedzi. Pomyślne otwarcie PDF nie dowodzi działania kanału zwrotnego.

Weryfikacja DKIM nie działa po SPX

SPX zmienia treść i załączniki. Jeśli wiadomość zostanie podpisana przed tą zmianą, podpis może być nieprawidłowy u odbiorcy. Należy określić, czy wewnętrzny serwer poczty, Sophos Firewall czy późniejsza brama podpisuje po wszystkich planowanych modyfikacjach. Łańcuch przetwarzania i test zewnętrzny trzeba zweryfikować łącznie.

Bezpieczne wycofanie

1. Najpierw usunąć konkretne przypisanie SPX z Domains and routing target lub Data Control List.
2. Jeśli jest używany, ustawić Default SPX template na None.
3. Wykonać wychodzący test negatywny i potwierdzić, że nie powstaje nowy PDF SPX.
4. Wycofać Reply i Registration Portal tylko wtedy, gdy nie zależy od nich żadna inna aktywna polityka SPX.
5. Przywrócić tymczasowy publiczny dostęp portowy, DNS lub portalowy do udokumentowanego stanu poprzedniego.
6. Usunąć szablon dopiero wtedy, gdy nie odwołuje się do niego żadna polityka ani aktywny proces operacyjny.
7. Zachować Mail logs i logi MTA z ostatniego testu szyfrowanego i pierwszego nieszyfrowanego.

Przed zmianą produkcyjnych ścieżek pocztowych i portalowych należy utworzyć aktualną kopię zapasową Sophos Firewall. SPX może nadal działać w środowiskach air gap, lecz zewnętrzne zależności DNS, certyfikatów i portalu muszą być osobno osiągalne. Ograniczenia produktu opisano w Funkcje SFOS bez dostępu do Internetu.

Operacyjna lista kontrolna

• Sprawdzono licencję, model, przepływ poczty MTA i odbiorcę zewnętrznego.
• Wyzwalacz i jego priorytet są udokumentowane.
• Typ hasła i bezpieczny kanał przekazania pasują do zastosowania.
• FQDN portalu, certyfikat, port i Allowed Networks mają wąski zakres.
• Przypisanie domeny, Data Control lub domyślne jest jednoznaczne.
• Testy pozytywny, negatywny, hasła, PDF i odpowiedzi zakończyły się powodzeniem.
• Mail logs i logi MTA można powiązać z wiadomością testową.
• Failover HA i logi lokalne dla węzłów są uwzględnione w procedurze operacyjnej.
• Właściciel, okresy wygaśnięcia, data przeglądu i wycofanie są udokumentowane.

FAQ