uwierzytelnianie Email na platformie Microsoft 365

Porada

Czy wiesz, że możesz bezpłatnie wypróbować funkcje w Microsoft Defender XDR Office 365 planie 2? Użyj 90-dniowej wersji próbnej Ochrona usługi Office 365 w usłudze Defender w centrum wersji próbnej portalu Microsoft Defender. Dowiedz się, kto może zarejestrować się i zapoznać się z warunkami dotyczącymi wersji próbnej tutaj.

Jako organizacja platformy Microsoft 365 ze skrzynkami pocztowymi w Exchange Online lub autonomiczną organizacją Exchange Online Protection (EOP) bez Exchange Online skrzynek pocztowych ochrona integralności wiadomości e-mail od nadawców w domenach jest ważna. Adresaci powinni mieć pewność, że wiadomości od nadawców w domenie rzeczywiście pochodzą od nadawców w domenie.

uwierzytelnianie Email (nazywane również weryfikacją poczty e-mail) to grupa standardów umożliwiających identyfikowanie i zapobieganie dostarczaniu wiadomości e-mail od podrobionych nadawców (nazywanych również fałszowaniem). Sfałszowane nadawcy są często używane w przypadku naruszenia zabezpieczeń poczty e-mail (BEC), wyłudzania informacji i innych ataków e-mail. Te standardy obejmują:

  • Struktura zasad nadawcy (SPF): określa źródłowe serwery poczty e-mail, które są autoryzowane do wysyłania wiadomości e-mail dla domeny.
  • DomainKeys Identified Mail (DKIM): używa domeny do cyfrowego podpisywania ważnych elementów wiadomości, aby upewnić się, że wiadomość nie została zmieniona podczas przesyłania.
  • Uwierzytelnianie komunikatów oparte na domenie, Raportowanie i zgodność (DMARC): określa akcję dla komunikatów, które nie sprawdzają nadawców SPF lub DKIM w domenie, i określa, gdzie wysłać wyniki DMARC (raportowanie).
  • Uwierzytelniony łańcuch odebranych odebranych (ARC) : zachowuje oryginalne informacje uwierzytelniania poczty e-mail przez znane usługi, które modyfikują komunikaty podczas przesyłania. Docelowy serwer poczty e-mail może używać tych informacji do uwierzytelniania komunikatów, które w przeciwnym razie mogłyby zakończyć się niepowodzeniem DMARC.

Należy pamiętać, że standardy te są współzależnością bloków konstrukcyjnych , które współpracują ze sobą , aby zapewnić najlepszą możliwą ochronę poczty e-mail przed fałszowaniem i wyłudzaniem informacji. Wszystko mniej niż wszystkie metody uwierzytelniania poczty e-mail powoduje ochronę niestandardową.

Aby skonfigurować uwierzytelnianie poczty e-mail dla poczty wysyłanej z organizacji platformy Microsoft 365 przy użyciu skrzynek pocztowych w Exchange Online lub autonomicznych organizacjach Exchange Online Protection (EOP) bez Exchange Online skrzynek pocztowych, zobacz następujące artykuły:

Aby zapobiec niepowodzeniom uwierzytelniania poczty e-mail z powodu usług modyfikujących pocztę przychodzącą wysyłaną do organizacji platformy Microsoft 365, zobacz Konfigurowanie zaufanych uszczelniaczy ARC.

W pozostałej części tego artykułu wyjaśniono:

Dlaczego internetowa poczta e-mail wymaga uwierzytelniania

Zgodnie z projektem poczta e-mail protokołu SMTP (Simple Mail Transfer Protocol) w Internecie nie podejmuje żadnych wysiłków, aby sprawdzić, czy nadawca wiadomości jest tym, za kogo się podaje.

