Test ortamında gerçek müşteri verisi kullanılır mı? Maskeleme, alt küme ve sentetik veri

Kısa cevap: canlı müşteri verisinin ham kopyası test ortamına gitmemeli. Ama "gerçekçi veri olmadan doğru test edilmez" itirazı da haklı, o yüzden cevap "kopyalamayın" ile bitmiyor. Çalışan kurgu üç parçadan oluşuyor: üretimden alınan küçük bir alt kümeyi maskeleyip gerçekçilik için kullanmak, uç durumlar ve hacim için sentetik kayıt üretmek, otomatik testlerin ihtiyacı olan veriyi kendilerinin kurması. Bir de çoğu ekibin gözden kaçırdığı dördüncü mesele var: kazaların büyük kısmı verinin kendisinden değil, test ortamının dışarıya gerçek çağrı yapmasından çıkıyor.

"Sadece bir kopya" diye başlar

K2view'in Mart 2026'da yayımladığı ankete göre kurumlar üretim dışı ortamlarda ortalama 29 tam veritabanı kopyası taşıyor, katılımcıların yüzde 44'ünde bu sayı 26'nın üzerinde. Aynı çalışmada geliştirme ve test ortamlarının yalnızca yüzde 4'ü veri gizliliği gereklerine tam uyumlu sayılmış, yüzde 76'sı son üç yılda üretim dışı bir ortamda hassas veri olayı yaşadığını söylemiş.

Perforce'un Temmuz 2026'da 518 kurumsal yöneticiyle yaptığı ankette daha ilginç bir tablo var: katılımcıların yüzde 99'u üretim dışı ortamlar için bir maskeleme politikası olduğunu söylüyor, yüzde 84'ü o politikaya istisna tanındığını da ekliyor. Yüzde 43'ü denetimde takılmış, yüzde 34'ü üretim dışı veriyle ilgili bir ihlal ya da veri hırsızlığı bildirmiş. İkisi de satıcı anketi, kesin rakam gibi okunmamalı. Yön gösterirler: politikanın kağıtta olması ile ortamda olması ayrı şeyler.

Sebep basit. Test ortamı üretimle aynı ilgiyi görmez. Erişim listesi daha geniştir, log daha azdır, parolalar daha zayıftır, uyarı kurulu değildir, bazen bir demo için internete açılmış ve öyle kalmıştır. Verinin hassasiyeti kopyalandığında azalmaz, etrafındaki koruma azalır.

Gerçekçilik ile gerçek kişi aynı şey değil

Geliştiricinin itirazı yersiz değil. Üretim verisi gerçek tuhaflığı taşır: 2014'ten kalma yarım adres kayıtları, iki kez girilmiş müşteriler, açıklama alanına sıkıştırılmış notlar, hiçbir zaman doldurulmamış kolonlar. Temiz bir seed dosyası bunların hiçbirini içermez, o yüzden temiz seed ile geçen test üretimde patlar.

Ama ihtiyaç duyulan şey verinin gerçek kişiye ait olması değil, gerçek şekle sahip olması. Bu ayrımı kabul ettiğiniz anda çözüm teknik bir işe dönüşüyor.

Maskeleme "isimleri sildik" demek değil

Kötü maskeleme, iyi maskelemeden daha tehlikelidir çünkü sorunu çözdüğünüzü sanırsınız. İşe yarayan bir maskeleme şu dört özelliği korur.

Deterministik olmalı: aynı girdi her tabloda aynı çıktıyı vermeli. Yoksa musteri.id ile siparis.musteri_id birbirini tutmaz, join'ler boş döner, ekip "veri bozuk" diyip ortamı kullanmayı bırakır.

Format korunmalı: kimlik numarası kendi algoritmasına uymalı, IBAN checksum'ı geçmeli, e-posta e-postaya benzemeli. Aksi halde uygulamanın doğrulama katmanı test verisini reddeder.

Benzersizlik korunmalı: unique indeks olan kolonda iki kaydı aynı değere maskelerseniz yükleme hata verir.

Dağılım korunmalı: tarih aralıkları, ülke dağılımı, null oranları benzer kalmalı ki sorgu planları üretimdekine yakın çıksın. Maskelenmiş veride her müşteri aynı şehirdeyse indeks davranışı üretimdekine benzemez.

