Exchange Server’da S/MIME ile Şifreli E-posta Yapılandırması

Yazar:komut.io ekibi Exchange Server Kurulum ve Yönetimi
0 Yorum

Kurumsal ortamlarda e-posta güvenliği deyince akla ilk gelen şey genellikle spam filtresi ya da TLS bağlantısıdır. Ama iletişimin gerçek anlamda korunması için bunlar yeterli değil. TLS size hat güvenliği sağlar, transit sırasında veriyi korur. Ancak mesaj sunucuya ulaştığında şifre çözülür ve düz metin olarak saklanır. Birisi sunucuya erişirse ya da bir ara sistem mesajı logluyorsa, içeriği okuyabilir. S/MIME ise farklı bir katman sunar: uçtan uca şifreleme. Mesaj gönderenin sisteminde şifrelenir, yalnızca alıcının özel anahtarıyla çözülür. Bu yazıda Exchange Server ortamında S/MIME’yi baştan sona kurup yönetmeyi ele alacağız.

S/MIME Nedir ve Exchange’deki Yeri Nedir

S/MIME, Secure/Multipurpose Internet Mail Extensions’ın kısaltmasıdır. Temel olarak iki şey yapar: dijital imzalama ve şifreleme. Dijital imzalama, mesajın gerçekten sizden geldiğini kanıtlar ve içeriğin değiştirilmediğini doğrular. Şifreleme ise yalnızca hedef alıcının mesajı okuyabileceğini garanti eder.

Exchange Server bu mekanizmayı natively destekler. Hem Exchange On-Premises (2016/2019) hem de Hybrid senaryolarda S/MIME kullanabilirsiniz. Outlook istemcisi bu sertifikaları otomatik olarak işleyebilir. Outlook on the Web (OWA) içinse biraz daha fazla yapılandırma gerekir.

Pratik bir senaryo düşünelim: Bir hukuk firmasında çalıştığınızı varsayalım. Müvekkil bilgileri, mahkeme belgeleri, sözleşme taslakları e-posta ile paylaşılıyor. Bu bilgilerin yalnızca alıcıya ulaşmasını garantilemek zorundasınız. Standart bir TLS kurulumu yeterli değil; mesajın her adımda şifreli kalması gerekiyor. İşte S/MIME burada devreye giriyor.

Sertifika Altyapısı Kurulumu

S/MIME için her kullanıcının bir e-posta sertifikasına ihtiyacı var. Bu sertifikaları iki kaynaktan alabilirsiniz: dahili bir Certificate Authority (CA) ya da ticari bir CA. Kurumsal ortamlarda genellikle kendi ADCS (Active Directory Certificate Services) altyapınızı kullanmak daha mantıklı, çünkü maliyet avantajı sağlar ve sertifika yönetimini merkezi tutabilirsiniz.

ADCS Üzerinde E-posta Sertifika Şablonu Oluşturma

Öncelikle Certificate Authority Management Console üzerinden yeni bir şablon oluşturmanız gerekiyor. Aşağıdaki PowerShell ile mevcut şablonları listeleyebilirsiniz:

# CA sunucusunda çalıştırın
Get-CATemplate | Select-Object Name, DisplayName | Format-List

Şablon oluşturmak için certlm.msc ya da Certification Authority konsolunu kullanmanız gerekebilir, ancak PowerShell ile de şablon kopyalama yapılabilir:

# PKI modülü ile şablon kontrolü
Import-Module ADCSAdministration

# Mevcut User şablonunu temel alarak yeni şablon listesi
Get-CATemplate | Where-Object {$_.Name -like "*User*"}

GUI tarafında yapmanız gerekenler şunlar: Certification Authority konsolunda Certificate Templates’e sağ tıklayıp Manage diyorsunuz, User şablonunu kopyalıyorsunuz, yeni şablonun adını “EmailEncryption” yapıyorsunuz. Extensions sekmesinde Application Policies altında Secure Email (1.3.6.1.5.5.7.3.4) ve Email Protection değerlerinin olduğundan emin oluyorsunuz. Key Usage’da Digital Signature ve Key Encipherment seçili olmalı.

