E-posta Şifreleme: TLS, S/MIME ve Uçtan Uca Koruma

E-posta şifreleme, bir iletinin yolculuğu boyunca içeriğini yalnızca yetkili tarafların okuyabilmesini sağlayan teknik önlemlerin bütünüdür. Tek bir anahtar ya da ayar yoktur: e-posta önce cihazınızdan kendi sunucunuza, oradan alıcının sunucusuna gider, sonra alıcının kutusunda bekler. Her durak ayrı bir risk taşır ve her biri farklı bir yöntemle korunur.

Çoğu işletme için doğru başlangıç, aktarım şifrelemesini eksiksiz yapmak ve gerçekten gizli yazışmalar için uçtan uca şifrelemeyi seçili kişilerde devreye almaktır. Bu katmanların bir kısmı kurumsal mail altyapısında sağlayıcı tarafından, bir kısmı ise sizin alan adınızda ve cihazlarınızda yapılandırılır.

E-posta şifreleme hangi katmanlarda yapılır?

E-posta şifreleme üç katmanda yapılır: aktarım (iletinin ağda taşınması), depolama (sunucuda bekleyen posta) ve içerik (iletinin kendisi). Her katman farklı bir saldırgana karşı koruma sağlar:

Önemli bir ayrım: TLS ve depolama şifrelemesi açıkken bile ileti, sağlayıcının sunucusunda işlenirken okunabilir durumdadır. İçeriği sağlayıcıdan da gizlemenin tek yolu uçtan uca şifrelemedir.

STARTTLS ile SSL/TLS portları arasındaki fark nedir?

İkisi de aktarımı TLS ile şifreler; fark, şifrelemenin ne zaman başladığıdır. Örtük TLS (implicit TLS) kullanan portlarda bağlantı ilk andan itibaren şifrelidir; STARTTLS’de ise bağlantı düz metin açılır ve istemci STARTTLS komutuyla şifrelemeye geçer.

E-posta programınızda iki seçenekten birini kullanın; önemli olan şifrelemenin zorunlu olmasıdır. STARTTLS seçiliyse istemcinin “şifreleme yoksa bağlanma” davranışında olduğundan emin olun; “varsa kullan” (opportunistic) ayarı, araya giren biri tarafından şifrelemesiz bağlantıya düşürülebilir. Şifresiz 25, 143 ya da 110 bağlantısında şifreniz ağda açık metin olarak gider. Outlook’ta doğru seçimin nasıl yapıldığı kurumsal mail Outlook ayarları rehberinde gösterilir.

MTA-STS ve TLS-RPT ne işe yarar?

MTA-STS (Mail Transfer Agent Strict Transport Security), alan adınıza e-posta gönderen sunuculara “bana yalnızca geçerli sertifikalı TLS ile teslim et” talimatı verir; TLS-RPT ise bu bağlantılarda yaşanan sorunları size rapor olarak gönderir. Sunucular arasındaki aktarım varsayılan olarak fırsatçıdır: karşı taraf STARTTLS sunmazsa ileti şifresiz gider. MTA-STS bu açığı kapatır.

Kurulum iki DNS kaydı ve bir ilke dosyasından oluşur:

_mta-sts.alanadiniz.com.  TXT  "v=STSv1; id=20261024"
_smtp._tls.alanadiniz.com. TXT  "v=TLSRPTv1; rua=mailto:[email protected]"

# https://mta-sts.alanadiniz.com/.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: mail.alanadiniz.com
max_age: 86400

1. İlke dosyasını HTTPS ile yayımlanan mta-sts alt alan adında sunun; mx satırlarına MX kayıtlarınızdaki sunucu adlarını yazın.
2. mode: testing ile başlayın ve TLS-RPT raporlarını birkaç hafta izleyin.
3. Hata görmüyorsanız mode: enforce değerine geçin, max_age süresini uzatın ve TXT kaydındaki id değerini değiştirin.

Alternatif olarak DNSSEC etkin alan adlarında DANE kullanılabilir; destek alıcı sunucuya göre değişir.

