Veri Yerelleştirme ve KVKK/GDPR Uyumlu Hosting: Hangi Ülkede ve Bölgede Host Etmelisiniz?

Veri Yerelleştirme Neden Bu Kadar Gündemde?

Son birkaç yılda neredeyse her proje planlama toplantısında aynı soruyla karşılaşıyoruz: “Bu sistemi Türkiye’de mi, Avrupa’da mı, yoksa global bir bölgede mi host etmeliyiz ki KVKK ve GDPR açısından başımız ağrımasın?” Özellikle müşteri verisi, loglar, yedekler ve üçüncü taraf servisler işin içine girdiğinde, sadece teknik değil, hukuki bir mimari de tasarlamanız gerekiyor. Yanlış bir lokasyon seçimi; ileride veri aktarımı yasakları, idari para cezaları ya da sözleşme ihlalleri gibi sonuçlar doğurabiliyor.

Bu yazıda, DCHost tarafında sık gördüğümüz gerçek senaryolardan yola çıkarak veri yerelleştirme kavramını sadeleştireceğiz ve KVKK/GDPR uyumlu hosting için hangi ülke ve bölgenin ne zaman mantıklı olduğunu somut şekilde anlatacağız. Teknik detaylara, çok bölgeli (multi-region) mimarilere, log ve yedek politikalarına kadar inip, sonunda da uygulayabileceğiniz net bir kontrol listesi bırakacağız. Hukuk ekibinizle birlikte çalışırken, elinizde teknik açıdan sağlam bir çerçeve olsun istiyoruz.

Temeller: Veri Yerelleştirme, KVKK ve GDPR Ne Diyor?

Veri yerelleştirme nedir?

Veri yerelleştirme, belirli türdeki verilerin belirli bir ülke veya bölge sınırları içinde saklanması, işlenmesi ve mümkünse o sınırlar dışına çıkarılmaması gerekliliğini ifade eder. Her zaman mutlak bir yasak değildir; çoğu zaman “yurtdışına aktarım şartları” üzerinden dolaylı biçimde tanımlanır. Hem KVKK hem de GDPR tarafında kritik olan nokta, kişisel verinin hangi ülkede, hangi hukuki rejimin altında işlendiği ve aktarıldığıdır.

Kişisel veri ve veri sorumlusu / işleyen rolleri

Hem KVKK hem GDPR’da birkaç temel kavram ortak:

• Kişisel veri: Kimliği belirli veya belirlenebilir gerçek kişiye ilişkin her türlü bilgi.
• Veri sorumlusu: Hangi verinin, hangi amaçla, ne kadar süre işleneceğine karar veren kişi/şirket.
• Veri işleyen: Veri sorumlusu adına veriyi işleyen; örneğin hosting sağlayıcınız.

Hosting tercihinde, siz çoğu zaman veri sorumlususunuz, DCHost gibi altyapı sağlayıcılar ise veri işleyen pozisyonunda. Dolayısıyla hangi ülke ve bölgede sunucu kullanacağınız, doğrudan sizin sorumluluğunuzda; ancak bunu teknik olarak doğru kurmak ve belgelendirmek bizim sorumluluğumuzla kesişiyor.

KVKK’nın yurtdışına veri aktarımı yaklaşımı

KVKK’da odak nokta, Türkiye’den yurtdışına kişisel veri aktarımıdır. Basitleştirerek söyleyelim:

• Veri Türkiye içindeki sunucularda işleniyorsa, yurtdışına aktarım hükümleri devreye girmez.
• Veri Türkiye dışındaki bir ülkede saklanıyor veya işleniyorsa, bu çoğunlukla “yurtdışına aktarım” sayılır.
• Bu aktarım için kanundaki hukuki şartların (açık rıza, yeterli koruma listesi, taahhütname ve Kurul onayı gibi) sağlanması gerekir.

