[ Kurumsal operasyonlar ]

Üretim ve test ortamlarındaki kimlik doğrulama değişikliklerini kontrol edin

Üretim ve test gönderme yetkisini, mülkiyetini ve kanıtlarını ayırın; böylece deneyler, canlı posta kontrollerini sessizce değiştiremez.

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

[ Anahtar noktalar ]

  • Üretim ve test gönderme yetkisini, mülkiyetini ve kanıtlarını ayırın; böylece deneyler, canlı posta kontrollerini sessizce değiştiremez.
  • Farklı adlar ve temiz kayıt satırları izolasyonu zorunlu kılmaz; Gerçek platformda imzalama yetkisini ve alıcının muhafazasını doğrulayın.
Bu sayfada

Bir test ortamı, üretim kimlikleri üzerinde gereksiz yetki vermeden değişikliklerin doğrulanmasını mümkün kılmalıdır. Gönderen kaydındaki uygulama ortamlarını ayırın ve DNS , imzalama, aktarma ve alıcı izinlerini bağımsız olarak gözden geçirin. Aşamalandırma adı verilen bir etiket, üretim kimlik bilgilerini veya aynı sınırsız imzalama anahtarını kullandığında bir izolasyon kontrolü değildir.

Ortam sınırını tanımlayın

Uygulamanın amacını, ortamını, sahibini, kritikliğini, görünür etki alanından, zarf etki alanından kaydedin, DKIM İmza kimliği, uç nokta, onaylı alıcılar, son test ve onay referansı. Platformun izin verdiği ölçüde farklı hizmet kimlikleri ve kimlik bilgisi depolarını kullanın. Üretim sırlarını bir fikstür veya dokümantasyon örneğine kopyalamayın.

Özel bir test alt alanı, adlandırma ve politikanın ayrılmasına yardımcı olabilir, ancak otomatik olarak bir güvenlik sınırı oluşturmaz. DMARC rahat hizalama protokolün geçerli keşif ve hizalama kurallarına bağlı olarak etki alanlarını kurumsal etki alanı düzeyinde ilişkilendirebilir. En soldaki farklı bir etiketin postaları alakasız hale getireceğini varsaymak yerine, gerçek hizalama davranışını doğrulayın. RFC 9989.

Yetkiyi isimlendirmeden ayırın

Her imzalama hizmetinin, DNS temsilcisinin ve geçiş kuralının neler yapabileceğini inceleyin. Üretim alanı için imza atmasına izin verilen bir test hizmeti yine de üretime uygun postalar üretebilir. Özel bir alana sahip bir test göndericisi, alıcı kontrolleri kısıtlanmamışsa yine de gerçek müşterilere ulaşabilir. Kimlik doğrulama ve alıcının sınırlandırılması farklı sorunları çözer.

İçin SPF, gerçek zarf kimliğini ve yetkili gönderme altyapısını inceleyin. DKIM için inceleyin seçici yalnızca görünen adres yerine sahiplik ve imzalama alanı. RFC 7208 Ve RFC 6376. Paylaşılan otoriteyi, görünmez bir kolaylık olarak değil, etkisi, sahibi ve geçerliliği olan açık bir istisna olarak ele alın.

İki aşamalandırma hatasını ayırın

Bir hazırlama hizmetinin etki alanından özel bir testi olduğunu, ancak imzalama kimlik bilgilerinin üretim için de imza atabildiğini varsayalım. İkinci bir hizmetin imzalama yetkisi sınırlıdır ancak kısıtlamasız gerçek alıcılara gönderim yapabilir. İlkinin imza izninin gözden geçirilmesi gerekiyor; ikincisi alıcının muhafaza altına alınmasını gerektirir. Test alanı etiketi her iki izin boşluğunu da çözemez.

Bunlar, yürütülen bir koruma veya platform denetimi değil, varsayımsal izin bulgularıdır. Onaylanan kimlikleri ve alıcıları kaydedin, ardından yetkili yapılandırma kanıtları ve sınırlı testlerle uygulamayı doğrulayın. Bir e-tablo bir uyumsuzluğu ortaya çıkarabilir ancak bir mesajı durduramaz. Kontrollerin mevcut olmadığı durumlarda, yalnızca isimlendirmeden izolasyon ilan etmek yerine, açık bir kontrolü veya dar anlamda onaylanmış bir alternatifi koruyun.

Gizli durum yerine gözden geçirilen yapılandırmayı destekleyin

Her ortam için amaçlanan yapılandırmayı ve tam farkı saklayın. Neyin tanıtıldığını gözden geçirmek için NIST temel ve değişiklik kontrolü ilkelerini kullanın. SP 800-128. Genel DNS adları, seçiciler ve sertifika kimlikleri gibi ortamlar arasında aynı olamayacak bağımlılıkları kaydedin.

