Data platforms are used in many places and Power BI is one solution to generate visual reports from different sources refined in Data platform.
In this post I will cover some of the security solutions for Power BI but first we have to see what is Power BI.
Table of Contents
What is inside Power BI?
Power BI consists of several elements that all work together, starting with these three basics:
- A Windows desktop application called Power BI Desktop.
- An online SaaS (Software as a Service) service called the Power BI service.
- Power BI mobile apps for Windows, iOS, and Android devices.
|License type||Capabilities when workspace is in shared capacity||Additional capabilities when workspace is in Premium capacity|
|Power BI (free)||Access to content in My Workspace||Consume content shared with them|
|Power BI Pro||Publish content to other workspaces, share dashboards, subscribe to dashboards and reports, share with users who have a Pro license||Distribute content to users who have free licenses|
|Power BI Premium Per User||Publish content to other workspaces, share dashboards, subscribe to dashboards and reports, share with users who have a Premium Per User license||Distribute content to users who have free and Pro licenses|
Differences between Free and Pro
|License type||Not in Premium capacity||Premium capacity|
|Free||Use as a personal sandbox where you create content for yourself and interact with that content. A free license is a great way to try out the Power BI service. You can’t consume content from anyone else or share your content with others 1||Interact with content assigned to Premium capacity and shared with you. Free, Premium per-user, and Pro users can collaborate without requiring the free users to have Pro accounts.|
|Pro||Collaborate with Premium per-user and Pro users by creating and sharing content.||Collaborate with free, Premium per user, and Pro users by creating and sharing content.|
Free End-user features
Power BI feature list for business users and others with free licenses
The Power BI Pro designer can share and collaborate with other Pro users in either of the workspaces. But, the only way the Power BI Pro user can share and collaborate with free users is by using Workspace B, which is in a Premium capacity. Within the workspace, the designer assigns roles to collaborators. Your role determines what actions you can take within the workspace. Power BI business users are usually assigned the Viewer role.
Types of workspaces
My Workspace stores all the content that you own and create. Think of it as your personal sandbox or work area for your own content. For many Power BI business users, My workspace remains empty because your job doesn’t involve creating new content. Business users, by definition, consume data created by others and use that data to make business decisions. If you find that you are creating content, consider reading the Power BI articles for designers instead.
Workspaces contain all the content for a specific app. When a designer creates an app, they bundle together all the content that is necessary for that app to be utilized. Content may include dashboards, reports, and datasets. Not every app will contain these three pieces of content. An app may contain only one dashboard, or three of each content type, or even twenty reports. It all depends on what the designer includes in the app. Commonly, app workspaces shared with business users don’t include the datasets.
Permissions in the workspaces
Access permissions determine what you can do in a workspace, so teams can collaborate. When granting access to a new workspace, designers add individuals or groups to one of the workspace roles: Viewer, Member, Contributor, or Admin.
As a Power BI business user, you’ll typically interact in workspaces using the Viewer role. But a designer could also assign you to the Member or Contributor role. The Viewer role lets you view and interact with content (dashboards, reports, apps) created by others and shared with you. And because the Viewer role can’t access the underlying dataset, it’s a safe way to interact with content and not have to worry that you’ll “hurt” the underlying data.
|Update and delete the workspace.|
|Add/remove people, including other admins.|
|Allow Contributors to update the app for the workspace|
|Add members or others with lower permissions.|
|Publish, unpublish, and change permissions for an app|
|Update an app.||If allowed 1|
|Share an item or share an app.2|
|Allow others to reshare items.2|
|Feature apps on colleagues’ Home|
|Manage dataset permissions.3|
|Feature dashboards and reports on colleagues’ Home|
|Create, edit, and delete content, such as reports, in the workspace.|
|Publish reports to the workspace, delete content.|
|Create a report in another workspace based on a dataset in this workspace.3|
|Copy a report.3|
|Create goals based on a dataset in the workspace.3|
|Schedule data refreshes via the on-premises gateway.4|
|Modify gateway connection settings.4|
|View and interact with an item.5|
|Read data stored in workspace dataflows|
1 Contributors can update the app associated with the workspace, if the workspace Admin delegates this permission to them. However, they can’t publish a new app or change who has permission to it.
2 Contributors and Viewers can also share items in a workspace if they have Reshare permissions.
3 To copy a report to another workspace, and to create a report in another workspace based on a dataset in this workspace, you need Build permission for the dataset. For datasets in the original workspace, if you have at least the Contributor role you automatically have Build permission through your workspace role. See Copy reports from other workspaces for details.
4 Keep in mind that you also need permissions on the gateway. Those permissions are managed elsewhere, independent of workspace roles and permissions. See Manage an on-premises gateway for details.
5 Even if you don’t have a Power BI Pro license, you can view and interact with items in the Power BI service if the items are in a workspace in a Premium capacity.
How to provision Power BI?
Open admin portal from https://app.powerbi.com/admin-portal
Give your info and provision your own workspace, easy as that.
From the main page you can try out Premium feature for free
Not going to go any deeper to Power BI, I will leave it to Power BI experts but the security aspect is interesting. So let’s see what you can do to make it more secure.
Then to the protection parts
A workload identity is an identity used by a software workload (such as an application, service, script, or container) to authenticate and access other services and resources. The terminology is inconsistent across the industry, but generally a workload identity is something you need for your software entity to authenticate with some system.
Service principal is an authentication method that can be used to let an Azure AD application access Power BI service content and APIs.
When you create an Azure Active Directory (Azure AD) app, a service principal object is created. The service principal object, also known simply as service principal, allows Azure AD to authenticate your app. Once authenticated, the app can access Azure AD tenant resources.
Create an Azure AD app.
- Create the Azure AD app’s secret.
- Get the app’s Application ID and Application secret.
- Create an Azure AD security group.
- Enable the Power BI service admin settings.
- Add the service principal to your workspace.
- Embed your content.
Certificate-based authentication enables you to be authenticated by Azure Active Directory (Azure AD) with a client certificate. The client certificate can be on a Windows, Android or iOS device, or kept in an Azure Key Vault.
- Embed your content with service principal.
- Create a certificate.
- Set up certificate authentication.
- Get the certificate from Azure Key Vault.
- Authenticate using service principal and a certificate.
Data at rest
Power BI uses two primary data storage resource types:
- Azure Storage
- Azure SQL Databases
In the majority of scenarios, Azure Storage is utilized to persist the data of Power BI artifacts, while Azure SQL Databases are used to persist artifact metadata.
Data in transit
Power BI requires all incoming HTTP traffic to be encrypted using TLS 1.2 or above. Any requests attempting to use the service with TLS 1.1 or lower will be rejected.
Customer Managed Keys
In Power BI Premium you can also use your own keys for data at-rest that is imported into a dataset (see Data source and storage considerations for more information). This approach is often described as bring your own key (BYOK).
Data source and storage considerations
To use BYOK, you must upload data to the Power BI service from a Power BI Desktop (PBIX) file. You cannot use BYOK in the following scenarios:
- Analysis Services Live Connection
- Excel workbooks (unless data is first imported into Power BI Desktop)
- Push datasets
- Streaming datasets
- Power BI goals do not currently support bring your own key (BYOK).
BYOK applies only to datasets. Push datasets, Excel files, and CSV files that users can upload to the service are not encrypted using your own key. To identify which artifacts are stored in your workspaces, use the following PowerShell command:
Get-PowerBIWorkspace -Scope Organization -Include All
Enable BYOK on your tenant
You enable BYOK at the tenant level with PowerShell, by first introducing to your Power BI tenant the encryption keys you created and stored in Azure Key Vault. You then assign these encryption keys per Premium capacity for encrypting content in the capacity.
The process simplied:
- You will configure Azure Key Vault
- You will use Unwrap and Wrap permissions on the Key vault
- RSA key has to be 4096 bits, not less.
- Enable Key vault to be accessed only from Power BI endpoints with allowing trusted Microsoft services to bypass this firewall.
- Enable BYOK with PowerShell and
Add-PowerBIEncryptionKeycommand as a Tenant wide setting
Vnet Data gateway (Preview)
- Currently, this feature is available only for Power BI datasets and Power Platform dataflows.
- This feature is currently not supported in sovereign clouds.
- Due to an AAD limitation you might see failures when the following settings are enabled together:
- Service Endpoint for AAD is enabled on the delegated VNet
- Conditional Access Policies are enabled for the tenantTo overcome this AAD limitation, you can try the following workaround:
- If you have VNet traffic blocked by a Conditional Access policy, check your Azure AD sign-in log. Once you’ve identified the traffic, you can get the IPv6 address being used and exclude it from your policy. More information: Location condition in Azure Active Directory conditional access
- You can’t change the region, subscription, or resource group for the VNet on which the VNet data gateway was created. This scenario isn’t currently supported.
- Power BI datasets:
- A list of supported data services for Power BI datasets is available in Supported Azure data services.
- Power Platform dataflows:
- For Power Platform dataflows, this feature currently doesn’t support the ability to write to a privatized data lake or Dataverse.
- A list of supported data sources for Power Platform dataflows is available in Supported data sources.
- VNet data gateways are created in your tenant’s home region by default and there’s currently no option to change the VNet data gateway region. Based on this limitation, VNet data gateways can only be used in Power platform environments in the home region of your tenant.
- VNet data gateways currently support only admin roles and not “Can Use and Can Use+Share” for Power Platform dataflows.
- Power BI paginated reports:
- VNet gateways support paginated reports.
- A list of supported data sources for Power Platform dataflows is available in Supported data sources for Power BI paginated reports.
How to enable
Basically the process is that You do the following:
- Register Power Platform as a Resource provider
- Associate the subnet to Microsoft Power Platform
- Create a Virtual Network Data gateway
Row and Object Level Security
When used with single sign-on, Row Level Security (RLS) and/or object-level security (OLS) can be implemented on the data source. This allows users to view only data they have privileges to access.
If the data source is Azure Analysis Services or on-premises Analysis Services, and RLS and/or OLS is configured, the Power BI service will apply that row level security, and users who do not have sufficient credentials to access the underlying data (which could be a query used in a dashboard, report, or other data artifact) will not see data they don’t have sufficient privileges for.
Apply sensitivity labels in the Power BI service
In the Power BI service, you can apply sensitivity labels to reports, dashboards, datasets, and dataflows.
To be able to apply sensitivity labels in the Power BI service:
- You must have a Power BI Pro or Premium Per User (PPU) license and edit permissions on the content you wish to label.
- Sensitivity labels must be enabled for your organization. Contact your Power BI admin if you aren’t sure about this.
- You must belong to a security group that has permissions to apply sensitivity labels, as described in Enable sensitivity labels in Power BI.
- All licensing and other requirements must have been met.
When sensitivity labels are enabled
- Specified users and security groups in the organization can classify and apply sensitivity labels to their Power BI content. In the Power BI service, this means their reports, dashboards, datasets, and dataflows. In Power BI Desktop, it means their .pbix files.
- In the service, all members of the organization will be able to see those labels. In Desktop, only members of the organization who have the labels published to them will be able to see the labels.
An Azure Information Protection Premium P1 or Premium P2 license is required to apply or view Microsoft Information Protection sensitivity labels in Power BI.
- To be able to apply labels to Power BI content and files, a user must have a Power BI Pro or Premium Per User (PPU) license in addition to one of the Azure Information Protection licenses mentioned above.
- Office apps have their own licensing requirements for viewing and applying sensitivity labels.
- Before enabling sensitivity labels on your tenant, make sure that sensitivity labels have been defined and published for relevant users and groups.
- Customers in China must enable rights management for the tenant and add the Microsoft Information Protection Sync Service service principle.
- Using sensitivity labels in Desktop requires the Desktop December 2020 release and later. If you try to open a protected .pbix file with a Desktop version earlier than December 2020, it will fail, and you will be prompted to upgrade your Desktop version.
How to apply?
From the main page open Admin portal
And under Tenant settings and Information protection
Under Allow users to apply sensitivity labels for Power BI content you will find the settings
DLP policies for Power BI (preview)
Considerations and limitations
- DLP policies for Power BI are defined in the Microsoft 365 compliance portal.
- DLP policies apply to workspaces. Only workspaces hosted in Premium Gen2 capacities are supported.
- DLP dataset evaluation workloads impact capacity. Metering for DLP evaluation workloads is not yet supported.
- Both classic and new experience workspaces are supported, provided that they are hosted in Premium Gen2 capacities.
- DLP policy templates are not yet supported for Power BI DLP policies. When creating a DLP policy for Power BI, choose the “custom policy” option.
- Power BI DLP policy rules currently support sensitivity labels and sensitive info types as conditions.
- DLP policies for Power BI are not supported for sample datasets, streaming datasets, or datasets that connect to their data source via DirectQuery or live connection.
- DLP policies for Power BI are not supported in sovereign clouds.
Licensing and permissions
Before you get started with DLP for Power BI, you should confirm your Microsoft 365 subscription. The admin account that sets up the DLP rules must be assigned one of the following licenses:
- Microsoft 365 E5
- Microsoft 365 E5 Compliance
- Microsoft 365 E5 Information Protection & Governance
Data from DLP for Power BI can be viewed in Activity explorer. There are four roles that grant permission to activity explorer; the account you use for accessing the data must be a member of any one of them.
- Global administrator
- Compliance administrator
- Security administrator
- Compliance data administrator
How to enable?
Open https://compliance.microsoft.com/datalossprevention?viewid=policies to start creating your own policy.
Create the policy of your liking and choose the workspaces to protect
For the selection you need Workspace ID (Microsoft, please let us browse)
You can find the Power BI object ID for any workspace from
- The Admin portal > workspaces
- The URL of a selected workspace
- PowerShell > Get-PowerBIWorkspace
Audit logs to M365 Admin center
Audit logs are enabled by default, so you can see the normal users and admins activities directly from Audit logs.
But you can also export them directly to Log analytics instance.
Go to tenant settings to Enable
Using service tags with Power BI
The following configurations are necessary to successfully enable the endpoints for use in the Power BI service:
- Enable a public endpoint in the SQL Managed Instance
- Create a Network Security Group rule to allow inbound traffic
- Enter the credentials in Power BI
Enable a public endpoint
The first part of the process is to enable a Public Endpoint in the SQL Managed Instance.
Microsoft has nice PowerShell scripts to accomplish the setup, so I will show the GUI side
And Microsoft instructions
Private endpoints for accessing Power BI
Or make it super secret by closing all internet connections
From tenant settings open Advanced networking and Enable Azure Private Link. When this is enabled You can disable the Public Internet access. Just remember that this is a settings for the whole tenant.
More from Microsoft
Power BI overview
Last but not least, an excellent one-pager from all the services around Power BI
End of the line
And these are just some examples on how to protect your Power BI, there is still a lot more but more on those later.