Detaylı teknik-uyum stratejisini parçalara ayırdığımız yazımız olan KVKK ve GDPR uyumlu hosting nasıl kurulur? rehberine de mutlaka göz atmanızı öneririz.

GDPR’da EEA içi / dışı veri aktarımı

GDPR tarafında ise odak Avrupa Ekonomik Alanı (EEA) içi ve dışı aktarımda:

• Veri AB/EEA içindeki sunucularda işleniyorsa, genellikle ek aktarım mekanizmasına gerek yoktur.
• Veri AB/EEA dışına aktarılıyorsa, adequacy decision (yeterlilik kararı) olan ülkelere aktarım kolaylaştırılır.
• Diğer ülkeler için Standart Sözleşme Maddeleri (SCC) gibi ek hukuki mekanizmalar gerekir.

Yani, Avrupa odaklı bir SaaS projeniz varsa, hem kvkk’ya hem GDPR’a bakarak iki taraflı bir mimari düşünmeniz gerekebilir.

Hangi Veri Nerede Durmalı? Önce Sınıflandırma Yapın

Lokasyon kararı vermeden önce, veriyi kabaca sınıflandırmak işleri çok kolaylaştırır:

• 1. Operasyonel veritabanı: Müşteri kayıtları, siparişler, kullanıcı hesapları.
• 2. Loglar: Erişim logları, uygulama logları, güvenlik logları.
• 3. Yedekler: Veritabanı backup’ları, dosya yedekleri, imajlar.
• 4. Analitik ve izleme verisi: Self-hosted analytics, A/B test verileri, performans metrikleri.

KVKK ve GDPR uyumlu bir mimaride çoğu zaman şu strateji uygulanır:

1. En kritik ve güncel kişisel veriler (operasyonel DB) için sıkı veri yerelleştirme (TR veya EEA içi).
2. Loglar ve analitik için anonimleştirme / maskeleme ve daha esnek lokasyon.
3. Yedekler içinse hem yerel hem farklı bölge kombinasyonları; ama yine hukuki dayanakları net.

Özellikle loglarınızda IP adresi, kullanıcı ajanı, oturum kimliği gibi verileri işliyorsanız, KVKK ve GDPR için log anonimleştirme rehberimizde anlattığımız IP maskeleme ve pseudonymization tekniklerini mutlaka devreye almanızı öneririz.

KVKK Açısından Hosting Lokasyonu: Türkiye, Avrupa, Diğer Bölgeler

1. Tamamen Türkiye içi hosting ne zaman gerekli?

Aşağıdaki durumlarda Türkiye içi veri yerelleştirme neredeyse standart beklenti haline geldi:

• Bankacılık, finans, telekom, sağlık gibi regülasyonu ağır sektörler.
• Çoğunlukla Türkiye’de mukim bireylere hizmet veren KOBİ ve kurumsal yapılar.
• Kamu kurumlarıyla entegrasyonu olan projeler.

Bu tip projelerde teknik karar genellikle şöyle olur:

• Operasyonel veritabanı ve dosyalar Türkiye’deki veri merkezinde tutulur.
• Yedeklerin bir kopyası yine Türkiye içinde, farklı bir veri merkezinde barındırılır.
• Yurtdışına aktarılan tek veri, anonimleştirilmiş loglar veya toplulaştırılmış istatistikler olabilir.

Biz DCHost tarafında bu senaryolarda, müşteriye önce TR içi tek bölge, sonrasında ise TR içi yedek bir bölge ile 3-2-1 yedek stratejisi kurmasını öneriyoruz. 3-2-1 stratejisinin pratik kurulumunu anlattığımız 3-2-1 yedekleme rehberine bakarak bunu kolayca uygulayabilirsiniz.

2. Türkiye + Avrupa hibrit mimari

Hem Türkiye’de kullanıcılarınız var hem de AB vatandaşlarına hizmet veriyorsanız, çok sık gördüğümüz mimari şu:

