Megosztás a következőn keresztül:

Email hitelesítés a Microsoft 365-ben

Tipp

Tudta, hogy ingyenesen kipróbálhatja az Microsoft Defender XDR funkcióit Office 365 2. csomagban? Használja a 90 napos Office 365-höz készült Defender próbaverziót a Microsoft Defender portal próbaverziós központjában. A Try Office 365-höz készült Microsoft Defender című cikkből megtudhatja, hogy ki regisztrálhat és ki használhatja a próbaverziót.

Microsoft 365-szervezetként, amely postaládákkal rendelkezik Exchange Online, vagy egy különálló, Exchange Online postaládákat nem tartalmazó Exchange Online Védelmi szolgáltatás (EOP) szervezetként fontos a tartományok feladóitól érkező e-mailek integritásának védelme. A címzetteknek biztosnak kell lennie abban, hogy a tartomány feladóitól érkező üzenetek valóban a tartomány feladóitól származnak.

Email hitelesítés (más néven e-mail-ellenőrzés) egy szabványcsoport, amely azonosítja és megakadályozza az e-mailek hamis feladóktól való kézbesítését (más néven hamisítás). A hamisított feladókat gyakran használják az üzleti e-mailek biztonsági sérülésére (BEC), adathalászatra és más e-mail-támadásokra. Ezek a szabványok a következők:

  • Sender Policy Framework (SPF): Meghatározza azokat a forrás levelezőkiszolgálókat, amelyek jogosultak e-mailek küldésére a tartomány számára.
  • DomainKeys Identified Mail (DKIM): Tartomány használatával digitálisan aláírja az üzenet fontos elemeit, hogy az üzenet ne legyen módosítva az átvitel során.
  • Tartományalapú üzenethitelesítés, -jelentéskészítés és -megfelelőség (DMARC): Meghatározza a sikertelen SPF- vagy DKIM-üzenetekre vonatkozó műveletet, és megadja, hogy hová kell küldeni a DMARC-eredményeket (jelentéskészítés).
  • Hitelesített fogadott lánc (ARC):: Megőrzi az eredeti e-mail-hitelesítési adatokat az átvitt üzeneteket módosító ismert szolgáltatások által. A cél levelezőkiszolgáló ezen adatok alapján hitelesítheti azokat az üzeneteket, amelyek egyébként sikertelenek lennének a DMARC-ben.

Fontos tisztában lenniük azzal, hogy ezek a szabványok egymástól függő építőelemek , amelyek együttműködve a lehető legjobb e-mail-védelmet biztosítják a hamisítás és az adathalászat elleni támadások ellen. Az összes e-mail-hitelesítési módszernél kisebbek esetén a védelem nem megfelelő.

Ha e-mail-hitelesítést szeretne konfigurálni a Microsoft 365-szervezetektől küldött e-mailekhez, amelyek postaládái Exchange Online vagy különálló Exchange Online Védelmi szolgáltatás (EOP) szervezetekben Exchange Online postaládák nélkül érkeznek, tekintse meg az alábbi cikkeket:

A Microsoft 365-szervezetnek küldött bejövő leveleket módosító szolgáltatások miatti e-mail-hitelesítési hibák megelőzéséhez tekintse meg a megbízható ARC-lezárók konfigurálását ismertető cikket.

A cikk további részei a következőt ismertetik:

Tipp

A cikk kísérőjeként tekintse meg Office 365-höz készült Microsoft Defender beállítási útmutatónkat, amely áttekinti az ajánlott eljárásokat, és védelmet nyújt az e-mailekkel, hivatkozásokkal és együttműködési fenyegetésekkel szemben. A szolgáltatások közé tartoznak többek között a biztonságos hivatkozások, a biztonságos mellékletek. A környezeten alapuló testreszabott felhasználói élmény érdekében a Microsoft 365 Felügyeleti központ Office 365-höz készült Microsoft Defender automatikus beállítási útmutatóját érheti el.

Miért van szükség az internetes e-mail-címre hitelesítésre?

A Simple Mail Transfer Protocol (SMTP) által az interneten küldött e-mailek kialakítása nem tesz erőfeszítéseket annak ellenőrzésére, hogy az üzenet feladója-e, akinek állítja magát.

