KVKK uyumlu ürün geliştirme rehberi

PsyBank bir online terapi platformu; danışan ile ruh sağlığı uzmanını bir araya getiriyor. İşlediğimiz verinin niteliği burada belirleyici: bir kişinin hangi terapistle görüştüğü, hangi tarihte seans aldığı, ödeme geçmişi ve terapistin tuttuğu notlar. Bunların hepsi KVKK'nın en hassas kategorisine, "özel nitelikli kişisel veri" başlığına girer. Bir e-ticaret sepetinin sızması can sıkıcıdır; bir kişinin terapi aldığı bilgisinin sızması geri alınamaz bir zarardır. Bu yüzden gizliliği projeye sonradan eklenen bir modül olarak değil, ilk mimari karar olarak ele aldık.

Bu rehber sağlık verisi işleyen bir ürünü 6698 sayılı Kişisel Verilerin Korunması Kanunu'na uyumlu geliştirmek için pratik adımları anlatıyor. Bir hukuk metni değil; geliştiricinin masasına oturduğunda vereceği somut kararlar üzerine. Veri minimizasyonundan şifrelemeye, saklama sürelerinden veri sahibi haklarına kadar, teoriyi koda çevirirken öğrendiklerimizi paylaşacağız. Odak noktamız tek bir ilke: uyum, en sona bırakılan bir denetim maddesi değil, mimarinin kendisidir.

Önce kelime dağarcığı: KVKK geliştiriciye ne der?

Uyumun ilk adımı, hukukun terimleriyle mimarinin terimlerini eşleştirmek. Kanun sizden ürettiğiniz her tabloyu değil, birkaç temel kavramı anlamanızı ister. Veri sorumlusu, verinin işlenme amacını ve yöntemini belirleyen taraftır — yani sizin şirketiniz. Veri işleyen ise onun adına veri işleyen üçüncü taraflardır; bulut sağlayıcınız, e-posta servisiniz, ödeme kuruluşunuz. Bu ayrım önemli çünkü aldığınız her dış hizmet bir veri işleyen sözleşmesi ve sorumluluk anlamına gelir.

İkinci kritik kavram özel nitelikli kişisel veri. Kanun'un 6. maddesi sağlık ve cinsel hayata ilişkin verileri ayrı bir korumaya alır; bunlar ancak ilgili kişinin açık rızasıyla veya sır saklama yükümlülüğü altındaki kişilerce işlenebilir. Bir terapi platformunda işlediğimiz verinin doğrudan bu kapsama girmesi, teknik önlem çıtasını yükseltir. Sıradan bir kişisel veri için makul sayılan bir tedbir, sağlık verisi için yeterli olmayabilir.

Son olarak açık rıza ve işleme amacı. Açık rıza belirli bir konuya ilişkin, bilgilendirmeye dayanan ve özgür iradeyle açıklanan onaydır — kutucuğu önceden işaretlenmiş bir onay değildir. Her işleme faaliyetinin bir dayanağı ve bir amacı olmalıdır; amaç dışında veri işleyemezsiniz. Bu ilkeyi kodda yaşatmanın en basit yolu, her veri alanının neden toplandığını ve hangi rızaya dayandığını belgelemektir.

Veri minimizasyonu: en iyi koruma, hiç tutmadığınız veridir

Sızdıramayacağınız tek veri, elinizde olmayan veridir. Bu yüzden uyumun en güçlü aracı şifreleme değil, minimizasyondur. Her yeni alan için ekibe tek bir soru sorduruyoruz: "Buna gerçekten ihtiyacımız var mı, yoksa iyi olur diye mi topluyoruz?" Cevap ikinciyse alan hiç açılmıyor. Bu disiplin, sonradan korumak zorunda kalacağımız yüzeyi baştan küçültüyor.

Aynı ilkeyi mimaride de uyguladık. Görüşme altyapımızda seansın ses ve görüntüsü uçtan uca akar; içerik hiçbir zaman sunucuya uğramaz. Sunucu yalnızca "kim, kiminle, hangi odada" bilgisini bilir. Böylece en hassas veri, yani konuşmanın kendisi, hiçbir zaman bizim sistemimizde bir kayıt olarak var olmaz. Toplamadığınız veriyi korumakla, silmekle veya bir ihlalde açıklamakla uğraşmazsınız.

Bir ürün ekibinde en pahalı satır, yazdığınız kod değil, ihtiyaç duymadığınız hâlde topladığınız veridir. Onu bir gün korumak, taşımak, silmek ve bir ihlalde hesabını vermek zorunda kalırsınız.

Minimizasyonu somutlaştıran pratik adımlarımız şunlar oldu:

