Satır ve nesne düzeyinde güvenlik

Bu sayfa dersin okuma sürümüdür. Metin bir kutuyu çalıştırmanı ya da adıma geçmeni söylüyorsa dersi uygulamada aç.

RLS: herkes kendi verisini görsün

Satır düzeyinde güvenlik (Row-Level Security), aynı raporu açan kişilerin farklı satırları görmesini sağlar. Modelleme → Rolleri yönet.

Statik RLS

-- "İstanbul Ekibi" rolü, Musteriler tablosu filtresi:
Musteriler[Sehir] = "İstanbul"

Rolün üyeleri yalnızca İstanbul'daki müşterileri ve (ilişki üzerinden) onların satışlarını görür. Her şehir için ayrı rol gerekir.

Dinamik RLS

Bir Yetkiler tablosu kur: Eposta | Sehir. Tek bir rol yeter:

-- Yetkiler tablosu filtresi:
Yetkiler[Eposta] = USERPRINCIPALNAME()

USERPRINCIPALNAME(), oturum açan kişinin e-postasını döndürür. Yetkiler tablosu Musteriler[Sehir] ile ilişkilendirilir (çoğu zaman çoka-çok ya da köprü tablo + “Güvenlik filtresini iki yönde uygula”). Yeni bir çalışan geldiğinde rol değişmez, yalnızca tabloya bir satır eklenir.

Test et

Desktop: Modelleme → Farklı görüntüle → rol ya da kullanıcı seç. Service: anlam modelinin güvenlik ayarlarında Rol olarak test et.

OLS: sütunu ya da tabloyu gizle

Nesne düzeyinde güvenlik (Object-Level Security), belirli rollerden bir tabloyu ya da sütunu (ör. Calisanlar[Maas]) tamamen gizler. Tabular Editor gibi araçlarla tanımlanır.

Önemli ayrıntılar

RLS, çalışma alanında Görüntüleyici rolündeki kullanıcılara uygulanır. Yönetici, Üye ve Katkıda bulunan rolleri modeli düzenleyebildiği için RLS'den etkilenmez.
RLS filtresi, ilişkiler üzerinden diğer tablolara yayılır; boyut tablosunda tanımlamak genellikle yeterlidir.
RLS rapor sayfasını gizlemek için değil, veriyi korumak içindir. Sayfa gizleme bir güvenlik önlemi değildir.

Uzmanlaş

Dinamik RLS: kim, hangi satırı?

Satış Müdürü Elif Doğan şunu istiyor: “Temsilcilerim yalnızca kendi satışlarını görsün. Ben ekibimin tamamını göreyim. Genel müdür her şeyi görsün.” Modelde Satislar[TemsilciNo] → Calisanlar[CalisanNo] ilişkisi ve Calisanlar[Eposta] sütunu zaten var. En basit dinamik rol tek satırlık bir tablo filtresidir:

-- Rol: "Temsilci", tablo: Calisanlar
Calisanlar[Eposta] = USERPRINCIPALNAME()

Ece Kurt oturum açtığında Calisanlar tek satıra iner, filtre ilişki üzerinden Satislar'a akar. Bunu yayımlamadan önce aynı filtreyi bir ölçüyle taklit ederek doğrulayabilirsin:

Ece Kurt Testi =
CALCULATE([Net Satış], Calisanlar[Eposta] = "ece.kurt@anadolumarket.com")

Sonuç 146.836,45 ₺ olmalıdır; rapor “Farklı görüntüle” ile açıldığında kart bu sayıyı göstermiyorsa rol ya da ilişki hatalıdır. Dikkat edilecek üç ayrıntı:

Boş e-posta: Bu modelde Pınar Yıldırım, Defne Öztürk ve Kerem Yılmaz'ın Eposta değeri boş. Rolde olsalar bile hiçbir şey görmezler. Eşleşen satırı olmayan kullanıcı boş rapor görür; hata mesajı almaz.
Biçim: USERPRINCIPALNAME() Service'te kullanıcının UPN'ini döndürür. Tabloda büyük/küçük harf ya da eski alan adı farkı varsa eşleşme kaçar. Konuk (B2B) kullanıcılarda değer #EXT# içeren bir biçimde gelebilir; gerçek bir konuk hesabıyla test et.
Boyutlar filtrelenmez: Filtre Calisanlar → Satislar yönünde akar. Musteriler ve Urunler boyutlarının tüm satırları görünür kalır; temsilci tüm müşteri adlarını dilimleyicide görebilir. Bu kabul edilemezse müşteri tablosuna ayrı bir filtre gerekir.

