Guardrails are Great… If You Actually Install Them
Data Loss Prevention (DLP) policies are one of the main ways to build safeguards into our Power Platform initiatives. We can use them to control which connectors and actions are allowed in the solutions that the makers build in our tenant, and which are not.
It goes well beyond just allowing or blocking connectors. We can also control specific actions inside those connectors. In some cases, such as for the SQL Server connector for example, we are also allowed to configure the endpoints that those actions can target (oh, how we wish we had that for the HTTP connectors). It also covers custom connectors quite well, and if we enable desktop flow DLPs via the tenant settings in the Power Platform Admin Center, we can also granularly control the actions and endpoints allowed inside our desktop flows. So, it’s all pretty cool and powerful.
But it comes completely unconfigured and open to everything by default. Which makes sense from Microsoft’s point of view – how can they possibly know what an organization might want allowed and what should be blocked. After all, if they see something as generally unsafe and not recommended to use, they would simply not let such a connect pass their screening and it would never be published. So, they allow everything by default and then it’s all on us to configure it the way we want it based on our internal policies.
Which is why Power Platform administrators need to be aware of how DLP policies work, and how to configure them in the right way to keep the data secure while also allowing the makers to experiment, innovate and build solutions that actually make a difference.
The Safest Platform Is the One Nobody Can Use
The easiest way to prevent people from using connectors that could potentially be unsafe is to block them all. However, since there’s more than 1500 of them currently, and the number keeps increasing constantly, it may be quite hard to keep track of them. So, the shortcut some admins may be tempted to take is to simply block everything that’s “blockable”. There are a few official Microsoft connectors that cannot be blocked, such as Microsoft Dataverse, Office 365 Outlook, Microsoft Teams, etc. These can then be split between the so-called “Business” and “Non-business” environments to render some of them useless, because connectors can only be used in the same flow/app/agent if they all are in the same group. Some people, for example, like moving Microsoft Dataverse to non-business, while everything else that cannot be blocked stays in business, rendering Dataverse practically unusable.
So, we could just block everything and only allow people to use the few connectors within the the MS365 ecosystem to build very simple personal productivity solutions, without needing to worry about going deeper into administering the platform.
That’s an option if we don’t want people innovating.
Alternatively, if we have Managed Environments, which means all users using anything in them need to have premium licenses, we could also use the so-called Advanced Connector Policies (ACPs) which don’t have any limitations as to what is “blockable” or not. We could then literally block everything.
That’s an option if we don’t want people using the Power Platform at all.
But do we really want that?
The Subtle Art of Not Blocking Everything
Security Is Not a Binary Choice
In most cases we don’t want either of the extremes. Leaving everything open by default is an obvious security risk. But blocking everything simply makes the whole platform useless, preventing people (and the business) from reaping the benefits it could bring when configured properly.
So, the right approach is somewhere in between the two. The exact sweet spot obviously depends on the business. But there are some general guidelines that almost every organization can follow to an extent and then tweak to their own liking. That’s what we call the “Adaptive” approach. It is essentially a way to configure the policies in a way that has different levels of flexibility, depending on user access, business requirements, solution complexity and criticality, etc. It obviously needs to be combined with an appropriate environment strategy to establish different environments that go from:
- General access – the Wild West where everyone has access (think of the Default environment), to
- Slightly limited access – separate teams, business units (environments for Finance should probably be separate from environments for Marketing), to
- Very limited access – individual business critical projects
There could obviously be more levels in the above, but the general idea is that when we have an environment policy that dictates what data resides where and who has access to it (via Role Based Access Control), we can also apply different DLP policies to those environments. That’s because the more limited the user access, the more open we might be with what connectors we allow.
What this means is a few things, that may seem counter-intuitive at first, but bear with us here.
The Default Environment Is Not Your Innovation Lab
It obviously means we go ballistic about protecting the Default environment. We should absolutely go with the “block everything” approach described above in here. That may seem counter-productive, as it would literally block innovation. But we honestly don’t want innovation to happen in the Default environment anyway. That is because of how difficult it is to govern and oversee what happens there. Every user on the tenant (including guests) has access to the Default environment, and we have no ways to prevent that.
But if we don’t want to completely stop people from using the Power Platform, what we should do is quite simple – block everything blockable (including custom connectors), allow people to use the MS365 connectors in the Default environment, so they can build simple personal productivity solutions.
But to prevent them from thinking the Power Platform is a complete flop, or that the admins are there just to make their lives miserable, we also need to educate them on how to ask for more permissions. And when they do come asking, we give them a separate environment, if it doesn’t already exist (after evaluating the business case, obviously). This environment will have more limited access, meaning we can be more open with what our makers can do there.
More Freedom, Smaller Blast Radius
When we have established environments for specific business units that will host their data and will have limited access, we might allow more connectors. This is not only because of more limited access, but also due to more established ownership. These environments will likely be governed by the Center of Excellence in the organization (if such a group exists). They will be monitored and reviewed periodically. And if they are used by business developers, it is likely that there will also be some user champions involved that will be more advanced and overseeing the entire initiative. Otherwise, it will be maintained and supervised by IT to an extent. As such, more connectors and endpoints may be allowed to pass through the policies here.
Since these environments might also house some more elaborate and potentially more business critical solutions, they might actually be entire environment stacks, rather than individual environments. They could have separate environments for ALM purposes (DEV-TEST-UAT-PROD) for example, that would potentially share the same DLP rules. But the rules would then usually be configured per such environment stack, as separate business units will usually need different connectors and/or different endpoints enabled for them.
This is why we might have DLP policies for the environments that the Finance unit uses, versus those that Operations use.
Maximum Freedom, Maximum Accountability
When we go even deeper in terms of RBAC limitations, we can open up more and more connectors/endpoints. This can happen either to environments for specific business critical solutions, or innovation environments that only experienced developers have access to. Since we will usually know every person in there, and we’ll be confident of both their competencies, as well as their risk management, we can potentially let them test more stuff.
Obviously, if those are innovation sandboxes rather than dedicated environments for business critical solutions, we will still limit the endpoints they have access to – we don’t want experimentation with production data. But we can allow more connectors that we might otherwise consider risky to an extent when in the hands of business users.
When it’s dedicated environments for specific business critical solutions, we will simply tailor the DLP policies to those solutions. We’ll only allow connectors and endpoints that are needed for those solutions and block everything else.
Safety Nets and Hard Stops
Finally, once the DLP policy layers for different access levels are established, there are a few more finishing touches to add. First of all, we want some coverage for new environments. We will usually assume they are at a similar level as the business-unit-specific environments we described earlier – some limited access, but not necessarily guaranteed expertise. This obviously depends on how we configure the tenant settings regarding who can create new environments, as well as how we set those new environments up in general. But regardless of that, we don’t necessarily want to review our DLP policies every single time we create new environments. As such, we need some baseline security in place to control anything potentially risky in every new environment.
As such, we should have a Default Policy that applies to every environment, except those we have already covered with other less restrictive policies. When evaluating DLP policies at runtime, the most restrictive rules have priority. So, we cannot have this Default Policy also covering the innovation and the specific use case environments. We need to exclude them. And the good thing is that we can in fact apply that by controlling the scope of the policy. This way, every new environment created will inherit this policy, unless we explicitly exclude it (after we have added it to some other policy or have created a new dedicated policy for it).
And then on top of that, we can also add an additional blanket policy, that applies to every single environment with no exceptions. It is there to block anything that we absolutely don’t want anywhere, regardless of how limited the access to an environment is. It might just be things that our IT policy renders unsafe. It could be specific endpoints under custom connectors, for example, or services we don’t want our makers using (such as the Google Suite, for example, if our organization uses the M365 ecosystem).
It might be a matter of preference, but in our case we always have a blanket policy that does at least this one thing (might have more in it) – block the “When a HTTP request is received”.
This is because of a very simple reason – there is no way to make it require authentication. Even though it does support authentication, the default security setting on it is “No authentication”, and there is no way to disable that. But at the same time it can be used to execute flows in our tenant after an HTTP request from an external system. We consider this a significant security risk, so we don’t allow anyone use it in any of the tenants that we supervise. And if people do need something along the lines of an HTTP-triggered flow, we usually help them find a better way to do it.
Nurturing Innovation in a Safe Way
Even though most agree that by default, the Power Platform feels a lot like the Wild West – with no rules and everything being allowed – the idea of proper governance is not that of handcuffs and guns to fight the chaos. The fact that no security configurations are established by default may seem daunting. At the same time, all the possible configurations – not only for DLP policies, but also tenant settings, environment strategies and their settings, RBAC, ALM, etc. – make it easy to lose sight of the big picture. It may be tempting to just block everything. But if we do that, we’re literally preventing our people (and the business) from moving forward. It defeats the entire purpose of having the platform in the first place.
An adaptive approach that evolves with the business and its users sits between the two extremes. Instead of asking “Should this connector be allowed or blocked?” it raises a better question: “Where should it be allowed?”
It obviously requires more knowledge, experience and effort in order to both know how to configure it, as well as actually performing the configurations and continuously maintaining it. Especially when new requests come in, new business critical projects pop up, etc. But if we don’t put that extra step in, those business critical projects may never actually happen. It’s the innovation that gives birth to them.
With an approach like that, governance stops being a barrier and becomes an enabler. Makers can experiment where experimentation makes sense. Business units can build solutions within boundaries that protect their data. Critical systems can operate in controlled environments where the rules are explicit and intentional.
And perhaps most importantly, administrators no longer need to choose between security and innovation.
With the right policies in place, they can have both.