How can I decide which protection method to use to protect my sensitive data in Fabric?
When should I use Purview DLP restrict access vs. Purview Protection Policies?
We’re often asked by customers regarding our recommendation on how to protect sensitive data in Fabric. In this blog post, I’ll briefly share the different protection options that currently exist in Fabric and compare them so that you can decide which one best fits your needs.
First, a bit of background, in Fabric, the basic level of access is controlled in the workspace level roles. On top of that, you can also define permissions for a specific item. Without having a Viewer role in the workspace or Read permissions to a certain item – users will not be able to access a report, for example. On a sub-item level, for some Fabric items, such as warehouses and semantic models, you can also control access at the column or at the row level. This means that the fundamental management of access happens on a daily basis through users managing their item permissions and workspace roles.
Last year, we introduced two capabilities that are effectively a layer on top of the workspace roles and item permissions. We’re answering a need that arises from organizations to have a centralized place to define and control access at the organization level. This takes effect when users may have been granted access to certain items, but then there is a wider-organization decision that if an item contains sensitive information or specific sensitivity labels, that access needs to be revoked:
Protection Policies – these policies are built on top of the Purview sensitivity labels. Microsoft Purview Information Protection labels with protection policies means that a compliance admin can define who can access a labeled item, ensuring that users without explicit access will be blocked out of Fabric items given the presence of a sensitivity label. For example, only my leadership team can access data labeled with the ‘Highly Confidential’ label.
Purview Data Loss Prevention policies with restrict access action allow you to define that based on the sensitive information found within your semantic model or on its sensitivity label – users will be restricted. Compliance admins can decide if they want to block access for guest users only, or to block all users in the tenant (except for the data owners who can remove the sensitive info and unblock the semantic model).
Below is a table demonstrating the differences between these two capabilities:
| Protection Policies | DLP Restrict Access Action | |
| Effective Action | Restrict users from accessing an item labeled with a sensitivity label that has a protection policy enabled. | Restrict users from accessing the data of an item that was scanned by a DLP policy and had sensitive data detected. |
| Restriction options | Users (including applications) who aren’t specified explicitly or within a user group in the policy of the label. | All users, or all guest users. Data owners will always maintain access. |
| Where do I define it | Purview portal -> Protection Policies | Purview portal -> DLP policies for Fabric |
| How can I identify it is applied on my item | Item’s Manage permissions page -> message appears at the top to reflect a label is protecting the item. | Red indication on affected semantic models and their downstream reports with hover card for more details. |
| Supported items | All native Fabric item types and Power BI semantic models. Other Power BI item types aren’t yet supported. | Semantic models (Coming soon: Fabric lakeshouses) |
Conclusion
As is often the case, the answer is – it depends on your use case.
DLP policies allow you to block users based on the content of your data and are reevaluated with every data change. This makes it possible to enforce access in situations where you may not have been aware sensitive data existed and is updated along with your data to keep it current.
Protection Policies can be more vastly deployed across your tenant as they are reliant on sensitivity labels, which have multiple assignment flows, allowing for wide usage and integration with your users’ day-to-day flows, including when data is exported to Office.
Example – how to use these two capabilities together:
- Enforce access to all the users outside the Finance user group, by applying a Protection Policy on the “Confidential/Finance” label, for instance. Then define that label as a default label in the Finance domain, which means it will be applied by default to all the newly created items in all the workspaces associated with that domain, ensuring unauthorized users do not have access to them. You can then define a DLP rule that looks for financial data in your semantic models when the “Confidential/Finance” label is not applied. In such case, DLP will restrict access to all users until this is resolved, meaning until the correct label is applied to the semantic model or until the sensitive data is removed from the model. Using these capabilities to complement each other allows you to get the best of both worlds, and most importantly, to ensure your data stays safe!
We hope this helps to shed some light on the possibilities you have to protect your Fabric data. We’re always happy to hear feedback.
