KVKK Uyumlu Yazılım Tasarımı: Privacy by Design Rehberi

KVKK uyumu çoğu kurumda hukuk departmanının işi sayılır: aydınlatma metni yazılır, VERBİS kaydı yapılır, sözleşmelere madde eklenir. Yazılım ise "verileri zaten koruyoruz" varsayımıyla olduğu gibi kalır. Sonra bir ilgili kişi başvurusu gelir ve kimse müşterinin verisinin hangi tablolarda, hangi yedeklerde ve hangi log dosyalarında olduğunu bilmez; ya da bir ihlal olur ve 72 saat içinde neyin sızdığı raporlanamaz.

KVKK (6698 sayılı Kanun) uyumu, GDPR'daki adıyla privacy by design, yazılımın tasarım kararlarıyla sağlanır. Bu yazıda kanunun ilkelerini teknik desenlere çeviriyoruz: kişisel veri envanterinin koda yansıması, veri minimizasyonu, alan bazlı şifreleme ve maskeleme, saklama süreleri ve otomatik imha, erişim logları, ilgili kişi başvuruları ve ihlal bildirimi. Örnekler Spring Boot ile; hukuki değerlendirme için KVKK uzmanınıza danışın, burada mimariyi ele alıyoruz.

İlkeden desene

1. Envanter koda yansır

Kişisel veri envanteri bir Excel dosyasında kalırsa ilk sürümde eskir. Envanteri koda taşıyın: her kişisel alan sınıflandırma, amaç ve saklama süresiyle işaretlenir; envanter raporu bu işaretlerden üretilir.

@Entity
public class Musteri {
    @Id private Long id;

    @KisiselVeri(sinif = Sinif.KIMLIK, amac = "sözleşme ifası", saklamaAy = 120)
    private String adSoyad;

    @KisiselVeri(sinif = Sinif.ILETISIM, amac = "sözleşme ifası", saklamaAy = 120)
    @Convert(converter = SifreliAlanConverter.class)          // alan bazlı şifreleme
    private String telefon;

    @KisiselVeri(sinif = Sinif.OZEL_NITELIKLI, amac = "yasal yükümlülük", saklamaAy = 120)
    @Convert(converter = SifreliAlanConverter.class)
    private String tcKimlikNo;
}

// Envanter raporu: koddan üretilir, elle güncellenmez
List<EnvanterSatiri> envanter = entityManager.getMetamodel().getEntities().stream()
    .flatMap(e -> Arrays.stream(e.getJavaType().getDeclaredFields()))
    .filter(f -> f.isAnnotationPresent(KisiselVeri.class))
    .map(EnvanterSatiri::from)
    .toList();

Bu yaklaşımın ikinci faydası: "hangi tablolarda kişisel veri var" sorusu bir sorguya dönüşür; başvuru ve ihlal anında liste elinizdedir.

2. Minimizasyon: toplamadığınız veri sızmaz

• Formda: Her alan için "neden gerekli" cevabı yoksa alan kaldırılır. Doğum tarihi yerine "18 yaş üstü" onayı yeterliyse tarihi toplamayın.

• API ve ekranlarda: Liste ekranları maskelenmiş değer döndürür (05** *** 12 34); tam değer yalnızca yetkili rol ve açık bir "göster" eylemiyle, loglanarak.

• Analitikte: Raporlar ve veri ambarı pseudonim kimliklerle çalışır; kimlik eşleme tablosu ayrı ve kısıtlı erişimlidir.

• Test ortamında: Üretim verisi asla olduğu gibi kopyalanmaz; anonimleştirilmiş ya da sentetik veri kullanılır.

3. Şifreleme ve maskeleme

Disk şifrelemesi (veritabanı TDE, bulut disk şifreleme) zorunlu tabandır ama yeterli değildir: veritabanına erişen herkes veriyi düz metin görür. Hassas alanlar için alan bazlı şifreleme uygulama katmanında yapılır; anahtar, veritabanından ayrı bir anahtar yönetim sisteminde (KMS, Vault) tutulur ve döndürülür.

@Converter
public class SifreliAlanConverter implements AttributeConverter<String, String> {
    private final AlanSifreleyici sifreleyici;   // AES-256-GCM; anahtar KMS'ten, sürüm etiketiyle

    @Override public String convertToDatabaseColumn(String duz) { return duz == null ? null : sifreleyici.sifrele(duz); }
    @Override public String convertToEntityAttribute(String sifreli) { return sifreli == null ? null : sifreleyici.coz(sifreli); }
}

Şifreli alanda arama yapılamaz; TC kimlik numarasıyla arama gerekiyorsa aynı satıra bir HMAC özeti (arama anahtarı) yazılır ve eşleşme özet üzerinden yapılır. Loglar ayrı bir konudur: kişisel veri log satırına hiç girmemelidir; log yapılandırmasında maskeleme (telefon, e-posta, TCKN için kalıp tabanlı) merkezi bir filtre olarak kurulur.

4. Saklama süresi ve otomatik imha

"Gerektiği kadar saklama" ilkesi, bir tarih alanı ve bir zamanlanmış iş olmadan uygulanamaz. Her kişisel veri kümesi için saklama süresi envanterde tanımlıdır; süre dolduğunda veri silinir, anonimleştirilir ya da yok edilir ve imha kaydı tutulur (yönetmelik periyodik imhayı en geç altı ayda bir ister).