• Ayrıştırma: Kimlik bilgileri ile seans verilerini ayrı tablolarda, mümkün olduğunca ayrı şemalarda tuttuk. Analitik için gereken yerlerde gerçek kimlik yerine takma bir kimlik (pseudonym) kullanıyoruz; iki tarafı birleştiren eşleşme tablosu ise en kısıtlı erişime sahip.
• Alan bazlı maskeleme: Destek ekibi bir kaydı açtığında telefon ve e-postanın yalnızca maskelenmiş hâlini görür. Tam veri, ancak belgelenmiş bir gerekçeyle ve iz bırakarak açılır.
• Serbest metinden kaçınma: Serbest metin alanları en zor denetlenen veridir. Yapılandırılabilecek her bilgiyi seçime bağladık; böylece hangi alanda ne tür veri olduğunu her zaman biliyoruz.
• Loglarda veri yok: Uygulama logları hata ayıklama içindir, kişisel veri deposu değil. Log yazan her yolu, kişisel veriyi dışarıda bırakacak şekilde gözden geçirdik.

Teknik tedbirler: şifreleme, erişim ve denetim izi

Özel nitelikli veri işleyen bir veri sorumlusunun alması gereken önlemler KVK Kurulu tarafından ayrıca belirlenmiştir: verinin şifrelenmesi, mümkünse ayrı sistemlerde tutulması, erişimlerin kayıt altına alınması ve güçlü kimlik doğrulama. Biz bunları üç katmanda uyguladık: aktarım, saklama ve erişim.

Aktarımda her bağlantı TLS ile şifreli; iç servisler arasında bile düz metin trafik yok. Saklamada veritabanı diskleri anahtar yönetim servisiyle şifreli, yedekler de aynı şekilde. En hassas alanlarda buna ek olarak uygulama katmanında şifreleme uyguluyoruz; böylece veritabanına doğrudan erişen biri bile alanın içeriğini anahtar olmadan okuyamıyor. Şifreleme anahtarlarını verinin durduğu yerden ayrı, kısıtlı bir serviste tutmak bu tedbirin can damarı.

Erişim tarafında ilke basit: en az yetki. Her rol yalnızca işini yapmak için gereken veriye erişir, yönetici hesapları iki faktörlü kimlik doğrulama olmadan çalışmaz. Ama asıl kritik olan, kimin neye eriştiğinin iz bırakması. Hassas veriye her erişimi değiştirilemez bir denetim kaydına yazıyoruz — kim, ne zaman, hangi kaydı, hangi gerekçeyle açtı:

type DenetimKaydi struct {
    Aktor     string    // erişen kullanıcı kimliği
    Eylem     string    // oku, guncelle, sil
    KayitID   string    // erişilen kaydın takma kimliği
    Gerekce   string    // zorunlu: neden erişildi
    Zaman     time.Time
}

func (s *Servis) HassasKaydiOku(ctx context.Context, id string) (*Kayit, error) {
    kayit, err := s.repo.Getir(ctx, id)
    if err != nil {
        return nil, err
    }
    // Erişim, veriden önce değil, veriyle birlikte kayıt altına alınır
    s.denetim.Yaz(ctx, DenetimKaydi{
        Aktor:   auth.Kullanici(ctx),
        Eylem:   "oku",
        KayitID: id,
        Gerekce: auth.Gerekce(ctx),
        Zaman:   time.Now(),
    })
    return kayit, nil
}

Denetim kaydının değeri, bir gün geriye dönüp "bu veriye kim, neden erişti?" sorusuna cevap verebilmenizde. Bu kayıt olmadan uyum bir iddiadan ibarettir; kayıtla birlikte kanıtlanabilir hâle gelir. Denetim kayıtlarını uygulamanın yazamayacağı, yalnızca ekleyebileceği bir depoda tutmak da bu güvencenin bir parçası.

Sık atlanan bir nokta da geliştirme ve test ortamları. Üretim verisini test ortamına kopyalamak, en sıkı üretim önlemlerini bir anda anlamsız kılar; çünkü test ortamları çoğu zaman daha gevşek korunur. Bu yüzden geliştirme ve test ortamlarında gerçek kişisel veri kullanmıyoruz. Bunun yerine üretim verisinin yapısını taklit eden ama içinde hiçbir gerçek kişiye ait bilgi bulunmayan sentetik veri üretiyoruz. Böylece ekip gerçekçi koşullarda çalışırken, tek bir gerçek danışanın verisi bile risk altına girmiyor.

Saklama, silme ve veri sahibinin hakları

Veriyi toplamak kadar, ne zaman yok edeceğinizi bilmek de uyumun parçası. Kanun, veriyi işleme amacının ortadan kalkmasının ardından silinmesini, yok edilmesini veya anonim hâle getirilmesini ister. Bunu ürüne gömmek için her veri türü için bir saklama süresi tanımladık ve bu süreyi otomatik işleyen bir imha görevine bağladık. Süre dolduğunda kayıt sessizce silinir; kimsenin elle temizlik yapmasını beklemeyiz, çünkü elle yapılan iş unutulur.

Silmenin iki yüzü var: gerçekten silmek ve anonimleştirmek. İstatistik için gereken verilerde kaydı silmek yerine kişiyle bağını koparıyoruz; geriye dönülemez şekilde takma kimliği bile kaldırıp yalnızca toplu sayıları bırakıyoruz. Anonimleştirmenin gerçek olması şart — tersine çevrilebilen bir maskeleme anonimleştirme değildir ve sizi korumaz.

