Power BI Desktop'ta satır düzeyi güvenlik (RLS) kılavuzu

Bu makale, Power BI Desktop ile çalışan bir veri modelleyicisi olarak sizi hedefler. Veri modellerinizde satır düzeyi güvenliği (RLS) zorunlu kılmaya yönelik iyi tasarım uygulamalarını açıklar.

RLS'nin tablo satırlarını filtrelediğinden anlamak önemlidir. Tablolar, sütunlar veya ölçüler dahil olmak üzere model nesnelerine erişimi kısıtlamak için yapılandırılamazlar.

Rol oluşturma

Birden çok rol oluşturmak mümkündür. Tek bir rapor kullanıcısı için izin gereksinimlerini göz önünde bulundurduğunuzda, rapor kullanıcısının birden çok rolün üyesi olacağı bir tasarım yerine tüm bu izinleri veren tek bir rol oluşturmaya çalışın. Bunun nedeni, rapor kullanıcılarının doğrudan kendi kullanıcı hesabını kullanarak veya dolaylı olarak güvenlik grubu üyeliğiyle birden çok rolle eşlenebiliyor olmasıdır. Birden çok rol eşlemesi beklenmeyen sonuçlara neden olabilir.

Bir rapor kullanıcısı birden çok rollere atandığında RLS filtreleri eklenir. Bu, rapor kullanıcılarının bu filtrelerin birleşimini temsil eden tablo satırlarını görebileceği anlamına gelir. Dahası, bazı senaryolarda rapor kullanıcılarının tablodaki satırları görmediğini garanti etmek mümkün değildir. Bu nedenle, SQL Server veritabanı nesnelerine (ve diğer izin modellerine) uygulanan izinlerden farklı olarak, "bir kez reddedildi her zaman reddedildi" ilkesi geçerli değildir.

İki rolü olan bir model düşünün: Çalışanlar adlı ilk rol, aşağıdaki kural ifadesini kullanarak tüm Bordro tablosu satırlarına erişimi kısıtlar:

FALSE()

Ancak, Yöneticiler adlı ikinci bir rol, aşağıdaki kural ifadesini kullanarak tüm Bordro tablosu satırlarına erişime izin verir:

TRUE()

Dikkatli olun: Rapor kullanıcısı her iki rolle de eşlenmişse tüm Bordro tablosu satırlarını görür.

RLS'i en iyi duruma getirme

RLS, her DAX sorgusuna otomatik olarak filtre uygulayarak çalışır ve bu filtrelerin sorgu performansı üzerinde olumsuz bir etkisi olabilir. Bu nedenle, verimli RLS iyi model tasarımına gelir. Aşağıdaki makalelerde açıklandığı gibi model tasarımı yönergelerini izlemek önemlidir:

• Yıldız şemasını ve Power BI'ın önemini anlama
• Power BI kılavuzu belgelerinde bulunan tüm ilişki kılavuzu makaleleri

Genel olarak, olgu türündeki tablolarda değil boyut türündeki tablolarda RLS filtrelerini zorunlu kılmak genellikle daha verimlidir. Ayrıca, RLS filtrelerinin diğer model tablolarına yayılmasını sağlamak için iyi tasarlanmış ilişkilere güvenin. RLS filtreleri yalnızca etkin ilişkiler aracılığıyla yayılır. Bu nedenle, model ilişkileri aynı sonucu elde edebilirken LOOKUPVALUE DAX işlevini kullanmaktan kaçının.

DirectQuery tablolarında RLS filtreleri uygulandığında ve diğer DirectQuery tablolarına ilişkin ilişkiler olduğunda kaynak veritabanını iyileştirin. Uygun dizinler tasarlamayı veya kalıcı hesaplanan sütunları kullanmayı içerebilir. Daha fazla bilgi için bkz . Power BI Desktop'ta DirectQuery modeli kılavuzu.

RLS etkisini ölçme

Performans Analizi kullanarak Power BI Desktop'ta RLS filtrelerinin performans etkisini ölçmek mümkündür. İlk olarak, RLS uygulanmadığında rapor görseli sorgu sürelerini belirleyin. Ardından, RLS'yi zorunlu kılmak ve sorgu sürelerini belirleyip karşılaştırmak için Modelleme şerit sekmesindeki Farklı Görüntüle komutunu kullanın.

Rol eşlemelerini yapılandırma

Power BI'da yayımlandıktan sonra üyeleri anlam modeli rolleriyle eşlemeniz gerekir. Rollere yalnızca anlamsal model sahipleri veya çalışma alanı yöneticileri üye ekleyebilir. Daha fazla bilgi için bkz . Power BI ile satır düzeyi güvenlik (RLS) (Modelinizde güvenliği yönetme).

Üyeler kullanıcı hesapları, güvenlik grupları, dağıtım grupları veya posta etkin gruplar olabilir. Mümkün olduğunda güvenlik gruplarını anlam modeli rolleriyle eşlemenizi öneririz. Microsoft Entra Id'de güvenlik grubu üyeliklerini yönetmeyi içerir. Büyük olasılıkla görevi ağ yöneticilerinize devreder.

Rolleri doğrulama

Modeli doğru filtrelediğinden emin olmak için her rolü test edin. Modelleme şerit sekmesindeki Farklı Görüntüle komutu kullanılarak kolayca yapılabilir.

ModelDE USERNAME DAX işlevini kullanan dinamik kurallar varsa beklenen ve beklenmeyen değerleri test ettiğinizden emin olun. Power BI içeriği eklerken (özellikle müşterileriniz için ekleme senaryolarını kullanarak) uygulama mantığı herhangi bir değeri etkili bir kimlik kullanıcı adı olarak geçirebilir. Mümkün olduğunda yanlışlıkla veya kötü amaçlı değerlerin satır döndürmeden filtrelere neden olduğundan emin olun.

Uygulamanın etkin kullanıcı adı olarak kullanıcının iş rolünü geçirdiği Power BI embedded'ı kullanan bir örnek düşünün: "Yönetici" veya "Çalışan". Yöneticiler tüm satırları görebilir, ancak çalışanlar yalnızca Tür sütun değerinin "İç" olduğu satırları görebilir.

Aşağıdaki kural ifadesi tanımlanır:

IF(
    USERNAME() = "Worker",
    [Type] = "Internal",
    TRUE()
)

Bu kural ifadesiyle ilgili sorun, "Çalışan" dışındaki tüm değerlerin tüm tablo satırlarını döndürmesidir. Bu nedenle, yanlışlıkla "Wrker" gibi bir değer istemeden tüm tablo satırlarını döndürür. Bu nedenle, beklenen her değer için test eden bir ifade yazmak daha güvenlidir. Aşağıdaki geliştirilmiş kural ifadesinde, beklenmeyen bir değer tablonun satır döndürmesine neden olur.

IF(
    USERNAME() = "Worker",
    [Type] = "Internal",
    IF(
        USERNAME() = "Manager",
        TRUE(),
        FALSE()
    )
)

Kısmi RLS tasarlama

Bazen hesaplamalar, RLS filtreleri tarafından kısıtlanmayan değerlere ihtiyaç duyar. Örneğin bir raporun, rapor kullanıcısının satış bölgesi için kazanılan gelirin kazanılmış tüm gelirlere göre oranını görüntülemesi gerekebilir.

Bir DAX ifadesinin RLS'yi geçersiz kılabilir olması mümkün olmasa da, aslında RLS'nin zorlandığını bile belirleyemez; bir özet model tablosu kullanabilirsiniz. Özet model tablosu "tüm bölgeler" için geliri almak üzere sorgulanır ve RLS filtreleri tarafından kısıtlanmaz.

Şimdi bu tasarım gereksinimini nasıl uygulayabileceğinizi görelim. İlk olarak aşağıdaki model tasarımını göz önünde bulundurun:

Model dört tablodan oluşur:

• Satış Temsilcisi tablosu, satış temsilcisi başına bir satır depolar. Her satış temsilcisinin e-posta adresini depolayan EmailAddress sütununu içerir. Bu tablo gizlidir.
• Sales tablosu sipariş başına bir satır depolar. Rapor kullanıcısının bölgesi tarafından kazanılan gelir oranını tüm bölgeler tarafından kazanılan gelire göre döndürmek için tasarlanan Revenue % All Region ölçüsünü içerir.
• Tarih tablosu tarih başına bir satır depolar ve yıl ve ay filtreleme ve gruplandırma işlemlerine izin verir.
• SalesRevenueSummary hesaplanan bir tablodur. Her sipariş tarihi için toplam geliri depolar. Bu tablo gizlidir.

Aşağıdaki ifade SalesRevenueSummary hesaplanan tablosunu tanımlar:

SalesRevenueSummary =
SUMMARIZECOLUMNS(
    Sales[OrderDate],
    "RevenueAllRegion", SUM(Sales[Revenue])
)

Satış Temsilcisi tablosuna aşağıdaki RLS kuralı uygulanır:

[EmailAddress] = USERNAME()

Üç model ilişkisinin her biri aşağıdaki tabloda açıklanmıştır:

İlişki	Açıklama
	Satış Temsilcisi ve Satış tabloları arasında çoka çok ilişki vardır. RLS kuralı, USERNAME DAX işlevini kullanarak gizli Satış Temsilcisi tablosunun EmailAddress sütununu filtreler. Bölge sütun değeri (rapor kullanıcısı için) Sales tablosuna yayılır.
	Tarih ve Satış tabloları arasında bire çok ilişki vardır.
	Date ve SalesRevenueSummary tabloları arasında bire çok ilişki vardır.

Aşağıdaki ifade Revenue % All Region ölçüsünü tanımlar:

Revenue % All Region =
DIVIDE(
    SUM(Sales[Revenue]),
    SUM(SalesRevenueSummary[RevenueAllRegion])
)

RLS kullanmaktan ne zaman kaçınılması gerekir?

Bazen RLS kullanmaktan kaçınmak mantıklıdır. Statik filtreler uygulayan yalnızca birkaç basit RLS kuralınız varsa, bunun yerine birden çok anlam modeli yayımlamayı göz önünde bulundurun. Her anlam modeli aynı veri izinlerine sahip belirli bir rapor kullanıcı kitlesine ait veriler içerdiğinden, anlam modellerinin hiçbiri rolleri tanımlamaz. Ardından, hedef kitle başına bir çalışma alanı oluşturun ve çalışma alanına veya uygulamaya erişim izinleri atayın.

Örneğin, yalnızca iki satış bölgesi olan bir şirket, her satış bölgesi için farklı çalışma alanlarına bir anlam modeli yayımlamaya karar verir. Anlamsal modeller RLS'yi zorlamaz. Ancak, kaynak verileri filtrelemek için sorgu parametrelerini kullanırlar. Bu şekilde, her çalışma alanında aynı model yayımlanır; bunlar yalnızca farklı anlam modeli parametre değerlerine sahiptir. Satış temsilcilerine çalışma alanlarından (veya yayımlanan uygulamalardan) yalnızca birine erişim atanır.

RLS'yi önlemenin çeşitli avantajları vardır:

• Geliştirilmiş sorgu performansı: Daha az filtre nedeniyle performansın artmasına neden olabilir.
• Daha küçük modeller: Daha fazla modele neden olsa da, boyutları daha küçüktür. Daha küçük modeller, özellikle barındırma kapasitesinde kaynaklar üzerinde baskı yaşanıyorsa sorgu ve veri yenileme yanıt hızını iyileştirebilir. Ayrıca, model boyutlarını kapasiteniz tarafından uygulanan boyut sınırlarının altında tutmak daha kolaydır. Son olarak, farklı kapasitelerde çalışma alanları oluşturabileceğiniz veya çalışma alanlarını farklı kapasitelere taşıyabileceğiniz için iş yüklerini farklı kapasitelerde dengelemek daha kolaydır.
• Ek özellikler: Web'de yayımla gibi RLS ile çalışmayan Power BI özellikleri kullanılabilir.

