GDPR ve KVKK için hosting: teknik kontrol listesi

GDPR (General Data Protection Regulation) ve KVKK (6698 sayılı Kişisel Verilerin Korunması Kanunu) kapsamındaki bir hizmette, hosting altyapısı yalnızca “site çalışsın” seviyesinde ele alınamaz. Yanlış veri konumu, yetersiz şifreleme, kontrolsüz erişim veya log/yedekleme dağınıklığı; hem hukuki risk hem de operasyonel arıza üretir. Bu rehberde hosting tarafında almanız gereken önlemleri, ölçülebilir teknik kontroller ve kontrol listeleri şeklinde göreceksiniz. Böylece “nereden başlamalıyım?” sorusu netleşecek.

1) Veri akışı ve veri konumu: GDPR/KVKK’nin en somut ayağı

İlk adım, hangi verinin nerede tutulduğunu ve hangi ülkelere aktarıldığını belirlemektir. GDPR açısından bu konu “data transfer” ve “data residency” başlıklarında doğrudan önem taşır; KVKK açısından ise kişisel verinin işlenmesi ve aktarım şartlarının yönetimi kritikleşir.

Hangi veriler hosting katmanında kritik?

Kayıt verileri: e-posta, ad/soyad, kullanıcı kimlikleri
İçerik ve dosyalar: üyeler tarafından yüklenen dokümanlar/medya
Uygulama logları: kullanıcı IP adresi, kullanıcı ajanı (user-agent), hata izleri
Yedekler (backup): canlı verinin tarihçesi
Analitik/izleme çıktıları: sunucu tarafı event logları

Sağlayıcıdan isteyeceğiniz net bilgiler

Hosting sağlayıcınızdan yazılı şekilde şu bilgileri istemeniz gerekir: - Sunucu fiziksel konumu (ülke/şehir düzeyi): veri merkezinin yeri - Bulut kullanılıyorsa: hangi bölgelerde (region) veri işlendiği - Destek erişimi: destek ekibinin hangi kanallardan eriştiği - Yedeklerin lokasyonu: canlı verinin yedeği aynı bölgede mi? - Üçüncü taraf servisler: CDN, WAF, e-posta, hata izleme (Sentry vb.) hangi ülkelere veri taşır?

Aşağıdaki karşılaştırma, “tek tek özellik” yerine “hangi kontrolü hangi sağlayıcı modelinde aramalıyım?” fikrini verir:

Konu	Kendi sunucun/kurulumun var (Dedicated veya yönetilen “bare metal”)	Yönetilen VPS/VDS (managed)	Paylaşımlı hosting (shared)
Veri konumu	Genelde en net planlanır	Sağlayıcı bölge seçimine bağlı	Daha az kontrol; altyapı soyutlanır
Yedek lokasyonu	Tasarımla netleşir	Sözleşme ve panel üzerinden doğrulanır	Sıklıkla belirsiz/tek havuz
Log kontrolü	Kendin tutarsın	Sağlayıcı + sen birlikte yönetirsiniz	Loglar sınırlı ve standart olabilir

2) Şifreleme (encryption): veri taşırken ve dururken

GDPR/KVKK yükümlülüklerinin teknik karşılığı, yetkisiz erişimi zorlaştırmaktır. Bu nedenle iki ana şifreleme katmanına odaklanın:

Aktarım sırasında (in transit): TLS ile şifreli bağlantı
Depolama sırasında (at rest): disk/saklama şifrelemesi

Kontrol paneli ve uygulama katmanı için somut kontroller

Web siteniz ve API’leriniz için TLS 1.2+ zorunlu kılın.
Uygulama içinde parolaları hash + salt ile saklayın (bcrypt/argon2 gibi).
Veritabanı bağlantıları için şifreli kanal kullanın.

Sunucu tarafında denetlemeniz gerekenler

Sağlayıcı, “disk encryption” (ör. AES-256) sunduğunu belgeleyebiliyor mu?
Yedek (backup) dosyaları şifreli mi? Şifreleme anahtarları nerede tutuluyor?
Yönetim erişimi için sadece anahtar tabanlı SSH (key-based) kullanın; parola tabanlı SSH’yi devre dışı bırakın.

Not: Yedekleme şifrelemesi “at rest” kapsamına girer. Canlı veriyi şifreli yapıp yedeği şifresiz tutmak, pratikte riski aynı seviyede bırakır.

3) Erişim kontrolü: yetki (authorization) ve kimlik doğrulama (authentication)

Hosting ortamında en sık yaşanan sorun, “sunucu açıktı” değil; yanlış kişiye yanlış yetki verildi durumudur. Bu yüzden erişimi katman katman yönetin.

Uygulama ve panel erişimi

Kontrol paneline (ör. cPanel, Plesk, kendi yönetim paneliniz) erişimde MFA/2FA (iki adımlı doğrulama) kullanın.
Personel değişiminde yetkileri anında iptal edin.
“Paylaşımlı admin” hesabı kullanmayın; kişisel hesap + rol tabanlı yetkilendirme uygulayın.

Sunucu erişimi

SSH için yalnızca izin verilen IP listesi veya VPN üzerinden erişim uygulayın.
Yetki ayrımı yapın:
Operasyon ekibi: servis restart/deploy
Güvenlik ekibi: log inceleme, dosya bütünlüğü kontrolleri
Geliştirme: uygulama kodu deploy (root yetkisi olmadan mümkünse)

İdeal rol ayrımı örneği

deploy kullanıcısı: sadece uygulama klasörüne yazma
ops kullanıcısı: servis yönetimi
sec kullanıcısı: log okuma + WAF/Firewall ayarları

4) Loglama, izleme ve veri minimizasyonu: hem güvenlik hem mevzuat

GDPR’nin temel ilkelerinden biri veri minimizasyonudur. Bu, logların “gerektiği kadar” tutulması anlamına gelir. Fakat KVKK açısından da kişisel veri içeren logların koruma altına alınması gerekir.

Loglarda saklamanız gereken minimumlar

Olay tespiti için gerekenler:
başarısız login sayıları
kritik endpoint erişimleri
sistem hata kodları ve zaman damgaları
Dosya bütünlüğü için gerekenler:
değişen kritik dosyalar

Loglarda kaçınılması gerekenler

Gereksiz biçimde tam kimlik bilgisi veya şifreleme anahtarları
Uzun süre saklanması gerekmeyen ayrıntılı kullanıcı içeriği
Şifreleri ya da “token”ları düz metin şekilde loglama

Net bir log planı (örnek)

Web/app logları: 30-90 gün (ihtiyaca göre)
Güvenlik olay logları (auth, sudo, firewall): 90-180 gün
DDoS/WAF eventleri: 30-180 gün (servis türüne bağlı)
Kapsam dışı ham trafik: saklamayın; sadece özet olayları tutun

Aşağıdaki tablo, log türüne göre “sakla/saklama” kararını pratikleştirir:

Log türü	Kişisel veri riski	Önerilen yaklaşım
Başarısız login	Yüksek	Kısa sürede sakla + alarm üret
Sunucu hata logu	Orta	Maskeleme + makul süre
Uygulama eventleri	Değişken	Veri minimizasyonu (mask/anonim)
Ham istek/response gövdesi	Çok yüksek	Saklamama veya ciddi maskeleme

5) Yedekleme (backup), geri dönüşüm ve imha: “sil” talebine hazırlık

Mevzuat gereği kişisel veriyi silme/anonimleştirme (right to erasure/ilgili talepler) gündeme geldiğinde, yedekler kritik hale gelir. Yedekleriniz varsa “canlı sildim ama yedeklerde duruyor” problemi çıkar.

Hosting tarafında net kontrol listesi

Yedekleme sıklığı: saatlik/günlük
Yedek saklama süresi: kaç gün?
Yedeklerin geri yükleme testi: en az ayda bir doğrulama
Şifreleme: yedek şifreli mi?
Yedekten geri dönüş: “hangi noktaya dönüş” mümkün (point-in-time)?

Silme talebi senaryosu için pratik plan

Uygulama seviyesinde ilgili kaydı sil
Arka planda cache/indeks gibi ikincil kopyaları güncelle
Yedeklerde veri tutma süresi politikana göre: - Saklama süresi yakınsa beklemeden aksiyon - Saklama süresi uzunsa, yedek yerine “log/özet veri” yaklaşımı

Eğer sağlayıcınız yedekleri tek bir havuzda ve şifrelenmemiş tutuyorsa, “silme talebi” operasyonu zorlaşır. Bu nedenle yedek yönetimi için sağlayıcıyla teknik ve sözleşmesel netlik gerekir.

6) Bulut/WAF/DDoS koruması: güvenlik önlemlerinin hukuki etkisi

