Bir lojistik firmasının BT müdürü bize tek bir soruyla geldi: "Yeni e-posta güvenlik çözümümüzü kurduk ama müşteriler 'maillerimiz gecikiyor' diyor, bir de geçen hafta muhasebeden birinin hesabı ele geçirilmiş, oradan tüm müşterilere phishing gitmiş — çözümümüz neden görmedi?" İki şikâyetin de tek bir ortak kökü vardı: mimari.
E-posta güvenliğinde "hangi ürün" sorusundan önce gelen, çoğu zaman atlanan bir soru var: "bu ürün nasıl bir mimariyle çalışıyor?" Çünkü mimari; teslimat hızını, iç phishing'i görüp görememeyi, kurulum riskini ve devreye alma süresini doğrudan belirler.
Bu yazıda iki temel mimariyi — geleneksel Secure Email Gateway (SEG) ve modern API-tabanlı (ICES) yaklaşımı — yan yana koyuyor, hangisinin hangi senaryoda ne yaptığını net biçimde anlatıyoruz.
1. İki Mimari, İki Farklı Felsefe
Secure Email Gateway (SEG) — "Yolu Değiştir"
Geleneksel SEG, e-postanın teslimat yolunu değiştirir. Alan adınızın MX kaydı, e-postayı önce dış bir gateway'e yönlendirecek şekilde ayarlanır. E-posta orada taranır, temizse Microsoft 365 ya da Google Workspace'e iletilir. Yani gateway, posta kutunuzun önünde duran bir bekçidir.
API-tabanlı / ICES — "Yanına Bağlan"
ICES (Integrated Cloud Email Security), MX kaydını hiç değiştirmez. Bunun yerine Microsoft Graph API ya da Google API üzerinden posta platformunuza içeriden bağlanır. E-postayı, posta kutusuna ulaştığı andaki haliyle (ve gerektiğinde ulaşmadan önce) analiz eder. Yani gateway gibi yolun ortasında durmaz; platformun içine yerleşir.
2. Yan Yana Karşılaştırma
| Kriter | SEG (Gateway) | API / ICES |
|---|---|---|
| MX kaydı değişikliği | Gerekir | Gerekmez |
| Teslimat gecikmesi | Var (saniyeler) | Yok (inline modda dahi minimum) |
| İç phishing (account takeover sonrası) | Göremez — e-posta hiç gateway'den geçmez | Görür — gelen ve giden tüm e-postalar taranır |
| Devreye alma süresi | Günler/haftalar (MX, konnektör, kural geçişi) | Dakikalar (API bağlantısı) |
| Geri alınabilirlik (false pozitif) | E-posta gateway'de takılır | Monitor modunda hiç müdahale etmez; detect & remediate ile geri çekilir |
| Mevcut Microsoft/Google korumasıyla ilişki | Genelde yerine geçer | Yanına eklenir (katmanlı) |
| İşbirliği platformları (Teams, SharePoint, OneDrive, Slack) | Kapsam dışı | Aynı entegrasyonla kapsanır |
3. Asıl Ayrım: İç Phishing'i Kim Görebilir?
SEG mimarisinin en kritik kör noktası budur. Bir kullanıcının hesabı ele geçirildiğinde (account takeover), saldırgan o kullanıcının gelen kutusundan şirket içi meslektaşlara ya da müşterilere phishing gönderir. Bu e-posta, alan adınızın içinde, doğrulanmış bir hesaptan çıktığı için MX'teki gateway'e hiç uğramaz — gateway sadece dışarıdan gelen postayı görür.
Giriş bölümündeki lojistik firmasının yaşadığı tam olarak buydu: SEG, dışarıdan gelen tehditleri tarıyordu ama ele geçirilen iç hesaptan müşterilere giden phishing'i hiç görmedi. API-tabanlı bir çözüm, gelen ve giden tüm trafiği platformun içinden gördüğü için bu senaryoyu yakalar.
4. Teslimat Hızı ve MX Riski
SEG kurulumu MX kaydını değiştirdiği için iki yan etki doğurur:
- Gecikme: Her e-posta dış gateway'de taranıp iletildiğinden, teslimat birkaç saniye gecikebilir. Yoğun ortamlarda bu fark hissedilir.
- Tek nokta riski ve yapılandırma karmaşası: MX, konnektör, SPF dahil etme zinciri ve MTA-STS gibi ayarların hepsi gateway'e göre yeniden kurgulanmalıdır. Yanlış yapılandırma, e-posta akışını tamamen durdurabilir.
API-tabanlı yaklaşımda MX'e dokunulmadığı için bu risklerin hiçbiri yoktur. E-posta her zamanki gibi doğrudan Microsoft/Google'a ulaşır; güvenlik katmanı paralel çalışır.
5. SEG'in Hâlâ Anlamlı Olduğu Durumlar
Dürüst olmak gerekirse SEG ölü bir teknoloji değildir. Şu durumlarda hâlâ tercih edilebilir:
- On-premise (şirket içi) Exchange sunucusu kullanan, buluta geçmemiş ortamlar.
- API erişiminin kurumsal politika gereği kısıtlandığı çok özel uyumluluk senaryoları.
- Çok katmanlı bir yaklaşımda, API çözümünün yanında ek bir dış filtre istenmesi.
Ancak Microsoft 365 ya da Google Workspace kullanan bulut tabanlı kurumların büyük çoğunluğu için API-tabanlı (ICES) yaklaşım, daha düşük risk, daha hızlı kurulum ve iç phishing görünürlüğü nedeniyle bugün varsayılan tercihtir. Sektör analistleri de (Gartner dahil) e-posta güvenliğinde ağırlığın ICES'e kaydığını işaret ediyor.
6. Check Point Harmony Email Nerede Duruyor?
Check Point Harmony Email & Collaboration tam da bu API-tabanlı (ICES) mimaride çalışır:
- Microsoft Graph / Google API üzerinden bağlanır — MX değişmez.
- Gelen + giden + iç e-postaları, ayrıca Teams, SharePoint, OneDrive, Slack, Dropbox içeriğini tek entegrasyonla tarar.
- Monitor / Detect & Remediate / Inline modlarıyla, riski sıfırdan canlıya kademeli geçiş sunar.
- ThreatCloud AI'ın 200+ motoruyla beslenir; 2025 Gartner Magic Quadrant for Email Security'de Leader konumundadır.
Mimarinin pratikte ne anlama geldiğini görmek için Microsoft 365'in yerleşik e-posta güvenliği neden yetmez ve BEC / CEO dolandırıcılığı yazılarımızı birlikte okuyabilirsiniz.
Sıkça Sorulan Sorular
API-tabanlı çözüm, e-posta posta kutusuna ulaştıktan sonra mı tarar? Bu geç değil mi?
İki seçenek var. Detect & Remediate modunda e-posta kullanıcıya ulaşır ve zararlıysa saniyeler içinde geri çekilir. Inline modunda ise zararlı e-posta hiç gelen kutusuna ulaşmadan engellenir. İhtiyacınıza göre seçilir; çoğu kurum monitor → detect → inline sırasını izler.
MX kaydını değiştirmek o kadar mı riskli?
Riskli olmasa MX değişikliği gece nöbetlerinde planlanmazdı. Yanlış konnektör ya da SPF zinciri, e-posta akışını durdurabilir. API yaklaşımı bu riski tamamen ortadan kaldırır çünkü teslimat yolu hiç değişmez.
İki mimariyi birlikte kullanabilir miyim?
Evet, bazı kurumlar katmanlı yaklaşım için her ikisini birlikte kullanır. Ancak Microsoft 365/Google Workspace ortamlarının çoğunda, mevcut platform korumasının yanına bir API katmanı eklemek hem daha basit hem de iç phishing görünürlüğü açısından daha etkilidir.
Mevcut Secure Email Gateway'imi atmam mı gerekiyor?
Hayır, zorunlu değil. Ancak bir API çözümü devreye aldığınızda, çoğu kurum SEG'in artık ek bir değer üretmediğini ve hem maliyeti hem teslimat gecikmesini azaltmak için onu kaldırabileceğini görüyor. Bu kararı 14 günlük trial verisiyle birlikte veriyoruz.
Şimdi Ne Yapmalı?
Mevcut e-posta güvenlik çözümünüzün mimarisini ve iç phishing görünürlüğünü birlikte değerlendirelim.
- Saha Denetimi: Mevcut mimarinizi (SEG mi, API mi, hiçbiri mi) ve görünürlük boşluklarınızı raporluyoruz.
- 14 Günlük Check Point Trial (monitor modu): MX'inize dokunmadan, mevcut korumanızın yanında çalışarak iç ve dış tehditleri ölçüyoruz.
Bu yazı hakkında: Kinetik Bilişim, Check Point Software Technologies'in Advanced Partner 2026 seviyesindeki Türkiye iş ortağıdır ve Email Solution Specialization akreditasyonuna sahiptir. Saha örnekleri anonim hale getirilerek paylaşılmıştır. Mimari tanımları (SEG, ICES) sektör standartlarıyla uyumludur.
