Data Loss Prevention Polices are the corner stone to protecting your Power Platform environments. They put controls on how data can flow in and out of the environment, protecting you from data leaks. Every Power Platform needs a well planned DLP strategy, it's not just a setup and forget, but requires continuous review.
There are two levels, Tenant and Environment. The Tenant level is the key one, as it supersedes the environment policies. Your Tenant level is you wall and has to be setup correctly, environment level can then trim down permissions on an environment level (but not increase).
I want to talk about how it works, strategy and maintenance. If you already know all about it jump to strategy and maintenance
How it Works
There are 3 main areas to configuring your DLP
- Connectors
- Custom Connectors
- Connector Configuration
1. Connectors
There are over 1000 connectors (and growing) available, the DLP allows you to group these connectors and apply controls on them, there are 3 buckets
Business
These should be any connectors that use your business data
Non Business
Any you want to be able to be used but not directly access your data
Blocked
Connectors you don't want people to use
Business and Non business work by enforcing they only work with connectors in the same bucket. So if SharePoint is in Business and Twitter/X is in Non Business then they cant be in the same flow. And before you think you could call a child flow to get around it, that is covered too.
A call out here is that there are 24 connectors you can't block (All Microsoft)
2. Custom Connectors
For custom connectors the connector is not add to one of the buckets, but the url it uses is.
There are 4 settings for a custom connector url:
- Blocked
- Non Business
- Business
- Ignore
As you can see there is an additional option from the buckets, ignore. This option defers the bucket to the tenant policy (policy covering all environments). If you don't have a policy it will default to both business and non business (it can't be set to specific urls, only all - * ).
The policies are enforced in order, so below will the api.consto.com is above the block all so will be allowed.
3. Connector Configuration
Selected connectors have additional options, the 2 main ones are the HTTP connector (this allows you to configure it like a custom connector).
And the SQL connectors, which have the same url/endpoint controls but also the option to control what actions are allowed (e.g you could set it to read only and block editing)
Strategy
There are 2 main DLP strategies, shared and bespoke. Shared creates a standard policy that covers all environments, so if a connector is approved in one it is approved in all. Bespoke is the opposite, with each environment stack having its own policy. This works if you have business dept stacks, e.g you have finance environments and only that environment can access the finance custom connector.
For ease of maintenance I prefer the shared approach, managing multiple policies wouldn't be too bad if they were static, but with continued new ones it can become a nightmare (Microsoft is introducing DLP groups but its still not perfect). I also don't like using DLP as access control to a api, that should be done at the api level. So I would rather everyone can call the api but only authorized users can use it (if you got lazy and just used the DLP then the api could be vulnerable to postman and other clients).
In my shared structure I have 3 groups
Default (Personal Productivity)
This is the most restricted policy, and covers all new environments unless they are opted out of the policy). I believe the default should only be for personal solutions (as there is no ALM and minimum governance), so that should limit the policy to non blockable connectors (basically Microsoft), everything else blocked. There is one exception, Dataverse, it can not be blocked but I don't want people using for personal solutions. So my workaround is for it to be on its own in the Non Business bucket. This way it can not be used in a flow with any other connector, making it practically unusable.
Standard
This covers all of your standard managed environments, it has additional connectors approved over the Default (as it has ALM and additional controls like intake and security reviews). It is split into 3, with a Dev, Test and Prod version. They are all the same except for the Custom Connector and Connector settings. In dev only dev versions of the api's are allowed, test test versions and prod prod. This way no one can use Test as pseudo prod and you are ensuring developer doesn't accidentally delete production.
Innovation
This is your most open policy and it should be set to just one innovation environment. This has allows any url in custom connectors and connector config. It also has all of the usually blocked connectors set to Non Business, allowing people to test and explore. It's better to see if something is even possible before going through all of the reviews and documentation.
As it's so open I add on additional controls, mainly share limits for Apps (through managed as if any environment should be this one should), and a scheduled flow that turns off all flows on the environment (I also run this against all dev environments to stop pseudo prod).
Additionally you need a strategy for your connectors, there are different ways to approach most connectors, Out the box and Custom. Both have their benefits and it is more of a preference thing (note, this does not cover Microsoft out of the Box connectors, and this is a prefered route, so not to say either is exclusive).
Out of the box
This strategy focuses on connectors that others have already created (there are over 1000 and growing). These connectors are often not built by the api owner, but someone from the community.
Benefits
- No Development time
- No ALM required (already in every environment)
Negatives
- No agreement with developer/owner so don't know exactly what happens to your data
- Not built to your exact requirement (see here to understand more)
Custom
This is the opposite to Out of the box, and requires you to create the connector yourself.
Benefits
- Exactly what you want (api's have many end points that might not be covered)
- You know the end to end data movement, ensuring happy security
- Not reliant on others schedule for updates
Negatives
- Requires development time
- Requires a ALM strategy to move the connector between Dev/Test/Prod
Maintenance
As I said your DLP policy is a continuing process, with new connectors released, version 2 launches and internal development. Having a process is key to keeping everything secure.
I always recommend to set your new connectors to blocked (a setting in the DLP policy).
For any connector to move out of blocked I have 2 options
Solution Requirement
In this case a specific solution requires the connector/url to be approved (nearly all custom connectors take this route). The solution owner ensures the connector goes through security review and passess all nfr's. The connector can not be approved specifically for the solution, its safe for all or none. This approach ensures that the api is fully secure separately from the Power Platform.
Platform Requirement
This could be because of predicted future needs or corporate changes (e.g. changed from one HR system to another so will have impacts on multiple existing solutions). This should be carried out in a DLP review meeting (regular cadence like every quarter), where security, platform engineers and api owners (not connector but the team who own the api in your organization). I normally recommend 2 different approaches for approving standard connectors. If the connector is owned by the api owner e.g Service Now own the the Service Now connector, then its just a case of checking your contract covers everything. If its an independent then I would explore the documentation uploaded by the publisher here.
Without a secure foundation every platform is destined to fail, so your DLP strategy should be the first thing on your rollout plan.
Top comments (1)
Wonderful content!!!