Standardowa wiadomość e-mail SMTP składa się z koperty wiadomości i zawartości wiadomości:

  • Koperta wiadomości zawiera informacje dotyczące przesyłania i odbierania komunikatu między serwerami SMTP. Koperta wiadomości została opisana w dokumencie RFC 5321. Adresaci nigdy nie widzą koperty wiadomości, ponieważ jest ona generowana podczas procesu transmisji komunikatów.
  • Zawartość wiadomości zawiera pola nagłówka wiadomości (łącznie nazywane nagłówkiem komunikatu) i treść komunikatu. Nagłówek komunikatu jest opisany w dokumencie RFC 5322.

W związku z tym projektem komunikat ma wiele wartości nadawcy:

  • Adres MAIL FROM (znany również jako 5321.MailFrom adres, nadawca P1 lub nadawca koperty) to adres e-mail używany do przesyłania wiadomości między serwerami poczty e-mail SMTP. Ten adres jest zwykle rejestrowany w polu nagłówek Return-Path w nagłówku wiadomości (chociaż źródłowy serwer poczty e-mail może wyznaczyć inny adres e-mail ze ścieżką powrotną ). Ten adres e-mail jest używany w raportach o braku dostawy (nazywanych również serwerami NDR lub wiadomościami odrzuceń).
  • Adres Od (znany również jako 5322.From adres lub nadawca P2) jest adresem e-mail w polu Od nagłówka i jest adresem e-mail nadawcy wyświetlanym w klientach poczty e-mail.

Poniższy przykład przedstawia uproszczoną transkrypcję prawidłowej transmisji komunikatów między dwoma serwerami poczty e-mail SMTP:

S: HELO woodgrovebank.com
S: MAIL FROM: dubious@proseware.com
S: RCPT TO: astobes@tailspintoys.com
S: DATA
S: To: "Andrew Stobes" <astobes@tailspintoys.com>
S: From: "Woodgrove Bank Security" <security@woodgrovebank.com>
S: Subject: Woodgrove Bank - Action required
S:
S: Greetings,
S:
S: We need to verify your banking details.
S: Please click the following link to verify that we have the right information for your account.
S:
S: https://short.url/woodgrovebank/updateaccount/12-121.aspx
S:
S: Thank you,
S: Woodgrove Bank
S: .

W tym przykładzie:

  • Źródłowy serwer poczty e-mail identyfikuje się jako woodgrovebank.com do docelowego serwera poczty e-mail tailspintoys.com w poleceniu HELO.
  • Adresatem wiadomości jest astobes@tailspintoys.com.
  • Adres MAIL FROM w kopercie wiadomości (używany do przesyłania wiadomości między serwerami poczty e-mail SMTP) to dubious@proseware.com.
  • Adres Od wyświetlany na kliencie poczty e-mail adresata to security@woodgrovebank.com.

Mimo że ta wiadomość jest prawidłowa zgodnie z protokołem SMTP, domena adresu MAIL FROM (proseware.com) nie jest zgodna z domeną w polu Adres od (woodgrovebank.com). Ta wiadomość jest klasycznym przykładem fałszowania, w którym intencja może oszukać odbiorcę, maskując prawdziwe źródło wiadomości do użycia podczas ataku wyłudzania informacji.

Oczywiście wiadomość e-mail SMTP wymaga pomocy w sprawdzeniu, czy nadawcy wiadomości są osobami, które twierdzą, że są!

Jak SPF, DKIM i DMARC współpracują ze sobą w celu uwierzytelniania nadawców wiadomości e-mail

