Türkiye lokasyon veri depolama: KVKK açısından yedekler ve kişisel veri içeren dosyalar nerede tutulmalı?

Ana sunucunuz İstanbul'da olabilir ama gece alınan yedek Frankfurt'a, Dublin'e ya da Virginia'ya gidiyorsa kişisel veri yine yurt dışındadır. Türkiye lokasyon veri depolama kararı yalnız üretim sunucusunu değil yedekleri, replikaları ve felaket kurtarma kopyalarını da kapsamalıdır. Bu rehber KOBİ sahipleri ve sistem yöneticileri için hazırlandı: yedeğin KVKK açısından nerede durması gerektiğini, gizli aktarımları nasıl bulacağınızı ve Türkiye'de değiştirilemez bir şirket dışı yedeği nasıl kuracağınızı anlatır.

Not: Bu yazı teknik bir rehberdir, hukuki tavsiye değildir. Aktarım dayanağı ve sözleşme konusunda KVKK danışmanınızla ya da avukatınızla çalışın.

Türkiye lokasyon veri depolama ne demek, yedek için neden ayrıca önemli?

Türkiye lokasyonu, verinin fiziksel olarak Türkiye sınırları içindeki bir veri merkezinde tutulması demektir. Sağlayıcının Türk şirketi olması ya da faturanın TL kesilmesi bunu tek başına sağlamaz. Belirleyici olan, disklerin hangi ülkede durduğu ve verinin hangi ülkeye kopyalandığıdır.

Yedek bu konuda en çok gözden kaçan kalemdir. Çünkü:

• Yedek, üretim verisinin tam bir kopyasıdır. Müşteri listesi, bordro, cari kartlar, e-posta arşivi hepsi içindedir.
• Yedekler genellikle üretim verisinden daha uzun saklanır. Silinmiş bir kişinin kaydı aylarca yedekte yaşamaya devam eder.
• Yedek yazılımları çoğu zaman varsayılan bir bulut bölgesiyle gelir ve kurulumda bu bölge sorgulanmadan kabul edilir.

Kısacası üretim sunucusunu Türkiye'ye taşıyıp yedeği yurt dışında bırakmak, KVKK açısından sorunun yarısını çözer.

KVKK m.9: yurt dışındaki yedek neden aktarım sayılabilir?

6698 sayılı Kanun'un 9. maddesi, 2024'te yapılan değişiklikle yurt dışı aktarım için kademeli bir sistem kurdu. Ana hatlarıyla:

1. Yeterlilik kararı: Kurul'un aktarım yapılan ülke ya da sektör için verdiği karar.
2. Uygun güvenceler: Yeterlilik kararı yoksa Kurul'un yayımladığı standart sözleşme, bağlayıcı şirket kuralları ya da Kurul izniyle yazılı taahhütname. Standart sözleşmenin imzadan sonra 5 iş günü içinde Kurum'a bildirilmesi gerekir.
3. Arızi aktarım istisnaları: Düzenli ve süreklilik taşımayan durumlar için dar istisnalar.

Burada kritik nokta şudur: Düzenli çalışan bir yedekleme işi "arızi" sayılmaz. Her gece otomatik olarak yurt dışındaki bir depoya giden yedek, süreklilik taşıyan bir aktarımdır ve dayanağı ya yeterlilik kararı ya da uygun güvenceler olmalıdır. Verinin şifreli olması aktarım niteliğini kendiliğinden ortadan kaldırmaz; şifreleme bir güvenlik tedbiridir, aktarım dayanağı değildir.

Güncel metin, standart sözleşme şablonları ve bildirim usulü için resmi kaynak KVKK'nın kendi sitesidir. Yorumlar zaman içinde değişebildiği için karar vermeden önce oradaki güncel duyurulara bakın.

Yedek, replika ve felaket kurtarma kopyası arasındaki fark önemli mi?

Teknik olarak farklıdırlar, KVKK açısından sonuç benzerdir. Gecelik yedek, anlık replika ya da yalnız felaket anında devreye giren bekleme kopyası, hepsi kişisel verinin yurt dışında bir sistemde saklanması demektir. "Yalnız felaket anında kullanacağız" demek, verinin orada sürekli durduğu gerçeğini değiştirmez.

