Güvenlik

KVKK ve Veri Egemenliği: Verinin Türkiye'de Kalması Ne Demek

Sunucunun Türkiye'de olması cümlesi çok kullanılıyor ama çoğu zaman eksik anlaşılıyor. Yedekler, loglar ve destek erişimi de bu hesabın parçası.

Kurumsal alım süreçlerinde en sık duyduğumuz cümlelerden biri veri Türkiye'de kalsın oluyor. Talep haklı, ama tek başına bir uyum stratejisi değil. Verinin hangi diskte durduğu kadar, kimin eriştiği, nereye kopyalandığı ve ne zaman silindiği de aynı çerçevenin parçası. Bu yazıda KVKK'nın ne istediğini ve bunun altyapı tarafındaki karşılığını ayrı ayrı ele alıyoruz.

Veri egemenliği ile veri yerelliği aynı şey değil

Birbirinin yerine kullanılan iki kavram var. Veri yerelliği, verinin fiziksel olarak hangi ülkenin sınırları içinde durduğuyla ilgilidir; tamamen coğrafi bir sorudur. Veri egemenliği ise verinin hangi ülkenin hukukuna tabi olduğuyla ilgilidir ve cevabı her zaman coğrafyayla örtüşmez.

Fark şurada ortaya çıkar: veri Türkiye'deki bir veri merkezinde durabilir, ama o veri merkezini işleten şirket başka bir ülkenin yargı yetkisi altındaysa, o ülkenin hukuku veriye erişim talebi doğurabilir. Bu yüzden soruyu yalnızca sunucu nerede diye değil, işletmecinin tabi olduğu hukuk hangisi ve veriye teknik olarak kimler erişebiliyor diye sormak gerekir. Kendi donanımımızı İstanbul'daki veri merkezimizde işletiyor olmamızın pratik karşılığı da budur: sanal sunucu hizmetinde verinin durduğu donanım da, ona erişen ekip de aynı hukuki çerçevenin içinde kalır.

Yurt dışına aktarımın 2024 sonrası hali

KVKK'nın yurt dışına aktarım rejimi 7499 sayılı Kanun ile değişti ve yeni düzen 2024 yılında yürürlüğe girdi. Önceki dönemde uygulamada tıkanma yaratan nokta, Kurul'un yeterlilik kararı vermemiş olması ve buna bağlı olarak aktarımların çoğunun taahhütname iznine sıkışmasıydı. Yeni düzen bu tabloyu üç kademeli bir yapıya oturttu.

  • Yeterlilik kararı: Kurul'un ülke, sektör ya da uluslararası kuruluş bazında yeterlilik kararı bulunuyorsa aktarım bu karara dayanarak yapılır.
  • Uygun güvenceler: Yeterlilik kararı yoksa standart sözleşme, bağlayıcı şirket kuralları, taahhütname gibi araçlarla aktarım mümkün hale gelir. Standart sözleşme kullanıldığında bunun Kurum'a bildirilmesi gerekir, yani imzalayıp bir kenara koymak yeterli değildir.
  • Arızi haller: Ne yeterlilik kararı ne de uygun güvence varsa, yalnızca kanunda sayılan istisnai durumlara dayanılabilir. Bunlar adı üstünde arızidir; düzenli ve süreklilik arz eden bir aktarımın dayanağı olamaz.

Asıl mesaj şu: aktarım yasak değil, belgelendirilmesi gereken bir işlem. Aktarımı hiç yapmamak birçok kurum için en ucuz yol oluyor. Uyumluluk yönetimi tarafında ilk iş genelde veri akış envanteri çıkarmak, çünkü çoğu kurum verisinin nereye gittiğini tam bilmiyor.

KVKK ile GDPR nerede ayrışıyor

KVKK büyük ölçüde GDPR öncesi Avrupa mevzuatından esinlendiği için iki metin birbirine benzer. Ama uyum projelerinde fark yaratan birkaç ayrım var.

Birincisi açık rızanın ağırlığı. Uygulamada KVKK tarafında açık rıza fazla kullanılıyor, oysa kanun rıza dışında da işleme şartları sayıyor. Bir sözleşmenin ifası ya da hukuki yükümlülük gibi bir dayanak varsa rıza almaya gerek yoktur; üstelik rıza her zaman geri alınabilir olduğu için daha kırılgan bir zemindir.

İkincisi ihlal bildirimi. Her iki düzende de yetkili otoriteye bildirim için yetmiş iki saatlik bir çerçeve söz konusudur. Bu sürenin pratik sonucu teknik tarafa düşer: ihlali yetmiş iki saat içinde bildirebilmek için önce onu fark edebiliyor olmak gerekir. Kayıt tutulmayan, izlenmeyen bir sistemde bu süre zaten baştan kaçırılmıştır. Zafiyet yönetimi ile uyumun kesiştiği yer tam olarak burasıdır.

Veri sorumlusu ve veri işleyen ayrımı

Altyapı hizmeti alan kurumların en sık karıştırdığı konu, sorumluluğun nerede durduğudur. KVKK iki rol tanımlar. Veri sorumlusu, kişisel verinin neden ve nasıl işleneceğine karar veren taraftır. Veri işleyen ise bu kararı vermez, yalnızca veri sorumlusunun talimatı doğrultusunda işlem yapar. Bir barındırma sağlayıcısı tipik olarak veri işleyen konumundadır.

Bu ayrımın pratik sonucu şudur: hizmet aldığınız sağlayıcı sizin yükümlülüğünüzü devralmaz. İlgili kişi başvurusu size gelir, ihlal bildirimi yükümlülüğü sizdedir, aydınlatma metnini siz hazırlarsınız. Sağlayıcı tarafındaki bir eksiklik, sizi veri sorumlusu olarak sorumluluktan kurtarmaz.

Bu yüzden veri sorumlusu ile veri işleyen arasında yazılı bir düzenleme bulunması gerekir. Bu metnin cevaplaması gereken sorular bellidir: veri işleyen hangi işlemleri yapmaya yetkilidir, hangi güvenlik tedbirlerini uygulamayı taahhüt eder, bir ihlal durumunda veri sorumlusunu ne kadar sürede bilgilendirir, hizmet sona erdiğinde veriyi iade mi eder yoksa imha mı eder.

Unutulan kopyalar: yedekler, loglar, test ortamları

Uyum çalışmalarında en sık atlanan konu, kişisel verinin tek bir yerde durmadığıdır. Üretim veritabanındaki bir kaydı sildiğinizde aynı kayıt hâlâ şu yerlerde duruyor olabilir:

  • Gecelik yedeklerde ve saklama süresi boyunca tutulan eski yedek setlerinde.
  • Uygulama loglarında, özellikle istek gövdesini olduğu gibi yazan hata kayıtlarında.
  • Üretimden kopyalanmış test ve staging ortamlarında.
  • Analitik ambarlarında ve rapor çıktılarında.
  • Destek ekibinin ekran görüntüsü aldığı biletlerde.

Bunların en zorlusu yedeklerdir, çünkü değiştirilemez yedek almak güvenlik açısından doğru bir tercihtir ama silme yükümlülüğüyle gerilim yaratır. Yaygın çözüm, yedekten seçici silme yapmaya çalışmak yerine yedeğin saklama süresini tanımlı tutmak ve o süre dolduğunda setin tamamının imha edilmesidir. Loglarda ise doğru yaklaşım silmek değil, kişisel veriyi loga hiç yazmamaktır.

Yükümlülüğün teknik karşılığı

KVKK veri güvenliğine ilişkin teknik ve idari tedbirleri ister ama bunları tek tek saymaz. Pratikte beklenen asgari çerçeve şudur:

  • Verinin taşınırken ve beklerken şifrelenmesi. Bu iki katmanın ayrı ayrı düşünülmesi gerekir; veri şifreleme tarafında asıl kritik soru şifrelemenin varlığı değil, anahtarın nerede durduğu ve kimin erişebildiğidir. Anahtar veriyle aynı yerde ve aynı erişim altındaysa şifrelemenin koruma değeri sınırlıdır.
  • Erişimlerin kişiye bağlı olması ve kayıt altında tutulması. Paylaşılan yönetici hesapları, bir ihlal sonrası kimin ne yaptığını belirlemeyi imkansız hale getirir.
  • Yetki matrisinin en az yetki ilkesine göre kurulması ve düzenli gözden geçirilmesi. Yetkiler zamanla birikir, çünkü kimse görev değişiminde eski yetkisini bırakmaz.
  • Bağımsız denetimden geçmiş bir yönetim sistemi. ISO 27001 hukuken zorunlu değildir ama teknik ve idari tedbirlerin sistematik biçimde kurulduğunu göstermenin en yaygın yoludur.

Saklama ve imha: en çok aksayan başlık

Kurumların büyük kısmı veri toplamayı ve korumayı çözer, silmeyi çözemez. Oysa ilgili yönetmelik saklama ve imha politikası hazırlamayı, her veri kategorisi için saklama süresi tanımlamayı ve süresi dolan veriyi düzenli olarak imha etmeyi öngörür. Periyodik imha aralığının altı ayı geçmemesi beklenir.

Bu maddenin altyapı tarafındaki karşılığı çoğu zaman ihmal edilir. Saklama süresi tanımlanmış olsa bile, bunu uygulayan otomatik bir mekanizma yoksa politika kağıt üzerinde kalır. Çalışan bir kurulumda saklama süresi veri kategorisi bazında tanımlanır, imha işi zamanlanmış bir görev olarak çalışır, her imha turu kayıt altına alınır ve bu kayıt denetimde delil olarak sunulabilir olur.

Uyumun izleme tarafı için zero-trust ve mikro segmentasyon yazısında ele aldığımız erişim denetimi yaklaşımı da bu resmin bir parçası: kimin hangi veriye erişebildiğini daraltmadan, erişim kayıtlarını tutmanın tek başına faydası sınırlı kalır.

Sık sorulan sorular

Verinin Türkiye'de olması KVKK uyumu için tek başına yeterli mi?

Hayır. Sunucunun Türkiye'de olması aktarım sorununu çözer, ama KVKK aydınlatma, hukuki sebep, saklama süresi, imha ve veri güvenliği yükümlülüklerini ayrıca arar. Veri merkezinin konumu gerekli koşullardan yalnızca biridir.

Yurt dışına veri aktarımı 2024 sonrası nasıl yapılıyor?

7499 sayılı Kanun ile değişen düzende önce ülke ya da sektör bazlı yeterlilik kararına bakılır. Yeterlilik kararı yoksa standart sözleşme, bağlayıcı şirket kuralları ya da taahhütname gibi uygun güvencelere başvurulur. Bunlar da yoksa yalnızca kanunda sayılan arızi hallere dayanılabilir.

Yedekler ve log kayıtları da kişisel veri sayılır mı?

Evet. Bir kaydı üretim veritabanından silmek, aynı kaydın yedeklerde ve log satırlarında durmasını engellemez. Saklama ve imha politikası yedekleri, arşivleri ve logları da kapsamak zorundadır, aksi halde silme yükümlülüğü kağıt üzerinde kalır.

Yurt dışından uzaktan erişim aktarım sayılır mı?

Veri fiziksel olarak Türkiye'de dursa bile yurt dışındaki bir ekibin bu veriye erişebiliyor olması aktarım olarak değerlendirilebilir. Bu yüzden destek ve bakım süreçlerinde kimin hangi veriye eriştiği, veri merkezinin konumu kadar önemlidir.

Periyodik imha ne sıklıkla yapılmalı?

İlgili yönetmelik periyodik imha aralığının altı ayı geçmemesini öngörür. Bunun için önce her veri kategorisi için saklama süresi tanımlanmış olmalı, sonra bu sürenin dolduğu kayıtların düzenli olarak silinmesi, yok edilmesi ya da anonim hale getirilmesi gerekir.

Uyum tarafını birlikte kuralım

KVKK, GDPR ve ISO 27001 süreçlerinde envanter çıkarmadan denetim hazırlığına kadar destek veriyoruz.

Uyumluluk yönetimi Uzmanla görüşün

İlgili yazılar

Güvenlik

Zero-Trust ve Mikro Segmentasyon

Erişimi daraltmadan tutulan erişim kaydının faydası neden sınırlı kalır.

Kubernetes

Kubernetes Sürüm Yükseltme

Destek penceresi dışına düşen cluster neden bir güvenlik sorununa dönüşür.