Eşleme tablosu: bir kişi, birden çok bölge

Bölge müdürlerinin birden çok bölgesi varsa Yetkiler(Eposta, Bolge) gibi bir eşleme tablosu kurulur. İki yol vardır:

Yol	Nasıl?	Artı / eksi
İlişki + iki yönlü güvenlik filtresi	Yetkiler → Bolge boyutu ilişkisi, “Güvenlik filtresini iki yönde uygula”	Görsel olarak sade; ama iki yönlü filtre performansı düşürür ve bir tabloda yalnızca bir ilişkide açılabilir
İlişkisiz tablo + filtre ifadesi	Musteriler rolünde: bölge, kullanıcının bölgeleri içinde mi?	Tek yönlü, öngörülebilir; ifade biraz daha uzun

-- Rol filtresi, tablo: Musteriler (Yetkiler tablosu ilişkisiz)
Musteriler[Bolge] IN
    CALCULATETABLE(VALUES(Yetkiler[Bolge]), Yetkiler[Eposta] = USERPRINCIPALNAME())

Yönetici hiyerarşisi: PATHCONTAINS

Elif'in “ekibimin tamamını göreyim” isteği hiyerarşi ister. Calisanlar[Yol] sütunu PATH(CalisanNo, YoneticiNo) ile üretilmiştir: Ece Kurt için “1|2|9”. Rol filtresi, oturum açan kişinin numarasının satırın yolunda geçip geçmediğine bakar:

-- Rol: "Hiyerarşi", tablo: Calisanlar
PATHCONTAINS(
    Calisanlar[Yol],
    LOOKUPVALUE(Calisanlar[CalisanNo], Calisanlar[Eposta], USERPRINCIPALNAME())
)

Analitik Müdürü Serkan Özdemir (4) için hangi satırların kalacağını bir sorguyla görebilirsin:

EVALUATE
FILTER(
    SELECTCOLUMNS(Calisanlar, "Ad", Calisanlar[AdSoyad], "Unvan", Calisanlar[Unvan], "Yol", Calisanlar[Yol]),
    PATHCONTAINS([Yol], 4)
)

Beş satır döner: Serkan ve dört ekip üyesi. Elif (2) için ise kendisi ve beş temsilci kalır; tüm satışlar bu ekipte olduğu için Elif 1.250.772,45 ₺'nin tamamını görür, kendi adına kayıtlı satış yalnızca 183.134,35 ₺'dir. Kenar durumlar:

E-posta tabloda yoksa LOOKUPVALUE BLANK döner, PATHCONTAINS hiçbir satırda doğru olmaz: kullanıcı boş rapor görür.
Aynı e-posta iki satırda varsa LOOKUPVALUE hata verir ve kullanıcının tüm görselleri bozulur. Eposta sütununda benzersizlik kontrolü yap.
Filtre 27 satırlık küçük bir tabloda değerlendirilir; ucuzdur. Aynı ifadeyi milyonlarca satırlık olgu tablosuna yazmak pahalıdır. RLS'yi her zaman küçük boyut tablosunda tanımla.

Birden çok rol: kesişim değil birleşim

Ece hem “Temsilci” rolünde hem de bir kampanya için “Ege Bölgesi” rolünde olsun. Roller toplanır: Ece kendi satışlarını ve Ege bölgesinin tüm satışlarını görür, ikisinin kesişimini değil. Bu, en geniş rolün diğerlerini boşa çıkarması demektir. “Hem kendi satışları hem yalnızca Ege” gibi bir kesişim isteniyorsa iki koşul tek bir rolün ifadesinde birleştirilmelidir. Birleşim etkisini test etmek için iki temsilcinin görünümünü birlikte hesapla:

İki Temsilci Birleşimi =
CALCULATE([Net Satış], Calisanlar[CalisanNo] = 9 || Calisanlar[CalisanNo] = 10)