Ana sunucu Türkiye'de, yedek yurt dışında: gizli aktarım senaryoları

Çoğu şirket bilinçli olarak yurt dışına yedek göndermez; aktarım fark edilmeden olur. Sık görülen senaryolar:

• SaaS yedek ürünleri: E-posta, ofis paketi ya da CRM yedeği sunan hizmetler veriyi kendi seçtikleri bölgede tutar. Panelde bölge seçimi yoksa veri büyük olasılıkla yurt dışındadır.
• Yedek yazılımının varsayılan bulut hedefi: Ajan kurulurken "bulut depoya da kopyala" seçeneği açık bırakılır.
• NAS cihazlarının bulut senkronu: Ofisteki NAS, üreticinin bulut hizmetine kopyalama yapacak şekilde ayarlanmış olabilir.
• Telemetri ve hata raporları: Bazı uygulamalar çökme dökümü ya da tanılama paketi gönderir. Bu paketler bellek içeriği, dolayısıyla kişisel veri içerebilir.
• Uzaktan destek erişimi: Yazılım üreticisinin ya da bakım firmasının yurt dışındaki ekibi sunucuya bağlanıp veriyi görüntülüyorsa bu da erişim yoluyla aktarım riskidir.
• Yedeğin yedeği: Türkiye'deki sağlayıcınız kopyaları kendi içinde yurt dışındaki bir bölgeye çoğaltıyor olabilir. Bunu yalnız sözleşme ve teknik doküman söyler.

Sunucudan dışarı giden bağlantıları listeleme

Aşağıdaki betik, sunucudaki kurulu TCP bağlantılarının uzak adreslerini, bağlantıyı açan süreci ve whois kaydındaki ülke kodunu listeler. Ubuntu 24.04 ve Debian 12 için hazırlandı. Yalnız okuma yapar, sistemde hiçbir şeyi değiştirmez; geri alınacak bir adım yoktur. whois paketi gerekir (sudo apt install whois), süreç adlarını görmek için sudo ile çalıştırın.

#!/usr/bin/env bash
# disari-baglantilar.sh
# Kurulu TCP bağlantılarının uzak IP'sini, süreç adını ve whois ülke kodunu listeler.
# Yalnız okur, sistemde değişiklik yapmaz. Tekrar tekrar çalıştırılabilir.
set -euo pipefail

command -v whois >/dev/null || { echo "whois bulunamadı: sudo apt install whois"; exit 1; }

ss -Htnp state established | while read -r _ _ _ peer proc; do
  ip="${peer%:*}"          # sondaki :port kısmını at
  ip="${ip#[}"; ip="${ip%]}"   # IPv6 köşeli parantezlerini temizle
  ip="${ip#::ffff:}"       # IPv4 eşlemeli IPv6 önekini temizle
  # Yerel ve özel ağ adreslerini atla
  case "$ip" in
    127.*|::1|10.*|192.168.*|172.1[6-9].*|172.2[0-9].*|172.3[0-1].*) continue ;;
  esac
  name=$(sed -n 's/.*(("\([^"]*\)".*/\1/p' <<<"${proc:-}")
  echo "$ip ${name:-bilinmiyor}"
done | sort -u | while read -r ip name; do
  # whois kaydındaki ilk country satırını al (kayıt ülkesidir, fiziksel konum değildir)
  cc=$(whois "$ip" 2>/dev/null | awk -F: 'tolower($1) ~ /^country$/ {gsub(/[ \t]/,"",$2); print toupper($2); exit}')
  printf '%-40s %-20s %s\n' "$ip" "$name" "${cc:-?}"
done

Beklenen çıktı şuna benzer (adresler belge amaçlıdır):

192.0.2.10                               sshd                 TR
198.51.100.25                            backup-agent         DE
203.0.113.40                             telemetryd           US

Bu çıktıyı yorumlarken dikkat: whois ülke kodu IP bloğunun kayıtlı olduğu ülkeyi gösterir, sunucunun fiziksel konumunu kesin olarak göstermez. Betik size "hangi süreç nereye konuşuyor" sorusunun listesini verir; kesin konum için o hizmetin sözleşmesine ve bölge ayarına bakmanız gerekir. Yedekleme saatinde de çalıştırın, çünkü yedek ajanları çoğu zaman yalnız o saatte bağlantı açar.

