As more enterprises adopt Power BI into their BI environment, questions still remain about data security. In his last webinar, our Business Intelligence Architect, Steve Hughes, discussed data security and compliance within the Power BI platform, including data classification, privacy levels and other settings that help manage security.
Expanding on his widespread knowledge of the topic, Steve has written a series of blog posts to answer specific questions about the service. Previous blog posts in this series cover the following topics: data classification, on-premises data gateway, sharing data, as well as compliance and encryption.
The Power BI service is updated frequently. These articles were created based on the Power BI implementation in early April 2017. You may find improvements and changes that impact your experience that are based on newer releases. Feel free to add comments to highlight changes.
Row Level Security in Power BI
Row level security is the ability to filter content based on a user's role. There are two ways to implement row level security in Power BI – through Power BI or using SSAS. Power BI has the ability to create roles based on DAX filters in the desktop which affect what users see in the various assets of Power BI.
In order for this to work, you will need to deploy to a Workspace where users only have read permissions. If the members of the group associated to the Workspace have edit permissions, row level security in Power BI will be ignored.
Both DirectQuery and data loaded into the model support RLS is the manner described above.
SQL Server Analysis Services implements RLS on its own. SSAS requires the enterprise gateway to implement LiveConnection and RLS. RLS is supported by using EffectiveUserName on the connection from Power BI to the on-premises SSAS instance (refer to documentation on setting up live connections to SSAS). This method works for both multidimensional and tabular models.