POWER BI ROW-LEVEL SECURİTY (RLS): MODEL ÜZERİNDE YETKİLENDİRME KURGUSU
Aynı raporu herkes açıyor ama herkesin gördüğü sayılar farklı olmalı: Bölge müdürü yalnızca kendi bölgesini, bayi yalnızca kendi satışını, İK yalnızca kendi birimini… Power BI Row-Level Security (RLS) tam bu ihtiyacı, rapor sayfalarını çoğaltmadan ve veri kopyalamadan çözer.
RLS’i “sayfayı gizleme” gibi düşünmek yanıltıcıdır; RLS, model katmanında satır bazlı filtre uygular. Yani kullanıcı raporu hangi görselle açarsa açsın, modelin izin verdiği satırların dışına çıkamaz. Bu nedenle doğru kurgu, yalnızca güvenlik değil, aynı zamanda sürdürülebilirlik ve performans meselesidir.
Bu yazıda Power BI’da RLS’in mantığını, statik ve dinamik yaklaşımları, DAX ile gerçekçi örnekleri, servis tarafındaki dağıtım ve test adımlarını, ayrıca en sık yapılan hataları model odaklı bir bakışla ele alacağız. Daha sistematik bir öğrenme için Power BI Eğitimi sayfasına da göz atabilirsiniz.

