[ Kurumsal operasyonlar ]

Edinilen etki alanlarını standartlaştırmadan önce devralınan gönderen envanterini değerlendirin

Kimlik doğrulama yetkilerini değiştirmeden önce, devralınan gönderenleri gerçek hizmetlere ve sorumlu sahiplere atayın.

EmailAuth araştırma ekibi tarafından · 3 dakikalık okuma

[ Anahtar noktalar ]

  • Kimlik doğrulama yetkilerini değiştirmeden önce, devralınan gönderenleri gerçek hizmetlere ve sorumlu sahiplere atayın.
  • İş onayı, teknik atıf ve gözlemlenen operasyon bağımsız durumlardır; hiçbiri diğerinin yerini tutamaz.
Bu sayfada

Devralınan gönderen envanteri, bir IP adresleri listesi değil, bir karar aracıdır. Edinilen etki alanlarını standartlaştırmadan önce, gözlemlenen postayı onu üreten müşteriye özel hizmete, işletme sahibine ve onaylanmış kimliklerine bağlayın. Tanıdık bir sağlayıcı hem yasal hem de istenmeyen trafiği barındırabilir; dolayısıyla altyapı tanıma tek başına onay anlamına gelmez.

Birden fazla kanıt kaynağıyla başlayın

Yetkili yapılandırma aktarımlarını, uygulama kayıtlarını, satıcı hesap kayıtlarını, DNS gözlemlerini ve mevcut posta kanıtlarını toplayın. Her gözlemin nereden geldiğini ve ne zaman toplandığını koruyun. Raporları birleştir kaynak IP'lerini ve kimlik doğrulama modellerini açığa çıkarabilir ancak kuruluşun iş amacını veya gönderen popülasyonunun tamamını bağımsız olarak belirleyemez. RFC 9990.

Her hizmet için, kayıt amacı, sorumlu sahip, sağlayıcı hesabı veya kiracı, kritiklik, görünür Etki alanından, zarf etki alanından, DKIM imza kimliği, son temsilci testi ve onay kanıtı. Bilinmeyen alanları açık tutun. Hareketsiz veya savunmada olabilecek alan adları için gönderme ve alma amaçlarını ayrı ayrı kaydedin.

Yetki eklemeden önce kimlikleri ilişkilendirin

Gözlemlenen tanımlayıcıları gerçek satıcı yapılandırması ve iş akışıyla karşılaştırın. DMARC kullanır hizalama yazar alanı ile kimliği doğrulanmış başarılı bir tanımlayıcı arasında; tanımlayıcıların olmadığı genel bir geçiş sonucu, çözmeniz gereken sorunu gizleyebilir. RFC 9989.

Bilinmeyen bir kaynağı eklemeyin SPF çünkü postalar oradan geliyor gibi görünüyor. SPF değerlendirilen kimlik için ana bilgisayarlara yetki verir ve değerlendirmesi, DNS arama sınırlarını içerir. RFC 7208 , bölüm 4.6.4. Yeni bir ekleme yetkiyi genişletebilir, operasyonel sınırları aşabilir veya uyumu düzeltmede başarısız olabilir. Önce amaçlanan hizmeti ve uygun kimlik doğrulamalı rotayı oluşturun.

Onay ve testi ayrı tutun

Onaylanmış bir hizmet yine de geçiş testinde başarısız olabilir; kimliği doğrulanmış bir mesaj yine de onaylanmamış bir hizmetten gelebilir. Her iki durumu da saklayın. Onay kanıtı sorumlu kararı tanımlamalı, test kanıtı ise gerçek işlemi, kimlikleri, sonucu ve zamanı tanımlamalıdır. Test geçişini işletme sahipliğinin yerine kullanmayın.

Devralınan bir faturalandırma hizmetinin adlandırılmış bir işletme sahibine ve onaylanmış bir amaca sahip olduğunu, ancak hedef hesabın imzalama kimliğinin doğrulanmadığını varsayalım. İkinci bir hizmette uyumlu bir geçiş mesajı var ancak tanımlanmış bir işletme sahibi yok. Birincisi, göçten önce rota kanıtlarına ihtiyaç duyar; ikincisinin yetkili servis olarak değerlendirilmeden önce atıfta bulunulması ve onaylanması gerekir. Her iki boşluk da diğer hizmetin güven verici sonucuyla çözülmüyor.

Bunlar, oluşturulan kayıtlar veya yürütülen testler değil, varsayımsal envanter kararlarıdır. Sahiplik, amaçlanan kimlikler, onay ve mevcut test kapsamı için ayrı alanlar tutun. Uygulama sahibi eksik hesap kanıtlarını sağladığında yalnızca kendi oluşturduğu durumu güncelleyin; test edilmemiş bir geçiş sonucunu otomatik olarak başarılı olarak değiştirmeyin.

İlişkilendirmeyi bir geçiş planına dönüştürün

Hizmetleri doğrulanmış sahip, bağımlılık ve hazır olma durumuna göre gruplayın. Kayıtları düzenlemeden önce amaçlanan hedef kimlikleri ve testleri tanımlayın. Bilinmeyen rotaları sessizce onaylamak veya silmek yerine, adlandırılmış bir sahibi ve son teslim tarihi ile araştırma için koruyun. Her bir sonraki geçiş için eski yapılandırmayı ve onaylanmış bir kurtarma planını koruyun.

Standardizasyondan sonra, gerçek gözlemleri onaylanmış envanterle karşılaştırın ve yeni kimlikleri araştırın. Emekli hizmetleri ve kararları tarihe kalsın. Yararlı bir envanter, birleşme projesi sona erdiğinde terk edilen bir elektronik tablo yerine, satıcı değişiklikleri ve olay müdahalesi aracılığıyla bir işletme kaydı olarak kalır.

