Przetwarzanie podpisów e-mail u klienta czy u dostawcy: co naprawdę dzieje się z Twoją pocztą

Zarządzanie podpisami e-mail po stronie serwera stało się standardem w organizacjach korzystających z Microsoft 365. Zamiast liczyć na to, że każde urządzenie i każdy profil Outlook zastosuje właściwy podpis, centralna usługa dodaje go spójnie w momencie, gdy poczta opuszcza tenant. Znacznie rzadziej mówi się o tym, co ta architektura oznacza dla drogi, jaką pokonuje wiadomość — i jakie pytania powinien zadać przegląd bezpieczeństwa, zanim powstanie pierwszy konektor.

Co się dzieje, gdy Microsoft 365 kieruje pocztę przez usługę podpisów

Aby usługa działająca po stronie serwera mogła zmodyfikować wiadomość, wiadomość musi do tej usługi trafić. W Microsoft 365 realizuje się to zwykle za pomocą reguł transportowych i konektorów: poczta wychodząca spełniająca zdefiniowane warunki jest przekierowywana z Exchange Online do usługi przetwarzającej, a drugi konektor przyjmuje zmodyfikowaną wiadomość z powrotem w celu finalnego dostarczenia. Microsoft opisuje ten wzorzec jako standardowy sposób integracji dodatkowej usługi pocztowej.

W czasie, gdy wiadomość znajduje się w usłudze przetwarzającej, jest obsługiwana jako kompletna wiadomość MIME. Obejmuje to:

• adresy nadawcy i odbiorców oraz pełny zestaw nagłówków
• temat i treść wiadomości, we wszystkich formatach, w jakich występuje
• załączniki i osadzone elementy, ponieważ są częścią struktury MIME
• wszystko, co usługa sama dodaje, na przykład podpisy, disclaimery lub bannery kampanii

Usługa parsuje tę strukturę, wstawia lub przepisuje HTML podpisu, składa wiadomość na nowo i przekazuje ją z powrotem do Microsoft 365. Gdy warstwę przetwarzania hostuje dostawca, każda objęta regułami wiadomość wychodząca przechodzi przez jego infrastrukturę — krótko, ale w całości.

Przejściowy dostęp to nadal dostęp

Wielu dostawców usług hostowanych deklaruje — wiarygodnie — że nie przechowuje treści wiadomości. To istotny mechanizm kontrolny i warto go weryfikować. Nie jest to jednak to samo, co brak dostępu. Polityka braku retencji ogranicza czas przechowywania danych; nie zmienia faktu, że systemy dostawcy odbierają i przetwarzają pełną wiadomość w tranzycie, ani tego, że personel dostawcy, jego narzędzia i pipeline aktualizacji znajdują się wewnątrz tej ścieżki.

Nie jest to zarzut wobec kogokolwiek i nie oznacza, że usługi hostowane są niebezpieczne. To po prostu precyzyjny opis architektury — i od tego opisu powinien zaczynać się przegląd bezpieczeństwa. Hostowana usługa podpisów może być dobrze zabezpieczona, a mimo to stanowić dodatkową granicę zaufania.

Co powinien objąć przegląd bezpieczeństwa

• Granica zaufania. Obok Microsoft 365 pojawia się nowy operator — z własnymi systemami, procesami supportu i uprzywilejowanymi administratorami. Kto ma dostęp do warstwy przetwarzania i na jakich zasadach?
• Łańcuch dostaw. Usługa znajduje się na ścieżce każdej objętej regułami wiadomości wychodzącej. Incydent, wadliwa aktualizacja lub problem operacyjny u dostawcy może dotknąć wielu tenantów jednocześnie. Wytyczne NIST traktują dostawców technologii jako element zarządzania ryzykiem łańcucha dostaw, a due diligence powinno być proporcjonalne do tej pozycji.
• Dostępność i mail flow. Dostarczalność poczty wychodzącej zależy teraz od dostępności relaya, jego certyfikatów i poprawnej konfiguracji konektorów. Co się dzieje, gdy usługa jest niedostępna — poczta czeka w kolejce, omija usługę czy nie wychodzi?
• Uwierzytelnianie wiadomości. Modyfikacja wiadomości w tranzycie może wpływać na ważność DKIM i wymaga starannej konfiguracji konektorów, TLS oraz — w zależności od przepływu — ARC.
• Tożsamość i uprawnienia. Jakich zgód na poziomie tenanta i jakich application permissions wymaga usługa i czy każde z nich jest uzasadnione konkretną funkcją?
• Logowanie i forensics. Jakie metadane są logowane, gdzie, jak długo i kto kontroluje dostęp do tych logów?