• TR lokasyon: Türkiye Cumhuriyeti vatandaşlarının asıl veritabanı ve dosyaları.
• EEA içi lokasyon: AB vatandaşlarına ait veri setinin ayrı tutulduğu veritabanı.
• Uygulama katmanı, GeoIP veya kullanıcı tercihiyle doğru veritabanına yönlendirir.

Böylece KVKK kapsamında Türkiye’de mukim kullanıcıların verisi Türkiye sınırları içinde kalırken, GDPR kapsamındaki kullanıcılar için EEA içi işleme sağlanmış olur. Bu tür çok bölgeli yapıların DNS ve ağ tarafını detaylı anlattığımız GeoDNS ve çok bölgeli hosting mimarisi rehberi de işin ağ bacağını tasarlarken oldukça yardımcı olur.

3. KVKK’ya göre yurtdışındaki bulut / veri merkezleri

Eğer veriyi Türkiye dışındaki bir ülkede host edecekseniz, KVKK açısından şu başlıkları netleştirmeniz gerekir:

• Veri aktaracağınız ülke yeterli koruma listesinde mi?
• Değilse, Kurul tarafından onaylı taahhütname veya benzeri mekanizmalar var mı?
• Açık rıza alıyorsanız, bu rıza gerçekten bilgilendirilmiş ve özgür iradeye dayanıyor mu?

Teknik tarafta ise şunları yapmanız gerekir:

• Hosting sağlayıcınızla veri işleyen sözleşmesini imzalamak.
• Verinin hangi ülkede fiziksel olarak tutulduğunu netleştirmek.
• Yedeklerin ve logların hangi bölgede saklandığını ayrıca belirtmek.

Burada temel prensip şu: verinin fiilen nerede olduğu kadar, hukuken hangi rejime tabi olduğu da önemli. Dolayısıyla sadece IP yakınlığına bakarak lokasyon seçmek artık yeterli değil.

GDPR Açısından Hosting Lokasyonu: EEA, Birleşik Krallık ve Diğerleri

AB odaklı projelerde varsayılan yaklaşım

Veri sorumlusu AB’de yerleşikse ya da AB’deki kullanıcılara yoğun hizmet veriyorsanız, en güvenli başlangıç noktası şudur:

• Operasyonel veritabanı ve dosya depolama EEA içindeki bir veri merkezinde olsun.
• İş sürekliliği için yedekler yine EEA içinde, tercihen farklı bir ülkede dursun.
• EEA dışındaki loglama veya analitik servisler kullanılacaksa, bunlar için SCC + ek koruma önlemleri alınsın.

Bu yaklaşım, hem GDPR’ın veri aktarımı kurallarını sadeleştirir hem de denetim anında savunması kolay bir çerçeve sunar.

Bir projede hem KVKK hem GDPR geçerliyse

Diyelim ki şirket Türkiye’de, AB’de de müşterileriniz var. Bu durumda:

• Türkiye mukimi kullanıcılar için KVKK’ya uygun bir TR lokasyonu.
• AB mukimi kullanıcılar için GDPR’a uygun bir EEA lokasyonu.
• Her iki bölge için de ayrı log, yedek ve silme politikaları.

Burada asıl zorluk, tek kod tabanıyla iki farklı hukuki rejimi yönetmek. Bu nedenle uygulama katmanında kullanıcıyı doğru bölgede işlemeyi ve doğru veritabanına yazmayı sağlayan bir segmentasyon kurgulamanız gerekir. Çok kiracılı (multi-tenant) SaaS mimarisi kullanıyorsanız, multi-tenant veritabanı ve hosting rehberimizde anlattığımız yapılar bu segmentasyonu kurgularken oldukça işinize yarar.

Karar Matrisi: Hangi Projeyi Nerede Host Etmelisiniz?

Şimdi en sık gelen senaryolar üzerinden gidelim ve her biri için pratik lokasyon önerisi çıkaralım.

Senaryo 1: Sadece Türkiye odaklı KOBİ web sitesi / e-ticaret

• Kullanıcı kitlesi: Büyük oranda Türkiye’de.
• Veri türü: Üyelik verileri, siparişler, fatura bilgileri.
• Önerilen hosting bölgesi: Türkiye veri merkezleri.

Bu senaryoda operasyonel verinin Türkiye dışına çıkması çoğu zaman gereksiz risk ve karmaşıklık yaratır. TR lokasyonlu bir VPS, dedicated veya paylaşımlı hosting, KVKK uyumunu sadeleştirir; aynı zamanda Türkiye’den erişim için gecikme süresini de düşürür. Sunucu lokasyonunun SEO ve gecikme üzerindeki etkilerini detaylı incelediğimiz sunucu lokasyonu ve SEO rehberine mutlaka göz atın.

Senaryo 2: Hem TR hem AB’ye hizmet veren SaaS

• Kullanıcı kitlesi: Türkiye + birkaç AB ülkesi.
• Veri türü: Hesaplar, faturalama, kullanım istatistikleri.
• Önerilen hosting bölgesi: TR + EEA hibrit.

Burada en sağlıklı yol, iki ayrı mantıksal bölge kurmaktır:

• “TR cluster” ve “EU cluster” gibi ayrı veritabanları ve dosya depoları.
• Kullanıcı kayıt olurken ülkesine göre ilgili kümeye atanır.
• Merkezi yönetim paneli, her iki bölgeden anonimleştirilmiş/aggregated rapor çeker.

Böylece KVKK ve GDPR yükümlülüklerini net sınırlarda yönetirsiniz; gerektiğinde bir bölgedeki verileri tamamen silebilmek de çok daha kolay olur.

Senaryo 3: Global B2B SaaS, merkezi Türkiye’de

• Kullanıcı kitlesi: Türkiye + AB + diğer ülkeler.
• Veri türü: Hesap verileri, proje/iş verisi, loglar.
• Önerilen hosting bölgesi: EEA merkezli ana cluster + TR’de ayrı cluster veya yedek.

Global bir ürün geliştiriyorsanız, çoğu zaman ana cluster’ı EEA içinde konumlandırmak GDPR uyumu açısından avantajlıdır. Türkiye’deki müşteriler içinse:

• Ya EEA’daki cluster üzerinden, gerekli KVKK aktarım şartları sağlanarak hizmet verilir.
• Ya da TR’de ek bir cluster açılıp Türkiye mukimleri burada tutulur.

Hangi yolun sizin için uygun olduğuna karar verirken, hukuki danışmanlığınızın önerilerini, SLA beklentilerini ve operasyonel bakım maliyetlerini birlikte düşünmeniz gerekir.

Senaryo 4: İç sistemler, intranet ve sadece çalışan verisi

• Kullanıcı kitlesi: Sadece çalışanlar (TR merkezli şirket).
• Veri türü: Personel bilgileri, İK süreçleri.
• Önerilen hosting bölgesi: Türkiye içi veya şirket veri merkezine yakın colocation.

Bu tip projelerde çoğu zaman dış dünyaya açık bir servis değil, kapalı intranet veya VPN üzerinden erişilen paneliniz olur. Bu nedenle:

• Türkiye içi dedicated sunucu veya colocation mimarisi tercih edilir.
• Yedekler, yine Türkiye içinde veya hukuken güvenli gördüğünüz bir ikinci bölgede tutulur.

Colocation tarafına ilgi duyuyorsanız, colocation ile kendi sunucunuzu barındırmanın avantajlarını detaylı anlattığımız rehbere de göz atabilirsiniz.

Teknik Mimaride Veri Yerelleştirmeyi Destekleyecek Örüntüler

1. Bölge bazlı veritabanı ayrımı

En net veri yerelleştirme stratejisi, bölge bazlı fiziksel veya mantıksal veritabanı ayrımıdır:

• db_tr: Türkiye mukimi kullanıcılar.
• db_eu: AB/EEA mukimi kullanıcılar.
• db_other: Diğer ülkeler (gerekliyse).

Uygulama katmanı, kullanıcı kayıt olurken veya login olduğunda hangi veritabanını kullanacağını belirler. Böylece bir gün bir bölgeyi tamamen farklı ülkeye taşımak isterseniz, diğerlerini etkilemeden migration yapabilirsiniz.

2. Çok bölgeli DNS ve edge katmanı

GeoDNS veya benzeri çözümlerle şu mantığı kurabilirsiniz:

• tr.example.com → Türkiye veri merkezi.
• eu.example.com → EEA veri merkezi.
• app.example.com → Kullanıcının IP/coğrafyasına göre doğru bölgeye yönlendiren bir edge katmanı.

Böylelikle hem gecikmeyi düşürür hem de veri yerelleştirme politikanızla ağ topolojinizi uyumlu hale getirirsiniz.

3. Ayrı log ve yedek politikaları

KVKK ve GDPR uyumlu bir mimaride log ve yedeklerin, operasyonel veriden farklı politikalara sahip olması gerekir:

• TR kullanıcılarının logları Türkiye’de; AB kullanıcılarının logları EEA’da tutulabilir.
• Loglarda IP ve kullanıcı kimliğini maskeleyip, saklama sürelerini sınırlayabilirsiniz.
• Yedekler için ise 3-2-1 stratejisiyle hem aynı bölgede hem farklı bölgede kopyalar oluşturabilirsiniz.

Özellikle log ve yedek saklama sürelerini belirlerken, yedek saklama süresi ve KVKK/GDPR dengesi ile hosting ve e-posta altyapısında log saklama süreleri rehberlerimizi okuyup, kendi dokümantasyonunuzla eşleştirmenizi tavsiye ederiz.

Üç Kritik Alan: Loglar, Yedekler ve Üçüncü Taraf Servisler

1. Loglar: En çok gözden kaçan kişisel veriler

Erişim loglarında IP adresi, user-agent, referrer, oturum kimlikleri gibi veriler bulunduğu için, bunlar da kişisel veri kapsamına girebilir. Bu nedenle:

• Loglarınız nerede saklanıyor? Hangi ülkede, hangi depolama servisinde?
• Ne kadar süreyle saklanıyor? KVKK/GDPR ile uyumlu bir retention süreniz var mı?
• IP maskeleme veya anonimleştirme yapıyor musunuz?

Biz, DCHost müşterilerinde log mimarisi tasarlarken mutlaka IP maskeleme, pseudonymization ve sınırlı saklama süresi prensiplerini öneriyoruz. Özellikle merkezi loglama sistemleri kuruyorsanız, bu verilerin hangi ülkede tutulduğunu net olarak belgeleyin.

2. Yedekler: Asıl veriden daha uzun yaşayan kopyalar

Yedekler genellikle operasyonel veriden daha uzun süre saklanır. Bu da şu soruyu doğurur: “Kullanıcı verisini sildim, ama yedeklerde ne kadar süre daha kalacak?”

• Yedeklerin fiziksel olarak hangi ülkede tutulduğunu netleştirin.
• Saklama süresini (ör. 30, 90, 180 gün) veri işleme amacınızla uyumlu belirleyin.
• Felaket kurtarma senaryosunda hangi ülkeye replikasyon yapıldığını dokümante edin.

Burada amaç, veriyi sonsuza kadar tutmak değil, iş sürekliliği ile hukuki yükümlülükler arasında makul bir denge kurmak. Bu dengeyi nasıl kuracağınızı detaylandırdığımız yedekleme stratejisi ve RPO/RTO rehberi de planlama aşamasında işinize yarayacaktır.

3. Üçüncü taraf SaaS ve CDN servisleri

