DMARC i szyfrowanie rozwiązują różne zagrożenia związane z pocztą elektroniczną. DMARC pomaga systemowi odbierającemu ocenić, czy domena jest używana poprzez wyrównaną, uwierzytelnioną ścieżkę. Szyfrowanie chroni dane komunikatów w przeskoku transportowym lub, w przypadku innego projektu, między punktami końcowymi komunikatów. Żadna kontrola nie dostarcza automatycznie drugiej.
To rozróżnienie ma znaczenie, ponieważ ta sama wiadomość może zostać dobrze uwierzytelniona i nadal podróżować bez zamierzonego zabezpieczenia transportu. Wiadomość może również zostać przesłana za pośrednictwem szyfrowanego połączenia, żądając domeny From, która nie ma wyrównanego uwierzytelnienia.
Zacznij od pytania o ochronę
Zanim wybierzesz sterowanie, zapytaj, co należy chronić:
- Pytanie zabezpieczające: czy przechodząca uwierzytelniona domena jest wyrównana z domeną w polu Od?; Odpowiedni mechanizm: DMARC z SPF Lub DKIM; Czego nie ustala: Poufność, intencje nadawcy lub bezpieczna treść
- Pytanie zabezpieczające: Czy wiadomość została podpisana przez posiadacza klucza prywatnego DKIM dla domeny d=?; Odpowiedni mechanizm: DKIM ; Czego nie ustala: Tożsamość człowieka, tajemnica lub umiejscowienie skrzynki odbiorczej
- Pytanie zabezpieczające: czy ten przeskok dostawy SMTP był wymagany do użycia akceptowalnego TLS ?; Odpowiedni mechanizm: MTA-STS lub inna polityka transportowa; Czego nie ustanawia: kompleksowa poufność lub z domeny wyrównanie
- Pytanie zabezpieczające: Czy odbiorca może odszyfrować treść przeznaczoną dla tego odbiorcy?; Odpowiedni mechanizm: szyfrowanie na poziomie wiadomości; Czego nie ustala: Dopasowanie DMARC chyba że zostało skonfigurowane osobno
Ta macierz opisuje granice kontroli, a nie ranking produktów. Kompletna architektura może wykorzystywać więcej niż jeden mechanizm, ponieważ zagrożenia nie są wymienne.
Podążaj jedną syntetyczną ścieżką komunikatu
Rozważmy fikcyjną fakturę wysłaną z billing@shop.example.com na accounts@buyer.example.org poprzez bezpośrednią dostawę SMTP . Usługa wysyłająca korzysta z domeny kopertowej pod adresem bounce.mailer.example.net i podpisuje się za pomocą d=shop.example.com. Załóż obowiązującą politykę DMARC i przeprowadź weryfikację tożsamości. W tym syntetycznym scenariuszu wysyłanie MTA odkrywa i pobiera prawidłową politykę MTA-STS w trybie egzekwowania dla domeny odbiorczej buyer.example.org z https://mta-sts.buyer.example.org/.well-known/mta-sts.txt. Sprawdza, czy wybrane miejsce docelowe, mx1.buyer.example.org , jest zgodne z polityką, następnie łączy się i negocjuje TLS , weryfikując certyfikat MX przed przesłaniem wiadomości.
Pod RFC 8461 §3.3, RFC 8461 §4.1, RFC 8461 §4.2 I RFC 8461 §5hipotetyczne kontrole potwierdzałyby następujące stwierdzenia:
- DKIM może zapewnić wyrównaną ścieżkę przekazywania, ponieważ podpis weryfikuje, a jego domena d= odpowiada domenie From w tym przykładzie.
- DMARC może przechodzić na poziomie wiadomości przez tę wyrównaną ścieżkę DKIM .
- Odbierający przeskok SMTP korzystał z protokołu TLS zgodnie z opublikowaną polityką transportową domeny odbiorcy, przy założeniu, że polityka ta była ważna, aktualna i prawidłowo zastosowana.
- Żaden z tych faktów nie dowodzi, że faktura jest autentyczna, że konto nadawcy nie zostało naruszone, ani że każda poprzednia i późniejsza kopia wiadomości pozostaje zaszyfrowana.
Teraz zmień tylko domenę podpisującą na d=mailer.example.net. DKIM nadal może przejść, ale ta niepowiązana domena nie będzie zgodna z shop.example.com . Przeskok dostawy chroniony protokołem TLS nie naprawia tego błędu wyrównania.
Oddziel podpisywanie i szyfrowanie DKIM
Pod RFC 6376 §3.7, DKIM stosuje podpis kryptograficzny do wybranych danych wiadomości. Weryfikator wykorzystuje klucz publiczny opublikowany dla selektor i d = domena. Podpis stanowi dowód na temat podpisanej treści i domeny podpisu. Nie ukrywa przekazu.
Szyfrowanie ma inny cel. Pod RFC 3207 §6, SMTP TLS chroni dane w negocjowanym połączeniu między systemami, a nie w pełnej, kompleksowej ścieżce wiadomości. MTA-STS umożliwia domenie odbierającej opublikowanie zasad, których mogą używać zgodni nadawcy podczas sprawdzania dostarczania TLS do swoich hostów MX . Raportowanie TLS może zapewnić zbiorczą informację zwrotną na temat awarii transportu w ramach RFC 8460 §4.1, RFC 8460 §4.2 I RFC 8460 §4.3. Te elementy sterujące nie zamieniają poczty SMTP w całkowicie zaszyfrowany obiekt.
Szyfrowanie na poziomie wiadomości to kolejna warstwa, ilustrowana przez S/MIME w RFC 8551 §1 I RFC 8551 §3.3. Może chronić treść, dzięki czemu mogą ją odczytać tylko zamierzone punkty końcowe z odpowiednimi kluczami, ale dystrybucja kluczy i przetwarzanie certyfikatów, np RFC 8551 §4 materiał. Możliwości odbiorcy, odzyskiwanie danych i dostęp do archiwów również wymagają wyraźnego projektu operacyjnego. DMARC pozostaje odrębną oceną widocznego uwierzytelniania z domeny i wyrównanego.
Zdefiniuj każdą decyzję dotyczącą zaufania
Przydatny zapis projektu wymienia cztery rzeczy dla każdego elementu sterującego:
- Sterowanie: DMARC ; Tożsamość lub zasób: domena w From; Kotwica zaufania: zasady DNS plus dostosowany wynik SPF lub DKIM ; Dowody do zachowania: Wynik zaufanego odbiorcy i obowiązujące zasady
- Sterowanie: DKIM ; Tożsamość lub zasób: domena podpisująca i selektor; Kotwica zaufania: klucz publiczny DNS ; Dowody, które należy zachować: podpis, wynik weryfikacji i kluczowy zapis
- Sterowanie: MTA-STS ; Tożsamość lub zasób: domena odbiorcza i transport MX ; Kotwica zaufania: wykrywanie DNS plus polityka HTTPS; Dowody do zachowania: identyfikator polisy, pobrana polisa i wynik dostarczenia
- Kontrola: Szyfrowanie wiadomości; Tożsamość lub zasób: klucze odbiorcy lub punktu końcowego; Kotwica zaufania: wybrany model zaufania klucza i certyfikatu; Dowody do zachowania: stan szyfrowania, mapowanie odbiorców i cykl życia klucza
Nie przekładaj ich na pojedynczą zieloną plakietkę. Każda odpowiedź ma węższe znaczenie i inny tryb awarii.
Mapuj kontrole na zagrożenia
DMARC może sprawić, że nieupoważnione użycie chronionej domeny From będzie łatwiejsze do zidentyfikowania i obsługi przez uczestniczących odbiorców. Nie zapobiega niewłaściwemu wykorzystaniu legalnego konta, sprawdzaniu, czy żądanie płatności jest prawdziwe, ani szyfrowaniu przechowywanej poczty.
TLS może zmniejszyć narażenie na pasywne przechwytywanie podczas chronionego przeskoku. Nie uwierzytelnia domeny From. System negocjujący protokół TLS z niewłaściwym lub niezaufanym miejscem docelowym nie zapewnia takiej samej pewności, jak połączenie potwierdzone zasadami i wymuszone zasadami.
Szyfrowanie wiadomości może chronić zawartość poza sesją transportową, w zależności od jej projektu. Samo w sobie nie tworzy zgodności DMARC , nie autoryzuje transakcji biznesowych ani nie eliminuje naruszenia bezpieczeństwa punktu końcowego.
Buduj dowody, nie zawyżając ich
Aby uzyskać tożsamość, przechwyć otrzymaną wiadomość przedstawiciela i zapisz Od, tożsamość koperty, każdą domenę DKIM d=, nieprzetworzone wyniki uwierzytelnienia, wyrównanie i dyspozycję DMARC . W przypadku transportu należy zachować politykę MTA-STS , zakres MX i dowody raportowania TLS . W przypadku szyfrowania wiadomości należy udokumentować, kto przechowuje klucze, w jaki sposób rejestrowani są odbiorcy, co się dzieje w przypadku utraty klucza i które systemy mogą uzyskać dostęp do zwykłego tekstu.
Badanie laboratoryjne powinno być oznaczone jako badanie. Nie dowodzi, że każda trasa produkcyjna zachowuje się identycznie. Weryfikuj usługi o niskim wolumenie, trasy przekazywania, zapasowe hosty MX oraz dostęp mobilny lub archiwalny, jeśli wpływają one na cel kontroli.
Przypisz osobnych właścicieli i trasy odzyskiwania
Operacje pocztowe często posiadają uwierzytelnianie i transport SMTP . Architektura bezpieczeństwa może posiadać własne zasady, pokrycie zagrożeń i standardy szyfrowania. Zespoły aplikacji są właścicielami tras wysyłania, które generują pocztę biznesową. Zespoły prawne i rejestrujące mogą wpływać na wymagania dotyczące przechowywania zawartości i odzyskiwania kluczy.
Nadaj każdej kontrolce wyzwalacz eskalacji. Regresja wyrównania dotyczy własności nadawcy i operacji pocztowych. Awaria zasad TLS trafia do właścicieli transportu i DNS . Utracony klucz szyfrowania wiadomości trafia do procesu odzyskiwania kluczy. Jedna ogólna kolejka „zabezpieczeń poczty e-mail” ukrywa decyzję, którą należy podjąć.
Wyraźnie podejmij decyzję o zakupie
Przed zatwierdzeniem projektu napisz jedno zdanie opisujące wymagany wynik. „Ogranicz nieautoryzowane użycie naszych domen Od” wskazuje na DMARC i dostosowane uwierzytelnianie. „Wymagaj akceptowalnego TLS w przypadku dostawy do naszej domeny” wskazuje na politykę transportową. „Trzymaj treść wiadomości nieczytelną poza zatwierdzonymi punktami końcowymi” wymaga projektu szyfrowania wiadomości.
Wyniki te mogą współistnieć. Ważną decyzją jest sfinansowanie brakującej ochrony, zamiast zakładać, że znany akronim dotyczący bezpieczeństwa poczty elektronicznej obejmuje jednocześnie tożsamość, poufność i legalność biznesową.
Zachowaj wnioski w dowodach
W przypadku mocowania faktury zachowaj pomyślne wyrównanie DKIM i zweryfikowany przeskok SMTP w różnych polach dowodów. Jeśli tylko d= zmieni się na niepowiązaną domenę dostawcy, podczas gdy SPF pozostanie niewyrównany, TLS nadal nie utworzy dopasowanej tożsamości. Opisane tutaj pobieranie zasad, negocjacja TLS i weryfikacja podpisu zakładają wprowadzanie danych wejściowych do nauczania, a nie przeprowadzanie testów sieci lub wiadomości.