Yazılım Testinde Gerçek Müşteri Verisi Kullanmak KVKK'ya Aykırı mı? Canlı Veri Kopyası, Maskeleme ve Anonimleştirme
Test ortamında gerçek müşteri verisi kullanmak KVKK'ya aykırı mı? Kurul'un 2020/905 sayılı kararı, maskeleme ile anonimleştirme farkı ve 2026 ceza tutarları.
Kısa cevap: 6698 sayılı Kanun'da "test ortamında gerçek veri kullanılamaz" diyen açık bir hüküm yok, ama canlı veri tabanının kopyasını test ya da geliştirme ortamına almak başlı başına bir kişisel veri işleme faaliyetidir ve Kişisel Verileri Koruma Kurulu bunu bir güvenlik zaafı olarak değerlendiriyor. Kurul'un 24 Kasım 2020 tarihli ve 2020/905 sayılı kararı konuyu oldukça net ortaya koyuyor. Bir sigorta şirketinin internet sayfasının bulunduğu test sunucusu siber saldırıya uğradı, uygulamanın veri tabanı silinip yerine fidye talebi içeren yeni bir veri tabanı yüklendi, 311 kişinin T.C. kimlik numarası, adı, soyadı, e-posta adresi ve plaka bilgisi etkilendi. Kararın en can alıcı tespiti şu: ihlalden önce test aşamasında kullanılan kişisel veriler test sunucusundaki veri tabanına kaydediliyordu, ihlalden sonra şirket kullandığı teknolojiyi değiştirerek kişisel veri kaydetmeden test yapabilir hâle geldi. Kurul, veriler en baştan kaydedilmemiş olsaydı bu siber saldırıda bir kişisel veri ihlalinin söz konusu olmayacağını söyledi. Şirkete veri güvenliği yükümlülüğü nedeniyle 300.000 TL, bildirim yükümlülükleri nedeniyle 30.000 TL olmak üzere toplam 330.000 TL idari para cezası uygulandı.
Konuyu gündeme getiren ihtiyaç genellikle masumdur. Ödeme akışında bir hata vardır ve hatayı ancak gerçek sipariş kayıtlarıyla yeniden üretebilirsiniz. Yeni bir rapor ekranı yazılmaktadır, uydurma verilerle ekran boş görünür. Performans testi yapılacaktır, iki yüz satırlık örnek küme anlamlı sonuç vermez. Sonunda biri canlı veri tabanının dökümünü alır, hazırlık sunucusuna yükler, bir kopyasını da kendi bilgisayarına indirir. O andan itibaren müşteri verisi, güvenlik kontrollerinin çoğunun uygulanmadığı bir ortamda çoğalmaya başlar. Test ortamlarının tipik hâli bellidir: parolalar basittir, iki faktörlü doğrulama yoktur, erişim logu tutulmaz, güncellemeler ertelenir, yetkilendirme gevşektir, bazen de sunucu sırf pratik olsun diye dışarıya açık bırakılır. 2020/905 sayılı kararda da test sayfasının tüm dünyaya açık erişilebilir olduğu, saldırganın yedi giriş denemesi sonunda sisteme girdiği, erişimlerde SSL VPN benzeri güvenli iletişim yöntemlerinin ve iki faktörlü kimlik doğrulamanın kullanılmadığı, parolaların yeterince güçlü olmadığı tespit edilmişti.
Hukuki tabloyu kurmak için tek bir soruyu yanıtlamak yeter: kopyalama işleminin kendisi nedir? Kanun'un 3. maddesi; kişisel veriler üzerinde gerçekleştirilen elde etme, kaydetme, depolama, muhafaza etme, değiştirme ve aktarma gibi her türlü işlemi kişisel veri işleme sayıyor. Canlı veri tabanının test ortamına kopyalanması bunların birkaçını aynı anda kapsar. Dolayısıyla bu işlemin de 4. maddedeki genel ilkelere uyması gerekir: belirli, açık ve meşru amaç, işlenme amacıyla bağlantılı sınırlı ve ölçülü olma, gerekli olan süre kadar muhafaza. Uygulamada en çok zorlanılan yer ölçülülük. Bir raporlama ekranını test etmek için müşterilerin kimlik numarasına, adresine ve telefonuna gerçekten ihtiyacınız var mı? Çoğu senaryoda cevap hayır. İkinci zorluk amaç tarafında, çünkü aydınlatma metinlerinde "yazılım geliştirme ve test" diye bir amaç genellikle yazmaz; sipariş verisi sipariş yönetimi için toplanmıştır. Üçüncüsü 12. madde. Veri sorumlusu uygun güvenlik düzeyini temin etmekle yükümlü ve bu yükümlülük canlı ortamla sınırlı değil, kişisel verinin bulunduğu her ortamı kapsıyor.
Madalyonun diğer yüzü de ceza konusu. Kurul'un 12 Mart 2020 tarihli ve 2020/213 sayılı kararına konu olayda bir internet servis sağlayıcısının çevrimiçi işlem merkezinde fatura ödemesi yapılamıyordu. Sorunu gidermek için uygulamaya log üreten özellikler eklenip "debug" ile düzeltme denendi, bu sırada bir güvenlik açığı oluştu ve 69 kişiye ait kart bilgisi 649 şirket müşterisi tarafından görüntülendi. Kurul, yazılım geliştiricilere sözlü olarak iletilen değişiklik talebinin test ortamında değil gerçek ortamda yapılmasını, canlıya alma süreçlerine ilişkin prosedürlerin uygulanmadığının göstergesi saydı. Şirket savunmasında sistem arayüzlerinde kişisel verilerin ya hiç gösterilmediğini ya da maskelendiğini belirtmişti; Kurul, buna rağmen kimlik ve finans verilerinin görüntülenebilmesini teknik eksiklik olarak değerlendirdi ve 300.000 TL idari para cezası verdi. İki kararı yan yana koyduğunuzda kural sadeleşiyor. Gerçek veriyi test ortamına taşımak da hata, testi canlı ortamda yapmak da hata. Doğrusu, gerçek veriyi çoğaltmadan çalışabilen bir test ortamı kurmak.
Burada en sık karıştırılan iki kavram devreye giriyor. Kurum'un Kişisel Verilerin Silinmesi, Yok Edilmesi veya Anonim Hale Getirilmesi Rehberi'nde maskeleme; kişisel verilerin belli alanlarının, kimliği belirli veya belirlenebilir bir gerçek kişiyle ilişkilendirilemeyecek şekilde silinmesi, üstlerinin çizilmesi, boyanması ve yıldızlanması gibi işlemler olarak tanımlanıyor. Anonim hale getirme ise çok daha yüksek bir eşik: verinin, başka verilerle eşleştirilse dahi hiçbir surette kimliği belirli veya belirlenebilir bir gerçek kişiyle ilişkilendirilemeyecek hâle getirilmesi. Fark, test veri tabanlarında hemen görünür. Ad ve soyad sütununu yıldızlayıp kimlik numarasını, telefonu, adresi, doğum tarihini ve sipariş geçmişini olduğu gibi bırakan bir betik maskeleme yapmıştır, anonimleştirme yapmamıştır. O tablo hâlâ kişisel veridir ve Kanun'un tamamı ona uygulanır. Anonim hâle gelmiş bir küme ise kişisel veri olmaktan çıktığı için Kanun kapsamı dışında kalır; 28. maddenin birinci fıkrasının (b) bendi de kişisel verilerin resmî istatistik ile anonim hâle getirilmek suretiyle araştırma, planlama ve istatistik gibi amaçlarla işlenmesini Kanun hükümlerinin uygulanmayacağı hâller arasında sayıyor.
Rehber, bir veriyi silmek ya da yok etmek yerine anonim hâle getirmeye karar verebilmek için üç şart arıyor: anonim hâle getirilmiş veri kümesinin başka bir veri kümesiyle birleştirilerek anonimliğinin bozulamaması, bir ya da birden fazla değerin bir kaydı tekil hâle getirebilecek şekilde anlamlı bir bütün oluşturmaması, kümedeki değerlerin birleşip bir varsayım veya sonuç üretebilir hâle gelmemesi. Yöntemler de ayrı ayrı sayılıyor. Değer düzensizliği sağlamayanlar arasında değişkenleri çıkartma, kayıtları çıkartma, bölgesel gizleme, genelleştirme, alt ve üst sınır kodlama, global kodlama ve örnekleme var. Değer düzensizliği sağlayanlar mikro birleştirme, veri değiş tokuşu ve gürültü ekleme. Anonimliği kuvvetlendiren istatistiksel yöntemler ise k-anonimlik, l-çeşitlilik ve t-yakınlık. Bu listeyi gören yazılım ekiplerinin çoğu haklı olarak duraksıyor, çünkü bir hata ayıklama oturumu uğruna bu ağırlıkta bir süreç kurmak mantıklı değil. Zaten mesele de tam burada. Test ortamının ihtiyacı anonimleştirilmiş gerçek veri değil, baştan üretilmiş sahte veridir.
Yine de anonimleştirmeyi denemeye karar verirseniz, rehberin altını çizdiği riski hesaba katın. Anonim hâle getirme işlemleri çeşitli müdahalelerle tersine döndürülebilir ve veri yeniden kimlik belirleyici hâle gelebilir; rehber buna anonimliğin bozulması diyor. Test veri tabanları bu riske canlı sistemlerden daha açıktır, çünkü küçüktürler. Yüz binlik bir tabloda kalabalığa karışan bir kayıt, üç yüz satırlık bir test kümesinde tekilleşir. Doğum yılı ve ilçe bilgisi duran bir tabloda, o ilçedeki tek kadın kardiyolog tek satırdır. İkinci sık hata, geri döndürülebilir yöntemleri anonimleştirme sanmak. Gerçek değerleri bir eşleştirme tablosunda saklayıp yerlerine takma anahtar koyuyorsanız elinizdeki veri anonim değildir, eşleştirme tablosuna erişebilen herkes bakımından hâlâ kişisel veridir. Aynı şey, sabit bir kuralla üretilip kolayca geri çevrilebilen sahte kimlik numaraları için de geçerli.
Test verisinde sağlık, biyometri veya sendika üyeliği gibi özel nitelikli veri varsa eşik yükseliyor. Kurul'un 31 Ocak 2018 tarihli ve 2018/10 sayılı ilke kararı; özel nitelikli kişisel veri işleyen veri sorumlularından ayrı bir politika ve prosedür belirlemesini, verilere erişim yetkisine sahip kullanıcıların yetki kapsamlarının ve sürelerinin net tanımlanmasını, periyodik yetki kontrollerini, elektronik ortamda verilerin kriptografik yöntemlerle muhafaza edilmesini, kriptografik anahtarların güvenli ve farklı ortamlarda tutulmasını, veriler üzerinde gerçekleştirilen tüm hareketlerin güvenli şekilde loglanmasını ve uzaktan erişim gerekiyorsa en az iki kademeli kimlik doğrulama sistemini istiyor. Kurum'un Şubat 2025'te yayımladığı Özel Nitelikli Kişisel Verilerin İşlenmesine İlişkin Rehber de bu kararı esas almayı sürdürüyor. Bir hastane bilgi yönetim sisteminin ya da bir insan kaynakları yazılımının test ortamında gerçek hasta veya çalışan kaydı duruyorsa, bu listenin tamamı o ortam için de geçerlidir. Sahada test ortamlarının çok azı bu maddelerden birini bile karşılıyor.
Geliştirme dışarıdan alınıyorsa tablo değişmiyor, yalnızca taraf sayısı artıyor. Yazılım firması veri sorumlusunun talimatıyla veri işlediği sürece veri işleyendir ve Kanun'un 12. maddesinin ikinci fıkrası, güvenlik tedbirlerinin alınması konusunda veri sorumlusuyla müştereken sorumlu olduğunu söylüyor. Kişisel Veri Güvenliği Rehberi, veri işleyenle imzalanan sözleşmenin yazılı olmasını, veri işleyenin yalnızca veri sorumlusunun talimatları doğrultusunda hareket edeceğine ilişkin hüküm taşımasını, süresiz sır saklama yükümlülüğünü ve bir ihlal hâlinde durumun derhal veri sorumlusuna bildirileceğinin öngörülmesini öneriyor. Aynı rehber, bakım ve onarım gibi amaçlarla dışarıdan gelen personelin kişisel verileri kopyalayarak kurum dışına çıkarmasının engellenmesini de istiyor. Buna rağmen sahada en çok duyulan cümle şu: "Veri tabanı yedeğini bir dosya transferi bağlantısıyla gönderelim, geliştirici kendi ortamında bakar." Dosya gönderildiği anda kontrol de elinizden çıkar. Kurul'un 16 Haziran 2020 tarihli ve 2020/465 sayılı kararında, bir paylaşım sürücüsünden altı terabayttan fazla verinin sızması, yüksek miktarda verinin tek bir yerde depolanmasıyla ilişkilendirilmiş ve bu riski azaltacak idari tedbirlerin alınmadığı sonucuna varılmıştı.
Test ortamı yurt dışındaki bir bulut hesabında duruyorsa ya da geliştirici ekip yurt dışındaki bir şirketse ikinci bir yükümlülük katmanı açılır. Kanun'un 9. maddesi kişisel verinin yurt dışına aktarılmasını ayrı şartlara bağlıyor; hakkında yeterlilik kararı bulunmayan ülkelere yapılan aktarımda standart sözleşme yöntemi kullanılıyorsa sözleşmenin imzalanmasından itibaren beş iş günü içinde Kuruma bildirilmesi gerekiyor ve bu bildirimin yapılmaması ayrı bir idari para cezası doğuruyor. Şirketlerde sıkça gözden kaçan ayrıntı şu: canlı sistemler için özenle hazırlanan aktarım dosyasına test ve geliştirme ortamları hiç girmez. Oysa aynı müşteri kaydı oradadır. Kod yazarken kullanılan yapay zekâ araçlarına gerçek müşteri kayıtlarının yapıştırılması da aynı başlığın bir başka görünümü ve çoğu şirkette henüz yazılı bir kuralı yok.
İhlal gerçekleştiğinde takvim işlemeye başlar. Kurul'un 24 Ocak 2019 tarihli ve 2019/10 sayılı kararı, veri sorumlusunun ihlali öğrendiği tarihten itibaren yetmiş iki saat içinde Kuruma bildirimde bulunmasını istiyor. İlgili kişilere bildirim ise makul olan en kısa sürede ve 18 Eylül 2019 tarihli ve 2019/271 sayılı karara uygun biçimde yapılmalı. 2020/905 sayılı kararda şirketin kendi internet sitesinde duyuru yayımlamış olması, ilgili kişiler tespit edilmiş olduğu için bildirim yerine sayılmadı; 30.000 TL'lik ikinci ceza kalemi buradan doğdu. 2026 rakamlarıyla üst sınırlar ciddi: veri güvenliği yükümlülüklerine aykırılık 256.357 TL ile 17.092.242 TL, aydınlatma yükümlülüğüne aykırılık 85.437 TL ile 1.709.200 TL arasında idari para cezası anlamına geliyor. Test ortamından sızan bir veri kümesi çoğu zaman tek bir kalemle de kapanmaz, çünkü o verinin test amacıyla işleneceği aydınlatma metninde de yazmıyordur.
Yapılacak iş listesi kısa, ama ertelenmeye fazlasıyla müsait. Önce envanter: canlı veri kopyalarının hangi sunucularda, hangi dizüstü bilgisayarlarda, hangi yedeklerde ve hangi konteyner imajlarında durduğunu yazılı hâle getirin. Sonra erişim: geliştiricilerin canlı veri tabanına doğrudan erişimini yetki matrisiyle sınırlayın, zorunlu hâllerde erişimi süreli verin ve kayıt altına alın. Ardından üretim: referans bütünlüğünü koruyan sahte kayıtlar üreten bir test verisi betiği, uzun vadede her maskeleme denemesinden ucuza gelir. Mevcut test veri tabanlarını imha edin ve imha kayıtlarını tutun, saklama ve imha politikanıza test, geliştirme ve eğitim ortamlarını ayrı başlıklar olarak ekleyin. Dış geliştiriciyle sözleşmenizi ve varsa yurt dışı aktarım dosyanızı bu ortamları da kapsayacak şekilde güncelleyin. KVKK Danışman'ın ücretsiz ön değerlendirmesinde test ve geliştirme ortamlarınızda hangi kişisel verilerin bulunduğunu, erişim yetkilerini ve yazılım tedarikçinizle imzaladığınız sözleşmeyi birlikte gözden geçiriyoruz.