Bir de veri sahibinin hakları var. Kanun'un 11. maddesi kişiye verisi hakkında bilgi alma, düzeltme, silinmesini isteme ve işlemeye itiraz etme hakkı tanır. Bu haklar bir e-posta kuyruğunda beklememeli; ürünün içinde self-servis olmalı. Kullanıcı hesap ayarlarından verisini indirebiliyor, düzeltebiliyor ve hesabını kapatma talebini başlatabiliyor. Bu talepleri de yine denetim kaydına yazıyoruz, çünkü bir hakkın kullanıldığını kanıtlayabilmek de sorumluluğun parçası.

Üçüncü taraflar ve verinin sınırları

Hiçbir ürün tek başına çalışmaz. Bulut sağlayıcısı, e-posta gönderim servisi, ödeme kuruluşu, hata izleme aracı — her biri sizin adınıza veri işleyen bir taraf. KVKK bu ilişkileri bir veri işleyen sözleşmesiyle güvence altına almanızı ister; sözleşme, üçüncü tarafın veriyi yalnızca sizin talimatınızla, belirlenen amaç için işleyeceğini ve aynı güvenlik önlemlerini alacağını taahhüt eder. Biz her yeni servisi eklemeden önce şu soruyu soruyoruz: bu servise gerçekten kişisel veri göndermek zorunda mıyız, yoksa veriyi ona hiç ulaştırmadan işleyebilir miyiz?

Özellikle hata izleme ve analitik araçları sinsi bir risk taşır; farkında olmadan kişisel veriyi dış bir servise sızdırabilirler. Bir istisna yakalandığında hata raporuna eklenen istek gövdesi, içinde bir e-posta veya kimlik bilgisi taşıyabilir. Bu yüzden dışarı giden her veriyi, kişisel bilgiyi ayıklayan bir süzgeçten geçiriyoruz. Amaç, üçüncü tarafın yalnızca işini yapmak için gereken en az veriyi görmesi.

Bir diğer kritik konu verinin coğrafyası. Bulut altyapısında verinin hangi bölgede saklandığı, yurt dışına aktarım kurallarını doğrudan etkiler. Sağlık verisi gibi hassas bir veriyi işlerken, verinin fiziksel olarak nerede durduğunu bilmek ve aktarım kurallarına uymak bir tercih değil zorunluluktur. Bu yüzden altyapı bölgesini rastgele değil, veri yerleşimi kurallarını gözeterek seçtik ve hassas verinin coğrafi sınırlarını bilinçli olarak belirledik.

Süreç ve kültür: VERBİS, ihlal ve tasarımdan gelen gizlilik

Teknik önlemler tek başına yetmez; uyum bir süreçtir. Belirli ölçekteki veri sorumluları Veri Sorumluları Sicil Bilgi Sistemi'ne (VERBİS) kaydolmak ve işleme envanterini güncel tutmakla yükümlü. Bu envanter aslında geliştirici için de yararlı bir belge: hangi veriyi neden işlediğinizin haritasını çıkarır ve minimizasyon tartışmalarında elinizdeki en iyi kaynak olur.

Bir de kötü günün planı gerekiyor. Veri ihlali yaşandığında veri sorumlusu, durumu öğrendiği andan itibaren en kısa sürede ve en geç 72 saat içinde KVK Kurulu'na bildirmekle yükümlü. Bu süreyi bir kriz anında değil, önceden hazırlanmış bir müdahale planıyla karşılamak gerekir: kim haberdar edilecek, hangi loglara bakılacak, etkilenen kişilere nasıl ulaşılacak. Denetim ve erişim kayıtlarımızın değeri asıl burada ortaya çıkar; ihlalin kapsamını dakikalar içinde çıkarabilmek, panikle günler geçirmekten çok farklıdır.

Bütün bunları mümkün kılan tek kültürel ilke, tasarımdan gelen gizlilik: her yeni özelliğin planlama aşamasında "bu hangi kişisel veriyi üretir, ne kadar saklanır, kim erişir?" sorusunu sormak. Bu soru sprint'in sonunda değil başında sorulduğunda, uyum bir engel değil, iyi mimarinin doğal sonucu hâline gelir.

Sonuç

Sağlık verisi işleyen bir ürünü KVKK uyumlu geliştirmek, uzun bir kontrol listesini işaretlemek değil, birkaç ilkeyi mimariye gömmektir: ihtiyacınız olmayan veriyi toplamayın, topladığınızı şifreleyin ve en az yetkiyle açın, her erişimi kayıt altına alın, süresi dolanı otomatik silin ve kullanıcıya kendi verisi üzerinde gerçek kontrol verin. Bu ilkeleri sonradan eklemek çok pahalıdır; en başta bir tasarım kararı olarak benimsemek ise çoğu zaman bedelsizdir. Uyumu bir yük değil, güven inşa etmenin en somut yolu olarak görün — çünkü kullanıcı, en hassas verisini yalnızca ona layık olduğunu kanıtlayan bir ürüne emanet eder.