Ece (9) ve Can Aydın (10) birlikte 385.695,65 ₺ eder. Bir diğer kural: RLS ve OLS farklı rollerden birleştirilemez. Bir kullanıcı, birinde satır filtresi, diğerinde nesne gizleme olan iki role üyeyse sorgu anında hata alır. Nesne güvenliğini ve satır güvenliğini aynı rolde tanımla.

OLS ve ölçüler

OLS bir sütunu gizlediğinde o sütuna başvuran ölçüler de o rol için otomatik kısıtlanır: Calisanlar[Maas] gizlenirse [Ortalama Maaş], [Toplam Maaş] ve [Medyan Maaş] da çalışmaz. Kullanıcı görselde “alan bulunamadı” türünde bir hata görür; bu yüzden OLS'li kullanıcılar için ayrı sayfa ya da rapor tasarla. OLS'yi Desktop'ta TMDL görünümünde ya da Tabular Editor gibi bir dış araçla tanımlarsın; rol üyeliği yine Service'te atanır.

Test etmek: matrisle, kişiyle, sayıyla

Desktop: Modelleme → Farklı görüntüle (View as): rolü seç, “Diğer kullanıcı” kutusuna e-postayı yaz. Dinamik RLS ancak böyle sınanır.
Service: anlam modelinde … → Güvenlik (Security) → rolün yanındaki … → Rol olarak test et (Test as role). Belirli bir kişi ya da rol bileşimi seçilebilir. Panolar bu testte desteklenmez; sayfalandırılmış raporlarda ve SSO'lu DirectQuery modellerinde çalışmaz.

Test kullanıcısı	Rol	Beklenen Net Satış
ece.kurt@…	Temsilci	146.836,45 ₺
elif.dogan@…	Hiyerarşi	1.250.772,45 ₺
Pınar Yıldırım (e-posta yok)	Temsilci	Boş
Rolü olmayan bir Görüntüleyici	—	Boş

Bu tabloyu bir test belgesi olarak modelin yanında tut; her model değişikliğinden sonra aynı kişilerle tekrar et.

RLS'nin uygulanmadığı ve yanıltabildiği yerler

Çalışma alanı rolleri: Yönetici, Üye ve Katkıda bulunan modeli düzenleyebildiği için RLS'den etkilenmez. Son kullanıcıları yalnızca Görüntüleyici olarak ekle ya da içerikleri uygulama ile dağıt. Derleme izni olan Görüntüleyiciler (Excel'de Çözümle dahil) RLS ile kısıtlı kalır.
Hizmet sorumlusu: rollere eklenemez; uygulamaya gömülü senaryolarda kullanıcının kimliği yerleştirme belirtecinde (embed token) etkin kimlik olarak gönderilir (Yayımlama dersi).
ALL RLS'yi aşmaz: [Kategori Payı %] gibi ölçülerde payda ALL ya da REMOVEFILTERS ile yazılmış olsa bile RLS filtresi geçerlidir. Ece'nin “kategori payı” kendi satışları içindeki paydır, şirket içindeki pay değil. Şirket geneli bir pay göstermek istiyorsan bu değeri ayrı ve onaylı bir yoldan (ör. RLS'siz bir özet tablo) sağlamak gerekir.
USERELATIONSHIP: RLS açıkken beklenmedik hatalar verebilir. [Teslime Göre Satış] gibi pasif ilişki kullanan ölçüleri rol testine dahil et.
Performans: iki yönlü güvenlik filtresi ve olgu tablosunda yazılmış karmaşık ifadeler her sorguya eklenir. Performans Analizi'ni “Farklı görüntüle” açıkken çalıştır; yönetici gözüyle hızlı olan sayfa temsilci gözüyle yavaş olabilir.

Kontrol listesiRol filtresi küçük boyut tablosunda mı? · E-posta sütunu benzersiz ve boş değer kontrolü yapıldı mı? · Konuk kullanıcı biçimi test edildi mi? · Roller birleşim olarak düşünüldü mü; RLS ve OLS aynı rolde mi? · Test kullanıcıları ve beklenen sayılar belgelendi mi? · Son kullanıcılar Görüntüleyici mi?