Sensitivity Labeling for Power BI and data assets for Australian Government compliance with PSPF
This article provides guidance for Australian Government organizations on the extension of Microsoft Purview sensitivity labeling capabilities into data sources. Its purpose is to demonstrate how these capabilities can strengthen an organizations approach to data security by labeling information in source systems. Advice in this article is intended to strenthen approaches to classification and protection of information outlined in the Protective Security Policy Framework (PSPF).
There are two Microsoft Purview capabilities that extend sensitivity labeling into and associated protections into the data and analytics space:
Schematized Data Assets or Data Map capabilities allow us to identify sensitive information while it resides in Database systems and apply labels to data in place.
Power BI integration allows for the labeling of Power BI assets, including dashboards, reports, datasets, dataflows, paginated reports, and Power BI (.pbix) files. Labels can be maintained on all exported Excel or PDF files and label-based Azure Rights Management encryption can be applied to exported items.
The intent of these capabilities is to better support the protection of information throughout its lifecycle. For example:
Note
These features are currently in preview and must be enabled by opting into the preview via the prompt available from the Information Protection > Labels menu.
Schematized data assets
Schematized Data Asset labeling, allows for labels to be automatically applied to data, such as that residing in database columns. The intent of this service is to enable the identification of sensitive information in source systems and to use this identification to help protect the information throughout its lifecycle and use within any connected systems. Labeling information at its source can also help to simplify information management in downstream systems by alleviating the need to utilize tools like Exact Data Match to identify content post-export.
Schematized data assets options can be enabled for a label via scope options within a label's configuration.
Following enablement of the schematized data assets scope option, Sensitive Information Types (as discussed in identifying sensitive information) are selected that align with the label being configured. This process is similar to recommending labels based on sensitive content detection.
Following label configuration, data assets need to be registered. Sensitivity Labels are supported for the following data sources:
- SQL server
- Azure SQL database
- Azure SQL Managed Instance
- Azure Synapse Analytics workspaces
- Azure Cosmos DB for NoSQL
- Azure Database for MySQL
- Azure Database for PostgreSQL
- Azure Data Explorer
The service requires time to scan the data source for defined sensitive information. The Microsoft Purview catalog, which is available from within the Azure portal can be used to view labeled sensitive information.
For further information on schematized data assets and labeling via Microsoft Purview Data Map, see labeling in the Microsoft Purview Data Map.
Power BI Integration
The ability for a sensitivity label to be available for application to Power BI content is tied to the label 'file' scope.
To make use of Power BI label integration, the Information Protection options will first need to be enabled from with the Power BI admin portal under the organization's settings.
The following options are available within the Power BI Information Protection admin settings:
| Setting | Purpose |
|---|---|
| Allow users to apply sensitivity labels for content | Enables MPIP Power BI integration and needs to be enabled to allow the labeling of Power BI items. |
| Apply sensitivity labels from data sources to their data in Power BI | This option allows for labels to be inherited from those applied to source information, such as Azure Synapse Analytics and Azure SQL Databases. This capability relies on the Schematized Data Assets features, which were discussed in the previous section. |
| Automatically apply sensitivity labels to downstream content | This option allows for labels to be inherited on items generated from Power BI data assets. For example, a label applied to a dataset flows through to reports and dashboards making use of the content. Labels inherited don't overwrite manually applied labels, and is viewed as complimentary to ISM-0271, ensuring a minimum level of protection for downstream items. |
| Allow workspace admins to override automatically applied sensitivity labels | This option allows for workspace admins to override labels, which are automatically labeled via the previous setting. This option is available in addition to the administrator's ability to change labels in order to override Azure Rights Management based controls that might lock administrators or users out of items. |
| Restrict content with protected labels from being shared via link with everyone in your organization | This option customizes sharing settings to restrict the creation people in your organization sharing links, reducing potential data exposure. |
Once Power BI Information Protection options are configured and labels have had time to replicate through to the Power BI service, labels are available for application to Power BI resources. For example:
As discussed during sensitivity label policies, label policies can be configured to enforce mandatory labeling for all Power BI content.
Enabling this option in addition to the Power BI downstream content setting, can help to ensure that sensitive information generated or viewed via Power BI is protected in line with the organizations DLP policies, including those recommended under preventing inappropriate distribution of security classified information.
These settings extend an organization's ability to meet PSPF Policy 8 Core Requirement 1. This is because they allow for classifications, markings, and associated controls to be extended to Power BI locations.
| Requirement | Detail |
|---|---|
| PSPF Policy 8, Requirement 1 (Core Requirement) - Identifying information holdings (v2018.6) | The originator must determine whether information being generated is official information (intended for use as an official record) and whether that information is sensitive or security classified. |
The Power BI downstream content settings will automatically apply a label based on the sensitivity of the source information. This isn't normally used in Government settings as it isn't following PSPF Policy 8 Core requirement 2. The reason is that the label is applied to content without a user needing to assess the information's sensitivity.
| Requirement | Detail |
|---|---|
| PSPF Policy 8 Requirement 2 (Core Requirement) - Assess the sensitivity and security classification of information holdings (v2018.6) | To decide which security classification to apply, the originator must: i. Assess the value, importance, or sensitivity of official information by considering the potential damage to government, the national interest, organizations, or individuals, that would arise if the information's confidentiality was compromised (refer to the following table), and ii. Set the security classification at the lowest reasonable level. |
There may be exceptional circumstances that require this function (for example a Machinery of Government (MoG) where bulk data is moved from a taskforce into a department), so is included here for this purpose.
For more information on enablement of Power BI integration, prerequisites, see Enable sensitivity labels in Power BI.