One of the great features of the Power Platform is the ability to connect to hundreds of different data sources through Connectors. Connectors are great for easily bringing multiple sources of data together under a single app or automated process. They also provide the ability to transfer data from one source to another. Users simply log into their service of choice and the data they have access to from that connector is available to their app or flow.
CAUTION...
The ease in which users can connect to different data sources and share data opens up potential risks for data to be shared outside of your organisation that go against company policy. Users generally have good intentions, but they can easily overlook the potential of exposing data to services and audiences that shouldn't have access to the data. For example, an employee (who forgets, or has never read, the organisation's IT policies) uses Power Automate to automatically copy documents from SharePoint to Google Docs or Dropbox which violates the organisation's IT policy. Or a malicious employee who has access to Dynamics 365 could create a Power App to send sensitive Dynamics 365 data out as a tweet via the Twitter connector.
As a CIO, IT Manager or Power Platform administrator, you do not want to take on this risk. You want to be able to manage who can use what connectors and prevent the risk of data loss. This is what Data Loss Prevention (DLP) policies are for.
This article outlines a recommended Power Platform DLP strategy to help you make decisions about how to apply DLP policies as the use of the Power Platform in your organisation expands over time.
What are Power Platform DLP Policies?
DLP policies are guard rails that wrap around Power Platform environments and determine which combinations of data sources can be used by Power Apps and Power Automate flows within an environment.
DLP policies are configured by categorising Power Platform connectors into three different groups:
Business - Power Apps or Power Automate flows can use any number of business connectors as long as there are no non-business connectors also being used by the app or flow.
Non-Business - Power Apps or Power Automate flows can use any number of non-business connectors as long as there are no business connectors also being used by the app or flow.
Blocked - Power Apps or Power Automate flows cannot use a blocked connector.
Policies are then applied to one or more environments based on a policy scope.
Let's explain with an example. In the diagram below, three environments (A, B & C) all have a DLP policy applied which has connectors categorised into each of the three connector groups. In this example...
A user can create an app that uses the Dataverse and SharePoint connectors together as they are both business connectors.
They can also create an app that uses the Google Drive and Google Calendar connectors together, as the company has deemed them to be OK for personal productivity use and categorised the connectors as non-business.
They will not be able to create an app that uses both SharePoint and Google Drive as these connectors are not in the same group.
They will not be able to create an app that uses the Twitter connector as it is blocked.
How do DLP Policies work?
If a user tries to build a Power App or Power Automate flow that violates a DLP policy they will be shown an error message about the violation and will not be able to save the app or flow.
For apps or flows that have been created prior to DLP policies being applied, apps will no longer work and flows will become suspended. This is extremely important to consider when applying DLP policies to an environment that has existing apps and flows.
To understand more about the details of DLPs, how they work and how to technically apply them I often refer to the following:
DLP Policy Alternative Uses
The primary purpose of DLP policies is to prevent data from being unintentionally exposed. However, they can also be used to enforce good practices and compliance with company policies for building apps and flows. Here are a few examples of real world scenarios where DLP policies could have prevented a compliance violation from occurring...
Apps created in the Default environment (which should be treated like a play pen) that connect to production Dynamics 365 data. It is generally not a good idea to have a production type app in the Default environment!
Apps created with a SQL connection to an on-premises database where the company's policy is to not use SQL or on premises data sources.
Apps, created and used by unlicensed users in the Default environment, that are connected to the environment's Dataverse database (requires a premium Power Apps license).
A DLP Strategy
A DLP strategy defines how we choose to configure DLP policies under the conditions of ever changing technologies (e.g. connectors) and business needs, in order to make the Power Platform a safe place for your organisation's data. In the following sections I outline an a recommended DLP strategy based on what we have learnt working with our clients.
DLP strategy is very tightly connected to Power Platform environment strategy. How you configure your environments affects how DLPs are applied and vice versa. To illustrate this example, lets say we have an organisation that has the following environments, grouped by criticality.
Lay a Foundation
The first step is to set up a foundation set of DLP policies. Using the example above foundational DLP policies are approached as follows...
Default Environment DLP policy
A restrictive policy that is applied to the Default environment only. The Default environment is essentially a play pen that all users have access to and should have strong guard rails. People will make mistakes in this environment. Typically this policy allows all Office 365 connectors and other standard business services that users across the organisation have access to, and blocks everything else. It is recommended that the Dataverse connector is blocked in this policy to ensure 'production' type apps are not created in the Default environment.
Tenant Default DLP policy
A tenant wide policy that is applied to all environments (including new ones) except for specific excluded environments that require the use of additional connectors. This is done by setting the DLP policy scope to Exclude certain environments. This policy has the same connector group configuration the Default environment policy except that it allows the Dataverse connector so that Teams environments can operate properly.
Dynamics 365 DLP policy
A policy specifically for Dynamics 365 environments. This policy is the same as the Tenant Default policy but allows Dynamics 365 connectors (e.g. Dynamics 365 Customer Insights, Fin & Ops Apps) and any other services required by the Dynamics 365 solution.
CoE DLP policy
A policy specifically for the CoE environment which has the Microsoft Centre of Excellence Starter Kit installed. The CoE apps need access to administrative connectors such as Power Platform for Admins which other environments typically should not. A list of required connectors for the CoE Starter Kit can be found here Set up the CoE Starter Kit - Power Platform | Microsoft Docs.
Let's take a look at how these policies are applied across our example organisation...
In our example organisation, the four foundation policies cover just about every environment, except for the Finance BU Prod environment. This environment is used by the Finance team which requires connectors that are blocked by the four foundation policies. In this scenario an environment specific policy is created just for the Finance BU Prod environment to allow them to connect to approved additional connectors required by the Finance team.
Accommodate Power Platform changes
Strategy is about being able to accommodate change in order to reach your objectives. Over time, your Power Platform will change. As your organisation adopts the Power Platform and more teams and employees start using it there will be increased requests for new environments and the use of new connectors. This could be due to a new project, people or business units wanting to leverage the Power Platform to digitise their processes.
Self Service Environments
Assuming that production environment creation is limited to administrators and all other environment creation settings are left as default, users can create their own trial, developer or Dataverse for Teams environments. When one of these environments are created they will be automatically added to the Tenant Default DLP policy ensuring that the data is protected in this environment from the get go.
IT Managed Environments
New production environments are created by IT administrators and will also be automatically added to the Tenant Default DLP policy. However, it is likely that these environments will require a less restrictive DLP policy. The administrator can exclude the production environment from the Tenant Default policy and add it to an environment specific policy if required.
New Connectors
When someone wants to build an app or flow that connects to a service that is currently not allowed by DLP policies then the Power Platform governance team need to assess the following:
Should the connector's service be used for business purposes?
What environment will the app or flow be built in and what other data sources / services could the new service be shared with?
Who else is creating Power Platform components in the environment?
Based on this assessment the governance team need to decide whether to create a new environment with an environment specific policy or update and existing policy for an existing environment.
Implementing DLP Policies
Now that you have an understanding of DLP strategy you will want to execute the strategy and implement DLP policies across your Power Platform tenant. However, proceed with caution as DLP policies implemented incorrectly can have a negative impact of existing apps and flows - stopping them from working. How to implement DLP policies without impact is the topic of my next blog where I will share a step by step process and tools we use. Subscribe to our blog to stay up to date.
One thing I struggle with when working with the M365 eco system, is how we are advised not to use the Default environment for production workloads but some services use it by default. For example, I'm working on a Project for the Web implementation at the moment, and by default this is set up in the Default environment. Yes, we can implement it into other environments but the user experience is better when deployed in the Default environment, because if you deploy to another environment users have no choice but to access the project via the Project PowerApp. This is especially so in companies that do not use Dynamics and therefore its users are not familiar with model driven ap…