DLP Policies, Policy Layering, and Granular configurations

As uncle Ben once said,


with great powers comes great responsibility

The power platform's flexibility and scalability have brought in never seen challenges for IT Admins. to address that Microsoft has provided us with a whole host of tools and technologies to establish guardrails against security vulnerabilities within Power Platform. Data Loss Prevention (DLP) Policies is one of those key safeguards that allows IT Admins to define policies that reduce the risk of organizational data intentionally or unintentionally being exposed within or outside the organization.


One of the key components of Power Platform is its ever-growing list of connectors that lets app makers connect the applications and flows to applications, data sources, and APIs, Custom Connectors even extends that to custom APIs or systems for which there is no predefined APIs available. Connectors are quite a fundamental component in the success of Power Platform, DLP Policies classify the connectors by their use and puts them in one of 3 buckets

  1. Business

  2. Non-Business

  3. Blocked

The concept behind this is that the connectors in the Business bucket cannot be used in the same flow or app with the connectors in the Non-Business bucket, and Blocked ones as the name suggests are not allowed to be used at all


DLP policies can be defined at the tenant level or to a specific environment(s). This means that in a single environment multiple policies could be applicable, this introduces a concept of policy layering


Policy Layering


Policy Layering is the distribution of connectors into logical groups when multiple policies are applied to an environment, lets take the following example of an environment where two policies are applied, for the sake of argument we are just showing a small set of connectors here out of all the connectors available.


In Policy 1,


Business Connectors: DataVerse, SharePoint Teams, SQL, and Outlook

Non-Business Connectors: FTP, SalesForce, Jira, Azure DevOps, and Approvals

Blocked Connectors: Twitter, Google Drive, Gmail


and in Policy 2,


Business Connectors: DataVerse, SharePoint Teams, Azure DevOps, and Outlook, and Approvals

Non-Business Connectors: SQL, SalesForce, Jira

Blocked Connectors: FTP and RSS


The above policies will result in the following logical grouping,


Group 1: DataVerse, SharePoint, Teams and Outlook, This is because in both policies all these connectors were in the Business Connectors group

Group 2: Azure DevOps and Approvals, This is because in both policies they were part of the same group, it doesn't matter if in one it was Business and the other it was Non-Business

Group 3: SalesForce and Jira, This is because in both policies they were part of Non-Business Connectors

Group 4: SQL, This is because SQL has not been commonly grouped with any other connector in both policies

Blocked Connectors: Any connector which is part of the blocked group in any policy will end up being blocked


What this logical grouping means is that the connector in each group can only be used with other connectors in that group in any App or flow


Granular Configurations


Microsoft announced in 2021 Wave 1 that they are extending the DLP capabilities and it will now allow more granular configuration of Connectors, what that means is that instead of restricting the whole connector, you can restrict certain actions within that connector, or for some connectors also allow the ability to define end-point filtering, e.g. you can allow HTTP connector but only to be connected to certain know URLs


Currently, these features are in public preview and only available for certain connectors. To Configure it, You have to edit your DLP policy and go to the list of connectors in the Business or Non-Business Tab

  1. Select a connector, e.g. HTTP, Azure Ad, or SQL

  2. In the toolbar, click Configure Connector and click on Configure Actions

  3. Toggle action(s) to No

  4. Click Save


Now if I try to use this action in an app or flow, I will be prompted and I won't be allowed to save the flow, in case of existing flows those will go in a suspended state.


What does this mean in the context of policy layering?


It means that an action has to be allowed in all the policies that are applicable on that environment, if action is restricted in any of the policies, it will be restricted for the environment, it acts similar to how blocked connectors behave


I will be doing more posts on this topic in the future where we will cover recommendations on what are the best practices in setting up these policies and how you can have more oversight of what has been applied in your tenancy as an IT Admin, so stay tuned.