Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
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. Guidance in this article is intended to strengthen 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:
Microsoft Purview data governance 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:
Azure data governance
Azure data governance 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.
To apply a label to assets in Azure, the file and other data assets scope option needs to be selected within a label's configuration. This will typically be enabled for all sensitivity labels.
Once enabled, 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 more information on labeling via Azure data governance, see Data governance with Microsoft Purview.
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 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 Purview 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 replicated 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 Data Loss Prevention (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 2024 - 09. Classifications & Caveats - Requirement 59 | The value, importance, or sensitivity of official information (intended for use as an official record) is assessed by the originator by considering the potential damage to the government, the national interest, organizations, or individuals that would arise if the information’s confidentiality were compromised. |
For more information on enablement of Power BI integration, prerequisites, see Enable sensitivity labels in Power BI.