Test Ortamında Gerçek Veri: En Sessiz KVKK Riski

Bir hata üretimde görülüyor, test ortamında görülmüyor. Çözüm herkesin bildiği çözüm: üretim yedeği test ortamına geri yükleniyor. İş akşam biterken kimse durup şunu sormuyor: bu ortamda şu anda kaç gerçek kişinin verisi var ve bu veriye kimler erişebiliyor? Bu yazı, en yaygın ve en az konuşulan kişisel veri riskini ele alıyor.

Herkesin Yaptığı, Kimsenin Konuşmadığı İş

Üretim verisinin üretim dışı ortamlara kopyalanması, kurumsal yazılım geliştirmenin en yerleşik alışkanlıklarından biridir. Sektör araştırmaları, işletmelerin büyük çoğunluğunun uygulama testinde canlı müşteri verisi kullandığını gösteriyor. Bunun sebebi ihmal değil, pratikliktir: gerçek veri gerçek hatayı gösterir.

Alışkanlığın sessiz kalmasının sebebi de aynı: hiçbir zaman bir olay üretmez. Yedek geri yüklenir, hata bulunur, iş biter. Ortam ayakta kalır ve içindeki veri orada durur. Ne bir uyarı çıkar ne bir bilet açılır.

Neden Sorun: Üç Ayrı Eksik

Bu alışkanlık tek bir kural ihlali değildir. Veri koruma mevzuatının üç ayrı ilkesine aynı anda dokunur ve her biri kendi başına bulgu üretir.

Amaç sınırlaması. Kişisel veri, toplanma amacıyla bağdaşmayan biçimde işlenemez. Müşteri verisi hizmet sunmak için toplanmıştır; yazılım testi için toplanmamıştır. Test, verinin toplandığı amaçtan farklı bir amaçtır ve bu ayrım genellikle hiç yapılmaz çünkü kimse test ortamına veri kopyalamayı bir "işleme faaliyeti" olarak görmez. Halbuki tanımı gereği öyledir.

Veri minimizasyonu. İşlenen veri, amaçla sınırlı ve ölçülü olmalıdır. Bir yedeğin geri yüklenmesi, tanımı gereği bunun tam tersidir: her tablo, her kolon, her satır. Bir ödeme hatasını incelemek için tüm müşteri tabanının kimlik ve iletişim bilgilerine ihtiyaç yoktur.

Güvenlik seviyesinin eşitsizliği. Üretim ortamı korunur: erişim kısıtlıdır, şifreleme vardır, izleme vardır, yedekleri denetlenir. Test ortamı bunların hiçbirine sahip olmak zorunda değildir ve genellikle değildir. Aynı veri, çok daha zayıf bir koruma altına taşınmış olur. Saldırgan açısından bakıldığında en kolay hedef, en iyi korunan ortam değil, aynı veriyi tutan en zayıf ortamdır.

Kaç Kopyanız Var, Gerçekten Biliyor musunuz?

Bu sorunun cevabı kurumların çoğunda tahmin edilenden büyüktür, çünkü kopyalar yalnızca resmi test ortamlarında durmaz.

Kabul testi ortamı vardır. Geliştirme ortamı vardır. Bir performans testi için ayrılmış üçüncü bir ortam vardır. Bir geliştiricinin kendi bilgisayarına indirdiği yedek dosyası vardır. Analiz için dışa aktarılmış bir elektronik tablo vardır. Bir tedarikçiye hata incelemesi için gönderilmiş bir örnek veri kümesi vardır. Ve genellikle, bir sunucunun disk üzerinde unutulmuş, üzerinde tarih olan bir yedek dosyası vardır.

Bu listedeki her kalem, aynı kişisel veriyi taşıyan ayrı bir kopyadır ve her biri ayrı bir ihlal yüzeyidir. Ortak özellikleri, hiçbirinin envanterde görünmemesidir. Kişisel veri envanteri hazırlanırken sistemler listelenir; sistemlerin kopyaları listelenmez.

Haklı Gerekçe ve Dürüst Karşılığı

Bu noktada geliştirme ve test ekiplerinin itirazı haklıdır ve ciddiye alınmalıdır: uydurma veriyle gerçek hata bulunamaz.

Gerçekten de üretim verisinin taşıdığı üç şey vardır ve üçü de uydurma veride bulunmaz. Hacim: on satırla çalışan bir sorgu on milyon satırla çalışmayabilir. Dağılım: gerçek veride bir müşterinin binlerce hareketi varken diğerinin hiç yoktur; bu çarpıklık plan seçimini değiştirir. Kirlilik: yıllar içinde birikmiş boş alanlar, tutarsız biçimler ve beklenmeyen karakterler yalnızca gerçek veride bulunur ve hataların çoğu tam olarak oradan çıkar.

Dolayısıyla doğru cevap "üretim verisi kullanmayın" değildir. Doğru cevap şudur: bu üç özelliği koruyup kişiyi tanımlayan alanları koruma altına almak. Bunlar birbirinden ayrılabilir; çünkü hatayı bulduran şey müşterinin adı değil, verinin şekli ve hacmidir.

Üç Seviyeli Çözüm

Kurumlar bu işi tek adımda çözmeye çalıştığında genellikle hiç başlayamaz. Seviyeli ilerlemek, ilk gün fayda üretir.

İkinci seviyedeki asıl zorluk teknik değildir. Bir kolonun maskelenip maskelenmeyeceğine yalnızca adına bakarak karar verilemez; on bir haneli her sayı kimlik numarası değildir ve adı hiçbir şey ima etmeyen bir kolon kişisel veri taşıyor olabilir. Karar, kolon adı ile içeriğin birlikte değerlendirilmesini gerektirir.

Bugün Yapılabilecekler

Kopyaları sayın. Üretim verisi taşıyan kaç ortam ve kaç dosya var? Bu sayıyı bulmak bir haftayı geçmez ve genellikle beklenenin iki katı çıkar.

Silme talebini simüle edin. Bir kişinin verisinin tüm ortamlardan silinmesi ne kadar sürer? Cevap veremiyorsanız, gerçek bir talep geldiğinde de veremeyeceksiniz.

Kopyalamayı kayda bağlayın. Üretimden veri çıkışı, ister yedek geri yükleme ister dışa aktarma olsun, bir talebe dayanmalı ve kim istedi, hangi gerekçeyle, hangi ortama sorularının cevabı kayıtlı olmalıdır. Bu tek başına kopyayı engellemez ama kopyayı görünür kılar.

Süre koyun. Her kopyanın bir son kullanma tarihi olsun. Tarihsiz kopya, kalıcı kopyadır.

SQL Change Guard bu tablonun ikinci ve üçüncü satırına doğrudan katkı verir: üretimden veri çekme talebi onaya bağlanır, hassas kolonlar sonuç kümesinde maskelenir ve verinin kime, hangi gerekçeyle, ne zaman gittiği kayıt altına alınır. Bir yedeğin test ortamına geri yüklenmesini engellemez; o kararın kendisi sizde kalır. Katkısı, üretimden çıkan verinin görünmez olmaktan çıkmasıdır.

Sık Sorulan Sorular

Test ortamı da bizim ağımızın içinde. Yine de risk var mı?

Evet, çünkü risk yalnızca dışarıdan gelmez. Test ortamlarına genellikle daha geniş bir grup erişir: geliştiriciler, test uzmanları, bazen tedarikçi danışmanları. Üretimde beş kişinin görebildiği veriyi test ortamında elli kişi görebiliyorsa, verinin kendisi aynı olsa bile maruz kalma yüzeyi on kat büyümüştür. Ayrıca test ortamları çoğu zaman üretimin sahip olduğu şifreleme, izleme ve yedek denetimi kontrollerine sahip değildir.

Maskelenmiş veriyle performans testi yapılabilir mi?

Maskeleme doğru yapıldığında evet. Performansı belirleyen şey alanların içeriği değil, satır sayısı, değerlerin dağılımı, indekslerin seçiciliği ve alan uzunluklarıdır. Bir isim alanı aynı uzunlukta başka bir metinle değiştirildiğinde sorgu planı değişmez. Dikkat edilmesi gereken nokta, maskelemenin seçiciliği bozmamasıdır: tüm müşterilere aynı adı vermek indeksin davranışını değiştirir ve testi yanıltır.

Yıllardır böyle çalışıyoruz ve hiç sorun yaşamadık. Neden şimdi?

Çünkü bu riskin doğası, gerçekleşene kadar hiçbir belirti vermemesidir. Sorun yaşanmamış olması, kontrolün çalıştığını değil, henüz test edilmediğini gösterir. İki durum bunu tetikler: bir veri ihlali bildirimi gerektiğinde etkilenen kişi sayısı tüm kopyalar üzerinden hesaplanır, ya da bir denetçi kişisel veri envanterini isteyip üretim dışı ortamları sorar. İkisi de önceden haber vermez ve ikisinde de geriye dönük düzeltme mümkün değildir.

Anonim hale getirmek ile maskelemek aynı şey mi?

Hayır ve bu fark hukuken önemlidir. Gerçekten anonim hale getirilmiş veri artık kişisel veri sayılmaz; ancak anonimlik, verinin hiçbir yolla bir kişiye geri bağlanamamasını gerektirir ve bu sanıldığından zordur. Kolon bazlı maskeleme genellikle bu eşiği karşılamaz: doğum tarihi, posta kodu ve cinsiyet gibi maskelenmemiş alanların birleşimi bir kişiyi tekrar tanımlanabilir kılabilir. Bu yüzden maskelenmiş test verisi, güvenlik açısından büyük bir kazanç sağlasa da, mevzuat karşısında hala kişisel veri gibi ele alınmalıdır.

SQL Change Guard test veritabanımızı maskeler mi?

Hayır ve kapsamı net söylemek doğru olur. Tüm bir veritabanını kopyalayıp içindeki kişisel alanları toplu olarak değiştiren araçlar ayrı bir kategoridir ve test verisi yönetimi olarak adlandırılır. SQL Change Guard bu işi yapmaz. Yaptığı iş, üretim veritabanından veri çekme talebini yönetmektir: talep açılır, gerekçesi yazılır, onaydan geçer, dönen sonuç kümesinde hassas kolonlar maskelenir ve verinin kime gittiği kaydedilir. Yani ilgilendiği yüzey, ortamlar arası toplu kopyalama değil, kişilerin üretimden veri almasıdır. İki ihtiyaç birbirini tamamlar; birbirinin yerine geçmez ve bir toplantıda bunun karıştırılması yanlış beklenti üretir.

Nereden başlamak gerekir?

Envanterden. Üretim verisi taşıyan ortamları ve dosyaları listeleyin, her birine bir sahip ve bir tarih yazın. Bu listenin uzunluğu, geri kalan tartışmayı kendiliğinden başlatır. Ardından tek bir ortamı seçip maskelemeyle ilerleyin; tüm ortamları aynı anda düzeltmeye çalışmak, çoğu programın hiç başlamadan durmasının sebebidir.