Ana içeriğe geç

SecuraWall.com

E-posta güvenliği ve sürekliliği

Keşfedin
Teknik Rehber · Siber Güvenlik

E-posta Güvenlik Ağ Geçidi Nedir?

E‑posta güvenlik gateway'i; spam, phishing, malware, spoofing ve zararlı bağlantı risklerini azaltmak için mesajları teslimat öncesi analiz eden güvenlik katmanıdır.

SON TEKNİK GÖZDEN GEÇİRME:
Siber Güvenlik

Bu Konu Neden Önemli?

E‑posta güvenlik gateway'i; spam, phishing, malware, spoofing ve zararlı bağlantı risklerini azaltmak için mesajları teslimat öncesi analiz eden güvenlik katmanıdır.

Karar Verirken Kontrol Edilecek Noktalar

SPF/DKIM/DMARC ile gateway politikalarını birlikte tasarlayın.

URL ve ek analizini ayrı katmanlar olarak değerlendirin.

VIP/finance hedefli saldırılar için özel politikalar kullanın.

Karantina ve kullanıcı bildirim akışlarını test edin.

Mimari ve çalışma modeli

E-posta ağ geçidi SMTP akışında kimlik, içerik ve hedef denetimi yapar. MX yönlendirmesi, connector güveni ve çıkış relay kapsamı mimarinin parçasıdır. SPF veya DKIM başarısı mesajın güvenli olduğunu kanıtlamaz; ele geçirilmiş meşru hesap da zararlı içerik gönderebilir. URL tıklama zamanı kontrolü, ek analizi ve karantina farklı görevlerdir.

İletme servisleri, mailing list ve uygulama gönderimleri yanlış pozitif üretebilir. Kontrol atlayan doğrudan teslim veya geniş güvenli connector yollarını keşfedin.

  1. 1Gönderen SMTP
  2. 2Gateway kontrolleri
  3. 3Karantina veya teslim
  4. 4Olay ve kullanıcı bildirimi
Mesaj başlıklarıyla gerçek teslim yolunu kanıtlayın; gateway atlayan connector olmadığını test edin.

Tasarım parametreleri

Posta rotası
MX, connector ve doğrudan teslim yollarını belgeleyin; gateway dışındaki yolu engellemeden tek noktada filtreleme eksik kalabilir.
Kimlik ve içerik
SPF/DKIM/DMARC, URL analizi ve ek incelemesi farklı tehditleri ele alır; bir kontrolün geçmesi hepsini doğrulamaz.
Kimlik ve kapsam
Kullanıcı, cihaz ve servis kimliklerini ayırın. Politikanın uygulandığı kaynakları ve dışarıda kalan erişim yollarını listeleyin.
Politika kararı
İzin, engelleme ve istisna koşullarını açık yazın. Kural sırası, varsayılan davranış ve oturum yenilenmesi sonucu değiştirebilir.
Kapasite ve gecikme
Yoğun saatteki gerçek iş yükünü ölçün. Güvenlik kontrolü açıkken yanıt sürelerini ve kuyrukları kontrolsüz temel ölçümle karşılaştırın.
Kayıt ve müdahale
Karar kaydının hangi sistemde tutulduğunu belirleyin. Olay kimliği, zaman, kaynak ve politika gerekçesi araştırmayı mümkün kılmalıdır.

Hesap ve uygulama örneği

Örnek test kümesinde normal fatura, sentetik phishing bildirimi ve uygulama e-postası kullanın. Teslim süresi, karantina sahipliği ve kullanıcının bildirim akışını ölçün. Açık relay testi yetkili laboratuvarla sınırlandırılmalı; gateway arızasında mesajın kuyrukta mı kaldığı yoksa kontrolsüz geçtiği belgelenmelidir.

Hata teşhisi

BelirtiOlası neden / ayrımDoğrulama
Meşru posta karantinadaKimlik hizalama, itibar veya içerik kararı farklı nedenler olabilir.Mesaj kimliğiyle teslim izi, başlıklar ve karantina gerekçesini eşleştirin.
İzin verilmesi beklenen işlem engelleniyorKural kapsamı veya istisna yanlış eşleşiyor olabilir; kontrolü bütünüyle kapatmak nedeni gizler.Tek bir test kimliği ve kaynakla karar kaydını inceleyin; aynı koşulu pilotta tekrar üretin.
Politika değiştiği halde erişim sürüyorMevcut oturum, belirteç veya başka bir erişim yolu farklı kontrol süresine sahip olabilir.Yeni ve mevcut oturumu ayrı test edin; doğrudan erişimin politika noktasını atlamadığını doğrulayın.
Alarm var ancak olay araştırılamıyorEksik alan, saat farkı veya veri toplama kesintisi ilişkilendirmeyi engelliyor olabilir.Kaynak kaydıyla merkezi kaydı eşleştirin; olayın baştan sona izlenebildiğini gösterin.

Kabul ve doğrulama kontrolleri

  1. Mesaj başlıklarıyla gerçek teslim yolunu kanıtlayın; gateway atlayan connector olmadığını test edin.
  2. İzinli ve reddedilmesi gereken akışları aynı test kimliğiyle ayrı doğrulayın.
  3. Yeni oturum, süresi dolan oturum ve iptal edilen yetkiyi sınayın.
  4. İstisnalar için sahip, kapsam ve bitiş tarihi kaydedin.
  5. Yanlış engelleme sırasında dar kapsamlı geri alma adımını uygulayın.
  6. Log kesintisi ve politika servisinin erişilememesi için davranışı belgeleyin.

İlgili kavramlar

Güven sınırı ve hata alanı

