Yedekleme (Backup) Sistemleri Kişisel Veri İhlaline Nasıl Dönüşür?
Snapshot’lar, Offline Yedekler ve KVKK Açısından Kontrol Edilmeyen Veri Alanları
KVKK uyum çalışmalarında kurumların büyük çoğunluğu; aktif sistemler, uygulamalar ve kullanıcı erişimleri üzerine yoğunlaşırken, yedekleme (backup) altyapılarını genellikle yalnızca bir iş sürekliliği veya felaket kurtarma konusu olarak ele almaktadır. Oysa uygulamada yedekleme sistemleri, kontrol edilmediği takdirde KVKK açısından en yüksek riskli veri alanlarından biri hâline gelmektedir.
Bu yazıda; snapshot’lar, offline yedekler, versiyonlama sistemleri ve arşiv ortamlarının nasıl fark edilmeden kişisel veri ihlaline zemin hazırladığı, Kurul yaklaşımı ve denetim pratikleri ışığında ele alınmaktadır.
Backup alanları, aktif sistemlerin birebir kopyasıdır; çoğu zaman daha uzun saklanır ve denetim dışı kalır. Bu nedenle KVKK açısından “kontrol edilmeyen veri alanı” riskini büyütür. Saklama-imha uyumu, erişim kontrolü, loglama ve ihlal değerlendirmesi backup mimarisine entegre edilmelidir.
Yedekleme Sistemleri KVKK Kapsamında mıdır?
KVKK açısından temel soru şudur:
Bir sistemde kişisel veri bulunuyor mu?
Yedekleme sistemleri;
- Aktif sistemlerin birebir kopyasını içerir,
- Çoğu zaman daha uzun süre saklanır,
- Erişim kontrolleri zayıf olabilir,
- Günlük operasyonun dışında kaldığı için denetim dışı kalır.
Bu nedenle, yedekleme ortamlarında yer alan veriler;
aktif sistemlerdeki verilerle aynı kişisel veri niteliğini taşır.
“Yedek” olması, bu verileri KVKK kapsamı dışına çıkarmaz.
Kurul yaklaşımı nettir:
Kişisel veri nerede tutuluyorsa, KVKK yükümlülükleri de oradadır.
Yedeklerde Tutulan Veriler Neden Envantere Girmiyor?
Denetimlerde en sık karşılaşılan sorunlardan biri; veri envanteri ile yedekleme altyapısının birbirinden tamamen kopuk olmasıdır.
Uygulamada sıklıkla:
- Envanter sadece canlı sistemler üzerinden hazırlanmakta,
- Yedekleme sunucuları, NAS cihazları, tape kütüphaneleri kapsam dışı bırakılmakta,
- “Teknik alan” gerekçesiyle hukuki analiz yapılmamaktadır.
Bu durum, Kurul nezdinde şu anlama gelir:
Envanteri eksik olan bir kurum, veri işleme faaliyetlerini tam olarak tanımlayamamıştır.
Dolayısıyla yedeklerde tutulan kişisel verilerin envantere dâhil edilmemesi, doğrudan uyumsuzluk olarak değerlendirilmektedir.
- Backup altyapısının “sistem” olarak envanterde hiç yer almaması
- Yedek erişim yetkilerinin rol bazlı olmaması / ortak hesap kullanımı
- Backup saklama sürelerinin saklama-imha politikasıyla eşleşmemesi
- Geri dönüş testlerinin yapılmaması veya kayıt altına alınmaması
Snapshot ve Versiyonlama Sistemleri Kişisel Veri Sayılır mı?
Modern altyapılarda snapshot ve versiyonlama mekanizmaları yaygın şekilde kullanılmaktadır:
- Sanal sunucu snapshot’ları
- Dosya sistemleri versiyonları
- Bulut tabanlı otomatik yedekler
Bu yapılar teknik olarak “geçici” gibi görülse de;
- Önceki tarihli kişisel verileri barındırır,
- Saklama süresi kontrolsüz biçimde uzayabilir,
- İmha süreçlerinin dışında kalabilir.
KVKK açısından snapshot’lar:
- Ayrı bir veri kopyasıdır,
- Kişisel veri içerir,
- Saklama ve imha yükümlülüğüne tabidir.
Snapshot retention politikası, otomasyon çıktıları, snapshot listeleri, silme job logları ve erişim matrisi (kim-neye erişiyor) birlikte saklanmalıdır.
Snapshot/versiyon süreleri; saklama-imha politikasıyla uyumlu takvimlenmeli, istisnalar onay mekanizmasına bağlanmalıdır.
Saklama Süresi Dolan Veriler Yedeklerde Neden Hâlâ Duruyor?
Bu başlık, denetimlerde en kritik kırılma noktalarından biridir.
Birçok kurumda:
- Aktif sistemlerde veri silinmiş veya anonimleştirilmiş,
- Ancak aynı verinin yedeklerde yıllarca tutulmaya devam ettiği görülmektedir.
Bu durum şu riski doğurur:
Hukuken imha edilmiş sayılan bir veri,
Teknik olarak hâlâ erişilebilir durumdadır.
Kurul açısından bakıldığında:
Yedeklerde tutulan kişisel veriler için de saklama süresi ve imha yükümlülüğü aynen geçerlidir.
Bu nedenle “yedekler dokunulmaz” yaklaşımı, KVKK ile bağdaşmamaktadır.
- Aktif sistem saklama süresi (ör. 2 yıl) + yedekleme katmanı (ör. 30/90/365 gün) ayrı ayrı tanımlanır.
- İş birimi istisnaları (dava/uyuşmazlık) gerekçelendirilir ve sürelendirilir.
- Yedek imha işlemleri için log + rapor + onay akışı oluşturulur.
Fidye Yazılımı Sonrası Yedeklerin Hukuki Riski
Fidye yazılımı vakalarında yedekleme sistemleri genellikle kurtarıcı olarak görülür. Ancak KVKK perspektifinden konu daha karmaşıktır.
Özellikle:
- Şifrelenmiş yedekler,
- Ele geçirilmiş offline kopyalar,
- Harici ortamlarda saklanan yedekler
şu soruları gündeme getirir:
- Yedeklere yetkisiz erişim oldu mu?
- Kişisel veri ihlali gerçekleşti mi?
- İhlal bildirimi yapılmalı mı?
Kurul’un yaklaşımı; verinin ele geçirilme ihtimali varsa, fiili kullanım olmasa dahi ihlal değerlendirmesi yapılması yönündedir. Bu da yedekleme altyapılarını doğrudan veri ihlali risk alanı hâline getirmektedir.
EDR/SIEM alarmları, yedekleme yazılımı audit logları, repo erişim izleri, servis hesapları, MFA kayıtları ve anahtar yönetim izleri.
Risk analizi, ilgili kişi sayısı/etki, veri kategorileri, muhtemel zarar ve ihlal bildirim kararının gerekçelendirilmesi.
Kurul Yaklaşımı: “İmha Edilmemiş Veri” Sorunu
Kurul kararlarında açıkça görülen temel yaklaşım şudur:
Silinmiş gibi görünen,
Ancak teknik olarak geri getirilebilir olan veriler,
Hukuken imha edilmiş sayılmaz.
Yedekleme sistemleri bu açıdan Kurul’un özellikle hassas olduğu alanlardandır. İmha politikasında yazan süreçlerin;
- Yedekleme sistemleri için de tanımlı olması,
- Uygulanabilir ve denetlenebilir olması,
- Kayıt altına alınması
beklenmektedir.
Teknik ve İdari Olarak Yedekleme Süreçleri Nasıl Yönetilmeli?
Teknik Tedbirler
- Yedekleme ortamlarına erişimlerin sınırlandırılması (rol bazlı, ayrıcalıklı hesap, MFA)
- Snapshot ve versiyonlama sürelerinin tanımlanması ve otomasyonla uygulanması
- Yedekler için ayrı saklama–imha takvimleri ve imha kanıt seti oluşturulması
- Şifreleme, anahtar yönetimi ve erişim loglarının merkezi toplanması
- Geri dönüş testlerinin periyodik yapılması ve raporlanması
İdari Tedbirler
- Yedekleme sistemlerinin veri envanterine dâhil edilmesi
- Saklama ve imha politikalarında backup/snapshot/arşiv alanlarının açıkça tanımlanması
- BT ve hukuk ekiplerinin ortak süreç yönetimi (RACI / sorumluluk matrisi)
- Düzenli iç denetim ve kontrol mekanizmaları
- Backup/NAS/tape/snapshot alanlarının envanterde açıkça tanımlanması
- Backup erişimlerinin rol bazlı, ayrıcalıklı hesaplarla ve MFA ile yönetilmesi
- Snapshot/versiyon sürelerinin politika ile uyumlu şekilde standardize edilmesi
- Geri dönüş testlerinin takvimlendirilmesi ve kanıt setiyle kayıt altına alınması
- Yedek şifreleme + anahtar yönetimi + erişim loglarının merkezi toplanması
Ana Çıkarımlar (Hızlı Okuma)
Karar vericiler için; bu sayfadan doğrudan aksiyon çıkaran özet bloktur.
- Backup alanları da kişisel veri işleme ortamıdır: KVKK yükümlülüğü “yedek” etiketiyle ortadan kalkmaz.
- Envanter kopukluğu, uyum kopukluğudur: Backup/NAS/tape/snapshot alanları envanterde görünmüyorsa denetimde kırılır.
- İmha, yalnızca aktif sistemde silmek değildir: Geri getirilebilir kopyalar imha yükümlülüğünü boşa düşürür.
- Ransomware senaryosunda “erişim şüphesi” bile kritiktir: Teknik inceleme + hukuki değerlendirme eş zamanlı yürütülmelidir.
- Kanıt seti olmadan kontrol tamamlanmış sayılmaz: Log, rapor, test tutanağı, erişim matrisi ve onay akışları saklanmalıdır.
Envanterde backup alanlarını satır bazında görünür kılın; erişim matrisi çıkarın; snapshot retention ve backup retention sürelerini yazılı hale getirin; MFA/ayrıcalıklı hesap kullanımını devreye alın; ilk geri dönüş testini planlayın ve kayıt altına alın.
Saklama-imha ile yedekleme takvimlerini birleştirin; imha kanıt setini standardize edin; merkezi log toplama ve alarm senaryolarını oluşturun; ransomware masa başı tatbikatı + ihlal karar matrisi (hukuk/BT) yayınlayın.
Mini Sözlük (Kısa Tanımlar)
Üretken arama motorlarının yanlış yorum riskini azaltmak için; temel terimlerin kısa ve net karşılıkları.
- Backup (Yedek)
- Aktif sistemdeki verinin belirli periyotlarla alınan kopyasıdır; kişisel veri içeriyorsa KVKK kapsamındadır.
- Snapshot
- Sistemin belirli bir andaki durumunu (veri + yapı) kopya olarak saklayan mekanizmadır; retention süresi kontrolsüz uzarsa uyum riski üretir.
- Offline Yedek
- Ağ bağlantısı kesilmiş/izole ortamda tutulan yedektir; fidye yazılımına direnç sağlar ancak erişim/anahtar yönetimi zayıfsa risk taşır.
- Saklama–İmha Takvimi
- Verinin ne kadar süre tutulacağı ve hangi yöntemle silineceği/anonymize edileceğini belirleyen uygulanabilir plan ve kanıt setidir.
- Kanıt Seti (Audit Evidence)
- Kontrolün uygulandığını gösteren loglar, raporlar, test tutanakları, erişim matrisi, onay akışları ve otomasyon çıktılarıdır.
En Güvenli Alan Sanılan Yer, En Büyük Risk Olabilir
Yedekleme sistemleri çoğu zaman “güvenli alan” olarak görülse de, KVKK açısından en kontrolsüz veri alanlarından biri hâline gelmiştir. Aktif sistemler ne kadar iyi yönetilirse yönetilsin, yedekleme altyapıları bu sürecin dışında bırakıldığında;
- İmha yükümlülüğü ihlal edilir,
- Veri ihlali riski artar,
- Denetimlerde ağır bulgular ortaya çıkar.
Nesil Teknoloji olarak KVKK ve siber güvenlik çalışmalarında; yedekleme altyapılarını yalnızca teknik değil, hukuki risk alanı olarak da ele alıyor; backup, snapshot ve arşiv sistemlerini gerçek uyum perspektifiyle değerlendiriyoruz.
Sık Sorulan Sorular
Backup ortamı “sadece teknik” bir alan sayılabilir mi?
Hayır. Backup ortamında kişisel veri bulunuyorsa, KVKK yükümlülükleri de o alana taşınır. “Yedek” niteliği, kişisel veri vasfını ortadan kaldırmaz.
Aktif sistemden silinen veri, yedekte duruyorsa imha edilmiş sayılır mı?
Hayır. Teknik olarak geri getirilebilir veri, hukuken imha edilmiş kabul edilmez. Bu nedenle yedekler için de uygulanabilir saklama-imha planı gerekir.
Fidye yazılımı sonrası yedeklere erişim şüphesi varsa ne yapılmalı?
Yetkisiz erişim ihtimali dahi ihlal değerlendirmesini tetikleyebilir. Teknik inceleme (delil bütünlüğü, loglar, erişim izleri) ile eş zamanlı hukuki değerlendirme yürütülmelidir.
Yedekler şifreliyse KVKK riski ortadan kalkar mı?
Şifreleme riski azaltır; ancak tek başına “tam uyum” sağlamaz. Anahtar yönetimi, erişim yetkileri, loglama, retention ve imha süreçleri birlikte tasarlanmalıdır.
Tape (teyp) arşivlerinde imha nasıl yönetilmeli?
Tape arşivlerinde saklama süresi tanımı, envanter ilişkilendirmesi, fiziksel güvenlik ve imha yöntemi (güvenli imha/eritme/parçalama vb.) yazılı prosedüre bağlanmalı ve kanıt seti üretilmelidir.
Snapshot retention süresi nasıl belirlenmeli?
Snapshot’lar “iş ihtiyacı” ve “saklama-imha” politikasıyla uyumlu olacak şekilde süreli tanımlanmalı; istisnalar gerekçeli onay mekanizmasıyla yönetilmelidir.
İlgili hizmet: veri ihlali acil eylem planı hakkında detaylı bilgi almak için sayfamızı inceleyebilirsiniz.