Toplu Sertifika Dağıtımı – Auto-Enrollment

Yüzlerce kullanıcı için tek tek sertifika kesmek imkansız. Auto-enrollment burada hayat kurtarır. Group Policy üzerinden şu yapılandırmayı yapın:

# GPO ayarlarını kontrol etmek için
gpresult /r /scope user | findstr "Auto-Enrollment"

# Sertifika enrollment durumunu kontrol et
certutil -user -store My

GPO yolunuz şu olmalı: Computer Configuration > Windows Settings > Security Settings > Public Key Policies > Certificate Services Client – Auto-Enrollment. “Enroll certificates automatically” seçeneğini aktif edin ve her iki onay kutusunu da işaretleyin.

Kullanıcı Sertifikalarını Exchange’e Tanıtmak

S/MIME şifrelemesi için gönderenin, alıcının public keyini bilmesi gerekiyor. Exchange bu bilgiyi Active Directory üzerinden alır. Kullanıcının sertifikasının AD hesabındaki userSMIMECertificate ya da userCertificate attribute’una yazılması gerekiyor. Auto-enrollment kullandığınızda bu genellikle otomatik oluyor, ama kontrol etmek iyi bir fikir:

# Belirli bir kullanıcının sertifika attribute'larını kontrol et
Get-ADUser -Identity "ahmet.yilmaz" -Properties userCertificate, userSMIMECertificate | 
Select-Object Name, userCertificate, userSMIMECertificate

Eğer sertifika attribute’da yoksa, kullanıcının sertifikasını publish etmeniz gerekiyor:

# Sertifikayı AD'ye yayınla
$cert = Get-Item Cert:CurrentUserMy | Where-Object {$_.EnhancedKeyUsageList -like "*Secure Email*"}
$certBytes = $cert.RawData
Set-ADUser -Identity "ahmet.yilmaz" -Replace @{userCertificate = $certBytes}

Exchange Server Tarafında Yapılandırma

Exchange Server 2016 ve 2019, S/MIME’yi özel bir şekilde “yönetmez” aslında; bu iş büyük ölçüde istemci tarafında döner. Ancak sunucu tarafında bazı kritik ayarlar var.

OWA için S/MIME Ayarları

Outlook on the Web üzerinden S/MIME kullanmak için kullanıcıların bir S/MIME kontrolü yüklemesi gerekiyor. Exchange tarafında bu özelliği aktif etmek için:

# OWA VirtualDirectory'de S/MIME'yi aktif et
Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -SMimeEnabled $true

# Hangi sunucularda OWA çalıştığını listele
Get-OwaVirtualDirectory | Select-Object Server, Name, SMimeEnabled

OWA S/MIME kontrolü için kullanıcılara bir ActiveX bileşeni sunulur (IE/Edge Legacy gerektiriyordu) ya da modern tarayıcılarda sertifika tabanlı çalışma yapılandırılabilir. Gerçek dünyada OWA S/MIME kurulumları hala bazı kısıtlamalar içerdiğinden, kritik operasyonlar için Outlook istemcisi tercih edilir.

Virtual Directory ve Sertifika Yönetimi

Exchange sunucusunun kendi sertifikasıyla S/MIME karıştırılmamalı, ama tutarlı bir PKI altyapısı için Exchange sertifikalarının da aynı CA’dan gelmesi önerilir:

# Exchange sertifikalarını listele
Get-ExchangeCertificate | Select-Object Subject, Thumbprint, NotAfter, Services

# Süresi dolmak üzere olan sertifikaları bul
Get-ExchangeCertificate | Where-Object {$_.NotAfter -lt (Get-Date).AddDays(30)} | 
Select-Object Subject, NotAfter, Thumbprint

Message Encoding ve S/MIME Uyumluluğu

Exchange, mesaj formatlarını otomatik dönüştürebilir ve bu bazen S/MIME imzalarını bozabilir. Remote domain ayarlarını gözden geçirin:

# Remote domain encoding ayarlarına bak
Get-RemoteDomain | Select-Object DomainName, LineWrapSize, TNEFEnabled, ContentType

# Varsayılan domain için TNEF'i kapat (S/MIME uyumluluğu için)
Set-RemoteDomain -Identity "Default" -TNEFEnabled $false

# Belirli bir domain için ayar
Set-RemoteDomain -Identity "partner.com" -TNEFEnabled $false -ContentType MimeHtmlText

TNEF (Transport Neutral Encapsulation Format), yani Winmail.dat dosyası S/MIME imzalı mesajlarla sorun çıkarabilir. Özellikle dış domain’lerle iletişimde bu ayara dikkat edin.

Outlook İstemci Yapılandırması

Kullanıcı tarafında S/MIME’yi Outlook’ta aktif etmek görece basit, ancak kurumsal ortamda bunu otomatize etmek gerekiyor.

Trust Center Yapılandırması – GPO ile

Kullanıcılara “Trust Center’a gir, Security sekmesini bul, sertifikayı seç” diye anlatmak hem zahmetli hem de hata riskli. Bunun yerine GPO ile merkezi yönetim yapın:

# Outlook GPO ayarlarını kontrol etmek için registry yolları
# HKCUSoftwareMicrosoftOffice16.0OutlookSecurity

# Mevcut Outlook güvenlik ayarlarını oku (istemci tarafında)
Get-ItemProperty -Path "HKCU:SoftwareMicrosoftOffice16.0OutlookSecurity" -ErrorAction SilentlyContinue

Office ADMX şablonları yüklendiğinde GPO’da şu yolu kullanabilirsiniz: User Configuration > Administrative Templates > Microsoft Outlook 2016 > Security > Cryptography. Burada “Default encryption setting for S/MIME messages”, “Send clear text signed message when sending signed messages” gibi kritik ayarları merkezi olarak yönetebilirsiniz.

Sertifika Seçimi Otomasyonu

Birden fazla sertifika olan kullanıcılarda Outlook yanlış sertifikayı seçebilir. Doğru sertifikayı otomatik olarak atamak için:

# PowerShell ile kullanıcının email sertifikalarını listele
Get-ChildItem Cert:CurrentUserMy | 
Where-Object {$_.EnhancedKeyUsageList -match "Secure Email"} | 
Select-Object Subject, Thumbprint, NotAfter, Issuer

Anahtar Yönetimi ve Escrow

İşte S/MIME’nin en kritik ve en çok göz ardı edilen konusu: anahtar kaybı. Bir kullanıcı şirkettten ayrılırsa ya da bilgisayarı çökerse ve özel anahtarı yoksa, o kullanıcıya gönderilmiş tüm şifreli e-postalar sonsuza kadar okunamaz hale gelir. Bu durum hem yasal uyumluluk hem de operasyonel süreklilik açısından ciddi bir risk.

Key Archival Yapılandırması

ADCS üzerinde Key Archival aktif edilirse, özel anahtarlar CA’da şifreli olarak saklanır:

# CA'da key archival sertifikasını kontrol et
certutil -config "CA_SUNUCUCA_ADI" -getconfig

# Key recovery agent sertifikalarını listele
certutil -config "CA_SUNUCUCA_ADI" -getkra

CA Management Console üzerinden sertifika şablonunuzu düzenleyin: Subject sekmesinde değil, ama Request Handling sekmesinde “Archive subject’s encryption private key” seçeneğini işaretleyin. Bu seçenek yalnızca Key Encipherment kullanım amacı olan şablonlarda görünür.

Kayıp Anahtar Kurtarma

Bir kullanıcının anahtarını kurtarmanız gerektiğinde:

# CA'dan arşivlenmiş anahtarı kurtar (KRA sertifikasına sahip yetkili kullanıcı)
certutil -config "CA_SUNUCUCA_ADI" -getkey <serial_number> output.p7b

# Kurtarılan anahtarı kullanılabilir formata dönüştür
certutil -recoverkey output.p7b recovered.pfx

# PFX dosyasını incele
certutil -dump recovered.pfx

