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 ilk adım, hangi modelde hangi kontrolün kimde olduğunu netleştirmektir.
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 (H2-1)
- •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.
- • Sunucu güvenliği ile birlikte değerlendirin: https://dgtlface.com/tr/yazilim/sunucu-guvenlik
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.
☑ Mini Check (H2-2)
- •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.
- • KVKK veri güvenliğiyle hizalayın: https://dgtlface.com/tr/raporlama/kvkk-veri-guvenligi
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.
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 (H2-3)
- •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.
- • Sunucu güvenliğiyle birlikte değerlendirin: https://dgtlface.com/tr/yazilim/sunucu-guvenlik
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.
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 DR/backup kurgusu ve admin erişim modeli kararın kritik parçasıdı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 (H2-4)
- •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.
- • Web geliştirme süreçleriyle bağlayın: https://dgtlface.com/tr/yazilim/web-sitesi-gelistirme
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.
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 (H2-5)
- •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.
- • İç linklerle birlikte değerlendirin: https://dgtlface.com/tr/yazilim/sunucu-guvenlik, https://dgtlface.com/tr/raporlama/kvkk-veri-guvenligi, https://dgtlface.com/tr/yazilim/web-sitesi-gelistirme
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
5) Kontrol listesi
- •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
Deliverables + “Buraya:” notları
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.
Sık Sorulan Sorular
KVKK açısından veri lokasyonu neden önemli?▾
On-prem mi, Türkiye içi bulut mu, global bulut mu seçmeliyim?▾
Backup ve loglar da veri lokasyonu kapsamına girer mi?▾
Otel ve B2B için hosting kararı teknik olarak nasıl verilmeli?▾
Yönetici panellerine erişimde en kritik kontrol nedir?▾
En sık yapılan hata nedir?▾
İlgili İçerikler