Hosting altyapınız KVKK/GDPR uyumlu olsa bile, entegre ettiğiniz üçüncü taraf servisler veriyi beklemediğiniz ülkelere götürebilir:

• CDN sağlayıcınız, logları hangi ülkede veya bölgede saklıyor?
• Analitik, hata izleme, e-posta pazarlama gibi SaaS araçlarınız veriyi nerede işliyor?
• Bu servislerle imzaladığınız veri işleyen sözleşmelerinde ülke/bölge açıkça yazıyor mu?

Bu yüzden, veri envanterinizi çıkarırken sadece “sunucu nerede?” sorusunu değil, “veri hangi servisler üzerinden hangi ülkelere akıyor?” sorusunu da yanıtlayın. Uyumlu hosting mimarisinin sınırı, çoğu zaman sadece kullandığınız sunucuyla değil, eklediğiniz her bir entegrasyonla yeniden çizilir.

DCHost Tarafında Uygulanabilir Adımlar: Kontrol Listesi

Projeyi bizimle planlarken aşağıdaki soruları birlikte netleştirdiğimizde, veri yerelleştirme kararınız çok daha sağlıklı hale geliyor:

1. Hedef kullanıcı kitlesi: Sadece Türkiye mi, Türkiye + AB mi, yoksa global mi?
2. Veri türleri: Sadece basit iletişim formları mı, yoksa ödeme, sağlık, finans verisi gibi hassas kategoriler de var mı?
3. Hukuki dayanak: KVKK/GDPR tarafında açık rıza, sözleşme, meşru menfaat gibi hangi temellere dayanıyorsunuz?
4. Lokasyon sınırları: Hukuk ekibiniz “veri mutlaka TR içinde kalsın” mı diyor, yoksa EEA içi de kabul edilebilir mi?
5. Yedek ve log politikası: Saklama süreleri, anonimleştirme, yurtdışına replikasyon konusunda net kurallarınız var mı?
6. Üçüncü taraflar: CDN, e-posta, analitik, CRM gibi araçların veri lokasyonlarını biliyor musunuz?

Bu sorular netleştikten sonra, DCHost tarafında size;

• TR ağırlıklı,
• TR + EEA hibrit,
• veya daha global ölçekte çok bölgeli

bir mimari önerebiliyoruz. VPS, dedicated sunucu veya colocation seçenekleri arasından, hem bütçenize hem de uyum gereksinimlerinize en uygun kombinasyonu teknik olarak birlikte tasarlıyoruz.

Sonuç: Veri Yerelleştirme Kararı Sadece “Sunucuyu Nereye Kuralım?” Değil

Veri yerelleştirme ve KVKK/GDPR uyumlu hosting; sadece “Türkiye mi, Avrupa mı?” sorusuna indirgenebilecek kadar basit değil. Hangi veri türünün nerede tutulduğu, log ve yedeklerin hangi ülkede saklandığı, üçüncü taraf servislerin veriyi nereye taşıdığı ve tüm bunların nasıl belgelendiği birlikte ele alınmalı. Sağlam bir mimari kurduğunuzda hem denetim anında eliniz güçlü olur hem de ileride bölge eklemek veya taşımak istediğinizde, sisteminizi zorlamadan evrimleştirebilirsiniz.

DCHost olarak biz, projeyi konuşurken sadece CPU, RAM ve diskten değil, veri akış haritanızdan da başlama eğilimindeyiz. Kullanıcı kitlenizi, yasal gereksinimlerinizi ve büyüme planlarınızı paylaştığınızda; Türkiye içi, Avrupa odaklı veya hibrit bir mimariyle bunu nasıl hayata geçirebileceğinizi teknik olarak birlikte tasarlayabiliriz. Projeniz hangi aşamada olursa olsun, veri yerelleştirme ve KVKK/GDPR uyumunu masaya yatırmak istiyorsanız, altyapı ekibimizle detaylı bir değerlendirme yapmak için bizimle iletişime geçmeniz yeterli.