As uncle Ben once said, ‘with great power comes great responsibility.’
The Power Platform’s flexibility and scalability have brought in never seen challenges for IT Admins to address. 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.
About the Author: Irfan Rizvi
Irfan is an experienced Microsoft certified Technology Consultant and Solutions Architect. He has more than 20 years of industry experience and has worked with a variety of Microsoft solutions. His current focus is on the Microsoft Power Platform, and loves to keep himself updated with the tech industry.
