Maskeleme ile şifreleme arasındaki fark ne?

Şifreleme bir anahtarla geri döndürülebilir ve veriyi beklerken ya da aktarılırken korur. Maskeleme bilinçli olarak tek yönlüdür ve veriyi kullanım anında korur — maskelenmiş bir değer aslına döndürülemez, gerçeğini görmemesi gereken birine göstermeyi güvenli kılan da tam olarak budur.

Maskeleme sonuçlar saklanmadan önce mi sonra mı yapılmalı?

Önce. Sonuçlar diske maskesiz yazılıp yalnızca görüntülenirken maskeleniyorsa, depolamada, yedeklerde ve o dosyayı okuyan her şeyde maskesiz bir kopya bulunur. Maskelemenin sonuç akışının içinde yapılması, maskesiz sürümün sonuç deposuna hiç yazılmaması demektir.

Maskeleme sonuçları hata ayıklama için işe yaramaz hâle getirir mi?

Genellikle hayır, çünkü hata ayıklama çoğunlukla değerlere değil verinin biçimine ihtiyaç duyar — hangi satırlar var, hangi alanlar boş, kayıtlar birbiriyle nasıl ilişkili. Maskeleme bu yapıyı korur. Bir mühendisin gerçekten gerçek bir değere ihtiyacı olduğunda, bu varsayılan değil açık bir karar hak eden bir taleptir.

Dinamik veri maskeleme nedir?

Dinamik veri maskeleme, saklanan veriye dokunmadan bir sorgu sonucundaki hassas değerleri gizler. Satır yine döner; içindeki kişisel veri dönmez. Bir e-posta kolonu a***@***.com, 16 haneli bir kart numarası ise QueryProxy’nin partial stratejisiyle 4********2 (ilk ve son karakter korunur) olarak döner ve geliştirici veriyi almadan verinin biçimini görür.

İşi yapan kelime dinamik. Veritabanında hiçbir şey değişmez. Dönüşüm, sorgu başına, çıkış yolunda gerçekleşir.

Sızıntı neden sonuçlarda

Erişim denetimi genellikle “bu kişi bu tabloyu okuyabilir mi?” sorusunda durur ve doğru yetkilendirilmiş bir okuma, kişisel verinin bir şirketten çıkmasının en yaygın yoludur. Kimse içeri girmez. Meşru gerekçesi olan bir mühendis meşru bir sorgu çalıştırır ve on bin gerçek e-posta adresi bir terminale, bir terminal geçmişine, bir CSV dosyasına ve nihayetinde bir sohbet başlığına düşer.

İki tür kural

Kolon desenleri ada bakar: email, phone, ssn, credit_card. Ucuz, öngörülebilir ve denetlemesi kolaydır; ama contact_1 adlı bir kolona karşı kördür — ve gördüğü ad, sorguyu yazanın seçtiği çıktı adıdır: SELECT api_key AS k en sert kolon kuralını bile atlatır.

İçerik regexleri değere bakar ve bir e-posta adresini nerede geçerse yakalar — kimsenin bakmayı düşünmediği serbest metinli bir notes alanının içinde bile. Erişimi daha geniştir, maliyeti daha yüksektir ve yanlış pozitif riski gerçektir. İçerik kurallarının her skaler değeri görmesi de önemlidir: sürücü sayısal kolonları metin olarak döndürmediği için, yalnızca string’lere bakan bir kural BIGINT saklanan bir kart numarasını sessizce atlar.

Hiçbiri tek başına yeterli değildir. Kolon kuralları tasarladığınız şemayı, içerik kuralları ise elinizdeki gerçek şemayı kapsar.

Yazım anında maskeleme

Maskelemenin gerçek olup olmadığına karar veren ayrıntı budur.

Sonuçlar maskesiz saklanıp görüntülenirken maskeleniyorsa, maskesiz bir kopya vardır — depolamada, yedeklerde, o dosyayı okuyan her şeyde. Maske bir görüntüleme tercihidir ve altındaki her katman gerçeğini tutar.

Maskeleme sonuç akışının içinde, satırlar yazılmadan önce çalışıyorsa maskesiz sürüm, eşleşen bir değer için sonuç deposuna hiç yazılmaz. Depodan sonradan sızdırılacak bir şey yoktur çünkü orada hiçbir şey saklanmamıştır. Maskeleme bir kural eşleştiğinde uygulanır: hiçbir kuralın kapsamadığı kolon ya da değer olduğu gibi döner.

QueryProxy, satırlar imleçten depolamaya akarken yazım anında maskeler.

Maskelemenin yanlış araç olduğu durumlar

Gerçek değer gereksinimin kendisiyse. Tek bir müşterinin bozuk kaydını ayıklamak o kaydı gerektirir. Cevap, herkes için varsayılanı zayıflatmak değil, açık ve denetlenen bir istisnadır.

Erişim denetiminin yerine geçmesi beklendiğinde. Maskeleme, izin verilmiş bir sorgunun ne döndüreceğini sınırlar. Kimin sorgu çalıştırabileceği hakkında söyleyecek hiçbir şeyi yoktur.

Maskelenmiş çıktı üzerinde analitik yaparken. Maskelenmiş veri bilinçli olarak kayıplıdır. Üzerinde toplama yaparsanız kendinden emin ama yanlış cevaplar alırsınız.

Devamı

Kural yapılandırması ve QueryProxy’nin sunduğu üç strateji için veri maskeleme dokümantasyonuna bakın. Maskelemenin onaylarla nasıl birleştiği için veritabanı erişim denetiminin ne olduğunu okuyun. Motora özgü notlar PostgreSQL ile MySQL ve MariaDB sayfalarında. Maskelemenin kişisel verilerle ve kart numaralarıyla ilişkisi için KVKK ve veritabanı erişim denetimi, GDPR ve veritabanı erişimi ve PCI DSS ve veritabanı erişim denetimi sayfalarına bakın.

Sık sorulanlar

Dinamik veri maskeleme nedir?: Dinamik veri maskeleme, saklanan veriye dokunmadan sorgu sonucundaki hassas değerleri gizlenmiş değerlerle değiştirir. Bir e-posta kolonu a***@***.com olarak dönebilir; böylece satır hata ayıklamak için kullanışlı kalır ama kişisel veri onunla birlikte dışarı çıkmaz.
Maskeleme ile şifreleme arasındaki fark ne?: Şifreleme bir anahtarla geri döndürülebilir ve veriyi beklerken ya da aktarılırken korur. Maskeleme bilinçli olarak tek yönlüdür ve veriyi kullanım anında korur — maskelenmiş bir değer aslına döndürülemez, gerçeğini görmemesi gereken birine göstermeyi güvenli kılan da tam olarak budur.
Maskeleme sonuçlar saklanmadan önce mi sonra mı yapılmalı?: Önce. Sonuçlar diske maskesiz yazılıp yalnızca görüntülenirken maskeleniyorsa, depolamada, yedeklerde ve o dosyayı okuyan her şeyde maskesiz bir kopya bulunur. Maskelemenin sonuç akışının içinde yapılması, maskesiz sürümün sonuç deposuna hiç yazılmaması demektir.
Maskeleme sonuçları hata ayıklama için işe yaramaz hâle getirir mi?: Genellikle hayır, çünkü hata ayıklama çoğunlukla değerlere değil verinin biçimine ihtiyaç duyar — hangi satırlar var, hangi alanlar boş, kayıtlar birbiriyle nasıl ilişkili. Maskeleme bu yapıyı korur. Bir mühendisin gerçekten gerçek bir değere ihtiyacı olduğunda, bu varsayılan değil açık bir karar hak eden bir taleptir.