Derinlemesine yazılım eğitimleri için kanalımı takip edebilirsiniz...

SQL Server 2016 – Row Level Security

Merhaba,

Veritabanı yönetim sistemlerinde amacımız; düzenli, organize edilmiş ve ilişkisel bir şekilde verilerimizi modifiye etmektir. Bu amacı icra ederken güvenlik birinci dereceden önem teşkil etmekte ve çeşitli yöntemlerle güvenlik mekanizması sağlanmaktadır. Bu yöntemler genellikle kullanıcı rol ve yetkilendirmeleriyle sağlanmaktayken, verilere dönük olarakta view gibi yapılarla gerçekleştirilmektedir.

SQL Server’da hangi kullanıcının hangi tablo üzerinde hangi işlemi yapabileceğini belirleyebiliyorduk. Lakin kullanıcıların kendilerini ilgilendiren verileri görmesini belirleyemiyorduk. Ta ki, SQL Server 2016 ile gelen Row Level Security özelliği gelene kadar…

Şöyle bir örnek üzerinden anlatım yaparsak konuyu oldukça kısa tutacağımız kanaatindeyim. Bir tablo ve bu tablo üzerinde yetkilendirilmiş birden fazla kullanıcı düşünün. Row Level Security özelliği ile her yetkili kullanıcı sadece kendisine ait kayıtları sorgulayabilecektir. Biz genellikle bu işlem için bir Stored Procedure yahut Function ile parametre olarak alınan kullanıcı adına özel olarak verileri seçiyorduk. Artık bu işlemi daha teknik boyutta gerçekleştireceğiz…

Yani anlayacağınız Row Level Security özelliği ile kullanıcılara tablo üzerinde yetki verirken tüm kayıtlara değil sadece kendisini ilgilendiren kayıtlara özel bir yetkilendirme yapıyor olacağız.

Şimdi aşağıdaki gibi veritabanımızı, tablomuzu ve verilerimizi oluşturalım.

CREATE DATABASE Yenilikler

USE Yenilikler

CREATE TABLE Satislar
(
	SatisID INT PRIMARY KEY IDENTITY,
	Urun NVARCHAR(MAX),
	Adet INT,
	Kullanici NVARCHAR(MAX)
)

INSERT Satislar VALUES
('AUrun', 3, 'Gencay'),
('BUrun', 5, 'Mehmet'),
('CUrun', 13, 'Ali'),
('DUrun', 23, 'Gencay'),
('EUrun', 33, 'Mehmet'),
('FUrun', 43, 'Ali'),
('GUrun', 53, 'Gencay'),
('HUrun', 63, 'Mehmet'),
('IUrun', 73, 'Ali'),
('OUrun', 83, 'Gencay'),
('PUrun', 93, 'Mehmet'),
('RUrun', 133, 'Ali')

Dikkatinizi çekerim ki, “Satislar” tablosundaki “Kullanici” kolonuna “Gencay”, “Mehmet” ve “Ali” değerlerini ekliyorum. Şimdi bu isimlerde kullanıcıları fiziksel olarak oluşturalım.

CREATE USER Gencay WITHOUT LOGIN
CREATE USER Mehmet WITHOUT LOGIN
CREATE USER Ali WITHOUT LOGIN

Şimdi bu kullanıcılarımıza “Satislar” tablosuna özel “Select” yetkisi verelim.

GRANT SELECT ON Satislar TO Gencay
GRANT SELECT ON Satislar TO Mehmet
GRANT SELECT ON Satislar TO Ali

Bu işlemlerden sonra ilgili kullanıcılarımızın herhangi biriyle tablomuzda select işlemi yaptığımızda aşağıdaki gibi tüm verilerin geldiğini göreceğiz.

SQL Server 2016 - Row Level Security

Bunun sebebi doğal olarak daha Row Level Security özelliğini kullanmadığımızdan kaynaklanmaktadır.

Şimdi Row Level Security özelliğini kullanabilmemiz için Inline Table Value Funtion oluşturmalıyız. Bu fonksiyon, kullanıcı sorguyu çalıştırdığında geriye 1 yani true değerini dönecek bir içerikte olmalıdır.

CREATE FUNCTION RowLevelSecurityFunction (@KullaniciAdi as sysname)
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN SELECT 1 AS rowLevelResult
WHERE @KullaniciAdi = USER_NAME()

Şimdi bu fonksiyonu, birazdan oluşturacağımız Security Policy(Güvenlik Politikası) için Filter Predicate olarak ekliyoruz. Yani uzun lafın kısası filtre olarak ayarlıyoruz.

CREATE SECURITY POLICY GuvenlikFiltresi
ADD FILTER PREDICATE dbo.RowLevelSecurityFunction(Kullanici)
ON dbo.Satislar
WITH (STATE = ON);

Burada dikkat etmemiz gereken bir kaç husus var. Yukarıda oluşturduğumuz “RowLevelSecurityFunction” isimli fonksiyon aracılığıyla “Satislar” tablosundaki “Kullanici” kolonunu filtre olarak ayarlıyoruz. Bir diğer nokta ise burada kullanılan tüm yapıların şema adlarını(.dbo) girerek çalışmanızı tavsiye ediyorum.

Şimdi bu işlemlerden sonra sıra sorgulama adımına geldi.
SQL Server 2016 - Row Level Security
Görüldüğü üzere “Gencay” kullanıcısıyla bir select sorgusu çalıştırdığımda gelen tablo ilgili kullanıcıya özel verileri barındıran tablo olmaktadır.

Keza diğer kullanıcılarda da benzer şekilde sonuçlar alınacaktır.

SQL Server 2016 – Row Level Security SQL Server 2016 – Row Level Security

Şimdi görüldüğü gibi select sorgumuza “where Kullanici = ‘…’” parametresini eklemediğimiz halde Row Level Security özelliği arkaplanda ilgili parametreyi eklemektedir. Haliyle bu işlemi oluşturmuş olduğumuz Security Policy nesnesi gerçekleştirmektedir.

Evet, bir yazımızın daha sonuna gelmiş bulunmaktayız. Umarım bol bol faydalanırsınız.

Sonraki yazılarımda görüşmek üzere…
İyi çalışmalar dilerim…

Bunlar da hoşunuza gidebilir...

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir