1. Bulut Altyapı Türleri: On-Prem, IaaS, PaaS, SaaS (Ne Değişir?)
Bulut kararı tek bir seçenek değildir; farklı işletim modelleri KVKK riskini farklı yerlerde büyütür. On-prem’de kontrol sizdedir ama operasyon yükü artar. SaaS’ta hız yüksektir ama veri lokasyonu, erişim ve loglar büyük ölçüde sağlayıcıya bağlıdır. Bu yüzden on-prem vs bulut kararı verirken hangi modelde hangi kontrolün kimde olduğunu netleştirmek gerekir.
KVKK açısından “kontrol yüzeyi” farkı
- •On-Prem: veri lokasyonu ve erişim kontrolü daha doğrudan, bakım sizde
- •IaaS: altyapı sağlayıcıda, yapılandırma sizde (region, network, logs)
- •PaaS: yönetim kolay, ama bazı log/backup katmanları platform tarafından yönetilir
- •SaaS: en hızlı; veri lokasyonu/alt işlemciler/backup politikası çok kritik
“Ortam” kavramı: dev/stage/prod
KVKK riski yalnız production’da değil; dev ve stage ortamlarında da ortaya çıkar (test verisi, kopya DB’ler). Hosting stratejisi bu ortamları da kapsamalıdır.
☑ Mini Check
- •Kullandığınız model net mi? (IaaS/PaaS/SaaS)
- •Dev/stage/prod ortamları ayrı mı ve dokümante mi?
- •Test ortamında gerçek veri kullanımı kontrol altında mı?
- •Platformun backup/log politikaları biliniyor mu?
- •Sağlayıcı tarafında admin erişim ve audit kabiliyeti var mı?
Ne yapmalıyım?
- • Her sistem için işletim modelini yazın (web, PMS, CRM, BI).
- • Dev/stage/prod ortamlarını ve veri kaynaklarını çıkarın.
- • Testte gerçek veri kullanımını sınırlandırın (mask/pseudo).
- • PaaS/SaaS için provider “backup/log/region” parametrelerini netleştirin.
- • İşletim modeli kararını prod, backup ve log katmanlarıyla birlikte dokümante edin.
2. Veri Lokasyonu ve Bölge Seçimi: “Prod Nerede?” Yetmez
KVKK açısından veri lokasyonu neden önemli?
Kısa yanıt: çünkü veri lokasyonu; verinin hangi ülke/bölgede tutulduğunu ve hangi ülke hukuk/altyapı sınırları içinde işlendiğini belirler. Teknik açıdan sadece production değil; backup, replikasyon ve log lokasyonları da veri lokasyonu kapsamındadır. Bu nedenle “TR region seçtik” demeden önce tüm veri kopyalarının nerede olduğunu görmek gerekir.
Region seçimi: tek bölge mi, çoklu bölge mi?
- •Tek bölge: kontrol daha kolay, DR (felaket kurtarma) planı ayrı tasarlanır
- •Çoklu bölge: dayanıklılık artar; ama veri lokasyonu ve replikasyon kontrolü kritikleşir
“Hidden residency” riski: log ve monitoring servisleri
Bazı log/monitoring servisleri farklı bölgelerde saklama yapabilir. Bu yüzden hosting stratejisinde “prod/backup/log” üçlüsü birlikte yazılmalıdır. Özellikle cloud backup ve log bölgesi kararları, panel erişimleri ve audit trail ile aynı tabloda değerlendirilmelidir.
☑ Mini Check
- •Production region net mi?
- •Backup region net mi? (ayrı mı, aynı mı?)
- •Replikasyon varsa hedef bölge(ler) net mi?
- •Log/monitoring verisi nerede tutuluyor?
- •Vendor/alt işlemciler listesi var mı?
Ne yapmalıyım?
- • Prod-backup-log için “lokasyon tablosu” çıkarın.
- • Replikasyon ve snapshot hedeflerini kontrol edin.
- • Log servisi lokasyon ayarlarını doğrulayın.
- • Vendor/alt işlemci envanteriyle eşleştirin.
- • Bölge seçimlerini erişim ve saklama politikalarıyla birlikte güncelleyin.
3. Yedekler ve Replikasyon: KVKK Açısından Nasıl Okunur?
Backup ve loglar da veri lokasyonu kapsamına girer mi?
Kısa yanıt: teknik açıdan evet, çünkü backup ve loglar da kişisel veri içerebilir ve çoğu zaman production’dan daha uzun süre saklanır. Bu yüzden retention, erişim ve lokasyon kontrolü backup/log katmanında daha kritik hale gelir; bulut ortamında şifreleme ve anahtar yönetimi de bu katmanların ayrılmaz parçasıdır.
Backup stratejisi: 3 soru
- Yedek nerede tutuluyor?
- Ne kadar süre tutuluyor (retention)?
- Kim erişebiliyor (RBAC/MFA/audit)?
Replikasyon ve DR: “dayanıklılık” ile “lokasyon” dengesi
DR planı çoklu lokasyon gerektiriyorsa, veri lokasyonu ve erişim kontrolleri daha sıkı tasarlanmalıdır. Burada amaç, dayanıklılığı artırırken “kontrolsüz veri kopyası” üretmemektir.
☑ Mini Check
- •Backup lokasyonu ve retention yazılı mı?
- •Backup erişimi RBAC + MFA ile kısıtlı mı?
- •Backup restore testleri kontrollü mü?
- •Replikasyon hedefleri net mi?
- •Log retention ve erişim kurgusu var mı?
Ne yapmalıyım?
- • Backup politikası oluşturun (lokasyon + süre + erişim).
- • Backup erişimini minimum role indirin.
- • Restore testlerinde gerçek veriyi minimize edin (mask/pseudo).
- • Replikasyon hedeflerini “bilinçli” seçin ve dokümante edin.
- • Şifreleme ve anahtar sahipliğini backup sürecinin parçası yapın.
4. Otel ve B2B İçin Hosting Karar Matrisi: On-Prem vs TR Bulut vs Global Bulut
On-prem mi, Türkiye içi bulut mu, global bulut mu seçmeliyim?
Kısa yanıt: tek doğru yok; karar, veri lokasyonu gereksinimi, operasyonel olgunluk, ölçek ihtiyacı ve erişim kontrol kabiliyetinizle verilir. En sağlıklı yaklaşım, kriterleri puanlayan bir karar matrisi kullanmaktır; özellikle cloud vendor teknik değerlendirmesi yapılmadan region, CDN, backup servisi ve alt hizmet riskleri eksik kalır.
Karar matrisi kriterleri (örnek)
- •Veri lokasyonu kontrolü (prod/backup/log)
- •Erişim kontrolleri (VPN, IP allowlist, MFA, audit)
- •Operasyon yükü (bakım/patch)
- •Ölçeklenebilirlik ve maliyet
- •Denetim hazırlığı (kanıt/rapor çıkarma kolaylığı)
- •Vendor bağımlılığı
Otel örneği: PMS/rezervasyon sistemi barındırma
Otel tarafında PMS/rezervasyon “core” sistemdir; kesinti maliyeti yüksektir. Bu yüzden PMS verisi için hosting mimarisi, DR/backup kurgusu ve admin erişim modeli kararın kritik parçasıdır. Ayrıca web ve PMS arasında veri lokasyonu netleşmeden rezervasyon, müşteri ve operasyon verisinin hangi altyapılar arasında dolaştığı görünmez kalır.
B2B örneği: CRM ve analitik sistemler
B2B’de CRM ve BI katmanı hızla büyür; data warehouse ve log servislerinin lokasyonu/erişimi çoğu zaman gözden kaçar. Matriste “log ve BI” kriteri özellikle görünür olmalıdır.
☑ Mini Check
- •Karar matrisi kriterleri yazılı mı?
- •Prod-backup-log lokasyonları puanlamaya dahil mi?
- •Admin erişimi (VPN/IP/MFA) puanlanıyor mu?
- •Denetim çıktıları (log bundle/export) düşünülmüş mü?
- •Vendor lock-in riski değerlendirildi mi?
Ne yapmalıyım?
- • On-prem / TR bulut / global bulut için kriter tablosu oluşturun.
- • Her sistem için ayrı puanlayın (web ≠ PMS ≠ CRM ≠ BI).
- • Admin erişimi ve audit kabiliyetini “kritik kriter” yapın.
- • Denetim provası gibi operasyonları modele ekleyin.
- • Karar matrisine vendor ve veri akışı kriterlerini de dahil edin.
5. Log ve Yönetim Erişimleri: VPN, IP Kısıtları, Break-Glass ve Audit
Hosting stratejisinin en kritik kısmı “kim erişebilir?” sorusudur. Region TR olsa bile, yönetici paneli herkese açıksa veya vendor erişimleri kontrolsüzse risk büyür. Bu yüzden erişim; VPN, IP allowlist, MFA ve audit ile tasarlanmalıdır. Bu kayıtların hosting lokasyonu ve veri güvenliği raporlaması içinde izlenmesi, yalnız altyapı değil denetim hazırlığı açısından da önemlidir.
Admin erişim modeli (pratik set)
- •VPN veya Zero-Trust erişim
- •IP allowlist (özellikle yönetim panelleri)
- •MFA zorunluluğu
- •Break-glass (acil durum hesabı) — sıkı prosedürle
- •Audit log (kim, ne zaman, ne yaptı)
Key Data Point (yumuşatılmış)
Hosting ve veri lokasyonu farkındalığı olan projelerde, ileride altyapı değişimi/göç kararlarında KVKK kaynaklı sürpriz ve “yeniden mimari” ihtiyacı daha az yaşanır; çünkü prod kadar backup/log ve admin erişimi de baştan düşünülmüştür.
☑ Mini Check
- •Yönetim panelleri VPN/Zero-Trust arkasında
- •IP allowlist uygulanıyor
- •MFA zorunlu
- •Break-glass hesabı prosedürlü
- •Audit log aktif ve düzenli inceleniyor
- •Prod/backup/log lokasyon dokümanı güncel (365 gün)
Ne yapmalıyım?
- • Admin erişimini VPN/Zero-Trust + MFA ile standardize edin.
- • Yönetim panellerine IP allowlist ekleyin.
- • Break-glass prosedürünü yazın ve test edin.
- • Audit log’ları aylık kısa kontrol rutinine bağlayın.
- • Erişim ve lokasyon kayıtlarını aynı yönetim dokümanında tutun.
Teknik not: Hosting kararı; sunucu güvenliği ve KVKK veri güvenliği yönetimiyle birlikte değerlendirilmelidir. Veri aktarımına dair hukuki değerlendirmeler hukuk/KVKK ekibiyle yapılmalı; bu yazı teknik şema ve kontrol seti odaklıdır.
6. Hosting Karar Matrisi
| Seçenek | Veri lokasyonu | Backup/log | Erişim kontrol | Operasyon yükü | Denetim kolaylığı | Not |
|---|---|---|---|---|---|---|
| On-Prem | Doğrudan kurum kontrolünde | Kurumun tasarımına bağlı | VPN/IP/MFA/audit kurum tarafından yönetilir | Yüksek | Kontroller iyi dokümanteyse yüksek | Bakım, patch ve DR sorumluluğu kurumda |
| TR Bulut | Türkiye bölgesi seçimiyle kontrol edilebilir | Backup/log bölgeleri ayrıca doğrulanmalı | Provider + kurum kontrolleri birlikte | Orta | Provider kabiliyetine göre yüksek | Region, replikasyon ve alt hizmetler ayrıca kontrol edilmeli |
| Global Bulut | Region seçimine ve servis mimarisine bağlı | Backup/log/replikasyon farklı bölgelerde olabilir | VPN/Zero-Trust/IP/MFA/audit ile sıkılaştırılmalı | Düşük–Orta | Gelişmiş audit araçları olabilir | Veri aktarımı ve lokasyon kararları hukuk/KVKK ekibiyle değerlendirilmelidir |
7. Hosting/Cloud Veri Lokasyonu & Erişim Yapısı Planlama Şablonunu İndir
Hosting/Cloud Veri Lokasyonu & Erişim Yapısı Planlama Şablonunu İndir — Yazılım / Hosting (v1.0)
Bu şablon, KVKK açısından kritik “prod-backup-log” lokasyon haritasını ve yönetici erişim modelini tek dokümana indirger. On-prem/TR bulut/global bulut seçeneklerini karar matrisiyle karşılaştırmanızı sağlar. Göç ve ölçek kararlarında KVKK kaynaklı sürprizleri azaltmak için operasyonel bir çerçeve sunar.
Kim Kullanır?
IT/BT + güvenlik + KVKK/uyum + proje yöneticileri (otel ve B2B).
Nasıl Kullanılır?
- Her sistem için prod/backup/log lokasyonunu ve sağlayıcı tipini doldur.
- Admin erişim kontrollerini (VPN/IP/MFA/audit) işaretle ve boşlukları çıkar.
- Karar matrisiyle on-prem/TR bulut/global bulut seçeneklerini puanla.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Prod/backup/log lokasyonları belirlendi
- ▢ ✅ Replikasyon hedefleri dokümante
- ▢ ✅ Admin erişim kontrolleri uygulanmış
- ▢ ✅ Karar matrisi puanlanmış
- ▢ ✅ Yıllık gözden geçirme planı var
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Production, backup ve log lokasyonlarını teknik olarak netleştirmek isterseniz KVKK uyum hizmetiyle hosting ve veri lokasyonu kontrolü sayfasına geçebilir, süreçle ilgili ek sorular için de KVKK uyum hizmeti hakkında sık sorulan sorular bölümüne göz atabilirsiniz.
Bir Sonraki Adım
Prod/backup/log lokasyonunu ve admin erişimlerini netleştirir; on-prem/TR bulut/global bulut kararını denetlenebilir matrise bağlar.