İlginizi Çekebilir
  1. Ana Sayfa
  2. SQL Server
  3. SQL Server Row Level Security Nedir?

SQL Server Row Level Security Nedir?

RowLevelSecurity_Custom

Güvenlik, Bilgi işlem dünyasında başlı başına bir öneme sahiptir. Mevzu veritabanı güvenliği konusuna gelince ise hayati bir önem taşır. Çünkü veritabanı içerisinde bulunduğu organizasyonun tüm verileri ve bilgileri yer almaktadır. Düşünün, e-ticaret işi yapan şirkette görev alıyorsunuz ve veritabanı içerisinde müşteri bilgileri, siparişleri, ödemeleri gibi çok sayıda bilgi yer alıyor. Bu bilgilerin ise güvenliğini takip etmek ve sağlamak ise DBA ’in – Veritabanı Yöneticisinin- en önemli görevlerinden bir tanesidir. İşte bu yazıda 2016 ile kazanım sağladığımız ve sonraki sürümlerde yer alan güvenlik, şifreleme çözümlerinden bahsediyor olacağım. Unutmayın, burada ki özellikler aynı zamanda KVKK tarafında da bir noktada ihtiyacınız olacaktır. Makale içerisinde yer alan örnekleri kendiniz uygulamak isterseniz en az 2017 sisteminizde kurulu olması gerekiyor. Ücretsiz versiyon olarak Developer edition tercih edebilirsiniz. Benim sistemimde 2019 Developer edition kuruludur.

Server Row Level Security Nedir?

Satır düzeyinde güvenlik, SQL Server ’da uzun süredir talep edilen bir özelliktir ve Microsoft SQL Server 2016 ile tanıtımını gerçekleştirdi. Bu özelliği SQL Server 2016 ve sonraki tüm versiyon ve sürümlerde (Express, Standart ve Enterprise) kullanabilirsiniz.

() , bir çok müşteri için bir çok iş ihtiyacını karşılamaktadır. Dolayısıyla satır düzeyinde güvenlik hakkında birçok senaryo üretebiliriz. Birincisi, tüm müşterileriniz aynı tabloda olduğunda ve Satış sorumlusu kişilerin diğer müşterilerden gelen verileri görmeden bu tabloya göre rapor verebilmesi önemli bir ihtiyaçtır. Farklı bir örnek verecek olursak, bir hastane içerisinde bir hemşire düşünün. Bu hemşirenin sadece kendi hastalarına ait verileri görebilmesini, farklı hemşire üzerindeki verileri görmemesinin sağlanması ihtiyaç olabilir. Muhtemelen ben örnek verdikçe siz kendi uygulamalarınıza bunun nasıl uygulanacağını düşünerek senaryo üretiyorsunuzdur. Bu nedenle satır düzeyinde güvenlik – Row Level Security – tabloları yapılandırmanız olanak tanır. Böylece kullanıcılar sadece erişim izni verilmiş satırları görebilir. Normal şartlarda bu işlemi gerçekleştirmek için uygulama seviyesinde where koşulu ile işlem yapan kişiye göre sınırlama uygulamanız gerekirdi. Fakat Insert, Update ve Delete işlemlerini gerçekleştirirken sadece kendi sınırlaması içerisinde işlem yapmasını sağlamak hakkında farklı iş süreçleri üretmeniz gerekiyor olur. İşte burada SQL Server 2016 ile gelen Row Level Security – – sizin için biçilmiş kaftandır.

SQL Server Row Level Security için Dipnot: Bu özellik, size oturum bazında bir güvenlik sağlayacaktır.

Yukarıda bahsettiğimiz örneklerimizden birkaçı hakkında bu özelliği nasıl kullanırız anlatalım.

Örnek 1: Bir mağaza çalışanısınız ve gün sonunda ne kadarlık satış yaptığınızı görmek istiyorsunuz.

Bu yazı için ben oluşturduğumuz “DMC_SQLSecurity” isimli veritabanı kullanıp örnek veriyor olacağım. Siz bunu kendi tarafınızda uygularken değiştirmeyi unutmayın.

Örnek içerisinde kullanmak için 1 Satış Yöneticisi, 2 tane Satış temsilcisi oluşturmam gerekiyor.

İhtiyacım olacak kullanıcılarımı oluşturdum. Şimdi sırada bir Satış tablosuna ihtiyacım var. Hemen aşağıdaki kod ile oluşturalım.

Satis tablosunu oluşturduktan sonra aşağıdaki kod ile kayıt ekleyelim.

Kayıtların eklendiğini görelim.

Resim-1

Oluşturduğumuz kullanıcılarımıza Satis tablosu üzerinde verileri görebilmeleri için “Select” yetkisi verelim.

Satis tablosu üzerinde sorgulama yaptığımızda bize her iki satış temsilcisi arkadaşımızın da verilerin geldiği gördük. Şimdi satış temsilcilerin sadece kendi satışlarını görebilmelerini sağlamak için SQL Server Row Level Security – RLS – özelliğini kullanacağız. Bunun için de bize bir adet True değer döndüren bir Inline Table Value Function ihtiyacımız var.

