Category: Power BI

Marc Lelijveld and Vytautas Kraujalis lock things down, over and over and over:

Imagine, you have everything setup and well secured in your data lakehouse, or data warehouse if you will. Then a user starts consuming the data in Power BI and imports all data according to the security applied to that users’ permissions. Once the data is imported, all data can easily be shared to others who might have other permissions on the same dataset. Potentially, this leads to a breach of data to people who should not have accessed this data at all. Ideally, you replicate the security from the source into Power BI, but without setting up everything by hand.

In this blog post, you will learn how you can automate the replication of security from source to your Power BI data model in just a few steps. A blog post based on an actual client case and written by Vytautas Kraujalis and myself.

Click through for an explanation and a link to the GitHub repo containing all of the scripts.

Reza Rad continues a series on data security in Power BI with two posts. The first covers row-level security:

There are multiple levels in which you can secure the data in a Power BI Dataset. Row Level Security is about applying security on a data row level. For example, sales managers in the united states should only see data for the United States, not Europe. The sales Manager in Europe won’t be able to see sales in Australia or the United States. And someone from the board of directors can see everything. The reason was that Row Level Security wasn’t part of the Power BI model. Now in the new version of Power BI Desktop, the security configuration is part of the model and will be deployed with the model.

The second looks at dynamic row-level security:

The most important question is, why dynamic row-level security? To answer this question, you must consider the limitation of static row-level security. Static row-level security is simple to implement. However, if you have thousands of roles, then it would be a nightmare to maintain. For example, if you want to create a payroll Power BI report in a company with ten thousand users, you want every user to have his/her role. Dynamic row-level security is the answer for such scenarios.

Check out both posts for more info.

Reza Rad explains different ways to secure data in Power BI:

Power BI supports the security of the data at the dataset level. This security means everyone can see the data they are authorized to see. There are different levels of that in Power BI, including Row-Level Security, Column-Level Security, and Object-Level Security. All these help Power BI Developers create one dataset but give users different views of the data from the same report. In this article, I’ll explain each of those methods and give some guidance on how to use them.

This serves as the opener to a series of articles on Power BI data security.

Marc Lelijveld points out that, just because the kitten covered its eyes and can’t see you don’t mean that you can’t see it:

Most of us probably know, but every now and then, I still run into cases where hiding pages in a Power BI report is used for security purposes. Although hiding pages might seem like a security feature, it is not intended to be used as one since it can be easily bypassed. Users can find hidden pages by simple URL tweaking or right-clicking on the tabs. The article provides an example of how users can use the Reports-Get Pages API to get all report pages and report sections without having to write a single line of code. The default page when publishing a report is the one that is open, even if it is hidden.

Yeah, hiding pages is really more of a convenience thing, especially if you’re making heavy use of drillthrough and other cross-page functionality.