İçeriğe geç
  • Hafta içi 08:00 – 18:00 · Destek 7/24
  1. Ana Sayfa
  2. Blog
  3. İşletme

KVKK ve veri yerelliği: sunucunuz nerede olmalı?

Kişisel veri işleyen her site KVKK kapsamındadır. Yurt dışına aktarım kuralları, VERBİS, saklama süreleri ve barındırma sağlayıcısıyla ilişki.

  • Güncellendi:
  • 8 dakika okuma
  • İşletme
Yerel bölgede tutulan veri kümelerini kilit simgesiyle anlatan izometrik çizim

İletişim formu olan bir site bile kişisel veri işler. KVKK, verinin nerede tutulduğuyla değil nasıl işlendiğiyle ilgilenir; ama sunucunun konumu, aktarım kuralları ve denetlenebilirlik açısından doğrudan sonuç doğurur. Bu yazı hukuki görüş değil, teknik karar verirken kullanacağınız bir çerçevedir.

Hangi veriler kapsamda?

Kişisel veri, kimliği belirli ya da belirlenebilir gerçek kişiye ilişkin her türlü bilgidir. Web tarafında tipik olarak şunlar sayılır:

  • Ad, soyad, e-posta, telefon, fatura adresi.
  • Üyelik ve sipariş kayıtları.
  • Sunucu erişim günlüklerindeki IP adresleri ve oturum kayıtları.
  • Çerezler aracılığıyla toplanan davranış verileri.

Erişim günlükleri sık atlanır. Ham access.log dosyalarınız IP adresi içerdiği için kişisel veri barındırır; saklama süresi tanımlamak ve gereksiz eskiyi silmek gerekir.

Günlükleri baştan maskelemek

İhtiyacınız olan genelde kimin geldiği değil, nereden geldiğidir. IP adresinin son sekizlisini atmak istatistiksel değeri korur, kişiye ulaşılabilirliği düşürür. Nginx tarafında karşılığı şudur:

map $remote_addr $ip_maskeli { "~(?<ilk>\d+\.\d+\.\d+)\.\d+" "$ilk.0"; default 0.0.0.0; }
log_format maskeli '$ip_maskeli - [$time_local] "$request" $status $body_bytes_sent';

Saklama süresini de aynı yerde bağlayın. logrotate yapılandırmasındaki rotate 60 satırı, günlük döndürmede altmış günden eski dosyanın silinmesi demektir. Politikanızda "erişim günlükleri iki ay saklanır" yazıyorsa bunun teknik karşılığı tam olarak bu satırdır.

Saldırı engelleme araçlarının ham IP'ye ihtiyacı olabilir; bu durumda ham günlüğü kısa, maskeli günlüğü uzun süre tutan iki ayrı akış kurun.

Yurt dışına aktarım

KVKK'nın 9. maddesi, kişisel verinin yurt dışına aktarımını belirli şartlara bağlar. 2024'teki değişiklikle standart sözleşme ve bağlayıcı şirket kuralları gibi araçlar kullanılabilir hale geldi, ancak bunlar da bildirim ve belge yükümlülüğü doğurur. Sunucunuz yurt dışındaysa, işlediğiniz kişisel veriler orada tutuluyor demektir; bu bir aktarımdır ve hukuki dayanağını belgelemeniz gerekir.

Sunucuyu Türkiye'de tutmak bu başlığı kökünden ortadan kaldırır. Uyum yükünü azaltmanın en basit yolu, aktarım yapmamaktır. Türkiye lokasyonlu altyapı tercih ettiğinizde, veri yerelliği tartışması denetimde gündeme bile gelmez.

Barındırma sağlayıcınız "veri işleyen" dir

Verinin amacını ve yöntemini siz belirlersiniz: veri sorumlusu sizsiniz. Barındırma sağlayıcısı sizin adınıza veriyi tutar; veri işleyendir. Bu ilişki yazılı olmalıdır ve sağlayıcınızdan şunları sorabilmelisiniz:

  • Veriler hangi ülkede, hangi veri merkezinde tutuluyor?
  • Yedekler nerede saklanıyor? (Yedeğin yurt dışında olması da aktarımdır.)
  • Erişim yetkisi kimlerde, erişim kayıtları tutuluyor mu?
  • Veri ihlali durumunda bildirim süreci nasıl işliyor?
  • Hizmet sona erdiğinde veriler ne zaman ve nasıl siliniyor?

