This blog is part of a blog series on good Power BI practices.
Topics vary from development tips to governance and from documentation to version control with concrete examples when applicable.
Today data security is the foundation of every impact-driven data solution. In Power BI (PBI) security is covered in multiple ways. PBI utilises the same security stack as Azure. It combines information protection and compliance tools of Microsoft 365 with security through multi-layered security measures and end-to-end protection to handle the security challenges of the cloud. In this blog post, we will explore PBI’s security capabilities including semantic model and low-code security as well as best practices for handling these security features.
Firstly, it’s good to start with the data by understanding its sensitivity and varied use cases for end users. As data sources in data solutions include confidential business and personal data as well as publicly available data, it is important to plan the implementation of security by categorising the data based on its confidentiality, availability and restricted properties. Consider questions such as: Who is using the data? Who needs to access the data and in what capacity? Does the data need to be anonymised or pseudonymised?
When planning security strategies, it’s important to identify what access semantic model and report creators need for different data sources. Creating and maintaining a list of all the data sources is valuable.
Row Level Security (RLS)
Row Level Security gives users different views of the same Power BI data based on their role. Applying RLS has become quicker with the enhanced row-level security editor in Power BI Desktop, where you can create RLS filters in a low-code interface without writing DAX. Role’s filter logic is inside the Power BI file in the Static RLS. Static RLS has its use cases in smaller data projects when, for example, access rights are needed for only a few users. To update static RLS, you need to open the PBIX file for every logic change and republish it in the Power BI service. However, static RLS must be heavily maintained when such a filter needs to be added for thousands of roles.
When dealing with many separate roles, it’s advisable to use the Dynamic RLS using the DAX Username() or UserPrincipalName() function. With these DAX functions, you need only to edit the records in the table and the change applies through the tables.
Checklist:
- The functionality of the dynamic RLS depends on the data model; therefore, it’s recommended to keep your model built correctly to apply those filters.
- Use active relationships when defining RLS roles in the data model whenever it’s possible. RLS filters won’t apply to inactive relationships, even if you use USERELATIONSHIP in your measure. However, there is a workaround to this.
- The enhanced row-level security default editor’s Default editor side doesn’t support Username() or UserPrincipalName() functions. Switching to the DAX editor to define the roles using these function filters is advisable. Additionally, using only a DAX editor when defining and editing a complex role is preferable rather than switching between the default editor and the DAX editor. Switching between editors might cause PBI to lose some of the written changes to the filter.
- To enhance the end user’s experience, remember that when applying RLS in the PBI report, use conditionally displayed text when RLS returns no data/count for your rows. In this way, end users with restricted access can see the text of custom messages instead of blanks or errors in metrics or tables.
- It’s important to remember that the RLS filter only restricts data access for users with Viewer permissions in the Power BI service. That means RLS doesn’t apply to Admins, Members, or Contributors. Always test RLS roles and viewer permissions in Power BI service.
Object Level Security (OLS)
Object Level Security can be used to secure specific tables and columns for created roles. As was the case with RLS, OLS is a security feature to prevent unauthorised people from discovering business critical or sensitive personal information. You can implement OLS through Tabular Editor on PBI Desktop.
Checklist:
- If you see an error while viewing a report as a user that is assigned to a combination of distinct roles, check if these roles have RLS and OLS security added to them. Power BI prevents mixing RLS and OLS security for one user via different roles because this could give users access to secured data.
- Do not secure a table if you want to create relationships that reference a secured column in that table.
- Note that semantic models with OLS configured for one or more table or column objects aren’t supported by some Power BI features like Q&A visualisations, Quick insights visualisations, Smart narrative visualisations, and Smart narrative visualisations.
- Unlike RLS, OLS also secures object names and metadata. In that way, it helps to prevent malicious users from discovering the existence of such objects. Moreover, users without permission can’t access secured metadata objects via DAX or any other method.
Power BI gateway security
The purpose of the data gateway is to transfer data between on-premises data and cloud services. You usually need a gateway to refresh data, modify the semantic model in the PBI service, or support DirectQuery connections. It allows multiple users to connect to data sources through a single shared gateway.
Checklist:
- Use on-premises data gateway (standard mode) with multiple users as it supports DirectQuery queries and live connections. It has more options to centralise gateway governance and management.
- Don’t use a personal gateway with the team or enterprise BI solutions.
- If possible, consider uploading local files to SharePoint or OneDrive for Work. You can connect to these files using the SharePoint folder connector, which doesn’t require a gateway.
- Evaluate the necessity of using gateway clusters for business-critical solutions. Gateway clusters provide high availability and load balancing.
- Ensure that the gateway owner is aware of the responsibility of managing, updating and monitoring gateways.
Microsoft Entra ID
Microsoft Entra ID (previously known as Azure Active Directory) is an important part of Power BI’s identity and access management. In terms of Data residency, PBI stores customer data in an Azure geography assigned when a Microsoft Entra tenant signs up for Power BI service for the first time. PBI customer data is stored in the selected Azure geography (aka home geo), except in cases where organisations use multi-geo deployments.
Checklist:
- Use Microsoft Entra ID groups to manage access control and ensure that only authorised users can access specific reports.
- Review and update group memberships regularly.
- Use planned invites to add guest users and assign them security roles before sharing content with row-level security. Avoid ad-hoc invites, as they can delay data protection and cause guests to see broken or blank reports when accessing shared content.
Power BI service security settings
Power BI service is governed by the Microsoft Online Services Terms and the Microsoft Enterprise Privacy Statement. The Microsoft Trust Center is the primary resource for compliance information for PBI. The PBI service follows the Security Development Lifecycle (SDL). The SDL helps developers build more secure software by reducing the number and severity of software vulnerabilities.
In addition, it’s good to know that the new integrated solution in Microsoft Fabric uses some common ways in which PBI implements security e.g. RLS, OLS, Entra ID and Workspace roles. Read more about Fabric’s security features here.
Checklist:
- Carefully evaluate the shared content in the Power BI service with different users.
- Create common guidelines in the team for handling access requests in various scenarios in the PBI service.
- Set limits on using semantic models across workspaces by adjusting tenant settings and using approved groups.
- In terms of sharing items, it is a good practice to follow the principle of least privileges and to manage a collection of items instead of individual items whenever possible.
- Enable audit logs in Power BI to monitor user activity, detect suspicious behaviour, and ensure security compliance.
Power BI and data encryption
PBI uses encrypted storage in Azure Blob Storage and Azure SQL Database depending on the type of data. In the case of direct query, import mode and pushed or streamed data, metadata is encrypted in either Azure Blob Storage or Azure SQL Database. On the other hand, data in PBI is always encrypted in transit using HTTPS to connect from the data source to the PBI service. Cached data in dashboards and report visuals is encrypted and stored in an Azure SQL Database.
Checklist:
- Cross-check that data sources use secure connections when importing data into PBI.
- Discuss secure data handling practices with stakeholders.
Overall, security management in PBI is a multilayered process. As the security landscape changes it is important to stay updated with new PBI features, with new security features and best practices being introduced regularly. Data security management is usually handled by different people in different work roles. For this reason, it is vital to keep an open dialogue with other people with security responsibilities, share your knowledge and plan for changed responsibilities.
For more information on PBI security, please visit the Power BI security white paper. We are here to help you with PBI-related matters, so don’t hesitate to contact us.
