Power BI ile satır düzeyinde güvenlik (RLS)

Satır düzeyi güvenlik (RLS), belirli kullanıcılar için veri erişimini kısıtlar. Filtreler verileri satır düzeyinde kısıtlar ve siz de roller içinde filtreler tanımlarsınız. Power BI hizmeti, çalışma alanına erişimi olan kullanıcılar bu çalışma alanında anlamsal modellere erişebilir. RLS yalnızca Görüntüleyici izinlerine sahip kullanıcılar için veri erişimini kısıtlar. Yöneticiler, Üyeler veya Katkıda Bulunanlar için geçerli değildir.

RLS uygulamak için şu üst düzey iş akışını izleyin:

1. DAX filtre ifadelerini kullanarak Power BI Desktop'ta rolleri ve kuralları belirleyin.
2. Yayınla semantik modeli ve raporu Power BI hizmetine.
3. üyeleri Power BI hizmeti rollerine ekleyin.
4. Veri filtrelemenin beklendiği gibi çalıştığını onaylamak için Rol olarak test et özelliğini kullanarak doğrulayın.

Power BI Desktop'ta veya Power BI hizmeti içeri aktarılan anlam modelleri için RLS'yi yapılandırabilirsiniz. RLS'yi SQL Server gibi DirectQuery kullanan anlamsal modellerde de yapılandırabilirsiniz. Analysis Services veya Azure Analysis Services canlı bağlantıları için satır düzeyi güvenlik yapılandırmasını Power BI yerine modelde yapmalısınız. Canlı bağlantı anlam modelleri için güvenlik seçeneği gösterilmez.

Note

Bu makale, özellikle Power BI anlamsal modeller için RLS'leri kapsar. Diğer Fabric öğelerinde veri güvenliği için bkz. Microsoft Fabric'te Güvenlik.

Note

Microsoft Fabric'daki Direct Lake semantik modelleri için RLS desteklenir. Ancak desteklenmeyen özellikler nedeniyle bir DAX sorgusu DirectQuery moduna geri dönerse RLS filtreleri yine de geçerli olur ancak performans özellikleri değişebilir. Fabric kapasite ölçümleri uygulamasında sorgu geri dönüş davranışını izleyin.

Power BI Desktop'ta rolleri ve kuralları tanımlama

Power BI Desktop'ta roller ve kurallar tanımlayabilirsiniz. Bu düzenleyiciyle, varsayılan açılan arabirimi ve DAX arabirimini kullanma arasında geçiş yapabilirsiniz. Power BI'da yayımladığınızda rol tanımlarını da yayımlarsınız.

Güvenlik rollerini tanımlamak için:

1. Verileri Power BI Desktop raporunuz içine aktarın veya DirectQuery bağlantısı yapılandırın.

   Note

   Analysis Services için Power BI Desktop canlı bağlantıları içinde rol tanımlayamazsınız. Bunu Analysis Services modeli içinde yapmanız gerekir.

2. Modelleme sekmesinde Rolleri Yönet'i seçin.

3. Rolleri yönet penceresinde Yeni'yi seçerek yeni bir rol oluşturun.

4. Roller altında, rol için bir ad girin ve Enter tuşuna basın.

   Note

   Virgülle bir rol tanımlayamazsınız, örneğin London,ParisRole.

5. Tablo seç'in altında, satır düzeyi güvenlik filtresi uygulamak istediğiniz tabloyu seçin.

6. Verileri filtrele'nin altında rollerinizi tanımlamak için varsayılan düzenleyiciyi kullanın. Oluşturulan ifadeler doğru veya yanlış bir değeri döndürür. DAX filtresi her satır için DOĞRU/YANLIŞ değerini değerlendirir. Yalnızca TRUE değeri döndüren satırlar görünür. Geri kalan her şey tamamen kaldırılır.

   Note

   Power BI'da desteklenen tüm satır düzeyi güvenlik filtreleri varsayılan düzenleyici kullanılarak tanımlanamaz. Sınırlamalar, bugün yalnızca username() veya userprincipalname() gibi dinamik kurallar da dahil olmak üzere DAX kullanılarak tanımlanabilen ifadeleri içerir. Bu filtreleri kullanarak rolleri tanımlamak için DAX düzenleyicisini kullanmaya geçin.