VERBİS kaydı

Belirli eşiklerin üzerindeki veri sorumlularının Veri Sorumluları Sicil Bilgi Sistemine kayıt yükümlülüğü vardır. Çalışan sayısı, yıllık mali bilanço ve işlenen verinin niteliği (özel nitelikli kişisel veri işleniyor mu) belirleyicidir. Muafiyet kapsamında olsanız bile aydınlatma metni, veri envanteri ve saklama-imha politikası hazırlamak yükümlülükten düşmez.

Kayıt yükümlülüğünü kanunun 16. maddesi düzenler, muafiyet ölçütlerini Kurul kararları belirler. Eşiklerin güncel hali ve sizin işletmenize nasıl uygulandığı için hukuk danışmanınıza başvurun.

Aydınlatma ile açık rıza aynı şey değildir

Sık karıştırılan iki kavram. Aydınlatma yükümlülüğü koşulsuzdur: hangi veriyi, hangi amaçla, hangi hukuki sebeple işlediğinizi ve kime aktardığınızı, veriyi topladığınız anda anlatmak zorundasınız. Açık rıza ise yalnız başka bir hukuki sebebe dayanamadığınız durumda gerekir ve özgür iradeyle, belirli bir konuya ilişkin ve bilgilendirilmiş olmalıdır.

Pratikte bu şu demektir: bir sipariş formundaki ad ve adres, sözleşmenin ifası için gereklidir; ayrıca rıza kutusu koymak gereksizdir ve rızayı sakatlar. Buna karşılık aynı formdaki "kampanya duyurusu almak istiyorum" seçeneği ayrı ve işaretsiz gelmelidir. Hizmet almanın ön şartı haline getirilen bir onay kutusu, özgür irade ölçütünü karşılamaz.

Veri ihlali olduğunda

Kurul, ihlalin öğrenilmesinden itibaren gecikmeksizin ve en geç 72 saat içinde Kuruma bildirim yapılmasını arar; ilgili kişilere de makul en kısa sürede haber verilir. Bu süre teknik ekibin hazırlıklı olmasını zorunlu kılar, çünkü 72 saatin büyük bölümü "ne oldu, hangi veriler etkilendi, kaç kişi" sorularıyla geçer.

Cevaplayabilmek için önceden hazır olması gerekenler: erişim ve yönetici işlem günlükleri, veri envanteri, sunucudaki kullanıcı yetki listesi ve iletişim kurulacak kişilerin listesi. Bunlar ihlal gününde toplanamaz.

Teknik tedbirler somuttur

Kurul kararlarında en sık atıf yapılan eksiklikler teknik ve idari tedbirlerdir. Web tarafında karşılığı şunlardır:

  1. Tüm trafiğin HTTPS üzerinden akması; sertifikanın geçerli ve güncel olması.
  2. Panel erişimlerinde güçlü parola ve iki adımlı doğrulama.
  3. Yetki ayrımı: her çalışana yalnız işi için gereken erişim.
  4. Yedeklerin şifreli tutulması ve geri dönüş provasının yapılması.
  5. Günlük kayıtlarının tutulması ve saklama süresi sonunda silinmesi.
  6. Güvenlik güncellemelerinin düzenli uygulanması.

Kendi sunucusunu yöneten işletmeler için bu maddelerin somut karşılığı ilk gün yapılan sunucu sertleştirmesidir: SSH anahtarına geçmek, gereksiz servisleri kapatmak, güvenlik duvarını yalnız gereken portlara açmak. Denetimde "hangi tedbirleri aldınız" sorusuna verilecek cevabın büyük bölümü bu adımlardan oluşur.

İdari taraf da yazılı olmalıdır: gizlilik taahhütnameleri, yetki matrisi ve personel işten ayrıldığında erişimlerin kapatılması yordamı.

Saklama süresi ve imha

Kişisel veri, işleme amacı ortadan kalktıktan sonra saklanamaz. Pratikte bu, her veri kategorisi için bir süre belirlemek ve süre dolduğunda otomatik silme kurmak demektir. İletişim formu kayıtları için altı ay, sipariş kayıtları için mevzuatın öngördüğü ticari saklama süresi, erişim günlükleri için birkaç ay gibi. Otomatik silme kurulmadığında politika kâğıt üzerinde kalır ve denetimde işe yaramaz.

