E-posta Şifreleme Seçenekleri: TLS, MTA-STS, S/MIME ve OME

Denetçi “e-postalarınız şifreli mi?” diye sorduğunda çoğu ekip “evet, TLS var” der. Cevap eksiktir. Sunucular arasındaki TLS bağlantısı iletinin sunucuda ve alıcının posta kutusunda açık durmasını engellemez; uçtan uca şifreleme ise taramayı ve arşivlemeyi zorlaştırır. Bu rehber fırsatçı TLS, MTA-STS ve TLS-RPT, S/MIME ve Microsoft Purview Message Encryption seçeneklerini, hangi senaryoda hangisinin seçileceğine karar verdirecek şekilde karşılaştırıyor.

Aktarım ve içerik şifrelemesi farkı

E-posta şifrelemesi iki ayrı katmanda düşünülür:

• Aktarım şifrelemesi: İleti bir sunucudan diğerine giderken şifrelenir (SMTP üzerinde STARTTLS). Her sunucu iletiyi açık olarak alır, işler ve bir sonrakine yeniden şifreli bağlantıyla gönderir. Ağı dinleyen saldırgana karşı korur; sunucu yöneticisine, ele geçirilmiş posta kutusuna veya yanlış alıcıya karşı korumaz.
• İçerik şifrelemesi: İletinin kendisi şifrelenir (S/MIME, OME). İleti posta kutusunda da şifreli kalır ve yalnızca yetkili alıcı açabilir. Bazı çözümlerde iletme, yazdırma veya kopyalama gibi kullanım hakları da kısıtlanabilir.

Uyum gereksinimlerini ve kurumsal siber güvenlik politikalarını yorumlarken bu ayrım belirleyicidir. Politika “kişisel veri içeren e-postalar şifreli gönderilir” diyorsa ve elinizde yalnızca TLS varsa, ileti alıcı tarafın saklama ortamında açık duruyor demektir. Bekleyen ve aktarılan veride şifreleme kontrollerinin genel çerçevesi şifreleme kontrolleri uygulama rehberinde.

Fırsatçı TLS ve sınırları

SMTP’de TLS varsayılan olarak fırsatçıdır (RFC 3207): karşı sunucu EHLO yanıtında STARTTLS yeteneğini bildirirse gönderen şifreli bağlantıya geçer, bildirmezse iletiyi açık metin gönderir. Kimse uyarılmaz. Üç temel zayıflık vardır:

1. Düşürme saldırısı: Yoldaki bir saldırgan EHLO yanıtından STARTTLS satırını silerse gönderen sunucu sessizce açık metne düşer.
2. Sertifika doğrulanmaz: Fırsatçı modda sunucular genellikle sertifikanın geçerliliğine ve ad eşleşmesine bakmaz; araya giren biri kendi sertifikasını sunabilir.
3. MX kaydı doğrulanmaz: DNS yanıtı değiştirilerek ileti saldırganın sunucusuna yönlendirilebilir.

Bu açıkları kapatan iki standart yol var: DNSSEC’e dayanan DANE (RFC 7672) ve HTTPS üzerinden yayımlanan politikaya dayanan MTA-STS (RFC 8461). DANE hem alan adınızda hem MX sunucularınızın alan adında DNSSEC ister. DNSSEC kullanmayan kurumlar için MTA-STS daha erişilebilir bir başlangıçtır. Kullandığınız bulut posta hizmetinin DANE desteğini üreticinin güncel dokümantasyonundan doğrulayın.

MTA-STS ve TLS-RPT yapılandırması

MTA-STS, alan adınıza e-posta gönderen sunuculara şunu söyler: “Bu alan adına yalnızca şu MX’lere, geçerli sertifikalı TLS ile teslim et.” Üç bileşeni var.

1. DNS kaydı. Politikanın varlığını ve sürümünü bildirir. Politika dosyası her değiştiğinde id değeri de güncellenmelidir; gönderenler önbelleği bu değere bakarak yeniler. Sahada en sık atlanan adım budur.

_mta-sts.example.com.  IN  TXT  "v=STSv1; id=20261110T090000;"

2. Politika dosyası. https://mta-sts.example.com/.well-known/mta-sts.txt adresinde, geçerli ve herkese açık bir CA tarafından imzalanmış sertifikayla yayımlanır:

version: STSv1
mode: testing
mx: mail.example.com
mx: *.mail.protection.outlook.com
max_age: 604800

mx satırları MX kayıtlarınızdaki adlarla eşleşmelidir; joker karakter yalnızca en soldaki etikette kullanılabilir. Örnekteki Exchange Online deseni yaygındır, ama MX kaydınızın güncel adını kendi kiracınızdan doğrulayın. max_age saniye cinsindendir; RFC 8461 en fazla 31557600 (yaklaşık bir yıl) değerine izin verir. mode değerleri testing, enforce ve none’dır.

3. TLS-RPT kaydı. RFC 8460’taki raporlama mekanizmasıdır; gönderen sunucular size teslimat sırasında yaşadıkları TLS ve politika hatalarını JSON raporlarla bildirir:

_smtp._tls.example.com.  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-rapor@example.com"

Uygulama sırası: TLS-RPT’yi yayımlayın, politikayı testing modunda başlatın, raporlarda sertifika adı uyuşmazlığı veya listede olmayan MX hatası kalmayınca enforce moduna geçin ve id değerini güncelleyin. MX sağlayıcısı değişirken sıra ters çevrilmez: önce politika dosyasına yeni MX eklenir, sonra DNS değişir. Tersini yaparsanız politikayı önbelleğe almış gönderenler yeni sunucuya teslimi reddeder. Posta gelmez.

MTA-STS gelen yönü korur. Belirli bir iş ortağına giden e-postada zorunlu ve doğrulanmış TLS istiyorsanız tanım gönderen tarafta yapılır. Exchange Online’da bu, iş ortağı alan adı için bir giden bağlayıcıyla kurulabilir:

New-OutboundConnector -Name "Partner zorunlu TLS" -ConnectorType Partner `
  -RecipientDomains partner.example -UseMXRecord $true `
  -TlsSettings DomainValidation -TlsDomain mail.partner.example

S/MIME: sertifika ve anahtar yönetimi

S/MIME (güncel sürümü RFC 8551), her kullanıcının X.509 sertifikası ve özel anahtarıyla e-postayı imzalamasını, alıcının açık anahtarıyla da şifrelemesini sağlar. İmza içeriğin değişmediğini ve gönderenin kimliğini kanıtlar; şifreleme iletiyi yalnızca alıcıya okutur. Teknik olarak güçlüdür. Operasyonel yükü ağırdır:

• Sertifika dağıtımı: Her kullanıcıya, e-posta adresini SAN alanında taşıyan ve e-posta koruması kullanım amacına sahip bir sertifika gerekir. Dış alıcılar için genel güvenilir bir CA’dan alınan sertifikalar CA/Browser Forum’un S/MIME Baseline Requirements kurallarına tabidir.
• Alıcı sertifikası: Şifreleme için alıcının açık sertifikası lazım. Dış alıcılarla genellikle önce imzalı bir ileti alışverişi yapmak gerekir.
• Anahtar emaneti ve arşiv: Şifreleme anahtarı kaybedilirse eski iletiler okunamaz. Kurumsal kullanımda şifreleme anahtarları güvenli şekilde emanete alınmalı, süresi dolan sertifikaların özel anahtarları saklanmalıdır. İmza anahtarları ise emanete alınmaz.
• Tarama kaybı: Şifreli gövde ve ekler ağ geçidinde taranamaz; zararlı yazılım ve DLP kontrolleri uç noktaya kayar.

S/MIME’nin yerinde olduğu senaryo, düzenli yazışılan ve kendi PKI’si olan sınırlı sayıda iş ortağıyla imzalı ve şifreli iletişimdir. Sahada sık rastlanan tablo ise şudur: S/MIME bütün kullanıcılara açılmış, anahtar yaşam döngüsü planlanmamış, birkaç yıl sonra laptop değişimiyle birlikte eski iletiler açılamaz hale gelmiş. Anahtarı kaybeden, arşivi kaybeder.

Microsoft Purview Message Encryption

Purview Message Encryption (OME), Microsoft 365’in Azure Rights Management altyapısını kullanır. Kullanıcı da alıcı da sertifika yönetmez. Microsoft 365 alıcıları iletiyi doğrudan istemcilerinde açar; diğer alıcılar bir bildirim bağlantısıyla web portalına yönlendirilir ve tek kullanımlık kod veya desteklenen bir hesapla kimlik doğrular.

Yaygın koruma seçenekleri Encrypt-Only (yalnızca şifreleme) ve Do Not Forward (iletme, yazdırma ve kopyalama kısıtlı) şeklindedir. Kullanıcı Outlook’ta şifrelemeyi kendisi seçebilir ya da posta akışı kuralıyla otomatik uygulanır. Kural yazmadan önce IRM yapılandırmasını test edin; lisanslama kapalıysa kural sessizce hiçbir şey yapmaz:

Get-IRMConfiguration | Select-Object AzureRMSLicensingEnabled, InternalLicensingEnabled
Test-IRMConfiguration -Sender kullanici@example.com -Recipient alici@example.net

New-TransportRule -Name "Disa giden guvenli konu" -SentToScope NotInOrganization `
  -SubjectContainsWords "[guvenli]" -ApplyRMSTemplate "Encrypt"

Konu satırına anahtar kelime yazma yöntemi kullanıcının hatırlamasına bağlıdır ve unutulur. Daha sağlam yol, şifrelemeyi hassas içerik algılamasına bağlamaktır: Microsoft Purview DLP politikası ile e-posta konumunda şifreleme eylemi tanımlamak ya da şifreleme içeren duyarlılık etiketleri kullanmak. İleti süre sonu, iptal ve birden fazla markalama şablonu gibi gelişmiş özellikler (Advanced Message Encryption) ek lisans ister; lisans kapsamını Microsoft’un güncel hizmet açıklamasından doğrulayın.

OME’nin avantajı, şifreli iletinin kiracı içinde içerik incelemesi, eBulma ve saklama politikalarına tabi kalabilmesidir. Sınırlaması ise dış alıcı tarafında çıkar: portal deneyimi yadırganır, yanıtlar da portal üzerinden yazılır. Kritik dış alıcılara portalın nasıl kullanılacağını önceden anlatan kısa bir not, ilk iletinin yanıtsız kalmasını önler.

Senaryoya göre seçim tablosu

Senaryo	Önerilen yöntem	Not
Tüm gelen e-postada düşürme saldırısına karşı koruma	MTA-STS + TLS-RPT	DNSSEC varsa DANE de
Belirli iş ortağıyla sözleşmesel zorunlu TLS	Partnere özel doğrulamalı TLS	Her iki taraf yapılandırmalı
Bordro, kişisel veri içeren dış gönderim	OME (DLP veya etiketle otomatik)	Alıcıda sertifika gerekmez
Gönderen kimliğini ve bütünlüğü kanıtlayan imzalı yazışma	S/MIME imzası	Hukuki geçerlilik için nitelikli sertifika gerekebilir
Kendi PKI’si olan sınırlı ortaklarla uçtan uca gizlilik	S/MIME şifreleme	Tarama uç noktaya kayar
İletinin iletilmesini ve yazdırılmasını engelleme	OME Do Not Forward veya etiket	Ekran görüntüsünü engellemez

Çoğu kurumda mantıklı sıra şu: önce MTA-STS ve TLS-RPT ile aktarım katmanını sıkılaştırın, sonra hassas veri akışlarını belirleyip OME’yi otomatik kurallara bağlayın, S/MIME’yi yalnızca gerçek iş ihtiyacı olan sınırlı gruplara açın. Gönderen kimlik doğrulaması bu yapının ayrı bir katmanıdır. DMARC zorlaması tamamlanmadıysa şifreleme sahte göndericiye karşı hiçbir şey yapmaz. Microsoft 365 kiracısında bu kontrollerin birlikte yapılandırılması Microsoft 365 güvenliği kapsamında, aktarım katmanı ve gönderen doğrulaması ise e-posta güvenliği çalışmasının parçası olarak ele alınabilir. MTA-STS’nin resmi tanımı için başvuru kaynağı RFC 8461.

Sık sorulan sorular

MTA-STS yayımlarsam giden e-postalarım da zorunlu TLS ile mi gider?

Hayır. Yayımladığınız MTA-STS politikası, size e-posta gönderen sunuculara sizin alan adınıza nasıl teslim edeceklerini söyler; yani gelen yönü korur. Giden yönde koruma, kendi gönderen sunucunuzun karşı tarafın MTA-STS politikasını okuyup uygulamasına bağlıdır. Exchange Online gibi hizmetlerde bu doğrulamayı sağlayıcı yapar; şirket içi MTA kullanıyorsanız ayrıca etkinleştirmeniz gerekir.

S/MIME ile şifrelenmiş e-postalar DLP ve zararlı yazılım taramasından geçer mi?

Uçtan uca şifrelenmiş içeriği ağ geçidi ve bulut filtreleri çözemez; ek taraması ve içerik tabanlı DLP kuralları şifreli gövdeye uygulanamaz. S/MIME şifrelemesini yaygınlaştırmadan önce uç noktadaki korumayı ve hangi kullanıcıların şifreleme yapabileceğini netleştirin.

Microsoft 365 kullanmayan bir alıcı OME ile şifrelenmiş e-postayı nasıl okur?

Alıcıya bağlantı içeren bir bildirim gelir ve şifreli ileti Microsoft’un web portalında açılır. Kimlik doğrulaması tek kullanımlık kodla veya desteklenen bir hesapla oturum açılarak yapılır. Alıcının özel bir istemci ya da sertifika kurması gerekmez.

Zorunlu TLS için MTA-STS mi yoksa iş ortağına özel bağlayıcı mı kullanılmalı?

MTA-STS, alan adınıza gönderen tüm sunuculara genel bir politika yayımlar ve karşı tarafın desteğine bağlıdır. Belirli bir iş ortağıyla sözleşmeye bağlı zorunlu TLS gerekiyorsa, kendi gönderen sunucunuzda o alan adı için sertifika doğrulamalı zorunlu TLS tanımlamak daha kesin bir kontroldür. İkisi birbirinin alternatifi değil, tamamlayıcısıdır.