Adayı güvenli bir ortamda test edin ve ardından üretim dağıtımı için gerekli onayı alın. Başarılı bir aşamalandırma testi, üretim DNS , izinleri veya yönlendirme davranışını kanıtlamaz. Üretimi yetkili alıcılarla doğrulayın ve uygulama sonrasında sınırlı bir test yapın. Test sırasında ortam değişirse eski sonuçları mevcut onay olarak değerlendirmek yerine temel çizgiyi yeniden oluşturun.

Kanıtı ve erişimi ayrı tutun

Ortam etiketleri ve zaman damgalarıyla birlikte ayrı test kanıtlarını saklayın. Gerekmediğinde gerçek alıcı verilerini çıkarın ve gerçek müşteri mesajlarını test donanımı olarak kullanmaktan kaçının. Üretim DNS düzenleme, imza kimlikleri atama ve alıcı kontrollerini sorumlu operatörlere değiştirme yeteneğini kısıtlayın.

Paylaşılan bağımlılıkları düzenli aralıklarla gözden geçirin. Test ve üretimin bir geçiş veya sağlayıcı hesabını paylaşması gerekiyorsa kimlik ve alıcı kullanımını sınırlayan gerçek kontrolleri belgeleyin. Üretim için geri almayı test temizlemeden ayrı olarak tanımlayın. Bir test seçicinin kaldırılması ancak hiçbir üretim akışının ona bağlı olmadığı doğrulandıktan sonra güvenlidir; isimler tek başına bu bağımlılığı oluşturamaz.

[ Götürmek ]

Farklı adlar ve temiz kayıt satırları izolasyonu zorunlu kılmaz; Gerçek platformda imzalama yetkisini ve alıcının muhafazasını doğrulayın.

[ 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

Sınırı uygula

Yapılandırma etiketlerinin arkasında platform kontrollerinin olması gerekir.

Sonraki adımlar

  1. Ayrı imza yetkisi.
  2. Alıcı kısıtlamalarını doğrulayın.
  3. Üretimi açıkça test edin.

CISO / SecOps

Ortamlar arası erişimi inceleyin

Paylaşılan kimlik bilgileri amaçlanan ayrılığı ortadan kaldırabilir.

Sonraki adımlar

  1. DNS izinlerini sınırlayın.
  2. İstisnaları izleyin.
  3. Promosyon kanıtlarını denetleyin.

Kurucu / Teknik Olmayan

Testi güvenli hale getirin

Ortam ayrımı müşteri iletişimini korumalıdır.

Sonraki adımlar

  1. Test alıcılarını onaylayın.
  2. Ayrı kimliklere fon sağlayın.
  3. Paylaşılan hizmet istisnalarını inceleyin.

[ SSS ]

Sık sorulan sorular

Bir hazırlama etiketi postaları yalıtır mı?

Hayır. Gerçek kimlik bilgilerini, imzalama yetkisini, uç noktaları ve alıcı kontrollerini inceleyin.

Bir test alt alanı her zaman DMARC ile yalıtılmış mıdır?

Hayır. Uygulanabilir hizalamayı ve ilke bulma semantiğini kontrol edin.

Kimlik doğrulama alıcıları içerebilir mi?

Hayır. Alıcı kısıtlamaları ayrı uygulama veya taşıma kontrolleri gerektirir.

Demirbaşlarda üretim kimlik bilgileri kullanılmalı mı?

Hayır. Sentetik verileri ve kontrollü test kimliklerini kullanın.

İki sahneleme örneği neyi açığa çıkarıyor?

Birinin aşırı imzalama yetkisi varken, diğerinin alıcı sınırlaması yok. Düzeltici kontrolleri ayrıdır.

Örnekler canlı bir sınırı zorunlu kılıyor mu?

Hayır. Bunlar varsayılan izin boşluklarını göstermektedir; yaptırımın gerçek uygulama veya taşıma platformunda doğrulanması gerekir.

Aşamalandırma başarısı üretimi otomatik olarak onaylayabilir mi?

Hayır. Üretim bağımlılıkları ve fiili dağıtım, kendi yetkili doğrulamalarına ihtiyaç duyar.

Bir test seçici yalnızca isimle silinebilir mi?

Hayır. Onaylanan kullanımdan kaldırılmadan önce hiçbir üretim akışının buna bağlı olmadığını doğrulayın.

[ Kaynaklar ]

Kaynaklar

  1. RFC 9989 DMARC

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

  2. RFC 7208 SPF

    Bölümler §2.3 · §2.4 · §4.6.4

  3. RFC 6376 DKIM

    Bölümler §3.5 · §3.6 · §5.2 · §6.1.2

  4. NIST SP 800 128 Yapılandırma Yönetimi

    Bölümler §3.2 Konfigürasyonların Belirlenmesi ve Uygulanması · §3.3 Konfigürasyon Değişikliğini Kontrol Etme

[ Sözlük ]

Sözlük

Çevre sınırı
Dağıtım bağlamları arasında kimliklerin, erişimin ve alıcıların zorunlu olarak ayrılması.
Terfi
Onaylanmış bir konfigürasyon değişikliğinin başka bir ortama kontrollü olarak taşınması.

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ı