Ancak RLS'yi önlemenin dezavantajları vardır:

• Birden çok çalışma alanı: Her rapor kullanıcısı hedef kitlesi için bir çalışma alanı gereklidir. Uygulamalar yayımlanırsa, rapor kullanıcısı hedef kitlesi başına bir uygulama olduğu anlamına da gelir.
• İçeriğin çoğaltılması: Raporlar ve panolar her çalışma alanında oluşturulmalıdır. Ayarlamak ve bakımını yapmak için daha fazla çaba ve zaman gerektirir.
• Yüksek ayrıcalıklı kullanıcılar: Birden çok rapor kullanıcısı hedef kitlesine ait olan yüksek ayrıcalıklı kullanıcılar, verilerin birleştirilmiş görünümünü göremez. Birden çok rapor açmaları gerekir (farklı çalışma alanlarından veya uygulamalardan).

RLS sorunlarını giderme

RLS beklenmeyen sonuçlar üretirse aşağıdaki sorunları denetleyin:

• Sütun eşlemeleri ve filtre yol tarifleri açısından model tabloları arasında yanlış ilişkiler vardır. RLS filtrelerinin yalnızca etkin ilişkiler aracılığıyla yayıldığını unutmayın.
• Her iki yönde de güvenlik filtresi uygula ilişkisi özelliği doğru ayarlanmadı. Daha fazla bilgi için bkz . çift yönlü ilişki kılavuzu.
• Tablolarda veri yok.
• Tablolara yanlış değerler yüklenir.
• Kullanıcı birden çok rolle eşlenir.
• Model toplama tabloları içerir ve RLS kuralları toplamaları ve ayrıntıları tutarlı bir şekilde filtrelemez. Daha fazla bilgi için bkz. Power BI Desktop'ta toplamaları kullanma (toplamalar için RLS).

Belirli bir kullanıcı herhangi bir veri göremiyorsa, bunun nedeni UPN'lerinin depolanmamış olması veya yanlış girilmesi olabilir. Ad değişikliğinin sonucu olarak kullanıcı hesabı değiştiğinden bu durum ani bir şekilde gerçekleşebilir.

Anlam modeli üzerinde yalnızca Okuma iznine sahip oluşturucular ve tüketiciler yalnızca görmelerine izin verilen verileri görüntüleyebilir (RLS rol eşlemelerine göre).

Kullanıcı çalışma alanında veya uygulamada bir raporu görüntülediğinde, RLS anlam modeli izinlerine bağlı olarak zorunlu kılınabilir veya uygulanmayabilir. Bu nedenle, içerik tüketicilerinin ve oluşturucularının yalnızca RLS'nin zorunlu kılınması gerektiğinde temel alınan anlam modeli üzerinde Okuma iznine sahip olması kritik önem taşır. RLS'nin zorunlu kılınıp uygulanmadığını belirleyen izin kuralları hakkında ayrıntılı bilgi için Rapor tüketici güvenliği planlaması makalesine bakın.

İlgili içerik

Bu makaleyle ilgili daha fazla bilgi için aşağıdaki kaynaklara göz atın:

• Power BI ile satır düzeyinde güvenlik (RLS)
• Power BI Desktop için satır düzeyi güvenlik (RLS) ile veri erişimini kısıtlama
• Power BI Desktop'ta model ilişkileri
• Power BI uygulama planlaması: Tüketici güvenliği planlamayı raporlama
• Sorularınız var mı? Power BI Topluluğu sormayı deneyin
• Öneri? Power BI'ı geliştirmek için fikirlere katkıda bulunma