Sektörel kurallar: finans ve benzeri alanlar

KVKK genel çerçevedir; bazı sektörlerde ek düzenleme vardır. Bankacılıkta BDDK'nın bilgi sistemlerine ilişkin düzenlemeleri, birincil ve ikincil (yedek) sistemlerin yurt içinde bulundurulmasını öngörür. Ödeme ve elektronik para kuruluşları, sigorta, sermaye piyasası kurumları ve kamu ile çalışan firmalar için de benzer yerelleştirme beklentileri bulunabilir.

Bu alanlardaysanız karar ölçütü basittir: yedek merkezinin yeri tartışmaya açık değil, düzenleyicinizin güncel metnine göre belirlenir. Kendi sektörünüzün mevzuatını ve denetim raporlarınızı uyum birimi ya da hukuk danışmanınızla birlikte kontrol edin. Bu bölüm de hukuki tavsiye değildir.

Teknik tedbirler: şifreleme, yetki, kayıt ve imha

Konum doğru olsa bile yedek korunmuyorsa risk sürer. KVKK'nın "uygun güvenlik düzeyi" beklentisini yedek için şöyle somutlaştırabilirsiniz:

• İstemci tarafında şifreleme: Yedek, sunucudan çıkmadan şifrelenmeli. Anahtar ya da parola sağlayıcıda değil sizde durmalı ve ayrı bir yerde (ör. şirket parola kasası) saklanmalı.
• Ayrı kimlik bilgisi: Yedek hedefine erişen anahtar yalnız o bucket'a yazma yetkisine sahip olmalı. Üretim sunucusunun yönetici hesabı yedek deposunu silebiliyorsa fidye yazılımı da silebilir.
• Erişim kaydı: Kimin hangi yedeği ne zaman indirdiği kayıt altında olmalı. Geri yükleme de bir veri işleme faaliyetidir.
• Saklama ve imha süresi: Kişisel veri saklama ve imha politikanızda yedekler için ayrı bir süre yazın. Süresi dolan yedekler otomatik silinmeli; "ne olur ne olmaz" diye sonsuza kadar tutulan yedek, imha yükümlülüğüyle çelişir.
• Geri yükleme testi: Hiç geri yüklenmemiş yedek, var olduğu kanıtlanmamış yedektir. Ayda en az bir kez örnek bir dosya ya da veritabanı geri yükleyin ve sonucu kaydedin.

Türkiye'de şirket dışı, değiştirilemez yedek kurmak

Fidye yazılımına ve KVKK'ya aynı anda cevap veren yapı, 3-2-1 kuralının Türkiye içinde uygulanmasıdır:

• 3 kopya: Üretim verisi ve iki yedek.
• 2 farklı ortam: Örneğin sunucunun yerel snapshot'ı ve nesne depolama.
• 1 şirket dışı kopya: Üretim ortamından ayrı, mümkünse değiştirilemez (object lock) bir hedef.

Şirket dışı kopyayı S3 uyumlu bir depoya göndermek en esnek yoldur. Örneğin İstanbul'daki S3 uyumlu Object Storage hizmetinde veri ve kopyaları Türkiye dışına çıkmaz; restic ya da rclone gibi açık kaynak araçlarla doğrudan kullanılabilir.

Adım 1: Object lock açık bucket'ı doğrulama

Object lock, bucket oluşturulurken açılmalıdır; sonradan açılamayabilir. Bucket'ınızın kilit yapılandırmasını aşağıdaki komutla kontrol edin. AWS CLI v2 için hazırlandı, yalnız okuma yapar. ORNEK_BUCKET ve uç nokta adresini kendi değerlerinizle değiştirin.

aws s3api get-object-lock-configuration \
  --bucket ORNEK_BUCKET \
  --endpoint-url https://s3.example.com

Beklenen çıktı, kilidin etkin olduğunu ve varsayılan saklama süresini gösterir:

{
    "ObjectLockConfiguration": {
        "ObjectLockEnabled": "Enabled",
        "Rule": {
            "DefaultRetention": {
                "Mode": "COMPLIANCE",
                "Days": 30
            }
        }
    }
}

COMPLIANCE kipinde süre dolmadan nesne kimse tarafından silinemez, yönetici hesabı dahil. Bu, fidye yazılımına karşı istediğiniz şeydir ama yanlış süre seçerseniz faturanız da o süre boyunca düşmez. Süreyi saklama politikanızla birlikte belirleyin.

Adım 2: restic ile şifreli yedek

Aşağıdaki örnek restic ile şifreli ve artımlı yedek alır. Ubuntu 24.04 ve Debian 12 için hazırlandı. restic init yalnız bir kez çalıştırılır; depo zaten varsa hata verir ve hiçbir şeyi bozmaz. Geri almak için zamanlanmış görevi kaldırmanız yeterlidir; kilitli yedekler süre dolunca silinebilir hale gelir.

#!/usr/bin/env bash
# /root/yedek.sh : /etc ve /srv dizinlerini Türkiye'deki S3 uyumlu depoya yedekler.
set -euo pipefail

export AWS_ACCESS_KEY_ID="ORNEK_ERISIM_ANAHTARI"        # yalnız bu bucket'a yazma yetkili anahtar
export AWS_SECRET_ACCESS_KEY="ORNEK_GIZLI_ANAHTAR"
export RESTIC_REPOSITORY="s3:https://s3.example.com/ORNEK_BUCKET"
export RESTIC_PASSWORD_FILE="/root/.restic-parola"      # chmod 600, kopyası parola kasasında

# Depo yoksa oluştur (varsa sessizce geç)
restic snapshots >/dev/null 2>&1 || restic init

# Yedeği al
restic backup /etc /srv --tag gunluk

# Saklama politikası: kilit süresinden (30 gün) uzun tutun ki prune kilitli nesneye takılmasın
restic forget --tag gunluk --keep-daily 45 --keep-monthly 12 --prune

# Bütünlük kontrolü: verinin bir kısmını okuyarak doğrula
restic check --read-data-subset=5%

Seçeneklerin tamamı için restic help backup ve restic help forget komutlarının çıktısına bakabilirsiniz. Zamanlama, veritabanı dökümü ve object lock ile birlikte kullanım ayrıntıları için S3 yedekleme rehberimiz adım adım örnek içerir.

Adım 3: Doğrulama

Kurulumdan sonra şu kontrolleri yapın:

1. restic snapshots komutu bugünün tarihli bir snapshot göstermeli.
2. Kilitli bir nesneyi silmeyi deneyin (aws s3api delete-object ile, --version-id vererek). AccessDenied dönmesi kilidin çalıştığını gösterir.
3. restic restore latest --target /tmp/geri-yukleme-testi --include /etc/hostname ile tek bir dosyayı geri yükleyin ve içeriğini karşılaştırın. Testten sonra yalnız /tmp/geri-yukleme-testi dizinini silin.
4. Dışarı bağlantı betiğini yedek saatinde tekrar çalıştırın; yedek trafiğinin yalnız Türkiye'deki uç noktaya gittiğini görün.

Üretim sunucunuzu da Türkiye'de tutmak istiyorsanız aynı adımları İstanbul lokasyonlu bir bulut sunucu üzerinde uygulayabilirsiniz.

Sağlayıcıya sorulacaklar

Teklif alırken şu soruların yazılı cevabını isteyin:

• Verim hangi şehirde, hangi veri merkezinde duruyor?
• Yedek ve replika kopyaları nerede? Herhangi biri Türkiye dışına çıkıyor mu?
• Destek ya da bakım için yurt dışından sistemlere erişim var mı?
• Alt yüklenici kullanıyor musunuz, varsa hangi ülkede?
• Sözleşme bittiğinde verim nasıl ve ne kadar sürede imha ediliyor, imha tutanağı veriliyor mu?
• Object lock ya da benzeri değiştirilemezlik özelliği var mı, hangi kipte?
• Erişim kayıtlarını bana sağlayabiliyor musunuz?

"Türkiye'de" cevabı yeterli değildir; yedeklerin ve kopyaların da Türkiye'de olduğunun sözleşmede ya da hizmet belgesinde yazması gerekir.

