SQL Server 2016 ve sonrası olan sürümlerinde veri maskeleme tekniklerini, özellikle Dinamik Veri Maskeleme (DDM) özelliğini derinlemesine incelemektedir. Rapor, DDM'nin temellerini, uygulama yöntemlerini, izin yönetimini, gelişmiş senaryoları, sınırlamalarını ve en iyi uygulamalarını kapsamaktadır.
1. SQL Server'da Veri Maskelemeye Giriş
Veri maskeleme, hassas verilerin yetkisiz kullanıcılar için okunamaz hale getirilmesi işlemidir. Bu bölümde, SQL Server bağlamında Dinamik Veri Maskeleme'nin (DDM) ne olduğu, Statik Veri Maskeleme'den (SDM) farkları ve özellik kullanılabilirliği incelenecektir.
-- MASK'lı kolonları bulmak için;
SELECT tbl.name as table_name, c.name AS column_name, c.is_masked, c.masking_function
FROM sys.masked_columns AS c
JOIN sys.tables AS tbl
ON c.object_id = tbl.object_id
WHERE is_masked = 1;1.1. Dinamik Veri Maskeleme (DDM): Amaç, Temel Faydalar ve Çalışma Mekanizması
Dinamik Veri Maskeleme (DDM), yetkisiz erişimi önlemeye yardımcı olan, müşterilerin hassas verilerin ne kadarının gösterileceğini uygulama katmanında minimum etkiyle belirlemesini sağlayan ilke tabanlı bir güvenlik özelliğidir.
DDM'nin temel amacı, hassas verilerin yetkisiz kullanıcılar tarafından görüntülenmesini engelleyerek veri maruziyetini sınırlamaktır. Veritabanındaki gerçek veriler değiştirilmez; maskeleme, sorgu sonuç kümesinde belirlenen veritabanı alanları üzerinde anlık olarak uygulanır. Bu yaklaşım, veritabanında maskeleme mantığını merkezileştirerek güvenlik tasarımını büyük ölçüde basitleştirir.
DDM'nin temel faydaları şunlardır:
● Hassas verilere yetkisiz erişimin önlenmesi: Belirlenen sütunlardaki veriler, yetkisi olmayan kullanıcılara maskelenmiş olarak gösterilir.
● Mevcut uygulamalarla kolay kullanım: Maskeleme kuralları sorgu sonuçlarında uygulandığından, mevcut sorguları değiştirmeden birçok uygulama hassas verileri maskeleyebilir.
● Uygulama katmanında minimum etki: Maskeleme veritabanı düzeyinde gerçekleştiği için uygulama kodunda değişiklik yapma ihtiyacı genellikle ortadan kalkar veya azalır. Bu, DDM'nin benimsenmesinde önemli bir avantajdır çünkü uygulama kodu değişiklikleri maliyetli ve zaman alıcı olabilir. Maskeleme mantığının uygulama içinde olması durumunda, hassas verilere erişen her uygulamanın değiştirilmesi gerekirdi. Veritabanında merkezileştirilmesi, sorgulayan uygulamadan bağımsız olarak maskeleme kurallarının tutarlı bir şekilde uygulanması anlamına gelir, bu da geliştirme yükünü ve tutarsız uygulama riskini azaltır.
● Veri ihlali riskinin azaltılması: Yetkisiz görüntüleyiciler için veri ihlali riskini azaltır.
DDM'nin çalışma mekanizması, sorgu zamanında devreye girer. Bir kullanıcı bir sorgu çalıştırdığında, SQL Server veritabanı motoru, kullanıcının izinlerine bağlı olarak verileri döndürmeden hemen önce belirlenen sütunlara maskeleme kurallarını uygular. Depolamadaki veriler hiçbir şekilde değiştirilmez.
1.2. Dinamik Veri Maskeleme (DDM) ile Statik Veri Maskeleme (SDM) Arasındaki Fark
DDM ve SDM, veri maskelemenin iki farklı yaklaşımıdır ve farklı amaçlara hizmet ederler:
● Dinamik Veri Maskeleme (DDM): Veritabanı içeriğini değiştirmeden gerçek zamanlı olarak hassas değerleri gizler; aktarım halindeki veriler maskelenirken, depodaki orijinal veriler bozulmadan kalır. DDM, özellikle canlı üretim sistemlerindeki verileri korumak için ve genellikle salt okunur senaryolarda kullanılır.
● Statik Veri Maskeleme (SDM): Depodaki verileri değiştirerek hassas verileri kalıcı olarak değiştirir; verilerin temizlenmiş bir kopyasını oluşturur. SDM, öncelikle geliştirme, test ve analiz gibi üretim dışı ortamlar için gerçekçi ancak kurgusal veriler sağlamak amacıyla kullanılır.
Bu iki yöntemi net bir şekilde ayırt etmek hayati önem taşır. DDM, canlı verilerin yetkisiz görüntülenmesinden korunması için tasarlanmışken, SDM diğer amaçlar için güvenli, duyarsızlaştırılmış veri kümeleri oluşturmakla ilgilidir. Bu seçim, güvenlik duruşunu ve veri kullanılabilirliğini doğrudan etkiler. DDM ve SDM arasındaki tercih, veri yaşam döngüsü yönetimi ve farklı ortamlardaki güvenlik açısından derin etkilere sahiptir.
DDM, veri bütünlüğünün çok önemli olduğu ve gerçek zamanlı erişimin (maskeli veya maskesiz) gerektiği üretim ortamları için uygundur. SDM, verileri kalıcı olarak değiştirerek, daha az güvenli ortamlar (geliştirme/test) için daha güvenlidir, çünkü bir ihlal meydana gelse bile hassas veriler mevcut değildir.
Ancak SDM, bu maskelenmiş kopyaları oluşturmak ve yenilemek için kendi ek yüküne sahip bir süreç gerektirir. DDM bu kopyalama sürecini ortadan kaldırır ancak üretimde dikkatli izin yönetimi gerektirir. DDM için "salt okunur" bağlam vurgusu da önemlidir ; DDM, yazma izinlerine sahip kullanıcılar tarafından güncellemeleri engellemese de , birincil tasarım amacı sorgu sonucu gizlemedir.
1.3. DDM Özellik Kullanılabilirliği: SQL Server 2016 ve sonrası olan ve Azure SQL Platformları
Dinamik Veri Maskeleme özelliği, SQL Server 2016 (13.x) ve sonraki sürümlerinde ve Azure SQL Veritabanı'nda mevcuttur. Bu bilgi, kullanıcının sürümlerle ilgili sorgusunu doğrudan yanıtlar ve SQL Server 2012'nin neden farklı bir yaklaşım gerektireceğinin zeminini hazırlar.
DDM'nin SQL Server 2016'da tanıtılması, Microsoft'un artan veri gizliliği ve güvenlik endişelerine bir yanıtı olarak değerlendirilebilir. 2016'dan önce, SQL Server'da maskeleme genellikle manuel ve karmaşık bir süreçti.
DDM, standartlaştırılmış, daha yönetilebilir ve potansiyel olarak daha performanslı bir çözüm sunarak, güvenlik özelliklerini uyumluluğu kolaylaştırmak için doğrudan veritabanı platformlarına yerleştirme yönündeki bir endüstri eğilimini yansıtmaktadır (örneğin'te bahsedilen GDPR, HIPAA).
2. Dinamik Veri Maskeleme Fonksiyonları (SQL Server 2016 ve sonrası olan)
SQL Server 2016 ve sonrası olan, hassas verileri maskelemek için çeşitli yerleşik fonksiyonlar sunar. Bu fonksiyonlar, farklı veri türleri ve maskeleme gereksinimleri için esneklik sağlar. Bu bölüm, T-SQL sözdizimi ve örnekleri için büyük ölçüde 'e dayanacak, açıklamalar ve nüanslar için ile çapraz referans yapılacaktır.
2.1. Varsayılan (Default) Maskeleme
Varsayılan maskeleme fonksiyonu, belirlenen alanın veri türüne göre tam maskeleme sağlar.
● Dize Veri Türleri (char, nchar, varchar, nvarchar, text, ntext): Alanın boyutu 4 karakterden azsa XXXX (veya daha az X) kullanılır. Örneğin, 3 karakterlik bir alan için XXX kullanılır.
● Sayısal Veri Türleri (bigint, bit, decimal, int, money, numeric, smallint, smallmoney, tinyint, float, real): Sıfır (0) değeri kullanılır.
● Tarih ve Saat Veri Türleri (date, datetime2, datetime, datetimeoffset, smalldatetime, time): 1900–01–01 00:00:00.0000000 (veya yalnızca tarih/yalnızca saat türleri için eşdeğeri) kullanılır.
● İkili Veri Türleri (binary, varbinary, image): ASCII değeri 0 olan tek bir bayt kullanılır.
● Özel Veri Türleri (timestamp, table, HierarchyID, uniqueidentifier, uzamsal türler): Boş bir değer kullanılır.
- Örneğin, uniqueidentifier için bu 00000000–0000–0000–0000–000000000000 olabilir.
T-SQL Sözdizimi: Kolon tanımında veya ALTER COLUMN ifadesinde MASKED WITH (FUNCTION = 'default()') kullanılır.
Pratik Örnekler ve Sorgu Çıktıları: Aşağıdaki örnekte, Uyeler tablosundaki Telefon ve DogumTarihi sütunları varsayılan fonksiyonla maskelenmiştir.
CREATE SCHEMA Veri;
GO
CREATE TABLE Veri.Uyeler (
UyeID INT IDENTITY(1,1) NOT NULL PRIMARY KEY,
Ad VARCHAR(100) NULL,
Soyad VARCHAR(100) NOT NULL,
Telefon VARCHAR(12) MASKED WITH (FUNCTION = 'default()') NULL,
Eposta VARCHAR(100) NOT NULL,
DogumTarihi DATETIME MASKED WITH (FUNCTION = 'default()') NULL
);
INSERT INTO Veri.Uyeler (Ad, Soyad, Telefon, Eposta, DogumTarihi)
VALUES ('Murat ', 'Culum', '5551234567', 'murat.culum@hotmail.com', '1990–01–01');
- Yetkisiz bir kullanıcı (MaskesizKullanici) oluşturalım
CREATE USER MaskesizKullanici WITHOUT LOGIN;
GRANT SELECT ON Veri.Uyeler TO MaskesizKullanici;
- MaskesizKullanici olarak sorgulama
EXECUTE AS USER = 'MaskesizKullanici';
SELECT UyeID, Ad, Soyad, Telefon, Eposta, DogumTarihi FROM Veri.Uyeler;
REVERT;
Bu örnekte, Telefon sütunu xxxx olarak ve DogumTarihi sütunu 1900–01–01 00:00:00.000 olarak maskelenmiştir. default() fonksiyonunun çeşitli veri türlerindeki davranışı, genel bir "güvenli" maske sağlama çabasını vurgular, ancak kullanışlılığı değişebilir. Bir dize için XXXX veya bir sayı için 0 net bir gizleme olsa da, tüm tarihler için 1900–01–01 döndürmek, dikkatli bir şekilde ele alınmazsa geçerli tarih aralıkları bekleyen uygulamaları karıştırabilir veya hatta bozabilir. Bu varsayılan çıktıların, default() fonksiyonunun uygun olup olmadığını veya daha iyi veri gerçekçiliği ya da uygulama uyumluluğu için özel/kısmi bir maskenin gerekip gerekmediğini değerlendirmek için anlaşılması kritik öneme sahiptir.
2.2. E-posta (Email) Maskeleme
E-posta maskeleme fonksiyonu, e-posta adresinin ilk harfini gösterir, yerel kısmın geri kalanını maskeler ve standart bir maskelenmiş alan adı kullanır. Örneğin, muratculum@hotmail.com adresi mXXX@XXXX.com veya benzeri bir formatta gösterilebilir. Farklı kaynaklarda maskelenmiş alan adı XXX.com veya XXXX.com olarak belirtilse de, tutarlı desen ilk harfin görünür olması, kullanıcı adının ve alan adının geri kalanının maskelenmesidir.
T-SQL Sözdizimi: MASKED WITH (FUNCTION = 'email()').
Pratik Örnekler ve Sorgu Çıktıları: Veri.Uyeler tablosundaki Eposta sütununu e-posta fonksiyonu ile maskeleyelim.
- Önceki Eposta sütunundaki maskeyi kaldıralım (varsa) ve yenisini ekleyelim
- ALTER TABLE Veri.Uyeler ALTER COLUMN Eposta DROP MASKED; - Eğer daha önce farklı bir maske uygulandıysa
ALTER TABLE Veri.Uyeler ALTER COLUMN Eposta ADD MASKED WITH (FUNCTION = 'email()');
- MaskesizKullanici olarak sorgulama
EXECUTE AS USER = 'MaskesizKullanici';
SELECT UyeID, Ad, Soyad, Telefon, Eposta, DogumTarihi FROM Veri.Uyeler;
REVERT;
email() fonksiyonu, gizliliği bir miktar orijinal ipucuyla dengeleyerek tanınabilir bir format sunar. İlk harfi göstermek, bazı dahili destek senaryoları için yararlı olabilir (örneğin, "Bu kullanıcı A… mı?"). Ancak, sabit maskelenmiş alan adı (örneğin, XXXX.com), orijinal e-posta alan adı hakkında hiçbir bilgi korunmadığı anlamına gelir (,.com ile bitmeyen alan adlarının.com olarak maskelendiğini belirtir). Bu güçlü bir gizlilik önlemidir ancak alan adı ayrımı gerekiyorsa kullanışlılığı sınırlar.
2.3. Rastgele (Random) Maskeleme (Sayısal Veri Türleri İçin)
Rastgele maskeleme fonksiyonu, sayısal değerleri belirtilen bir aralık içinde rastgele bir sayıyla değiştirir. Bu fonksiyon yalnızca sayısal veri türleri için geçerlidir.
T-SQL Sözdizimi: MASKED WITH (FUNCTION = 'random(<baslangic_araligi>, <bitis_araligi>)').
Pratik Örnekler ve Sorgu Çıktıları: Siparisler adında yeni bir tablo oluşturalım ve IndirimKodu sütununu rastgele maskeleyelim.
CREATE TABLE Veri.Siparisler (
SiparisID INT IDENTITY(1,1) NOT NULL PRIMARY KEY,
MusteriID INT NOT NULL,
Tutar DECIMAL(10,2) NOT NULL,
IndirimKodu SMALLINT MASKED WITH (FUNCTION = 'random(1, 100)') NULL
);
INSERT INTO Veri.Siparisler (MusteriID, Tutar, IndirimKodu)
VALUES (1, 250.75, 15), (2, 120.00, 85);
GRANT SELECT ON Veri.Siparisler TO MaskesizKullanici;
- MaskesizKullanici olarak sorgulama
EXECUTE AS USER = 'MaskesizKullanici';
SELECT SiparisID, MusteriID, Tutar, IndirimKodu FROM Veri.Siparisler;
REVERT;
Rastgele maskeleme, açıkça iletilmezse yanıltıcı olabilir. Gerçek değeri gizlerken, "gerçekçi" ancak yanlış bir sayı sunmak (), kullanıcıları 0 veya XXXX gibi açıkça maskelenmiş bir yer tutucu yerine gerçek, ancak farklı veriler gördüklerini düşünmeye yöneltebilir. Bu, özellikle kullanıcılar rastgele maskeleme ile DDM'nin aktif olduğundan habersizse, analiz veya raporlama için önemlidir. Net dokümantasyon ve kullanıcı eğitimi esastır.
2.4. Özel Dize (Kısmi — Partial) Maskeleme
Özel dize (veya kısmi) maskeleme fonksiyonu, belirtilen sayıda ön ek ve son ek karakterini gösterir ve ortasına özel bir dolgu dizesi ekler. Bu fonksiyon yalnızca dize türündeki sütunlar için çalışır.
T-SQL Sözdizimi: MASKED WITH (FUNCTION = 'partial(<onek_uzunlugu>, "<dolgu_dizesi>", <sonek_uzunlugu>)').
● <onek_uzunlugu>: Gösterilecek baştaki karakter sayısı.
● <dolgu_dizesi>: Ortada kullanılacak maskeleme dizesi (örneğin, "xxxxx").
● <sonek_uzunlugu>: Gösterilecek sondaki karakter sayısı.
Pratik Örnekler ve Sorgu Çıktıları: Veri.Uyeler tablosundaki Ad sütununu kısmi maskeleyelim.
- ALTER TABLE Veri.Uyeler ALTER COLUMN Ad DROP MASKED; - Eğer daha önce farklı bir maske uygulandıysa
ALTER TABLE Veri.Uyeler ALTER COLUMN Ad ADD MASKED WITH (FUNCTION = 'partial(1, "xxxx", 1)');
- MaskesizKullanici olarak sorgulama
EXECUTE AS USER = 'MaskesizKullanici';
SELECT UyeID, Ad, Soyad, Telefon, Eposta, DogumTarihi FROM Veri.Uyeler WHERE UyeID = 1;
REVERT;
"Murat" adı "Mxxxxt" (veya dolgu dizesinin uzunluğuna bağlı olarak benzeri) şeklinde maskelenecektir. Eğer Ad "Roberto" olsaydı, "Rxxxxo" olarak maskelenirdi. Kısmi maskeleme, veri kullanışlılığı ve gizliliği arasında denge kurmak için en fazla esnekliği sunar ancak dikkatli tasarım gerektirir. Orijinal dizenin bazı kısımlarını (örneğin, bir kredi kartının son 4 hanesi, bir adın ilk/son harfleri) gösterme yeteneği, tanımlama veya operasyonel amaçlar için çok yararlı olabilir. Ancak, çok fazla veya tahmin edilebilir kısımları göstermek maskelemeyi zayıflatabilir. Ön ek/son ek uzunluğu ve dolgu dizesi seçimi bağlama bağlı olmalı ve risk değerlendirmesi yapılmalıdır.
Örneğin, 5 karakterlik bir kodu partial(2, "X", 2) ile maskelemek verilerin %80'ini açığa çıkarır.
2.5. Kredi Kartı Maskeleme Deseni
Bu, genellikle son dört haneyi gösteren ve XXXX-XXXX-XXXX-1234 gibi sabit bir maskelenmiş dizeyle ön eklenen kısmi maskelemenin özel bir kullanım durumudur.
T-SQL Sözdizimi: MASKED WITH (FUNCTION = 'partial(0,"xxxx-xxxx-xxxx-",4)').
Pratik Örnekler ve Sorgu Çıktıları: Odemeler adında yeni bir tablo oluşturalım ve KrediKartiNo sütununu partial fonksiyonu ile maskeleyelim.
CREATE TABLE Veri.Odemeler (
OdemeID INT IDENTITY(1,1) NOT NULL PRIMARY KEY,
UyeID INT NOT NULL,
KrediKartiNo VARCHAR(19)
MASKED WITH (FUNCTION = 'partial(0,"xxxx-xxxx-xxxx-",4)') NULL,
SonKullanmaTarihi VARCHAR(5) NULL
);
INSERT INTO Veri.Odemeler (UyeID, KrediKartiNo, SonKullanmaTarihi)
VALUES (1, '1234–5678–9012–3456', '12/25');
GRANT SELECT ON Veri.Odemeler TO MaskesizKullanici;
- MaskesizKullanici olarak sorgulama
EXECUTE AS USER = 'MaskesizKullanici';
SELECT OdemeID, UyeID, KrediKartiNo, SonKullanmaTarihi FROM Veri.Odemeler;
REVERT;
partial() ile elde edilebilir. DDL'deki amacı daha net hale getirir ve bu son derece hassas veri türü için tutarlı bir maskeleme yaklaşımını teşvik eder.
2.6. DDM Fonksiyonlarının Özeti (SQL Server 2016 ve sonrası olan)
Aşağıdaki tablo, SQL Server 2016 ve sonrasında bulunan DDM fonksiyonlarını özetlemektedir:
NOT:
DatetimeApplies to: SQL Server 2022 (16.x)
Masking method for column defined with data type datetime, datetime2, date, time, datetimeoffset, smalldatetime.
It helps masking the
year => datetime("Y"),month=> datetime("M"),day=>datetime("D"),hour=>datetime("h"),minute=>datetime("m"), orseconds=>datetime("s")portion of the day.Example of how to mask the year of the datetime value:
ALTER COLUMN BirthDay ADD MASKED WITH (FUNCTION = 'datetime("Y")')
Example of how to mask the month of the datetime value:
ALTER COLUMN BirthDay ADD MASKED WITH (FUNCTION = 'datetime("M")')
Example of how to mask the minute of the datetime value:
ALTER COLUMN BirthDay ADD MASKED WITH (FUNCTION = 'datetime("m")')
Bu tablo, fonksiyonları kolayca karşılaştırılmasına ve ihtiyaçlarınıza en uygun olanı seçmesine olanak tanıyan özet ve karar verme sürecine yardımcı olur. MASK standartlarına uygun bir şekilde uygulanmasında iş görür.
3. Dinamik Veri Maskelemenin Uygulanması (SQL Server 2016 ve sonrası olan)
Dinamik Veri Maskeleme, hem yeni tablolar oluşturulurken hem de mevcut tablolardaki sütunlara uygulanabilir. Bu bölümde, T-SQL komutları kullanılarak DDM'nin nasıl tanımlanacağı, değiştirileceği ve kaldırılacağı gösterilecektir.
3.1. Tablo Oluşturma Sırasında Maskelerin Tanımlanması (CREATE TABLE)
Maskeleme fonksiyonları, tablo oluşturma (CREATE TABLE) sırasında sütun tanımlarının bir parçası olarak yapılandırılabilir. Bu, hassas sütunların baştan bilindiği yeni tablolar için ideal bir yaklaşımdır. Maskelerin tablo oluşturma sırasında tanımlanması, güvenliği veritabanı tasarım aşamasına entegre eder. Bu proaktif yaklaşım, hassas verilerin başlangıcından itibaren maskeleme için dikkate alınmasını sağlar, sonradan eklenen bir özellik olmaktan çıkar. "Tasarım gereği güvenlik" ilkeleriyle uyumludur ve veri koruma önlemlerinin yerleşik olduğunu göstererek uyumluluk çabalarını basitleştirebilir.
T-SQL Örneği: Aşağıdaki örnek, MusteriBilgileri adlı bir tablo oluşturur ve çeşitli sütunlara farklı DDM fonksiyonları uygular.
CREATE TABLE Veri.MusteriBilgileri (
MusteriID INT IDENTITY(1,1) NOT NULL PRIMARY KEY,
TamAd VARCHAR(200) MASKED WITH (FUNCTION = 'partial(1, "…", 1)') NULL,
TCKimlikNo VARCHAR(11) MASKED WITH (FUNCTION = 'partial(0, "xxxxxxx", 4)') NULL, - Son 4 haneyi göster
Telefon VARCHAR(15) MASKED WITH (FUNCTION = 'default()') NULL,
Eposta VARCHAR(100) MASKED WITH (FUNCTION = 'email()') NOT NULL,
YillikGelir MONEY MASKED WITH (FUNCTION = 'random(1000, 5000)') NULL - Gerçek geliri gizler, rastgele bir aralık gösterir
);
INSERT INTO Veri.MusteriBilgileri (TamAd, TCKimlikNo, Telefon, Eposta, YillikGelir)
VALUES ('Ayşe Kaya', '12345678901', '5321234567', 'ayse.kaya@example.com', 120000);
- Yetkisiz kullanıcı (MaskesizKullanici) ile sorgulama
EXECUTE AS USER = 'MaskesizKullanici';
SELECT MusteriID, TamAd, TCKimlikNo, Telefon, Eposta, YillikGelir FROM Veri.MusteriBilgileri;
REVERT;
3.2. Mevcut Sütunlara Maske Ekleme veya Değiştirme (ALTER TABLE… ADD MASKED WITH)
Mevcut bir sütuna veri maskesi eklemek veya mevcut bir maskeyi değiştirmek için, sütunu ALTER TABLE… ALTER COLUMN… ADD MASKED WITH komutuyla değiştirerek maske eklenir ve gerekli maskeleme türü belirtilir. Bu, mevcut veritabanlarına DDM uygulamak veya maskeleme kurallarını değiştirmek için esastır. ALTER TABLE yaklaşımı, uyarlanabilir güvenliğe olanak tanır. Veri hassasiyeti zamanla değişebilir veya yeni düzenlemeler daha önce maskelenmemiş verilerin maskelenmesini gerektirebilir. Mevcut sütunlara maske ekleme/değiştirme yeteneği, veri taşıma veya kapsamlı şema değişiklikleri olmadan bu gelişen gereksinimlere uyum sağlama esnekliği sunar.
T-SQL Örneği: Daha önce oluşturulmuş Veri.Uyeler tablosundaki Soyad sütununa varsayılan maskeleme ekleyelim.
ALTER TABLE Veri.Uyeler
ALTER COLUMN Soyad ADD MASKED WITH (FUNCTION = 'default()');
- MaskesizKullanici olarak sorgulama
EXECUTE AS USER = 'MaskesizKullanici';
SELECT UyeID, Ad, Soyad, Telefon, Eposta, DogumTarihi FROM Veri.Uyeler;
REVERT;
Eğer Soyad sütununda zaten bir maske varsa, bu komut mevcut maskeyi default() fonksiyonuyla değiştirir.
3.3. Sütunlardan Veri Maskelerini Kaldırma (ALTER TABLE… DROP MASK)
Bir sütundaki veri maskesini kaldırmak için ALTER TABLE… ALTER COLUMN… DROP MASK komutu kullanılır (bu'deki "dinamik veri maskesini bırak" örneğinden çıkarılabilir). Bu, bir sütun artık hassas kabul edilmiyorsa veya bir sütun için DDM'nin geçici olarak devre dışı bırakılması gerekiyorsa gereklidir. Bir maskenin kaldırılması, temel verileri o sütunda SELECT iznine sahip tüm kullanıcılara anında gösterir. Bir maske eklemenin aksine (görünümü kısıtlar), bir maskeyi bırakmak görünümü genişletir. Bu eylem dikkatli bir şekilde kontrol edilmeli ve denetlenmelidir, çünkü veri maruziyetini doğrudan etkiler. ALTER ANY MASK izninin sıkı bir şekilde kontrol edilmesinin önemini vurgular.
T-SQL Örneği: Veri.Uyeler tablosundaki Soyad sütunundan maskeyi kaldıralım.
ALTER TABLE Veri.Uyeler
ALTER COLUMN Soyad DROP MASKED;
- MaskesizKullanici olarak sorgulama
EXECUTE AS USER = 'MaskesizKullanici';
SELECT UyeID, Ad, Soyad, Telefon, Eposta, DogumTarihi FROM Veri.Uyeler;
REVERT;
3.4. Veri Sorgulama: Maskelenmiş ve Maskelenmemiş Veri Görünümlerinin Gösterilmesi
DDM'nin etkisini göstermek için, aynı tabloyu farklı izinlere sahip kullanıcılar olarak sorgulayacağız.
Kurulum:
1. Veri.MusteriBilgileri tablosu önceki örneklerdeki gibi maskelenmiş sütunlarla oluşturulmuş ve veri eklenmiştir.
2. MaskesizKullanici adlı, yalnızca SELECT iznine sahip bir kullanıcı mevcuttur.
3. YetkiliKullanici adlı, UNMASK iznine sahip (veya db_owner gibi örtük olarak maskesizleştirme yeteneğine sahip) bir kullanıcı oluşturalım.
- YetkiliKullanici oluşturalım ve UNMASK izni verelim
CREATE USER YetkiliKullanici WITHOUT LOGIN;
GRANT SELECT ON Veri.MusteriBilgileri TO YetkiliKullanici;
GRANT UNMASK TO YetkiliKullanici; - Veritabanı genelinde UNMASK izni (test için; normalde daha kısıtlı olmalı)Sorgulama ve Çıktılar:
● MaskesizKullanici olarak sorgulama:
EXECUTE AS USER = 'MaskesizKullanici';
SELECT MusteriID, TamAd, TCKimlikNo, Telefon, Eposta, YillikGelir FROM Veri.MusteriBilgileri;
REVERT;
● YetkiliKullanici olarak sorgulama:
EXECUTE AS USER = 'YetkiliKullanici';
SELECT MusteriID, TamAd, TCKimlikNo, Telefon, Eposta, YillikGelir FROM Veri.MusteriBilgileri;
REVERT;
Bu, DDM'nin pratikte nasıl çalıştığının somut bir kanıtını sunar ve izinlerin etkisini görsel olarak doğrular. Aynı sorgunun, kullanıcı ayrıcalıklarına bağlı olarak farklı sonuçlar vermesi, uygulamaya şeffaf bir şekilde gerçekleşir. Bu, DDM'nin temel gücüdür. Uygulama standart bir SELECT ifadesi gönderir. Veritabanı motoru, sorgulayan kullanıcının izinlerine dayanarak maskelenmiş veya maskelenmemiş verilerin döndürülüp döndürülmeyeceğine karar verir. Bu şeffaflık, uygulamanın DDM'den "haberdar" olmasına veya farklı kullanıcı türleri için farklı sorgulara sahip olmasına gerek kalmadan uygulama geliştirmeyi basitleştirir.
4. DDM için İzinler ve Yetkilendirme (SQL Server 2016 ve sonrası olan)
Dinamik Veri Maskeleme'nin etkin bir şekilde yönetilmesi, doğru izinlerin atanmasına bağlıdır. Bu bölüm, maske tanımlama, yönetme ve maskelenmemiş verilere erişimi kontrol etme izinlerini ayrıntılı olarak ele alacaktır.
4.1. Maskeleri Tanımlamak ve Yönetmek için Gerekli İzinler (ALTER ANY MASK, Tabloda ALTER)
Bir sütuna maske eklemek, mevcut bir maskeyi değiştirmek veya kaldırmak için ALTER ANY MASK veritabanı düzeyinde izni ve ilgili tablo üzerinde ALTER izni gereklidir. Bir tabloyu başlangıçta bir maske ile oluşturmak için standart CREATE TABLE ve şema üzerinde ALTER ON SCHEMA izinleri yeterlidir.
ALTER ANY MASK izni, genellikle güvenlik görevlilerine veya kıdemli veritabanı yöneticilerine (DBA) verilir ve dikkatli bir şekilde yönetilmelidir. ALTER ANY MASK izninin genel tablo değiştirme izinlerinden ayrılması, görevlerin ayrılmasına olanak tanır. Bir geliştirici, sütun eklemek veya veri türlerini değiştirmek için bir tabloda ALTER iznine sahip olabilir, ancak hangi sütunların hassas olduğuna ve nasıl maskelenmesi gerektiğine karar verme yetkisine sahip olmayabilir. ALTER ANY MASK izninin özel bir güvenlik rolüne verilmesi, maskeleme değişiklikleri için bir inceleme ve onay süreci uygular ve yönetişimi güçlendirir.
4.2. UNMASK İzni: Orijinal Verilere Erişimi Kontrol Etme
UNMASK izni, bir kullanıcıya maskeleme tanımlanmış sütunlardan maskelenmemiş verileri alma yetkisi verir. Bir tabloda SELECT iznine sahip kullanıcılar tablo verilerini görüntüleyebilir; sütunlar maskelenmişse, UNMASK izinleri yoksa maskelenmiş verileri görürler. Bu, hassas verileri meşru olarak görmesi gereken son kullanıcılar veya uygulamalar için kilit izindir.
UNMASK, veri erişimi için tek başına bir izin değildir; SELECT davranışını değiştirir. Bir kullanıcının bir nesneyi (tablo/görünüm) sorgulayabilmesi için öncelikle o nesne üzerinde SELECT iznine ihtiyacı vardır. UNMASK daha sonra o kullanıcı için maskelemeyi "geçersiz kılan" ek bir katman olarak işlev görür. Bir nesne üzerinde SELECT olmadan UNMASK vermek etkisiz olacaktır (: "UNMASK her zaman herhangi bir etkiye sahip olmak için bir SELECT izniyle birlikte gelmelidir"). Bu etkileşim, yalnızca UNMASK'e odaklanmak yerine bütünsel bir izin stratejisinin gerekliliğini vurgular.
4.3. Granüler UNMASK İzin Yönetimi
UNMASK izinleri veritabanı düzeyinde, şema düzeyinde, tablo düzeyinde veya sütun düzeyinde verilebilir veya iptal edilebilir. SQL Server 2022 bu özelliği daha da geliştirmiştir, ancak bu rapor SQL Server 2016 ve sonrası olan yeteneklerine odaklanmaktadır.
Bu ayrıntı düzeyi, en az ayrıcalık ilkesini uygulamak için kritik öneme sahiptir. Kullanıcılar yalnızca kesinlikle ihtiyaç duydukları belirli verilerin maskesini kaldırabilmelidir.
Granüler UNMASK izinleri, DDM'nin karmaşık ortamlardaki pratik kullanışlılığının temel taşıdır. Bu ayrıntı düzeyi olmadan, DDM bir kullanıcı için bir tablo veya veritabanı başına ya hep ya hiç özelliği olurdu. Belirli kullanıcılar/roller için yalnızca belirli sütunların maskesini kaldırma yeteneği, aynı tablo veya veritabanındaki diğer hassas verileri bu kullanıcılardan korurken çeşitli iş gereksinimlerini karşılayabilen ince ayarlı erişim kontrolüne olanak tanır.
Bu, kullanıcının x kullanıcısının xy sütununu maskesiz, yx sütununu ise maskeli görme senaryosunu doğrudan mümkün kılar.
T-SQL Örnekleri (GRANT/REVOKE)
● Veritabanı Düzeyinde UNMASK:
○ Amaç: Kullanıcının tüm veritabanındaki tüm maskelenmiş verileri maskesiz görmesini sağlar. Aşırı dikkatle kullanılmalıdır.
○ GRANT UNMASK TO <kullanici_veya_rol_adi>;
○ REVOKE UNMASK FROM <kullanici_veya_rol_adi>;
○ Örnek: GRANT UNMASK TO MuhasebeSefi;
● Şema Düzeyinde UNMASK: SQL Server 2022 and later
○ Amaç: Kullanıcının belirtilen şemadaki tüm tablolardaki tüm maskelenmiş verileri maskesiz görmesini sağlar.
○ GRANT UNMASK ON SCHEMA::<sema_adi> TO <kullanici_veya_rol_adi>;
○ REVOKE UNMASK ON SCHEMA::<sema_adi> FROM <kullanici_veya_rol_adi>;
○ Örnek: GRANT UNMASK ON SCHEMA::Satis TO SatisMuduru;
● Tablo Düzeyinde UNMASK: SQL Server 2022 and later
○ Amaç: Kullanıcının belirtilen tablodaki tüm maskelenmiş sütunları maskesiz görmesini sağlar.
○ GRANT UNMASK ON <sema_adi>.<tablo_adi> TO <kullanici_veya_rol_adi>;
○ REVOKE UNMASK ON <sema_adi>.<tablo_adi> FROM <kullanici_veya_rol_adi>;
○ Örnek: GRANT UNMASK ON Veri.MusteriBilgileri TO MusteriHizmetleriTemsilcisi;
● Sütun Düzeyinde UNMASK: SQL Server 2022 and later
○ Amaç: Kullanıcının yalnızca belirtilen maskelenmiş sütunu maskesiz görmesini sağlar. Bu en ayrıntılı ve genellikle tercih edilen yöntemdir.
○ GRANT UNMASK ON <sema_adi>.<tablo_adi>(<sutun_adi>) TO <kullanici_veya_rol_adi>;
○ REVOKE UNMASK ON <sema_adi>.<tablo_adi>(<sutun_adi>) FROM <kullanici_veya_rol_adi>;
○ Örnek: GRANT UNMASK ON Veri.MusteriBilgileri(TCKimlikNo) TO FinansAnalisti;
— — — — — — — — — — — — — — — — — — — — — — — — — — —
4.4. Örtük Maskesizleştirme Yeteneklerine Sahip Kullanıcılar
Bazı kullanıcılar veya roller, DDM'yi varsayılan olarak atlayan örtük maskesizleştirme yeteneklerine sahiptir.
● CONTROL SERVER veya veritabanı düzeyinde CONTROL iznine sahip kullanıcılar, maskelenmiş verileri orijinal biçiminde görüntüleyebilir. Bu, sysadmin, db_owner gibi yönetici rollerini içerir.
● Veritabanındaki CONTROL izni, hem ALTER ANY MASK hem de UNMASK iznini içerir.
Bu, yönetimsel amaçlar için beklenen bir davranıştır ancak bilinmesi gerekir. Aşırı izin verme (örneğin, uygulama hizmet hesaplarını db_owner yapma), bu hesaplar için DDM'yi etkili bir şekilde geçersiz kılar.
Bir uygulama db_owner hesabıyla bağlanırsa, DDM o uygulama tarafından çalıştırılan sorgulara uygulanmaz, uygulamanın bazı son kullanıcılarına maskeli veri gösterme amacı olsa bile (uygulamanın kendisi daha fazla mantık uygulamadığı sürece).
Bu, yalnızca etkileşimli kullanıcılar için değil, hizmet hesapları için de en az ayrıcalık ilkesinin önemini vurgular. DDM, uygulamalar minimum düzeyde ayrıcalıklı hesaplarla bağlandığında ve belirli kullanıcılara gerektiği gibi UNMASK verildiğinde en etkilidir.
4.5. DDM İle İlgili İzinlerin Özeti
Aşağıdaki tablo, DDM ile ilgili temel izinleri ve amaçlarını özetlemektedir:
Bu tablo, DDM uygulamasının kendisini güvence altına almak için kimin ne yapabileceğini (maske tanımlama, verilerin maskesini kaldırma) anlamanın temelini oluşturur.
5. Gelişmiş DDM Senaryoları ve Operasyonel Hususlar (SQL Server 2016 ve sonrası olan)
Dinamik Veri Maskeleme, basit sorgu sonuçlarını maskelemenin ötesine geçen çeşitli senaryolarda ve operasyonel durumlarda belirli davranışlar sergiler.
5.1. SELECT INTO ve INSERT INTO İşlemleriyle Etkileşim
SELECT INTO veya INSERT INTO… SELECT ifadeleri kullanılarak maskelenmiş bir sütundan başka bir tabloya veri kopyalandığında, hedef tablodaki verilerin durumu işlemi gerçekleştiren kullanıcının UNMASK ayrıcalıklarına bağlıdır.
● Eğer işlemi UNMASK iznine sahip olmayan bir kullanıcı gerçekleştirirse, hedef tabloya maskelenmiş veriler yazılır.
● Eğer işlemi UNMASK iznine sahip (veya db_owner gibi örtük olarak bu yetkiye sahip) bir kullanıcı gerçekleştirirse, hedef tabloya orijinal, maskelenmemiş veriler yazılır.
Bu davranış, yetkisiz kullanıcıların DDM'yi basitçe verileri daha fazla kontrole sahip olabilecekleri yeni bir tabloya kopyalayarak atlatmalarını önler.
DDM'nin koruması, yetkisiz kullanıcılar tarafından başlatılan veri taşıma işlemlerine kadar uzanır. Bu, DDM'nin tasarımının önemli bir yönüdür. Veri kopyalama her zaman maskelenmemiş verilerle sonuçlansaydı, DDM kolayca atlatılabilirdi.
Kopyalamayı gerçekleştiren kullanıcının bağlamının ve izinlerinin kopyalanan verilerin durumunu belirlemesi güvenlik sınırını korur. Bu, yetkisiz kullanıcılar tarafından oluşturulan geçici tabloların veya hazırlık tablolarının bile maskelenmiş sütunlardan kaynaklanıyorsa maskelenmiş veriler içereceği anlamına gelir.
Örnek Senaryo: Veri.MusteriBilgileri tablosundaki TCKimlikNo (maskeli) ve TamAd (maskeli) sütunlarını içeren verileri yeni bir tabloya kopyalayalım.
- MaskesizKullanici olarak SELECT INTO
EXECUTE AS USER = 'MaskesizKullanici';
SELECT MusteriID, TamAd, TCKimlikNo
INTO Veri.MusteriKopya_Maskeli
FROM Veri.MusteriBilgileri;
SELECT * FROM Veri.MusteriKopya_Maskeli; - TamAd ve TCKimlikNo maskeli olacaktır
DROP TABLE Veri.MusteriKopya_Maskeli;
REVERT;
- YetkiliKullanici (UNMASK izniyle) olarak SELECT INTO
EXECUTE AS USER = 'YetkiliKullanici';
SELECT MusteriID, TamAd, TCKimlikNo
INTO Veri.MusteriKopya_Maskesiz
FROM Veri.MusteriBilgileri;
SELECT * FROM Veri.MusteriKopya_Maskesiz; - TamAd ve TCKimlikNo orijinal (maskesiz) olacaktır
DROP TABLE Veri.MusteriKopya_Maskesiz;
REVERT;5.2. Veri İçe/Dışa Aktarma Süreçlerindeki Davranış
SELECT INTO'ya benzer şekilde, DDM, SQL Server İçe/Dışa Aktarma Sihirbazı gibi araçlar kullanıldığında da uygulanır. UNMASK ayrıcalıklarına sahip olmayan bir kullanıcı tarafından yapılan bir veritabanı dışa aktarma işlemi, maskelenmiş veriler içeren bir dışa aktarma dosyasıyla sonuçlanacaktır.
Bu verilerin içe aktarılması, hedefte statik olarak maskelenmiş verilerle sonuçlanacaktır. Bu, veriler standart araçlarla anlık veritabanı ortamından ayrıldığında bile, yetkisiz bir kullanıcı tarafından yapılıyorsa verileri korur. Yetkisiz kullanıcılar tarafından dışa aktarılan veriler, dışa aktarma dosyasında "kalıcı olarak" maskelenir. DDM'nin temel veritabanı verilerinin canlı olduğu durumun aksine, yetkisiz bir kullanıcı tarafından maskelenmiş olarak dışa aktarıldıktan sonra, bu dışa aktarma dosyası maskelenmiş değerleri ('XXXX', Ɔ' gibi) içerir.
Dosyanın kendisinden "maskesini kaldırmanın" bir yolu yoktur. Bu, üçüncü taraflara veri dökümleri sağlamak veya daha az güvenli analitik ortamlara yüklemek gibi senaryolar için kritik öneme sahiptir.
5.3. Maskelenmiş Sütunlara Bağımlı Hesaplanmış Sütunlar Üzerindeki Etki
Bir maske doğrudan bir hesaplanmış sütun üzerinde yapılandırılamaz. Ancak, bir hesaplanmış sütun maskelenmiş olan başka bir sütuna bağlıysa, hesaplanmış sütun, temel kaynak sütun(lar) üzerinde UNMASK izni olmayan kullanıcılara maskelenmiş veriler döndürür. DDM'nin etkisi bağımlılıklar yoluyla yayılır.
T-SQL Örneği: SatisDetaylari tablosunda, BirimFiyat maskeli ve SatisTutari bu fiyata göre hesaplanıyor.
CREATE TABLE Veri.SatisDetaylari (
SatisID INT IDENTITY PRIMARY KEY,
UrunAdi VARCHAR(100),
Miktar SMALLINT,
BirimFiyat MONEY MASKED WITH (FUNCTION = 'default()'), - Maskeli (0 olarak görünecek)
IndirimOrani DECIMAL(3,2) DEFAULT 0,
SatisTutari AS (Miktar * BirimFiyat * (1 - IndirimOrani)) - Hesaplanmış
);
INSERT INTO Veri.SatisDetaylari (UrunAdi, Miktar, BirimFiyat, IndirimOrani)
VALUES ('Kalem', 10, 5.00, 0.10);
- MaskesizKullanici (BirimFiyat için UNMASK izni yok) olarak sorgulama
EXECUTE AS USER = 'MaskesizKullanici';
SELECT SatisID, UrunAdi, Miktar, BirimFiyat, SatisTutari FROM Veri.SatisDetaylari;
REVERT;
Bu örnekte, BirimFiyat yetkisiz kullanıcı için 0.00 olarak maskelendiğinden, SatisTutari da 0.00 olarak hesaplanacaktır. Maskeleme temel sütunları, yetkisiz kullanıcılar için bağımlı hesaplanmış sütunlarda beklenmedik veya anlamsız sonuçlara yol açabilir. Eğer BirimFiyat bir kullanıcı için 0 olarak maskelenirse, Miktar * 0 * (1-IndirimOrani) olarak hesaplanan SatisTutari da 0 olacaktır.
Bu, istenen davranış olabilir (türetilmiş hassas değerleri gizlemek) veya anlamlı hesaplanmış değerler bekleyen raporları ya da uygulama mantığını bozabilir. Bu, DDM uygularken sütun bağımlılıklarının dikkatli bir şekilde analiz edilmesini gerektirir.
5.4. Yüksek Kullanılabilirlik (HA) Kurulumlarında DDM (örneğin, Always On Kullanılabilirlik Grupları)
DDM, Always On Kullanılabilirlik Grupları (AG'ler) ile uyumludur. Maske tanımları veritabanı şemasının bir parçasıdır ve ikincil kopyalara çoğaltılır. UNMASK izinleri, aynı zamanda çoğaltılan veritabanı sorumlularına (kullanıcılar/roller) verilir.
● Okunabilir İkincil Kopyalarda Tutarlılık: UNMASK izni olmayan kullanıcılar tarafından okunabilir ikincil kopyalara karşı yapılan sorgular, birincil kopyayla tutarlı olarak maskelenmiş veriler döndürecektir. UNMASK iznine sahip kullanıcılar okunabilir bir ikincil kopyayı sorguladığında maskelenmemiş verileri görmelidir.
● İzin Senkronizasyonu: Veritabanı düzeyindeki izinler (UNMASK, ALTER ANY MASK) ve kullanıcı/rol tanımları veritabanının bir parçasıdır ve senkronize edilir. Veritabanı kullanıcılarının bağlanabilmesi için sunucu düzeyindeki oturum açma bilgilerinin tüm kopyalarda mevcut olması gerekir.
DDM, Always On AG'leriyle sorunsuz bir şekilde bütünleşir ve kopyalar arasında tutarlı veri koruması sağlar. DDM politikaları ve ilgili izinler veritabanı meta verilerinde saklandığından, bir AG'deki veritabanı çoğaltmasıyla doğal olarak akarlar. Bu, bir uygulama birincil veya okunabilir bir ikincil kopyaya bağlansa da veri maruziyeti kurallarının tutarlı olmasını sağlar ve HA ortamlarında güvenlik yönetimini basitleştirir. Ana husus, sunucu düzeyindeki oturum açma bilgilerinin AG kopyalarını barındıran örnekler arasında senkronize edilmesini sağlamaktır.
6. Dinamik Veri Maskelemenin Sınırlamaları ve Kısıtlamaları (SQL Server 2016 ve sonrası olan)
Dinamik Veri Maskeleme güçlü bir özellik olsa da, her güvenlik aracında olduğu gibi bazı sınırlamaları ve kısıtlamaları vardır. Bu sınırlamaların farkında olmak, DDM'yi etkili bir şekilde planlamak ve uygulamak için önemlidir.
6.1. DDM, Şifreleme veya Bütünsel Güvenlik Önlemlerinin Yerine Geçmez
DDM bir maskeleme/gizleme aracıdır, şifreleme değildir. Veriler diskte düz metin olarak saklanır. Denetim, şifreleme (örneğin, TDE), Satır Düzeyinde Güvenlik (RLS) gibi diğer güvenlik özelliklerini tamamlayıcı niteliktedir ve bunlarla birlikte kullanılması şiddetle tavsiye edilir. Bu, beklentileri yönetir. DDM, sorgu sonuçlarında yetkisiz görüntülemeye karşı korur, doğrudan dosya erişimine veya SQL sorgu motorunu atlatan karmaşık saldırılara karşı koruma sağlamaz. Yalnızca DDM'ye güvenmek, eksik bir veri güvenliği algısı yaratır. Bir saldırgan veritabanı dosyalarına (örneğin,.mdf/.ldf) veya yedeklemelere (TDE ile şifrelenmemişse) erişim kazanırsa, DDM yalnızca sorgu katmanında çalıştığı için düz metin verilere doğrudan erişebilir. Bu nedenle DDM genellikle derinlemesine savunma stratejisinin bir katmanı olarak tanımlanır.
6.2. Desteklenmeyen Sütun Türleri
Aşağıdaki sütun türleri için maskeleme tanımlanamaz:
● FILESTREAM
● COLUMN_SET
● Always Encrypted sütunları (DDM, Always Encrypted ile uyumlu değildir)
● Seyrek (sparse) sütunlar ve belirli hesaplanmış sütunlar doğrudan maskelenemez.
Kullanıcıların DDM uygulamasını planlarken bu teknik kısıtlamaların farkında olması gerekir. Bu sınırlamalar genellikle bu sütun türlerinin SQL Server motoru tarafından özel doğasından veya işlenmesinden kaynaklanır.
Always Encrypted sütunları istemci tarafında şifrelenir; sunucu hiçbir zaman düz metin verilerini görmez, bu da sunucu tarafı DDM'yi uygulanamaz hale getirir.
FILESTREAM verileri veritabanı dışında dosya sisteminde saklanır. Bu doğal mimari farklılıklar, bir sorgu sonucu değiştirme özelliği olan DDM'nin neden bunlara uygulanamadığını açıklar. Bu, bu sütun türlerindeki veriler için alternatif koruma mekanizmalarının kullanılması gerektiği anlamına gelir.
6.3. Tam Metin Dizinleriyle (Full-Text Indexes) İlgili Kısıtlamalar
Veri maskelemesi uygulanmış bir sütun, bir tam metin dizini için anahtar olamaz. Bu, maskelenmesi amaçlanan sütun aynı zamanda tam metin arama için de kritik öneme sahipse arama işlevselliğini etkileyebilir. Bu kısıtlama, muhtemelen tam metin dizinlerinin gerçek veriler üzerinde nasıl çalıştığından kaynaklanmaktadır.
Tam metin dizinlerinin sütunun gerçek içeriğini ayrıştırması ve dizine eklemesi gerekir. Sütun dizine eklenmeden önce maskelenseydi, dizin maskelenmiş veriler üzerine kurulur ve orijinal içeriği aramak için işe yaramaz hale gelirdi. Maskeleme dizine eklendikten sonra ancak aramadan önce uygulansaydı, tutarsızlıklara yol açabilir veya verileri açığa çıkarabilirdi. Bu nedenle, kısıtlama bu karmaşıklıkları önler.
6.4. Veri Çıkarımı (Inference) ve Brute-Force Teknikleri Potansiyeli
DDM, veritabanı kullanıcılarının doğrudan bağlanmasını ve hassas verilerin parçalarını açığa çıkaran kapsamlı sorgular çalıştırmasını engellemeyi amaçlamaz.
Gelişmiş kullanıcılar, maskelenmemiş sütunları veya yedek dosyalarını (erişilebilir ve şifrelenmemişse) kullanarak maskelenmiş verileri çıkarabilir. DDM, sorgu erişimi olan kararlı içeriden kişilere karşı kusursuz değildir.
Çıkarım Örneği: Bir maaş sütunu default() ile maskelenmişse (yani 0 gösteriyorsa), ancak maskelenmemiş bir Unvan sütunu varsa, bir kullanıcı iş unvanlarına göre maaş aralıklarını çıkarabilir. Eğer partial() bir TC Kimlik Numarası için xxxxxxx6789 gösteriyorsa ve kullanıcı bireyleri daraltan diğer kriterlere göre sorgu yapabiliyorsa, tam TC Kimlik Numarasını tahmin edebilir.
Çıkarım saldırıları riski, kullanıcının erişebildiği bağlamsal veri miktarı ve kullanılan maskeleme türü ile artar. default() maskeleme, partial() veya dar bir aralıktaki random() maskelemeye göre çıkarım yapmak için daha az bilgi sağlar. Bir kullanıcı birçok ilgili, maskelenmemiş sütunu sorgulayabiliyorsa, daha eksiksiz bir resim oluşturabilir ve maskelenmiş değerler hakkında daha eğitimli tahminlerde bulunabilir.
Bu, yalnızca tek tek sütunları izole bir şekilde maskelemek yerine veri erişiminin bütünsel bir görünümünün önemini vurgular. İlgili bağlamsal verileri içeren satırlara erişimi kısıtlamak için Satır Düzeyinde Güvenlik gerekebilir.
6.5. Performans Ek Yükü Hususları
Microsoft, maskeleme sorgu işleminin sonunda yapıldığı için performans etkisinin minimal ve genellikle ihmal edilebilir olduğunu belirtmektedir. Ancak, belirli iş yükleri için yine de doğrulanması tavsiye edilir., özellikle dinamik maskeleme ile potansiyel performans etkisinden bahseder (ancak bu, SQL Server'ın DDM'sine özgü olmayan genel bir ifadedir). Genel olarak verimli olsa da, karmaşık sorgular veya çok yüksek işlem hacmine sahip sistemler test edilmelidir.
"Minimal etki" iddiası muhtemelen tipik DDM fonksiyonları için doğrudur, ancak son derece karmaşık senaryolar veya özel mantık (DDM, yerleşik fonksiyonlarının ötesinde çok genişletilebilir olmasa da) farklı davranabilir. Yerleşik fonksiyonlar (default, email, partial, random) veritabanı motoru içinde yerel olarak uygulanır ve muhtemelen optimize edilmiştir.
DDM, örneğin, her satır için karmaşık kullanıcı tanımlı fonksiyonları çağırmayı içerseydi (SQL Server DDM'nin çalışma şekli bu değildir, ancak varsayımsal bir durumdur), etki daha büyük olabilirdi. Standart DDM için maliyet, öncelikle ayrıcalıksız bir kullanıcıya yönelik sonuç kümesindeki her satır için fonksiyonu değerlendirmektir.
6.6. Diğer Kısıtlamalar
● Maskelenmiş sütunlar Always Encrypted ifadelerinin bir parçası olarak kullanılamaz (DDM, Always Encrypted ile uyumlu değildir ).
● Kullanımdan kaldırılmış READTEXT, UPDATETEXT, WRITETEXT ifadeleri, UNMASK izni olmayan kullanıcılar için DDM ile yapılandırılmış bir sütunda düzgün çalışmaz.
● PolyBase harici tablolarındaki sütunlar maskelenemez.
● Bağımlılıkları olan sütunlara (örneğin, şemaya bağlı görünümler, ona başvuran dizine eklenmiş hesaplanmış sütunlar) DDM eklemek, önce bağımlılığı kaldırmayı, ardından dinamik veri maskesini eklemeyi ve sonra bağımlılığı yeniden oluşturmayı gerektirebilir.
7. Etkili Dinamik Veri Maskeleme için En İyi Uygulamalar (SQL Server 2016 ve sonrası olan)
Dinamik Veri Maskeleme'nin potansiyelinden tam olarak yararlanmak ve güvenlik duruşunu güçlendirmek için belirli en iyi uygulamaların izlenmesi önemlidir.
7.1. DDM'yi Katmanlı Bir Güvenlik Mimarisi İçinde Entegre Etme
DDM, diğer SQL Server güvenlik özelliklerini (denetim, şifreleme, RLS) tamamlayıcı niteliktedir ve bunlarla birlikte kullanılmalıdır. Bu, derinlemesine savunma yaklaşımının bir parçasıdır. DDM bir yönü (veri görüntüleme) ele alırken, diğerleri depodaki verileri (TDE), ayrıntılı satır erişimini (RLS) ve erişimi izlemeyi (denetim) ele alır.
Etkili veri koruması, birden fazla güvenlik özelliğinin sinerjik kullanımını gerektirir. Hiçbir tek güvenlik özelliği her derde deva değildir.
DDM, sorgularda yetkisiz görüntülemeye karşı korur. TDE, fiziksel ortam çalınırsa verileri korur. RLS, kullanıcıların yetkili olmadıkları satırları görmesini engeller. Denetim, kimin neye eriştiğini izler. Birlikte, herhangi bir özellikten tek başına çok daha güçlü koruma sağlarlar. Örneğin, DDM bir maaşı maskeleyebilir, ancak RLS bir yöneticinin kendi departmanında olmayan çalışanlara ait satırları bile görmesini engelleyebilir.
7.2. UNMASK İzinleri için En Az Ayrıcalık İlkesine Bağlı Kalma
UNMASK iznini yalnızca orijinal hassas verilere kesinlikle erişmesi gereken kullanıcılara/rollere verin ( — genel en iyi uygulama). Ayrıntılı (sütun düzeyinde, tablo düzeyinde) UNMASK izinleri kullanın.
Bu, saldırı yüzeyini en aza indirir. Maskelenmemiş verileri görebilen ne kadar az sorumlu varsa, maruz kalma riski o kadar düşük olur. UNMASK izinlerinin düzenli olarak gözden geçirilmesi, bunları dikkatli bir şekilde vermek kadar önemlidir.
Kullanıcı rolleri ve sorumlulukları değişir. Belirli bir proje için UNMASK erişimine ihtiyaç duyan bir kullanıcının proje bittikten sonra buna ihtiyacı olmayabilir. Kimin UNMASK izinlerine sahip olduğunun ve neden olduğunun periyodik denetimleri, "ayrıcalık kaymasını" önlemek ve en az ayrıcalık ilkesine sürekli bağlılığı sağlamak için kritik öneme sahiptir.
7.3. Hassas ve Maskelenmiş Verilere Erişim için Denetim Uygulama
Maskelenmiş ve maskelenmemiş verilere erişimi izlemek için SQL Server Denetimi'ni etkinleştirin. Bu, şüpheli etkinlikleri tespit eder, uyumluluk için bir denetim izi sağlar ve DDM'yi atlama veya UNMASK ayrıcalıklarını kötüye kullanma girişimlerini belirlemeye yardımcı olabilir.
Denetim, yalnızca maskelenmiş sütunlara sahip tablolara erişimi değil, özellikle UNMASK ayrıcalıklarının kullanıldığı zamanları da yakalamalıdır. KullaniciA'nın maskelenmiş sütunlara sahip bir tabloyu sorguladığını bilmek bir şeydir.
KullaniciA'nın onu sorguladığını ve UNMASK iznine sahip olduğu için maskelenmemiş verileri gördüğünü bilmek, hassas veri erişimi açısından daha önemlidir. Denetim yapılandırmaları, mümkünse bu ayrıntı düzeyini yakalamak için ince ayarlanmalıdır (örneğin, belirli eylemleri denetleyerek veya kullanıcı izinleriyle ilişkilendirerek).
7.4. Maskeleme Politikalarının Periyodik Olarak Gözden Geçirilmesi ve Bakımı
Gelişen veri ortamlarına ve güvenlik gereksinimlerine uyum sağlamak için maskeleme kurallarını sürekli olarak güncelleyin ve gözden geçirin. Veri sınıflandırması değişebilir, yeni hassas veri öğeleri eklenebilir veya düzenlemeler gelişebilir.
Maskeleme politikası incelemesi, daha büyük bir veri yönetişimi sürecinin parçası olmalıdır. DDM kuralları statik olmamalıdır. Bu inceleme süreci, DDM yapılandırmasının etkili ve kuruluşun mevcut risk duruşu ve veri işleme politikalarıyla ilgili kalmasını sağlamak için veri sahiplerini, güvenlik ekiplerini ve uyumluluk görevlilerini içermelidir.
Uygulama işlevselliğindeki değişiklikler de DDM politikası güncellemelerini gerektirebilir.
7.5. Yazma İzinleri için Uygun Erişim Kontrolü
Bir maske oluşturmak, sütuna yapılan güncellemeleri engellemez. Yazma izinlerine sahip kullanıcılar, sorgularken maskelenmiş verileri görseler bile maskelenmiş sütunları güncelleyebilir.
Güncelleme izinlerini sınırlamak için uygun erişim kontrolü kullanın. DDM, okuma erişimi gizlemesiyle ilgilidir, yazma engellemesiyle değil. Bu, yönetilmezse potansiyel bir veri bütünlüğü sorununu vurgular.
Bir kullanıcı maskelenmiş bir değer (örneğin, 'XXXX') görür ancak UPDATE iznine sahipse, istemeden (veya kötü niyetle) sütunu 'XXXX' ile güncelleyebilir ve böylece orijinal verileri bozabilir. Bu, DDM'nin katı INSERT, UPDATE, DELETE izin yönetimiyle eşleştirilmesi gerektiğini pekiştirir.
7.6. Veri Keşfini Dikkate Alma
Yüzlerce tablodaki potansiyel olarak binlerce sütun arasından hassas sütunları belirlemek bir ön koşuldur. Hassas olduğunu bilmediğiniz şeyi maskeleyemezsiniz.
Veri keşfi araçları veya süreçleri, kapsamlı DDM uygulaması için gereklidir. Büyük, karmaşık bir veritabanı ortamındaki tüm PII, finansal veriler, sağlık kayıtları vb.'ni manuel olarak belirlemek hataya açık ve zaman alıcıdır. Otomatik veri keşfi ve sınıflandırma araçları, DDM için aday sütunların belirlenmesinde önemli ölçüde yardımcı olabilir ve hassas verilerin gözden kaçırılmamasını sağlar.