Bu envanter ve inceleme iş akışı, önerilen bir işletim modelidir. NIST SP 800-53 Rev. 5 CM-8 ve CM-3, hesap verilebilir envanterler ve kontrollü değişiklikler için genel bir temel sağlar; e-postaya özel bu alanları belirlemez veya onay vermezler. NIST kontrol kataloğu.

[ Götürmek ]

İş onayı, teknik atıf ve gözlemlenen operasyon bağımsız durumlardır; hiçbiri diğerinin yerini tutamaz.

[ Role göre ]

Bu sizin için ne anlama geliyor?

Sonraki pratik adımlar için rolünüzü seçin.

BT / Posta Yöneticisi

Yetkilendirmeden önce özellik

Sağlayıcı etiketi, doğrulanmış bir müşteri rotası değildir.

Sonraki adımlar

  1. Tüm kimlik doğrulama kimliklerini kaydedin.
  2. Amaçlanan hedef yapılandırmayı test edin.
  3. Standardizasyondan sonra yeni kimlikleri araştırın.

CISO / SecOps

Onaylamayı operasyondan ayrı tutun

Güvenilir bir hizmetin hâlâ bozuk bir kontrol yolu olabilir.

Sonraki adımlar

  1. Onaylanmamış ve test edilmemiş popülasyonları ayrı ayrı inceleyin.
  2. İlişkilendirme kanıtlarını ve karar geçmişini koruyun.
  3. Kanıtlarla çözülene kadar sahiplik boşluklarını takip edin.

Kurucu / Teknik Olmayan

Entegrasyondan önce işletme sahipliğini atayın

Bilinmeyen gönderenlerin otomatik standardizasyona değil kararlara ihtiyacı vardır.

Sonraki adımlar

  1. Hizmet sahiplerini adlandırın.
  2. Geçiş planlamasında kritikliğin görünür olmasını sağlayın.
  3. Bir sağlayıcı markasını onayla eş tutmayın.

[ SSS ]

Sık sorulan sorular

Tanıdık bir sağlayıcı IP'si bir göndereni onaylamak için yeterli mi?

Hayır. Müşteriye özel hizmeti, amacı, hesabı ve sahibini onaylayın.

Envanterde hangi kimlikler var?

Kiracı ve hizmet bağlamının yanı sıra görünür Kimden, zarf ve DKIM imzalama etki alanlarını kaydedin.

Raporlar uygulama sahibi görüşmelerinin yerini alabilir mi?

Hayır. Tam bir ticari ilişkilendirme değil, gözlemler sağlarlar.

Bilinmeyen gönderenler SPF eklenmeli mi?

Uygun kimlik doğrulaması yapılmış rotanın ilişkilendirilmesinden ve onaylanmasından önce değil.

Onaylanmış bir gönderici standardizasyon testlerinde başarısız olabilir mi?

Evet. Onay ve gözlemlenen çalışma ayrı durumlardır.

Bilinmeyen alanlar neden korunsun?

Soruşturma çalışmalarını belirler ve desteklenmeyen varsayımların onaylanmasını engeller.

Örnek bir mutabakat gerçekleştiriyor mu?

Hayır. Onay, atıf ve mevcut teknik kanıtları birbirinden ayırmak için varsayımsal hizmet durumlarını kullanır.

Daha sonra envanter nasıl tutulmalıdır?

Operasyonlar boyunca değişiklikleri, yeni gözlemleri, kullanımdan kaldırmaları ve testleri uzlaştırın.

[ Kaynaklar ]

Kaynaklar

  1. RFC 9989 Etki Alanı Tabanlı İleti Kimlik Doğrulaması, Raporlama ve Uyumluluk

    Bölümler §4.4 · §4.10.1 · §5.3.5 · §5.4 · §7.4 · §8

  2. RFC 9990 DMARC Toplu Raporlama

    Bölümler §3.1 · §3.1.1 · §7

  3. RFC 7208 Gönderen Politikası Çerçevesi

    Bölümler §3.2 · §3.3 · §4.6.4 · §5.2 · §6.1

  4. NIST SP 800-53 Rev 5 Sürüm 5.2.0 resmi OSCAL kataloğu

    Bölümler CM-3 Yapılandırma Değişikliği Kontrolü · CM-5 Değişiklik için Erişim Kısıtlamaları · AC-6 En Az Ayrıcalık · CM-8 Sistem Bileşen Envanteri

[ Sözlük ]

Sözlük

Gönderen ilişkilendirmesi
Gözlemlenen postaları belirli bir hizmete, müşteri hesabına ve sorumlu işletme sahibine bağlama.
Tanımlayıcı hizalaması
DMARC yazar alanı ile başarılı bir SPF veya DKIM tanımlayıcısı arasında gerektirdiği ilişki.

Kurumsal menşe

Neden en iyi finans kurumları ve hükümetler e-posta güvenlik kontrol panellerini kullanımdan kaldırdı.

Geleneksel e-posta kimlik doğrulama platformları size bir gösterge tablosu satar ve mühendislerinizden bu işi yapmalarını ister. Riskli ortamlarda, manuel gözetim, gecikmeli uygulama, konfigürasyon kayması ve izlenmeyen gölge alanlar anlamına gelir.

EmailAuth aracılı e-posta kaynak platformudur. Temsilcilerimiz uyguluyor p=reject, üçüncü taraf gönderenleri uyumlu tutun ve alan adlarınızı tam sürüme taşıyın RFC 9989 döngüdeki insan tarafından denetlenebilirliğe sahip yeni DMARC standardı uyumluluğu.

Hükümetler Büyük işletmeler 1. Seviye finans kurumları

SaaS · Özel kiracılık · Şirket içi hava boşluklu · BYOK şifrelemesi

Bilgi Bankası