7. İsteğe bağlı olarak, rolünüzü tanımlamak üzere DAX düzenleyicisini kullanmaya geçmek için DAX düzenleyicisine geç'i seçin. DAX ifadeleri true veya false değerini döndürür. Örneğin: [Entity ID] = “Value”. DAX düzenleyicisi, formüller için otomatik tamamlama (intellisense) ile tamdır. İfade kutusunun üzerindeki onay işaretini seçerek ifadeyi doğrulayabilir ve değişiklikleri geri döndürmek için ifade kutusunun üzerindeki X düğmesini seçebilirsiniz.

   Note

   Bu ifade içinde username() kullanabilirsiniz. username() öğesinin Power BI Desktop'ta ETKİALANI\kullanıcıadı biçimine sahip olduğunu unutmayın. Power BI hizmeti ve Power BI Rapor Sunucusu içinde, kullanıcının Kullanıcı Asıl Adı (UPN) biçimindedir. Ayrıca, bu ifade kutusunda, normalde Fransızca veya Almanca gibi noktalı virgül ayırıcıları kullanan bir yerel ayar kullanıyor olsanız bile DAX işlev bağımsız değişkenlerini ayırmak için virgül kullanın.

8. Varsayılan düzenleyiciye geç'i seçerek varsayılan düzenleyiciye geri dönebilirsiniz. Her iki düzenleyici arabiriminde yapılan tüm değişiklikler mümkün olduğunda arabirimler arasında geçiş yaparken kalıcı olur. DaX düzenleyicisini kullanarak varsayılan düzenleyicide tanımlanmayan bir rol tanımlarken, varsayılan düzenleyiciye geçmeyi denerseniz, düzenleyicileri değiştirmenin bazı bilgilerin kaybolmasına neden olabileceği uyarısını alırsınız. Bu bilgileri korumak için İptal'i seçin ve dax düzenleyicisinde yalnızca bu rolü düzenlemeye devam edin.

   Note

   Bu ifade kutusunda, normalde Fransızca veya Almanca gibi noktalı virgül ayırıcıları kullanan bir yerel ayar kullanıyor olsanız bile, DAX işlevi bağımsız değişkenlerini ayırırken virgül kullanın.

9. Kaydet'i seçin.

Power BI Desktop'ta bir role kullanıcı atayamazsınız. Bunları Power BI hizmetinde atarsınız. Kullanıcıadı() veya userprincipalname() DAX işlevlerini kullanarak ve doğru ilişkileri yapılandırarak Power BI Desktop'ta dinamik güvenliği etkinleştirebilirsiniz.

Yaygın DAX filtre desenleri

Aşağıdaki örneklerde RLS rollerini tanımlarken kullanabileceğiniz yaygın DAX filtre ifadeleri gösterilmektedir:

• Statik RLS - Verileri sabit bir değerle kısıtlar:

  [Region] = "West"
  

• UPN ile Dinamik RLS — Oturum açan kullanıcının e-posta adresine göre verileri kısıtlar:

  [UserEmail] = USERPRINCIPALNAME()
  

• USERNAME ile Dinamik RLS — Verileri kullanıcının etki alanına ve kullanıcı adına göre kısıtlar:

  [UserDomain] = USERNAME()
  

• CUSTOMDATA ile Dinamik RLS — gömme uygulamasından geçirilen özel bir dizeye göre verileri kısıtlar:

  [AppRole] = CUSTOMDATA()
  

  Note

  CUSTOMDATA() öncelikli olarak uygulamanın Power BI REST API aracılığıyla özel etkili bir kimlik dizesi geçirdiği katıştırılmış senaryolarda kullanılır.

Dinamik RLS en yaygın yaklaşımdır çünkü tek bir rol tanımının veri modelinizdeki kullanıcı eşleme tablosuna göre her kullanıcı için verileri farklı filtrelemesine olanak tanır.

Örnek: Satış verilerini bölgeye göre filtreleme

Sales bir tablonuz olduğunu ve bu tablonun Region, Product ve Amount sütunlarına sahip olduğunu varsayalım. Yalnızca bölgenin "Batı" olduğu satırları görebilmeleri için "Batı" rolüne atanan kullanıcıları kısıtlamak istiyorsunuz.

"Batı" rolünün DAX filtre alanına aşağıdaki ifadeyi girin:

[Region] = "West"

Filtrelemeden önce (tüm veriler):

Bölge	Product	Tutar
Batı	Bileşen A	beş yüz
Doğu	Pencere Öğesi B	300
Batı	Pencere Öğesi C	450
Güney	Bileşen A	200
Doğu	Pencere Öğesi C	375

Filtrelemeden sonra ("Batı" rol kullanıcıları için görünüm):

Bölge	Product	Tutar
Batı	Bileşen A	beş yüz
Batı	Pencere Öğesi C	450

DAX ifadesi, tablodaki her satırı değerlendiren bir satır filtresi işlevi görür. Yalnızca sütunun Region "Batı" değerine eşit olduğu satırlar bu role atanan kullanıcılar tarafından görülebilir.

Tip

Filtrenizin, raporu yayımlamadan önce beklenen satırları döndürdüğünü doğrulamak için, Rol olarak görüntüle özelliğini (Power BI hizmeti içinde rolü doğrulama bölümünde açıklanmıştır) kullanın.

Varsayılan olarak, satır düzeyi güvenlik filtrelemesi, ilişkilerin tek yöne veya çift yönlü olarak ayarlanmasına bakılmaksızın tek yönlü filtreler kullanır. İlişkiyi seçip Her iki yönde de güvenlik filtresi uygula onay kutusunu işaretleyerek satır düzeyi güvenlikle çift yönlü çapraz filtrelemeyi el ile etkinleştirebilirsiniz. Bir tablo birden çok çift yönlü ilişkide yer alıyorsa, bu ilişkilerden yalnızca biri için bu seçeneği belirleyebilirsiniz. Ayrıca, satır düzeyi güvenliğin kullanıcı adına veya oturum açma kimliğine dayalı olduğu sunucu düzeyinde dinamik satır düzeyi güvenlik de uyguladığınızda bu seçeneği belirleyin.

Daha fazla bilgi için Power BI'da DirectQuery kullanarak çift yönlü çapraz filtreleme ve Tablolu BI Anlam Modelinin Güvenliğini Sağlama teknik makalesine bakın.

çift yönlü çapraz filtreleme

Varsayılan olarak, satır düzeyi güvenlik filtrelemesi, ilişkilerin tek yöne veya çift yönlü olarak ayarlanmasına bakılmaksızın tek yönlü filtreler kullanır.

İlişkiyi seçip Her iki yönde de güvenlik filtresi uygula onay kutusunu işaretleyerek satır düzeyi güvenlikle çift yönlü çapraz filtrelemeyi el ile etkinleştirebilirsiniz. Ayrıca, satır düzeyi güvenliğin kullanıcı adına veya oturum açma kimliğine dayalı olduğu sunucu düzeyinde dinamik satır düzeyi güvenlik de uyguladığınızda bu seçeneği belirleyin. Bir tablo birden çok çift yönlü ilişkide yer alıyorsa, bu ilişkilerden yalnızca biri için bu seçeneği belirleyebilirsiniz.

Caution

Çift yönlü güvenlik filtrelemenin etkinleştirilmesi, özellikle birçok ilişki veya büyük veri kümesine sahip modellerde sorgu performansını olumsuz etkileyebilir. Üretime dağıtmadan önce kapsamlı bir şekilde test edin.

Daha fazla bilgi için Power BI'da DirectQuery kullanarak çift yönlü çapraz filtreleme ve Tablolu BI Anlam Modelinin Güvenliğini Sağlama teknik makalesine bakın.

Modelinizde güvenliği yönetme

Anlam modelinizde güvenliği yönetmek için, dokuda anlam modelinizi kaydettiğiniz çalışma alanını açın ve aşağıdaki adımları uygulayın:

1. Fabric'te, anlamsal model için Diğer seçenekler menüsünü seçin. Semantik model adının üzerine geldiğinizde bu menü görüntülenir.

   

2. Güvenlik'i seçin.

   

Güvenlik sizi, oluşturduğunuz bir role üye eklediğiniz Rol Düzeyi Güvenlik sayfasına götürür. Katkıda Bulunan veya daha yüksek çalışma alanı rollerine sahip kullanıcılar Güvenlik seçeneğini görür ve kullanıcıları bir role atayabilir. Senaryoya bağlı olarak anlamsal model sahipliği veya derleme izni gerekebilir.

Note

Yalnızca Power BI Desktop'ta önceden tanımlanmış satır düzeyi güvenlik rollerine sahip modellerde veya Power BI hizmetinde veri modelinizi düzenlerken güvenliği yönetebilirsiniz. Modelinizde önceden tanımlanmış roller yoksa Power BI hizmetinde güvenliği yönetemezsiniz.

Rol üyeliğini yönetme

Üye ekle

Power BI hizmeti, kullanıcının veya güvenlik grubunun e-posta adresini veya adını yazarak role bir üye ekleyebilirsiniz. Power BI'da oluşturulan Grupları ekleyemezsiniz. Kuruluşunuza dış üyeler ekleyebilirsiniz. RLS'nin dış B2B konuk kullanıcılarla nasıl çalıştığına ilişkin yönergeler için bkz. Dış (B2B konuk) kullanıcılar için dikkat edilmesi gerekenler.

Satır düzeyi güvenliği ayarlamak için aşağıdaki grupları kullanabilirsiniz.

• Dağıtım Grubu
• E-posta etkinleştirilmiş Grup
• Microsoft Entra Güvenlik Grubu — Güvenlik grubu harici B2B konuk kullanıcılar içeriyorsa, bilinen sınırlamalar için Harici (B2B konuk) kullanıcılarla ilgili dikkat edilmesi gerekenler bölümüne bakın.

Important

Microsoft 365 grupları desteklenmez ve hiçbir rollere eklenemez. RLS rol üyeliği için yalnızca yukarıda listelenen grup türleri desteklenir.

Rol adının yanındaki veya Üyeler'in yanındaki parantez içindeki sayıya göre rolün parçası olan üye sayısını görebilirsiniz.

Üyeleri kaldırma

Adlarının yanındaki X işaretini seçerek üyeleri kaldırabilirsiniz.

Power BI hizmeti içindeki rolü doğrulama

Tanımladığınız rolü test ederek Power BI hizmeti doğru çalıştığını doğrulayabilirsiniz.

1. Rolün yanındaki Diğer seçenekler 'i (...) seçin.
2. Testi rol olarak seçin.

Note

Panolar, Rol olarak test et seçeneği kullanılarak test için kullanılamaz. Varsa, bu anlam modeliyle Power BI Desktop'tan yayımlanan rapora yönlendirilirsiniz.

Rapor yüklendiğinde aşağıdakileri doğrulayın:

• Raporda yalnızca rolde tanımlanan filtre ifadesiyle eşleşen veri satırları görüntülenir.
• Görseller, tablolar ve grafikler, tam veri kümesini değil filtrelenen verileri yansıtır.
• Dinamik RLS kullanıyorsanız, veriler Şu anda görünüyor başlığında gösterilen kimliğe karşılık gelir.

Sayfa üst bilgisinde, uygulanan rol gösterilir. Şu anda olarak görüntüleme seçeneğini seçerek diğer rolleri, rollerin birleşimini veya belirli bir kişiyi test edin. Burada, test edilen bireye veya role ilişkin önemli izin ayrıntılarını görürsünüz. İzinlerin RLS ile etkileşim kurması hakkında daha fazla bilgi için bkz . RLS kullanıcı deneyimi.

Sayfa üst bilgisinde Görüntüleme'yi seçerek, anlam modeline bağlı diğer raporları test edin. Yalnızca semantik modelinizle aynı çalışma alanında bulunan raporları test edebilirsiniz.

Normal görüntülemeye dönmek için Satır Düzeyi Güvenliğe Dön'e tıklayın.

Note

Rol olarak test etme özelliği, Çoklu Oturum Açma (SSO) etkinleştirilmiş DirectQuery modellerinde çalışmaz. Ayrıca Soru-Cevap görselleştirmeleri, Hızlı içgörü görselleştirmeleri ve Copilotdahil olmak üzere Rol olarak test et özelliğinde raporun tüm yönleri doğrulanamaz.

Tip

Eğer rol olarak test etme beklenen sonuçları göstermiyorsa, aşağıdakileri deneyin:

• DAX filtre ifadesi söz diziminin doğru olduğunu ve doğru sütun adlarına başvurdığını doğrulayın.
• Test etmek için doğru rolü seçtiğinizden emin olun.
• Dinamik RLS için, kullanıcı eşleme tablosunun ya USERPRINCIPALNAME() ya da USERNAME() için eşleşen değerler içerdiğini onaylayın.
• SSO'nun etkinleştirildiği DirectQuery modellerinde Rol olarak test desteklenmez. Bunun yerine, veri filtrelemeyi doğrulamak için gerçek bir Görüntüleyici rolü kullanıcısı olarak oturum açın.

username() veya userprincipalname() DAX işlevini kullanma

Veri kümenizdeki DAX işlevleri username() veya userprincipalname() avantajlarından yararlanabilirsiniz. Bunları Power BI Desktop'taki ifadeler içinde kullanabilirsiniz. Modelinizi yayımladığınızda, Power BI hizmeti içinde kullanılır.

Power BI Desktop'ta username(), ETKİALANI\Kullanıcı biçiminde bir kullanıcı döndürür ve userprincipalname(), biçiminde user@contoso.combir kullanıcı döndürür.

Power BI hizmeti içinde username() ve userprincipalname() kullanıcı asıl adını (UPN) döndürür. Bu, e-posta adresine benzer.

Power BI'da çalışma alanlarıyla RLS kullanma

Power BI Desktop raporunuzu Power BI hizmeti bir çalışma alanında yayımlarsanız, RLS rolleri çalışma alanında Görüntüleyici rolüne atanan üyelere uygulanır. Görüntüleyicilere anlam modeli için Derleme izinleri verilse bile RLS yine de geçerlidir. Örneğin, Derleme izinlerine sahip Görüntüleyiciler Excel'de Çözümle'yi kullanıyorsa, verilerin görünümü RLS ile kısıtlanır. Yönetici, Üye veya Katkıda Bulunan atanan çalışma alanı üyelerinin anlam modeli için düzenleme izni vardır ve bu nedenle RLS bunlar için geçerli değildir. RLS'nin çalışma alanında bulunan kişilere uygulanmasını istiyorsanız, yalnızca Görüntüleyici rolü atayabilirsiniz. Çalışma alanlarındaki roller hakkında daha fazla bilgi edinin.

Dış (B2B konuk) kullanıcılar için dikkat edilmesi gerekenler

Microsoft Entra B2B aracılığıyla dış kullanıcılarla Power BI içerik paylaşıyorsanız, RLS için aşağıdaki önemli noktalara dikkat edin.

Dış üyeleri olan Entra güvenlik grupları

Dış B2B konuk kullanıcıları içeren Microsoft Entra güvenlik grupları RLS rol üyeliği için kullanıldığında beklendiği gibi çalışmayabilir. Bazı yapılandırmalarda (özellikle dış kullanıcının konuk türü hesabı (üye türü hesabı yerine) olduğunda, konuğun grup üyeliği RLS filtreleri uygulanırken Power BI hizmeti tarafından doğru şekilde değerlendirilmez.

Önerilen geçici çözüm: Entra güvenlik grupları aracılığıyla RLS rollerine dış kullanıcılar eklemek yerine, bunları doğrudan e-posta adresine göre role ekleyin. E-posta adresi, kullanıcının B2B hesabıyla eşleştirilir. Bu, RLS filtreleri uygulandığında kimliklerinin doğru şekilde eşleştiğinden emin olunmasını sağlar. Daha fazla bilgi için bkz. Rol Üyeliğini Yönetme.

Çok sayıda dış kullanıcısı olan kuruluşlar için grup tabanlı rol üyeliği yerine ile USERPRINCIPALNAME() dinamik RLS kullanmayı göz önünde bulundurun. Bu yaklaşım, her kullanıcının kimliğini ayrı ayrı değerlendirir ve grup üyeliği çözümleme sorununu tamamen önler.

Important

Şu anda RLS rol üyeliği için Microsoft Entra güvenlik grupları kullanıyorsanız ve bu gruplar B2B konuk kullanıcıları içeriyorsa konuk kullanıcıların doğru filtrelenmiş verileri gördüğünü doğrulayın. Bunu yapmazlarsa dış kullanıcıları e-posta adreslerini kullanarak doğrudan RLS rolüne ekleyin.

Note

Bu sınırlamanın tam kapsamı, Microsoft Entra ID yapılandırmanıza ve kullanılan B2B konuk davetinin türüne bağlı olarak değişebilir. Dış erişim için grup tabanlı RLS'ye güvenmeden önce her zaman gerçek konuk kullanıcı hesaplarıyla test edin.

Dış kullanıcılarla içerik paylaşma hakkında daha fazla bilgi için bkz. Distribute Power BI content to external guest users with Microsoft Entra B2B.

Geçici çözümü uyguladıktan sonra sorun devam ederse, ek tanılama adımları için Sorun Giderme: Dış konuğun veri görmemesi başlıklı bölüme bakın.

B2B konukları için UPN çözünürlüğü

Dış B2B konuk kullanıcısı bir Power BI raporuna eriştiğinde, USERPRINCIPALNAME() DAX işlevi genellikle e-posta benzeri bir tanımlayıcı döndürür (örneğin, user@partner.com). Bazı yapılandırmalarda, #EXT# biçiminde, bir konuk UPN döndürebilir (örneğin, user_partner.com#EXT#@yourtenant.onmicrosoft.com).

Bu ayrım dinamik RLS için önemlidir. Eğer kullanıcı eşleme tablonuzun depoladığı tanımlayıcı biçimi, USERPRINCIPALNAME() 'in döndürdüğü biçimden farklıysa, filtre ifadesi eşleşmez ve konuk kullanıcı ya veri görmez ya da yanlış veri görebilir.

B2B konukları için USERNAME() davranışı

USERNAME() DAX işlevi, kullanıcının etki alanı\kullanıcı adı tanımlayıcısını döndürür. B2B konuk kullanıcıları için bu işlev genellikle bir etki alanı\kullanıcı adı biçimi yerine yapılandırmaya (örneğin, user@partner.com) bağlı olarak USERPRINCIPALNAME() benzeri bir UPN benzeri tanımlayıcı döndürür. B2B konukları için USERNAME() ve USERPRINCIPALNAME() genellikle aynı değeri döndürdüğünden, çoğu uygulama tutarlılık için USERPRINCIPALNAME() kullanır.

Tip

Mevcut dinamik RLS'niz kullanıyorsa USERNAME(), içeriği harici olarak paylaşmadan önce ortamınızdaki konuk kullanıcılar için döndürdüğü değeri doğrulayın. Test raporunda görüntülenen bir kart görseli USERNAME() ekleyerek kontrol edebilirsiniz. Önerilen yaklaşım: Kullanıcı eşleme tablonuzda, USERPRINCIPALNAME() tarafından döndürülen değerle aynı tanımlayıcı biçimini depolayın ve tutarlı bir şekilde kullanın. Çoğu durumda, e-posta adreslerinin kullanılması yönetimi basitleştirir:

[UserEmail] = USERPRINCIPALNAME()

Sütun UserEmail, hem dahili hem de harici kullanıcılar için user@partner.com gibi e-posta adreslerini içerir.

Note

tarafından USERPRINCIPALNAME() döndürülen değer, kullanıcının oturum açma tanımlayıcısıdır (UPN), e-posta adresi olmayabilir. Çoğu kullanıcı için bunlar aynıdır, ancak farklılık gösterebilir (örneğin, kullanıcının e-postası diğer ad olduğunda). Kullanıcı eşleme tablonuzu oluştururken, Microsoft Entra ID USERPRINCIPALNAME() özniteliği yerine mail tarafından döndürülen değeri kullanın.

Important

ile USERPRINCIPALNAME()dinamik RLS kullanıyorsanız, her zaman gerçek dış konuk kullanıcılarla test edin. Rol olarak test etme özelliği kendi kimliğinizi kullanır ve dış kullanıcı UPN çözümü sorunlarını ortaya çıkarmıyor.

Note

B2B konukları için UPN çözüm davranışı, kiracılar arası erişim ayarları ve konuk kullanıcı türü gibi Microsoft Entra ID yapılandırmanıza bağlı olarak değişebilir. Her zaman kendi ortamınızdaki davranışı doğrulayın.

Sorun giderme: Dış konuk veri görmüyor

B2B konuk kullanıcısı boş bir rapor görürse veya "veri yok" iletisi alıyorsa şu adımları izleyin:

1. Döndürülen UPN biçimini doğrulayın - Kullanarak USERPRINCIPALNAME() bir test ölçüsü oluşturun ve bunu bir kart görselinde görüntüleyin. Konuk kullanıcının döndürülen gerçek değeri görmek için raporu görüntülemesini sağlayın.
2. Kullanıcı eşleme tablosunu denetleyin - Eşleme tablosunun , bu konuk için döndürdüğü değerle tam olarak eşleşen USERPRINCIPALNAME() bir satır içerdiğini onaylayın.
3. Büyük/küçük harf duyarlılığını denetleme - DAX dize karşılaştırmaları varsayılan olarak büyük/küçük harfe duyarlı değildir, ancak veri kaynağınızın büyük/küçük harfe duyarlı değerler eklemediğinden emin olun.
4. Kiracılar arası erişim ayarlarını gözden geçirin - Kuruluşunuz cross-tenant erişim ilkeleri kullanıyorsa, bunlar Power BI hangi UPN biçiminin sunulduğunu etkileyebilir.
5. Gerçek konuk kullanıcıyla test edin - Rol olarak test et özelliği kendi kimliğinizi kullanır. Her zaman gerçek dış konuk hesabıyla doğrulayın.
6. Rol atamasını doğrulama — Konuk kullanıcı beklenenden daha fazla veri görürse RLS rolüne atandığını onaylayın. Herhangi bir RLS rolüne atanmamış kullanıcılar, RLS uygulandığı ancak eşleşen bir rol atanmadığı için genellikle hiç veri göremez (boş sonuçlar). DAX filtresi her satır için DOĞRU/YANLIŞ değerini değerlendirir. Yalnızca TRUE döndüren satırlar görüntülenir. Diğer her şey tamamen kaldırılır.

Power BI içeriğini dış kullanıcılarla paylaşma hakkında daha fazla bilgi için bkz. Distribute Power BI content to external guest users with Microsoft Entra B2B.

Dikkat edilecekler ve sınırlamalar

Bulut modellerinde satır düzeyi güvenlikle ilgili geçerli sınırlamaları burada görebilirsiniz:

• daha önce Power BI hizmeti rolleri ve kuralları tanımladıysanız, bunları Power BI Desktop'ta yeniden oluşturmanız gerekir.
• RLS'yi yalnızca Power BI Desktop ile oluşturulan anlam modellerinde tanımlayabilirsiniz. Excel ile oluşturulan anlam modelleri için RLS'yi etkinleştirmek istiyorsanız, önce dosyalarınızı Power BI Desktop (PBIX) dosyalarına dönüştürmeniz gerekir. Daha fazla bilgi edinin.
• Hizmet sorumluları RLS rolüne eklenemez. Buna göre, son etkin kimlik olarak hizmet sorumlusu kullanan uygulamalar için RLS uygulanmaz.
• Yalnızca İçeri Aktarma ve DirectQuery bağlantıları desteklenir. Analysis Services'e canlı bağlantılar şirket içi modelde işlenir.
• RLS etkinleştirildiğinde, DAX sorgularında ve ölçülerinde USERELATIONSHIP() işlevinin kullanılması beklenmeyen hatalara neden olabilir. Bu sorunu geçici olarak çözmek için, USERELATIONSHIP() kullanmaktan kaçınmak için DAX ifadelerinizi yeniden tasarlayın ve bunun yerine model düzeyi ilişkileri veya diğer DAX desenlerini kullanın.
• Rol olarak test et/Rol olarak görüntüle özelliği, çoklu oturum açma (SSO) etkinleştirilmiş DirectQuery modellerinde çalışmaz.
• Rolü test et/rolü görüntüle özelliği yalnızca anlam modelleri çalışma alanı raporlarını gösterir.
• Rol olarak test et/Rol olarak görüntüle özelliği sayfalandırılmış raporlarda çalışmaz.
• Belirteç tabanlı kimlik yalnızca Microsoft Entra kimlik doğrulamasına izin verecek şekilde yapılandırılmış bir Azure SQL Veritabanı bağlı kapasitedeki DirectQuery modellerinde çalışır. Daha fazla bilgi için bkz . Belirteç tabanlı kimlikle rapor ekleme
• 'IdentityBlob' parametresi, Azure SQL için bir OAuth 2.0 erişim belirtecidir ve yalnızca Azure SQL DirectQuery bağlantısı olan veri kümeleri için desteklenir. Mekanizmanın kendisi Azure SQL'e özgüdür: blob is kapsamı https://database.windows.net/.default olarak belirlenmiş bir Microsoft Entra erişim belirtecidir. App-owns-data embedding içindeki diğer veri kaynakları için eşdeğer belirteç geçirme mekanizması yoktur. Daha fazla bilgi için bkz. GenerateToken için REST API başvurusu.

Dinamik RLS ile ilgili önemli noktalar ve sınırlamalar

, USERPRINCIPALNAME()veya USERNAME()gibi CUSTOMDATA()DAX işlevleriyle dinamik satır düzeyi güvenlik (RLS) kullandığınızda aşağıdaki noktalara dikkat edin.

B2B kiracılar arası senaryolar

B2B senaryolarında USERPRINCIPALNAME(), kiracı yapılandırmasına bağlı olarak değişebilen, Power BI hizmetinin çözümlediği kimliği döndürür. Aşağıdakilerden biri olarak görünebilir:

• Dış kullanıcının e-posta adresi ()user@partner.com veya
• user_partner.com#EXT#@tenant.onmicrosoft.com gibi kiracı tarafından çözümlenen bir değer

Tam biçim garanti edilmediğinden ortamınızda doğrulanması gerekir.

Kullanıcı eşleme tablonuz, tanımlayıcıları USERPRINCIPALNAME()’ın konuk kullanıcılar için döndürdüğünden farklı bir biçimde depoluyorsa, RLS filtre ifadesi eşleşmez ve konuk hiçbir veri göremez veya yanlış veri görür. Ortamınızdaki dış kullanıcılar için USERPRINCIPALNAME() tarafından döndürülen tam değeri her zaman doğrulayın.

Tip

kullanarak USERPRINCIPALNAME() bir test ölçüsü oluşturun ve bunu bir kart görselinde görüntüleyin. Dış konuk kullanıcıların, döndürülen değerin kullanıcı eşleme tablonuzla eşleştiğinden emin olmak için raporu görüntülemesini sağlayın. Bu basit test, eşleşmeyen kimlik değerlerinde hata ayıklama saatlerini engelleyebilir.

Dinamik RLS ile rol sınırlamaları olarak test et

Power BI hizmeti Test as role özelliği, dinamik RLS ifadelerini değerlendirirken kendi kimliğinizi kullanır. Bu, simülasyonunu yapmaya çalıştığınız kullanıcının değil UPN'nizi döndürdüğü anlamına gelirUSERPRINCIPALNAME(). Belirli bir B2B konuk kullanıcının veya hizmet aslının ne göreceğini görmek için Test as role kullanılamaz.

Rol olarak test et, rol üyeliğini simüle eder ancak özellikle B2B konukları veya gömülü senaryolar için başka bir kullanıcının kimlik doğrulama bağlamını tam olarak yansıtmaz.

Dış kullanıcılar için dinamik RLS'yi doğrulamak için gerçek konuk kullanıcı olarak oturum açın ve raporu doğrudan görüntüleyin. Bu, beklenen değeri döndürdüğünü USERPRINCIPALNAME() ve RLS filtrelerinin bu kullanıcı için doğru şekilde eşleştiğini onaylamanın tek yoludur.

Hizmet sorumlularıyla gömülü senaryolar

Bir rapora, hizmet sorumlusu kullanarak kimlik doğrulayan gömülü bir uygulama üzerinden erişildiğinde, USERPRINCIPALNAME() ve USERNAME(), son kullanıcının kimliğini değil, hizmet sorumlusunun uygulama kimliğini veya boş bir dize döndürür.

Bu işlevler son kullanıcı kimliğini döndürmez ve bu nedenle hizmet sorumlusu ekleme senaryolarında kullanıcı başına filtreleme için kullanılamaz. Bu, bu işlevleri temel alan dinamik RLS filtrelerinin ekli senaryolarda kullanıcı başına verileri filtrelemeymeyeceği anlamına gelir.

Ekli senaryolarda kullanıcı başına RLS uygulamak için Power BI REST API'sinin effective identity özelliğini kullanın. Bir gömme belirteci oluştururken EffectiveIdentity nesnesini uygun kullanıcı adı ve rollerle iletin. RLS kurallarınızda CUSTOMDATA() kullanılıyorsa, özel veri dizesini EffectiveIdentity.CustomData aracılığıyla iletin.

Daha fazla bilgi için bkz. ISV'ler için Katıştırılmış senaryolar için RLS.

Important

Service principal ile gömme yaparken, RLS filtrelerinin doğru şekilde uygulandığını doğrulamak için her zaman EffectiveIdentity içeren gerçek gömme belirteçleriyle test edin. Power BI hizmeti Test as role özelliği, katıştırılmış kimlik doğrulama akışlarının benzetimini yapmaz.

Power BI raporu, RLS ile yapılandırılmış bir satıra referans verirse, silinmiş veya mevcut olmayan bir alan için olduğu gibi aynı mesajın görüntülendiğini unutmayın. Bu kullanıcılar için rapor bozuk gibi görünüyor.

Sıkça Sorulan Sorular

Soru: Daha önce Power BI hizmeti bir veri kümesi için roller ve kurallar oluşturduysam ne olur? Ben bir şey yapmasam bile hâlâ çalışırlar mı?
Yanıt: Hayır, görseller düzgün işlenmez. Power BI Desktop'ta rolleri ve kuralları yeniden oluşturmanız ve ardından Power BI hizmetine yayımlamanız gerekir.

Soru: Analysis Services veri kaynakları için bu rolleri oluşturabilir miyim?
Yanıt: Evet, verileri Power BI Desktop'a aktardıysanız. Canlı bağlantı kullanıyorsanız, Power BI hizmeti içinde RLS'yi yapılandıramazsınız. Şirket içi Analysis Services modelinde RLS tanımlarsınız.

Soru: Kullanıcılarım tarafından erişilebilen sütunları veya ölçüleri sınırlamak için RLS kullanabilir miyim?
Yanıt: Hayır, kullanıcının belirli bir veri satırına erişimi varsa bu satıra ait tüm veri sütunlarını görebilir. Sütunlara ve sütun meta verilerine erişimi kısıtlamak için nesne düzeyinde güvenlik kullanmayı göz önünde bulundurun.

Soru: RLS, ayrıntılı verileri gizlememe izin veriyor ancak görsellerde özetlenen verilere erişim izni veriyor mu?
Yanıt: Hayır, tek tek veri satırlarının güvenliğini sağlarsınız, ancak kullanıcılar her zaman ayrıntıları veya özetlenmiş verileri görebilir.

Soru: Veri kaynağımda zaten tanımlanmış güvenlik rolleri var (örneğin, SQL Server rolleri veya SAP BW rolleri). Bu rollerle RLS arasındaki ilişki nedir?
Yanıt: Yanıt, verileri içeri aktarıp aktarmadığınıza veya DirectQuery kullanıp kullanmadığınıza bağlıdır. Verileri Power BI veri kümenize aktarıyorsanız, veri kaynağınızdaki güvenlik rolleri kullanılmaz. Bu durumda, Power BI'a bağlanan kullanıcılar için güvenlik kurallarını zorunlu kılmak için RLS tanımlamanız gerekir. DirectQuery kullanıyorsanız veri kaynağınızdaki güvenlik rolleri kullanılır. Kullanıcı bir raporu açtığında Power BI, temel alınan veri kaynağına kullanıcının kimlik bilgilerine göre verilere güvenlik kuralları uygulayan bir sorgu gönderir.

Soru: Kullanıcı birden fazla role ait olabilir mi?
Yanıt: Bir kullanıcı birden çok role ait olabilir ve roller birikimlidir. Örneğin, bir kullanıcı hem "Satış" hem de "Pazarlama" rollerine aitse, bu rollerin her ikisi için de verileri görebilir.

İlgili içerik

• Power BI Desktop için satır düzeyi güvenlik (RLS) ile veri erişimini kısıtlama
• Power BI uygulama planlaması: Tüketici güvenliği planlamayı raporlama
• ISV'ler için Katıştırılmış senaryolar için RLS
• Microsoft Entra B2B ile Power BI içeriğini dış konuk kullanıcılara dağıtın

Sorularınız var mı? Power BI Topluluğu Önerileri'ni sormayı deneyin. Power BI'ı geliştirmek için fikirlere katkıda bulunma