KVKK ve GDPR denildiğinde çoğu işletmenin aklına ilk olarak çerez metinleri ve aydınlatma formu geliyor. Oysa işin görünmeyen, ama en kritik tarafı; verinin hangi ülkedeki hangi veri merkezinde tutulduğu, hangi sunucular arasında aktarıldığı ve yedeklerin nerede saklandığı. Yani doğrudan hosting mimariniz. Türkiye, Avrupa ve ABD arasında veri merkezi seçimi yaparken sadece performans ve maliyet değil, veri yerelleştirme, kişisel verilerin yurt dışına aktarımı ve hukuki sorumluluklar da işin içine giriyor.
Bu yazıda Türkiye, AB ve ABD veri merkezleri arasında seçim yaparken hangi verinin nerede tutulacağını, kimlerin erişeceğini, yedek ve log akışlarının nasıl yönetileceğini ele alıyoruz. Amaç, hukuki gereklilikleri performans ve işletim ihtiyaçlarıyla birlikte değerlendiren bir veri yerleşimi planı oluşturmaktır. Ülke seçimi tek başına KVKK veya GDPR uyumu sağlamaz; aşağıdaki senaryolar, somut veri akışınıza uyarlanacak mimari seçeneklerdir.
KVKK, GDPR ve Veri Yerelleştirme: Temeli Netleştirelim
Temel kavramlar: Sorumlu, işleyen, yurt dışına aktarım
Önce terminolojiyi sadeleştirelim. KVKK ve GDPR tarafında:
- Veri sorumlusu: Kişisel verilerin hangi amaçlarla ve nasıl işleneceğini belirleyen taraf.
- Veri işleyen: Veri sorumlusu adına kişisel veri işleyen taraf. Hosting hizmetindeki rol, fiilen yapılan işleme göre belirlenir; yalnızca fiziksel alan ve enerji sağlayan bir colocation hizmeti otomatik olarak veri işleyen sayılmaz.
- Yurt dışına aktarım: Yalnızca sunucunun sınır dışında bulunmasıyla açıklanamaz. Uygulanabilir hukuk, veriyi açıklayan sorumlu/işleyen ve yurt dışındaki ayrı alıcı birlikte değerlendirilir. Başka bir ülkedeki hizmet sağlayıcıya uzaktan erişim verilmesi de aktarım oluşturabilir.
Kurumun yurt dışına aktarım rehberi, Kanuna tabi bir veri sorumlusu veya işleyenin kişisel verileri yurt dışındaki başka bir sorumlu/işleyene iletmesini veya erişilebilir kılmasını esas alır. Türkiye’deki ana veritabanına yabancı destek şirketinin erişmesi, veriler taşınmasa da bu değerlendirmeye girer. CDN, e-posta, izleme, yedekleme ve alt işleyenleri de aynı akış haritasına ekleyin.
Veri yerleşimi, hukukun kapsamı ve aktarım ayrı konulardır
KVKK bütün kişisel verilerin her koşulda Türkiye’de tutulmasını emretmez; sektöre veya hizmete özgü yerelleştirme yükümlülükleri ayrıca incelenmelidir. GDPR bakımından da Avrupa coğrafyası ile AB/Avrupa Ekonomik Alanı (AEA) aynı değildir. GDPR madde 3, AB’deki bir kuruluşun faaliyetleri kapsamında işlemeyi ve AB dışında bulunan kuruluşların Birlik içindeki kişilere mal/hizmet sunması veya Birlik içindeki davranışlarını izlemesi gibi durumları kapsar. Vatandaşlık veya sunucu ülkesi tek başına belirleyici değildir. KVKK’nın somut faaliyete uygulanması ayrıca değerlendirilir.
Dolayısıyla gerçekçi hedef şu olmalı:
- Birincil veri yerleşimini uygulanabilir hukuk, varsa sektörel kısıtlar ve gerçek veri akışlarına göre seçin.
- Aktarım varsa önce geçerli hukuki mekanizmayı belirleyin; sözleşmeler ve teknik tedbirleri bu mekanizmanın koşullarına göre uygulayın.
- Yedek, log, analitik ve uzaktan destek için ayrı saklama, erişim ve aktarım kararları kaydedin.
KVKK ve GDPR’in hosting katmanına yansımasını daha detaylı anlatan rehberimiz olan KVKK ve GDPR uyumlu hosting nasıl kurulur? yazısına da mutlaka göz atmanızı öneririz.
Hosting Lokasyonu Seçimine Hukuki Açıdan Bakış
Türkiye’de sunucu: KVKK odağında yerel barındırma
Türkiye merkezli bir şirket için değerlendirilebilecek bir seçenek, uygulama ve veritabanı sunucularının Türkiye veri merkezlerinde tutulmasıdır. Bu sayede:
- Kişisel verilerin depolandığı asıl ortam yurt içi sayılır.
- Sağlayıcıyla yapılacak veri işleme sözleşmesinde teknik ve idari tedbirler ile tarafların sorumlulukları tanımlanmalıdır.
- Lokasyon seçimi tek başına uyum güvencesi değildir; süreçler ilgili karar ve rehberlere göre ayrıca değerlendirilmelidir.
Bu modelde de CDN, e-posta servisleri veya üçüncü taraf analitik araçları sebebiyle yurt dışına aktarım söz konusu olabilir; bu nedenle ana sunucuların Türkiye’de olması, çekirdek müşteri verisinin tüm kopyalarının Türkiye’de kaldığını göstermez. Yan servislere gönderilen veriler de envantere dahil edilmelidir.
AB’de sunucu: GDPR ve KVKK nasıl birlikte değerlendirilir?
AB pazarına odaklanan bir uygulamada AB içindeki bir veri merkezi teknik ve ticari açıdan uygun olabilir. Ancak veri yerleşimi, hukukun uygulanması ve aktarım koşulları için ayrı kontroller gerekir:
- Veritabanının AB’de tutulması yalnızca o kopyanın konumunu gösterir; destek, yedek ve alt işleyen konumlarını da kontrol edin.
- GDPR kapsamını işletmenin faaliyetleri ve madde 3 üzerinden belirleyin. AB’de sunucu kiralamak tek başına bütün işlemleri otomatik olarak GDPR kapsamına sokmaz.
- KVKK’ya tabi bir sorumlu/işleyenin AB’deki ayrı alıcıya veri açması, ilgili kişinin vatandaşlığından bağımsız olarak madde 9 kapsamında değerlendirilebilir.
2024’te değişen KVKK madde 9, yurt dışına aktarımı aşamalı olarak düzenler. Güncel aktarım planını şu ayrımlarla hazırlayın:
- İşleme şartı ve yeterlilik: Madde 5 veya 6’daki ilgili işleme şartını belirleyin. Aktarımın yapılacağı ülke, sektör veya uluslararası kuruluş hakkında geçerli bir Kurul yeterlilik kararı varsa kapsamını kontrol edin; AB veya ABD için kendiliğinden yeterlilik varsaymayın.
- Uygun güvence: Yeterlilik kararı yoksa işleme şartına ek olarak ilgili kişinin haklarını kullanabilmesi ve etkili kanun yollarına başvurabilmesi gerekir. Kurulun ilan ettiği standart sözleşme, Kurul onaylı bağlayıcı şirket kuralları, Kurul izni alınmış yazılı taahhütname veya yine Kurul izni gerektiren kamu kuruluşları arası anlaşma yollarından uygun olanını değerlendirin.
- Standart sözleşme: Taraf rollerine uygun Kurul metnini ve eklerini tamamlayın. İmzalar tamamlandıktan sonra beş iş günü içinde Kuruma bildirim gerekir. AB standart sözleşme maddeleri (SCC) Türk standart sözleşmesinin yerine geçmez.
- Arızi istisnalar: Yeterlilik ve uygun güvence yolları kullanılamıyorsa madde 9’daki sınırlı istisnalar yalnızca arızi aktarımlar için gündeme gelir. Muhtemel riskler açıklanarak alınan açık rıza, sürekli hosting veya düzenli replikasyon için genel bir kestirme yol değildir.
- Ayrı yükümlülükler: Aydınlatma metni, işleme şartı, veri işleyen sözleşmesi ve aktarım mekanizması birbirinin yerine geçmez. GDPR uygulanıyorsa madde 28’deki işleyen sözleşmesi/hukuki düzenleme ile 44–49’daki aktarım koşullarını da ayrıca sağlayın.
ABD’de sunucu: ABD pazarı için barındırma ve aktarım planlaması
ABD lokasyonu genellikle şu senaryolarda gündeme geliyor:
- ABD pazarı hedefleniyorsa (SaaS, oyun, medya platformları vb.).
- Analitik, loglama veya yedeklerin bir kopyası küresel bir altyapıda tutulmak isteniyorsa.
GDPR kapsamındaki ABD aktarımlarında AB yeterlilik kararının EU–US Data Privacy Framework (DPF) kapsamındaki alıcıya uygulanıp uygulanmadığını kontrol edin. Alıcının aktif kaydı, ilgili bağlı şirketi ve aktarılacak veri türlerini kapsamalıdır. DPF bütün ABD sağlayıcılarını kapsamaz ve KVKK için aktarım dayanağı değildir. Diğer GDPR yollarında, örneğin SCC kullanıldığında, alıcı ülkenin hukuk ve uygulamalarını değerlendirin; gerektiğinde etkili ek tedbirler alın.
- ABD’ye gönderilecek veriyi amaç için gerekli alanlarla sınırlayın; yedek veya analitik etiketi kapsamı kendiliğinden değiştirmez.
- Psödonimleştirme, kimlik bilgisini ayrı tutarak riski azaltabilir; veri hâlâ kişisel olabilir. Anonimleştirme ise yeniden ilişkilendirmeyi önlemelidir; yalnızca hash veya toplulaştırma kullanmak yeterli değildir.
- Şifreli yedekte anahtarların kimde olduğunu ve verinin nerede çözülebileceğini belirleyin. Sağlayıcının açık veriye ihtiyaç duyduğu bir hizmette TLS ve sağlayıcı kontrollü disk şifrelemesi aynı korumayı sağlamaz. Anahtarları Türkiye’de tutmak da tek başına GDPR aktarım koşullarını karşılamaz.
Varsayımsal bir tasarımda ana kopya Türkiye veya AB’de, felaket kurtarma (DR) kopyası ABD’de tutulabilir. Bu bir iş sürekliliği seçeneğidir; yedek kullanımının hukuken daha güvenli olduğu sonucu çıkarılamaz. Hem ilk replikasyon hem felakette verinin açılması, işlenmesi ve ana bölgeye geri dönüşü aktarım planına dahil edilmelidir.
Türkiye, AB ve ABD Veri Merkezlerini Karşılaştırma
Gecikme süresi, SEO ve kullanıcı deneyimi
Veri merkezinin bulunduğu ülke, sayfa açılış süresini ve API gecikmesini etkileyebilir; gerçek sonuç ağ rotasına, peering’e, uygulamaya ve önbelleğe bağlıdır. Hedef bölgelerden TTFB ve uygulama yanıt sürelerini ölçün. Sunucu konumu tek başına sıralama artışı sağlamaz. Sunucu lokasyonunun SEO’ya etkisi rehberi bu teknik ve arama görünürlüğü ayrımını ele alır.
- Türkiye hedefliyorsanız: Ana sunucunun Türkiye’de olması TTFB açısından avantaj sağlayabilir; KVKK değerlendirmesinde diğer veri akışları da dikkate alınmalıdır.
- Avrupa hedefliyorsanız: AB içindeki kullanıcılara yakın bir nokta gecikmeyi azaltabilir; GDPR uyumu yalnızca lokasyona bağlı değildir.
- Küresel kullanıcı kitlesinde: Coğrafi olarak dağınık kullanıcılar için çok bölgeli mimari (multi-region), maliyet ve işletim karmaşıklığıyla birlikte değerlendirilebilecek bir seçenektir.
Altyapı standartları ve veri merkezi şeffaflığı
Hangi ülkede olursa olsun, seçtiğiniz veri merkezinin ve hosting sağlayıcınızın aşağıdaki alanlarda şeffaf olması gerekir:
- Fiziksel güvenlik (kartlı geçiş, CCTV, ziyaretçi kaydı vb.)
- Enerji altyapısı (N+1 veya üstü yedeklilik, jeneratör kapasitesi)
- Ağ altyapısı (çoklu upstream, DDoS koruması, IPv6 desteği)
- Yangın ve iklimlendirme sistemleri
- Bilgi güvenliği sertifikaları (ör. ISO/IEC 27001): kapsamını, geçerliliğini ve seçilen hizmeti kapsayıp kapsamadığını doğrulayın; sertifika tek başına KVKK/GDPR uyumunu kanıtlamaz.
Veri merkezi kavramına daha teknik bir yerden bakmak isterseniz, veri merkezi nedir ve hosting için neden kritiktir yazımız size altyapı tarafını netleştirmede yardımcı olacaktır.
Türkiye, AB ve ABD: Kararı hangi koşullar değiştirir?
- Türkiye: Yerel depolama ve yerel destek, bazı yurt dışı akışları azaltabilir. GDPR’a tabi bir kuruluşun Türkiye’deki ayrı alıcıya aktarımı ayrıca değerlendirilir; yalnızca kullanıcının Avrupa’da yaşaması aktarımı tanımlamaz.
- AB: AB/AEA içinde kalan işlem zinciri GDPR aktarım analizini sadeleştirebilir. KVKK’ya tabi dışa aktarım, Türkiye’den erişim ve diğer ülkelerdeki alt işleyenler yine incelenmelidir.
- ABD: Hedef kitle, iş sürekliliği ve ağ ihtiyaçları için seçilebilir. Hukuki karar, alıcıya ve geçerli mekanizmaya bağlıdır; üretim ve yedek kopyaları aynı titizlikle değerlendirin.
KVKK ve GDPR Uyumlu Hosting için Mimari Stratejiler
1. Tek bölgeli Türkiye mimarisi
Hedef kitlesi ağırlıkla Türkiye olan, KVKK yükümlülüklerini sade tutmak isteyen kurumlar için değerlendirilebilecek bir senaryo:
- Uygulama ve veritabanı sunucuları: Türkiye’de seçilecek veri merkezlerinde.
- Yedekler: Hızlı geri dönüş için yerel kopya; ortak arıza riskini azaltmak için başka bir Türkiye tesisinde uzak kopya.
- Loglar: İşleme amacı ve uygulanabilir saklama yükümlülüklerine göre süre belirlenerek Türkiye içindeki merkezi log depolarında.
Bu modelde uygulama, veritabanı, yedek ve merkezi log depoları Türkiye’de planlanır. Ancak “kişisel verileriniz nerede tutuluyor?” sorusunun yanıtı, yan servislere gönderilen verilerin konumlarını da içermelidir.
2. Tek bölgeli AB mimarisi
AB pazarına odaklanan ve GDPR uyumunu önceliklendiren SaaS, kurumsal portal veya e-ticaret projelerinde:
- Uygulama ve veritabanı katmanını AB’de seçilen bir bölgede çalıştırın; sağlayıcının mevcut lokasyonunu ve sözleşmedeki taahhüdünü doğrulayın.
- Yedekleri AB içinde bağımsız tesislere dağıtmayı değerlendirin; bölge dışındaki yönetim ve destek erişimlerini de inceleyin.
- KVKK kapsamında dışa aktarım varsa uygun madde 9 yolunu kurun. AB’de işleme bilgisini aydınlatmaya eklemek tek başına yeterli değildir.
Burada önemli olan, veri envanterinizi ve veri akış haritanızı net çıkarmak. Hangi kullanıcı grubunun verisi AB’de, hangisi Türkiye’de? Eğer karma bir model kullanıyorsanız, bu ayrımı net dokümante etmeniz gerekir.
3. Hibrit Türkiye + AB mimarisi
Türkiye ve AB operasyonlarını birlikte yürüten varsayımsal bir hizmette, bölgesel tenant ayrımı şu şekilde tasarlanabilir:
- Türkiye operasyonu için: Ana veritabanı Türkiye’de seçilen veri merkezinde.
- AB operasyonu için: Ayrı veritabanı kümesi AB’de seçilen bölgede.
- Yönetim ve raporlama: Tenant’ın izin verilen bölgesine bağlanan uygulama; bölgeler arası sorgu, dışa aktarma ve destek erişimleri için ayrı yetki.
Bu ayrım gereksiz veri dolaşımını azaltabilir; ortak yönetim paneli veya rapor deposu kişisel verileri tekrar tek yerde topluyorsa akış devam eder. Bölgesel veritabanı yerleşimi tek başına veri minimizasyonu veya mevzuat uyumu sağlamaz. Replikasyon ve DNS tarafındaki seçenekler için çok bölgeli mimari rehberimize bakabilirsiniz.
4. Türkiye/AB ana, ABD ikincil (DR) mimarisi
Uzak bir bölgede felaket kurtarma kapasitesi gereken varsayımsal bir projede şu yapı değerlendirilebilir:
- Ana kopya: Türkiye veya AB’de seçilen üretim bölgesinde.
- İkincil kopya: ABD’de seçilen DR bölgesinde; bant genişliği, kabul edilebilir veri kaybı (RPO) ve geri dönüş süresi (RTO) birlikte planlanır.
ABD ortamı normalde üretim trafiği almasa bile kopyalanan kişisel verilerin aktarımı başlamış olur. Tasarımı yalnızca sözleşmede lokasyon belirtmeye dayandırmayın:
- Uygulanabilir KVKK/GDPR aktarım yolunu, alıcıyı ve alt işleyenleri kaydedin; üretime geçişten önce gerekli sözleşme, bildirim veya izinleri tamamlayın.
- Aktarımdan önce güçlü şifreleme, ayrı anahtar yönetimi ve rol tabanlı erişim (RBAC) kurun. EDPB’nin şifreli yedek örneği, verinin aktarılmadan önce şifrelenmesi, korumanın saklama süresince etkili kalması ve anahtarların yalnızca aktaranın kontrolünde veya AEA’da ya da esasen eşdeğer koruma sağlayan bir hukuk alanında güvenilir bir kuruluşta tutulması gibi koşullara dayanır.
- Felakette anahtar erişimini, açık verinin işleneceği tarafı, failover ve failback akışlarını önceden belirleyin. Testler ve izleme verileri de envantere dahil olsun.
Veri Kategorilerine Göre Veri Yerelleştirme Kararları
Üretim veritabanı: En sıkı kısımlar burada
Kullanıcı hesapları, sipariş bilgileri, sözleşme verileri gibi çekirdek kişisel veriler üretim veritabanınızda durur. Bu nedenle:
- Hangi ülke/ülkelerde tutulacağına en üst seviye kararı burada verin.
- Erişimleri en kısıtlı tuttuğunuz katman burası olsun.
- Okuma kopyaları (read replica) için dahi lokasyon ve şifreleme politikasını netleştirin.
Loglar: Hem güvenlik hem KVKK için kritik gri alan
Sunucu, uygulama ve güvenlik logları; IP adresi, oturum kimliği veya hesapla ilişkilendirilebilen istek bilgileri içerebilir. Bu kayıtları kişisel veri kapsamı bakımından değerlendirin; hata ayıklama amacıyla parolaları, erişim anahtarlarını veya gereksiz istek gövdelerini kaydetmeyin.
- Log deposunun, izleme sağlayıcısının ve erişen ekiplerin ülkelerini kaydedin.
- Saklama süresini amaca ve geçerli yasal yükümlülüklere göre belirleyin; tüm loglar için tek bir evrensel KVKK/GDPR süresi yoktur.
- Gereksiz alanları kaldırın; maskelemenin veya psödonimleştirmenin otomatik anonimlik sağlamadığını dikkate alın.
Bu noktada, log saklama planınızı yaparken hosting ve e-posta altyapısında log saklama süreleri rehberindeki pratik önerileri dikkate almak uyum sürecinizi oldukça kolaylaştırır.
Yedekler: 3-2-1 stratejisi ve lokasyon kararı
Veri yerelleştirme konuşulurken en çok atlanan konulardan biri de yedeklerin nerede durduğu. Oysa yedekler de kişisel veri içerir. Bu yüzden 3-2-1 yedekleme modelini uygularken lokasyonları bilinçli seçmelisiniz:
- 3 kopya: Üretim verisi ve iki yedek kopya.
- 2 farklı ortam: Ortak arıza riskini azaltan farklı depolama ortamları; yalnızca aynı sistemde iki klasör yeterli değildir.
- 1 uzak kopya: Farklı bir tesiste; aynı ülkede bulunabilir. Başka ülke seçilirse geçerli aktarım yolunu ve erişimleri ayrıca belirleyin.
Bu stratejiyi KVKK ve GDPR ile uyumlu şekilde nasıl kuracağınızı merak ediyorsanız, 3-2-1 yedekleme stratejisi rehberimiz tam bu noktada işin teknik detaylarını adım adım anlatıyor.
Analitik ve raporlama verileri: Anonimleştirme ile esneklik kazanmak
Trafik ve dönüşüm raporları gibi analitik çıktılarda kişisel veri ihtiyacını azaltmak mümkündür. Isı haritası veya oturum kaydı ise doğrudan kişiyi veya davranışını açığa çıkarabilir. Önce hangi alanlara ihtiyaç olduğunu belirleyin, ardından yeniden ilişkilendirme riskini değerlendirin:
- Gerçekten anonim hale gelen çıktıları, kişisel veri içeren ham kayıtlardan ayırın.
- Hash’lenmiş kimlikleri ve küçük gruplara ait istatistikleri otomatik olarak anonim saymayın.
- Anonimleştirme öncesindeki toplama, işleme ve aktarım aşamalarının yükümlülüklerini sürdürün; yurt dışında anonimleştirmek ilk aktarımı ortadan kaldırmaz.
Uygulamalı Senaryolar: Türkiye, Avrupa ve ABD Kombinasyonları
Senaryo 1: Sadece Türkiye pazarına çalışan e-ticaret sitesi
Başlangıçta Türkiye pazarı odaklı klasik bir e-ticaret projesini düşünelim. Bu projede önerdiğimiz mimari:
- Sunucu: Türkiye lokasyonu ve hizmet kapsamı doğrulanmış bir VPS veya dedicated sunucu.
- Veritabanı: Müşteri ve sipariş verileri Türkiye’de; ödeme ve destek sağlayıcılarına giden alanlar ayrıca haritalanır.
- Yedekler: Yerel ve başka bir Türkiye tesisindeki uzak kopya; yedek sıklığı RPO’ya, saklama süresi işleme amacı ve yükümlülüklere göre seçilir.
- Loglar: Türkiye’de merkezi depolama; görev bazlı erişim, rotasyon ve süre sonunda imha.
Bu örnekte planlama toplantısının somut çıktısı; hangi kaydın kaç gün tutulacağı, hangi çalışanın hangi loglara erişeceği ve bir geri yüklemede önceden silinmiş kayıtların yeniden kullanıma açılmasının nasıl önleneceğidir. Sağlayıcının bu ayarların hangisini yönettiğini ve hangilerinin uygulama ekibine ait olduğunu hizmet kapsamına yazın.
Senaryo 2: Türkiye merkezli ama AB’de büyüyen SaaS
İkinci senaryo: Şirket Türkiye’de kurulu, fakat SaaS ürünü artık Almanya, Fransa, Hollanda gibi ülkelerde de ciddi müşteri kazanmaya başlamış. Burada tipik mimari şöyle oluyor:
- Türkiye operasyonu: Türkiye’de ayrı veritabanı kümesi.
- AB operasyonu: AB’de ayrı veritabanı kümesi; tesis ve erişim ülkeleri sözleşmede doğrulanır.
- Uygulama: Her bölgede kendi uygulama sunucuları ve tenant yetkilendirmesi.
- Merkezi yönetim: Tenant kimliğine göre bölgesel API’ye bağlanır; ortak raporlarda gerekli en az veri kullanılır.
Bu model, gereksiz bölgeler arası kopyaları azaltabilir. Türkiye’deki ekibin AB verisine erişimi veya ortak destek sistemine kayıt aktarımı yine değerlendirilmelidir; müşteri grubuna göre ayırmak tek başına hukuki sonuç doğurmaz. SaaS uygulamalarında çok kiracılı mimari rehberi, altyapı seçeneklerini bu ayrım üzerinden planlamaya yardımcı olur.
Senaryo 3: Küresel kitleye oynayan içerik/medya platformu
Üçüncü senaryoda; hem Türkiye’de hem AB’de hem de ABD’de ciddi trafik alan bir içerik veya medya platformumuz var. Bu durumda hedef:
- Kullanıcıya en yakın lokasyondan içerik sunarak gecikmeyi azaltmak,
- Kişisel verilerin tutulduğu asıl veritabanlarını daha sınırlı sayıda bölgede toplamak,
- CDN ve önbellekleme sayesinde, kişisel veri içermeyen statik içeriği küresel dağıtmak.
Pratik bir yaklaşım:
- Türkiye ve AB’de ana veritabanı kümeleri; hesap ve kişiye özel içerik izin verilen bölgede işlenir.
- ABD’de herkese açık içerik önbelleği ve gerekiyorsa gerçekten anonim rapor çıktıları.
- CDN’nin IP adresi, çerez, URL ve erişim loglarını ayrıca inceleyin. Hesap veritabanı ABD’de olmasa bile CDN veya analitik alıcısına kişisel veri aktarımı olabilir.
Hosting Sağlayıcısıyla Seçim ve İşletim Adımları
1. Veri envanteri ve akış haritasını çıkarın
Teknik mimariden önce her veri akışı için kaynak sistemi, veri kategorisini, amacı, alıcı tüzel kişiyi, saklama ve erişim ülkelerini gösteren bir veri akış haritası hazırlayın. Şu kaynakları atlamayın:
- Kullanıcı kayıt formları, sipariş süreçleri, destek talepleri, pazarlama otomasyonu.
- Loglama: Web sunucusu, uygulama, güvenlik, e-posta, CDN logları.
- Yedekler ve arşivler.
2. Bölgeyi kullanıcı kitlesi ve veri akışıyla birlikte seçin
Hedef kitle, performans ihtiyacını anlamak için başlangıçtır. Bölge kararını hukuk kapsamı, aktarım koşulları, destek erişimleri ve işletim kapasitesiyle birlikte verin:
- Türkiye odaklı hizmet: Türkiye bölgesini ağ performansı ve tüm işlem zincirini yerelde tutabilme imkânıyla değerlendirin.
- AB odaklı hizmet: AB/AEA bölgesini, bölge dışı yönetim ve alt işleyen akışlarını da dikkate alarak değerlendirin.
- Karma hizmet: Ayrı tenant bölgeleri ile ortak yönetim sistemleri arasında hangi verilerin geçeceğini tasarlayın.
DCHost dahil değerlendirdiğiniz sağlayıcılardan mevcut VPS, dedicated sunucu veya colocation lokasyonlarını, yedek hedeflerini ve destek ülkelerini yazılı olarak doğrulayın. Bölge sabitlemenin hangi hizmetleri kapsadığını, değişiklik bildirimlerini ve sorumluluk paylaşımını sözleşmede netleştirin.
3. DNS, SSL ve çok bölgeli yönlendirmeleri planlayın
Çok bölgeye geçerken geo-routing, ağırlıklı yönlendirme ve TTL değerlerini planlayın; DNS önbellekleri geçişi geciktirebilir. DNS coğrafi yönlendirmesi bir erişim yetkisi veya veri yerleşimi sınırı değildir: doğru tenant bölgesini uygulama ve veritabanı izinleriyle de uygulayın. Her uçta TLS sertifikası ve güvenli servis bağlantısı bulunmalıdır. DNS kayıtları A’dan Z’ye rehberimiz kayıt türlerini ve yaygın hataları açıklar.
4. Loglama, saklama süreleri ve silme süreçlerini netleştirin
Silme taleplerini uygulama, log ve yedek katmanlarında birlikte ele alın. KVKK’da işleme şartlarının ortadan kalkması, GDPR madde 17’de ise ilgili silme sebepleri ve istisnalar değerlendirilir; her talep bütün kayıtların koşulsuz ve anında silinmesi anlamına gelmez. Şunları netleştirin:
- Hangi kaydın saklama dayanağı ve süresi nedir; süre sonunda hangi işlem uygulanır?
- Yedek kopyaları ne zaman ve nasıl imha edilir; geri yüklemede silme işlemleri nasıl yeniden uygulanır?
- Anonim çıktı ile kişisel veri içeren kaynaklar nasıl ayrılır; yapılan işlemler nasıl kayıt altına alınır?
Log rotasyonu, silme görevleri ve yedek saklama ayarlarını yazılı politikayla eşleştirin. KVKK imha yönetmeliğindeki süre ve kayıt gerekliliklerini, GDPR kapsamındaki talepleri ve varsa zorunlu saklama sürelerini görev sahibine bağlayın; yalnızca uygulama ekranındaki kaydı gizlemeyi imha olarak kabul etmeyin.
5. Felaket kurtarma (DR) ve iş sürekliliği planı
Çok bölgeli veya hibrit mimarilerde, verinin nerede tutulduğu kadar, bir bölgede sorun çıktığında hangi bölgenin hangi sırayla devreye gireceği de önemlidir. Felaket kurtarma planınızı oluştururken şu soruları cevaplayın:
- Hangi bölgeler aktif–aktif, hangileri aktif–pasif çalışacak?
- DNS failover senaryosunda hangi lokasyona ne kadar sürede geçilecek?
- Dönüş senaryosunda (primary bölge geri geldiğinde) veri tutarlılığı nasıl sağlanacak?
Planı RTO/RPO hedefleri, aktarım mekanizmaları, erişim yetkileri ve sorumlularla birlikte kaydedin. Kontrollü geri yükleme ve failover testlerinde hedefleri ölçün; anahtarların erişilebilirliğini ve geri dönüşte veri tutarlılığını doğrulayın. Bir arıza, önceden değerlendirilmemiş bir ülkeye sınırsız veri aktarımı izni oluşturmaz.
Veri Merkezi Kararını Belgelenmiş Bir Mimariye Dönüştürün
Türkiye, AB ve ABD arasında hosting seçimi; kişisel verinin hangi ülkede tutulacağı, hangi alıcıya açılacağı, ne kadar saklanacağı ve bir arızada nereye taşınacağına dair bir karar bütünüdür. Uygulanabilir hukuk ve aktarım mekanizmasını belirledikten sonra gecikme, maliyet, güvenlik ve işletim kapasitesini karşılaştırın. Hukuki gereklilikler yalnızca işletmenin risk iştahına göre kaldırılabilecek tercihler değildir.
Kararın gözden geçirilebilir çıktısı; veri akış haritası, alıcı ve alt işleyen listesi, sözleşmeler, erişim politikası, saklama takvimi ve DR planıdır. DCHost ile teknik seçenekleri görüşürken bu belgeler üzerinden mevcut lokasyonları ve hizmet kapsamını doğrulayabilirsiniz. Yeni bir bölge, destek sağlayıcısı veya analitik aracı eklendiğinde planı yeniden değerlendirin; ilk kurulumdaki uyum incelemesi sonraki bütün değişiklikleri kapsamaz.