Güven sınırı, aynı erişim kararlarını paylaşan bileşenleri ayırır; hata alanı ise tek bir olayın birlikte etkileyebileceği kaynakları tanımlar. İki VLAN kullanmak, aralarında serbest yönlendirme varsa güçlü bir güven sınırı kurmaz. İki yedek aynı yönetici hesabıyla silinebiliyorsa da farklı klasörlerde bulunmaları ayrı hata alanı sağlamaz. Tasarımda fiziksel yer, kimlik sağlayıcı, yönetim hesabı, ağ yolu ve enerji kaynağını ayrı ayrı değerlendirin. Bir bileşen kaybedildiğinde hangi erişimlerin ve kurtarma seçeneklerinin ayakta kalacağını sınayın.

Kimlik doğrulama ve oturum

Kimlik doğrulama kullanıcının veya iş yükünün kim olduğunu kanıtlar; yetkilendirme ise bu kimliğin ne yapabileceğini belirler. Başarılı oturum açma, bütün kaynaklara erişim izni anlamına gelmez. Kullanıcı oturumları, servis kimlikleri, API belirteçleri ve cihaz sertifikaları farklı yaşam döngülerine sahiptir. İlk giriş kadar oturum süresi, belirteç yenileme, işten ayrılma, kayıp cihaz ve acil erişim senaryolarını da tasarlayın. Kimlik sağlayıcı erişilemez olduğunda hangi oturumların süreceğini ve hangi yeni erişimlerin engelleneceğini ölçün.

En az yetki ve görev ayrımı

En az yetki, bir görevin gerektirdiği izinlerin belirli kaynak ve süreyle sınırlandırılmasıdır. Herkese aynı yönetici rolünü vermek, erişim incelemesini ve olay araştırmasını zorlaştırır. Günlük kullanıcı hesabı ile ayrıcalıklı hesabı ayırın; servis hesaplarının etkileşimli kullanımını ve gereksiz ağ erişimini kısıtlayın. Yetki matrisi, kimliğin kaynağa hangi işlemle eriştiğini göstermelidir. Bir izin kaldırıldığında uygulamanın çalışmayı sürdürmesi de test kapsamına girer: gereksiz yetkiler bazen yalnız kontrollü azaltma sırasında ortaya çıkar.

Telemetri ve zaman eşleştirmesi

Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; günlük kaydı bulunmaması, olay yaşanmadığı şeklinde yorumlanmamalıdır.

Politikanın yaşam döngüsü

Bir politika yalnız etkinleştirildiği anda değil, kapsamı değiştikçe de yönetilmelidir. Taslak, gözlem, pilot, uygulama ve periyodik inceleme aşamalarını ayırın. Her istisnanın sahibi, gerekçesi, kapsamı ve sona erme tarihi olmalıdır. Test verileri gerçek kullanıcı davranışını temsil etmezse başarılı pilot üretimde yanlış engellemelere dönüşebilir. Önce kimin ve hangi uygulamanın etkilenebileceğini belirleyin; sonra ölçülebilir kabul koşullarıyla devreye alın. Geri alma yolu yalnız düğme konumunu değil, değişikliğin kim tarafından ve hangi koşulda geri alınacağını da tanımlamalıdır.

TLS ve sertifika doğrulaması

TLS iletişimin gizliliğini ve bütünlüğünü sağlar; sertifika doğrulaması karşı taraf kimliğinin kontrolüne yardımcı olur. Sertifika adı, zincir, geçerlilik süresi ve güvenilen kökler birlikte değerlendirilmelidir. Bir bağlantının şifreli olması uygulamanın yetkilendirmesinin doğru olduğu anlamına gelmez. Reverse proxy veya inspection kullanılıyorsa TLS oturumunun hangi noktada sonlandırıldığını çizimde açıkça gösterin. Hata teşhisinde sertifika kontrolünü kapatmak kalıcı çözüm değildir; yanlış hostname, eksik ara sertifika ve cihaz saatini ayrı inceleyin.

Birincil teknik dokümantasyon

SecuraWall MailFlow

E-posta Güvenliği ve Sürekliliği

Backup MX, SMTP Gateway, AntiSpam ve Antivirus hizmetleri.

SecuraWall MailFlow’u keşfedin
Who · How · Why

Bu İçerik Nasıl Hazırlandı?

KİM?

Doz Teknoloji Teknik Ekibi

İçerik, Doz Teknoloji’nin kurumsal BT hizmet alanlarında kullandığı teknik değerlendirme yaklaşımı temel alınarak hazırlanmıştır.

NASIL?

Teknik kriterler + birincil kaynaklar

Konu; üretici dokümantasyonu, standart kuruluşları ve ilgili resmî teknik kaynaklarla çapraz kontrol edilmiştir.

NEDEN?

Karar kalitesini artırmak

Amaç, teknik bir terimi yalnız tanımlamak değil; satın alma, tasarım veya işletim kararı verirken hangi kriterlerin birlikte değerlendirilmesi gerektiğini görünür hale getirmektir.

SON TEKNİK GÖZDEN GEÇİRME

Bu Rehberle İlgili Kurumsal Çözümler

Teknik konuyu uygulamaya dönüştürmek için ilgili hizmet ve çözüm sayfalarına geçebilirsiniz.

Teknik İhtiyacınızı Birlikte Değerlendirelim

Mevcut altyapınızı, kullanıcı sayınızı veya teknik hedefinizi paylaşın; ürün, lisans veya proje kapsamını ihtiyaca göre netleştirelim.

Teknik Talep Oluşturun
Kurumsal IT Ürün Satışı, Lisanslama ve Kurulum
Kurumsal IT Proje & Çözüm Senaryoları
Tüm ilgili içerikleri görüntüleyin
WhatsApp'tan Yazın
Kopyalandı!