Power BI Row-Level Security (RLS) nedir, neyi garanti eder?
Power BI Row-Level Security, veri modelindeki tablolar üzerinde tanımladığınız filtre kurallarıyla, kullanıcıların satır seviyesinde hangi veriyi görebileceğini belirler. Kullanıcı rapora erişse bile, modelin izin vermediği satırlar sorgu sonucuna dahil edilmez.
RLS’in güçlü yanı, güvenliği rapor sayfasına değil modele bağlamasıdır. Bu, aynı veri modeliyle farklı kitlelere güvenli dağıtım yapmayı mümkün kılar. Ancak unutmayın: RLS, veri kaynağındaki erişim yönetiminin yerine geçmez; özellikle DirectQuery senaryolarında kaynağın da uygun şekilde korunması gerekir.
RLS ile “görsel gizleme” arasındaki fark
Rapor sayfalarını gizlemek ya da bir dilimleyiciyi kilitlemek, güvenlik değildir; yalnızca arayüz davranışıdır. RLS ise sorgu sonucunu değiştirir. Kullanıcı, dışa aktarma veya “Analyze in Excel” gibi yollarla da modelin dışına çıkamaz (yetkileri ayrıca kontrol etmek şartıyla).
RLS’in sınırları: kimlik, izin ve paylaşım modeli
Power BI Service’de RLS, kullanıcı kimliğini (Azure AD/Entra ID) esas alır. Raporu paylaştığınız alan (Workspace, App, Dataset izinleri) yanlış kurgulanırsa, model doğru olsa bile yetki sızıntısı yaşanabilir. Bu yüzden RLS, paylaşım ve rol dağıtımıyla birlikte düşünülmelidir.
Yetkilendirme kurgusunun temeli: model tasarımı ve ilişki stratejisi
İyi bir RLS tasarımı için önce modelin “kim neyi görür?” sorusunu net bir şekilde temsil etmesi gerekir. En iyi sonuç, yıldız şema (fact + dimension) düzeninde alınır: filtreler mümkün olduğunca boyut tablolarında tanımlanır ve fact tabloya ilişkiler üzerinden yayılır.
Yıldız şema ile RLS’i sadeleştirme
Örneğin Sales fact tablosu ve Region dimension tablosu olan bir modelde, rol filtresini Region üzerinde kurmak genellikle daha okunaklı ve bakımı kolaydır. Fact üzerinde filtre yazmak, hem performansı zorlayabilir hem de kuralın kapsamını karmaşıklaştırabilir.
Bridge tablolar ve many-to-many senaryolar
Gerçek hayatta bir kullanıcı birden fazla bölgeden sorumlu olabilir. Bu durumda “Kullanıcı-Bölge Eşlemesi” gibi bir bridge tablo ile dinamik RLS kurgulanır. Burada kritik nokta, ilişkinin yönü ve filtre yayılımıdır. Gereksiz çift yönlü ilişkiler, beklenmedik filtre davranışlarına yol açabilir.
Hangi tabloda filtre yazmalı?
- Öncelik: Boyut tabloları (müşteri, bölge, bayi, departman gibi).
- Bridge varsa: önce bridge üzerinde kullanıcı filtresi, sonra ilgili boyuta filtre yayılımı.
- Fact üzerinde filtre: yalnızca zorunlu durumlarda ve kural basitse.
Statik RLS ve dinamik RLS: doğru yaklaşımı seçmek
RLS kuralları iki ana yaklaşımla kurulabilir: statik (role üyeleri tek tek atanır) ve dinamik (kural, oturum açan kullanıcıya göre çalışır). Organizasyon büyüdükçe statik yaklaşım yönetilmesi zor bir listeye dönüşür; dinamik yaklaşım ise doğru tasarlanırsa oldukça ölçeklenebilir.
Statik RLS ne zaman mantıklı?
Kullanıcı sayısı azsa, roller çok net ayrışıyorsa ve erişim listesi nadiren değişiyorsa statik RLS işe yarar. Örneğin yalnızca üç yönetim rolü (Yönetim, Finans, Operasyon) gibi.
Dinamik RLS’in avantajı ve tipik kurgu
Dinamik RLS’de modelde bir “Yetki” tablosu bulunur: Kullanıcı e-postası, sorumlu olduğu bölge/bayi/departman anahtarlarıyla eşleştirilir. Kural, oturumdaki kullanıcıyı yakalayıp bu eşleşmeye göre filtre uygular. Böylece kullanıcı değişse bile model kuralı değişmez; sadece yetki tablosu güncellenir.
DAX ile RLS kuralları: gerçekçi örnekler
Power BI Desktop’ta Modeling > Manage roles ekranında her rol için bir veya daha fazla tabloya filtre ifadesi yazarsınız. Bu ifadeler DAX’tır ve satır bağlamında değerlendirilir. En yaygın dinamik yaklaşım, kullanıcı e-postasını USERPRINCIPALNAME() ile yakalamaktır.
Örnek 1: Bölge bazlı dinamik RLS (bridge tablosu ile)
Varsayım: DimRegion (RegionId, RegionName), FactSales (RegionId, Amount, DateId...), SecurityUserRegion (UserEmail, RegionId) tabloları var. İlişkiler: SecurityUserRegion[RegionId] → DimRegion[RegionId] (tek yön), DimRegion[RegionId] → FactSales[RegionId] (tek yön).
// ROL: BölgeErişimi
// Tablo: SecurityUserRegion
SecurityUserRegion[UserEmail] = USERPRINCIPALNAME()Bu kural SecurityUserRegion tablosunu oturum açan kullanıcıya indirger; ilişkiler üzerinden DimRegion ve FactSales otomatik filtrelenir. Böylece kullanıcı yalnızca atandığı RegionId’lerin satışlarını görür.
Örnek 2: Bayi bazlı erişim + “herkes kendi bayisini görsün” kuralı
Varsayım: DimDealer (DealerId, DealerName), SecurityUserDealer (UserEmail, DealerId). Aynı mantıkla rol filtresini SecurityUserDealer üzerinde kurarsınız.
// ROL: BayiErişimi
// Tablo: SecurityUserDealer
SecurityUserDealer[UserEmail] = USERPRINCIPALNAME()Bu yaklaşımın en güzel yanı, bayi değişikliklerinde raporu yeniden yayınlamadan, yalnızca yetki tablosunu güncelleyerek (ETL/refresh ile) yeni erişimi devreye alabilmenizdir.
Örnek 3: Yönetici “tümünü görsün” istisnası
Bazen bir rol içinde istisna gerekir: belirli e-postalar tüm veriyi görsün. Bunu DAX’ta kontrollü şekilde yapabilirsiniz; ancak kural karmaşıklaştıkça okunabilirlik düşer. Bu nedenle mümkünse “Admin” gibi ayrı bir rol tercih edilir.
Yine de tek rolde çözmek gerekirse, yetki tablosuna “IsAdmin” alanı eklemek daha sürdürülebilirdir. Örneğin SecurityUserRegion’da IsAdmin = 1 olan kullanıcılar için filtreyi esnetebilirsiniz. Bu tür esnetmelerde test şarttır.
RLS test etme: Desktop ve Service tarafında güvenilir kontrol
RLS’i yazdıktan sonra “doğru çalışıyor mu?” sorusunu iki yerde yanıtlamalısınız: Desktop’ta rol simülasyonu ve Service’de gerçek kullanıcı bağlamı. Desktop’taki “View as” testleri hızlıdır, ancak Service’deki paylaşım ve izin modeliyle birleşince farklı sonuçlar oluşabilir.
Power BI Desktop’ta “View as” ile rol simülasyonu
Desktop’ta Modeling > View as ile rolü seçip raporu o bağlamda görürsünüz. Dinamik RLS kullanıyorsanız, Other user alanına test etmek istediğiniz e-posta adresini girerek USERPRINCIPALNAME() davranışını simüle edebilirsiniz.
Power BI Service’de “Test as role” ve paylaşım kontrolleri
Dataset yayınlandıktan sonra Service’de dataset ayarlarında roller görünür. Burada kullanıcıları rollere atar ve test edersiniz. Ayrıca raporun kimlerle paylaşıldığı, App üzerinden dağıtım yapılıp yapılmadığı, kullanıcıların dataset üzerinde “Build” izni olup olmadığı gibi detaylar, nihai güvenliği doğrudan etkiler.

