Power BI and enterprise data security

This issue's Microsoft MVP Lab researcher Davis Zhang, Microsoft MVP, MCSE, one of the official document contributors, focuses on the Power Platform and Power BI global technology stack. The following section will share with you some core technical points (BYOK, OLS and DLP) related to data protection in Power BI.

Preface

Data is not only an enterprise's asset, but also its lifeblood, and its importance is self-evident. With more and more enterprises adopting Power BI as one of their business intelligence solutions, users have stricter requirements on the security and compliance of data in Microsoft BI system. Due to the length of the article, from the perspective of PBI and M365 administrators, the following will excerpt the core data security issues in the Power BI platform, that is, "data storage, data presentation and data export" for graphic explanations.

PBI data security data storage

When a Power BI dataset is published to PBI Service, its data is actually stored in Azure Blob Storage. By default, data encryption is managed by Microsoft, while the value of the key, the rotation rules, and the encryption method are not controlled by the enterprise or organization. control. Although Microsoft uses a strong enough 256-bit AES encryption algorithm, this argument may not help in the face of some companies' stringent information security policies and rigorous scrutiny by compliance departments. Implementing BYOK (Bring your own Key) in Power BI is the only solution in order to keep the organization in control of the keys and to comply with their policies on data encryption and rotation rules.

Implement BYOK in PBI

Notice:

• BYOK is currently only available for PBI Premium (including Capacity and Per User)
• BYOK mainly supports Import datasets with relational database bit data sources

1. Log in to Azure to create a Key Vault, and assign Unwrap Key and Wrap Key permissions

2. Add the Power BI workspace administrator account and Power BI Service service principal you want to use for BYOK in Access Policy

3. Next, create a key with the following configuration

4. Now, apply the key created in the previous step to the PBI capacity, there is currently no interface for setting, you need to type the command in PowerShell

--安装 Cmdlets（已装跳过）
Install-Module -Name MicrosoftPowerBIMgmt
--登录
Connect-PowerBIServiceAccount 
--在整个PBI租户中启用BYOK
Add-PowerBIEncryptionKey -Name '<输入Key名称>' -KeyVaultKeyUri '<输入Key URI>'
--注：其中 Key URI可在 Azure Key Vault 中查询复制
--获取容量 ID
Get-PowerBICapacity -Scope Individual
--最后，为该容量设置 BYOK
Set-PowerBICapacityEncryptionKey -CapacityId <输入容量ID> -KeyName '<输入Key名称>'

At this point, BYOK is set up, enter the following command to verify:

Get-PowerBIEncryptionKey

The configuration is successful as shown in the figure:

It should be noted that the current implementation of BYOK is at the entire capacity level, not the Workspace level. Once BYOK is set for a capacity, all workspaces under that capacity inherit the capacity's BYOK setting.

5. For key rotation, you can use the following commands. To achieve regular rotation, you can configure it to an existing application, or directly use the "Rotation Policy" preview function in Azure Key Vault

Switch-PowerBIEncryptionKey -Name '<输入Key名称>' -KeyVaultKeyUri '<输入新的Key URI>'

It should be noted here that both the new key and the current key must be enabled, otherwise the following error will be encountered. After ensuring that the keys are enabled, the problem is solved, as shown in the figure:

PBI data security data presentation

The security of the data presentation stage, as the name suggests, refers to how to give different users or different groups different access rights to the data based on different custom roles when users access PBI reports, although we can determine whether a user is a certain user in the workspace Grants the Viewer role, but does not control what data the user can and cannot see.

Fortunately, in the Power BI import model, Microsoft provides two data security settings, RLS and OLS, the former is row-level security familiar to PBI users, which can use DAX to define filtering rules for different fields in different tables based on roles , you can also dynamically define visitor permissions in combination with USERPRINCIPALNAME() (due to a lot of data, it will not be expanded here); while the latter OLS (Object Level Security) is the security set for the field itself, which can control different fields (including fields) based on roles Name) is visible to a specific user, we can understand it as "column-level security".

▌ Implement OLS in PBI

Like RLS, OLS also needs to create roles in PBID first, but the security control of specific table or field visibility needs to be done in external tool tabular editor . To hide fields from a specified role, just use this tool to connect to the model, select the table or field to be set, and set the value of the corresponding role in OLS to None, as shown in the figure:

Here are some points to note about OLS:

1. If a table or field hidden from a role is used in a front-end report, all visualizations associated with it will not be available when the role views the report.
2. Although OLS cannot be implemented for a specific measure, if the field referenced by the measure contains hidden fields, the measure remains invisible to the specified role.