GDPR/KVKK, “gerekli teknik ve idari tedbirleri” bekler. DDoS koruması, sadece erişilebilirlik değil; aynı zamanda hizmetin sürekliliği ve veri güvenliği açısından dolaylı katkı sağlar.

DDoS/WAF seçiminde bakılacak teknik noktalar

Layer 7 (HTTP) koruması: uygulama katmanını hedefleyebilme
Otomatik saldırı tespiti ve hız limitleri
WAF event loglarının kişisel veri içerip içermediği
Rate limit/ban sürelerinin politika ile uyumu

Sağlayıcıdan isteyebileceğiniz doğrulama

Korumanın hangi trafik türlerini kapsadığı
Yanlış pozitif/yanlış blok ayarlarının nasıl yönetildiği
Olay raporlamasının (raporlama/alert) mevcut olup olmadığı

7) Sağlayıcı sözleşmeleri ve teknik ekler: mevzuatın “yazılı” tarafı

Hosting önlemlerinin önemli bir kısmı teknik kadar sözleşmesel ve dokümantasyon gerektirir.

Hosting sözleşmesinde hedeflemeniz gereken maddeler

İşleyen/denetleyen (controller/processor) rolünün netliği
Veri işleme kapsamı: hangi hizmetler için hangi veriler işlenir
Alt işlemciler (sub-processor) listesi
Veri konumu ve aktarım mekanizması
Güvenlik tedbirleri: şifreleme, erişim kontrolü, loglama
İhlal (data breach) bildirim süreçleri ve süreler
Yedekleme ve imha politikası

8) İdeale yakın hosting mimarisi: VDS/VPS seçimini mevzuata göre yapmak

VDS ve VPS, GDPR/KVKK tarafında doğru mimari kurulduğunda “kontrol” sağlar. Buradaki kritik nokta, sadece sunucuyu kiralamak değil; kontrolü elde etmektir.

Tek tek seçeneklerden “mevzuata uygunluk” çıkarımı

VDS (VDS sunucusu): Genelde daha yönetilebilir; disk/servis bazında kontrol artar
Managed VPS/VDS: İyi yönetimle hız kazanır; ama yedek/log erişimi sınırlanabilir
Dedicated: En yüksek kontrol; veri konumu ve güvenlik mimarisi en net tasarlanır

9) Uygulanabilir kontrol listesi: bugün başlayın, yarın denetleyin

Aşağıdaki listeyi, hosting sağlayıcınızla görüşürken ve kendi altyapınızı yapılandırırken kullanın.

Hosting teknik kontrol listesi

[ ] Sunucu/region veri konumu net tanımlı
[ ] TLS (in transit) zorunlu
[ ] Disk ve yedek şifrelemesi var (at rest)
[ ] SSH erişimi key-based + parola kapalı
[ ] Panel erişiminde MFA/2FA var
[ ] Rol bazlı erişim ve ayrı hesaplar kullanılıyor
[ ] Loglar veri minimizasyonuna uygun tutuluyor
[ ] Loglarda hassas alanlar maskeleme ile yönetiliyor
[ ] Yedekten geri yükleme testi düzenli
[ ] Silme/anonimleştirme talebi yedek saklama süresiyle uyumlu
[ ] WAF/DDoS koruması etkin ve event logları incelenebilir

Sağlayıcıdan istenecek doküman listesi

[ ] Veri işleme dokümanı / güvenlik politikaları
[ ] Alt işlemci listesi
[ ] Veri konumu ve yedek konumu bilgisi
[ ] İhlal bildirimi prosedürü
[ ] Yedek şifreleme ve erişim modeli

Sonuç: Hosting önlemlerini “özellik” değil “kontrol” olarak kurun

GDPR ve KVKK açısından hosting tarafında doğru yaklaşım, tek tek teknoloji adlarını toplamak değil; verinin nerede işlendiğini, kimlerin eriştiğini, verinin nasıl şifrelendiğini, log ve yedeklerin nasıl tutulduğunu uçtan uca kontrol edebilmektir. Bugün yapmanız gereken en hızlı aksiyon: veri konumu + yedek şifrelemesi + log veri minimizasyonu + erişim (MFA/SSH key) başlıklarını sağlayıcınızdan yazılı doğrulamayla netleştirmektir. Ardından yukarıdaki kontrol listesini kendi altyapınıza uygularsanız, denetim süreci dahil olmak üzere riskinizi ölçülebilir biçimde düşürürsünüz.