Güvenlik tasarımında kritik noktalar: izinler, dışa aktarma ve “Build” hakkı
RLS, “kim neyi görür” kısmını çözer; fakat “kim neyi yapar” kısmı da en az onun kadar önemlidir. Kullanıcıların rapor üzerinde veri dışa aktarması, dataset üzerinden yeni rapor üretmesi ya da farklı araçlarla bağlanması gibi senaryolar, yönetişim gerektirir.
Dataset izinleri ve “Build” hakkı
Dataset üzerinde “Build” izni olan kullanıcılar, veri modelini kullanarak yeni raporlar oluşturabilir. RLS yine uygulanır, ancak yönetişim açısından bu yetkiyi kontrollü vermek gerekir. Eğer amaç yalnızca raporu tüketmekse, App üzerinden yayınlamak çoğu zaman daha temiz bir dağıtım yaklaşımıdır.
Export, Analyze in Excel ve hassas veri riski
Kurumsal politikanıza göre dışa aktarma seçeneklerini sınırlandırmanız gerekebilir. RLS, kullanıcıya gösterilmeyen satırları zaten çıkartır; ancak görünen satırların dışa aktarımı hâlâ mümkündür. Bu nedenle hassas alanlar için ek maskeleme, veri sınıflandırma ve tenant ayarları gündeme gelebilir.
Performans ve bakım: sürdürülebilir bir RLS mimarisi
RLS ifadesi her sorguda çalıştığı için, gereksiz karmaşıklık performansı etkiler. Özellikle çok büyük güvenlik eşleme tablolarında (on binlerce kullanıcı eşlemesi) modelin tasarımı ve ilişkiler hayati hale gelir. Amaç, filtreyi en hızlı şekilde ilgili boyutlara yaymak ve fact üzerinde minimum hesap yükü oluşturmaktır.
İyi pratikler: basit kural, doğru tablo, doğru ilişki
- Dinamik RLS’i mümkünse bridge tablo üzerinden kurun; USERPRINCIPALNAME() ile filtreyi daraltın.
- Çift yönlü ilişkiyi son çare olarak düşünün; gerekirse ayrı bir boyut/bridge tasarlayın.
- Yetki tablosunda anahtarları sayısal tutun (RegionId, DealerId gibi) ve metin karşılaştırmalarını azaltın.
Bakım kolaylığı için yetki tablosu tasarımı
Yetki tablosunu “kimin hangi anahtarlara eriştiği” mantığıyla sade tutun. Birden fazla yetki türünüz varsa (bölge + ürün grubu gibi), ayrı bridge tabloları veya tek tabloda farklı kolonlar düşünülebilir; ancak karmaşıklık arttıkça test matrisi büyür. Okunabilirlik ve denetlenebilirlik bakım maliyetini belirler.
Sık yapılan hatalar ve hızlı teşhis adımları
RLS kurulduğu halde kullanıcı “hiç veri görmüyor” ya da “fazla veri görüyor” şikâyetiyle geliyorsa, sorun çoğunlukla ilişkiler ve anahtar eşleşmesindedir. Teşhisi sistematik yaparsanız, çözüm genellikle dakikalar içinde bulunur.
“Hiç veri yok” sorunu
- USERPRINCIPALNAME() ile gelen değer, yetki tablosundaki e-posta formatıyla birebir aynı mı?
- Yetki tablosu refresh oldu mu, güncel mi?
- İlişki yönleri filtre yayılımını doğru taşıyor mu?
“Fazla veri görünüyor” sorunu
En sık neden, istemeden etkinleşen çift yönlü filtre veya yanlış kardinaliteyle kurulan ilişkilerdir. Bridge tabloda tekilleşmeyen anahtarlar da beklenmedik geniş filtre etkisi yaratabilir. Ayrıca aynı kullanıcıya birden fazla rol atandıysa, Power BI bu rolleri birleştirerek beklenenden daha geniş erişim doğurabilir.
Hızlı kontrol için basit ölçü
Dinamik RLS’i doğrulamak için rapora bir kart koyup oturum bilgisini göstermek oldukça pratiktir. Aşağıdaki ölçü, test sırasında kimin bağlamında olduğunuzu hızlıca görmenizi sağlar:
// Ölçü: OturumKullanicisi
OturumKullanicisi =
"UPN: " & USERPRINCIPALNAME()Bu kart, Service’de de aynı şekilde çalışır ve yanlış e-posta eşleşmesi gibi problemleri erken yakalamanıza yardımcı olur.
Uygulama örneği: departman ve bölge birlikte yönetildiğinde
Bir kullanıcı hem departmana hem bölgeye göre kısıtlanacaksa iki ayrı filtre boyutu devreye girer. Bu durumda güvenlik tablosunu “UserEmail + DepartmentId + RegionId” şeklinde tasarlamak cazip görünür; fakat kombinasyon patlaması yaşanabilir. Alternatif olarak iki bridge tablo (User-Department, User-Region) kurup boyutlara ayrı ayrı filtre yaymak daha yönetilebilir olur.
Bu tür senaryolarda hedef, kuralı DAX ile karmaşıklaştırmak yerine modeli sadeleştirmektir. RLS’de en iyi optimizasyon, doğru modellemedir.
Sonuç: RLS’i rapordan değil modelden düşünün
Power BI Row-Level Security, doğru kurgulandığında aynı raporu güvenle ölçeklemenizi sağlar. Başarının anahtarı; yıldız şema temelli modelleme, dinamik RLS için temiz bir yetki tablosu, tutarlı anahtarlar ve Service tarafında disiplinli izin yönetimidir.
Bu yaklaşımı standartlaştırdığınızda, yeni kullanıcı eklemek “raporu kopyalamak” değil, yalnızca yetki tablosuna bir satır eklemek kadar basit hale gelir. Böylece güvenlik, bakım ve performans hedefleri aynı tasarımda buluşur.


