Dynamic Data Masking ve Column Encryption Değişiklikleri Nasıl Yönetilmeli?
I’m a passionate software engineer specializing in SQL change management, database security, and DevOps automation. With over 17 years of experience in the banking sector, I focus on building tools and processes that make database deployments safer, more auditable, and automated.
As the creator of SQL Change Guard, I develop solutions that use risk scoring and AI-powered code analysis to detect dangerous SQL scripts before they reach production. I’m dedicated to helping teams minimize downtime and data loss through smarter change governance.
When I’m not coding, I enjoy sharing insights about secure development practices, WPF desktop applications, and integrating modern CI/CD pipelines.
Feel free to connect or reach out at info@sqlchangeguard.com
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