A szabványos SMTP-e-mail-üzenetek üzenetborítványból és üzenettartalomból tevődnek létre:

  • Az üzenet borítékja információkat tartalmaz az üzenet SMTP-kiszolgálók közötti továbbításáról és fogadásáról. Az üzenet borítékjának leírása az RFC 5321-ben található. A címzettek soha nem látják az üzenetborítékot, mert az az üzenettovábbítási folyamat során jön létre.
  • Az üzenet tartalma üzenetfejlécmezőket (együttesen az üzenetfejlécet) és az üzenet törzsét tartalmazza. Az üzenet fejlécét az RFC 5322 ismerteti.

A kialakítás miatt egy üzenet több feladói értékkel rendelkezik:

  • A MAIL FROM cím (más néven a cím, a 5321.MailFrom P1 feladó vagy a boríték feladója) az az e-mail-cím, amelyet az üzenet SMTP-levelezőkiszolgálók közötti átviteléhez használnak. Ez a cím általában az üzenetfejléc Visszatérési útvonal fejléc mezőjében van rögzítve (bár a forrás levelezőkiszolgáló más Feladói útvonal e-mail-címet is megadhat). Ez az e-mail-cím nem kézbesítési jelentésekben (más néven sikertelen kézbesítésről szóló jelentésekben vagy visszapattanó üzenetekben) használatos.
  • A Feladó cím (más néven a cím vagy a 5322.From P2 feladó) a Feladó fejlécmezőben szereplő e-mail-cím, és a feladó e-mail-címe, amely az e-mail ügyfelekben látható.

Az alábbi példa egy érvényes üzenetátvitel egyszerűsített átiratát mutatja be két SMTP e-mail-kiszolgáló között:

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: .

Ebben a példában:

  • A forrás levelezőkiszolgáló a HELO parancsban woodgrovebank.com azonosítja magát a cél levelezőkiszolgáló tailspintoys.com.
  • Az üzenet címzettje: astobes@tailspintoys.com.
  • Az üzenet borítékjában lévő MAIL FROM cím (amely az üzenet SMTP-levelezőkiszolgálók közötti továbbítására szolgál) a következő dubious@proseware.com: .
  • A címzett e-mail-ügyfélprogramjában megjelenő Feladó cím a következő security@woodgrovebank.com: .

Bár ez az üzenet az SMTP szerint érvényes, a MAIL FROM cím (proseware.com) tartománya nem egyezik a Feladó cím (woodgrovebank.com) tartományával. Ez az üzenet egy klasszikus példa a hamisításra, ahol a szándék valószínűleg megtéveszti a címzettet azáltal, hogy maszkolja az üzenet valódi forrását, amelyet adathalász támadáshoz használ.

Egyértelmű, hogy az SMTP-e-mailnek segítségre van szüksége annak ellenőrzéséhez, hogy az üzenet feladói azok-e, akiknek állítják magukat!

Az SPF, a DKIM és a DMARC együttműködése az e-mail-feladók hitelesítése érdekében

