Kurumsal e-posta güvenliği tartışması çoğunlukla spam filtrelerine ve antivirüs yazılımlarına indirgeniyor. Oysa yukarıdaki senaryonun gerçekleşmesi için ne virüse ne de zararlı bir bağlantıya ihtiyaç var. Tek ihtiyaç duyulan sadece bir alan adı taklidi ve teyit edilmemiş bir talimat. İş yerinde e-posta güvenliğini sağlamak, birbirinden bağımsız üç katmanı aynı anda işler durumda tutmak demektir. Alan adı kimlik doğrulaması, hesap erişim güvenliği ve kullanıcı alışkanlıkları. Bunlardan biri eksik olduğunda diğer ikisi yeterli olmaz. Son iki katman uygulamada iç içe geçtiği için bu yazıda tek başlık altında ele alınıyor.
-
-
Kurumsal e-postayı hedef alan saldırılar neye benziyor
-
Uygulamada en sık karşılaşılan dört saldırı tipi var.
Kimlik bilgisi toplama (phishing): Sahte bir e-posta giriş ekranı gönderilir. Kullanıcı parolasını buraya yazar. Ekran genellikle gerçek giriş ekranının bir kopyasıdır ve “posta kutunuz doldu, doğrulayın” gibi zaman baskısı yaratan bir ifadeyle sunulur.
Sahte ödeme talimatı: Giriş bölümündeki senaryo budur. Saldırgan, yöneticinin ya da tedarikçinin adını kullanır. Teknik bir açıktan çok, taraflar arasındaki güven ve yetki ilişkisini istismar eder.
Zararlı ek ve bağlantı: Fatura, kargo bildirimi veya CV görünümlü dosyalar fidye yazılımı taşır. Makro içeren ofis belgeleri ve sıkıştırılmış arşivler en sık kullanılan biçimlerdir.
Ele geçirilmiş hesaptan gönderim: En zoru budur çünkü ileti gerçekten şirketin kendi e-posta adresinden gönderilir. Filtreler onu meşru sayar hâliyle alıcılar da şüphelenmez.
Kurumsal e-posta güvenliği nasıl sağlanır: 7 adımlık uygulama sırası
Yukarıdaki saldırı tiplerinin her birine karşılık gelen bir önlem var. Ancak bu önlemlerin hepsini aynı anda devreye almak çoğu şirket için mümkün olmuyor. Sıralama bu noktada önem kazanıyor, çünkü bazı adımlar diğerlerinin ön koşulu. DMARC politikasını sertleştirmeden önce SPF ve DKIM'in kurulu olması, yönlendirme kurallarını denetlemeden önce hesaplara erişimin güvence altına alınmış olması gerekir.
Aşağıdaki sıra, etkisi en yüksek ve uygulaması en hızlı adımdan başlayarak ilerler. Her adımın yanında, o adımın gerçekten tamamlandığını gösteren ölçütü de bulacaksınız. "Kurduk" demek ile "çalışıyor" demek arasındaki farkı bu ölçütler kapatır.
|
# |
Adım |
Tamamlandı kriteri |
|
1 |
Tüm hesaplarda çok faktörlü doğrulamayı zorunlu kılın |
Yönetici panelinde çok faktörlü doğrulama kaydı olmayan hesap sayısı sıfır |
|
2 |
SPF kaydını yayınlayın, meşru gönderim kaynaklarını listeleyin |
Alan adında tek bir SPF kaydı var ve 10 DNS sorgusu sınırı aşılmıyor |
|
3 |
DKIM imzalamayı tüm gönderim kaynaklarında açın |
Test iletisinin başlığında dkim=pass sonucu görünüyor |
|
4 |
DMARC kaydını p=none ve raporlama adresiyle kurun |
14 gün boyunca kesintisiz rapor akışı alınıyor |
|
5 |
Raporlar temizlendiğinde politikayı quarantine, ardından reject değerine taşıyın |
Meşru trafiğin yüzde 98'inden fazlası doğrulamayı geçiyor |
|
6 |
Eski kimlik doğrulama yöntemlerini kapatın, yönlendirme kurallarını denetleyin |
POP3 ve IMAP üzerinde eski kimlik doğrulama kapalı, tanımsız dış yönlendirme kuralı yok |
|
7 |
Ödeme talimatı teyit kuralını yazılı hâle getirin ve duyurun |
Kural bir dokümanda tanımlı ve işe yeni başlayanlara ilk hafta içinde anlatılıyor |
Sıradaki bölüm 2 ile 5 arasındaki adımları, onu izleyen bölüm ise 1, 6 ve 7. adımları ayrıntılandırıyor.
-
-
Alan Adı Kimlik Doğrulaması: SPF, DKIM ve DMARC Kayıtları
-
İlk üç saldırı tipinin ortak noktası, şirketin alan adının izinsiz kullanılabilmesidir. Bunu önlemeye yönelik temel mekanizmalar üç DNS kaydı üzerinden yapılandırılır.
|
Kayıt |
Ne yapar |
Eksik olduğunda |
|
SPF |
Alan adı üzerinden hangi sunucuların gönderim yapabileceğini belirtir. |
Herkes sizin adınıza ileti gönderebilir. |
|
DKIM |
İletiyi dijital olarak imzalar ve iletinin aktarım sırasında değiştirilip değiştirilmediğinin doğrulanmasını sağlar. |
İçeriğin bütünlüğü doğrulanamaz. |
|
DMARC |
SPF ve DKIM doğrulaması başarısız olduğunda alıcı sistemin nasıl davranacağını belirler ve raporlama yapılmasını sağlar. |
İki kayıt da kurulu olsa bile taklit iletiler teslim edilmeye devam eder. |
Üç kayıt da DNS üzerinde TXT kaydı olarak tanımlanır. Temel biçimleri şu şekildedir:
SPF v=spf1 include:_spf.saglayici.com -all
DKIM selector._domainkey.alanadi.com (TXT, sağlayıcı üretir)
DMARC v=DMARC1; p=none; rua=mailto:[email protected]
Üçünün de tanımlı olması tek başına yeterli olmaz. DMARC kaydındaki politika değeri belirleyicidir. p=none yalnızca rapor toplar ve hiçbir iletiyi durdurmaz. Çoğu şirket yıllarca bu ayarda kalıyor ve sisteminin kendisini koruduğunu düşünüyor.
Doğru yöntem, politikayı en az 14 gün p=none değerinde tutarak rapor toplamak ve bu süre içinde meşru gönderim kaynaklarınızı (muhasebe yazılımı, e-ticaret altyapısı, pazarlama aracı) tespit etmektir. Raporlarda meşru trafiğin yüzde 98'inden fazlası doğrulamayı geçmeye başladığında politika quarantine değerine taşınabilir. Bu değerde 30 gün sorunsuz ilerlendiğinde sıra reject değerine gelir.
Geçişi tek adımda yapmak zorunda değilsiniz. DMARC kaydındaki t etiketi, politikanın bir kademe yumuşak uygulanmasını talep eder: p=quarantine; t=y kaydında iletiler p=none gibi işlenir, p=reject; t=y kaydında ise p=quarantine gibi. Bu sayede yeni politika, gözden kaçan bir gönderim kaynağı varsa yazışmaları durdurmadan önce raporlarda görünür hâle gelir. Kademeli yol şu şekilde işler: p=quarantine; t=y → p=quarantine → p=reject; t=y → p=reject. Her aşamada bir ila iki haftalık gözlem yeterlidir.
Kayıtlarınızda pct, rf veya ri etiketleri varsa bunlar artık geçerli değildir. Herhangi bir şeyi bozmazlar, alıcı sistemler tanımadıkları etiketleri yok sayar; yine de bir sonraki DNS düzenlemesinde temizlenmeleri gerekir.
DMARC kaydının söz dizimi RFC 9989, raporlama biçimi ise RFC 9990 ve RFC 9991 belgelerinde tanımlıdır. SPF için RFC 7208, DKIM için RFC 6376 geçerlidir.
-
-
Hesap Erişimi ve Çalışan Alışkanlıkları
-
Alan adı korunsa bile bir e-posta hesabının parolası ele geçirildiğinde önceki güvenlik katmanı işlevsiz kalır. Bu katmanda yedi başlık öne çıkıyor.
Çok Faktörlü Doğrulama: Parola sızsa bile ikinci adım olmadan giriş yapılamaz. Tek başına en yüksek etkiye sahip önlem budur ve çoğu sağlayıcıda ek bir maliyet getirmez.
Eski Kimlik Doğrulama Yöntemleri: POP3 ve IMAP bağlantılarında eski kimlik doğrulama yöntemleri kullanılıyorsa bunlar çok faktörlü doğrulamanın kapsamı dışında kalabilir. Kullanılmıyorlarsa kapatılmalı, kullanılıyorsa uygulama parolalarıyla sınırlandırılmalıdır.
Dış Gönderici Etiketi: Alan adınızın dışından gelen iletilerin üstüne otomatik olarak bir uyarı bandı eklenir. Giriş bölümündeki senaryoyu hatırlayın: gönderen adresindeki alan adında tek bir harf fazlaydı ve kimse fark etmemişti. Tedarikçi görünümlü bir ileti, gerçekte dış bir alan adından geldiğini kendi üzerinde ilan ettiğinde, kimsenin gönderen adresini karakter karakter okumasına gerek kalmaz. Kurulumu birkaç dakika süren bu ayar, alan adı taklidini görünür kılan tek teknik önlemdir.
İşten Ayrılan Çalışanların Hesapları: Hesap silinmeden önce parola değiştirilir, açık oturumlar sonlandırılır ve gelen iletiler yetkili bir kişiye yönlendirilir. Hesap bir kez silindiğinde hesaba ait arşivi geri getirmenin yolu kalmayabilir.
Yönlendirme Kuralları: Bir hesabı ele geçiren saldırganın ilk işi, genellikle tüm iletileri dışarıya kopyalayan sessiz bir yönlendirme kuralı eklemektir. Yönetici panelinden bu kuralların düzenli olarak gözden geçirilmesi, aylarca fark edilmeyen sızıntıları ortaya çıkarır.
Tehlikeli Ek Uzantıları: Makro içeren ofis belgeleri ve parola korumalı arşivler, tarama yapan katmanların içeriği açamadığı biçimlerdir. Fidye yazılımı taşıyan iletilerde en sık bu iki biçim kullanılır. Yönetici panelinden bu uzantıların kurum genelinde engellenmesi, kullanıcıdan hiçbir şey beklemeden bütün bir saldırı tipini devre dışı bırakır. Bu dosyaların iş akışında gerçekten gerekli olduğu birimler varsa engel, kurum geneli yerine yalnızca o birimler için gevşetilir.
Talimat Teyidi: Teknik önlemlerin tamamı kurulu olsa bile, giriş bölümündeki IBAN senaryosunu yazılım değil, bir kural durdurur. Ödeme bilgisi değişikliği veya olağan dışı bir aktarım talebi, daha önceden kayıtlı bir telefon numarası aranarak doğrulanır. Bu kuralın yazılı hâle getirilmesi ve işe yeni başlayan çalışanlara ilk hafta içinde anlatılması, bu tür yüksek maliyetli saldırıların önlenmesinde önemli bir rol oynar.
-
-
Sağlayıcıdan Ne Beklenmeli?
-
Yukarıdaki önlemlerin bir kısmı şirketin sorumluluğundayken bir kısmı altyapıyı işleten sağlayıcının sorumluluğundadır. Sağlayıcı seçerken sorulacak soruların teknik olması gerek yoktur.
-
Kimlik doğrulama kayıtlarını kim yapılandırıyor?
-
Karantinaya alınan iletileri yönetici görebiliyor mu?
-
Sunucular arasındaki trafik şifreleniyor mu?
-
Arşiv ne kadar süre saklanıyor ve veriler hangi ülkede barındırılıyor?
Barındırma paketlerine dâhil olarak sunulan posta hizmetlerinde bu soruların çoğuna açık ve yeterli bir yanıt alınamayabiliyor. Buna karşılık sağlayıcı tarafında yönetilen bir e-posta altyapısı tercih edildiğinde antispam ve antivirüs katmanları, e-posta ağ geçidi ve kimlik doğrulama kayıtlarının yapılandırılması hizmet kapsamında sunuluyor. Türkiye'deki veri merkezlerini kullanan kurumsal e-posta sağlayıcısı ProMail ile çalışan firmalar için veriler yurt dışına aktarılmadığından ötürü aktarımdan doğan ek yükümlülükler de gündeme gelmiyor. Hiçbir sağlayıcının alıcı taraftaki filtreleme sonucunu garanti edemeyeceğini de eklemek gerekir. Asıl mesele hangi güvenlik mekanizmalarının devrede olduğudur.
-
-
Bir hesabın ele geçirildiği anlaşıldığında ilk bir saat içinde ne yapılmalı?
-
Hazırlık kadar müdahale süreci de önceden planlanmalıdır. Sıralama şu şekilde işler:
-
Hesabın parolasını değiştirin ve tüm aktif oturumları sonlandırın.
-
Yönlendirme kurallarını, imzayı ve otomatik cevaplama ayarlarını kontrol edin; saldırganın eklediklerini silin.
-
Gönderilmiş öğeler klasörünü inceleyerek kimlere ileti gittiğini listeleyin.
-
Aynı parolanın kullanıldığı diğer sistemleri belirleyin ve bu sistemlerdeki parolaları da değiştirin.
-
Saldırganın e-posta gönderdiği müşteri ve tedarikçileri telefonla uyarın.
-
İhlal kişisel veri içeriyorsa bildirim yükümlülüğünü değerlendirin.
Son madde çoğu şirketin gözünden kaçıyor. Kişisel Verileri Koruma Kurulunun 24 Ocak 2019 tarihli kararı, veri sorumlusunun ihlali öğrendiği andan itibaren en geç 72 saat içinde Kurula bildirimde bulunmasını öngörür. Süre ihlalin gerçekleştiği tarihten değil, öğrenildiği tarihten başlar.





