Önceki yazılarda bahsettiğim RLS, yani Row Level Security, modeldeki verileri kullanıcının kimliğine göre filtrelemek için kullanabileceğiniz bir yöntem. Eğer ihtiyacımız kullanıcıdan bazı tablo ve sütunları ve hatta metrikleri gizlemekse bunun için kullanabileceğimiz yöntem OLS, yani Object Level Security. OLS, adı üstünde “objeler” üzerinden bir gizleme yöntemi. X kullanıcı grubu satışları görsün ama maliyetleri görmesin demek istiyorsak kullanmamız gereken yöntem OLS, RLS değil!
Yazı İçeriği
OLS Nerede Tanımlanır?
OLS tanımlamak -mevcut durumda- Power BI Desktop ile mümkün değil! External araçlardan biri olan Tabular Editor ile mümkün sadece. Eğer developer profilindeyseniz DAX Studio ile birlikte olmazsa olmaz araçlardan biri. TE 3 ücretli bir uygulama, ama Tabular Editor 2 ücretsiz. Uygulamayı kurduğunuzda Power BI Desktop’taki External Tools menüsünde gözükecektir. Eğer tıklarsanız da ilgili Power BI dosyanızın TOM modelini açar.
OLS’nin detaylarına girmeden önce bir kaç noktaya değinmekte fayda var: OLS gibi calculation groups oluşturma da desktop uygulamasında henüz yok. Benzer şekilde Azure ya da on-prem Analysis Service’te olan perspektif, translations ve partitioning özellikleri de doğrudan desktop ile -mevcut durumda- kullanılamıyor. Eğer bu özellikler projeniz için kritikse iki opsiyonunuz var: Tabular Editor kullanmak ya da SQL Server Data Tools ile modelinizi Analysis Service üzerinde kurmak. Microsoft, Power BI Premium servisini Analysis Service’in tepesinde konumlandırdı. Premium serviste olan ama Azure/on-prem Analysis Service’te olmayan özellikler var.
Dolayısıyla kurumsal bir proje için orta uzun vadede Power BI Premium daha uygun bir seçim olabilir. Eğer Premium sizin için fazlasıyla pahalı bir seçenekse Premium Per User öneririm. Tabular Editor, hem pbix, hem Azure/on-prem Analysis Service hem de Premium servisteki datasetleri/modelleri düzenlemek için kullanılabilecek -mevcut durumda- en ideal editör.
Her ne kadar Microsoft “ben bu programı tanıyorum” dese de, bazı şirketler/kurumlar 3. parti uygulamaları kullandırmakta gönülsüz davranabiliyor! Eğer böyle bir durum varsa ve tek bir modelde OLS-vari bir durum yaratmak istiyorsanız, yapabileceğiniz yegane şey USERNAME, USERPRINCIPAL gibi fonksiyonlarla kullanıcının kim olduğunu tespit edip ona göre metriklerinizi modifiye etmek olabilir.
Diyelim bir Maliyet metriğiniz var ve bazı kullanıcıların bu metriği görmesini istemiyorsunuz. Kullanıcıyı yakalayıp bunu formülünüze uygun şekilde gömebilirsiniz.
Kullanıcı = USERPRINCIPALNAME()
Maliyet =
IF( [Kullanıcı] = "pbi@powerbi.istanbul" ,
BLANK() ,
SUMX('Satışlar' , 'Satışlar'[Miktar] * 'Satışlar'[Birim Maliyet] )
)
Formüle gömdüğümüz kullanıcılar maliyet bilgisini boş olarak görecektir.
Eğer uzun bir kullanıcı listesi varsa, rapora erişen kullanıcının bu listede olup olmadığını kontrol ederek de yapabilirsiniz, artık mevcut yapınız neyse. Kullanıcılar diye bir tablo ve bu tabloda da bazı metrikleri görmesini istemediğimiz kullanıcıların listesi olsun diyelim.
1 ya da 0 döndüren bir kontrol metriği yazıp bunu görülmesini istemediğiniz diğer metriklere gömebilirsiniz.
Kullanıcı Testi =
VAR _Kullanici = USERPRINCIPALNAME()
VAR _MetrigiGorsunGormesin =
IF(
_Kullanici IN VALUES('Kullanıcılar'[Kullanıcı Listesi] ) ,
0,
1
)
RETURN
_MetrigiGorsunGormesin
Maliyet-2 =
SUMX(
'Satışlar',
'Satışlar'[Miktar] * 'Satışlar'[Birim Maliyet]
) * [Kullanıcı Testi]
…
Tam bir güvenlik çözümü olmamakla birlikte yaratıcı bazı teknikler kullanarak kullanıcılara sadece görmelerini istediğiniz rapor sayfalarını da gösterebilirsiniz! Microsoft Türkiye’den Mustafa Aşıroğlu‘nun bu yazısına bir göz atmanızı öneririm!
…
OLS’nin detaylarına geçelim!
Tabular Editor ile iki farklı objeye OLS atamak mümkün: Tablolar ve sütunlar. Metriklere doğrudan OLS ataması yapamıyoruz ama dolaylı olarak atayabiliriz. Ama öncelikle sırf OLS için kullanmak amacıyla bir rol yaratmamız lazım.
Tablo Seviyesinde OLS
Bir tablonun tamamını gizlemek için rollerden OLS için yarattığımız rolü seçip, Security bölümündeki “Table Permissions” ‘tan gizlemek istediğimiz tabloyu seçip listeden “None” dememiz yeterli.
Örneğe göre “Ürün Kategorileri” tablosunu gizledik.
Bu rolü test ettiğimizde “Ürün Kategorileri” tablosundaki herhangi bir sütunu içeren bütün görseller “patlayacaktır” !
Çünkü artık modelde “Ürün Kategorileri” diye bir tablo ve dolayısıyla sütunları yok!
Benzer şekilde, bu tabloyu veya bu tablodaki herhangi bir sütunu refere eden metrikler varsa onlar da uçacaktır.
Misal, modelde kategori sayısını sayan basit bir metrik olsun:
Kategori Sayısı = COUNTROWS('Ürün Kategorileri')
OLS rolünü test ettiğimizde bu metriğin de modelden uçtuğunu görürüz.
Tablo seviyesinde OLS ataması yaparken bazı kısıtlamalar var!
İlişki zincirini kıran bir tabloyu gizleyemiyoruz. Örnek resimden gidecek olursak, A-B-C tabloları birbiriyle ilişkili. B tablosunu gizlemek ilişki zincirini kıran bir durum, bu yüzden B tablosuna OLS ataması yapamayız. Ancak A ile C tabloları arasında başka bir ilişki yaratabilirsek B tablosunu gizleyebiliriz.
Sütun Seviyesinde OLS
Sütunlara OLS atanması da aynen tablolarda olduğu gibi! “Satışlar” tablosunda “Birim Maliyet” sütunu var. Bu sütunu gizlemek için “Tables” –> “Satışlar” –> “Birim Maliyet” seçip, Object Level Security’den OLS rolü için “None” demek yeterli.
“Birim Maliyet” sütunu modelden uçacaktır. Artı, aynen tablolarda olduğu gibi, bu sütunu refere eden bir metriğimiz varsa bu da modelden uçacaktır.
Maliyet OLS =
SUMX('Satışlar' , 'Satışlar'[Miktar] * 'Satışlar'[Birim Maliyet] )
Metrik Seviyesinde OLS
Metriklere doğrudan OLS ataması yapamıyoruz, ama yukarıdaki örneklerde gördüğümüz gibi dolaylı atama yapabiliyoruz. Birim maliyet sütununu gizle, bu sütunu dolaylı/dolaysız refere eden bütün metrikler modelden uçsun!
Güzel!
Peki, ya aşağıdaki gibi bir durum olursa ne yapacağız?
Modelde [Satışlar] metriği var, tüm kullanıcıların görmesini istediğimiz. Ve bu metriğe bağlı -diyelim- bir [Prim] metriğimiz var.
Prim = [Satışlar] * 0.9
Satışlar herkesin görmesini istediğimiz bir metrik, ama Prim tutarını herkesin görmesini istemiyoruz. Satışlar metriğinin refere ettiği bir sütuna OLS ataması yapsak her şey uçacak!
Bu tür bir durumda yapabileceğimiz iki şey var:
İlki: [Prim] metriğini, bir başka fiktif tabloya al ve bu tabloya OLS ataması yap!
İkincisi: [Prim] metriğinin formülünde, OLS ataması yaptığımız sütunlardan herhangi birini refere et.
Prim OLS =
VAR _BirimMaliyet = AVERAGE('Satışlar'[Birim Maliyet])
RETURN
[Satışlar] * 0.9
OLS ile gizlediğimiz -misal- birim maliyet sütununun adının bir şekilde geçmesi bile [Prim] metriğinin modelden uçmasına yetecektir! Maliyet sütunuyla ilgili ne yazdığımızın bile bir önemi yok! Yeter ki sütunun adı geçsin!
Bir Kullanıcı hem OLS hem de RLS rolüne atanabilir mi?
Hayır!
RLS rolleri yarattığımızda, bir kullanıcıyı birden fazla RLS rolüne atamak mümkün! Diyelim “Ev Aletleri” ve “Kameralar” diye iki tane RLS rolümüz var, herhangi bir kullanıcıyı her iki role de atadığınızda, ilgili kullanıcı hem Ev Aletleri hem de Kameralar kategorisindeki satışları görür.
Ama OLS rollerini RLS rolleriyle mix edemiyoruz. Yani bir kullanıcı ya RLS rollerine üyedir, ya da OLS rolüne. Hem birim maliyeti görmesin, hem de sadece “Ev Aletleri” kategorisinin satışlarını görsün deme ihtiyacımız varsa, OLS için tanımladığımız rolde “Kategori” sütununa = “Ev Aletleri” dememiz lazım!
…
Row Level Security ve Object Level Security, Power BI ekosistemindeki birbirini tamamlayan iki farklı otorizasyon sistemi, bunlardan başka bir otorizasyon yöntemi -mevcut durumda- yok. Eğer karmaşık, kompleks bir kullanıcı otorizasyonu ihtiyacınız varsa bunu çözmek için birden fazla dataset/veri modeli oluşturmayı tercih etmiş olabilirsiniz. Yönetimi daha kolay olabilir duruma göre. Eğer birden fazla datasetiniz/modeliniz varsa bu durumlar için, dataflow’ları kullanmayı, eğer Premium lisansınız varsa datamart’ları kullanmayı tavsiye ederim. Aksi taktirde aynı veriyi -gereksiz yere- birden fazla buluta gönderiyor olabilirsiniz!
Yazıdaki modeli -bloga üyeyseniz- indirebilirsiniz.
Sadece üyeler görebilir. Hızlı üyelik için sosyal medya hesabınızla giriş yapabilirsiniz!