Ways to secure access in Power BI

Power BI Admin portal

When it comes to protecting or getting access to certain artifacts, workspaces, reports, and datasets, the first line of defense within the Power BI environment is the Power BI Admin portal. The portal settings help with limiting sharing, auditing usage, and managing data security across an entire tenant. These settings, combined with security groups in Office 365, are critical elements in helping manage and control access across the organization at a high level, so it’s a good idea to look at these first when planning out your Power BI program.

Workspaces and roles

In Power BI, a workspace is where people collaborate, create, and use dashboards, reports, and datasets. Access to workspaces is controlled by a role-based security boundary. The most typical roles in a workspace are:

• Admin: Can update/delete the workspace, and add/remove people, including other admins
• Member: Can add members with lower permissions, manage dataset permission
• Contributor: Can create, edit, delete, copy, and publish reports
• Viewer: Can view and interact with an item and read stored data

Source: Microsoft

Note that these roles are typically assigned to operations staff and developers, not the end users of the reports. For end users, there is an alternative access mechanism: apps.

Think of an app as a mechanism to bundle together a set of reports, dashboards, and data, and then provide access to them for a group of end users. There is only one app per workspace. When a user logs into Power BI they can see the apps from different workspaces that they have access to, and from there they can access the different reports they want to view.

From a security protections perspective, in this way, multiple users can access or view a number of reports without needing to give them physical access to the source workspace.

Source: Microsoft

One of the advantages of Power BI is that paginated reports on a report server can be brought into Power BI under the same pane of glass, residing side-by-side with the rest of your reports. This allows users to edit reports in the Power BI workspace or on report servers, all of which can be hosted in the same service. Another layer of protection that is provided is at the dataset level, where you can control who refreshes reports and who can’t. You can also control who can access the dataset or not. For example, on a particular dataset, you can identify the specific users who are allowed access.

Processing entities

Inherent in the Power BI infrastructure are built-in controls as data flows from one processing entity to the next. Let’s look at how that works:

Source: Microsoft

Power BI datasets

The “dataset” is the key entity in Power BI. It contains:

• The data model
• The definition of the data source connectors
• The transformation code to modify/combine the data read from the data sources to populate the data model
• The code for all measures used in reports

The dataset will typically have a refresh schedule that will cause data to be read from the data sources on a regular cadence (although there are also other options where the data is not cached but instead read “live” from the sources as needed).

Dataset-level permissions can be added based on who can edit, modify, or refresh data. For example, users in the finance or marketing departments can have access to the data they need but are excluded from modifying the underlying data model which serves as a single point of truth.

Power BI dataflows

A “dataflow” allows transformation code to be compartmentalized and can run on a separate refresh schedule to the dataset. This allows data transformation processing to be offloaded from the dataset. In larger environments, a single dataflow can act as an input to multiple datasets. For example, if a report needs data from a SQL DB and an Excel sheet on a SharePoint server, you could build two dataflows – one to read/transform SQL data and one to read/transform Excel data – and then have a dataset read those two sets of data and combine them together. From an organizational perspective, different dev teams could own specific dataflows and take ownership of that code, along with maintenance and access to the underlying source.

By decoupling the user base from the source systems to the Power BI tenant, you can decrease system usage and provide report builders with faster and more organized access to datasets. In this way, setting the right controls helps improve self-service BI and increase efficiencies across the entire organization.

Power BI reports

Reports “live connect” to a Power BI dataset. While a report provides graphical visualizations, the code/data is coming from the underlying dataset. This means that many different reports can use the same dataset without needing to provide access to the business logic itself, allowing for consistent data and increased efficiency.

The reporting artifact itself has many sharing rules and permissions you can add for sharing internally between departments or sharing externally with vendors, etc. Sharing features should ideally be planned out ahead of time. By default, Power BI leaves admin settings open, so it’s important to carefully go through decisions at each stage to ensure critical assets like corporate IP are protected.

Power BI pipelines

For DevOps, one tool that is often used is Power BI pipelines. Once you have established a dataset and a set of reports (and possibly a set of dataflows) in a workspace and the development process is complete, a Power BI pipeline can be used to propagate/copy all those entities to a test workspace and then a production workspace. Similarly, if a change is introduced into a report in, for example, the development workspace, that change can be efficiently moved to the test & production workspaces. Permissions are required for report developers to push reports through a dev UAT and production environment. This feature requires a “Premium” workspace as does the SSRS report migration functionality.

While this is not a comprehensive assessment of all the opportunities to establish access and control parameters in Power BI, it does touch on some of the main areas you should be familiar with. We hope you’ve found the information to be useful.

If your team needs assistance reviewing and assessing how your Power BI infrastructure can be set up to provide the security, access, and permissions your organization needs to get the most from everything Power BI offers, get in touch. We’re here to help. A Power BI health check for Power BI and Power BI Premium environments is a great starting point.