RLS: Forumlarda En Çok Yardım İstenen Konu
Power BI forumlarında Row Level Security (RLS) kadar sık sorulan bir konu yoktur. _"Her bölge müdürü sadece kendi bölgesini görsün"_, _"Satış temsilcisi sadece kendi müşterilerini görsün"_ — bu talepler her kurumsal projede karşımıza çıkar.
RLS, aynı raporu farklı kullanıcılara farklı veri filtreleriyle göstermenizi sağlar. Tek bir rapor, tek bir dataset — ama herkes sadece yetkili olduğu veriyi görür.
RLS Nasıl Çalışır?
Temel Kavramlar
- Rol: Bir güvenlik kuralı tanımı (örn: "Bölge Müdürü")
- DAX Filtresi: Rolün uyguladığı filtre ifadesi
- Üye: Role atanan kullanıcılar (e-posta ile)
- USERPRINCIPALNAME(): Oturum açan kullanıcının e-posta adresini döndüren fonksiyon
Statik RLS (Basit Yaklaşım)
Her bölge için ayrı rol tanımlarsınız:
// Rol: "İstanbul Bölgesi"
// Tablo: DimMusteri
[Bolge] = "İstanbul"
// Rol: "Ankara Bölgesi"
[Bolge] = "Ankara"
// Rol: "İzmir Bölgesi"
[Bolge] = "İzmir"Dinamik RLS (Doğru Yaklaşım)
Dinamik RLS'de kullanıcı bilgisi bir güvenlik tablosunda tutulur ve USERPRINCIPALNAME() ile otomatik eşleştirilir.
Adım 1: Güvenlik Tablosu Oluşturun
-- SQL Server'da güvenlik tablosu
CREATE TABLE GuvenlikTablosu (
KullaniciEmail NVARCHAR(200),
Bolge NVARCHAR(100),
Yetki NVARCHAR(50) -- 'Bolge', 'Ulke', 'Hepsi'
);
INSERT INTO GuvenlikTablosu VALUES
('ali@firma.com', 'İstanbul', 'Bolge'),
('ayse@firma.com', 'Ankara', 'Bolge'),
('mehmet@firma.com', 'İzmir', 'Bolge'),
('ceo@firma.com', NULL, 'Hepsi'); -- CEO tüm veriyi görürAdım 2: DAX Filtresi Yazın
// Tek bir RLS rolü — tüm kullanıcılar için çalışır
// Tablo: DimMusteri
VAR KullaniciEmail = USERPRINCIPALNAME()
VAR KullaniciYetki =
LOOKUPVALUE(
GuvenlikTablosu[Yetki],
GuvenlikTablosu[KullaniciEmail], KullaniciEmail
)
RETURN
IF(
KullaniciYetki = "Hepsi",
TRUE(), -- CEO her şeyi görür
[Bolge] IN
SELECTCOLUMNS(
FILTER(GuvenlikTablosu, [KullaniciEmail] = KullaniciEmail),
"Bolge", [Bolge]
)
)Adım 3: İlişkileri Kurun
Hiyerarşik RLS
Forumda en çok sorulan ileri düzey senaryo: _"Bölge müdürü kendi bölgesini, genel müdür tüm bölgeleri görsün."_
// Hiyerarşik RLS — yönetici hiyerarşisi
VAR KullaniciEmail = USERPRINCIPALNAME()
VAR KullaniciBolge =
LOOKUPVALUE(GuvenlikTablosu[Bolge], GuvenlikTablosu[KullaniciEmail], KullaniciEmail)
VAR KullaniciSeviye =
LOOKUPVALUE(GuvenlikTablosu[Seviye], GuvenlikTablosu[KullaniciEmail], KullaniciEmail)
RETURN
SWITCH(
KullaniciSeviye,
"CEO", TRUE(),
"Direktör", [Ulke] = LOOKUPVALUE(GuvenlikTablosu[Ulke], GuvenlikTablosu[KullaniciEmail], KullaniciEmail),
"Müdür", [Bolge] = KullaniciBolge,
FALSE()
)Test Etme
RLS'i dağıtmadan önce mutlaka test edin. Power BI Desktop'ta:
- Modeling > Manage Roles ile rolleri tanımlayın
- Modeling > View As ile test edin
- Bir kullanıcı e-postası girin ve raporu o kullanıcının gözünden görün
En Yaygın RLS Hataları
Hata 1: Admin/Member RLS'i Bypass Eder
| Workspace Rolü | RLS Uygulanır mı? |
|---|---|
| Admin | ❌ Tüm veriyi görür |
| Member | ❌ Tüm veriyi görür |
| Contributor | ❌ Tüm veriyi görür |
| Viewer | ✅ RLS uygulanır |
Hata 2: USERPRINCIPALNAME Boş Dönüyor
Power BI Desktop'ta USERPRINCIPALNAME() bazen boş döner. View As ile test edin, doğrudan raporda test etmeyin.
Hata 3: İlişki Yönü Yanlış
Güvenlik tablosu ile dimension arasındaki ilişki tek yönlü olmalı ve "Apply security filter in both directions" işaretlenmemeli — aksi halde beklenmeyen sonuçlar çıkar.
Hata 4: Birden Fazla Rol Atanması
Bir kullanıcıya birden fazla rol atanırsa, filtreler OR mantığıyla birleşir (birleşim/union). Bu bazen beklenenden fazla veri gösterir.
Sonuç
RLS, Power BI'da veri güvenliğinin temelidir. Dinamik RLS yaklaşımını kullanın — tek rol, güvenlik tablosu ve USERPRINCIPALNAME() ile yönetilebilir bir yapı kurun. Hiyerarşik yapılar için SWITCH bazlı filtreler kullanın. Ve en önemlisi: kullanıcıları Workspace'e Viewer olarak ekleyin, yoksa RLS çalışmaz.
