Neden “least privilege” (en az yetki) kurumsal e-postada kritiktir?
Kurumsal e-posta hesapları; teklif, fatura, müşteri yazışmaları, sözleşme ekleri ve erişim bağlantıları gibi yüksek değerli içerikler taşır. Bu nedenle e-posta yetkilendirmesi “kim kime, ne kadar ve ne kadar süreyle erişecek?” sorularına net cevaplar vermelidir. En az yetki prensibi, bir kişinin işini yapması için gerekli minimum erişimi vermeyi hedefler. Böylece hem hata riski hem de kötüye kullanım etkisi sınırlanır.
Pratikte en yaygın sorun şudur: Bir işi hızlandırmak için fazla yetki verilir (örneğin tüm posta kutusuna tam erişim) ve bu yetki daha sonra geri alınmaz. Zamanla hesaplar, ekipler değişir; eski yetkiler unutulur ve kurumun saldırı yüzeyi büyür. Doğru model seçimi, düzenli gözden geçirme ve kayıt altına alma ile bu riskler azaltılabilir.
Temel erişim modelleri: Aynı amaç için farklı araçlar
Kurumsal e-posta altyapılarında sık görülen erişim modelleri genelde şu kavramların etrafında şekillenir: shared mailbox (paylaşımlı posta kutusu), delegasyon (tam erişim veya belirli yetkiler), “Send As”, “Send on Behalf”, forwarding (yönlendirme) ve klasör paylaşımı. Bu kavramlar benzer görünse de güvenlik, izlenebilirlik ve iş akışı açısından farklı sonuçlar doğurur.
Shared mailbox (paylaşımlı posta kutusu) ne zaman doğru seçimdir?
Shared mailbox genellikle bir kişinin değil bir ekibin sahip olduğu adresler için uygundur: destek, satış, muhasebe gibi. Burada amaç, gelen kutusunun bir kişiyle “özdeşleşmemesi” ve iş sürekliliğinin ekip üzerinden yürümesidir. Shared yapı, çalışan ayrılışlarında “kimin kutusu?” tartışmasını azaltır ve erişim yönetimini ekip üyeliği üzerinden daha düzenli hale getirebilir.
Ancak shared mailbox kullanırken de en az yetki geçerlidir. Her ekip üyesinin her klasöre erişmesi gerekmeyebilir. Örneğin muhasebe@ adresinde tahsilat, tedarikçi, bordro gibi ayrışmış klasörler varsa, bordro içeriğine yalnızca belirli kişiler erişmelidir.
Delegation (delegasyon) ve tam erişim ne zaman gerekir?
Delegasyon, bir kullanıcının başka bir kullanıcının posta kutusuna erişim yetkisi almasıdır. En riskli ve aynı zamanda en güçlü senaryo “tam erişim”dir; çünkü yetki verilen kişi, posta kutusundaki çok geniş içeriklere ulaşabilir. Tam erişim, yalnızca net gerekçe varsa ve süre/çerçeve belirlenerek verildiğinde anlamlıdır: yönetici asistanının ajanda ve yazışmaları yönetmesi, geçici izin döneminde kritik bir rolün devralınması gibi.
Delegasyon verirken şu soruları sormak gerekir: Gerçekten tüm posta kutusuna mı ihtiyaç var, yoksa belirli klasörlere mi? Gönderim yetkisi gerekiyor mu? Yetki kalıcı mı, süreli mi? Süreli yetkiler için bir bitiş tarihi ve geri alma planı mutlaka tanımlanmalıdır.
“Send As” ile “Send on Behalf” arasındaki fark
Bu iki gönderim modeli, e-postanın alıcı tarafında “gönderenin kim göründüğünü” belirler ve yanlış seçildiğinde hem iç kontrol hem de müşteri iletişimi açısından sorun çıkarabilir.
- Send As: Mesaj, doğrudan yetki verilen adres adına gönderilmiş gibi görünür. Örneğin ekip üyesi, destek@ adına yanıtlar ve alıcı “gönderen” alanında destek@ görür.
- Send on Behalf: Mesaj, “X adına Y gönderdi” mantığıyla görünür. Bu, şeffaflık ve iç kontrol açısından bazı kurumlarda tercih edilir. Müşteri iletişiminde ise kimi zaman gereksiz karmaşa yaratabilir.
En az yetki açısından bakıldığında; bir kişinin sadece temsil yetkisine ihtiyacı varsa “Send As/On Behalf” düşünülebilir, fakat bunun yanında gereksiz “tam erişim” vermek çoğu zaman fazladır. Gönderim yetkisi ile okuma/erişim yetkisi birbirinden ayrı ele alınmalıdır.
Klasör paylaşımı: Tüm posta kutusunu açmadan iş yürütmek
Bazen ihtiyaç, bir posta kutusunun tamamını paylaşmak değil, yalnızca belirli klasörlerde iş yapmaktır. Örneğin yönetici; “Sözleşmeler” klasörünü hukuk ekibiyle, “Seyahat” klasörünü asistanla paylaşmak isteyebilir. Klasör bazlı paylaşım, en az yetki prensibine çok uygundur; çünkü erişim kapsamını daraltır.
Bu modelin zayıf tarafı operasyonel karmaşıklıktır: Klasör yapısı değiştikçe yetkiler güncellenmelidir. Bu nedenle klasör paylaşımı uygulanacaksa standart bir klasör mimarisi ve sahiplik kuralları belirlemek iş yükünü azaltır.
Yönlendirme (forwarding) neden “erişim modeli” değildir?
Forwarding, çoğu zaman “birine erişim verelim” yerine hızlı çözüm gibi görülür. Oysa yönlendirme, hem teslim edilebilirlik ve kimlik doğrulama zincirlerinde teknik yan etkilere neden olabilir hem de verinin kontrolsüz çoğalmasına yol açar. Kurumsal kontrol açısından en kritik sorun ise şudur: Yazışmaların kurumsal posta kutusu dışında başka kutulara (kişisel hesaplar dahil) akması, veri sınıflandırması ve saklama disiplinini zorlaştırır.
Bu nedenle forwarding, bir ekip erişim çözümünden çok istisnai bir taşıma/aktarım mekanizması olarak düşünülmelidir. Erişim ihtiyacında shared mailbox, delegasyon veya klasör paylaşımı gibi daha kontrollü yöntemler tercih edilir.
Senaryo bazlı doğru model seçimi
1) support@ gibi ekip adresi
- Öneri: Shared mailbox veya ekip tabanlı yapı.
- Gönderim: Genellikle “Send As” (müşteri deneyimi için).
- Ek kontrol: Kimin hangi bileti yanıtladığını takip etmek için süreç kuralı (konu etiketi, kategori, not vb.).
2) Yönetici asistanı erişimi
- Öneri: Önce klasör ve takvim bazlı paylaşım; yetmezse süreli delegasyon.
- Gönderim: Kurum kültürüne göre “Send on Behalf” şeffaflık için uygun olabilir.
- Güvenlik: Yetki kapsamı ve süre net olmalı, düzenli gözden geçirilmeli.
3) Muhasebe süreçleri (fatura@, tahsilat@)
- Öneri: Shared mailbox, fakat klasör ayrımı ve rol bazlı erişim.
- Gönderim: “Send As” sık kullanılır; içerik erişimi sınırlanmalıdır.
- Risk: Hassas ekler için ayrı klasör ve sınırlı erişim.
4) Çalışan ayrılışı ve devir
Çalışan ayrıldığında ilk refleks bazen “her şeyi yönlendir” olur. Daha güvenli yaklaşım; posta kutusunu kilitlemek, erişimi kontrollü bir şekilde devretmek ve gerekli iletişim kanallarını rol bazlı adreslere taşımaktır. Devir süresince kimin hangi yetkiyle eriştiği kayıt altına alınmalı, süreç bitince yetkiler geri alınmalıdır.
Yetkilendirme yönetimi için pratik kontrol listesi
- İş gerekçesi: Yetki neden veriliyor? Hangi işi mümkün kılıyor?
- Kapsam: Tam posta kutusu mu, klasör mü, sadece gönderim mi?
- Süre: Bitiş tarihi var mı? Yoksa neden kalıcı?
- Onay: Yetki kim tarafından talep edildi, kim onayladı?
- Gözden geçirme: Belirli aralıklarla (ör. üç ayda bir) yetki listesi kontrol ediliyor mu?
- Ayrılış senaryosu: Kullanıcı işten ayrıldığında bu yetki otomatik/manuel nasıl kaldırılacak?
En sık yapılan hatalar ve nasıl önlenir?
“Herkese tam erişim verelim, sonra bakarız” yaklaşımı
Bu yaklaşım genellikle kalıcı hale gelir. Alternatif olarak önce en dar model (klasör paylaşımı veya sadece gönderim) ile başlayıp, gerçekten ihtiyaç ortaya çıkarsa genişletmek daha doğru bir güvenlik pratiğidir.
Gönderim yetkisi ile okuma yetkisini karıştırmak
Bir kişinin bir adres adına e-posta göndermesi gerekebilir, fakat geçmiş yazışmaların tamamını görmesi gerekmeyebilir. Gönderim ve okuma yetkileri mümkün olduğunca ayrı tasarlanmalıdır.
Rol bazlı adresleri kişiye bağlamak
info@, sales@ gibi adresler bir kişiye bağlı yürütülürse o kişi izne çıktığında veya ayrıldığında süreç kilitlenir. Rol bazlı adreslerin ekip süreçlerine bağlanması süreklilik sağlar.
Sonuç: Daha güvenli, daha yönetilebilir bir e-posta organizasyonu
Kurumsal e-postada doğru yetkilendirme modeli; yalnızca güvenliği artırmakla kalmaz, aynı zamanda iş sürekliliğini ve ekip verimliliğini de yükseltir. Shared mailbox, delegasyon, Send As/Send on Behalf ve klasör paylaşımı arasındaki farkları netleştirip en az yetki prensibiyle uyguladığınızda, hem denetim hem de operasyon tarafında daha sürdürülebilir bir yapı oluşur.
Kuruluşunuz MX1Mail gibi profesyonel bir e-posta platformu kullanıyorsa, yetki ve erişim ihtiyaçlarını belirlerken önce organizasyonel modeli (rol adresleri, ekip posta kutuları, devir süreçleri) netleştirmek; ardından erişimi kapsam/süre/onay ilkeleriyle standartlaştırmak iyi bir başlangıç olacaktır.