GDPR ve Posta Sunucusu Konumu: Sınır Ötesi Aktarımı Coğrafyayla Değil Veri Yoluyla Değerlendirmek
"Sunucu Frankfurt'ta, o yüzden GDPR uyumluyuz" bir mühendislik ifadesi değil, bir temenni. GDPR'ın V. Bölümü coğrafyayı değil erişimi düzenler. Bu yazıda posta sunucusu konumunu haritadaki bir pin olarak değil, SMTP zincirinin her hop'una yayılmış bir veri yolu olarak değerlendiriyoruz.
EvilMail Team5 Ağustos 202612 dk okuma
Bir müşteri Almanya'daki bir kullanıcıya sözleşme gönderiyor. Alan adının birincil MX'i Falkenstein'daki Hetzner sunucunuzda; Maildir /var/mail/vhosts/ altında, AB toprağında duruyor. Uyumlu, değil mi? Şu üç satırı çalıştırana kadar öyle görünüyor: dig +short MX çıktısındaki ikincil MX bir ABD Mailgun bloğuna çözümleniyor, rspamd içerik puanlaması için ABD merkezli bir reputation API'sine POST atıyor ve Postfix logları Grafana Cloud'un us-east bölgesine akıyor. Mesaj AB'den AB'ye gidiyordu; ama içeriği, zarfı ve gönderenin IP'si çoktan üç ayrı üçüncü ülke sistemine erişilebilir hâle geldi.
İşte bu yüzden "sunucu konumu" tek bir pin değildir. Bir veri yolu (data path) meselesidir. GDPR'ın uluslararası aktarım rejimi, verinin datacenter'a nerede indiğini değil, o veriye kimin — hangi yargı yetkisi altındaki hangi aktörün — ulaşabildiğini sorar. Değerlendirmeyi haritadaki noktaya göre değil, SMTP zincirinin her hop'una, at-rest depolamaya, log ve yedek akışına ve operatörün tabi olduğu hukuka göre yaparız. Konumu seçmezsiniz; veri yolunu tasarlarsınız.
"Aktarım" hukuken ne demek — coğrafya değil erişim
GDPR'da uluslararası aktarımlar V. Bölüm'de, Madde 44-50 arasında düzenlenir. Madde 44 genel ilkeyi koyar: üçüncü bir ülkeye aktarım ancak Bölüm'ün tüm koşulları sağlandığında yapılabilir. Madde 45 yeterlilik (adequacy) kararını, 46 uygun güvenceleri (SCC/BCR), 47 bağlayıcı kurumsal kuralları, 48 üçüncü ülke otorite ve mahkeme kararlarının AB'de doğrudan icra edilemezliğini, 49 ise dar ve istisnai derogasyonları düzenler.
Kritik nokta EDPB'nin "aktarım" tanımıdır. Aktarım, veriyi fiziksel olarak bir yerden bir yere "göndermek" değil, veriyi üçüncü ülkedeki bir alıcı için erişilebilir kılmaktır. Yani veri Falkenstein'da dursa bile, ABD'deki bir operatör ona uzaktan erişebiliyorsa aktarım gerçekleşmiştir.
E-posta bağlamında "kişisel veri" beklediğinizden geniştir. Sadece gövde değil; Subject, From/To/Cc zarf adresleri, tüm başlıklar ve Received: satırlarındaki istemci IP adresi de kişisel veridir. Recital 30 IP adreslerini açıkça sayar, CJEU'nun Breyer kararı (C-582/14) dinamik IP'nin bile kişisel veri olduğunu teyit eder. Transit halindeki veri de veridir: bir mesaj bir MTA kuyruğunda saniyeler kalsa bile o an erişilebilir kişisel veridir. Ve asıl kör nokta burada belirir — operatörün tabi olduğu hukuk. Buna birazdan CLOUD Act başlığında döneceğiz.
Postanın gerçek yolu: her hop bir potansiyel aktarım
Tek bir mesajın dokunduğu sistemleri sayın: submission (587) → giden MTA → alıcı birincil MX → backup/ikincil MX → içerik ve AV taraması (rspamd, ClamAV, harici reputation API) → DKIM imzalama → arşiv/journaling → şifre sıfırlama gibi transactional API'ler. Her birinin ayrı bir konumu ve ayrı bir operatörü olabilir. Uyum, bu zincirin en zayıf hop'u kadar güçlüdür.
İkincil MX'inizin nerede olduğunu bilmiyorsanız, şununla başlayın:
Gelen bir mesajın gerçek güzergahını görmek için Received: başlıklarını alttan yukarıya okuyun: her hop bir zaman damgası, bir IP ve çoğu zaman coğrafi ipucu bırakır. O IP'lerden herhangi biri EEA dışına düşüyorsa, o mesajın kişisel verisi orada erişilebilir olmuştur.
Konum seçiminin üç hukuki katmanı
Sunucu konumunu değerlendirirken birbirinden ayrı üç katmanı karıştırmayın.
1. At-rest depolama konumu. Maildir veya veritabanının fiziksel olarak durduğu yer. En görünür katman ve genellikle tek düşünülen katman — ama üçünün en önemsizidir.
2. Transit güzergahı ve şifreleme. Mesajın hangi ağlardan geçtiği ve bu geçişin şifreli olup olmadığı. Bir mesaj EEA içindeki iki nokta arasında gitse bile, ara bir relay üçüncü ülkedeyse transit orada görünür hâle gelir.
3. Operatörün tabi olduğu hukuk — asıl kör nokta. Frankfurt'taki bir AWS eu-central-1 veya Azure bölgesi fiziksel olarak AB toprağındadır, ama işleten şirket ABD'ye tabidir. US CLOUD Act (2018) ABD yargısına tabi bir sağlayıcıyı, veri fiziksel olarak AB'de dursa bile ifşaya zorlayabilir. GDPR Madde 48 bu tür üçüncü ülke kararlarını AB'de doğrudan icra edilemez sayar — ama bu, sağlayıcıyı ABD'de bekleyen yaptırımdan kurtarmaz. Sonuç: iki hukuk sistemi arasında sıkışmış bir sağlayıcı ve sizin üstünüzde kalan gerçek bir risk.
"Datacenter AB'de ama şirket ABD'de" ikilemi tam da burada doğar. Bu yüzden veri egemenliğini (data sovereignty) ciddiye alan kurumlar ya AB-egemen (sovereign) bulut tekliflerine ya da tümüyle AB'ye tabi bağımsız barındırıcılara — Hetzner, OVH, Scaleway, netcup — yönelir. evilmail altyapısını AB kökenli bağımsız sağlayıcılar üzerinde tutmamızın nedeni tam olarak bu: CLOUD Act yüzeyini baştan sıfırlamak, sonradan SCC ile yamamaktan ucuzdur.
2026 itibarıyla yeterlilik haritası ve mekanizma seçimi
Aktarım gerçekten gerekiyorsa GDPR üç yol sunar, net bir öncelik sırasıyla.
Yeterlilik kararı (Madde 45) en temiz yoldur; ek mekanizma gerektirmez. 2026 itibarıyla yeterli kabul edilen ülkeler: Andorra, Arjantin, Kanada (yalnızca ticari), Faroe Adaları, Guernsey, İsrail, Man Adası, Japonya, Jersey, Yeni Zelanda, Güney Kore, İsviçre, Birleşik Krallık ve Uruguay. ABD için özel durum var: EU-US Data Privacy Framework, 10 Temmuz 2023 yeterlilik kararıyla geçerlidir — ama yalnızca DPF listesine self-sertifikalı ABD alıcıları için. Sertifikayı dataprivacyframework.gov listesinden doğrulamadan DPF'e güvenmeyin. Ayrıca DPF hukuken kırılgandır; Privacy Shield ve Safe Harbor'ın akıbetini gördük, "Schrems III" riski masadadır. DPF'i tek bacaklı bir çözüm olarak değil, SCC ile desteklenen bir katman olarak kurgulayın.
Uygun güvenceler (Madde 46) yeterlilik yoksa devreye girer. Güncel Standart Sözleşme Hükümleri, Komisyon Uygulama Kararı (EU) 2021/914 ile gelen dört modüldür (C2C, C2P, P2P, P2C). Ama Schrems II (CJEU C-311/18, 16 Temmuz 2020) sonrası SCC imzalamak tek başına yetmez: her aktarım için bir Transfer Impact Assessment (TIA) zorunludur. TIA, hedef ülkenin hukukunun SCC güvencelerini pratikte etkisiz kılıp kılmadığını değerlendirir ve gerekirse ek teknik önlemleri (şifreleme, pseudonymization) şart koşar.
Madde 49 istisnaları (açık rıza, sözleşmenin ifası) dar ve istisnaidir — rutin bir e-posta akışını buna dayandırmayın. SCC'yi ne zaman atlayabilirsiniz? Yalnızca alıcı yeterli bir ülkedeyse veya geçerli bir yeterlilik kararı (DPF dahil, doğrulanmış sertifikayla) varsa. Onun dışında SCC + TIA dosyanız hazır olmalı.
Aktarımı kapatan teknik kontroller
En iyi TIA, aktarımı hiç yapmama ihtiyacını doğuran teknik mimaridir. İki cephede çalışın.
Transit tarafında opportunistic TLS yetmez — bir MITM, EHLO yanıtından STARTTLS'i düşürerek bağlantıyı düz metne indirebilir. Zorlayıcı katmanları ekleyin: MTA-STS enforce modu ve mümkünse DANE/TLSA (DNSSEC şarttır).
dns
; _mta-sts TXT: politikanın varlığını ve sürümünü ilan eder
_mta-sts.evilmail.pro. IN TXT "v=STSv1; id=20260704T120000Z"
# Postfix main.cf — alışta TLS mevcutsa kullan, gidişte DANE zorla
smtpd_tls_security_level = may
smtp_tls_security_level = dane
smtp_dns_support_level = dnssec
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
At-rest tarafında LUKS tam disk şifrelemesi tabandır, ama tek başına yalnızca çalınan diske karşı korur — çalışan sistemde veri düz görünür. Dovecot'un mail_crypt plugin'i posta kutusu düzeyinde şifreleme ekler:
En önemlisi de şu: erişimi AB içinde tutun. Spam/AV zincirini self-host edin — harici bir bulut reputation API'sine POST atmak yerine yerel rspamd + ClamAV kullanın. DKIM'i harici bir imzalama servisine değil, kendi sunucunuzda imzalayın. Her dışarı çıkan lookup, sessiz bir aktarım adayıdır.
Unutulan aktarımlar: loglar, yedekler, izleme
Denetimlerde en sık kaçırılan sızıntılar postanın kendisi değil, etrafındaki telemetridir. /var/log/mail.log içindeki her Postfix/Dovecot satırı istemci IP'si ve zarf adresleri içerir — yani kişisel veri. Bu logları Datadog'a veya Grafana Cloud'un us-east bölgesine gönderiyorsanız, tek bir mesaj bile EEA dışına çıkmadan aktarım gerçekleştirmiş olursunuz.
Aynısı yedekler için geçerli. borg, restic veya rsync deponuz nerede? Offsite replikasyonun hedef bölgesini doğrulayın — S3 uyumlu bir bucket'ın endpoint'i çoğu zaman sessizce us-east-1'e düşer. İzleme probları, uptime kontrolleri ve Sentry gibi hata izleme servisleri de payload'larında e-posta adresleri taşıyabilir.
Bir de retention'ı unutmayın: Madde 5(1)(e) verinin gereğinden uzun tutulmamasını ister. Sonsuza dek büyüyen bir log arşivi hem bir uyum hem de bir sorumluluk yüküdür. Depo bölgesini şöyle doğrulayın:
bash
# restic deposunun gerçekte hangi endpoint/bölgede olduğunu gör
restic cat config | grep -i repo
echo $RESTIC_REPOSITORY # s3:s3.eu-central-1.amazonaws.com/... olmalı, us-* değil
# log shipper'ın hedefini doğrula
grep -riE 'endpoint|region|url' /etc/vector/ /etc/promtail/
Karar çerçevesi ve checklist
Bir e-posta yığını için TIA'yı yönetilebilir tutmanın yolu şu üç adımdır: veri yolunu haritala → her hop için operatör + konum + mekanizma üçlüsünü yaz → boşlukları teknik kontrolle kapat. Konum başlamak için bir yerdir, bitiş değil.
İkincil/backup MX kimin, nerede? Sessizce bir US sağlayıcısına mı düşüyor?
Spam ve AV taraması nerede çalışıyor — self-host mu, harici bulut API mı?
Log toplayıcının bölgesi EEA içinde mi? (Vector/Promtail/Datadog hedefi)
Yedek deposunun bölgesi doğrulandı mı? (restic/borg/S3 endpoint)
At-rest şifreleme aktif mi? (LUKS + Dovecot mail_crypt)
Transitte MTA-STS enforce + DANE devrede mi?
Bir US alıcısına DPF ile mi güveniyorsunuz — sertifika dataprivacyframework.gov'da doğrulandı mı?
Yeterlilik yoksa SCC (2021/914) + yazılı TIA dosyası mevcut mu?
Retention/silme süresi tanımlı ve uygulanıyor mu? (Md. 5(1)(e))
Datacenter AB'de ama operatör ABD'ye mi tabi? CLOUD Act yüzeyi değerlendirildi mi?
Bu on bir maddeyi bir kez dürüstçe çalıştırın; "sunucumuz Frankfurt'ta" cümlesinin uyum hakkında ne kadar az şey söylediğini göreceksiniz. Konumu seçmek beş dakikalık iştir. Veri yolunu tasarlamak asıl mühendisliktir — ve GDPR'ın sorduğu tam olarak budur.
