Hangi Kolon Maskelenecek? Maskeleme Kararı Nasıl Verilir

Üretim verisinin maskelenmesi gerektiği konusunda kimse tartışmaz. Tartışma bir adım önce başlar ve çoğu kurum orada takılır: bir sorgu sonucundaki hangi kolonun maskeleneceğine kim, neye bakarak karar veriyor?

Asıl Soru Maskelemek Değil, Bilmek

Maskeleme teknik olarak kolaydır: değeri yıldızla değiştirirsiniz. Zor olan, hangi değerin değiştirileceğine karar vermektir. İki yaygın yaklaşım da tek başına yetersizdir.

Birincisi elle listedir: hassas kolonların adı bir yere yazılır ve o liste uygulanır. Sorgu SELECT * ile yazıldığında ya da bir kolon alias ile başka bir adla döndüğünde liste tutmaz. Yeni bir tablo eklendiğinde de kimse listeyi güncellemeyi hatırlamaz.

İkincisi her şeyi maskelemektir. Güvenlidir ama sonucu kullanılamaz hale getirir; ekipler bu yüzden maskelemeyi tamamen kapatmanın yollarını arar. Aşırı sıkı bir kontrol, uygulanmayan bir kontrole dönüşür.

İki Eksen: Kolonun Adı ve İçindeki Veri

Çalışan model iki bağımsız sinyali birleştirir. Birincisi sınıflandırma kataloğu: kolonun adı bilinen bir hassas alanla eşleşiyor mu (tckn, iban, telefon, eposta, ad, soyad). İkincisi veri deseni: kolonun içindeki değerler hassas bir biçime uyuyor mu.

İkisi de tek başına yanılır ve farklı yönlerde yanılır. Ad yalan söyler: kolon col1 ya da data3 olabilir, ya da tam tersine musteri_adi adlı bir kolonda ürün adı durabilir. İçerik de yalan söyler: kolon boş olabilir, ya da o gün örneklenen satırlar tesadüfen sentetik olabilir.

İki sinyalin birlikte kullanılması, birinin yanıldığı yerde diğerinin yakalamasını sağlar. Ad tanınmadığında içerik devreye girer; içerik belirsiz olduğunda ad karar verir.

Desen Yetmez, Doğrulayıcı Gerekir

Veri desenini yalnız düzenli ifadeyle kurmak çok sayıda yanlış pozitif üretir. On bir haneli her sayı TC kimlik numarası değildir; sipariş numarası da olabilir, barkod da. On altı haneli her sayı kart numarası değildir.

Çözüm, desenin üstüne bir doğrulayıcı koymaktır: değerin kendi içinde taşıdığı kontrol basamağını hesaplamak. Bu hesap matematikseldir ve tahmine yer bırakmaz.

Doğrulayıcı olmayan alanlar da vardır: ad, adres, teşhis kodu gibi. Bunlarda desen ve kolon adı birlikte çalışır, matematiksel kesinlik yoktur. Bu sınırı bilmek önemlidir; sistemin neyi kesin bildiği ile neyi tahmin ettiği ayrılmalıdır.

Örnekleme ve Eşik: Kaç Satıra Bakmalı

İçerik kontrolü her satırı taramaz; tarasaydı büyük sonuç kümelerinde teslim süresi kabul edilemez olurdu. Bunun yerine bir örneklem alınır ve bir eşik uygulanır.

Pratikte üç ayar vardır. Örneklem büyüklüğü kaç satıra bakılacağını söyler; makul bir başlangıç bin satırdır. Eşik yüzdesi kolonun hassas sayılması için örneklemin ne kadarının desene uyması gerektiğini söyler; yüzde yirmi dengeli bir başlangıçtır. Örnekleme biçimi ilk N satırın mı yoksa rastgele satırların mı alınacağını belirler.

Eşiği düşürmek daha çok kolonu maskeler ve yanlış pozitifi artırır; yükseltmek gerçek hassas kolonu kaçırma riskini artırır. Doğru değer kurumun veri yapısına bağlıdır, ama bir kural işe yarar: eşiği ayarlarken hata yönünü seçin. Üretim verisinde fazladan maskelemek, eksik maskelemekten daha ucuzdur.

Maskeleme Akışın Değil Verinin Özelliğidir

Bu ayrım tasarımın en önemli kararıdır. Maskeleme kuralı onay akışına bağlanırsa, aynı talep üretim ve test sunucusuna birlikte gittiğinde tek bir karar verilir ve o karar iki ortam için de yanlış olur.

Doğru yer sunucu tanımıdır. Her sunucunun kendi maskeleme rejimi olur ve karar sunucu başına ayrı verilir. İki rejim pratikte yeterlidir:

• Katı rejim: sınıflandırma kataloğu ve veri desenleri birlikte çalışır. Üretim için varsayılan budur.
• Yalnız içerik rejimi: kolon adına bakılmaz, yalnız veri desenlerine bakılır. Sentetik veri barındıran ortamlarda gürültüyü bitirir.

Yalnız içerik rejiminin güzel bir özelliği vardır: kendini doğrular. Test sunucusuna bir gün gerçek veri yüklenirse, doğrulayıcılı desenler devreye girer ve maskeleme kendiliğinden geri gelir. Kimsenin bir ayarı hatırlaması gerekmez. Kabul edilen kayıp ise açıktır ve yazılmalıdır: deseni olmayan alanlar (ad, adres, teşhis) o ortamda açık gider.

Katı rejim dışındaki her rejim yazılı bir gerekçe istemelidir. "Bu sunucuda neden gevşetildi" sorusunun cevabı, gevşetildiği anda kayda girmelidir; denetim sırasında hatırlanarak yazılamaz.

Maskesiz İstemek: Gerekçe ve İkinci Onay

Maskeli veri her zaman yetmez. Bir müşteri şikayetini incelerken gerçek IBAN'ı görmek gerekebilir. Bu ihtiyacı reddeden bir sistem, ekibi maskelemeyi tamamen atlatmaya iter.

Doğru tasarım istisnayı yasaklamaz, pahalılaştırır ve görünür kılar. Maskesiz kolon isteyen kişi gerekçe yazar, talep ayrı bir onaydan geçer ve hangi kolonun kimin onayıyla maskesiz gittiği kayda girer. Böylece istisna bir kaçamak değil, sayılabilir bir olay olur. Yılda kaç kez maskesiz veri çıktığı ölçülebilir bir sayıya dönüşür.

Bir ayrıntı daha: teslim anındaki rejim kayda dondurulmalıdır. Sunucu sonradan katı rejime çevrilse bile, o gün verinin nasıl teslim edildiği değişmemelidir. Aksi halde geçmiş bir teslimatın kaydı, bugünkü ayarla yeniden yorumlanır ve kanıt olmaktan çıkar.

Sık Sorulan Sorular

Tam maskeleme mi kısmi maskeleme mi kullanmalıyız?

Kullanım amacına bağlıdır. Kısmi maskeleme değerin son birkaç karakterini bırakır ve kayıt eşleştirmeye izin verir: destek ekibi müşterinin "kartımın son dört hanesi" dediği bilgiyle kaydı bulabilir. Tam maskeleme daha güvenlidir ama sonucu ayırt edilemez hale getirir. Kimlik ve teşhis gibi alanlarda tam, kart ve telefon gibi alanlarda kısmi maskeleme yaygın bir dengedir.

Kolon takma adla (alias) dönerse maskeleme kaçar mı?

Yalnız kolon adına bakan bir sistemde kaçar, ve bu en sık görülen açıktır. İçerik kontrolü bu boşluğu kapatır: değer hangi adla dönerse dönsün deseni ve kontrol basamağı aynıdır. İki eksenin birlikte kullanılmasının en somut faydası budur.

Maskeleme sorgu sonucunu yavaşlatır mı?

İçerik kontrolü örneklem üzerinde çalıştığı için maliyeti sonuç kümesinin tamamıyla değil örneklem büyüklüğüyle orantılıdır. Bir zaman bütçesi tanımlamak da işe yarar: kontrol bütçeyi aşarsa güvenli tarafta durulur ve kolon hassas kabul edilir. Performans kaygısı, maskelemeyi kapatmanın gerekçesi olmamalıdır.

Sorgu çalıştırılmadan hangi kolonların geleceği bilinebilir mi?

Bilinebilir. Sorgunun sonuç kolonları, sorgu çalıştırılmadan ve tek satır veri okunmadan sunucudan alınabilir. Bu, talebi açan kişinin daha kaydetme anında "şu kolonlar maskelenecek" bilgisini görmesini sağlar. Sürpriz, teslimden sonra değil kaydetmeden önce ortadan kalkar.