Bu işlemden sonra oluşturduğumuz Inline fonksiyonu filter edecek bir policy oluşturmamız gerekiyor.

Oluşturduğumuz fonksiyon ve Policy kodlarını inceleyecek olursak; gördüğümüz üzere fonksiyonumuz parametre olarak kullanıcı adı alıyor ve geriye True ve NULL değerleri döndürüyor. POLICY bölümümüzde ise PRADICATE bölümünde oluşturduğumuz fn_RLS adında ki fonksiyonumuzu tablomuz üzerinde sorgu çalıştırıldığında otomatik olarak Filtrelemek için kullanılacağını ve hangi tablo üzerinde işlemi gerçekleştireceğini belirtiyoruz.

Şimdi bu tanımlamalar sonrasında Satis tablomuzu sorgulayalım.

Resim-2

Hatta öyle ki, bağlanıp işlemleri gerçekleştirdiğiniz kullanıcı ile Satis tablosunu sorgulamak isterseniz karşınıza kayıt gelmeyecekti.

Resim-3

Peki Satis tablosu boş mu? Değil tabi ki, SatisYapan bilgisine uygun bir kullanıcı geldiğinde select sorgusunun sonucu dönüyor, aksi taktirde yazdığımız Inline fonksiyondan null değeri döndüğü için ekrana değer gelmiyor.  Aklınıza hemen bu özelliği kullanmak adına SQL Server 2016 öncesi versiyonlarda nasıl uygulayacağız sorusu geliyorsa hemen onun da cevabını aşağıdaki örnek ile açıklayalım.

SQL Server 2016 öncesi Row Level Security nasıl Uygulanır?

Yukarıda Row Level Security kullanımı hakkında bir örnek gerçekleştirdik, şimdi aynı örnek konusu üzerinden SQL Server 2016 öncesinde nasıl bir kullanım yapabiliriz bunu anlatalım. Satis Temsilcilerimiz ve Satis yöneticilerimiz aynı olsun.

Örnek için çalışmaya başlamadan önce RLS örneğinde oluşturduğumuz Satis tablosunu drop edelim. Drop etmeden önce oluşturduğumuz policy off yapmamız gerekiyor.

Drop işlemini yaptık, şimdi örneğimiz için tekrar çalışmaya başlayabiliriz. Benzer örnek için yine Satis tablosu oluşturup içerisine örnek kayıtlar ekleyelim.

Satis tablosunu sorgulayalım.

Resim-4

RLS özelliğini kullanamayacağımız için bir user mapping tablosuna ihtiyacımız var.

Mapping tablosuna kayıt ekleyelim.

Şimdi Satis tablosu ile Mapping tablosunu eşleştirmesini yapacağımız ve satışları raporlayacağımız view oluşturalım.

Daha önce tanımlamasını yaptığımız kullanıcılarımızı v_satis isimli view select edebilmeleri için yetkilerini veriyoruz.

Yetki tanımlamasını gerçekleştirdikten sonra SatisTemsilcisi1 kullanıcısı ile hem Satis tablosunu hem de v_satis isimli view sorgulayalım.

Resim-5

Yukarıdaki resimde gördüğümüz üzere kullanıcımızın Satis tablosunu görmeye yetkisi yok. Şimdi v_satis için sorgulama yapalım.

Resim-6

SatisTemsilcisi2 ve SatisYoneticisi kullanıcılarımız ile v_satis sorgulayalım.

Resim-7

Resim-8

Resim-7 ve Resim-8 de görüldüğü üzere sorgulama sonucu boş geldi, sebebi çünkü view içerisinde yaptığımız mapping tanımlamasıdır. Eğer ki SatisYoneticisi için view de değişiklik yaparsanız satistemsilcisi1 işlemleri görebilir.

Tekrar SatisYoneticisi ile sorguluyoruz.

Resim-9

SQL Server Row Level Security – RLS – hakkında detaylı bilgiyi yukarıda edindiniz. Bir sonraki yazımız SQL Server encryption – SQL Server da Şifreleme- konusunu anlatıyor olacağım.

 

Yorum Yap

Yazar Hakkında

Milenyumdan beri ilginç bir merak duygusu ile başlayan bilgisayar ve teknoloji dünyası merakı sayesinde eğitim yaşantımı doğup büyüdüğüm Düzce'de geçirdim. Sonrasında Düzce'nin kendimi geliştirmek adına yeterli imkanlara sahip olmadığından İstanbul'a gelip Bilge Adam Eğitim Kurumlarından Yazılım ve Veritabanı eğitimi aldım. Eğitimimi tamamlarken çeşitli Windows ve Web uygulamaları geliştirdim. Sırası ile Sentez Yazılım, Nebim Yazılım, Ciceksepeti, Doğan Holding, Kariyer.Net, TurkNet gibi firmalarında Yönetici / Müdür pozisyonlarında farklı ünvanlarda ( Yazılım Geliştirici / Raporlama ve Veritabanı Yöneticisi gibi) görev aldım. Şimdilerde ise DMC Bilgi Teknolojileri firmasının Kurucu Ortaklığını ve Veritabanı Danışmalığı Hizmeti vermekteyim.

Yorum Yap