Bir de gözden kaçan kısım var: ad ve soyadı silmek kimliksizleştirmek değildir. Narayanan ve Shmatikov'un 2008'de IEEE Güvenlik ve Gizlilik Sempozyumu'nda sunduğu çalışma, Netflix'in "anonim" yarışma veri setindeki abonelerin dışarıdan bulunabilen IMDb puanlarıyla eşleştirilerek teşhis edilebildiğini gösterdi. Doğum tarihi, posta kodu ve sipariş geçmişi gibi dolaylı tanımlayıcıların birleşimi tek başına yeter. En riskli alan da genelde serbest metin kolonlarıdır: destek kaydı açıklaması, sipariş notu, iptal gerekçesi. Oralarda ad, telefon ve hesap numarası düz metin olarak durur ve kolon adında "isim" geçmediği için maskeleme betiğine hiç girmez.

Takma adlaştırma ile anonimleştirmeyi de karıştırmamak gerekiyor. Avrupa Veri Koruma Kurulu'nun Ocak 2025'te kabul ettiği 01/2025 sayılı rehber bu ayrımı netleştiriyor: geri döndürülebilir bir eşleme tablosu duruyorsa veri hâlâ kişisel veridir, koruma yükümlülüğü sürer. Türkiye'deki mevzuat tarafı ayrı bir konu, teknik karar bundan bağımsız verilmeli ve verinin kendisi baştan küçültülmeli.

Alt küme almak: 2 TB yerine 20 GB

Tam kopya almanın maliyeti sadece risk değil, zaman. 2 TB'lık bir veritabanını her ortam için geri yüklemek saatler alır, maskeleme betiği o boyutta gece boyu çalışır, hiçbir geliştirici o kopyayı kendi makinesine indiremez.

Alt küme alma, ilişkisel bütünlüğü koruyarak dikey bir kesit çıkarmak demek. Bir çapa tablo seçersiniz, mesela son 90 günün siparişleri, sonra yabancı anahtarları izleyerek bağlı tüm kayıtları toplarsınız. İki tuzağı var. Birincisi, parametre ve sözlük tabloları (ülke, para birimi, vergi oranı, ürün kategorisi) her zaman tam alınmalı, kesit içinde aranmamalı. İkincisi, kesitin içine bilinçli olarak "zor" kayıtlar konmalı: iade edilmiş sipariş, kısmi ödeme, çok satırlı fatura, iptal edilmiş abonelik. Rastgele seçilen 90 gün bunların hepsini içermez.

Doğru yapıldığında ortam kurulumu dakikalara iner. Bu da sürekli entegrasyon hattında her dal için tek kullanımlık ortam açmayı mümkün kılar, ki test verisi meselesinin asıl çözümü odur.

Sentetik veri nerede işe yarar, nerede yaramaz

Sentetik veri, maskelenmiş verinin sağlayamadığı iki şeyi sağlar. Birincisi uç durumlar: negatif stok, 40 karakterlik isim, 29 Şubat, emoji içeren adres, sağdan sola yazılan alfabe, kuruş yuvarlamasında sıkışan tutar. Bunlar üretim verisinde ya hiç yoktur ya da bir tane vardır ve alt kümeye düşmez. İkincisi hacim: yük testi için 50 milyon satır gerekiyorsa onu üretimden almak zorunda değilsiniz.

Yapamadığı şey de net: on yıllık bir sistemin biriktirdiği tarihsel bozukluğu taklit edemez. O yüzden üçünü birden kullanan ekipler kazanıyor. Perforce anketinde katılımcıların yüzde 86'sı statik maskeleme, yüzde 60'ı dinamik maskeleme, yüzde 51'i sentetik veri kullandığını söylüyor. Toplam yüzde 100'ü aşıyor çünkü bu bir seçim değil, katman meselesi.

Asıl kaza e-posta kutusunda olur

Maskeleme yaptınız diyelim. Test ortamı yine de gerçek SMTP sunucusuna bağlıysa ve maskelenmiş e-posta adresleri bir şekilde gerçek adreslere benziyorsa, gece çalışan bir betik müşterilere "siparişiniz kargoya verildi" yazar. Bu tarz olaylar veri sızıntısından daha sık yaşanıyor ve daha görünür oluyor.

Aynı risk dış entegrasyonların hepsinde var: e-fatura sağlayıcısında gerçek belge kesilmesi, kargo API'sinde gerçek gönderi açılması, ödeme sağlayıcısında gerçek çekim denenmesi, SMS sağlayıcısında gerçek mesaj gitmesi. Alınacak önlemler teknik olarak ucuz:

• Giden postayı yakalayan bir sunucu kullanın, üretim dışı ortamlarda SMTP hiçbir zaman dışarı çıkmasın.
• Zorunluysa alıcı izin listesi koyun; sadece kendi alan adınıza gönderim yapılsın.
• Her sağlayıcının test ortamı anahtarlarını kullanın, üretim anahtarları üretim dışı ortamlarda hiç bulunmasın.
• Giden ağ trafiğinde varsayılanı reddet yapın, üçüncü taraf adreslerini tek tek açın.

Bu dört madde, üretim verisini maskelemekten daha kısa sürer ve ilk gün faydasını verir.

Ortam ayrımının yazılı hali

ISO/IEC 27002:2022'nin 8.33 numaralı kontrolü test bilgisini ayrı bir başlık olarak ele alıyor ve dört şey istiyor: test ortamlarına üretimle aynı erişim kontrolünün uygulanması, üretim verisi her kopyalandığında ayrı bir yetkilendirme alınması, kopyalama ve kullanımın kayda geçmesi, test bittiğinde verinin silinmesi. "Her kopyalamada ayrı yetkilendirme" maddesi pratikte en çok atlanan kısım, çünkü kopya alma işi genelde kimsenin onayına takılmadan bir komutla yapılıyor.

Kart verisi işleyen sistemlerde kural daha keskin. PCI DSS v4.0'ın 6.5.5 maddesi canlı kart numaralarının üretim öncesi ortamlarda kullanılmasını yasaklıyor; tek istisna o ortamın kart verisi ortamı kapsamına alınıp tüm gerekliliklerle korunması, ki bu da çoğu ekibin istemeyeceği bir maliyet.

Staging'i internete açık bırakmak

Maskelenmiş veri bile korumasız bir sunucuda durmamalı. Üretim dışı ortamlarda uygulanması gereken asgari set kısa: kimlik doğrulama olmadan erişilememesi, arama motorlarına kapatılması, ayrı bir alan adında durması, üretimden gelen yönetici hesaplarının yükleme sonrası sıfırlanması, ortamın bir sahibinin ve son kullanma tarihinin olması.

Avustralya düzenleyicisinin Optus davasında mahkemeye sunduğu iddianame bu son maddenin neden önemli olduğunu gösteriyor. İddiaya göre bir erişim kontrolü kod hatası 2018'de yayına alınmış, uç nokta 2020'de internete açık hale gelmiş ve hata 2022'deki ihlale kadar birkaç gözden geçirmede fark edilmemiş. Sahibi olmayan bir uç nokta yıllarca fark edilmiyor, bu da envanterin neden bir güvenlik kontrolü sayıldığını açıklıyor.

Nereden başlanır

Sıfırdan bir test verisi platformu kurmaya çalışmayın, üç hafta içinde biten bir sıra izleyin.

1. Envanter çıkarın. Üretim verisinin kopyası hangi ortamlarda var? Demo sunucusu, analitik kopya, eski bir yedek dosyası ve geliştirici makinelerindeki dump'lar dahil.
2. Hassas kolonları işaretleyin. Kolon adına bakarak değil, örnek satır okuyarak. Serbest metin alanlarını ayrı bir başlık yapın.
3. Tek bir maskeleme işi yazın. Ürün satın almadan önce bir betik yeter. Gece çalışsın, çıktısı tek bir temizlenmiş dump olsun.
4. Maskelemeyi doğrulayın. Hassas kolonlarda üretimle birebir eşleşen değer kaldı mı, yabancı anahtarlar tutuyor mu, unique kısıtlar geçiyor mu? Bu kontroller otomatik çalışmalı, yoksa ilk şema değişikliğinde sessizce bozulur.
5. Dış çağrıları kesin. Posta yakalayıcı, sandbox anahtarları, giden trafikte varsayılan reddet.
6. Kural koyun. Üretimden her kopya alımında yazılı onay, kayıt ve son kullanma tarihi. Kopya süresiz durmasın.

Bu hafta atabileceğiniz adım

Test ortamınızın veritabanına bağlanın ve müşteri tablosundan rastgele on satır çekin. Gerçek bir insanın adı, e-postası ve telefonu ekrana geliyorsa sorunuzun cevabı var. Sonra staging üzerinden kendinize bir sipariş oluşturun ve gerçekten dışarıya e-posta çıkıp çıkmadığına bakın. İki kontrol yarım saat sürüyor ve genelde ikisi de beklenmedik sonuç veriyor.