Çapraz Kurum Senaryoları

Gerçek dünyada işler her zaman iç kullanıcılar arasında kalmaz. Dış partnerlere şifreli e-posta göndermek ya da onlardan şifreli mesaj almak istediğinizde farklı durumlar ortaya çıkıyor.

Harici Kullanıcıların Public Key’lerini Yönetmek

Dış kişinin sertifikası AD’nizde olmayacak. Outlook bu sertifikayı nerede bulacak? İki yöntem var:

İlki, alıcının size daha önce imzalı bir mesaj atmış olması. Outlook imzalı mesajlardan public key’i otomatik olarak kişi kartına ekler. Bu yüzden S/MIME kullanacak partnerlerinizden önce imzalı bir test maili atmasını isteyin.

İkincisi, sertifikayı manuel olarak kişi kartına eklemek. Outlook’ta kişi açılır, Certificates sekmesinden sertifika import edilir.

Toplu yönetim için LDAP tabanlı bir sertifika deposu da kurabilirsiniz:

# Exchange'de harici LDAP sertifika kaynağı tanımlamak
# (Outlook tarafında yapılır, Trust Center > Email Security > Get S/MIME Receipt)

# Powershell ile global address list'teki kullanıcıların sertifika durumunu kontrol et
Get-Mailbox -ResultSize Unlimited | ForEach-Object {
    $user = Get-ADUser -Identity $_.SamAccountName -Properties userCertificate -ErrorAction SilentlyContinue
    if ($user) {
        [PSCustomObject]@{
            Name = $_.DisplayName
            Email = $_.PrimarySmtpAddress
            HasCertificate = ($user.userCertificate -ne $null)
        }
    }
} | Where-Object {$_.HasCertificate -eq $false}

Bu script, sertifikası olmayan kullanıcıları listeler. Periyodik çalıştırmak için zamanlanmış görev olarak ayarlayabilirsiniz.

Sorun Giderme

S/MIME kurulumunda en sık karşılaşılan sorunların büyük kısmı sertifika zinciri doğrulama problemlerinden kaynaklanır. Alıcı mesajı açtığında “Bu sertifika güvenilir değil” uyarısı görüyorsa, büyük ihtimalle root CA sertifikası alıcının trusted store’unda değildir.

Sertifika Zinciri Kontrolü

# Sertifika zincirini doğrula
certutil -verify -urlfetch user_cert.cer

# OCSP ve CRL erişimini test et
certutil -url user_cert.cer

# Sertifikanın kullanım amaçlarını kontrol et
certutil -dump user_cert.cer | findstr "Application Policies"

Mesaj İmza Doğrulama Hatası

Bir mesajın imzası “geçersiz” gösteriliyorsa önce şunu kontrol edin: mesaj transit sırasında değiştirilmiş mi? Exchange transport kuralları veya üçüncü parti gateway’ler mesaj gövdesini değiştirebilir.

# Exchange message tracking ile mesajın geçtiği hop'ları gör
Get-MessageTrackingLog -Sender "[email protected]" -Start (Get-Date).AddHours(-2) |
Select-Object Timestamp, EventId, Source, Recipients, MessageSubject |
Format-Table -AutoSize

# Transport agent'ları listele (mesajı değiştirebilecek bileşenler)
Get-TransportAgent | Select-Object Name, Enabled, Priority

Şifreli Mesaj Açılamıyor

Bu genellikle üç nedenden biri: özel anahtar yok, yanlış sertifika seçilmiş ya da sertifika süresi dolmuş. Outlook’un hata mesajı genellikle yeterince açıklayıcı olmuyor:

# Kullanıcının mevcut özel anahtarlarını listele
Get-ChildItem Cert:CurrentUserMy | 
Select-Object Subject, Thumbprint, HasPrivateKey, NotAfter |
Where-Object {$_.HasPrivateKey -eq $true}

# Belirli bir sertifikanın özel anahtarını test et
$cert = Get-ChildItem Cert:CurrentUserMy | Where-Object {$_.Thumbprint -eq "THUMBPRINT_BURAYA"}
$cert.PrivateKey -ne $null

Compliance ve Denetim Gereklilikleri

S/MIME kullanımı bazı compliance senaryolarını karmaşık hale getirebilir. Örneğin Exchange’in Journal özelliği ya da eDiscovery, şifreli mesajların içeriğine erişemez. Bu durum KVKK denetimleri ya da yasal tutma (litigation hold) süreçlerinde sorun yaratabilir.

Bu sorunu çözmek için iki yaklaşım var. Birincisi, kullanıcıların şifreli mesajları yerel PST yerine Exchange mailbox’ında tutmasını sağlamak ve key escrow ile şifre çözme kapısını açık bırakmak. İkincisi, hangi iletişim kanallarının S/MIME gerektirdiğini net olarak politikayla belirlemek; her e-postayı şifrelemek yerine yalnızca gizli sınıflandırılmış içerikleri şifrelemek.

# Litigation hold'daki mailbox'ları listele
Get-Mailbox -ResultSize Unlimited | 
Where-Object {$_.LitigationHoldEnabled -eq $true} |
Select-Object DisplayName, PrimarySmtpAddress, LitigationHoldDate

# In-place hold ile birlikte S/MIME politika notu için transport rule örneği
# (Bu kural şifreli mesajları takip eder, içerik değil)
New-TransportRule -Name "SMIME_Tracking" `
    -MessageContainsDataClassifications @() `
    -HeaderMatchesMessageHeader "Content-Type" `
    -HeaderMatchesPatterns "application/pkcs7*" `
    -SetHeaderName "X-SMIME-Encrypted" `
    -SetHeaderValue "True"

Sertifika Yenileme Stratejisi

Sertifika süresi dolduğunda eskiden şifrelenmiş mesajlar hala okunabilir olmalı. Bu nedenle eski sertifikaların özel anahtarlarını asla silmemek gerekiyor. Yenileme yapıldığında eski sertifika arşive alınmalı, özel anahtarı ise güvenli bir yerde saklanmalı.

# Süresi dolmuş ama arşivde tutulması gereken sertifikaları bul
Get-ChildItem Cert:CurrentUserMy |
Where-Object {
    $_.NotAfter -lt (Get-Date) -and 
    $_.EnhancedKeyUsageList -match "Secure Email"
} |
Select-Object Subject, Thumbprint, NotAfter

# Eski sertifikanın yedeğini PFX olarak al
$oldCert = Get-ChildItem Cert:CurrentUserMy | Where-Object {$_.Thumbprint -eq "ESKI_THUMBPRINT"}
Export-PfxCertificate -Cert $oldCert -FilePath "C:Backupold_smime_cert.pfx" -Password (Read-Host -AsSecureString "PFX Parolası")

Sonuç

S/MIME kurulumu, “bir kez yap unut” değil, sürekli bakım gerektiren bir altyapı. Sertifika döngüsünü, anahtar yedeklemesini ve kullanıcı farkındalığını ihmal ettiğinizde güvenlik kazancı elde edemezsiniz, aksine operasyonel sorun birikirir.

Pratik tavsiyem şu: Her şeyi aynı anda uygulamaya almaya çalışmayın. Önce CA altyapısını ve sertifika şablonunu hazırlayın, auto-enrollment’ı pilot bir grupla test edin. Sorunsuz çalıştığını gördükten sonra tüm kullanıcılara açın. OWA S/MIME’yi başlangıçta devre dışı bırakabilirsiniz, çünkü Outlook istemcisi çok daha olgun bir deneyim sunuyor.

Key escrow’u baştan kurun. Sonradan “şu kullanıcının 2 yıllık maillerini okuyamıyoruz” durumuna düşmek hem teknik hem de yasal açıdan son derece sıkıntılı. Ve son olarak: kullanıcıları eğitin. Şifreli e-postayı kimi zaman şifreleyip kimi zaman şifrelemeden göndermek, alıcıda yanlış bir güven hissi yaratabilir. Politikanız tutarlı olmalı.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir