# Dynamic Data Masking ve Column Encryption Değişiklikleri Nasıl Yönetilmeli?

Veri maskeleme ve kolon şifrelemesi güvenlik mimarisinin önemli parçaları. Ama bu yapılandırmalardaki değişiklikler çoğunlukla değişiklik yönetiminin dışında kalıyor.

Dynamic Data Masking (DDM) Nedir? DDM, yetkisiz kullanıcılara hassas verileri maskelenmiş biçimde gösterir. Gerçek veri veritabanında olduğu gibi durur ama yetkisi olmayan kullanıcı maskelenmiş versiyonu görür. sql-- E-posta kolonuna maskeleme ekle ALTER TABLE Musteriler ALTER COLUMN Email ADD MASKED WITH (FUNCTION = 'email()');

\-- Kredi kartı numarasına kısmi maskeleme ALTER TABLE Odemeler ALTER COLUMN KrediKartiNo ADD MASKED WITH (FUNCTION = 'partial(0,"XXXX-XXXX-XXXX-",4)'); Basit görünüyor. Ama bu değişiklik kimin ne gördüğünü doğrudan etkiliyor.

DDM Değişikliğinin Riski Maskeleme kaldırıldı Biri maskelemeyi geçici olarak kaldırdı, test edecekti. Geri eklemeyi unuttu. Artık yetkisiz kullanıcılar gerçek veriyi görüyor. Kim fark eder? Yanlış kullanıcıya unmask yetkisi sqlGRANT UNMASK TO KullaniciAdi; Bu satır bir kullanıcıya tüm maskelenmiş verileri açık görme yetkisi veriyor. Yanlış kişiye verilmesi ciddi gizlilik ihlali. Maskeleme fonksiyonu değiştirildi Kısmi maskeleme yerini tam maskelemeyle değiştirildi ya da tam tersi. Bunu kullanan raporlar bozuldu.

Always Encrypted DDM'den daha güçlü bir yöntem: Always Encrypted. Veri veritabanı motoruna bile şifreli görünür, sadece istemci tarafındaki anahtar sahibi açık veriyi görebilir. sql-- Always Encrypted ile kolon oluşturma örneği CREATE TABLE HassasVeriler ( ID INT PRIMARY KEY, TcKimlikNo NVARCHAR(11) ENCRYPTED WITH ( COLUMN\_ENCRYPTION\_KEY = MyCEK, ENCRYPTION\_TYPE = Deterministic, ALGORITHM = 'AEAD\_AES\_256\_CBC\_HMAC\_SHA\_256' ) ); Always Encrypted yapılandırması değiştirilmek istendiğinde etki çok daha büyük. Bu yapılandırma hem veritabanı hem uygulama katmanını etkiliyor.

Bu Değişiklikleri Değişiklik Sürecine Dahil Etmek DDM ve Always Encrypted değişiklikleri için ek bir onay katmanı olmalı: güvenlik ekibi. Teknik doğruluk DBA tarafından onaylanır. Ama "bu maskelemenin kaldırılması güvenlik açısından kabul edilebilir mi" sorusu güvenlik ekibinin alanı. Bu iki onay mekanizması birlikte çalıştığında ne teknik ne de güvenlik açısından göz ardı edilen değişiklik kalmaz.

Periyodik Maskeleme Denetimi sql-- Maskelenmiş kolonları listele SELECT t.name AS TabloAdi, c.name AS KolonAdi, c.masking\_function AS MaskelemeFonksiyonu FROM sys.masked\_columns c JOIN sys.tables t ON c.object\_id = t.object\_id ORDER BY t.name, c.name; Bu sorgunun çıktısı beklenen maskeleme yapılandırmasıyla karşılaştırılmalı. Beklenmedik bir değişiklik varsa kim yaptı sorusu sorulmalı.

Sonuç Veri maskeleme ve şifreleme yapılandırmaları görünmez ama kritik güvenlik kontrolleri. Değişiklik yönetimine dahil edilmediğinde sessiz güvenlik açıkları oluşur. Detaylı bilgi için: sqlchangeguard.com