@Scheduled(cron = "0 0 3 1 * *")                              // her ayın 1'i, 03:00
void periyodikImha() {
    for (SaklamaKurali k : saklamaKurallari.aktifOlanlar()) {  // envanterden türetilir
        List<ImhaAdayi> adaylar = k.suresiDolanlar(clock.instant());
        for (ImhaAdayi a : adaylar) {
            switch (k.yontem()) {
                case SIL          -> a.sil();
                case ANONIMLESTIR -> a.anonimlestir();          // ad → "***", telefon → null, kimlik → hash
            }
            imhaKayitlari.kaydet(ImhaKaydi.of(a, k, clock.instant()));   // denetim için
        }
    }
}

İki zorluk: yedekler (silinen veri yedekte durur; yedek saklama süresi imha politikasının parçasıdır ve şifreleme anahtarını imha etmek — crypto-shredding — pratik bir çözümdür) ve yasal saklama çakışması (fatura verisi ticari kanun gereği 10 yıl saklanır; müşteri "sil" dese de fatura silinmez, yalnızca pazarlama amaçlı veri silinir). Kural motoru bu çakışmayı envanterdeki hukuki dayanaktan çözer.

5. Erişim logu: kim, ne zaman, neyi gördü?

Kişisel veriye her erişim — özellikle tam değer görüntüleme, dışa aktarım ve toplu sorgu — kim, ne zaman, hangi kayıt, hangi amaçla bilgisiyle değiştirilemez bir loga yazılır. Bu log ihlal anında "etkilenen kişiler" sorusunun cevabıdır ve iç kötüye kullanımın caydırıcısıdır. Uygulamada bir servis katmanı aspect'i ya da API gateway seviyesinde yapılır; log kişisel veri içermez, yalnızca kayıt kimliğini içerir.

6. İlgili kişi başvurusu: 30 gün, tek servis

Bir kişi "hangi verilerimi tutuyorsunuz, silin" dediğinde cevap 30 gün içinde verilmelidir. Bunun elle yapılması, on beş tabloyu ve üç dış sistemi kim taradıysa ona bağlıdır. Doğru tasarım, kişi kimliğinden tüm kişisel verileri bulan, okunabilir biçimde dışa aktaran ve silme/anonimleştirme uygulayan bir veri öznesi servisidir; envanter işaretleri sayesinde hangi tabloların taranacağı koddan bilinir. Dış sistemlere (e-posta sağlayıcı, CRM SaaS) iletilen veriler için silme talebi otomatik olarak ilgili API'lere yayılır.

7. Yurt dışı aktarım ve bileşen seçimi

2024 değişikliğiyle yurt dışına aktarım rejimi GDPR'a yaklaştı: yeterlilik kararı, standart sözleşme gibi uygun güvenceler ya da istisnalar gerekir. Yazılım tarafında bu, her bulut ve SaaS bileşeninin (e-posta gönderimi, hata izleme, analitik, LLM API'si, CDN) verinin nerede işlendiğine göre değerlendirilmesi ve bir aktarım envanterinin tutulması demektir. Bölge seçilebilen hizmetlerde Türkiye/AB bölgesi, seçilemeyenlerde pseudonim veri ya da kullanmama kararı.

Uygulama kontrol listesi

• Kişisel alanlar kodda sınıf, amaç ve saklama süresiyle işaretli; envanter koddan üretiliyor.

• Formlar ve API'ler yalnızca gerekli alanı topluyor ve döndürüyor; listelerde maskeleme var.

• Özel nitelikli ve kimlik verileri alan bazlı şifreli; anahtar KMS'te, döndürülebilir.

• Log filtresi kişisel veriyi maskeliyor; loglarda TCKN, telefon, e-posta yok.

• Saklama süreleri tanımlı; periyodik imha işi çalışıyor ve imha kaydı tutuyor; yedek politikası uyumlu.

• Kişisel veriye erişim logu var; ihlal anında etkilenen kayıtlar sorgulanabiliyor.

• Veri öznesi servisi: bul, dışa aktar, sil/anonimleştir; dış sistemlere yayılıyor.

• Test ortamı anonim/sentetik veriyle çalışıyor.

• Bulut ve SaaS bileşenleri için veri yerleşimi ve aktarım envanteri var.

Sık sorulan sorular

KVKK ile GDPR arasındaki fark yazılımı etkiler mi?

Teknik desenler büyük ölçüde aynıdır; farklar sürelerde (başvuru yanıtı 30 gün, ihlal bildirimi 72 saat), VERBİS gibi idari yükümlülüklerde ve aktarım rejiminin ayrıntılarındadır. Hem Türkiye'de hem AB'de faaliyet gösteren kurumlar için tek bir tasarım her iki rejimi karşılar.

Anonimleştirme ile pseudonimleştirme arasındaki fark ne?

Anonim veri geri döndürülemez ve kişisel veri sayılmaz; pseudonim veri bir eşleme tablosuyla kişiye geri bağlanabilir ve kişisel veri olmaya devam eder. Analitik için pseudonim, imha için anonim.

Mevcut sisteme sonradan uygulanabilir mi?

Evet, kademeli: önce envanter işaretleri ve log maskeleme (düşük risk, yüksek kazanç), sonra erişim logu ve veri öznesi servisi, en son alan bazlı şifreleme (veri göçü gerektirir) ve imha işleri.

Sonuç

KVKK uyumu, envanterin koda yansıdığı, gereksiz verinin toplanmadığı, hassas alanların şifrelendiği, sürelerin otomatik uygulandığı, erişimin loglandığı ve tek kişinin verisinin tek servisle yönetilebildiği bir mimaridir. Bu mimari kurulduğunda uyum bir proje değil, sistemin doğal davranışı olur.

Mevcut uygulamanızın KVKK açısından teknik değerlendirmesini yapmak ve bu desenleri kademeli uygulamak için yazılım tasarımı ve mimari ile kurumsal uygulama geliştirme hizmetlerimize göz atabilirsiniz.