Row-Level Security (RLS): Power BI'da Kurumsal Yetki Yönetimi

"Genel Müdür tüm satışı görmeli, bölge müdürleri sadece kendi bölgesini, saha temsilcileri sadece kendi müşterilerini." Bu ihtiyaç, Power BI'ın Row-Level Security (RLS) özelliğiyle karşılanır. Doğru kurgulanmış RLS, tek rapor + tek dataset ile onlarca farklı yetki seviyesini yönetmenizi sağlar; yanlış kurgu ise güvenlik açığı yaratır ve performansı bozar. Bu yazıda static ve dynamic RLS'yi, USERPRINCIPALNAME kullanımını ve saha uygulamalarını detaylı ele alacağız.

01. RLS Nedir ve Ne Çözer?

Row-Level Security, veri modeline uygulanan filtreler aracılığıyla, aynı raporun farklı kullanıcı tarafından farklı satır kümesiyle görülmesini sağlar. Yönetici yorgun düşerek 10 farklı rapor kopyalamak yerine tek rapor kurar; roller ve filtreler ayrımı yapar.

RLS iki katmanda çalışır:

• Model katmanı: hangi rolün hangi satırları göreceği DAX filtreleriyle tanımlanır
• Service katmanı: hangi kullanıcının hangi role atandığı Power BI Service'te yönetilir

Bu iki katman doğru bağlanmazsa kullanıcı ya hiç veri görmez ya da yetkisi olmayan veriye erişir.

02. Static RLS: Basit ama Ölçeklenmez

Static RLS'te her rol için DAX filtresi elle tanımlanır. Örneğin:

• "Marmara Rolü" için: [Bölge] = "Marmara"
• "Ege Rolü" için: [Bölge] = "Ege"
• "İstanbul Bayi Rolü" için: [Bölge] = "Marmara" && [Şehir] = "İstanbul"

Bu yaklaşım az sayıda rol için (2-5) çalışır ama 20+ rolde yönetimi cehenneme döner. Yeni bölge eklendiğinde model güncellemesi ve yeniden yayınlama gerekir.

03. Dynamic RLS: Ölçeklenebilir Doğru Yaklaşım

Dynamic RLS'te tek bir rol tanımlanır ve filtre, giriş yapan kullanıcının kim olduğuna göre çalışır. USERPRINCIPALNAME() fonksiyonu, oturum açan kullanıcının e-postasını döner. Bu değer, "Kullanıcılar" adında bir security tablosuyla eşleştirilir:

• Kullanıcılar tablosu: [E-posta], [Kullanıcı Adı], [Bölge], [Bayi Kodu], [Rol]
• DAX filtresi (Bölge dimension'ında): [Bölge] IN CALCULATETABLE(VALUES(Kullanıcılar[Bölge]), Kullanıcılar[E-posta] = USERPRINCIPALNAME())

Yeni kullanıcı eklenince modeli değiştirmezsiniz; sadece Kullanıcılar tablosuna satır eklersiniz.

04. Security Tablosu Tasarımı

Dynamic RLS'in kalbi security tablosudur. İyi tasarlanmış bir security tablosu:

• Kullanıcı-erişim ilişkisini net gösterir (bir kullanıcı birden çok bölgeye erişebilir)
• Ana dimension tablolarıyla ilişkilendirilebilir
• Değişiklikleri kolay yönetilir (Excel, SharePoint veya SQL kaynaklı)
• Rol hiyerarşisini destekler (Genel Müdür = tüm bölgeler)

Genel Müdür rolü için tipik uygulama: security tablosunda "*" sembolü veya boş bırakılmış filtre alanı; DAX'ta "eğer * ise tümü görülür" mantığı işlenir.

05. Test ve Doğrulama Süreci

RLS uygulandıktan sonra "yayınladık, çalışıyor mudur" varsayımıyla ilerlemek tehlikelidir. Test adımları:

• Power BI Desktop'ta "View as roles" özelliği ile her rol için önizleme
• Service'te farklı e-posta hesaplarıyla giriş yaparak canlı test
• Rapordaki toplam değerin kullanıcıya göre değişmesi doğrulanmalı
• Kullanıcı yetki dışı bir dimension'a filtre uyguladığında sıfır satır gösterildiği doğrulanmalı
• Performansın etkisi ölçülmeli (RLS'li sorgu, RLS'siz sorgudan %10-30 yavaş olabilir)

06. Object-Level Security (OLS) ile Fark

RLS satırları gizler ama tüm sütunlar görülür. Bazı senaryolarda sütun bazlı gizleme gerekir: bordro tablosundaki maaş sütununu sadece İK'nın görmesi gibi. Bu ihtiyaç için Object-Level Security (OLS) kullanılır.

OLS, Tabular Editor gibi harici bir araçla tanımlanır; Power BI Desktop'ta arayüzü henüz yoktur. Enterprise senaryolarda RLS + OLS birlikte kullanılır: satır bazlı yetki + hassas sütunların rol bazlı gizlenmesi.

07. Yaygın Tuzaklar

RLS uygulamasında sık yapılan hatalar:

• USERPRINCIPALNAME sonucunun Kullanıcılar tablosundaki e-postayla birebir eşleşmemesi (küçük-büyük harf, boşluk)
• Bidirectional ilişkiyle security tablosunu bağlamak: performans çöker
• RLS'yi Composite modelde (DirectQuery + Import karışık) test etmeden yayınlamak
• Excel export'u unutmak: rapordan Excel'e çıkan veri RLS filtresine uyar ama teknik ekibin veriye direct DB erişimi RLS'yi devre dışı bırakır
• Şablon (template) raporlarda RLS'yi Service yayınından sonra yeniden tanımlamamak