DMARC ve şifreleme farklı e-posta risklerini çözer. DMARC alıcı sistemin, bir alanın hizalanmış, kimliği doğrulanmış bir yol üzerinden kullanılıp kullanılmadığını değerlendirmesine yardımcı olur. Şifreleme, mesaj verilerini bir aktarım atlama noktası boyunca veya farklı bir tasarımla mesaj uç noktaları arasında korur. Her iki kontrol de otomatik olarak diğerini sağlamaz.
Bu ayrım önemlidir çünkü aynı mesajın kimliği iyi bir şekilde doğrulanabilir ve yine de istediğiniz taşıma güvencesi olmadan seyahat edebilir. Bir mesaj, hizalanmış kimlik doğrulaması olmayan bir Gönderen etki alanı talebinde bulunurken şifreli bir bağlantı üzerinden de seyahat edebilir.
Koruma sorusuyla başlayın
Kontrolü seçmeden önce neyin korunması gerektiğini sorun:
- Koruma sorusu: Kimliği doğrulanmış bir etki alanı Kimden'deki etki alanıyla uyumlu mu?; İlgili mekanizma: DMARC ile SPF veya DKIM; Neyi belirlemez: Gizlilik, gönderenin amacı veya güvenli içerik
- Koruma sorusu: Mesaj, d= alanı için DKIM özel anahtarının sahibi tarafından mı imzalandı?; İlgili mekanizma: DKIM ; Neyi belirlemez: İnsan kimliği, gizlilik veya gelen kutusu yerleşimi
- Koruma sorusu: Kabul edilebilir TLS kullanmak için bu SMTP dağıtım noktası gerekli miydi?; İlgili mekanizma: MTA-STS veya başka bir taşıma politikası; Neyi belirlemez: Uçtan uca gizlilik veya Alan Adından hizalama
- Koruma sorusu: Bir alıcı, kendisine yönelik içeriğin şifresini çözebilir mi?; İlgili mekanizma: Mesaj düzeyinde şifreleme; Neyi belirlemez: Ayrı olarak yapılandırılmadıkça DMARC hizalaması
Bu matris, ürün sıralamasını değil, kontrol sınırlarını açıklar. Tehditler birbirinin yerine geçemediği için eksiksiz bir mimari birden fazla mekanizma kullanabilir.
Bir sentetik mesaj yolunu takip edin
billing@shop.example.com adresinden accounts@buyer.example.org adresine doğrudan SMTP teslimatı yoluyla gönderilen kurgusal bir faturayı düşünün. Gönderme hizmeti, bounce.mailer.example.net adresinde bir zarf alanı kullanır ve d=shop.example.com. Geçerli bir DMARC politikasının olduğunu ve kimlik kontrollerinin tamamlandığını varsayalım. Bu sentetik senaryoda, gönderen MTA https://mta-sts.buyer.example.org/.well-known/mta-sts.txt adresinden alıcı etki alanı buyer.example.org için geçerli bir zorlama modu MTA-STS politikasını keşfeder ve alır https://mta-sts.buyer.example.org/.well-known/mta-sts.txt. Seçilen hedefin ( mx1.buyer.example.org ) politikayla eşleşip eşleşmediğini kontrol eder, ardından TLS bağlanıp pazarlık yapar ve mesajı aktarmadan önce MX sertifikasını doğrular.
Altında RFC 8461 §3.3, RFC 8461 §4.1, RFC 8461 §4.2 Ve RFC 8461 §5varsayımsal kontroller şu ifadeleri destekleyecektir:
- İmza doğrulandığından ve bu örnekte d= alanı Kimden alanıyla eşleştiğinden DKIM hizalanmış bir geçiş yolu sağlayabilir.
- DMARC mesaj düzeyinde bu hizalanmış DKIM yolundan geçebilir.
- Alıcı SMTP atlama noktası, politikanın geçerli, geçerli ve doğru şekilde uygulandığını varsayarak, alıcı etki alanının yayınlanmış aktarım politikasına uygun olarak TLS kullandı.
- Bu gerçeklerin hiçbiri faturanın gerçek olduğunu, gönderenin hesabının ele geçirilmediğini veya mesajın önceki ve sonraki tüm kopyalarının şifreli kaldığını kanıtlamaz.
Şimdi yalnızca imzalama alanını d=mailer.example.net. DKIM yine de başarılı olabilir ancak bu ilgisiz alan adı shop.example.com ile uyumlu olmayacaktır. TLS korumalı dağıtım noktası bu hizalama hatasını onarmaz.
DKIM imzalamayı ve şifrelemeyi ayrı tutun
Altında RFC 6376 §3.7DKIM , seçilen mesaj verilerinin üzerine kriptografik bir imza uygular. Doğrulayıcı, aşağıdakiler için yayınlanan bir genel anahtarı kullanır: seçici ve d= etki alanı. İmza, imzalanan içerik ve imzalama alanı hakkında kanıt sağlar. Mesajı gizlemez.
Şifrelemenin farklı bir amacı vardır. Altında RFC 3207 §6SMTP TLS , uçtan uca mesaj yolunun tamamını değil, sistemler arasında anlaşmalı bir bağlantıdaki verileri korur. MTA-STS alıcı etki alanının uyumlu gönderenlerin MX ana bilgisayarlarına TLS dağıtımını doğrularken kullanabileceği bir politika yayınlamasına olanak tanır. TLS raporlaması, aşağıdaki koşullar altında aktarım hataları hakkında toplu geri bildirim sağlayabilir: RFC 8460 §4.1, RFC 8460 §4.2 Ve RFC 8460 §4.3. Bu kontroller SMTP postasını uçtan uca şifrelenmiş bir nesneye dönüştürmez.
Mesaj düzeyinde şifreleme, S/MIME ile gösterilen başka bir katmandır. RFC 8551 §1 Ve RFC 8551 §3.3. İçeriği, yalnızca uygun anahtarlara sahip amaçlanan uç noktaların okuyabileceği şekilde koruyabilir, ancak anahtar dağıtımı ve sertifika işleme gibi RFC 8551 §4 konu. Alıcı kapasitesi, kurtarma ve arşiv erişimi de açık operasyonel tasarıma ihtiyaç duyar. DMARC görünür Kimden alanı ve hizalanmış kimlik doğrulamanın ayrı bir değerlendirmesi olarak kalır.
Her güven kararını tanımlayın
Yararlı bir tasarım kaydında her kontrol için dört şey belirtilir:
- Denetim: DMARC ; Kimlik veya varlık: Alan Adı Kimden; Güven çapası: DNS politikası artı uyumlu SPF veya DKIM sonucu; Saklanacak kanıtlar: Güvenilir alıcı sonucu ve geçerli politika
- Kontrol: DKIM ; Kimlik veya varlık: İmzalama alanı ve seçici; Güven bağlantısı: DNS genel anahtarı; Saklanacak kanıtlar: İmza, doğrulama sonucu ve anahtar kaydı
- Kontrol: MTA-STS ; Kimlik veya varlık: Etki alanı ve MX aktarımının alınması; Güven çapası: DNS keşfi artı HTTPS politikası; Saklanacak kanıtlar: Politika kimliği, getirilen politika ve teslimat sonucu
- Kontrol: Mesaj şifreleme; Kimlik veya varlık: Alıcı veya uç nokta anahtarları; Güven çapası: Seçilen anahtar ve sertifika güven modeli; Saklanacak kanıtlar: Şifreleme durumu, alıcı eşlemesi ve anahtar yaşam döngüsü
Bunları tek bir yeşil rozete çevirmeyin. Her cevabın daha dar bir anlamı ve farklı bir başarısızlık modu vardır.
Kontrolleri tehditlerle eşleyin
DMARC katılımcı alıcıların korumalı bir Gönderen alan adının yetkisiz kullanımını tanımlamasını ve işlemesini kolaylaştırabilir. Meşru bir hesabın kötüye kullanılmasını engellemez, bir ödeme talebinin doğru olup olmadığını denetlemez veya saklanan postayı şifrelemez.
TLS korumalı bir atlamada pasif müdahaleye maruz kalmayı azaltabilir. From etki alanının kimliğini doğrulamaz. TLS yanlış veya güvenilmeyen hedefle anlaşan bir sistem, politika tarafından uygulanan, doğrulanmış bir bağlantıyla aynı güvenceyi elde edemedi.
İleti şifrelemesi, tasarımına bağlı olarak içeriği aktarım oturumunun ötesinde koruyabilir. Tek başına DMARC hizalaması oluşturmaz, bir ticari işlemi yetkilendirmez veya uç nokta uzlaşmasını ortadan kaldırmaz.
Aşırı iddiada bulunmadan kanıt oluşturun
Kimlik için, temsilcinin aldığı mesajı yakalayın ve Kimden, zarf kimliğini, her DKIM d= alanını, ham kimlik doğrulama sonuçlarını, hizalamayı ve DMARC düzenini kaydedin. Taşıma için MTA-STS politikasını, MX kapsamını ve TLS raporlama kanıtlarını saklayın. Mesaj şifreleme için anahtarların kimin elinde olduğu, alıcıların nasıl kaydedildiği, anahtar kaybolduğunda ne olacağı ve hangi sistemlerin düz metne erişebileceği gibi belgeler.
Bir laboratuvar testi test olarak etiketlenmelidir. Her üretim rotasının aynı şekilde davrandığını kanıtlamaz. Düşük hacimli hizmetleri, yönlendirme rotalarını, yedek MX ana bilgisayarlarını ve kontrol hedefini etkiledikleri yerlerde mobil veya arşiv erişimini doğrulayın.
Ayrı sahipler ve kurtarma rotaları atayın
Posta işlemleri genellikle kimlik doğrulama ve SMTP aktarımına sahiptir. Güvenlik mimarisi politikaya, tehdit kapsamına ve şifreleme standartlarına sahip olabilir. Uygulama ekipleri, iş postası oluşturan gönderme yollarının sahibidir. Hukuk ve kayıt ekipleri içerik saklama ve anahtar kurtarma gerekliliklerini etkileyebilir.
Her kontrole bir yükseltme tetikleyicisi verin. Hizalama regresyonu, gönderen sahipliğine ve posta işlemlerine gider. Bir TLS politikası hatası aktarıma ve DNS sahiplerine gider. Kayıp bir mesaj şifreleme anahtarı, anahtar yönetimi kurtarma işlemine gider. Genel bir "e-posta güvenliği" kuyruğu, verilmesi gereken kararı gizler.
Satın alma kararını açıkça belirtin
Bir projeyi onaylamadan önce istenen sonuç için bir cümle yazın. DMARC ve uyumlu kimlik doğrulamaya yönelik "Kimden alan adlarımızın yetkisiz kullanımını azaltın". "Alanımıza teslimat için kabul edilebilir TLS gerektir" taşıma politikasına işaret ediyor. "Mesaj içeriğini onaylanmış uç noktaların dışında okunamaz halde tut", bir mesaj şifreleme tasarımı gerektirir.
Bu sonuçlar bir arada var olabilir. Önemli karar, tanıdık bir e-posta güvenliği kısaltmasının kimlik, gizlilik ve iş meşruiyetini aynı anda kapsadığını varsaymak yerine, eksik korumayı finanse etmektir.
Sonucu kanıtın içinde tutun
Fatura sabitlemesi için başarılı DKIM hizalamasını ve doğrulanmış SMTP atlamasını farklı kanıt alanlarında tutun. SPF hizalanmamış halde kalırken yalnızca d= ilgisiz sağlayıcı etki alanına değişirse TLS yine de hizalanmış bir kimlik oluşturmaz. Burada açıklanan politika getirme, TLS anlaşması ve imza doğrulama işlemlerinin, gerçekleştirilen ağ veya mesaj testleri değil, öğretme girdileri olduğu varsayılır.