KVKK uyumlu yazılım, çoğu işletmenin sözleşmelerde görüp geçtiği bir ibare gibi dursa da aslında çok somut bir mühendislik meselesidir. Kişisel Verilerin Korunması Kanunu, müşterilerinizin adını, telefonunu, adresini ve çok daha hassas bilgilerini işleyen her işletmeye yükümlülükler getirir; bu yükümlülüklerin önemli bir kısmı ise kağıt üzerindeki politikalarla değil, kullandığınız yazılımın nasıl inşa edildiğiyle karşılanır. Aydınlatma metniniz kusursuz olabilir; ama veriler korumasız bir veritabanında duruyorsa uyum yalnızca görüntüdedir.
Bu yazıda veri güvenliğini iki gözle birden ele alacağız: yazılım geliştiren ekip gözüyle 'KVKK uyumlu yazılım nasıl inşa edilir' ve yazılım kullanan işletme gözüyle 'kullandığım sisteme hangi soruları sormalıyım'. Örnekler, sağlık verisi gibi özel nitelikli veriler işleyen sistemler geliştirirken edindiğimiz saha tecrübesinden geliyor; teori değil, uygulama anlatacağız.
KVKK yazılımdan ne bekler?
Kanunun teknik tarafa bakan özü birkaç ilkede toplanır: kişisel veri, amaçla sınırlı ve gerektiği kadar işlenmeli; doğru ve güncel tutulmalı; gerektiği süre kadar saklanıp süresi dolunca silinmeli veya anonim hale getirilmeli; ve yetkisiz erişime karşı uygun teknik ve idari tedbirlerle korunmalıdır. 'Uygun teknik tedbir' ifadesi kanunda kasıtlı olarak esnektir; içini dolduran şey, sektörün kabul görmüş güvenlik pratikleridir: şifreleme, erişim kontrolü, kayıt tutma, yedekleme.
Veri kategorileri arasında da hiyerarşi vardır. Ad ve telefon gibi genel kişisel verilerin yanında; sağlık bilgisi, biyometrik veri, dernek üyeliği gibi özel nitelikli kişisel veriler çok daha sıkı korunmak zorundadır. Bir klinik yazılımı ile bir e-ticaret yazılımının güvenlik çıtası bu yüzden aynı değildir. Yazılımın hangi veri kategorilerini işlediği, daha tasarım aşamasında masaya yatırılmalı ve koruma düzeyi buna göre belirlenmelidir.
Burada kritik kavram 'privacy by design', yani tasarımdan itibaren gizliliktir: veri koruması, bitmiş yazılıma sonradan yapıştırılan bir yama değil, ilk mimari çizimden itibaren sistemin dokusuna işlenen bir ilke olmalıdır. Sonradan eklenen güvenlik hem pahalıdır hem de daima eksik kalır; baştan kurgulanan güvenlik ise günlük işleyişin görünmez bir parçası olur.
Şifreleme: veriye giden her yolda
Şifrelemenin iki cephesi vardır. Birincisi iletim halindeki veri: kullanıcının tarayıcısı ile sunucu arasındaki tüm trafik HTTPS ile şifrelenmelidir; bu artık tartışma konusu bile değildir. İkincisi ve daha çok ihmal edileni, duran veridir: veritabanının kendisi ele geçirilse ya da bir yedek dosyası yanlış ellere düşse ne olur? İşte bu senaryoya karşı, hassas alanların veritabanı içinde de şifreli saklanması gerekir.
Pratikte bunun anlamı şudur: telefon numarası, kimlik bilgisi, iki faktörlü doğrulama anahtarı gibi alanlar veritabanına açık metin olarak değil, AES-256 gibi güçlü algoritmalarla şifrelenerek yazılır. Kendi sistemlerimizde bu yaklaşımı standart olarak uyguluyoruz; ekranlarda ise veri maskeleme devreye girer: numaranın tamamını görmesi gerekmeyen kullanıcı, yalnızca son hanelerini görür. Veriyi hem kasada kilitli tutmak hem de vitrine yarım çıkarmak diye özetlenebilir.
Parolalar ise apayrı bir kategoridir: parola asla şifrelenmez, geri döndürülemez biçimde hash'lenir. BCrypt gibi bu iş için tasarlanmış, kasıtlı olarak yavaş çalışan algoritmalar kullanılır; böylece veritabanı ele geçirilse bile parolaların kendisi elde edilemez. Kullanıcısına 'şifrenizi unuttuysanız size eski şifrenizi gönderelim' diyen bir sistem görürseniz bilin ki parolaları açık saklıyordur; bu, günümüzde kabul edilemez bir pratiktir.
Erişim kontrolü: herkes her şeyi görmemeli
Veri güvenliğinin en çok ihmal edilen boyutu iç erişimdir. Dış saldırganlara karşı duvar örülürken, içeride herkesin her veriyi görebildiği sistemler kurulur. Oysa KVKK'nın amaçla sınırlılık ilkesi içeride de geçerlidir: bir çalışan, işini yapmak için gerekmeyen veriye erişememelidir. Bunun yazılımdaki karşılığı rol bazlı yetkilendirmedir: sekreter, uzman ve yönetici aynı sistemde farklı ekranlar, farklı yetkiler ve farklı veri alanları görür.
Erişimin bir de kayıt boyutu vardır: kim, ne zaman, hangi veriye baktı, neyi değiştirdi? Bu izleme kayıtları hem caydırıcıdır hem de bir olay yaşandığında geriye dönük inceleme imkanı verir. Giriş denemelerinin kaydedilmesi, art arda başarısız denemelerde hesabın veya IP adresinin geçici olarak engellenmesi, oturum sürelerinin makul tutulması ve kritik hesaplarda iki faktörlü doğrulama; hepsi aynı bütünün parçalarıdır.
Çok kiracılı SaaS sistemlerinde erişim kontrolünün bir katmanı daha vardır: kiracılar arası izolasyon. Bir işletmenin kullanıcısı, sistemdeki başka bir işletmenin verisine hiçbir koşulda ulaşamamalıdır ve bu güvence, geliştiricinin dikkatine değil mimarinin kendisine gömülü otomatik filtrelerle sağlanmalıdır. Sağlayıcınıza bu izolasyonu nasıl kurduğunu sormaktan çekinmeyin; net cevap, olgunluğun işaretidir.
Verinin yaşam döngüsü: saklama, silme, anonimleştirme
KVKK yalnızca verinin korunmasını değil, ömrünü de düzenler: amaç ortadan kalktığında veri silinmeli, yok edilmeli veya anonim hale getirilmelidir. Yazılım tarafında bu, düşünüldüğünden zor bir problemdir; çünkü veriler birbirine bağlıdır. Bir müşteriyi veritabanından kökten silmek, ona bağlı faturaları, ödemeleri ve yasal olarak saklanması zorunlu ticari kayıtları da bozabilir. Ticaret ve vergi mevzuatı bazı kayıtların yıllarca saklanmasını isterken, KVKK kişisel verinin silinmesini ister; iki yükümlülük dengelenmelidir.
Bu dengeyi kuran mühendislik cevabı anonimleştirmedir: kişiyi tanımlayan alanlar (ad, telefon, adres) geri döndürülemez biçimde silinir ya da anlamsız değerlerle değiştirilir; finansal ve istatistiksel kayıtlar ise kişiyle bağı kopmuş halde korunur. Kendi sistemlerimizde kalıcı silme talebini tam böyle çözüyoruz: kişisel iz yok olur, işletmenin mali bütünlüğü bozulmaz. Silme akışının bu incelikle tasarlanmamış olduğu yazılımlarda, ya kişisel veri sonsuza dek kalır ya da silme işlemi muhasebeyi çökertir.
Yedekler de yaşam döngüsünün parçasıdır: veri düzenli yedeklenmeli, yedekler de en az canlı veri kadar korunmalı ve saklama süreleri tanımlı olmalıdır. Felaket senaryosu tatbikatı yapılmamış bir yedek, yedek değil temennidir. Verinin nerede, hangi ülkede barındırıldığı sorusu da önemlidir; yurt dışına veri aktarımı KVKK'da ayrı kurallara tabidir ve kullandığınız hizmetlerin sunucu konumu bu açıdan sorgulanmalıdır.
Geliştirme sürecinde güvenlik disiplini
KVKK uyumlu yazılım, yalnızca doğru özelliklerin toplamı değil, doğru geliştirme alışkanlıklarının ürünüdür. Birkaç örnek verelim: veritabanı bağlantı bilgileri ve şifreleme anahtarları asla kaynak koda veya herkesin eriştiği ayar dosyalarına yazılmaz; ortam değişkenleri ya da güvenli anahtar kasalarında tutulur. Test ortamlarında gerçek müşteri verisi kullanılmaz. Kullanıcıdan gelen her girdi doğrulanır; SQL enjeksiyonu ve benzeri klasik saldırılara kapı aralanmaz.
Süreç tarafında da disiplin gerekir: kod gözden geçirme alışkanlığı, bağımlılıkların bilinen açıklara karşı düzenli taranması, canlı sisteme erişimin az sayıda kişiyle sınırlanması ve yapılan her müdahalenin kayıtlı olması. Kendi projelerimizde canlı veritabanına doğrudan müdahaleyi engelleyen koruma katmanları kullanıyoruz; bir betiğin yanlışlıkla üretim ortamında çalışmasını daha en baştan imkansızlaştırmak, en ucuz sigortadır.
Yazılım kullanan işletmeye pratik bir kontrol listesiyle bitirelim. Sağlayıcınıza sorun: Verilerim hangi ülkede, hangi altyapıda barınıyor? Hassas alanlar veritabanında şifreli mi? Parolalar nasıl saklanıyor? Rol bazlı yetkilendirme ve erişim kayıtları var mı? Silme talebimde kişisel veriler gerçekten siliniyor mu? Yedekleme ve felaket kurtarma planı nedir? Bu soruların hepsine net cevap alabiliyorsanız doğru ellerdesiniz; alamıyorsanız, KVKK uyumu o sözleşmedeki ibareden ibaret olabilir. Veri güvenliği bir pazarlama cümlesi değil, her gün yeniden hak edilen bir güvendir.
Sık sorulan sorular
+KVKK uyumlu yazılım ne demektir?
Kişisel verileri; şifreleme, rol bazlı erişim kontrolü, kayıt tutma, güvenli saklama ve silme/anonimleştirme süreçleriyle kanunun öngördüğü teknik tedbirlere uygun biçimde işleyen yazılımdır. Uyum yalnızca hukuki metinlerle değil, yazılımın mimarisiyle sağlanır.
+Kişisel veriler veritabanında nasıl saklanmalı?
Telefon ve kimlik bilgisi gibi hassas alanlar AES-256 gibi güçlü algoritmalarla şifrelenerek, parolalar ise BCrypt gibi geri döndürülemez hash yöntemleriyle saklanmalıdır. Ekranlarda tam görüntüleme gerekmeyen veriler maskelenmeli, tüm bağlantılar HTTPS ile korunmalıdır.
+Özel nitelikli kişisel veri nedir, neden daha sıkı korunur?
Sağlık bilgisi, biyometrik veri gibi öğrenilmesi halinde kişinin mağduriyetine veya ayrımcılığa yol açabilecek verilerdir. KVKK bu kategoriye daha sıkı işleme şartları ve daha güçlü koruma tedbirleri öngörür; bu nedenle örneğin klinik yazılımlarının güvenlik çıtası standart yazılımlardan yüksektir.
+Müşteri verisini silmek yasal kayıtları bozar mı?
Doğru tasarlanmış sistemlerde bozmaz. Çözüm anonimleştirmedir: kişiyi tanımlayan alanlar geri döndürülemez biçimde kaldırılır, yasal olarak saklanması zorunlu finansal kayıtlar ise kişiyle bağı koparılmış halde korunur. Böylece hem KVKK hem ticari mevzuat yükümlülükleri birlikte karşılanır.
+Kullandığım yazılımın KVKK uyumunu nasıl kontrol ederim?
Sağlayıcıya somut sorular sorun: veriler nerede barınıyor, hassas alanlar şifreli mi, parolalar nasıl saklanıyor, erişim kayıtları tutuluyor mu, silme talebinde veri gerçekten siliniyor mu, yedekleme planı nedir? Bu sorulara şeffaf ve net cevap veremeyen sağlayıcı, risk işaretidir.