W tej sekcji opisano, dlaczego potrzebujesz SPF, DKIM i DMARC dla domen w Internecie.

  • SPF: Jak wyjaśniono w artykule Konfigurowanie SPF do identyfikowania prawidłowych źródeł poczty e-mail dla domeny usługi Microsoft 365, SPF używa rekordu TXT w systemie DNS do identyfikowania prawidłowych źródeł poczty z domeny MAIL FROM i co zrobić, jeśli docelowy serwer poczty e-mail odbiera wiadomość e-mail z niezdefiniowanego źródła ("trudne niepowodzenie" odrzucenia wiadomości; "Nietrwałe niepowodzenie" w celu zaakceptowania i oznaczenia komunikatu).

    Problemy z filtrem SPF:

    • SPF weryfikuje źródła dla nadawców tylko w domenie MAIL FROM. SPF nie uwzględnia domeny w domenie Adres od lub wyrównanie między domenami MAIL FROM i From:

      • Osoba atakująca może wysłać wiadomość e-mail, która przekazuje uwierzytelnianie SPF (fałszywie ujemne), wykonując następujące kroki:
        • Zarejestruj domenę (na przykład proseware.com) i skonfiguruj SPF dla domeny.
        • Wyślij wiadomość e-mail z prawidłowego źródła dla zarejestrowanej domeny z adresami e-mail z innej domeny (na przykład woodgrovebank.com).
      • Legalna usługa poczty e-mail, która wysyła wiadomość e-mail w imieniu innych domen, może kontrolować adres MAIL FROM. Inne domeny i domena MAIL FROM nie są zgodne, więc komunikaty nie mogą przekazać uwierzytelniania SPF (wynik fałszywie dodatni).

    • SPF przerywa działanie po napotkaniu komunikatów opartych na serwerze przekazywania wiadomości e-mail, które przekierowuje lub przekazuje komunikaty .

      • Przekazywanie wiadomości e-mail na podstawie serwera powoduje zmianę źródła wiadomości z oryginalnego serwera na serwer przesyłania dalej.
      • Serwer przesyłania dalej nie jest autoryzowany do wysyłania wiadomości e-mail z oryginalnej domeny MAIL FROM, więc wiadomość nie może przekazać uwierzytelniania SPF (wynik fałszywie dodatni).

    • Każda domena i wszystkie poddomeny wymagają własnych indywidualnych rekordów SPF. Domeny podrzędne nie dziedziczą rekordu SPF domeny nadrzędnej. Takie zachowanie staje się problematyczne, jeśli chcesz zezwolić na pocztę e-mail ze zdefiniowanych i używanych poddomen, ale zapobiegaj niezdefiniowanym i nieużywanym domenom podrzędnym poczty e-mail.

  • DKIM: Jak wyjaśniono w artykule Konfigurowanie modułu DKIM do podpisywania wiadomości e-mail z domeny platformy Microsoft 365, program DKIM używa domeny do cyfrowego podpisywania ważnych elementów wiadomości (w tym z adresu) i przechowuje podpis w nagłówku wiadomości. Serwer docelowy sprawdza, czy podpisane elementy komunikatu nie zostały zmienione.

    Jak program DKIM pomaga SPF: DKIM może weryfikować komunikaty, które nie spełniają SPF. Przykład:

    • Wiadomości z usługi hostingu poczty e-mail, w której ten sam adres MAIL FROM jest używany do obsługi poczty z innych domen.
    • Komunikaty, które napotykają przekazywanie wiadomości e-mail na podstawie serwera.

    Ponieważ sygnatura DKIM w nagłówku komunikatu nie ma wpływu ani nie zmienia się w tych scenariuszach, te komunikaty mogą przekazywać moduł DKIM.

    Problemy z modułem DKIM: domena używana przez program DKIM do podpisywania komunikatu nie musi być zgodna z domeną w polu Adres od wyświetlanym na klientach poczty e-mail.

    Podobnie jak SPF, osoba atakująca może wysłać wiadomość e-mail, która przekazuje uwierzytelnianie DKIM (fałszywie ujemne), wykonując następujące kroki:

    • Zarejestruj domenę (na przykład proseware.com) i skonfiguruj program DKIM dla domeny.
    • Wyślij wiadomość e-mail z adresami e-mail z innej domeny (na przykład woodgrovebank.com).

  • DMARC: Jak wyjaśniono w artykule Konfigurowanie usługi DMARC w celu zweryfikowania domeny Z adresu dla nadawców w usłudze Microsoft 365, usługa DMARC używa SPF i DKIM do sprawdzania zgodności między domenami w adresach MAIL FROM i From. DMARC określa również akcję, którą docelowy system poczty e-mail powinien podjąć w przypadku komunikatów, które nie spełniają funkcji DMARC, i określa, gdzie wysyłać wyniki DMARC (zarówno przebieg, jak i niepowodzenie).

    Jak usługa DMARC pomaga SPF i DKIM: Zgodnie z wcześniejszym opisem, SPF nie podejmuje próby dopasowania domeny w domenie MAIL FROM i adresach z. Program DKIM nie ma znaczenia, czy domena, która podpisała komunikat, jest zgodna z domeną w polu Adres od.

    Usługa DMARC rozwiązuje te braki przy użyciu SPF i DKIM, aby potwierdzić, że domeny w adresach MAIL FROM i From są zgodne.

    Problemy z usługą DMARC: uzasadnione usługi, które modyfikują komunikaty przesyłane przed przerwą dostarczania SPF, DKIM, a zatem sprawdzają DMARC.

  • ARC: Jak wyjaśniono w artykule Konfigurowanie zaufanych uszczelniaczy ARC, uzasadnione usługi, które modyfikują komunikaty przesyłane, mogą używać usługi ARC do zachowania oryginalnych informacji uwierzytelniania poczty e-mail zmodyfikowanych komunikatów.

    Jak usługa ARC pomaga DMARC: docelowy system poczty e-mail może zidentyfikować usługę jako zaufany uszczelniacz ARC. Usługa ARC może następnie użyć zachowanych informacji uwierzytelniania poczty e-mail do zweryfikowania komunikatu.

