Power BI Desktop’ta satır düzeyi güvenlik (RLS) kılavuzuRow-level security (RLS) guidance in Power BI Desktop

Bu makale, Power BI Desktop'la çalışan veri modelleyicilerine yöneliktir.This article targets you as a data modeler working with Power BI Desktop. Veri modellerinizde satır düzeyi güvenliği (RLS) zorunlu kılmaya yönelik iyi tasarım uygulamaları açıklanmaktadır.It describes good design practices for enforcing row-levels security (RLS) in your data models.

RLS’nin tablo satırlarını filtrelediğini kavramak önemlidir.It's important to understand RLS filters table rows . Tablo, sütun veya ölçüler dahil olmak üzere model nesnelerine erişimi kısıtlamak için yapılandırılamaz.They can't be configured to restrict access to model objects, including tables, columns, or measures.

Not

Bu makalede RLS’nin ne olduğu veya nasıl ayarlanacağı açıklanmaz.This article doesn't describe RLS or how to set it up. Daha fazla bilgi için bkz. Power BI Desktop için satır düzeyi güvenlik (RLS) ile veri erişimini kısıtlama.For more information, see Restrict data access with row-level security (RLS) for Power BI Desktop.

Ayrıca, Azure Analysis Services veya SQL Server Analysis Services ile dışarıda barındırılan modellerle kurulan canlı bağlantılarda RLS’yi zorunlu kılma konusu bu makalede açıklanmaz.Also, it doesn't cover enforcing RLS in live connections to external-hosted models with Azure Analysis Services or SQL Server Analysis Services. Bu durumlarda RLS, Analysis Services tarafından zorunlu kılınır.In these cases, RLS is enforced by Analysis Services. Power BI çoklu oturum açma (SSO) kullanarak bağlanırsa RLS’yi Analysis Services zorunlu kılar (hesabın yönetici ayrıcalıkları yoksa).When Power BI connects using single-sign on (SSO), Analysis Services will enforce RLS (unless the account has admin privileges).

Rol oluşturmaCreate roles

Birden çok rol oluşturulabilir.It's possible to create multiple roles. Tek bir rapor kullanıcısına gereken izinleri düşünüyorsanız bu kullanıcının birden çok rolün üyesi olduğu bir tasarım yerine, tüm bu izinleri sağlayan tek bir rol oluşturmaya gayret edin.When you're considering the permission needs for a single report user, strive to create a single role that grants all those permissions, instead of a design where a report user will be a member of multiple roles. Çünkü bir rapor kullanıcısı, doğrudan kendi kullanıcı hesabını kullanarak veya güvenlik grubu üyeliği tarafından dolaylı yoldan birden çok role eşlenebilir.It's because a report user could map to multiple roles, either directly by using their user account or indirectly by security group membership. Birden çok rol eşlemesi, beklenmeyen sonuçlara neden olabilir.Multiple role mappings can result in unexpected outcomes.

Bir rapor kullanıcısı birden çok role atandığında, RLS filtreleri eklenebilir hale gelir.When a report user is assigned to multiple roles, RLS filters become additive. Bu, rapor kullanıcılarının bu filtrelerin birleşimini gösteren tablo satırlarını görebileceği anlamına gelir.It means report users can see table rows that represent the union of those filters. Dahası, bazı senaryolarda rapor kullanıcısının bir tablodaki satırları görmeyeceğini garanti etmek mümkün değildir.What's more, in some scenarios it's not possible to guarantee that a report user doesn't see rows in a table. Bu nedenle, SQL Server veritabanı nesnelerine (ve diğer izin modellerine) izinler uygulanmadıkça, “bir kez reddedilen her zaman reddedilir” ilkesi de uygulanmaz.So, unlike permissions applied to SQL Server database objects (and other permission models), the "once denied always denied" principle doesn't apply.

İki rolü olan bir model düşünün: Çalışanlar adlı ilk rol, aşağıdaki kural ifadesini kullanarak tüm Bordro tablo satırlarına yönelik erişimi kısıtlar:Consider a model with two roles: The first role, named Workers , restricts access to all Payroll table rows by using the following rule expression:

FALSE()

Not

Kuralın ifadesi false olarak değerlendirilmediğinde kural herhangi bir tablo satırı döndürmez.A rule will return no table rows when its expression evaluates to false .

Ancak Yöneticiler adlı ikinci rol, aşağıdaki kural ifadesini kullanarak tüm Bordro tablo satırlarına yönelik erişime izin verir:Yet, a second role, named Managers , allows access to all Payroll table rows by using the following rule expression:

TRUE()

Şuna dikkat edin: Bir rapor kullanıcısı her iki rolle de eşlenirse tüm Bordro tablosu satırlarını görecektir.Take care: Should a report user map to both roles, they'll see all Payroll table rows.

RLS’yi iyileştirmeOptimize RLS

RLS, her DAX sorgusuna otomatik olarak filtre uygulayarak çalışır ve bu filtrelerin sorgu performansı üzerinde olumsuz bir etkisi olabilir.RLS works by automatically applying filters to every DAX query, and these filters may have a negative impact on query performance. Bu nedenle, verimli RLS için modelin iyi tasarlanması gerekir.So, efficient RLS comes down to good model design. Aşağıdaki makalelerde açıklandığı şekilde, model tasarım kılavuzunu izlemek önemlidir:It's important to follow model design guidance, as discussed in the following articles:

Genel anlamda, RLS filtrelerini olgu türünde tablolar yerine boyut türünde tablolarda zorunlu kılmak çoğu zaman daha verimlidir.In general, it's often more efficient to enforce RLS filters on dimension-type tables, and not fact-type tables. Ayrıca, RLS filtrelerinin diğer model tablolarına yayılmasını sağlamak için iyi tasarlanmış ilişkileri kullanabilirsiniz.And, rely on well-designed relationships to ensure RLS filters propagate to other model tables. Bu nedenle, model ilişkileri aynı sonuca ulaşacağı zaman LOOKUPVALUE DAX işlevini kullanmaktan kaçının.So, avoid using the LOOKUPVALUE DAX function when model relationships could achieve the same result.

DirectQuery tablolarında RLS filtreleri her zorunlu kılındığında ve diğer DirectQuery tablolarıyla ilişkiler söz konusu olduğunda, kaynak veritabanını iyileştirdiğinizden emin olun.Whenever RLS filters are enforced on DirectQuery tables and there are relationships to other DirectQuery tables, be sure to optimize the source database. Bu işlem için uygun dizinlerin tasarlanması veya kalıcı olarak hesaplanan sütunların kullanılması gerekebilir.It can involve designing appropriate indexes or using persisted computed columns. Daha fazla bilgi için bkz. Power BI Desktop’ta DirectQuery modeli kılavuzu.For more information, see DirectQuery model guidance in Power BI Desktop.

RLS etkisini ölçmeMeasure RLS impact

Performans Analizi’ni kullanarak Power BI Desktop’taki RLS filtrelerinin performans etkisini ölçebilirsiniz.It's possible to measure the performance impact of RLS filters in Power BI Desktop by using Performance Analyzer. İlk olarak, RLS zorunlu kılınmadığında rapor görseli sorgu sürelerini belirleyin.First, determine report visual query durations when RLS isn't enforced. Daha sonra, 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.Then, use the View As command on the Modeling ribbon tab to enforce RLS and determine and compare query durations.

Rol eşlemelerini yapılandırmaConfigure role mappings

Power BI’da yayımlandığında, üyeleri veri kümesi rolleriyle eşlemeniz gerekir.Once published to Power BI, you must map members to dataset roles. Yalnızca veri kümesi sahipleri veya çalışma alanı yöneticileri roller üye ekleyebilir.Only dataset owners or workspace admins can add members to roles. Daha fazla bilgi için bkz. Power BI ile satır düzeyi güvenlik (RLS) (Modelinizde güvenliği yönetme).For more information, see Row-level security (RLS) with Power BI (Manage security on your model).

Üyeler kullanıcı hesapları veya güvenlik grupları olabilir.Members can be user accounts or security groups. Mümkün olduğunda, güvenlik gruplarını veri kümesi rollerine eşlemenizi öneririz.Whenever possible, we recommend you map security groups to dataset roles. Buna Azure Active Directory’deki güvenlik grubu üyeliklerini yönetmek de dahildir.It involves managing security group memberships in Azure Active Directory. Büyük olasılıkla, görevi ağ yöneticilerinize devreder.Possibly, it delegates the task to your network administrators.

Rolleri doğrulamaValidate roles

Modeli doğru şekilde filtrelemesini sağlamak için her bir rolü test edin.Test each role to ensure it filters the model correctly. Bu işlem, Modelleme şerit sekmesindeki Farklı Görüntüle komutunu kullanarak kolayca yapılır.It's easily done by using the View As command on the Modeling ribbon tab.

Model USERNAME DAX işlevini kullanarak dinamik kurallara sahip olduğunda, beklenen ve beklenmeyen değerleri test ettiğinizden emin olun.When the model has dynamic rules using the USERNAME DAX function, be sure to test for expected and unexpected values. Power BI içeriğini eklerken (özellikle Uygulama verilere sahiptir senaryosu kullanılırken) uygulama mantığı tüm değerleri etkili bir kimlik kullanıcı adı olarak geçirebilir.When embedding Power BI content—specifically using the App owns data scenario—app logic can pass any value as an effective identity user name. Mümkün olduğunda, yanlışlıkla veya kötü amaçlı kullanılan değerlerin filtrelerde satır döndürmemesini sağlayın.Whenever possible, ensure accidental or malicious values result in filters that return no rows.

Uygulamanın, kullanıcının iş rolünü etkin kullanıcı adı olarak geçirdiği, Power BI Embedded kullandığınız bir örneği ele alın: Bu “Yönetici” veya “Çalışan” olabilir.Consider an example using Power BI embedded, where the app passes the user's job role as the effective user name: It's either "Manager" or "Worker". 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.Managers can see all rows, but workers can only see rows where the Type column value is "Internal".

Aşağıdaki kural ifadesi tanımlanmıştır:The following rule expression is defined:

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

Bu kural ifadesiyle ilgili sorun, “Çalışan” hariç tüm değerlerin tüm tablo satırlarını döndürmesidir.The problem with this rule expression is that all values, except "Worker", return all table rows . Yani “Çlışan” gibi yanlışlıkla yazılan bir değer, istenmeyen bir şekilde tüm tablo satırlarını döndürür.So, an accidental value, like "Wrker", unintentionally returns all table rows. Bu nedenle, beklenen her değeri test eden bir ifade yazmak daha güvenlidir.Therefore, it's safer to write an expression that tests for each expected value. Aşağıdaki iyileştirilmiş kural ifadesinde, beklenmeyen bir değer tabloda hiç satır döndürmemektedir.In the following improved rule expression, an unexpected value will result in the table returning no rows.

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

Kısmi RLS tasarlamaDesign partial RLS

Bazen, hesaplamalar için RLS filtreleri tarafından kısıtlanmayan değerler gerekir.Sometimes, calculations need values that aren't constrained by RLS filters. Örneğin bir raporda, rapor kullanıcısının satış bölgesinde elde edilen gelirin elde edilen tüm gelire oranının gösterilmesi gerekebilir.For example, a report may need to display a ratio of revenue earned for the report user's sales region over all revenue earned .

Bir DAX ifadesinin RLS’yi geçersiz kılması mümkün olmasa da (aslında RLS’nin zorunlu kılındığını bile belirleyemez) bir özet model tablosu kullanabilirsiniz.While it's not possible for a DAX expression to override RLS—in fact, it can't even determine that RLS is enforced—you can use a summary model table. Özet model tablosu “tüm bölgeler” için geliri almak üzere sorgulanır ve RLS filtreleriyle kısıtlanmaz.The summary model table is queried to retrieve revenue for "all regions" and it's not constrained by any RLS filters.

Bu tasarım gereksinimini nasıl uygulayabileceğinizi görelim.Let's see how you could implement this design requirement. İlk olarak, aşağıdaki model tasarımını ele alın:First, consider the following model design:

Model diyagramının bir resmi gösterilir. Aşağıdaki paragraflarda açıklanmıştır.

Model dört tablodan oluşur:The model comprises four tables:

  • Salesperson tablosu, satış personeli başına bir satır depolar.The Salesperson table stores one row per salesperson. Her satış personelinin e-posta adresinin depolandığı EmailAddress sütununu içerir.It includes the EmailAddress column, which stores the email address for each salesperson. Bu tablo gizlidir.This table is hidden.
  • Satış tablosu, sipariş başına bir satır depolar.The Sales table stores one row per order. Rapor kullanıcısının bölgesinde elde edilen gelirlerin, tüm bölgelerde elde edilen gelirlere oranını döndürmek üzere tasarlanan Revenue % All Region ölçüsünü içerir.It includes the Revenue % All Region measure, which is designed to return a ratio of revenue earned by the report user's region over revenue earned by all regions.
  • Date tablosu tarih başına bir satır döndürür ve yıl ile ay şeklinde filtreleyip gruplandırmaya olanak verir.The Date table stores one row per date and allows filtering and grouping year and month.
  • SalesRevenueSummary , hesaplanan bir tablodur.The SalesRevenueSummary is a calculated table. Her sipariş tarihi için toplam geliri depolar.It stores total revenue for each order date. Bu tablo gizlidir.This table is hidden.

Aşağıdaki ifadede SalesRevenueSummary hesaplanan tablosu tanımlanır:The following expression defines the SalesRevenueSummary calculated table:

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

Not

Aynı tasarım gereksinimini toplama tablosu da karşılayabilirdi.An aggregation table could achieve the same design requirement.

Salesperson tablosuna aşağıdaki RLS kuralı uygulanır:The following RLS rule is applied to the Salesperson table:

[EmailAddress] = USERNAME()

Üç model ilişkisinin her biri, aşağıdaki tabloda açıklanır:Each of the three model relationships is described in the following table:

İlişkiRelationship AçıklamaDescription
Akış çizelgesi sonlandırıcı 1. Salesperson ve Sales tabloları arasında çoka çok ilişki vardır.There's a many-to-many relationship between the Salesperson and Sales tables. RLS kuralı, USERNAME DAX işlevini kullanarak gizli Salesperson tablosunun EmailAddress sütununu filtreler.The RLS rule filters the EmailAddress column of the hidden Salesperson table by using the USERNAME DAX function. Region sütun değeri (rapor kullanıcısı için) Sales tablosuna yayılır.The Region column value (for the report user) propagates to the Sales table.
Akış çizelgesi sonlandırıcı 2. Date ve Sales tablolarında bire çok ilişkiler vardır.There's a one-to-many relationships between the Date and Sales tables.
Akış çizelgesi sonlandırıcı 3. Date ve SalesRevenueSummary tabloları arasında bire çok ilişkiler vardır.There's a one-to-many relationships between the Date and SalesRevenueSummary tables.

Aşağıdaki ifadede Revenue % All Region ölçüsü açıklanır:The following expression defines the Revenue % All Region measure:

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

Not

Hassas bilgileri açığa çıkarmaktan kaçınmaya özen gösterin.Take care to avoid disclosing sensitive facts. Bu örnekte yalnızca iki bölge varsa bir rapor kullanıcısının diğer bölge için geliri hesaplaması mümkündür.If there are only two regions in this example, then it would be possible for a report user to calculate revenue for the other region.