Aşağıdaki tablo, sürelerin nereden türediğini gösterir. Rakamlar örnektir; kendi sürelerinizi mevzuat ve hukuk danışmanınızın görüşüyle belirleyin.

Veri kategorisiSüreyi belirleyenTeknik karşılığı
İletişim formu kayıtlarıİşleme amacıVeritabanında zamanlanmış silme görevi
Sipariş ve fatura kayıtlarıVergi ve ticaret mevzuatındaki saklama süreleriArşiv tablosu, süre dolunca anonimleştirme
Erişim günlükleriGüvenlik ihtiyacılogrotate döndürme sayısı
YedeklerKurtarma hedefiYedek saklama politikasındaki gün sayısı
Silinmiş üyelik hesaplarıİşleme amacının sona ermesiYumuşak silme yerine gerçek silme işi

Yedekler burada en çok atlanan satırdır. Canlı veritabanından sildiğiniz kayıt, aylar öncesine ait bir yedekte durmaya devam eder. Yedek saklama süresini imha politikasıyla uyumlu tutmadığınız sürece silme işlemi yarım kalır. Aynı gerilim yedekleme tarafında da görülür: sürüm sayısı arttıkça kurtarma gücü artar, imha yükü de artar.

Veritabanındaki kaydın değil sunucunun kendisinin imhası için ayrı bir rehber yazdık: sunucudaki kişisel veri nasıl yok edilir.

Alt yükleniciler zinciri

Kendi sunucunuz Türkiye'de olsa bile kullandığınız üçüncü taraf servisler veriyi yurt dışına taşıyabilir: analitik, canlı destek, e-posta pazarlama aracı, form servisi, ödeme sağlayıcısı. Envanterinizi çıkarırken sitenizin dış dünyaya yaptığı istekleri tarayıcının ağ sekmesinden listeleyin. Çoğu işletme, hangi verinin nereye gittiğini ilk kez bu listeyi çıkarırken görür.

Envanteri çıkarma yordamı

  1. Sitenin en çok kullanılan beş sayfasını tarayıcının ağ sekmesi açıkken gezin ve kendi alan adınız dışına giden tüm istekleri listeleyin.
  2. Her satır için üç soruyu cevaplayın: hangi veri gidiyor, hangi şirkete gidiyor, o şirketin sunucusu nerede?
  3. Sunucu tarafındaki dış çağrıları da ekleyin: ödeme sağlayıcısı, kargo entegrasyonu, SMS servisi, e-posta gönderim servisi. Bunlar ağ sekmesinde görünmez.
  4. Veritabanı tablolarını gözden geçirip hangi tabloda kişisel veri olduğunu işaretleyin.
  5. Listeyi yılda en az bir kez ve her yeni entegrasyondan sonra güncelleyin.

Sunucunuz gerçekten nerede? Üç bağımsız kanıt

Veri envanterinizde "sunucu Türkiye'de" yazması bir beyandır; denetimde ya da bir veri ihlali sonrasında sorulacak soru, bunu neye dayanarak yazdığınızdır. Üç kaynak birbirini tamamlar ve hiçbiri tek başına yeterli değildir.

1. IP adresinin kayıtlı sahibi

Her IP bloğunun bir bölgesel internet kayıt kuruluşunda kayıtlı bir sahibi ve ülkesi vardır. Sunucunuzun IP adresini sorgulayın:

whois SUNUCU_IP | grep -iE '^(inetnum|netname|country|org-name)'

Çıktıdaki country alanı bloğun kayıtlı olduğu ülkeyi, org-name bloğun sahibini gösterir. Bu bilgi, sunucunun fiziksel konumunu değil, IP bloğunu kimin yönettiğini kanıtlar. Türkiye'de kayıtlı bir blok yurt dışındaki bir veri merkezinde de kullanılabilir; tersi de mümkündür.

2. Ağ yolu

Trafiğin sunucuya hangi ağlardan geçerek ulaştığını mtr gösterir:

mtr -rwzc 10 -4 alanadiniz.com

Son satırlardaki AS numaraları ve gecikme süreleri bir fikir verir: Türkiye içinden yapılan bir ölçümde son atlamaya 10 ms civarında ulaşılıyorsa sunucu büyük olasılıkla yakındadır. Ama sitenizin önünde bir CDN ya da koruma hizmeti varsa, mtr sunucunuza değil o hizmetin size en yakın noktasına ulaşır. Bu durumda yol, kaynağın konumu hakkında bir şey söylemez; ve bu ayrıntı, yurt dışına aktarım açısından ayrıca değerlendirilmesi gereken bir hizmet sağlayıcınız olduğunu hatırlatır. Bir adresin hangi IP'ye ve hangi barındırma altyapısına çözüldüğünü görmek için hosting sorgulama ve IP sorgulama araçlarını kullanabilirsiniz.

3. Sözleşme ve sağlayıcı beyanı

Bağlayıcı olan kanıt teknik ölçüm değil, sağlayıcınızla yaptığınız sözleşmedir. IP konum veritabanları yanılabilir, ağ yolu değişebilir; ama sözleşmede verinin işlendiği ve yedeklendiği ülke yazılıysa, ölçüm yalnız bu beyanın tutarlılığını sınar. Sağlayıcıdan yazılı olarak şunları isteyin:

  • Sunucunun ve yedeklerin bulunduğu ülke. Birincil sunucu Türkiye'de, yedekleri yurt dışında olan kurulumlar sık görülür.
  • Destek ve yönetim erişiminin hangi ülkelerden yapıldığı; uzaktan erişim de bir aktarım biçimi olarak değerlendirilebilir.
  • Sözleşme sona erdiğinde verinin nasıl ve ne kadar sürede silineceği.

Üç kaynağı birlikte dosyalayın: whois çıktısı, tarihli bir ağ yolu ölçümü ve sözleşmenin ilgili maddesi. Bu, envanterdeki tek satırlık beyanı denetlenebilir bir kayda çevirir. Hukuki değerlendirme için bu kaydı hukuk danışmanınızla birlikte okuyun.

Bu çerçeve ne zaman yetmez?

Sunucuyu Türkiye'ye almak aktarım başlığını kapatır, uyumun tamamını değil. Özel nitelikli kişisel veri işliyorsanız (sağlık, biyometrik veri gibi), yurt dışı merkezli bir bulut servisini iş süreçlerinizin merkezine koyduysanız ya da yurt dışında müşteriniz varsa tablo değişir ve başka mevzuatlar devreye girebilir. Bu yazı hukuki görüş değildir; uygulama kararlarını hukuk danışmanınızla verin.

Uyum, tek seferlik bir proje değil sürdürülen bir işletim disiplinidir. Altyapı tarafında Türkiye lokasyonunu seçmek, bu disiplinin en az tartışılan ve en kolay uygulanan parçasıdır.

Sık sorulan sorular

Sunucunun hangi ülkede olduğunu nasıl öğrenirim?

IP adresinin whois kaydı bloğun kayıtlı ülkesini ve sahibini, mtr gibi bir ölçüm ağ yolunu ve gecikmeyi gösterir. İkisi de fiziksel konumu kesin kanıtlamaz; bağlayıcı bilgi sağlayıcınızın sözleşmede beyan ettiği konumdur. Üçünü birlikte saklamak en sağlam kayıttır.

Sunucu Türkiye'de ama yedekler yurt dışında olabilir mi?

Olabilir ve sık görülür. Yedekler de kişisel veri içerir; konumları birincil sunucudan ayrı olarak sorulmalı ve sözleşmede yazılı olmalıdır. Yurt dışında tutulan yedek, birincil sunucu Türkiye'de olsa da aktarım hükümlerini gündeme getirebilir.

Sitemin önünde CDN varsa veri yurt dışına aktarılmış olur mu?

CDN, ziyaretçi trafiğini kendi noktalarından geçirir ve içeriği oralarda önbelleğe alabilir. Bunun aktarım açısından nasıl değerlendirileceği, hangi verinin CDN'den geçtiğine ve hizmetin nasıl yapılandırıldığına bağlıdır; bu değerlendirmeyi hukuk danışmanınızla yapın ve CDN sağlayıcısını da veri envanterinize ekleyin.

  • #kvkk
  • #uyum
  • #veri yerelliği

Sunucunun ve yedeklerin nerede durduğunu yazılı olarak bilmek mi istiyorsunuz? KVKK uyumlu sunucu sayfamızda altyapımızın konumunu ve uyum dosyanıza girecek bilgileri anlatıyoruz.

KVKK uyumlu sunucuya bakın
Devamı

İlgili yazılar