KVKK uyumu bir belge seti değil, bir mimari sonucudur. Kişisel veri barındıran bir altyapıda ağ topolojisi, kimlik yönetimi, şifreleme, depolama katmanları, yedek rotasyonu, log mimarisi ve ortam ayrımı doğru kurulduğunda uyumun teknik tarafı büyük ölçüde kendiliğinden karşılanır. Yanlış kurulduğunda ise hiçbir politika belgesi bunu telafi etmez.
Bu rehber, altyapıyı kuran ve işleten ekipler için yazıldı. Her bölümde önce mimari kararı, sonra o kararın uyum karşılığını ele alıyoruz.
Başlangıç noktası: veri nerede duruyor?
Uyum çalışmalarının çoğu «müşteri veritabanı» varsayımıyla başlar ve orada biter. Gerçek bir altyapıda kişisel veri çok daha fazla noktaya yayılır, üstelik çoğu kimsenin bilerek koymadığı yerlerdedir.
| Katman | Tipik içerik | Keşif yöntemi |
|---|---|---|
| Uygulama sunucuları | Form girdileri, oturum verisi, geçici dosyalar |
/tmp, upload dizinleri, önbellek
|
| Veritabanları | Müşteri, çalışan, sipariş kayıtları | Şema taraması, kolon adı eşleştirme |
| Read-replica / raporlama | Üretimin tam kopyası | Replikasyon topolojisi çıkarılmalı |
| Dosya depolama | Sözleşmeler, özlük dosyaları, faturalar | Paylaşılan klasörler, eski arşivler |
| Object storage | Yüklenen belgeler, görseller | Bucket envanteri ve erişim politikaları |
| Yedekler | Yukarıdakilerin tamamı | Yedek kataloğu, saklama süresi |
| Log kayıtları | IP, kullanıcı adı, erişim zamanı | Uygulama, web sunucusu, güvenlik duvarı |
| E-posta sunucusu | Yazışmaların tamamı | Arşiv ve silinmiş öğeler dahil |
| VDI / uzak masaüstü | Kullanıcı profilleri, yerel dosyalar | Profil diskleri |
| Test ve geliştirme | Üretimden kopyalanmış gerçek veri | En sık bulgu, aşağıda ayrı bölüm |
| Video gözetim | Görüntü kaydı | Kayıt süresi ve erişim yetkisi |
Bu tabloyu kendi ortamınız için doldurmak, hem veri akış diyagramınızın hem de envanterinizin temelini oluşturur. Pratik bir ipucu: veriyi aramak yerine kopyalanma yollarını izleyin. Bir tablo replike ediliyorsa, bir dizin yedekleniyorsa, bir log merkezi toplayıcıya gönderiliyorsa, veri orada da vardır.
Ağ mimarisi: düz ağ en pahalı hatadır
Kişisel veri barındıran sistemlerin ofis ağıyla aynı L2 alanında olması, hâlâ en yaygın yapısal sorun. Hedeflenmesi gereken katmanlı topoloji:
- DMZ / dış katman: yalnızca ters vekil sunucu, yük dengeleyici ve WAF. Uygulama burada çalışmaz.
- Uygulama katmanı: dışarıdan doğrudan erişilemez, yalnızca DMZ’den belirli portlarla ulaşılır.
- Veri katmanı: veritabanları ve dosya depolama. Yalnızca uygulama katmanından erişilir, internet çıkışı yoktur.
- Yönetim katmanı: SSH ve RDP erişimi yalnızca VPN veya bastion (jump host) üzerinden. Yönetim portları asla internete açık değildir.
Dışa açık her servis önünde uygulama katmanı koruması ve hacim saldırılarına karşı koruma ayrı ayrı değerlendirilmelidir. WAF ile uygulama koruma enjeksiyon ve veri sızdırma denemelerini L7’de keser; DDoS koruması ise erişilebilirliği korur. Erişilebilirlik burada konfor meselesi değildir: veriye erişimin engellenmesi de bir veri güvenliği sorunu sayılır.
Segmentasyon, uyum tarafında «yetkisiz erişimin önlenmesi» başlığının en somut karşılığıdır. Bir denetimde «veritabanına kimler erişebiliyor» sorusuna ağ diyagramıyla cevap verebilmek, politika belgesiyle cevap vermekten çok daha güçlüdür.
Kimlik ve erişim: hesap sayısı kadar risk
Erişim mimarisinde hedef basit: her erişim kişiye bağlı, gerekçeli ve izlenebilir olmalı.
Paylaşılan hesapları kaldırın. admin hesabını üç kişinin kullanması, log kayıtlarını değersizleştirir. Bir olayda «kim yaptı» sorusunun cevabı yoksa, tuttuğunuz logun uyum değeri de yoktur.
Rol bazlı yetkilendirme (RBAC) kurun. En az yetki ilkesi teoride herkesin bildiği, pratikte nadiren uygulanan kural. Geliştiricinin üretim veritabanına doğrudan okuma yetkisi olması gerekiyor mu, yoksa maskelenmiş bir kopya yeterli mi?
Yönetici hesaplarında çok faktörlü kimlik doğrulama zorunlu olsun. İstisnasız.
Yaşam döngüsünü otomatikleştirin. İşten ayrılan personelin yetkilerinin kapatılması İK süreçlerine bağlanmalı. Denetimlerde en sık rastlanan bulgulardan biri, aylar önce ayrılmış çalışanların hâlâ aktif VPN hesabıdır.
Erişim matrisini periyodik gözden geçirin. Çeyrek başına bir kez, kim neye erişiyor listesinin çıkarılıp onaylanması.
Şifreleme: asıl soru anahtarın kimde olduğu
«Verilerimiz şifreli» cümlesi tek başına bir şey ifade etmez. Üç ayrı soru vardır.
Aktarım halinde: TLS 1.2 ve üzeri, tercihen TLS 1.3. Sadece dışa açık servisler için değil, iç servisler arası trafikte de. Veritabanı bağlantıları sıklıkla şifresiz kalır.
Durağan halde: disk veya hacim seviyesinde şifreleme (AES-256), object storage için sunucu tarafı şifreleme, veritabanında hassas kolonlar için kolon bazlı şifreleme.
Anahtar yönetimi: anahtarlar nerede duruyor, kim erişebiliyor, rotasyon periyodu ne? Anahtar şifrelediği veriyle aynı sistemde duruyorsa, şifrelemenin koruma değeri büyük ölçüde kaybolur.
Anahtar sahipliği aynı zamanda mimari bir kaldıraçtır: anahtar sizde ise, sağlayıcının altyapısında duran veri sizin izniniz olmadan okunamaz. Bu, sağlayıcı seçiminde sorulması gereken ilk teknik sorulardan biridir.
Depolama mimarisi: saklama süresi bir politika değil, bir yapılandırmadır
Saklama süreleri genellikle bir Word belgesine yazılıp orada kalır. Oysa depolama katmanında bu bir yapılandırma parametresidir.
Object storage kullanıyorsanız lifecycle policy ile nesnelerin belirli süre sonra otomatik silinmesi veya arşiv katmanına taşınması tanımlanabilir. Veritabanı tarafında partition rotasyonu ve zamanlanmış temizlik işleri aynı işi görür. Dosya sunucusunda ise genellikle hiçbir mekanizma yoktur ve veri sonsuza kadar birikir.
Katmanlı depolama tasarımı bu noktada hem maliyeti hem uyumu birlikte çözer: sık erişilen veri hızlı katmanda, nadiren erişilen veri S3 nesne depolamada, süresi dolan veri ise otomatik olarak silinir.
Uyum karşılığı: «kişisel veriler işlendikleri amaç için gerekli olan süre kadar muhafaza edilir» ilkesi, teknik olarak lifecycle kuralı demektir. Belgede yazan 5 yıl, sistemde bir parametreye karşılık gelmiyorsa uygulanmıyor demektir.
Yedekleme ve felaket kurtarma: en çok gözden kaçan kopya
Yedek, kişisel verinin ayrı bir kopyasıdır. Bu tek cümle, yedek mimarisinin neden uyumun merkezinde olduğunu açıklar.
RPO ve RTO’yu önce belirleyin. Ne kadar veri kaybını göze alabilirsiniz, ne kadar sürede ayağa kalkmanız gerekiyor? Bu iki sayı, yedekleme sıklığını ve replikasyon mimarisini belirler.
3-2-1 kuralını koruyun. Üç kopya, iki farklı ortam, bir kopya farklı lokasyonda. Fidye yazılımı senaryoları için bir adım daha: değiştirilemez (immutable) yedek.
Yedek lokasyonunu bilinçli seçin. «Coğrafi olarak dağıtılmış yedekleme» ifadesi tek başına yeterli bilgi değildir. Hedef veri merkezinin hangi ülkede olduğu sorulmalıdır, çünkü üretim ortamınız Türkiye’de olsa bile yedeğiniz yurt dışına çıkıyorsa bu bağımsız bir yurt dışı aktarımıdır.
İmha ile yedek rotasyonunu birlikte tasarlayın. Saklama süresi dolan veya silme talebi gelen bir kayıt üretim veritabanından silindiğinde yedeklerde yaşamaya devam ediyorsa, iş yarım kalmıştır. İki pratik yaklaşım var: yedek rotasyon süresini saklama politikasına yaklaştırmak ya da kolon/nesne bazlı şifreleme kullanıp anahtarı imha etmek (crypto-shredding).
Felaket kurtarma ortamı üretimin aynısıdır. Aynı segmentasyon, aynı erişim kontrolü, aynı şifreleme, aynı lokasyon kuralları. DR ortamını «geçici» sayıp güvenlik seviyesini düşürmek yaygın bir hata.
Bu katman için bulut yedekleme, veri çoğaltma (vCAV) ve olağanüstü durum kurtarma (DRaaS) çözümleri kullanılabilir; kritik olan, hangi çözüm seçilirse seçilsin yukarıdaki dört sorunun yazılı cevabının olmasıdır.
Log mimarisi: tuttuğunuz log kanıt değeri taşıyor mu?
Log tutmak yeterli değil. Bir olay sonrasında logun kanıt değeri taşıması için üç özelliği olmalı.
Merkezîlik. Loglar üretildiği sunucuda kalırsa, o sunucu ele geçirildiğinde ilk silinen şey olur. Merkezi bir toplayıcıya, tercihen yazma sonrası değiştirilemeyecek şekilde gönderilmeli.
Bütünlük. Hash zinciri, WORM depolama veya zaman damgası mekanizmalarından biri. «Bu log değiştirilmemiştir» iddiasının teknik dayanağı olmalı.
Zaman senkronizasyonu. NTP olmadan korelasyon yapılamaz. Farklı sunucularda saat farkı varsa olay zinciri kurulamaz.
Dikkat edilecek bir nokta: logların kendisi de kişisel veri içerir. IP adresi, kullanıcı adı, erişim zamanı bir araya geldiğinde kişisel veridir. Bu nedenle log deposu da erişim kontrolü, şifreleme ve saklama süresi kurallarına tabidir.
Bu başlıkta 5651 sayılı Kanun kapsamındaki loglama yükümlülükleriyle kavramsal bir örtüşme vardır, ancak iki rejimin amacı ve kapsamı farklıdır. İkisini tek bir log politikasıyla karşılamaya çalışmak yaygın ama riskli bir kısayoldur.
Ortam ayrımı ve veri maskeleme
Denetimlerde en sık çıkan bulgu şu: test ortamında üretimden kopyalanmış, maskelenmemiş gerçek müşteri verisi.
Mantık anlaşılır. Gerçek veriyle test etmek daha kolaydır. Ancak test ortamı genellikle daha zayıf korunur, daha çok kişinin erişimi vardır ve yedekleme politikası yoktur. Yani en hassas veri, en korumasız ortamda durur.
Çözüm katmanlı:
- Üretim, test ve geliştirme ortamlarını ağ seviyesinde ayırın
- Üretimden veri kopyalanacaksa maskeleme veya tokenizasyon boru hattından geçirin
- Mümkün olduğunda sentetik veri üretin
- Kopyalama işlemini otomatikleştirip elle yapılan
mysqldumpalışkanlığını kaldırın
Lokasyon ve topoloji kararı
Altyapı lokasyonu, gecikme süresi ve maliyetin yanı sıra idari yükü de belirleyen bir karardır.
Verileriniz ve yedekleriniz Türkiye sınırları içinde kalıyorsa, yurt dışına veri aktarımı rejimi hiç devreye girmez. Yurt dışındaki bir veri merkezinde tutuluyorsa, 2024’te değişen rejim uyarınca uygun bir aktarım mekanizması kurmanız ve Kuruma bildirim yapmanız gerekir. Bu bir yasak değil, bir iş yüküdür: sözleşme, bildirim, envanter güncellemesi ve sürekli takip.
Mimari açıdan bunun anlamı şu: region seçimi tek seferlik bir karar değildir. Yedek hedefi, DR bölgesi, CDN pop noktaları ve yönetilen servislerin çalıştığı bölge ayrı ayrı kontrol edilmelidir. Uygulamanız İstanbul’da çalışırken yönetilen veritabanı yedeklerinin başka bir kıtaya gitmesi, fark edilmeden gerçekleşen tipik bir durumdur.
Paylaşılan sorumluluk: altyapının hangi katmanı kimde?
Altyapının bir kısmını dışarıya verdiğinizde teknik sorumluluk katman katman bölünür. Hukuki sorumluluk ise bölünmez: veri sorumlusu siz kalırsınız, sağlayıcı çoğu senaryoda veri işleyendir.
| Katman | On-premise | Colocation | IaaS | SaaS |
|---|---|---|---|---|
| Fiziksel güvenlik | Siz | Sağlayıcı | Sağlayıcı | Sağlayıcı |
| Donanım ve ağ omurgası | Siz | Siz | Sağlayıcı | Sağlayıcı |
| Sanallaştırma | Siz | Siz | Sağlayıcı | Sağlayıcı |
| İşletim sistemi ve yama | Siz | Siz | Siz | Sağlayıcı |
| Uygulama yapılandırması | Siz | Siz | Siz | Kısmen |
| Erişim yetkileri | Siz | Siz | Siz | Siz |
| Veri ve sınıflandırma | Siz | Siz | Siz | Siz |
Son iki satır her modelde sizde kalır. «Buluta geçtik, güvenlik artık onlarda» varsayımı tam olarak burada kırılır.
Bu nedenle sağlayıcıyla yapılacak sözleşmede teknik ekibin bakması gereken maddeler var: verinin ve yedeklerin fiziksel lokasyonu, alt işleyen listesi, şifreleme anahtarlarının yönetimi, veri ihlalinde bildirim süresi ve hizmet sonunda imha prosedürü. Bu maddeler hukuk metni gibi görünse de cevapları tamamen mimaridir.
Referans kontrol listesi
Ağ
- Katmanlı segmentasyon kurulu, veri katmanının internet çıkışı yok
- Yönetim erişimi yalnızca VPN veya bastion üzerinden
- Dışa açık servisler önünde WAF ve DDoS koruması
Kimlik
- Paylaşılan hesap yok
- Yönetici hesaplarında MFA
- Erişim matrisi çeyreklik gözden geçiriliyor
- Ayrılan personel süreci otomatik
Şifreleme
- TLS 1.2+ her yerde, iç trafik dahil
- Durağan veri şifreli
- Anahtarlar ayrı yönetiliyor, rotasyon tanımlı
Depolama ve imha
- Saklama süreleri lifecycle kuralına dönüştürülmüş
- Süresi dolan veri otomatik siliniyor
- İmha işlemi loglanıyor
Yedek ve felaket kurtarma
- RPO ve RTO tanımlı
- Yedek lokasyonunun ülkesi biliniyor
- Immutable yedek var
- Geri yükleme testi son 6 ayda yapıldı
- DR ortamı üretimle aynı güvenlik seviyesinde
Log
- Merkezi toplama
- Bütünlük koruması
- NTP senkronizasyonu
- Log deposu da erişim kontrollü
Ortamlar
- Üretim, test ve geliştirme ağ seviyesinde ayrı
- Test ortamında maskelenmemiş gerçek veri yok