Sunucuda bekleyen e-postalar şifrelenir mi?

Depolamada şifreleme (encryption at rest) sağlayıcının altyapı tercihidir; disk ya da birim düzeyinde uygulandığında çalınan bir disk ya da sızan bir yedek dosyası okunamaz hâle gelir. Ancak sunucu çalışırken postalar e-posta yazılımı tarafından okunabilir durumdadır, çünkü sizin webmail’de görebilmeniz için çözülmeleri gerekir.

Bu nedenle depolama şifrelemesi fiziksel ve yedek kaynaklı riskleri azaltır, sağlayıcı tarafında yetkili erişime karşı ise koruma sağlamaz. Bir sağlayıcıyı değerlendirirken şu soruları sorun:

• Posta depolama alanı ve yedekler şifreli mi?
• Yedekler nerede tutuluyor ve kimler erişebiliyor?
• Yönetici erişimleri kayıt altına alınıyor mu?
• Hesabınızda iki adımlı doğrulama kullanılabiliyor mu?

Veri merkezinin fiziksel güvenliği de bu katmanın parçasıdır; LIONFIN veri merkezimiz 7/24 NOC ve SOC ekiplerince izlenir. LIONFIN’in kendi e-posta platformu xMail ise hesap güvenliği için iki adımlı doğrulama sunar.

S/MIME ve PGP ile uçtan uca şifreleme nasıl çalışır?

S/MIME ve PGP (OpenPGP), iletiyi alıcının açık anahtarıyla şifreler; ileti yalnızca alıcının özel anahtarıyla açılabildiği için yol boyunca ve sunucularda okunamaz. İkisi de ayrıca dijital imza sunar; imza, iletinin size ait olduğunu ve yolda değiştirilmediğini kanıtlar.

• S/MIME: Bir sertifika otoritesinden alınan X.509 e-posta sertifikasıyla çalışır. Outlook, Apple Mail ve iOS gibi yaygın istemcilerde yerleşik destek bulunur; kurumsal ortamlarda merkezi yönetimi daha kolaydır.
• PGP: Anahtar çiftini kullanıcı kendisi üretir; güven, anahtarların doğrulanmasına dayanır. Thunderbird’ün güncel sürümleri OpenPGP desteğini yerleşik sunar; bazı istemcilerde eklenti gerekir.

Pratik sınırlamaları bilmek gerekir: şifreli ileti gönderebilmek için alıcının açık anahtarına ya da sertifikasına önceden sahip olmanız gerekir; alıcı aynı yöntemi kullanmıyorsa iletiyi açamaz. Gönderen, alıcı ve tarih gibi başlıklar şifrelenmez, çoğu uygulamada konu satırı da açık kalır. Bu yüzden e-posta şifreleme kurarken uçtan uca yöntemi genellikle hukuk, finans ve insan kaynakları gibi gizli yazışma yapan ekiplerle sınırlı başlatmak daha uygulanabilir olur.

SPF, DKIM ve DMARC şifreleme sayılır mı?

Hayır; SPF, DKIM ve DMARC kimlik doğrulama mekanizmalarıdır, iletinin içeriğini gizlemezler. Görevleri, alıcı sunucunun “bu ileti gerçekten bu alan adından mı geldi ve yolda değiştirildi mi?” sorusunu yanıtlamasını sağlamaktır. DKIM bir dijital imza kullansa da bu imza içeriği şifrelemez; herkes iletiyi okuyabilir, yalnızca değiştirildiğini fark edebilir.

Şifreleme ve kimlik doğrulama birbirini tamamlar: şifreleme okunmayı, kimlik doğrulama ise sahte gönderimi ve oltalama saldırılarını zorlaştırır. İkisinden biri eksikse koruma yarım kalır. Kayıtların kurulumu ayrı rehberlerde anlatılır: SPF kaydı nasıl eklenir, DKIM kaydı nasıl eklenir ve DMARC kaydı nasıl eklenir. Hesap, alan adı ve kullanıcı katmanlarını birlikte ele alan genel bir yol haritası için e-posta güvenliği rehberi yazısına bakabilirsiniz.