Co zmienia przetwarzanie u klienta (BYOC)

W modelu hostowanym przez klienta — SignaGrid Private jest zaprojektowany dokładnie jako taka opcja wdrożenia — warstwa przetwarzania działa we własnym środowisku chmurowym klienta. Infrastruktura dostawcy zostaje usunięta ze ścieżki poczty: wiadomości trafiają do relaya, którym operuje klient, w wybranym przez niego regionie, zabezpieczonego kluczami i sekretami pod jego kontrolą.

To zmienia odpowiedzi na kilka pytań z przeglądu:

• treść wiadomości pozostaje w środowisku objętym politykami bezpieczeństwa klienta
• logi i ich retencja pozostają w środowisku klienta
• klient decyduje o oknach aktualizacji i może kontrolować dostęp supportu do środowiska
• nie ma współdzielonego środowiska uruchomieniowego, więc problem operacyjny innej organizacji nie działa na Twojej infrastrukturze

Czego BYOC nie zdejmuje z klienta

Przetwarzanie u klienta to architektoniczne przesunięcie odpowiedzialności, a nie automatyczny wzrost bezpieczeństwa. Klient przejmuje obszary, które wcześniej absorbował dostawca:

• Zabezpieczenie relaya. Hosty, segmentacja sieci, sekrety, certyfikaty i dostęp do środowiska przetwarzania to obszary, które klient musi sam utwardzić i monitorować.
• Projekt mail flow. Konektory, zakres routingu, zachowanie w razie awarii i procedury awaryjnego bypassu nadal trzeba zaprojektować, udokumentować i przetestować.
• Dostarczalność. SPF, DKIM, DMARC oraz — tam gdzie to istotne — ARC nadal mają znaczenie. Prywatny relay modyfikujący wiadomości uczestniczy w tym samym łańcuchu uwierzytelniania co każdy inny relay, a błędna konfiguracja równie skutecznie psuje dostarczalność.
• Operacje. Wydajność, monitoring, patchowanie i przetestowana ścieżka aktualizacji stają się częścią środowiska operacyjnego klienta.

Źle utrzymywany prywatny relay może być w praktyce słabszy niż kompetentnie prowadzona usługa hostowana. Wartością BYOC nie jest automatyczne bezpieczeństwo, lecz to, że granica zaufania, ścieżka danych i mechanizmy operacyjne są pod Twoją kontrolą i możesz je samodzielnie weryfikować.

Jak wybrać model

Żaden z modeli nie jest uniwersalnie właściwy. Zarządzana usługa chmurowa, taka jak SignaGrid Cloud, pasuje do organizacji, które akceptują zewnętrzny procesor w zamian za mniejszy nakład operacyjny — pod warunkiem, że dostawca jest transparentny co do przepływu danych i potrafi udokumentować swoje mechanizmy kontrolne. Wdrożenie u klienta, takie jak SignaGrid Private, jest odpowiedzią dla organizacji, których wymagania regulacyjne, kontraktowe lub wewnętrzny model ryzyka wykluczają zewnętrzny podmiot na ścieżce poczty — i które są gotowe prowadzić relay w sposób profesjonalny.

Właściwe pytanie nie brzmi, który model jest bezpieczniejszy w teorii. Brzmi: które granice zaufania Twoja organizacja jest gotowa zaakceptować, a które musi kontrolować samodzielnie.