Dinamik Veri Maskeleme (DDM) Denetçiye Ne Söylemez?

"Kimlik numarası kolonunda maskeleme var" cümlesi denetim toplantılarında sık duyulur ve genellikle SQL Server'ın dinamik veri maskelemesini (Dynamic Data Masking, DDM) kasteder. DDM kullanışlı bir özelliktir. Ama denetçinin sorusu "ekranda yıldız görünüyor mu" değil, "hassas veri kimin eline geçti ve bunu nereden biliyorsunuz" sorusudur. Bu yazı DDM'nin neyi koruduğunu, nerede yetmediğini ve veri üretimden dışarı çıkarken hangi kontrolün gerektiğini örnek sorgularla anlatır.

Dinamik Veri Maskeleme Nasıl Çalışır

DDM, SQL Server 2016 ile geldi. Kolona bir maske fonksiyonu tanımlanır; veri diskte değişmez, yalnız sorgu sonucunda yetkisi olmayan kullanıcıya maskeli döner. Hazır fonksiyonlar default(), email(), random() ve partial()dır; SQL Server 2022 tarihler için datetime() ekledi.

ALTER TABLE dbo.Customer
  ALTER COLUMN NationalId ADD MASKED WITH (FUNCTION = 'partial(0,"*******",4)');

-- A user without UNMASK permission:
SELECT CustomerId, NationalId FROM dbo.Customer WHERE CustomerId = 42;
-- 42 | *******4521

Sınır 1: Koşul Gerçek Değerle Çalışır

Maske yalnız sonuca uygulanır; WHERE koşulu gerçek değer üzerinde çalışır. Bu, sorgu yazabilen bir kullanıcının değeri tahmin ederek bulabileceği anlamına gelir. Microsoft'un kendi belgesi de DDM'nin bu tür çıkarımı önlemek için tasarlanmadığını açıkça yazar.

-- Masked in the result, but the predicate sees the real value:
SELECT COUNT(*) FROM dbo.Customer
WHERE CustomerId = 42 AND NationalId LIKE '1%';   -- 1 or 0

-- Repeating this digit by digit reveals the full value.
SELECT CustomerId FROM dbo.Employee WHERE Salary > 150000;  -- masked column, real filter

Bu yüzden DDM, sorgu yazamayan kullanıcıya hazır ekran sunan bir uygulamada iyi çalışır; serbest sorgu yazabilen bir kullanıcıya karşı ise yalnız bir kolaylıktır, güvenlik sınırı değildir.

Sınır 2: Yetkili Kullanıcı Maskesiz Görür

Maskeyi UNMASK izni kaldırır. Veritabanında CONTROL yetkisi olanlar, yani db_owner üyeleri ve sistem yöneticileri bu izne kendiliğinden sahiptir. Üretim verisine en çok erişen kişiler, veritabanı yöneticileri, maskeyi hiç görmez. SQL Server 2022 öncesinde UNMASK veritabanı genelinde verilirdi; 2022 ile şema, tablo ve kolon düzeyinde verilebilir:

GRANT UNMASK ON dbo.Customer(NationalId) TO SupportAnalyst;   -- SQL Server 2022+

Bir ayrıntı daha: maskeli kolonu okuyan kullanıcı SELECT INTO ya da INSERT INTO ... SELECT ile veriyi başka bir tabloya kopyalarsa, yeni tabloya maskeli değer yazılır. Bu iyi bir davranıştır, ama yetkili kullanıcının yaptığı kopya maskesiz olur ve o kopyanın nereye gittiğini DDM bilmez.

Sınır 3: Kayıt Tutmaz

DDM bir görüntüleme kuralıdır, bir kayıt mekanizması değildir. Kimin maskesiz değeri gördüğünü, hangi sorguyu çalıştırdığını ya da sonucu nereye kaydettiğini tutmaz. Bu sorular için ayrıca SQL Server Audit ile hassas tablolardaki SELECT ifadeleri kaydedilmelidir. Denetçinin "bu kolonu son üç ayda kim maskesiz gördü" sorusuna DDM tek başına cevap veremez.

Veri Dışarı Çıkarken: Teslim Maskelemesi

Üretim verisi en çok bir sorgu sonucu olarak dışarı çıkar: bir analist, bir destek ekibi ya da bir denetim çalışması için. Bu noktada soru değişir: veri kimin istediğiyle, hangi gerekçeyle ve hangi kolonları açık olarak kime gitti? Burada gereken, maskelemenin teslim edilen dosyanın içinde yapılması ve her kararın kayda geçmesidir.

SQL Change Guard'da üretimden veri bir veri talebiyle çıkar ve şu adımlardan geçer:

• İki dedektör. Kolon adı kataloğu adı hassas olan kolonu (örneğin TCKN, Iban) veriye bakmadan yakalar. İçerik desenleri sonuçtan alınan örneklemde değerin kendisine bakar; kimlik numarası, vergi numarası, kart numarası ve IBAN için sağlama algoritması çalışır, böylece rastgele bir sayı yanlışlıkla hassas sayılmaz.
• Süre dolarsa maskelenir. İçerik tespitinin süre bütçesi dolarsa incelenemeyen kolonlar açık bırakılmaz, maskelenir.
• Maskesiz kolon gerekçe ister. Bir kolonun açık gitmesi istenirse gerekçe yazılır ve kurulum varsayılanında ek bir onay adımı açılır.
• Her kolonun kararı kayda geçer. Maskelenen kolon hangi kurala göre maskelendiğiyle, maskelenmeyen kolon da gerekçesiyle (örneklemde hassas değer bulunmadı, veri yok gibi) yazılır. Talep kaydedilirken planlanan karar ile teslimdeki karar farklıysa denetim dosyası bunu istisna olarak gösterir.
• Dosya şifreli gider, indirme kayda geçer. Sonuç ekranda gösterilmez; parolalı, şifreli bir paket olarak teslim edilir. Dosyayı kimin, hangi gerekçeyle indirdiği yazılır ve dosya saklama süresi sonunda silinir.

Sınırı da açık söyleyelim: bu adımlar yalnız ürün üzerinden açılan veri talepleri için geçerlidir. Bir kullanıcı SQL Server Management Studio ile doğrudan bağlanıp sorgu çalıştırırsa ürün onu görmez ve maskelemez; o yolda DDM, SQL Server Audit ve doğrudan erişim yetkisinin daraltılması geçerlidir.

Hangisi Ne Zaman

Sık Sorulan Sorular

DDM veriyi şifreler mi?

Hayır. Veri diskte, yedekte ve işlem günlüğünde açık durur. Şifreleme için Always Encrypted ya da Transparent Data Encryption gibi ayrı özellikler gerekir; her biri farklı bir tehdide karşıdır.

PostgreSQL ve Oracle'da DDM var mı?

PostgreSQL'in çekirdeğinde yoktur; postgresql_anonymizer gibi eklentiler dinamik maskeleme sağlar. Oracle'da aynı işi Data Redaction yapar ve Advanced Security seçeneğinin parçasıdır, ayrıca lisanslanır.

Hedef kolonda DDM varsa ürünün maskelemesiyle ne olur?

Ürünün hedefte kullandığı SQL hesabının UNMASK izni yoksa sonuç ürüne zaten DDM maskesiyle gelir ve ürünün maskelemesi bunun üzerine uygulanır. İzni varsa değerler açık gelir ve teslimdeki maskeleme kararı ürünün kendi kurallarıyla verilir.

Maskeleme kararlarını denetçiye nasıl gösteririm?

Ürün üzerinden açılan her veri talebinin denetim dosyasında her kolonun kararı ve gerekçesi bulunur. Dönem görünümü için "Query Result Activity" raporu teslim edilen sonuçları ve maskeleme kararını, "Data Access and Export Log" raporu ise dosyayı kimin hangi gerekçeyle indirdiğini listeler.