Ez a szakasz azt ismerteti, hogy miért van szükség az SPF, a DKIM és a DMARC protokollra az interneten található tartományokhoz.

  • SPF: Az SPF beállítása a Microsoft 365-tartomány érvényes e-mail-forrásainak azonosításához című cikk szerint az SPF egy TXT rekordot használ a DNS-ben a MAIL FROM tartomány érvényes levelezési forrásainak azonosításához, és mi a teendő, ha a cél levelezőkiszolgáló nem definiált forrásból fogad leveleket (a "hard fail" nem utasítja el az üzenetet; A "soft fail" nem fogadja el és jelöli meg az üzenetet).

    SPF-problémák:

    • Az SPF csak a MAIL FROM tartományban lévő feladók forrását ellenőrzi. Az SPF nem veszi figyelembe a tartományt a Feladó címében vagy a LEVELEK FELADÓJA és a Feladó tartomány közötti igazításban:

      • A támadó az alábbi lépések végrehajtásával küldhet olyan e-mailt, amely megfelel az SPF-hitelesítésnek (hamis negatív).
        • Regisztráljon egy tartományt (például proseware.com), és konfigurálja az SPF-t a tartományhoz.
        • Küldjön e-mailt a regisztrált tartomány érvényes forrásából, egy másik tartományban lévő Feladó e-mail-címekkel (például woodgrovebank.com).
      • Egy megbízható levelezőszolgáltatás, amely más tartományok nevében küld leveleket, szabályozhatja a MAIL FROM címet. A többi tartomány és a MAIL FROM tartomány nem egyezik, ezért az üzenetek nem tudják átadni az SPF-hitelesítést (hamis pozitív).

    • Az SPF megszakad, miután az üzenetek kiszolgálóalapú e-mail-továbbítással találkoznak, amely átirányítja vagy továbbítja az üzeneteket.

      • A kiszolgálóalapú e-mail-továbbítás az üzenetforrást az eredeti kiszolgálóról a továbbító kiszolgálóra módosítja.
      • A továbbító kiszolgáló nem jogosult e-maileket küldeni az eredeti MAIL FROM tartományból, így az üzenet nem tud SPF-hitelesítést átadni (hamis pozitív).

    • Minden tartományhoz és altartományhoz saját SPF-rekordokra van szükség. Az altartományok nem öröklik a szülőtartomány SPF rekordját. Ez a viselkedés problémássá válik, ha engedélyezni szeretné az e-maileket a definiált és a használt altartományokból, de meg szeretné akadályozni a nem definiált és nem használt altartományok e-mailjeinek használatát.

  • DKIM: A DKIM beállítása a Microsoft 365-tartományból érkező e-mailek aláírásához című témakörben leírtak szerint a DKIM egy tartományt használ az üzenet fontos elemeinek digitális aláírására (beleértve a Feladó címét is), és az aláírást az üzenet fejlécében tárolja. A célkiszolgáló ellenőrzi, hogy az üzenet aláírt elemei nem módosultak-e.

    Hogyan segít a DKIM az SPF-ben? A DKIM képes ellenőrizni a sikertelen SPF-üzeneteket. Például:

    • Olyan e-mail-szolgáltatótól érkező üzenetek, ahol ugyanazt a MAIL FROM címet használják más tartományokból érkező levelekhez.
    • Kiszolgálóalapú e-mail-továbbítást tapasztaló üzenetek.

    Mivel az üzenetfejlécben lévő DKIM-aláírás nincs hatással vagy módosul ezekben a forgatókönyvekben, ezek az üzenetek képesek átadni a DKIM-et.

    DKIM-problémák: A DKIM által az üzenetek aláírásához használt tartománynak nem kell megegyeznie az e-mail-ügyfelekben látható Feladó cím tartományával.

    Az SPF-hez hasonlóan a támadók az alábbi lépések végrehajtásával küldhetnek DKIM-hitelesítést (hamis negatív) át adó e-mailt:

    • Regisztráljon egy tartományt (például proseware.com), és konfigurálja a DKIM-et a tartományhoz.
    • E-mail küldése másik tartományban lévő Feladó e-mail-címmel (például woodgrovebank.com).

  • DMARC: A DMARC beállítása a Feladó címtartomány ellenőrzéséhez a Microsoft 365-ben című témakörben leírtak szerint a DMARC az SPF és a DKIM használatával ellenőrzi a MAIL FROM és a From cím tartományai közötti igazítást. A DMARC azt a műveletet is megadja, amelyet a cél levelezőrendszernek el kell végeznie a sikertelen DMARC-üzeneteken, és azonosítja a DMARC-eredmények küldésének helyét (sikeres és sikertelen is).

    Hogyan segíti a DMARC az SPF-et és a DKIM-et? A korábban leírtak szerint az SPF nem kísérli meg a tartomány egyeztetését a MAIL FROM tartományban és a feladói címekben. A DKIM nem számít, ha az üzenetet aláíró tartomány megegyezik a Feladó cím tartományával.

    A DMARC az SPF és a DKIM használatával oldja meg ezeket a hiányosságokat annak ellenőrzésére, hogy a MAIL FROM és a From cím tartományai egyeznek-e.

    DMARC-problémák: Megbízható szolgáltatások, amelyek módosítják az átvitt üzeneteket a kézbesítési szünet előtt SPF, DKIM, és ezért DMARC-ellenőrzések.

  • ARC: A megbízható ARC-lezárók konfigurálásával foglalkozó szakaszban leírtak szerint az átvitt üzeneteket módosító jogszerű szolgáltatások az ARC használatával megőrizhetik a módosított üzenetek eredeti e-mail-hitelesítési adatait.

    Hogyan segíti az ARC a DMARC-t? A cél levelezőrendszer megbízható ARC-tömítőként azonosíthatja a szolgáltatást. Az ARC ezután felhasználhatja a megőrzött e-mail-hitelesítési adatokat az üzenet ellenőrzéséhez.

Bejövő e-mail-hitelesítés a Microsoft 365-be küldött levelekhez

Az adathalászati problémák és az e-mail-feladók által az interneten érvényes erős e-mail-hitelesítési házirendek teljes körű bevezetése miatt a Microsoft 365 implicit e-mail-hitelesítéssel ellenőrzi a bejövő e-maileket. Az implicit e-mail-hitelesítés kiterjeszti a rendszeres SPF-, DKIM- és DMARC-ellenőrzéseket más forrásokból származó jelek használatával a bejövő e-mailek kiértékelésére. Ezek a források a következők:

  • Feladók hírnevét.
  • Feladói előzmények.
  • Címzettek előzményei.
  • Viselkedéselemzés.
  • Egyéb fejlett technikák.

A Microsoft implicit hitelesítéssel kapcsolatos eredeti bejelentését lásd: A Sea of Phish Part 2 – Enhanced Anti-hamisítás a Microsoft 365-ben.

Ezen egyéb jelek használatával a hagyományos e-mail-hitelesítési ellenőrzéseken egyébként meghiúsuló üzenetek implicit hitelesítést adhatnak át, és engedélyezhetők a Microsoft 365-be.

Összetett hitelesítés

A Microsoft 365 implicit hitelesítési ellenőrzéseinek eredményei egyetlen, összetett hitelesítéscompauth nevű értékben vannak kombinálva és tárolva. Az compauth érték az üzenetfejlécek Authentication-Results fejlécébe lesz bélyegzve. Az Authentication-Results fejléc a következő szintaxist használja:

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

Ezeket az értékeket a Hitelesítési eredmények üzenetfejléc ismerteti.

A rendszergazdák és a felhasználók megvizsgálhatják az üzenetfejléceket annak kiderítéséhez, hogy a Microsoft 365 hogyan azonosította a feladót gyanús vagy hamisított feladóként.

Tipp

Fontos tisztában lenni azzal, hogy az összetett hitelesítési hibák nem eredményeznek közvetlenül letiltott üzenetet. Rendszerünk egy holisztikus kiértékelési stratégiát használ, amely az üzenet általános gyanús jellegét és az összetett hitelesítési eredményeket veszi figyelembe. Ennek a módszernek az a célja, hogy mérsékelje annak kockázatát, hogy helytelenül blokkolja a megbízható e-maileket olyan tartományokból, amelyek esetleg nem feltétlenül tartják be szigorúan az e-mail hitelesítési protokollokat. Ez az kiegyensúlyozott megközelítés segít megkülönböztetni a valóban kártékony e-maileket azoktól az üzenetküldőktől, amelyek egyszerűen nem felelnek meg a szabványos e-mail-hitelesítési eljárásoknak.

Az alábbi példák csak az e-mail-hitelesítés eredményeire (az értékre és az compauth okra) összpontosítanak. A Microsoft 365 egyéb védelmi technológiái hamisításként azonosíthatják az e-mail-hitelesítést átadó üzeneteket, vagy megbízhatóként azonosíthatják az e-mail-hitelesítést sikertelen üzeneteket.

  • Forgatókönyv: Az SPF rekordban vagy a DKIM-aláírásban szereplő tartomány nem egyezik a Feladó cím tartományával.

  • Eredmény: Az üzenet meghiúsulhat az összetett hitelesítés során. Az összetett hitelesítési hiba ellenére az üzenet továbbra is engedélyezhető, ha más értékelések nem jeleznek gyanús természetet:

    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

  • Forgatókönyv: A fabrikam.com tartomány nem rendelkezik SPF, DKIM vagy DMARC rekordokkal.

  • Eredmény: Az fabrikam.com tartományban lévő feladóktól érkező üzenetek összetett hitelesítést hiúsulhatnak meg:

    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

  • Forgatókönyv: A fabrikam.com tartomány SPF rekorddal rendelkezik, és nem rendelkezik DKIM-rekorddal. A MAIL FROM és a From cím tartományai egyeznek.

  • Eredmény: Az üzenet képes összetett hitelesítést átadni, mert az SPF-nek átadott tartomány megegyezik a Feladó cím tartományával:

    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

  • Forgatókönyv: A fabrikam.com tartomány SPF rekord nélküli DKIM-rekorddal rendelkezik. A DKIM által aláírt tartomány megegyezik a Feladó címben szereplő tartománnyal.

  • Eredmény: Az üzenet képes összetett hitelesítést átadni, mert a DKIM-aláírás tartománya megegyezik a Feladó cím tartományával:

    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

  • Forgatókönyv: Az SPF rekordban vagy a DKIM-aláírásban szereplő tartomány nem egyezik a Feladó cím tartományával.

  • Eredmény: Az üzenet meghiúsulhat az összetett hitelesítés sorá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

E-mail-hitelesítési hibák elkerülése a Microsoft 365-nek küldött e-mailek esetén

Tipp

A Microsoft 365 ügyfelei az alábbi módszerekkel engedélyezhetik a hamisításként vagy hitelesítési hibáként azonosított feladóktól érkező üzeneteket:

  • SPF, DKIM és DMARC rekordok konfigurálása a tartományokhoz: Használja a tartományregisztráló vagy a DNS-szolgáltató által megadott konfigurációs adatokat. Vannak külső vállalatok is, amelyek segítenek az e-mail-hitelesítési rekordok beállításában.

    Sok vállalat nem tesz közzé SPF rekordokat, mert nem ismeri a tartományában lévő üzenetek összes e-mail-forrását.

    1. Először tegyen közzé egy SPF rekordot, amely tartalmazza az összes ismert e-mail-forrást (különösen a vállalati forgalom helyét), és használja a kényszerítési szabály "helyreállítható hiba" (~all) értékét. Például:

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

      Ha létrehozza ezt az SPF rekordot, a Microsoft 365 hitelesítettként kezeli a vállalati infrastruktúrából érkező e-maileket, de az azonosítatlan forrásokból érkező e-mailek továbbra is hamisként lesznek megjelölve, ha nem sikerül az összetett hitelesítés. Ez a viselkedés azonban továbbra is javulást jelent a tartomány feladóitól érkező összes e-mailnél, amelyet a Microsoft 365 hamisításként jelölt meg. A cél levelezőrendszer általában akkor fogadja a tartomány feladóitól érkező üzeneteket azonosítatlan forrásokból, ha az SPF helyreállítható feladatkényszerítési szabmánnyal van konfigurálva.

    2. További e-mail-forrásokat fedezhet fel és foglalhat bele az üzenetekbe. Például:

      • Helyszíni e-mail-kiszolgálók.
      • Email szolgáltatott szoftver (SaaS) szolgáltatótól kell elküldeni.
      • Email felhőüzemeltetési szolgáltatásból (Microsoft Azure, GoDaddy, Rackspace, Amazon Web Services stb.) küldve.

      Miután azonosította tartománya összes e-mail-forrását, frissítheti az SPF rekordot a "hard fail" (-allsikertelen) kényszerítési szabály értékének használatára.

    3. Állítsa be a DKIM-et az üzenetek digitális aláírásához.

    4. Állítsa be a DMARC-t annak ellenőrzésére, hogy a MAIL FROM és a From cím tartományai egyeznek-e, megadhatja, hogy mi a teendő a DMARC-ellenőrzéseket nem tartalmazó üzenetekkel (elutasítás vagy karantén), valamint a DMARC-eredmények monitorozására szolgáló jelentéskészítési szolgáltatások azonosítására.

    5. Ha tömeges feladókkal küld e-maileket az Ön nevében, ellenőrizze, hogy a Feladó cím tartománya megegyezik-e az SPF vagy a DMARC protokollt átadó tartománnyal.

  • Egy tartomány e-mail-címét üzemelteti, vagy olyan üzemeltetési infrastruktúrát biztosít, amely képes e-maileket küldeni:

    • Győződjön meg arról, hogy az ügyfelek rendelkeznek olyan dokumentációval, amely leírja, hogyan konfigurálhatja az SPF-t a tartományaikhoz.
    • Fontolja meg a DKIM-aláíró DKIM kimenő leveleit, még akkor is, ha az ügyfél nem állította be explicit módon a DKIM-et a tartományában (alapértelmezett tartománnyal kell aláírnia). Akár DKIM-aláírásokkal is aláírhatja az e-mailt (a vállalati tartományával és az ügyfél tartományával, ha/ha elérhető).

    A Microsoftnak való kézbesítés nem garantált, még akkor sem, ha hitelesíti a platformról származó e-maileket. Az e-mail-hitelesítés azonban biztosítja, hogy a Microsoft ne küldjön automatikusan levélszeméteket az ügyféltartományokból egyszerűen azért, mert nincs hitelesítve.