Sık yapılan hatalar

• Yalnız ana sunucuya bakmak: Üretim Türkiye'de, yedek ise yedek yazılımının varsayılan yurt dışı bölgesinde kalır.
• Şifrelemeyi aktarım dayanağı sanmak: Şifreleme riski azaltır ama m.9 kapsamındaki yükümlülüğü ortadan kaldırmaz.
• Yedek anahtarını üretim sunucusuyla paylaşmak: Silme yetkili tek bir anahtar, fidye yazılımının yedeği de silmesine izin verir.
• Saklama süresi tanımlamamak: Yıllarca birikmiş yedekler hem maliyet hem imha yükümlülüğü sorunu yaratır.
• Object lock süresini forget politikasından uzun tutmak: restic prune kilitli nesneleri silemez ve hata verir; politikayı kilit süresine göre ayarlayın.
• Geri yükleme testini hiç yapmamak: Parola dosyası kaybolmuşsa şifreli yedek kullanılamaz; bunu felaket gününde öğrenmek istemezsiniz.

Sık sorulan sorular

Yedek şifreliyse yurt dışında tutmak KVKK'ya uygun olur mu?

Şifreleme önemli bir güvenlik tedbiridir ama tek başına yurt dışı aktarımın dayanağı değildir. Düzenli yedekleme için m.9'daki yeterlilik kararı ya da standart sözleşme gibi uygun güvencelerden birine ihtiyaç vardır. En sade yol, yedeği de Türkiye'de tutmaktır.

Standart sözleşme imzaladıysam yurt dışı yedek sorunsuz mu?

Standart sözleşme bir dayanak sağlar; imzadan sonra 5 iş günü içinde Kurum'a bildirilmesi gerekir. Ayrıca aydınlatma metinlerinizi güncellemeniz ve sağlayıcının yükümlülüklere uyduğunu takip etmeniz gerekir. Bu idari yük, yedeği Türkiye'de tutarak tamamen ortadan kalkar.

Türkiye'deki sağlayıcı, kopyaları yurt dışına gönderiyor olabilir mi?

Olabilir. Bazı hizmetler dayanıklılık için kopyaları farklı ülkelerdeki bölgelere dağıtır. Bunu yalnız sözleşme ve hizmet belgesi söyler; "veri ve tüm kopyaları Türkiye'de" ifadesini yazılı olarak isteyin.

Kendi ofisimdeki NAS yeterli şirket dışı yedek sayılır mı?

Hayır. Ofisteki NAS, üretim ortamıyla aynı binada ve çoğu zaman aynı ağdadır; yangın, hırsızlık ya da fidye yazılımı ikisini birlikte etkiler. NAS iyi bir yerel kopyadır, şirket dışı kopya için ayrı bir hedef gerekir.

Object lock süresi ne kadar olmalı?

Tek doğru sayı yoktur. Fidye yazılımının fark edilme süresi, saklama politikanız ve maliyet birlikte değerlendirilir. Pratik ölçüt: bir saldırıyı fark etmeniz için gereken en uzun süreden daha uzun olsun, imha politikanızdaki süreyi ise aşmasın.

Bu işi hazır yapmak isterseniz

Yedek hedefini kurmak, kilit süresini belirlemek ve geri yükleme testini düzenli yürütmekle uğraşmak istemiyorsanız, KVKK yedekleme çözümüyle verilerinizin Türkiye'de tutulan, üretim ortamından ayrı bir kopyasını oluşturabilirsiniz. Kapsamı ve saklama süresini ihtiyacınıza göre birlikte netleştirebiliriz.

Sonuç

KVKK açısından soru "sunucum nerede?" değil, "verimin bütün kopyaları nerede?" sorusudur. Önce dışarı giden bağlantıları listeleyin, yedek yazılımlarının ve SaaS araçlarının bölgesini kontrol edin. Ardından Türkiye'de, şifreli ve değiştirilemez bir şirket dışı kopya kurun, saklama süresini yazılı hale getirin ve geri yüklemeyi düzenli test edin. Hukuki dayanak konusundaki son kararı ise danışmanınızla birlikte verin.