RLS’yi kullanmaktan kaçınmaAvoid using RLS

İhtiyaç duymadığınız sürece RLS’yi kullanmaktan kaçının.Avoid using RLS, whenever it makes sense to do so. Statik filtreler uygulayan az sayıda basitleştirilmiş RLS kuralınız varsa bunun yerine birden çok veri kümesini yayımlamanız yararlı olabilir.If you have only a small number of simplistic RLS rules that apply static filters, consider publishing multiple datasets instead. Aynı veri izinlerine sahip her veri kümesi belirli bir rapor kullanıcı kitlesine yönelik veri içerdiğinden, veri kümelerinin hiçbiri rolleri tanımlamaz.None of the datasets define roles because each dataset contains data for a specific report user audience, which has the same data permissions. Daha sonra, kitle başına bir çalışma alanı oluşturup çalışma alanına veya uygulamaya erişim izinleri atayın.Then, create one workspace per audience and assign access permissions to the workspace or app.

Örneğin, yalnızca iki satış bölgesi olan bir şirket farklı çalışma alanlarına her satış bölgesi için bir veri kümesi yayımlamaya karar verir.For example, a company that has just two sales regions decides to publish a dataset for each sales region to different workspaces. Veri kümeleri RLS’yi zorunlu kılmaz.The datasets don't enforce RLS. Ancak, kaynak verilerini filtrelemek için sorgu parametrelerini kullanırlar.They do, however, use query parameters to filter source data. Bu yöntemle, aynı model her çalışma alanında yayımlanır, yalnızca veri kümesi parametre değerleri farklıdır.This way, the same model is published to each workspace—they just have different dataset parameter values. Satış personellerine yalnızca bir çalışma alanına (veya yayımlanan uygulamaya) erişim atanır.Salespeople are assigned access to just one of the workspaces (or published apps).

RLS’den kaçınmanın çeşitli avantajları vardır:There are several advantages associated with avoiding RLS:

  • İyileştirilmiş sorgu performansı: Daha az filtreye sahip olduğundan, performansın iyileşmesine yardımcı olabilir.Improved query performance: It can result in improved performance due to fewer filters.
  • Daha küçük modeller: Daha fazla model oluştursa da bunlar boyut bakımından daha küçüktür.Smaller models: While it results in more models, they are smaller in size. Özellikle barındırma kapasitesi kaynaklar üzerinde baskı hissediyorsa daha küçük modeller sorgu ve veri yenileme yanıt hızını iyileştirebilir.Smaller models can improve query and data refresh responsiveness, especially if the hosting capacity experiences pressure on resources. Ayrıca model boyutlarını, kapasiteniz tarafından uygulanan boyut sınırlarının altında tutmak daha kolaydır.Also, it's easier to keep model sizes beneath size limits imposed by your capacity. Son olarak, farklı kapasitelerde çalışma alanları oluşturabileceğinizden (veya bunları farklı kapasitelere taşıyabileceğinizden), farklı kapasiteler arasında iş yüklerini dengelemek daha kolaydır.Lastly, it's easier to balance workloads across different capacities, because you can create workspaces on—or move workspaces to—different capacities.
  • Ek özellikler: Web’de yayımlama gibi RLS ile çalışmayan Power BI özellikleri kullanılabilir.Additional features: Power BI features that don't work with RLS, like Publish to web, can be used.

Ancak, RLS’den kaçınmanın bazı dezavantajları da vardır:However, there are disadvantages associated with avoiding RLS:

  • Birden çok çalışma alanı : Her rapor kullanıcı kitlesi için bir çalışma alanı gerekir.Multiple workspaces: One workspace is required for each report user audience. Uygulamalar yayımlandıysa bu, rapor kullanıcı kitlesi başına bir uygulama olduğu anlamına gelir.If apps are published, it also means there's one app per report user audience.
  • İçeriğin çoğaltılması: Rapor ve panoların her bir çalışma alanında oluşturulmaları gerekir.Duplication of content: Reports and dashboards must be created in each workspace. Ayarlayıp sürdürmek için daha fazla çaba ve zaman harcamanız gerekir.It requires additional effort and time to set up and maintain.
  • Yüksek ayrıcalığa sahip kullanıcılar: Birden çok rapor kullanıcı kitlesine ait olan yüksek ayrıcalığa sahip kullanıcılar, verilerin birleştirilmiş bir görünümünü göremez.High privilege users: High privilege users, who belong to multiple report user audiences, can't see a consolidated view of the data. Birden çok raporu (farklı çalışma alanlarından veya uygulamalardan) açmaları gerekir.They'll need to open multiple reports (from different workspaces or apps).

RLS sorunlarını gidermeTroubleshoot RLS

RLS beklenmeyen sonuçlar üretirse aşağıdaki sorunları denetleyin:If RLS produces unexpected results, check for the following issues:

  • Model tabloları arasında, sütun eşleme ve filtre yönü bakımından hatalı ilişkiler var.Incorrect relationships exist between model tables, in terms of column mappings and filter directions.
  • Güvenlik filtrelerini her iki yönde de uygula ilişki özelliği doğru ayarlanmamış.The Apply security filter in both directions relationship property isn't correctly set. Daha fazla bilgi için bkz. Çift yönlü ilişki kılavuzu.For more information, see Bi-directional relationship guidance.
  • Tablolar veri içermiyor.Tables contain no data.
  • Tablolara yanlış değerler yüklenmiş.Incorrect values are loaded into tables.
  • Kullanıcı birden çok role eşlenmiş.The user is mapped to multiple roles.
  • Model, toplama tabloları içeriyor ve RLS kuralları toplamalar ile ayrıntıları tutarlı bir şekilde filtrelemiyor.The model includes aggregation tables, and RLS rules don't consistently filter aggregations and details. Daha fazla bilgi için bkz. Power BI Desktop’ta toplamaları kullanma (toplamalar için RLS).For more information, see Use aggregations in Power BI Desktop (RLS for aggregations).

Belirli bir kullanıcının hiç veri görmemesi, UPN’lerinin depolanmamasından veya yanlış girilmesinden kaynaklanabilir.When a specific user can't see any data, it could be because their UPN isn't stored or it's entered incorrectly. Bir ad değişikliğinin sonucu olarak kullanıcı hesabı değiştiyse bu durum bir anda oluşabilir.It can happen abruptly because their user account has changed as the result of a name change.

İpucu

Test amacıyla, USERNAME DAX işlevini döndüren bir ölçü ekleyin.For testing purposes, add a measure that returns the USERNAME DAX function. Bunu “Ben Kimim?” şeklinde adlandırabilirsiniz.You might name it something like "Who Am I". Daha sonra, ölçüyü rapordaki bir kart görseline ekleyip Power BI’da yayımlayın.Then, add the measure to a card visual in a report and publish it to Power BI.

Belirli bir kullanıcı tüm verileri görebiliyorsa raporlara doğrudan çalışma alanından erişiyor olabilir veya veri kümesinin sahibi olabilir.When a specific user can see all data, it's possible they're accessing reports directly in the workspace and they're the dataset owner. RLS yalnızca şu durumlarda zorunlu kılınır:RLS is only enforced when:

  • Rapor bir uygulamada açıldığında.The report is opened in an app.
  • Rapor bir çalışma alanında açıldığında ve kullanıcı Görüntüleyici rolüyle eşlendiğinde.The report is opened in a workspace, and the user is mapped to the Viewer role.

Sonraki adımlarNext steps

Bu makaleyle ilgili daha fazla bilgi için aşağıdaki kaynaklara bakın:For more information related to this article, check out the following resources: