Email ověřování v Microsoftu 365

Tip

Věděli jste, že si můžete zdarma vyzkoušet funkce v Microsoft Defender XDR pro Office 365 Plan 2? Použijte 90denní zkušební verzi Defender pro Office 365 v centru zkušebních verzí portálu Microsoft Defender Portal. Zde zjistíte více o tom, kdo se může zaregistrovat a o podmínkách zkušební verze.

Jako organizace Microsoft 365 s poštovními schránkami v Exchange Online nebo samostatná organizace Exchange Online Protection (EOP) bez Exchange Online poštovních schránek je důležitá ochrana integrity e-mailových zpráv od odesílatelů ve vašich doménách. Příjemci by si měli být jistí, že zprávy od odesílatelů ve vaší doméně ve skutečnosti pocházejí od odesílatelů ve vaší doméně.

Email ověřování (označované také jako ověřování e-mailů) je skupina standardů pro identifikaci a zabránění doručování e-mailových zpráv od zfalšovaných odesílatelů (označovaných také jako falšování identity). Zfalšovaní odesílatelé se běžně používají při obchodních e-mailových útocích (BEC), phishingu a dalších e-mailových útocích. Mezi tyto standardy patří:

  • Sender Policy Framework (SPF): Určuje zdrojové e-mailové servery, které mají oprávnění odesílat poštu pro doménu.
  • DKIM (DomainKeys Identifikovaná pošta): Používá doménu k digitálnímu podepsání důležitých prvků zprávy, aby se zajistilo, že zpráva nebyla během přenosu změněna.
  • DMARC (Domain-Based Message Authentication, Reporting and Conformance): Určuje akci pro zprávy, které selžou SPF nebo DKIM, kontroluje odesílatele v doméně a určuje, kam se mají odesílat výsledky DMARC (sestavy).
  • Protokol ARC (Authenticated Received Chain): Zachovává původní ověřovací informace e-mailu známými službami, které upravují přenášené zprávy. Cílový e-mailový server může tyto informace použít k ověřování zpráv, které by jinak selhaly v DMARC.

Je důležité si uvědomit, že tyto standardy jsou vzájemně závislé stavební bloky , které společně poskytují nejlepší možnou e-mailovou ochranu před falšováním identity a útoky phishing. Cokoli menšího než všechny metody ověřování e-mailů vede k nestandardní ochraně.

Pokud chcete nakonfigurovat ověřování e-mailů odesílaných z organizací Microsoft 365 s poštovními schránkami v Exchange Online nebo samostatných organizacích Exchange Online Protection (EOP) bez Exchange Online poštovních schránek, přečtěte si následující články:

Pokud chcete zabránit selháním ověřování e-mailů způsobených službami, které upravují příchozí poštu odeslanou vaší organizaci Microsoft 365, přečtěte si téma Konfigurace důvěryhodných zapečetění ARC.

Zbývající část tohoto článku vysvětluje:

Proč internetový e-mail potřebuje ověřování

E-maily protokolu SMTP (Simple Mail Transfer Protocol) se záměrně nesnaží ověřit, že odesílatel zprávy je tím, za koho se vydává.

Standardní e-mailová zpráva SMTP se skládá z obálky zprávy a obsahu zprávy:

  • Obálka zprávy obsahuje informace pro přenos a příjem zprávy mezi servery SMTP. Obálka zprávy je popsána v DOKUMENTU RFC 5321. Příjemci obálku zprávy nikdy neuvidí, protože se generuje během procesu přenosu zprávy.
  • Obsah zprávy obsahuje pole záhlaví zprávy (souhrnně označované jako záhlaví zprávy) a text zprávy. Záhlaví zprávy je popsáno v dokumentu RFC 5322.

Kvůli tomuto návrhu má zpráva více hodnot odesílatele:

  • Adresa MAIL FROM (označovaná také jako 5321.MailFrom adresa, odesílatel P1 nebo odesílatel obálky) je e-mailová adresa, která se používá při přenosu zprávy mezi e-mailovými servery SMTP. Tato adresa je obvykle zaznamenána v poli Hlavička Return-Path v záhlaví zprávy (i když zdrojový e-mailový server může určit jinou e-mailovou adresu Return-Path ). Tato e-mailová adresa se používá v oznámeních o nedoručení (označovaných také jako oznámení o nedoručení nebo nedoručitelnosti).
  • Adresa odesílatele (označovaná také jako 5322.From adresa nebo odesílatel P2) je e-mailová adresa v záhlaví Od a je e-mailová adresa odesílatele, která se zobrazuje v e-mailových klientech.

Následující příklad ukazuje zjednodušený přepis platného přenosu zpráv mezi dvěma e-mailovými servery 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: .

V tomto příkladu:

  • Zdrojový e-mailový server se v příkazu HELO identifikuje jako woodgrovebank.com k cílovému e-mailovému serveru tailspintoys.com.
  • Příjemcem zprávy je astobes@tailspintoys.com.
  • Adresa MAIL FROM v obálce zprávy (používá se k přenosu zprávy mezi e-mailovými servery SMTP) je dubious@proseware.com.
  • Adresa odesílatele zobrazená v e-mailovém klientovi příjemce je security@woodgrovebank.com.

I když je tato zpráva platná podle protokolu SMTP, doména adresy MAIL FROM (proseware.com) neodpovídá doméně v adrese Odesílatele (woodgrovebank.com). Tato zpráva je klasickým příkladem falšování identity, kdy záměr pravděpodobně oklame příjemce maskováním skutečného zdroje zprávy, který se má použít při útoku phishing.

Je zřejmé, že e-mail SMTP potřebuje pomoc s ověřením, že odesílatelé zpráv jsou tím, za koho se vydávají.

Jak SPF, DKIM a DMARC spolupracují při ověřování odesílatelů e-mailových zpráv

Tato část popisuje, proč potřebujete SPF, DKIM a DMARC pro domény na internetu.

  • SPF: Jak je vysvětleno v tématu Nastavení SPF k identifikaci platných e-mailových zdrojů pro vaši doménu Microsoft 365, SPF používá záznam TXT v DNS k identifikaci platných zdrojů pošty z domény MAIL FROM a co dělat, když cílový e-mailový server obdrží poštu z nedefinovaného zdroje ('těžké' selhání' zprávu odmítnout; "soft fail" přijmout a označit zprávu).

    Problémy se SPF:

    • SPF ověřuje zdroje pouze pro odesílatele v doméně MAIL FROM. SPF nebere v úvahu doménu v adrese Odesílatele nebo zarovnání mezi doménami MAIL FROM a From:

      • Útočník může odeslat e-mail, který projde ověřováním SPF (falešně negativní), pomocí následujícího postupu:
        • Zaregistrujte doménu (například proseware.com) a nakonfigurujte pro doménu SPF.
        • Odešlete e-mail z platného zdroje pro registrovanou doménu s e-mailovou adresou Od v jiné doméně (například woodgrovebank.com).
      • Legitimní e-mailová služba, která odesílá poštu jménem jiných domén, může řídit adresu MAIL FROM. Ostatní domény a doména MAIL FROM se neshodují, takže zprávy nemůžou projít ověřováním SPF (falešně pozitivní).

    • SPF se přeruší, když zprávy narazí na serverové přeposílání e-mailů, které přesměrovává nebo předává zprávy.

      • Předávání e-mailů na základě serveru změní zdroj zpráv z původního serveru na server pro předávání.
      • Server pro přeposílání nemá oprávnění k odesílání pošty z původní domény MAIL FROM, takže zpráva nemůže projít ověřováním SPF (falešně pozitivní).

    • Každá doména a všechny subdomény vyžadují své vlastní záznamy SPF. Subdomény nedědí záznam SPF nadřazené domény. Toto chování se stává problematickým, pokud chcete povolit e-maily z definovaných a použitých subdomén, ale zabránit e-mailům z nedefinovaných a nepoužívaných subdomén.

  • DKIM: Jak je vysvětleno v tématu Nastavení DKIM pro podepisování pošty z domény Microsoft 365, DKIM používá doménu k digitálnímu podepisování důležitých prvků zprávy (včetně adresy Odesílatele) a ukládá podpis do záhlaví zprávy. Cílový server ověří, že podepsané prvky zprávy nebyly změněny.

    Jak DKIM pomáhá SPF: DKIM může ověřovat zprávy, které SPF selžou. Příklady:

    • Zprávy ze služby pro hostování e-mailu, kde se stejná adresa MAIL FROM používá pro poštu z jiných domén.
    • Zprávy, u které dochází k přeposílání e-mailů na serveru

    Vzhledem k tomu, že podpis DKIM v záhlaví zprávy není v těchto scénářích ovlivněn ani změněn, mohou tyto zprávy předat DKIM.

    Problémy s DKIM: Doména, kterou DKIM používá k podepsání zprávy, se nemusí shodovat s doménou v adrese Odesílatele, která se zobrazuje v e-mailových klientech.

    Podobně jako SPF může útočník odeslat e-mail, který projde ověřováním DKIM (falešně negativní), pomocí následujícího postupu:

    • Zaregistrujte doménu (například proseware.com) a nakonfigurujte pro doménu DKIM.
    • Odešlete e-mail s e-mailovou adresou Od v jiné doméně (například woodgrovebank.com).

  • DMARC: Jak je vysvětleno v tématu Nastavení DMARC pro ověření domény adresy Odesílatele pro odesílatele v Microsoftu 365, DMARC používá SPF a DKIM ke kontrole zarovnání mezi doménami v adresách MAIL FROM a From. DMARC také určuje akci, kterou by měl cílový e-mailový systém provést se zprávami, které selžou, a určuje, kam se mají odesílat výsledky DMARC (úspěšné i neúspěšné).

    Jak DMARC pomáhá SPF a DKIM: Jak bylo popsáno dříve, SPF se nepokouší spárovat doménu v doméně MAIL FROM a Adresách od. DKIM se nezajímá, jestli doména, která zprávu podepsala, odpovídá doméně v adrese Od.

    DMARC tyto nedostatky řeší tak, že pomocí SPF a DKIM potvrdí, že se domény v adresách MAIL FROM a From shodují.

    Problémy s DMARC: Legitimní služby, které upravují zprávy během přenosu před doručením, přerušují kontroly SPF, DKIM a tedy DMARC.

  • ARC: Jak je vysvětleno v tématu Konfigurace důvěryhodných zapečetění ARC, legitimní služby, které upravují přenášené zprávy, můžou službu ARC používat k zachování původních ověřovacích informací e-mailu upravených zpráv.

    Jak ARC pomáhá DMARC: Cílový e-mailový systém dokáže službu identifikovat jako důvěryhodný zapečetěč ARC. Arc pak může k ověření zprávy použít zachované ověřovací informace e-mailu.

Ověřování příchozích e-mailů pro poštu odeslanou do Microsoftu 365

Kvůli útokům phishing a méně než úplnému přijetí zásad silného ověřování e-mailů odesílateli e-mailů na internetu používá Microsoft 365 ke kontrole příchozích e-mailů implicitní ověřování e-mailů . Implicitní ověřování e-mailů rozšiřuje pravidelné kontroly SPF, DKIM a DMARC pomocí signálů z jiných zdrojů k vyhodnocení příchozích e-mailů. Mezi tyto zdroje patří:

  • Reputace odesílatele.
  • Historie odesílatele.
  • Historie příjemců.
  • Behaviorální analýza.
  • Další pokročilé techniky.

Pokud se chcete podívat na původní oznámení Microsoftu o implicitní ověřování, přečtěte si téma Moře phish, část 2 – Rozšířená ochrana proti falšování identity v Microsoftu 365.

Při použití těchto dalších signálů můžou zprávy, které by jinak selhaly v tradičních kontrolách ověřování e-mailů, projít implicitním ověřováním a povolit je do Microsoftu 365.

Složené ověřování

Výsledky implicitních kontrol ověřování Microsoftu 365 se zkombinují a ukládají do jedné hodnoty s názvem složené ověřování nebo compauth zkráceně. Hodnota compauth se v záhlaví zprávy orazítkuje do hlavičky Authentication-Results . Hlavička Authentication-Results používá následující syntaxi:

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

Tyto hodnoty jsou vysvětleny v hlavičce zprávy s výsledky ověřování.

Správci a uživatelé můžou prozkoumat záhlaví zpráv a zjistit, jak Microsoft 365 identifikoval odesílatele jako podezřelého zfalšovaného nebo legitimního odesílatele.

Tip

Je důležité si uvědomit, že při selhání složeného ověřování nedojde přímo k zablokování zprávy. Náš systém používá holistickou strategii hodnocení, která bere v úvahu celkovou podezřelou povahu zprávy spolu s výsledky složeného ověřování. Tato metoda je navržená tak, aby zmírnila riziko nesprávného blokování legitimních e-mailů z domén, které nemusí striktně dodržovat protokoly pro ověřování e-mailů. Tento vyvážený přístup pomáhá odlišit skutečně škodlivé e-maily od odesílatelů zpráv, kteří jednoduše nevyhovují standardním postupům ověřování e-mailů.

Následující příklady se zaměřují pouze na výsledky ověřování e-mailů ( compauth hodnotu a důvod). Jiné technologie ochrany Microsoft 365 můžou identifikovat zprávy, které procházejí ověřováním e-mailu, jako zfalšované, nebo identifikovat zprávy, u kterých se nepovede ověření e-mailu, jako legitimní.

  • Scénář: Doména v záznamu SPF nebo podpisu DKIM neodpovídá doméně v adrese Od.

  • Výsledek: Zpráva může selhat složeného ověřování. I přes selhání složeného ověřování může být zpráva stále povolená, pokud jiná hodnocení nenaznačují podezřelou povahu:

    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

  • Scénář: Doména fabrikam.com nemá žádné záznamy SPF, DKIM ani DMARC.

  • Výsledek: Zprávy od odesílatelů v doméně fabrikam.com můžou selhat při složené ověřování:

    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

  • Scénář: Doména fabrikam.com obsahuje záznam SPF a žádný záznam DKIM. Domény v adresách MAIL FROM a From se shodují.

  • Výsledek: Zpráva může projít složené ověřování, protože doména, která předala SPF, odpovídá doméně v adrese Od:

    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

  • Scénář: Doména fabrikam.com obsahuje záznam DKIM bez záznamu SPF. Doména, kterou DKIM podepsal zprávu, odpovídá doméně v adrese Od.

  • Výsledek: Zpráva může projít složené ověřování, protože doména v podpisu DKIM odpovídá doméně v adrese 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

  • Scénář: Doména v záznamu SPF nebo podpisu DKIM neodpovídá doméně v adrese Od.

  • Výsledek: Zpráva může selhat ve složené ověřování:

    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 se vyhnout selhání ověřování e-mailů při odesílání pošty do Microsoftu 365

Tip

Zákazníci Microsoft 365 můžou pomocí následujících metod povolit zprávy od odesílatelů, kteří jsou identifikováni jako falšování identity nebo selhání ověřování:

  • Konfigurace záznamů SPF, DKIM a DMARC pro vaše domény: Použijte informace o konfiguraci, které poskytuje váš doménový registrátor nebo hostitelská služba DNS. Existují také společnosti třetích stran, které pomáhají s nastavením záznamů o ověřování e-mailů.

    Mnoho společností nepublikuje záznamy SPF, protože neznají všechny zdroje e-mailu pro zprávy ve své doméně.

    1. Začněte publikováním záznamu SPF, který obsahuje všechny e-mailové zdroje, o kterých víte (zejména tam, kde se nachází podnikový provoz), a použijte hodnotu pravidla vynucení "soft fail" (~all). Příklady:

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

      Pokud vytvoříte tento záznam SPF, Bude Microsoft 365 považovat příchozí e-maily z podnikové infrastruktury za ověřené, ale e-maily z neidentifikovaných zdrojů můžou být i nadále označené jako falšování, pokud se nezdaří složené ověřování. Toto chování je ale stále ještě lepší než všechny e-maily od odesílatelů v doméně, které Microsoft 365 označí jako falšované. Cílový e-mailový systém obvykle přijímá zprávy od odesílatelů v doméně z neidentifikovaných zdrojů, když je SPF nakonfigurované pomocí pravidla vynucení měkkého selhání.

    2. Objevte a zahrňte do svých zpráv další e-mailové zdroje. Příklady:

      • Místní e-mailové servery.
      • Email odesílaný od poskytovatele softwaru jako služby (SaaS).
      • Email odesílána ze služby hostování cloudu (Microsoft Azure, GoDaddy, Rackspace, Amazon Web Services atd.).

      Po identifikaci všech zdrojů e-mailu pro vaši doménu můžete aktualizovat záznam SPF tak, aby používal hodnotu pravidla vynucení "hard fail" (-all).

    3. Nastavte DKIM pro digitální podepisování zpráv.

    4. Nastavte DMARC, abyste ověřili, že se domény v adresách MAIL FROM a From shodují, abyste mohli určit, co dělat se zprávami, které neprošly kontrolami DMARC (odmítnutí nebo karanténa), a identifikovat služby generování sestav pro monitorování výsledků DMARC.

    5. Pokud k odesílání e-mailů vaším jménem používáte hromadné odesílatele, ověřte, že doména v adrese Odesílatele odpovídá doméně, která předává SPF nebo DMARC.

  • Hostujete e-mail domény nebo poskytujete hostingovou infrastrukturu, která může posílat e-maily:

    • Ujistěte se, že vaši zákazníci mají dokumentaci, která vysvětluje, jak nakonfigurovat SPF pro jejich domény.
    • Zvažte možnost podepisování odchozí pošty DKIM DKIM, a to i v případě, že zákazník ve své doméně explicitně nenastaví DKIM (podepíše se s výchozí doménou). E-mail můžete dokonce podepisovat podpisy DKIM (doménou vaší společnosti a doménou zákazníka, pokud je k dispozici).

    Doručení do Microsoftu není zaručené, a to ani v případě, že ověřujete e-maily pocházející z vaší platformy. Ověřování e-mailu ale zajišťuje, že Microsoft automaticky neposílá e-maily z domén vašich zákazníků jednoduše proto, že nejsou ověřené.