The simple example shown in the figure below is a good illustration of the above two points. Since the OLS value of the field "OrderQty" for the role "User" is set to None, the visualization on the left is completely unavailable, and the table on the right does not use this field, nor does it use any measure that references it, so it shows Not affected.

Due to the limitation of the underlying technology, the current PBID cannot hide specific fields or values without affecting the display of other fields or values in the same visualization. Therefore, the application value of OLS is mainly reflected in the user self-service analysis.

PBI data security data

By specifying roles in the workspace to cooperate with RLS and OLS, we have achieved permission control over the content of PBI data, but what we cannot control is how to continuously protect the data after the data is exported from Power BI, and how to perform operations on the PBI data. Monitoring so that administrators can be alerted in a timely manner whenever sensitive data is detected.

The solution to this situation is to implement DLP (Data Lose Prevention) for Power BI. It consists of the following two stages:

1. Microsoft 365 administrators can create and define sensitivity labels for Power BI. Different sensitivity labels can be set with different permission definitions. Administrators of PBI workspaces can set different data sets, data flows and reports according to the situation. Corresponding sensitivity labels so that sensitive data can be protected even after leaving Power BI. To quote the MS documentation:

When labeled data leaves Power BI, either via export toExcel, PowerPoint, PDF, or .pbix files, or via other supported export scenariossuch as Analyze in Excel or live connection PivotTables in Excel, Power BIautomatically applies the label to the exported file and protects it accordingto the label’s file encryption settings. This way your sensitive data canremain protected, even when it leaves Power BI.

2. Microsoft 365 admins can create DLP policies for Power BI that can monitor sensitive data based on sensitivity labels for PBI content (this feature is in preview).

Note: Implementing DLP requires a Microsoft 365 E5 subscription

▌ Implement DLP in PBI

◇ Create and publish sensitivity labels

1. Create a label in the M365 Compliance Center as shown below.

Note: If the Information protection tab is not visible, you need to check your account permissions and M365 Lisence

2. Select Files & emails

3. This step is to determine the permission settings after the sensitivity label is applied. You can add users, security groups and even domains, and assign them different roles.

The following figure clarifies the permissions of different roles, and you can also customize the permissions of roles by checking specific items.

4. After the label is created, publish the label:

Note: Sub-labels can be created from existing sensitivity labels. Sub-labels can further define permissions on the basis of inheriting the parent's permission scope, which is useful for large organizations.

This can be checked during the publishing labeling process, which will force Power BI developers to apply sensitivity labels to datasets and reports before publishing them, as shown in the section "PBI Sensitivity Label Enforcement Validation" below:

Back in Power BI Service, the published tags are already available:

Notice:

1. After the sensitivity label is published, it is usually not displayed in each application immediately. As shown in Figure 1 below, "It can take up to 24 hours...", so if you don't see the posted label in PBI, it doesn't necessarily mean that your setup was unsuccessful, just wait patiently.

2. Power BI admin needs to enable sensitivity labels in tenant settings (see Figure 2)

                                    （图1）

                                    （图2）

◇ Verification

1. PBI sensitivity labels enforce validation

The following users must apply sensitivity labels to PBIX before they can publish reports.

2. Data export protection effect verification

As shown in the figure, I have specified sensitivity labels for datasets, reports, and paginated reports, where HIGH SENSITIVE Only specific users can view the exported data.

        【示例1-1】Power BI 报表导出验证（使用有权限的账户）

        【示例1-2】Power BI 报表导出验证（使用无权限的账户）

        【示例2】Power BI 分页报表（Paginated Report）导出验证

◇ Create DLP strategy

The DLP strategy is still a preview function in Power BI, and some features are not supported for the time being. If the public beta is in April this year, then the GA may have to be pushed back again. The following only explains the strategy creation part.

1. In the M365 Compliance Center, start with Custom Policy and create:

2. Select Power BI and DLP is applied to the entire capacity by default. If you only want DLP to be applied to individual workspaces, you can enter the corresponding Workspace ID:

3. Create DLP policy alert triggering rules that can be enforced only on PBI content marked with a specific sensitivity label:

4. Administrators can monitor data here:

In addition to the above, there are many technical points related to Power BI security, such as gateway security, private link integration, Azure Log Analytics integration, etc. It is enough to write a book to explain these contents one by one. There is very little research, some pits, some bugs, even if you search Google, it is difficult to find a solution, so you still have to rely on the reader's patient exploration, and get the support of Microsoft technical staff when necessary.

for Power BI Security White Paper