Bu yazıya sahadan bir cümleyle başlayalım — bir BT müdüründen, birebir: "Maillerimiz zaten şifreli değil mi? Tarayıcıda kilit işareti var." Bu cümle, e-posta şifrelemedeki en yaygın yanılgıyı özetliyor. O kilit işareti (TLS), mailin yolda şifrelendiğini gösterir — postacının zırhlı araçla gitmesi gibi. Ama mail sunucuya indiğinde, yedeklendiğinde, yanlış kutuya düştüğünde ya da hesap ele geçirildiğinde içerik apaçık ortadadır. Zarfın kendisi hiç mühürlenmemiştir.
Mail Teknolojileri Serimizin bu ikinci yazısında zarfı mühürleyen iki teknolojiyi ele alıyoruz: S/MIME ve PGP. Amaç yine aynı: hiç bilmeyen bir BT yöneticisinin okuyup uygulayabileceği, sık hataları ve doğrusunu gösteren bir rehber — tanım ezberi değil. İlk yazıyı (SPF/DKIM/DMARC) okumadıysanız buradan başlayabilirsiniz; o yazı "gönderen gerçekten siz misiniz" sorusunu, bu yazı "içeriği sizden başkası okuyabilir mi" sorusunu çözer.
1. Önce Kavramı Netleştirelim: TLS Neyi Korur, Neyi Korumaz?
E-postada üç ayrı koruma katmanı vardır ve bunlar sık karıştırılır:
- Taşıma şifrelemesi (TLS): Mail, sunucular arasında yolculuk ederken şifrelenir. Bugün büyük sağlayıcılar arasında standarttır. Ama uçtan uca değildir — mail her sunucuda açık halde durur.
- Kimlik doğrulama (SPF/DKIM/DMARC): Gönderenin gerçekliğini doğrular; içeriği şifrelemez.
- Mesaj şifrelemesi (S/MIME, PGP): Mailin içeriğini şifreler; yalnızca hedef alıcının açabileceği hale getirir. Sunucu ele geçirilse, yedek sızsa, mail yanlış kişiye gitse bile içerik okunamaz. Bu yazının konusu bu katman.
Kısa kural: TLS yolu korur, S/MIME/PGP zarfı mühürler. Hassas içerik taşıyorsanız (finansal veri, sağlık verisi, sözleşme, teknik çizim) ikisine birden ihtiyacınız var.
2. S/MIME — Kurumsal Dünyanın Standardı
S/MIME (Secure/Multipurpose Internet Mail Extensions), sertifika tabanlı çalışır: kimliğiniz, güvenilir bir sertifika otoritesinin (CA) imzaladığı bir e-posta sertifikasıyla doğrulanır. İki şey yapar: dijital imza (mailin sizden çıktığını ve değişmediğini kanıtlar) ve şifreleme (içeriği yalnızca alıcının açabilmesini sağlar).
Nasıl kurulur? (Microsoft 365 örneğiyle)
- Sertifika edinin: Bir CA'dan (ör. kurumsal sertifika sağlayıcıları) çalışan başına S/MIME sertifikası alınır. Kurumsal senaryoda bu, tek tek satın almak yerine merkezi olarak (MDM/Intune ya da GPO ile dağıtılarak) yapılır.
- Sertifikayı yükleyin: Sertifika (.pfx) kullanıcının cihazına kurulur; Outlook, Ayarlar → Güven Merkezi → E-posta Güvenliği altından imzalama/şifreleme sertifikası olarak seçilir.
- Genel anahtarları paylaşın: Şifreli mail gönderebilmek için alıcının genel anahtarına (sertifikasına) ihtiyacınız vardır. En basit yol: karşı taraf size bir kez imzalı mail atar; Outlook sertifikayı kişiye kaydeder.
- İmzalayın ve şifreleyin: Yeni mailde "İmzala" ve/veya "Şifrele" düğmeleri artık aktiftir. İlk test: karşılıklı imzalı mail → sonra şifreli mail.
Sık yapılan hatalar → doğrusu
- Hata: Özel anahtarı tek kopyayla cihazda bırakmak. Cihaz çöktüğünde ya da çalışan ayrıldığında, o anahtarla şifrelenmiş tüm geçmiş mailler sonsuza dek okunamaz hale gelir. Doğrusu: Anahtar yedekleme/emanet (key escrow) politikası — kurumsal dağıtımda sertifikalar merkezi olarak yedeklenir.
- Hata: Süresi dolan sertifikayı fark etmemek. İmzalar bir gün "geçersiz" görünmeye başlar, karşı taraf sizi sahte sanır. Doğrusu: Sertifika yaşam döngüsünü takvime değil merkezi yönetime bağlamak; yenilemeyi otomatikleştirmek.
- Hata: "İmzalama" ile "şifrelemeyi" karıştırmak. İmza kimliği kanıtlar ama içerik açıktır; şifreleme içeriği kapatır. Hassas ek "imzalı ama şifresiz" gidince koruma sanılandan azdır. Doğrusu: Hassas içerikte ikisi birlikte.
- Hata: Şifreli mailin parolasını/anahtarını aynı kanaldan göndermek. Şifreli dosya + parolası aynı mail zincirindeyse, şifreleme tiyatrodan ibarettir. Doğrusu: İkinci kanal (SMS, telefon) — ya da zaten parola gerektirmeyen S/MIME/PGP.
3. PGP — Esnek ve Bağımsız Alternatif
PGP (Pretty Good Privacy; açık standardı OpenPGP), CA'ya ihtiyaç duymaz: her kullanıcı kendi anahtar çiftini üretir — genel anahtar (herkese dağıtılır) ve özel anahtar (asla paylaşılmaz). Güven, sertifika otoritesi yerine anahtarın doğru kişiden alındığından emin olmaya dayanır.
Nasıl kurulur? (özet akış)
- Araç seçin: Windows'ta Gpg4win (Kleopatra), macOS'ta GPG Suite; Thunderbird'de OpenPGP yerleşiktir.
- Anahtar çifti üretin: Ad + e-posta ile 3072/4096-bit RSA (ya da modern ECC) anahtar üretilir; özel anahtar güçlü bir parolayla korunur.
- Genel anahtarı paylaşın: Web sitenize koyabilir, imza dosyanıza fingerprint ekleyebilir ya da doğrudan gönderebilirsiniz. Karşı tarafın anahtarını da alıp doğrularsınız (fingerprint'i telefonla teyit etmek en temiz yöntem).
- Şifreleyin/imzalayın: Araç, mail istemcinize entegre olur; alıcının genel anahtarıyla şifreler, sizin özel anahtarınızla imzalar.
Sık yapılan hatalar → doğrusu
- Hata: Özel anahtar parolasını kaybetmek / anahtarı yedeklememek. PGP'de "parolamı unuttum" düğmesi yoktur. Doğrusu: Anahtar + iptal sertifikası (revocation certificate) üretim anında yedeklenir, çevrimdışı saklanır.
- Hata: Fingerprint doğrulamadan anahtara güvenmek. Saldırgan, hedefin adına sahte anahtar yayınlayabilir. Doğrusu: İlk anahtar alışverişinde fingerprint'i ikinci kanaldan teyit etmek.
- Hata: Konu satırının şifrelenmediğini unutmak. PGP (ve S/MIME) gövdeyi ve ekleri şifreler; konu satırı ve alıcı bilgisi açıktır. Doğrusu: Konuya hassas bilgi yazmamak ("X firması devralma sözleşmesi" gibi bir konu, şifreli gövdeyi anlamsızlaştırır).
4. Hangisi, Ne Zaman? (Ve Türkiye'ye Özel Not: KEP)
- Kurumsal, sürekli, çok kullanıcılı ihtiyaç → S/MIME. Outlook/Microsoft 365 ve mobil istemcilerle yerleşik uyum, merkezi dağıtım ve yönetim kolaylığı. Düzenli hassas yazışma yapan departmanlar (finans, hukuk, İK) için doğal seçim.
- Kurum dışı, uzman-uzmana, ad-hoc ihtiyaç → PGP. CA maliyeti yok, karşı tarafın kurumsal altyapısına bağımlılık yok. Güvenlik araştırmacıları, gazeteciler, tek tek dış paydaşlarla yüksek hassasiyetli alışveriş.
- Türkiye'ye özel not — KEP ile karıştırmayın: KEP (Kayıtlı Elektronik Posta), gönderinin hukuki delil niteliğini sağlar (kim, kime, ne zaman — tebligat yerine geçer); içeriğin uçtan uca gizliliği ayrı bir konudur. KEP resmi bildirim içindir, S/MIME/PGP içerik gizliliği içindir; biri diğerinin yerine geçmez, ihtiyaca göre birlikte kullanılır.
5. Bir Üst Seviye: Sertifika Derdi Olmadan Kurumsal Şifreleme
Dürüst olalım: S/MIME'ın kurumsal dağıtımı (sertifika yaşam döngüsü, anahtar emaneti, karşı tarafın uyumu) ciddi operasyon ister; PGP ise kurum dışı bireysel senaryolarda parlar ama yüzlerce çalışana ölçeklemek zordur. Tam bu boşluk için üçüncü bir yol var: politika tabanlı şifreleme.
Check Point Harmony Email & Collaboration tarafında bu şöyle çalışır: DLP motoru, giden maili içeriğine göre sınıflar (IBAN, TC kimlik, sağlık verisi, "gizli" damgalı ek...); politikayla eşleşen mail otomatik olarak şifrelenir. Alıcı, tarayıcı üzerinden güvenli portalda kimliğini doğrulayıp maili okur — karşı tarafta sertifika, anahtar, kurulum gerekmez. Çalışan hiçbir düğmeye basmayı hatırlamak zorunda değildir; "İK maaş dosyasını şifrelemeyi unuttu" senaryosu ortadan kalkar. S/MIME/PGP'nin yerini almaz — insan hatasını devreden çıkaran tamamlayıcı katmandır.
Sıkça Sorulan Sorular
Microsoft 365'in kendi mesaj şifrelemesi (OME/Purview) yeterli değil mi?
Purview Message Encryption pratik bir araçtır ve birçok senaryoda yeterlidir; ancak lisans seviyesine bağlıdır, politika esnekliği sınırlıdır ve şifreleme kararını çoğu zaman kullanıcının doğru etiketlemesine bırakır. İçerik-farkındalıklı otomatik DLP sınıflandırmasıyla birlikte kullanıldığında en güçlü halini alır.
Şifreleme phishing'i de engeller mi?
Hayır — bu ayrımı net yapmak gerekir. Şifreleme gizlilik sağlar (içeriği kimse okuyamaz); phishing/BEC savunması ayrı bir katmandır. Hatta imzalı-şifreli görünen bir mail, ele geçirilmiş gerçek bir hesaptan geliyorsa sahte bir güven duygusu bile yaratabilir. İki katman birbirini tamamlar, ikame etmez.
Karşı tarafın hiçbir altyapısı yok; yine de şifreli gönderebilir miyim?
S/MIME/PGP için karşı tarafın anahtarı/sertifikası şarttır. Karşı taraf kurulumsuzsa portal tabanlı politika şifrelemesi (yukarıdaki 5. bölüm) tam bu senaryo içindir: alıcı yalnızca tarayıcıyla, kimliğini doğrulayıp okur.
Çalışan ayrılınca şifreli mailleri ne olur?
Anahtar emaneti (escrow) kurulmuşsa kurum, yasal saklama yükümlülükleri kapsamında erişimi koruyabilir. Kurulmamışsa mailler kalıcı olarak kapalıdır — S/MIME dağıtımına başlamadan önce escrow politikasını yazmanız tam da bu yüzden kritik.
Şimdi Ne Yapmalı?
Kendinize iki soru sorun: (1) Finans/hukuk/İK ekipleriniz hassas içeriği bugün nasıl gönderiyor? (2) "Şifrelemeyi unutma" kararı bir insana mı, bir politikaya mı bağlı? İkinci sorunun cevabı "insana" ise:
- Ücretsiz Saha Denetimi: Giden hassas veri akışınızın (DLP açısından) fotoğrafını çeker, şifreleme boşluklarını raporlarız.
- Politika tabanlı şifreleme demosu: Harmony Email üzerinde, sizin gerçek senaryolarınızla (IBAN'lı mail, özlük dosyası, sözleşme eki) uçtan uca gösterim.
Bu yazı hakkında: Mail Teknolojileri Serimizin ikinci yazısıdır; bir sonraki yazı MTA-STS ve TLS-RPT ile taşıma katmanı güvenliğini ele alacak (bu yazıdaki "TLS yolu korur" cümlesinin devamı). Kinetik Bilişim, Check Point Software Technologies'in Advanced Partner 2026 seviyesindeki Türkiye iş ortağıdır; Email, Endpoint & Browser, Mobile ve SASE Solution Specialization akreditasyonlarına sahiptir. Yazar Kemal Özleyen, Check Point Workspace Security Expert sertifikalı bir siber güvenlik mühendisidir.
