Mimari ve çalışma modeli
API based email security ve API email security, posta platformuna API üzerinden bağlanan güvenlik çözümlerini anlatır. Seçimde kritik sorular uygulamanın hangi verilere eriştiği, neyi değiştirebildiği ve mesajı hangi aşamada incelediğidir.
Posta kutusu API'si üzerinden değişiklik bildirimi alan bir ürün ile SMTP akışında çalışan bulut ağ geçidinin kontrol noktaları farklıdır. API etiketi tek başına teslimat öncesi engelleme garantisi vermez. Bazı çözümler teslimat sonrası inceleme ve düzeltme yaparken farklı mimariler başka yöntemler kullanabilir; üreticiden gerçek akış ve zaman ölçümü isteyin.
Microsoft Graph'ta Mail.Read ile Mail.ReadWrite farklı işlem kapsamlarıdır; Mail.ReadWrite ayrıca Mail.Send yetkisi anlamına gelmez. Exchange Online Application RBAC kaynak kapsamını daraltmaya yardımcı olur; bunun yanında kalmış geniş Entra izinlerinin toplam erişimi büyütmediğini de denetleyin. Gmail tarafında metadata erişimi ile içerik okuma kapsamları eşdeğer değildir. Yalnız başlık gören bir uygulamanın ek dosyayı inceleyebildiğini varsaymayın.
Bildirim aboneliğinin süresi dolabilir veya olay işleme gecikebilir. Bu nedenle yeni mesajların kapsama girme oranını, bildirim gecikmesini ve düzeltme tamamlanma süresini ayrı ölçün. Doz Teknoloji, API katmanını mevcut platforma göre değerlendirir. SecuraWall bu karşılaştırmada bulut SMTP ağ geçidi ve Backup MX yaklaşımının örneğidir; burada bir posta kutusu API tarama ürünü olarak tanıtılmamaktadır.
- 1Platform olayı veya SMTP akışı
- 2Yetki ve kaynak kapsamı
- 3İnceleme ve politika kararı
- 4Düzeltme veya teslimat kanıtı
Tasarım parametreleri
- Veri ve işlem kapsamı
- Başlık, gövde, ek ve silme/taşıma erişimini ayrı yazın; kurum genelindeki uygulama izni ile kullanıcı adına izni ayırın.
- Kapsanan kaynaklar
- Kullanıcı, paylaşılan posta kutusu, grup, iç yazışma ve arşiv kapsamını pilotta tek tek doğrulayın.
- İnceleme zamanı
- Platforma geliş, kullanıcıya görünme, bildirim, karar ve düzeltme zamanlarını aynı saat kaynağıyla ölçün.
- Yaşam döngüsü
- Abonelik yenileme, iptal edilen izin, API kotası ve kaçırılan bildirimler için telafi davranışı belirleyin.
API katmanı ve bulut e-posta ağ geçidi
Bu tablo mimari seçim içindir. Ürünlerin gerçek kapsamı, etkin politikaları ve platform entegrasyonu pilotta doğrulanmalıdır.
| Karar noktası | Posta kutusu API yaklaşımı | Bulut SMTP ağ geçidi |
|---|---|---|
| Kontrol yeri | İzin verilen platform verileri ve işlemleri | Üzerinden geçen SMTP trafiği |
| Zamanlama | Bildirim ve tarama mimarisine bağlı | Yönlendirilen mesajı hedefe iletmeden değerlendirebilir |
| İç yazışma | İzin ve ürün kapsamındaysa inceleyebilir | Geçitten geçmiyorsa gözlemez |
| Geçici hedef kesintisi | Tek başına SMTP kuyruğu anlamına gelmez | Hizmet kapsamındaysa kabul edilen mesajı kuyruklayabilir |
Hesap ve uygulama örneği
Örnek pilotta 20 kullanıcıya ve iki paylaşılan posta kutusuna ait izinli test mesajlarını izleyin. Mesajın platforma gelişini t0, bildirimi t1, güvenlik kararını t2 ve düzeltme sonucunu t3 olarak kaydedin. t2−t0 inceleme gecikmesini, t3−t0 ise sonuca kadar geçen süreyi gösterir. Bunlar örnek ölçüm tanımlarıdır; bütün sağlayıcılar için sabit bir süre değildir.
Aynı pilotta bir test posta kutusunu uygulama kapsamından çıkarın ve erişimin gerçekten reddedildiğini doğrulayın. Bildirim aboneliğinin yenilenmediği bir laboratuvar senaryosunda alarmı ve telafi taramasını inceleyin. Yönetici ekranında yeşil bağlantı simgesi görünmesi, bütün posta kutularının ve bütün mesajların tarandığını tek başına kanıtlamaz.
Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Bağlantı açık ama mesaj incelenmiyor | Kutu veya içerik kapsamı yetersiz olabilir. | Erişim kapsamını ve mesajın olay zincirini inceleyin. |
| Karar mesaj okunduktan sonra geliyor | Teslimat sonrası bildirim ve işleme gecikmesi olabilir. | Kullanıcı görünürlüğü ile karar zamanını karşılaştırın. |
| Kapsam dışı kutu hâlâ okunabiliyor | Paralel geniş yetki ataması kalmış olabilir. | Entra izinleriyle Application RBAC kapsamının toplam etkisini test edin. |
Kabul ve doğrulama kontrolleri
- İstenen her API yetkisini somut özelliğe bağlayın.
- İçerik, ek ve paylaşılan kutu kapsamını doğrulayın.
- Teslimat ve inceleme zamanlarını ayrı ölçün.
- Abonelik bitişi, kota ve telafi akışını deneyin.
- Kapsam dışındaki posta kutusuna erişimin reddedildiğini kanıtlayın.
- API ile SMTP katmanlarının hangi akışları kapsadığını belgeleyin.
İlgili kavramlar
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.
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.
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.
Yüksek erişilebilirlik ile kurtarma ayrımı
Yüksek erişilebilirlik, belirli arızalarda hizmetin kısa kesintiyle sürmesini hedefler; yedekleme, kaybolan veya bozulan veriyi önceki bir noktadan geri getirir. Bir küme yanlış silinen kaydı diğer düğüme de aktarabilir. Bu nedenle HA ve yedekleme birbirinin yerine geçmez. Hizmetin DNS, kimlik, ağ, depolama ve enerji bağımlılıklarını birlikte düşünün. Başarılı düğüm geçişi tek başına yeterli değildir: kullanıcı oturumunun, uygulama yazmasının ve dış entegrasyonların geçiş sonrası davranışı da ölçülmelidir.
Birincil teknik dokümantasyon
Bulut e-posta güvenliği ve sürekliliğini değerlendirin
Doz Teknoloji tarafından işletilen SecuraWall MailFlow ile bulut e-posta güvenliği ve Backup MX seçeneklerini inceleyin. Kurulum gereksinimlerini mevcut posta altyapınıza göre değerlendirin.
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.