Uwierzytelnianie przychodzące poczty e-mail dla poczty wysłanej na platformę Microsoft 365

Ze względu na problemy z wyłudzaniem informacji i mniej niż całkowite wdrożenie silnych zasad uwierzytelniania poczty e-mail przez nadawców poczty e-mail w Internecie, platforma Microsoft 365 używa niejawnego uwierzytelniania poczty e-mail do sprawdzania przychodzącej poczty e-mail. Niejawne uwierzytelnianie poczty e-mail rozszerza regularne kontrole SPF, DKIM i DMARC przy użyciu sygnałów z innych źródeł w celu oceny przychodzącej poczty e-mail. Te źródła obejmują:

  • Reputacja nadawcy.
  • Historia nadawcy.
  • Historia adresatów.
  • Analiza behawioralna.
  • Inne zaawansowane techniki.

Aby wyświetlić oryginalne ogłoszenie firmy Microsoft dotyczące uwierzytelniania niejawnego, zobacz A Sea of Phish Part 2 — Enhanced Anti-spoofing in Microsoft 365 (A Sea of Phish Part 2 — Enhanced Anti-spoofing in Microsoft 365).

Korzystając z tych innych sygnałów, wiadomości, które w przeciwnym razie nie będą sprawdzać tradycyjnego uwierzytelniania poczty e-mail, mogą przekazywać uwierzytelnianie niejawne i być dozwolone na platformie Microsoft 365.

Uwierzytelnianie złożone

Wyniki niejawnych testów uwierzytelniania platformy Microsoft 365 są łączone i przechowywane w pojedynczej wartości o nazwie uwierzytelnianie złożone lub compauth w skrócie. Wartość compauth jest ostemplowana w nagłówku Authentication-Results w nagłówkach wiadomości. Nagłówek Authentication-Results używa następującej składni:

Authentication-Results:
   compauth=<fail | pass | softpass | none> reason=<yyy>

Te wartości zostały wyjaśnione w nagłówku komunikatu Authentication-results.

Administratorzy i użytkownicy mogą sprawdzać nagłówki komunikatów, aby dowiedzieć się, w jaki sposób usługa Microsoft 365 zidentyfikowała nadawcę jako podejrzanego, sfałszowanego nadawcę lub zgodnego z prawem.

Porada

Ważne jest, aby zrozumieć, że niepowodzenie uwierzytelniania złożonego nie powoduje bezpośrednio zablokowania komunikatu. Nasz system korzysta z całościowej strategii oceny, która uwzględnia ogólny podejrzany charakter komunikatu wraz z wynikami uwierzytelniania złożonego. Ta metoda ma na celu ograniczenie ryzyka nieprawidłowego zablokowania legalnej poczty e-mail z domen, które mogą nie być ściśle zgodne z protokołami uwierzytelniania poczty e-mail. To zrównoważone podejście pomaga odróżnić prawdziwie złośliwe wiadomości e-mail od nadawców wiadomości, które po prostu nie są zgodne ze standardowymi praktykami uwierzytelniania poczty e-mail.

W poniższych przykładach skupiono się tylko na wynikach uwierzytelniania poczty e-mail (wartość i przyczyna compauth ). Inne technologie ochrony platformy Microsoft 365 mogą identyfikować komunikaty, które przekazują uwierzytelnianie poczty e-mail jako sfałszowane, lub identyfikować wiadomości, które nie uwierzytelniania poczty e-mail są uzasadnione.

  • Scenariusz: Domena w rekordzie SPF lub podpis DKIM nie jest zgodna z domeną w polu Adres od.

  • Wynik: Komunikat może zakończyć się niepowodzeniem uwierzytelniania złożonego. Pomimo niepowodzenia uwierzytelniania złożonego komunikat może nadal być dozwolony, jeśli inne oceny nie wskazują podejrzanego charakteru:

    Authentication-Results: spf=none (sender IP is 192.168.1.8)
  smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
  (signature was verified) header.d=maliciousdomain.com;
  contoso.com; dmarc=none action=none header.from=contoso.com;
  compauth=fail reason=001
From: chris@contoso.com
To: michelle@fabrikam.com

  • Scenariusz: domena fabrikam.com nie ma rekordów SPF, DKIM ani DMARC.

  • Wynik: Komunikaty od nadawców w domenie fabrikam.com mogą zakończyć się niepowodzeniem uwierzytelniania złożonego:

    Authentication-Results: spf=none (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=none
  action=none header.from=fabrikam.com; compauth=fail reason=001
From: chris@fabrikam.com
To: michelle@contoso.com

  • Scenariusz: domena fabrikam.com ma rekord SPF i nie ma rekordu DKIM. Domeny w adresach MAIL FROM i From są zgodne.

  • Wynik: Komunikat może przekazać uwierzytelnianie złożone, ponieważ domena, która przekazała SPF, jest zgodna z domeną w adresie From:

    Authentication-Results: spf=pass (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=bestguesspass
  action=none header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com

  • Scenariusz: domena fabrikam.com ma rekord DKIM bez rekordu SPF. Domena podpisana przez program DKIM wiadomość jest zgodna z domeną w polu Adres od.

  • Wynik: komunikat może przekazać uwierzytelnianie złożone, ponieważ domena w sygnaturze DKIM jest zgodna z domeną w adresie Od:

    Authentication-Results: spf=none (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=pass
  (signature was verified) header.d=outbound.fabrikam.com;
  contoso.com; dmarc=bestguesspass action=none
  header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com

  • Scenariusz: Domena w rekordzie SPF lub podpis DKIM nie jest zgodna z domeną w polu Adres od.

  • Wynik: Komunikat może zakończyć się niepowodzeniem uwierzytelniania złożonego:

    Authentication-Results: spf=none (sender IP is 192.168.1.8)
  smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
  (signature was verified) header.d=maliciousdomain.com;
  contoso.com; dmarc=none action=none header.from=contoso.com;
  compauth=fail reason=001
From: chris@contoso.com
To: michelle@fabrikam.com

Jak uniknąć błędów uwierzytelniania poczty e-mail podczas wysyłania wiadomości e-mail na platformę Microsoft 365

Porada

Klienci platformy Microsoft 365 mogą używać następujących metod, aby zezwalać na komunikaty od nadawców, które są identyfikowane jako błędy fałszowania lub uwierzytelniania:

  • Skonfiguruj rekordy SPF, DKIM i DMARC dla domen: użyj informacji o konfiguracji dostarczonych przez rejestratora domen lub usługę hostingu DNS. Istnieją również firmy innych firm, które pomagają w konfigurowaniu rekordów uwierzytelniania poczty e-mail.

    Wiele firm nie publikuje rekordów SPF, ponieważ nie zna wszystkich źródeł wiadomości e-mail dla wiadomości w swojej domenie.

    1. Rozpocznij od opublikowania rekordu SPF zawierającego wszystkie znane źródła poczty e-mail (zwłaszcza w przypadku lokalizacji ruchu firmowego) i użyj wartości reguły wymuszania "błąd miękki" (~all). Przykład:

      fabrikam.com IN TXT "v=spf1 include:spf.fabrikam.com ~all"

      Jeśli utworzysz ten rekord SPF, platforma Microsoft 365 traktuje przychodzącą pocztę e-mail z infrastruktury firmowej jako uwierzytelnioną, ale wiadomości e-mail z niezidentyfikowanych źródeł mogą nadal być oznaczone jako fałszywe, jeśli nie powiedzie się uwierzytelnianie złożone. Jednak to zachowanie jest nadal ulepszeniem od wszystkich wiadomości e-mail od nadawców w domenie oznaczonej jako fałszowanie przez platformę Microsoft 365. Zazwyczaj docelowy system poczty e-mail akceptuje komunikaty od nadawców w domenie z niezidentyfikowanych źródeł, gdy SPF jest skonfigurowany z regułą wymuszania nietrwałego błędu.

    2. Odnajdywanie i dołączanie większej liczby źródeł wiadomości e-mail. Przykład:

      • Lokalne serwery poczty e-mail.
      • Email wysyłane od dostawcy oprogramowania jako usługi (SaaS).
      • Email wysyłane z usługi hostingu w chmurze (Microsoft Azure, GoDaddy, Rackspace, Amazon Web Services itp.).

      Po zidentyfikowaniu wszystkich źródeł wiadomości e-mail dla domeny możesz zaktualizować rekord SPF, aby użyć wartości reguły wymuszania "hard fail" (-all).

    3. Skonfiguruj infrastrukturę DKIM do cyfrowego podpisywania komunikatów.

    4. Skonfiguruj usługę DMARC, aby sprawdzić, czy domeny w adresach MAIL FROM i From są zgodne, aby określić, co zrobić z komunikatami, które nie sprawdzają DMARC (odrzucają lub poddają kwarantannie) oraz identyfikować usługi raportowania w celu monitorowania wyników DMARC.

    5. Jeśli używasz nadawców zbiorczych do wysyłania wiadomości e-mail w Twoim imieniu, sprawdź, czy domena w adresie Od jest zgodna z domeną, która przekazuje protokół SPF lub DMARC.

  • Hostujesz adres e-mail domeny lub udostępniasz infrastrukturę hostingu, która może wysyłać wiadomości e-mail:

    • Upewnij się, że klienci mają dokumentację wyjaśniającą, jak skonfigurować SPF dla swoich domen.
    • Rozważ podpisanie przez DKIM poczty wychodzącej DKIM, nawet jeśli klient nie jawnie skonfigurował modułu DKIM w swojej domenie (zaloguj się przy użyciu domeny domyślnej). Możesz nawet dwukrotnie podpisać wiadomość e-mail przy użyciu podpisów DKIM (z domeną firmową i domeną klienta, jeśli/kiedy jest dostępna).

    Dostarczanie do firmy Microsoft nie jest gwarantowane, nawet jeśli uwierzytelniasz wiadomość e-mail pochodzącą z platformy. Jednak uwierzytelnianie poczty e-mail gwarantuje, że firma Microsoft nie wysyła automatycznie wiadomości e-mail ze swoich domen klientów tylko dlatego, że nie jest uwierzytelniona.