One of the key security tools for Power Platform admins is the Data Loss Prevention Policies, (soon to be called Connector Controls, going to take a while to get use to that 😎 ). I have gone into more detail about it here , but in a nut shell it allows you to control what connectors and urls work.
There are 3 levels to DLP policies, tenant, environment and connector. The connector level is only for selected connectors and targets urls, but it is also enforced at the environment level, so its only really 2 levels, tenant and environment.
So as you can see, there can be an over arching tenant DLP, but in my experience there is little value in the tenant level DLP. DLP updates require global admins, even at the environment level. That means only (well should be) a small team of people can create/update DLP policies, so you would expect them to not need a central DLP (also what is the point, as whoever can edit a environment DLP can edit the tenant DLP).
This means DLP is really all about environments, with the logic being different environments can have different policies. These policies stop certain connectors working in the same flow and certain teams from using certain connectors. But here's the problem, its limited to the Power Platform, let me explain.
The Problem
The issue is that if DLP was a house, it would have a fence with its neighbour, but could simply walk onto the road to get around the fence.
Above you see 3 different business areas, each with their own DLP set around the systems we use. The key thing we want to control is the flow of data/information, as an example, we don't want SQL connector used to provide data for Twitter/Facebook. The setup means that no one flow can get data from an internal system and pass it to an external system.
But as I said, the problem is its limited to the platform, so it means we can easily bypass the controls by simply stepping out and back in to the platform, and hoping between the environments/DLP policies we want.
The easy one to use is SharePoint, because (even with new ability to block it, you need managed environments and SharePoint is generally so ubiquitous it's hard to block it). In our example we have a SQL connector in the Finance environment that saves data as csv to a SharePoint library. Then we have a SharePoint triggered flow in the Media environment that loads the csv and shares it publicly.
Thoughts
I understand that everything has limits, and the Power Platforms sphere of influence/control will always be limited, but I think the issue is the false sense of security.
Having environment level DLP policy encourages a disjointed security approach, making admins think at the micro level, not the macro. The simple truth is the platform needs to be treated as a whole, managed and governed that way, the more you delegate the higher the risk.
What You should do
Because the connections can even transverse users (flow in Finance doesn't have to be owned by same maker as Media) DLP policies need to be considered as one. Having separate DLP policies lowers the risk, it doesn't remove, so that has to be calculated when looking at the risk impact.
I would recommend using a tenant wide DLP policy for all connectors, and then having environment level just to control url's (custom connectors and connector level). That makes everything simpler to control, reduces false sense of security, but maintains dev/test/prod environment to system links.
Though I would definitely still keep a limited DLP for the Default and Dataverse for Teams (anywhere were makers can access production). This means the other thing to ensure is proper separation of duty, your makers should not have edit access to production whenever possible (use Service accounts), and your developer environments must be controlled (reporting & control flows).
I would also have for ones related to the platform, like Copilot Studio and Desktop connectors, as I want them in designated environments just for governance.
If you would like to get notified every new blog (I also do a few in the Power Platform Community), subscribe below
Subscribe to David Wyatts Blogs
powerdevbox.com
Top comments (1)
Thanks for explaining the potential vulnerability and how we could go around the system to get the data.
My understanding is that the new features ( not sure if its only for Managed environment) allows you to apply DLP at environment group level. Like the concept of rationalising the DLP and making default only for personal productivity