Microsoft 365'te Email kimlik doğrulaması

İpucu

Office 365 Plan 2 için Microsoft Defender XDR'daki özellikleri ücretsiz olarak deneyebileceğinizi biliyor muydunuz? Microsoft Defender portalı deneme hub'ında 90 günlük Office 365 için Defender deneme sürümünü kullanın. Kimlerin kaydolabileceğini ve deneme koşullarını buradan. öğrenin.

Exchange Online posta kutuları olan bir Microsoft 365 kuruluşu veya Exchange Online posta kutuları olmayan tek başına bir Exchange Online Protection (EOP) kuruluşu olarak, etki alanlarınızdaki gönderenlerden gelen e-posta iletilerinin bütünlüğünü korumak önemlidir. Alıcılar, etki alanınızdaki gönderenlerden gelen iletilerin gerçekten etki alanınızdaki gönderenlerden geldiğinden emin olmalıdır.

Email kimlik doğrulaması (e-posta doğrulaması olarak da bilinir), sahte gönderenlerden gelen e-posta iletilerinin teslimini tanımlamaya ve önlemeye yönelik bir grup standarttır (sahtekarlık olarak da bilinir). Sahte gönderenler genellikle iş e-posta güvenliğinin aşılması (BEC), kimlik avı ve diğer e-posta saldırılarında kullanılır. Bu standartlar şunlardır:

  • Sender Policy Framework (SPF):Etki alanı için posta gönderme yetkisi olan kaynak e-posta sunucularını belirtir.
  • DomainKeys Identified Mail (DKIM): İletinin aktarım sırasında değiştirilmediğinden emin olmak için iletinin önemli öğelerini dijital olarak imzalamak için bir etki alanı kullanır.
  • Etki Alanı Tabanlı İleti Kimlik Doğrulaması, Raporlama ve Uyumluluk (DMARC):SPF veya DKIM tarafından etki alanındaki gönderenleri denetleyemeyen iletiler için eylemi belirtir ve DMARC sonuçlarının (raporlama) nereye gönderileceği belirtir.
  • Kimliği Doğrulanmış Alınan Zincir (ARC):Aktarımdaki iletileri değiştiren bilinen hizmetler tarafından özgün e-posta kimlik doğrulama bilgilerini korur. Hedef e-posta sunucusu, DMARC'nin başarısız olacağı iletilerin kimliğini doğrulamak için bu bilgileri kullanabilir.

Bu standartların kimlik sahtekarlığı ve kimlik avı saldırılarına karşı mümkün olan en iyi e-posta korumasını sağlamak için birlikte çalışanbirbirine bağımlı yapı taşları olduğunu fark etmek önemlidir. Tüm e-posta kimlik doğrulama yöntemlerinden daha azı standart dışı korumayla sonuç olur.

Exchange Online posta kutusu olmayan Exchange Online veya tek başına Exchange Online Protection (EOP) kuruluşlarında posta kutuları olan Microsoft 365 kuruluşlarından gönderilen postalar için e-posta kimlik doğrulamasını yapılandırmak için aşağıdaki makalelere bakın:

Microsoft 365 kuruluşunuza gönderilen gelen postaları değiştiren hizmetlerden kaynaklanan e-posta kimlik doğrulaması hatalarını önlemek için bkz. Güvenilen ARC mühürleyicilerini yapılandırma.

Bu makalenin geri kalanında şunlar açıklanmaktadır:

İnternet e-postası neden kimlik doğrulamasına ihtiyaç duyar?

Tasarım gereği, internet üzerindeki Basit Posta Aktarım Protokolü (SMTP) e-postası, ileti gönderenin iddia ettiği kişi olduğunu doğrulamaya çalışmaz.

Standart smtp e-posta iletisi, ileti zarfı ve ileti içeriğinden oluşur:

  • İleti zarfı, iletiyi SMTP sunucuları arasında iletme ve alma bilgilerini içerir. İleti zarfı RFC 5321'de açıklanmıştır. İleti iletimi işlemi sırasında oluşturulduğundan alıcılar ileti zarfını hiçbir zaman görmez.
  • İleti içeriği, ileti üst bilgisi alanlarını (topluca ileti üst bilgisi olarak adlandırılır) ve ileti gövdesini içerir. İleti üst bilgisi RFC 5322'de açıklanmıştır.

Bu tasarım nedeniyle, bir iletinin birden çok gönderen değeri vardır:

  • MAIL FROM adresi (adres, P1 gönderen veya zarf gönderen olarak 5321.MailFrom da bilinir) SMTP e-posta sunucuları arasında iletiminde kullanılan e-posta adresidir. Bu adres genellikle ileti üst bilgisindeki Dönüş Yolu üst bilgisi alanına kaydedilir (ancak kaynak e-posta sunucusu farklı bir Dönüş Yolu e-posta adresi belirleyebilir). Bu e-posta adresi, teslim edilemez raporlarda (NDR'ler veya geri dönen iletiler olarak da bilinir) kullanılır.
  • Kimden adresi (adres veya P2 göndereni olarak 5322.From da bilinir) Kimden üst bilgisi alanındaki e-posta adresidir ve gönderenin e-posta istemcilerinde gösterilen e-posta adresidir.

Aşağıdaki örnekte, iki SMTP e-posta sunucusu arasında geçerli bir ileti iletiminin basitleştirilmiş dökümü gösterilmektedir:

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

Bu örnekte:

  • Kaynak e-posta sunucusu, HELO komutunda tailspintoys.com hedef e-posta sunucusuna woodgrovebank.com olarak kendini tanımlar.
  • İleti alıcısı şeklindedir astobes@tailspintoys.com.
  • İleti zarfı içindeki MAIL FROM adresi (iletiyi SMTP e-posta sunucuları arasında iletmek için kullanılır) şeklindedir dubious@proseware.com.
  • Alıcının e-posta istemcisinde gösterilen Kimden adresi şeklindedir security@woodgrovebank.com.

Bu ileti SMTP'ye göre geçerli olsa da, MAIL FROM adresinin (proseware.com) etki alanı Kimden adresindeki (woodgrovebank.com) etki alanıyla eşleşmiyor. Bu ileti, kimlik avı saldırısında kullanmak üzere iletinin gerçek kaynağını maskeleyerek alıcıyı aldatma olasılığının yüksek olduğu klasik bir kimlik sahtekarlığı örneğidir.

Açıkçası SMTP e-postası, ileti gönderenlerin iddia ettikleri kişi olduğunu doğrulamak için yardıma ihtiyaç duyar!

E-posta iletisi gönderenlerin kimliğini doğrulamak için SPF, DKIM ve DMARC birlikte nasıl çalışır?

Bu bölümde, internet üzerindeki etki alanları için neden SPF, DKIM ve DMARC'ye ihtiyacınız olduğu açıklanmaktadır.

  • SPF: Microsoft 365 etki alanınız için geçerli e-posta kaynaklarını belirlemek üzere SPF'yi ayarlama bölümünde açıklandığı gibi SPF, MAIL FROM etki alanından geçerli posta kaynaklarını belirlemek için DNS'de bir TXT kaydı kullanır ve hedef e-posta sunucusu tanımlanmamış bir kaynaktan posta alırsa ne yapmalıdır ('sabit başarısız' iletiyi reddetmek için; 'soft fail' to accept and mark the message).

    SPF sorunları:

    • SPF yalnızca MAIL FROM etki alanındaki gönderenlerin kaynaklarını doğrular. SPF, Kimden adresi'ndeki etki alanını veya MAIL FROM ile Kimden etki alanları arasındaki hizalamayı dikkate almaz:

      • Saldırgan aşağıdaki adımları izleyerek SPF kimlik doğrulamasını (hatalı negatif) geçiren e-posta gönderebilir:
        • Bir etki alanı kaydedin (örneğin, proseware.com) ve etki alanı için SPF'yi yapılandırın.
        • Kayıtlı etki alanı için geçerli bir kaynaktan, farklı bir etki alanındaki Kimden e-posta adresleriyle (örneğin, woodgrovebank.com) e-posta gönderin.
      • Diğer etki alanları adına posta gönderen geçerli bir e-posta hizmeti, MAIL FROM adresini denetleyebilir. Diğer etki alanları ve MAIL FROM etki alanı eşleşmiyor, bu nedenle iletiler SPF kimlik doğrulamasını (hatalı pozitif) geçiremiyor.

    • İletiler, iletileri yeniden yönlendiren veya aktaran sunucu tabanlı e-posta iletme ile karşılaştıktan sonra SPF sonları .

      • Sunucu tabanlı e-posta iletme, ileti kaynağını özgün sunucudan iletme sunucusuna değiştirir.
      • İletme sunucusu özgün MAIL FROM etki alanından posta gönderme yetkisine sahip olmadığından, ileti SPF kimlik doğrulamasını (hatalı pozitif) geçiremez.

    • Her etki alanı ve tüm alt etki alanları kendi spf kayıtlarını gerektirir. Alt etki alanları üst etki alanının SPF kaydını devralmaz. Tanımlanan ve kullanılan alt etki alanları için e-postaya izin vermek, ancak e-postanın tanımlanmamış ve kullanılmayan alt etki alanları olmasını engellemek istiyorsanız bu davranış sorunlu hale gelir.

  • DKIM: DKIM'i Microsoft 365 etki alanınızdan posta imzalamak için ayarlama bölümünde açıklandığı gibi DKIM, iletinin önemli öğelerini (Kimden adresi dahil) dijital olarak imzalamak için bir etki alanı kullanır ve imzayı ileti üst bilgisinde depolar. Hedef sunucu, iletinin imzalı öğelerinin değiştirilmediğini doğrular.

    DKIM SPF'ye nasıl yardımcı olur: DKIM, SPF'de başarısız olan iletileri doğrulayabilir. Örneğin:

    • Diğer etki alanlarından gelen postalar için aynı MAIL FROM adresinin kullanıldığı bir e-posta barındırma hizmetinden gelen iletiler.
    • Sunucu tabanlı e-posta iletme ile karşılaşan iletiler.

    İleti üst bilgisindeki DKIM imzası bu senaryolarda etkilenmediğinden veya değiştirilmediğinden, bu iletiler DKIM'yi geçirebilir.

    DKIM sorunları: DKIM'in bir iletiyi imzalamak için kullandığı etki alanının, e-posta istemcilerinde gösterilen Kimden adresindeki etki alanıyla eşleşmesi gerekmez.

    SPF gibi saldırgan da aşağıdaki adımları izleyerek DKIM kimlik doğrulamasını (hatalı negatif) geçiren e-posta gönderebilir:

    • Bir etki alanı kaydedin (örneğin, proseware.com) ve etki alanı için DKIM'yi yapılandırın.
    • Farklı bir etki alanındaki Kimden e-posta adresleriyle e-posta gönderin (örneğin, woodgrovebank.com).

  • DMARC: DMARC'yi Microsoft 365'teki gönderenler için Kimden adres etki alanını doğrulamak üzere ayarlama bölümünde açıklandığı gibi, DMARC, POSTA KAYNAK ve Kimden adreslerindeki etki alanları arasındaki hizalamayı denetlemek için SPF ve DKIM kullanır. DMARC ayrıca hedef e-posta sisteminin DMARC'de başarısız olan iletilerde gerçekleştirmesi gereken eylemi belirtir ve DMARC sonuçlarının nereye gönderildiğini (hem başarılı hem de başarısız) tanımlar.

    DMARC SPF ve DKIM'e nasıl yardımcı olur: Daha önce açıklandığı gibi SPF, MAIL FROM etki alanı ve Kimden adreslerindeki etki alanıyla eşleşme girişiminde bulunmaz. DKIM, iletiyi imzalayan etki alanının Kimden adresindeki etki alanıyla eşleşip eşleşmediğiyle ilgilenmez.

    DMARC, MAIL FROM ve From adreslerindeki etki alanlarının eşleşip eşleşmediğini doğrulamak için SPF ve DKIM kullanarak bu eksiklikleri giderir.

    DMARC sorunları: Teslim kesmeden önce aktarımdaki iletileri değiştiren geçerli hizmetler SPF, DKIM ve dolayısıyla DMARC denetimleri.

  • ARC: Güvenilir ARC sızdırmazlıklarını yapılandırma bölümünde açıklandığı gibi, aktarımdaki iletileri değiştiren meşru hizmetler değiştirilmiş iletilerin özgün e-posta kimlik doğrulama bilgilerini korumak için ARC'ı kullanabilir.

    ARC DMARC'ye nasıl yardımcı olur: Hedef e-posta sistemi, hizmeti güvenilir bir ARC sealer olarak tanımlayabilir. ARC daha sonra korunan e-posta kimlik doğrulama bilgilerini kullanarak iletiyi doğrulayabilir.

Microsoft 365'e gönderilen posta için gelen e-posta kimlik doğrulaması

Kimlik avı endişeleri ve internetteki e-posta gönderenler tarafından güçlü e-posta kimlik doğrulama ilkelerinin tam olarak benimsenmesinden daha az olması nedeniyle, Microsoft 365 gelen e-postayı denetlemek için örtük e-posta kimlik doğrulaması kullanır. Örtük e-posta kimlik doğrulaması, gelen e-postayı değerlendirmek için diğer kaynaklardan gelen sinyalleri kullanarak normal SPF, DKIM ve DMARC denetimlerini genişletir. Bu kaynaklar şunlardır:

  • Gönderenin itibarı.
  • Gönderen geçmişi.
  • Alıcı geçmişi.
  • Davranış analizi.
  • Diğer gelişmiş teknikler.

Microsoft'un örtük kimlik doğrulaması hakkındaki özgün duyurusunu görmek için bkz. A Sea of Phish Part 2 - Microsoft 365'te Gelişmiş Kimlik Sahtekarlığı Önleme.

Bu diğer sinyalleri kullanarak, geleneksel e-posta kimlik doğrulaması denetimlerinde başarısız olacak iletiler örtük kimlik doğrulamasını geçirebilir ve Microsoft 365'e izin verebilir.

Bileşik kimlik doğrulaması

Microsoft 365'in örtük kimlik doğrulama denetimlerinin sonuçları birleştirilir ve bileşik kimlik doğrulaması adlı tek bir değerde veya compauth kısaca depolanır. Değer, compauth ileti üst bilgilerinde Authentication-Results üst bilgisine damgalanır. Authentication-Results üst bilgisi aşağıdaki söz dizimini kullanır:

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

Bu değerler Kimlik doğrulama sonuçları ileti üst bilgisinde açıklanmıştır.

Yöneticiler ve kullanıcılar, Microsoft 365'in göndereni şüpheli bir sahte gönderen veya meşru olarak nasıl tanımlamış olduğunu öğrenmek için ileti üst bilgilerini inceleyebilir.

İpucu

Bileşik kimlik doğrulama hatasının doğrudan bir iletinin engellenmesiyle sonuçlanmadığını anlamak önemlidir. Sistemimiz, bir iletinin genel şüpheli doğasını ve bileşik kimlik doğrulama sonuçlarını dikkate alan bütünsel bir değerlendirme stratejisi kullanıyor. Bu yöntem, e-posta kimlik doğrulama protokollerine kesinlikle uymayabilecek etki alanlarından gelen yasal e-postaları yanlış engelleme riskini azaltmak için tasarlanmıştır. Bu dengeli yaklaşım, ileti gönderenlerden gelen ve standart e-posta kimlik doğrulaması uygulamalarına uymayan gerçekten kötü amaçlı e-postaları ayırt etmeye yardımcı olur.

Aşağıdaki örnekler yalnızca e-posta kimlik doğrulamasının sonuçlarına compauth (değer ve neden) odaklanır. Diğer Microsoft 365 koruma teknolojileri, e-posta kimlik doğrulamasını sahte olarak geçiren iletileri veya e-posta kimlik doğrulamasında başarısız olan iletileri meşru olarak tanımlayabilir.

  • Senaryo: SPF kaydındaki etki alanı veya DKIM imzası Kimden adresindeki etki alanıyla eşleşmiyor.

  • Sonuç: İleti bileşik kimlik doğrulamasında başarısız olabilir. Bileşik kimlik doğrulama hatasına rağmen, diğer değerlendirmeler şüpheli bir yapıya işaret etmezse iletiye izin verilmeye devam edilebilir:

    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

  • Senaryo: fabrikam.com etki alanının SPF, DKIM veya DMARC kaydı yok.

  • Sonuç: fabrikam.com etki alanındaki gönderenlerden gelen iletiler bileşik kimlik doğrulamasında başarısız olabilir:

    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

  • Senaryo: fabrikam.com etki alanının SPF kaydı vardır ve DKIM kaydı yoktur. MAIL FROM ve From adreslerindeki etki alanları eşleşmektedir.

  • Sonuç: SPF'den geçen etki alanı Kimden adresindeki etki alanıyla eşleştiğinden, ileti bileşik kimlik doğrulamayı geçirebilir:

    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

  • Senaryo: fabrikam.com etki alanının SPF kaydı olmayan bir DKIM kaydı vardır. DKIM'in iletiyi imzalayan etki alanı, Kimden adresindeki etki alanıyla eşleşir.

  • Sonuç: DKIM imzasında bulunan etki alanı Kimden adresindeki etki alanıyla eşleştiğinden ileti bileşik kimlik doğrulamasını geçirebilir:

    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

  • Senaryo: SPF kaydındaki etki alanı veya DKIM imzası Kimden adresindeki etki alanıyla eşleşmiyor.

  • Sonuç: İleti bileşik kimlik doğrulamasında başarısız olabilir:

    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

Microsoft 365'e posta gönderirken e-posta kimlik doğrulaması hatalarını önleme

İpucu

Microsoft 365 müşterileri, sahtekarlık veya kimlik doğrulama hataları olarak tanımlanan gönderenlerden gelen iletilere izin vermek için aşağıdaki yöntemleri kullanabilir:

  • Etki alanlarınız için SPF, DKIM ve DMARC kayıtlarını yapılandırın: Etki alanı kayıt şirketiniz veya DNS barındırma hizmetiniz tarafından sağlanan yapılandırma bilgilerini kullanın. Ayrıca, e-posta kimlik doğrulama kayıtlarının ayarlanmasına yardımcı olmak için ayrılmış üçüncü taraf şirketler de vardır.

    Birçok şirket, etki alanındaki iletilerin tüm e-posta kaynaklarını bilmediğinden SPF kayıtlarını yayımlamaz.

    1. Bildiğiniz tüm e-posta kaynaklarını içeren bir SPF kaydı yayımlayarak başlayın (özellikle kurumsal trafiğinizin bulunduğu yerde) ve "geçici hata" (~all ) zorlama kuralı değerini kullanın. Örneğin:

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

      Bu SPF kaydını oluşturursanız, Microsoft 365 kurumsal altyapınızdan gelen e-postaları kimliği doğrulanmış olarak kabul eder, ancak kimliksiz kaynaklardan gelen e-postalar bileşik kimlik doğrulamasında başarısız olursa kimlik sahtekarı olarak işaretlenebilir. Ancak bu davranış, Microsoft 365 tarafından sahte olarak işaretlenen etki alanındaki gönderenlerden gelen tüm e-postalarda yine de bir geliştirmedir. Genellikle, SPF geçici bir hata zorlama kuralıyla yapılandırıldığında hedef e-posta sistemi, etki alanındaki gönderenlerden gelen iletileri tanımlanamayan kaynaklardan kabul eder.

    2. İletileriniz için daha fazla e-posta kaynağı bulun ve ekleyin. Örneğin:

      • Şirket içi e-posta sunucuları.
      • Email hizmet olarak yazılım (SaaS) sağlayıcısından gönderilir.
      • Email bir bulut barındırma hizmetinden (Microsoft Azure, GoDaddy, Rackspace, Amazon Web Services vb.) gönderilir.

      Etki alanınız için tüm e-posta kaynaklarını tanımladıktan sonra, SPF kaydınızı "sabit başarısız" (-all zorlama kuralı değerini) kullanacak şekilde güncelleştirebilirsiniz.

    3. İletileri dijital olarak imzalamak için DKIM'i ayarlayın.

    4. DMARC'yi, MAIL FROM ve From adreslerindeki etki alanlarının eşleşip eşleşmediğini doğrulamak, DMARC denetimlerinde başarısız olan iletilerle ne yapacağını belirtmek (reddetme veya karantinaya almak) ve DMARC sonuçlarını izlemek üzere raporlama hizmetlerini belirlemek için ayarlayın.

    5. Sizin adınıza e-posta göndermek için toplu gönderenler kullanıyorsanız Kimden adresindeki etki alanının SPF veya DMARC geçen etki alanıyla eşleşip eşleşmediğini doğrulayın.

  • Bir etki alanının e-postasını barındırabilir veya e-posta gönderebilen barındırma altyapısı sağlarsınız:

    • Müşterilerinizin etki alanları için SPF'yi yapılandırmayı açıklayan belgeleri olduğundan emin olun.
    • Müşteri etki alanında DKIM'i açıkça ayarlamasa bile (varsayılan etki alanıyla oturum açın) DKIM giden postasını DKIM ile imzalamayı göz önünde bulundurun. E-postayı DKIM imzalarıyla (şirket etki alanınızla ve varsa/varsa müşterinin etki alanıyla) çift imzalayabilirsiniz.

    Platformunuzdan gelen e-postaların kimliğini doğrulasanız bile Microsoft'a teslim garanti edilemez. Ancak e-posta kimlik doğrulaması, Microsoft'un yalnızca kimliği doğrulanmamış olduğu için müşteri etki alanlarınızdan gelen e-postaları otomatik olarak gereksiz olarak göndermemesini sağlar.