Sektörel·
26 Nisan 2026
Hastane bilgi sistemleri, laboratuvar sonuçları, reçete bildirimleri ve sigorta yazışmaları her gün milyonlarca e-posta üzerinden aktarılıyor. Sağlık verisinin en değerli hedeflerden biri haline geldiği bu ortamda yetersiz e-posta güvenliği; hem hasta mahremiyetini tehdit ediyor hem de kurumları ağır idari yaptırımlarla karşı karşıya bırakıyor.
6698 sayılı Kişisel Verilerin Korunması Kanunu'nun 6. maddesi, kişilerin sağlık ve cinsel hayatına ilişkin verileri "özel nitelikli kişisel veri" olarak tanımlamakta; bu verilerin işlenmesi için açık rıza ya da kanunda sayılan istisnalardan birinin varlığını şart koşmaktadır. Kişisel Verileri Koruma Kurumu'nun (KVKK) yayımladığı "Özel Nitelikli Kişisel Verilerin İşlenmesinde Veri Sorumlularınca Alınması Gereken Yeterli Önlemler" başlıklı kararı (2018/10 sayılı Karar), söz konusu verilerin aktarımında kriptografik yöntemlerin kullanılmasını açıkça öngörmektedir. E-posta, bu aktarım kanallarının başında gelmekte; dolayısıyla iletim şifrelemesi ve kimlik doğrulama mekanizmaları artık isteğe bağlı olmaktan çıkmış durumdadır.
Dünya Sağlık Örgütü (WHO) ve Avrupa Birliği Siber Güvenlik Ajansı (ENISA), 2023 yılı tehdit ortamı raporlarında sağlık sektörünü fidye yazılımı ve kimlik avı (phishing) saldırılarında en çok hedef alınan sektörler arasında göstermektedir. Türkiye özelinde ise Sağlık Bakanlığı'nın yönetiminde yürütülen e-Nabız ve ÇKYS (Çekirdek Kaynak Yönetim Sistemi) entegrasyonlarının yaygınlaşması, kurumsal e-posta altyapısını kritik bir saldırı yüzeyi haline getirmektedir.
E-posta sahteciliğini (spoofing) ve kimlik avını engellemenin standart yolu; SPF, DKIM ve DMARC protokollerinin üçlü kombinasyonudur. Bu protokoller birbirini tamamlayıcı nitelikte olup her biri farklı bir güvenlik katmanı sağlar:
| Protokol | RFC | İşlevi | DNS Kaydı Türü | Sağlık Sektörü Önemi |
|---|---|---|---|---|
| SPF (Sender Policy Framework) | RFC 7208 | Belirli bir alan adından e-posta göndermeye yetkili IP adreslerini tanımlar | TXT | Sahte gönderen adresiyle hasta veya hekim kandırma girişimlerini engeller |
| DKIM (DomainKeys Identified Mail) | RFC 6376 | Gönderen sunucu, e-postayı özel anahtarıyla imzalar; alıcı taraf DNS'teki açık anahtarla doğrular | TXT (selector._domainkey) | İletim sırasında içerik değiştirilmediğini kanıtlar; laboratuvar sonucu manipülasyonunu önler |
| DMARC (Domain-based Message Authentication, Reporting & Conformance) | RFC 7489 | SPF ve DKIM doğrulaması başarısız olduğunda mesaja ne yapılacağını (reject/quarantine/none) tanımlar ve raporlama sağlar | TXT (_dmarc) | Başarısız kimlik doğrulama girişimlerini merkezi raporla izlemeye olanak tanır; uyumluluk kanıtı üretir |
Sağlık kurumları için önerilen DMARC politikası, başlangıçta p=none ile izleme modunda çalıştırılmalı; yeterli raporlama verisi elde edildikten sonra p=quarantine ve nihayetinde p=reject seviyesine çıkarılmalıdır. Bu aşamalı geçiş, meşru e-postaların yanlışlıkla engellenmesini önler.
E-postanın ağ üzerinde aktarımı sırasında içeriğin şifrelenmesi için SMTP üzerinde TLS (Transport Layer Security) kullanılır. RFC 8314, e-posta istemci-sunucu iletişiminde TLS kullanımını standartlaştırmış; RFC 7672 ise SMTP MTA Strict Transport Security (MTA-STS) mekanizmasını tanımlamıştır. MTA-STS, e-posta sunucularının yalnızca TLS bağlantılarını kabul etmesi gerektiğini otomatik olarak duyurmasına ve zorunlu kılmasına imkan tanır; bu sayede "downgrade" saldırıları (TLS'i devre dışı bırakarak şifresiz iletişime zorlama) önlenir.
Hastane yönetim sistemleri (HIS/HBS) entegrasyonunda sunucu-sunucu e-posta trafiğinin de TLS 1.2 veya üzeri bir sürümle korunması zorunludur. TLS 1.0 ve 1.1'in kullanımdan kaldırılması, Ulusal Siber Güvenlik Stratejisi ve Eylem Planı kapsamında Bilgi Teknolojileri ve İletişim Kurumu (BTK) tarafından da tavsiye edilmektedir.
İş E-Postası Dolandırıcılığı (BEC — Business Email Compromise), saldırganın kurumsal bir e-posta hesabını ele geçirerek ya da taklit ederek finansal transfer, veri paylaşımı veya hesap bilgisi talep etmesi esasına dayanır. Sağlık sektöründe bu saldırı tipi şu biçimlerde görülmektedir:
Bu saldırılara karşı teknik kontrollerin yanı sıra süreç kontrolleri de şarttır: büyük tutarlı ödemelerde e-posta dışı kanal (telefon veya yüz yüze) ile doğrulama kuralı, IBAN değişikliği taleplerine ek onay adımı ve çalışanlara yönelik düzenli simüle phishing tatbikatları bu süreç kontrollerinin başında gelir.
E-posta yoluyla gerçekleşen kişisel veri ihlalleri, 6698 sayılı KVKK'nın 12. maddesi uyarınca veri sorumlusuna ciddi yükümlülükler doğurmaktadır. İhlal tespitinden itibaren 72 saat içinde KVKK'ya bildirim yapılması zorunludur (madde 12/5). İhlal büyüklüğüne ve ihmalin derecesine göre Kurul, KVKK madde 18 kapsamında 50.000 TL'den 1.000.000 TL'ye kadar idari para cezası uygulayabilir.
6563 sayılı Elektronik Ticaretin Düzenlenmesi Hakkında Kanun (ETK) ise ticari elektronik iletilere odaklanmaktadır. Sağlık kurumlarının randevu hatırlatması, sağlık kampanyası veya tanıtım içerikli e-posta gönderimlerinde ETK madde 6 uyarınca önceden onay (opt-in) alınması ve her iletide kolayca erişilebilir bir abonelikten çıkma (unsubscribe) mekanizması sunulması zorunludur. BTK'nın 2015 tarihli "Ticari İletişim ve Ticari Elektronik İletiler Hakkında Yönetmelik"i bu yükümlülükleri ayrıntılı biçimde düzenlemektedir.
Siber güvenlik araştırmaları, veri ihlallerinin büyük çoğunluğunda insan faktörünün belirleyici rol oynadığını tutarlı biçimde göstermektedir. Teknik kontroller ne kadar güçlü olursa olsun, bir çalışanın kandırılarak kimlik bilgilerini paylaşması ya da kötü niyetli bir eki açması sistemin tamamını tehlikeye atabilir. Bu nedenle sağlık kurumlarının e-posta güvenlik programı şu unsurları içermelidir:
Sağlık kurumları için e-posta güvenliğini aşamalı olarak güçlendiren pratik bir yol haritası aşağıdaki gibi yapılandırılabilir:
| Aşama | Süre | Yapılacaklar | Öncelik |
|---|---|---|---|
| 1 — Envanter | 1-2 hafta | Tüm gönderen alan adlarını ve IP'leri listele; mevcut SPF/DKIM/DMARC durumunu denetle | Kritik |
| 2 — SPF & DKIM | 2-4 hafta | SPF kaydını oluştur/düzelt; tüm posta sunucularında DKIM imzalamayı etkinleştir | Kritik |
| 3 — DMARC (none) | 4-8 hafta | DMARC p=none ile izleme başlat; haftalık raporları analiz et | Yüksek |
| 4 — TLS & MTA-STS | 2-4 hafta | Tüm SMTP bağlantılarında TLS 1.2+ zorunlu kıl; MTA-STS politika dosyasını yayımla | Yüksek |
| 5 — DMARC (quarantine→reject) | 8-16 hafta | Raporlar temizlendikten sonra politikayı aşamalı sıkılaştır | Orta |
| 6 — DLP & MFA | Sürekli | Veri kaybı önleme kurallarını devreye al; ayrıcalıklı hesaplarda MFA zorunlu kıl | Yüksek |
| 7 — Eğitim & Tatbikat | Yılda 2x | Simüle phishing tatbikatı ve farkındalık eğitimi düzenle | Orta |
SPF (RFC 7208) kaydı, alıcı sunucuya hangi IP adreslerinin sizin alan adınızdan e-posta göndereceğini söyler. Bu kayıt yoksa alıcı sunucu göndereni doğrulayamaz ve e-postayı şüpheli sayarak spam filtresine yönlendirir. Doğru bir SPF kaydı v=spf1 include:posta-saglayicisi.com ~all biçiminde TXT kaydı olarak DNS'e eklenir.
Hayır. DKIM şifreleme değil, dijital imzalama işlemi yapar. E-postanın belirli başlıklarını ve gövdesini özel anahtarla imzalar; alıcı sunucu DNS'teki açık anahtarla imzayı doğrular. İçerik gizliliği için ayrıca TLS iletim şifrelemesi ya da uçtan uca şifreleme (S/MIME, PGP) gereklidir.
6698 sayılı KVKK'nın 12/5. maddesi uyarınca kişisel veri ihlalinin tespitinden itibaren en geç 72 saat içinde KVKK'ya bildirim yapılması zorunludur. İhlal aynı zamanda ilgili kişileri olumsuz etkiliyorsa onlara da "en kısa sürede" bildirim yapılmalıdır. Bildirim, Kurul'un belirlediği form ile e-Devlet üzerinden iletilir.
Yasak değil, ancak koşullu. KVKK madde 8 ve 9 uyarınca özel nitelikli kişisel veriler (sağlık verisi dahil), açık rıza olmaksızın yalnızca kanunda sayılan istisnalara dayanılarak aktarılabilir. Aktarım şifreli kanal üzerinden yapılmalı ve kayıt altına alınmalıdır. Şifreli iletim için S/MIME sertifikası veya şifreli ek yöntemi tercih edilmektedir.
MFA, hesap ele geçirme riskini önemli ölçüde azaltır ancak tek başına yeterli değildir. Kimlik avı saldırılarının ileri versiyonları (adversary-in-the-middle / AiTM), gerçek zamanlı oturum çalma yoluyla MFA'yı atlayabilir. Bu nedenle MFA'ya ek olarak kimlik avına dirençli kimlik doğrulama (FIDO2/geçiş anahtarı), koşullu erişim politikaları ve e-posta kimlik doğrulama protokolleri birlikte kullanılmalıdır.
İletim güvenliği için TLS 1.2 minimum, TLS 1.3 önerilir. Uçtan uca şifreleme gerektiren senaryolarda (örn. hasta-hekim yazışması) S/MIME (RFC 5751) veya OpenPGP (RFC 4880) kullanılabilir. Türkiye'de e-imza altyapısı açısından 5070 sayılı Elektronik İmza Kanunu ve Kamu Sertifikasyon Merkezi (Kamu SM) sertifikaları referans alınmalıdır.
6563 sayılı ETK ve buna dayalı BTK Yönetmeliği (2015) uyarınca ticari elektronik ileti göndermek için alıcıdan önceden onay (opt-in) alınması şarttır. Onay belgesi en az üç yıl saklanmalıdır. Her iletide gönderenin ticaret unvanı, adres bilgisi ve kolayca kullanılabilir bir ret/abonelikten çıkma imkânı bulunmalıdır. Ret talebinin 3 iş günü içinde yerine getirilmesi gerekmektedir.
Kesin bir süre kanunda belirtilmemiş olmakla birlikte Sağlık Bakanlığı'nın hasta kayıtlarına ilişkin düzenlemeleri ve KVKK'nın hesap verebilirlik ilkesi (madde 4/f) bir arada değerlendirildiğinde e-posta loglarının en az 3 yıl, idari ve hukuki işlemlerde delil niteliği taşıyabilecek yazışmaların ise 10 yıla kadar saklanması tavsiye edilmektedir. Saklama süresi sonunda güvenli silme (NIST SP 800-88 standardı) uygulanmalıdır.
DMARC, iki tür rapor üretir: toplu (aggregate / RUA) ve adli (forensic / RUF) raporlar. Bu raporlar ham XML biçiminde gelir. Google Postmaster Tools, dmarcian, Valimail ve MXToolbox gibi ücretsiz veya ücretli platformlar raporları görselleştirerek yetkisiz gönderici kaynaklarını ve başarısız kimlik doğrulamaları hızlıca tespit etmenizi sağlar.
Evet. SPF, DKIM ve DMARC yapılandırmaları, DNS panelinde yapılan TXT kayıt eklemeleri ile herhangi bir yazılım satın alınmadan gerçekleştirilebilir. Kurumsal e-posta hizmeti (Microsoft 365, Google Workspace gibi) kullanan klinikler için bu sağlayıcılar DKIM anahtarı oluşturma ve SPF kaydı kılavuzlarını yönetici konsolunda sunmaktadır. MTA-STS politikası ise yalnızca bir HTTPS dosyası yayımlamayı gerektirmektedir.
Reklamsız, KVKK uyumlu; kurulum ve geçiş ücretsiz, mailleri biz taşırız.