Roles and license required for DLP
I'm not going to talk about Environments or Data Integration in this article – I will elaborate about those topics on separate articles.
It's important to understand that, without Plan 2, you can't configure an Environment DLP. If you are a Global Admin and don't have Plan 2, the only DLPs you can configure are tenant-level policies, that apply to all environments:
If you need more control and granularity when creating DLPs, then you will need a Plan 2 license. Normally you need enviroment-level DLPs when you use a production environment, and a development environment.
Your development environment should not be governed by any DLP and only a limited number of users should have access to this environment so that they can freely test integrations between various target services.
In the screenshot below I've configured a DLP that will govern all Environments except the Development environment:
It's worth mentioning that normal users with Plan 2, that are not Global Administrators, can also create Data Loss Prevention policies, but only on the Environments that they created or on Environments where they were mapped to the Environment Admin role.
This is because the Plan 2 license will give access to the Admin Center and let the user create Environments and manage DLP policies that the user created. Plan 2 will not give permissions over DLPs that the user did not create or Environments that the user can't manage.
Data Groups give you the ability to segregate connectors into separate containers: Business Data Only and No Business Data Allowed
I've added a few connectors in the Business Data Only group and left the rest in the No Business Data Allowed group. Note that DLPs don't have the ability to distinguish between business data and non-business data on their own without user intervention, so it's up to you to decide which connectors fall in these categories and how data should flow between the target services these connectors connect to.
As an example, in my case, SharePoint is a connector that I will use for business data, while Dropbox will be used for non-business data. So I don't want my data to flow from SharePoint to Dropbox and vice-versa.
Segregating the connectors in the two groups will ensure that users will not be able to build applications or flows that combine connectors from different data groups.
As an example, users who will try to build flows or applications that use SharePoint and SQL Server will not be able to do so. However, they will be able to build flows or applications that use a combination of connectors from the same data group (e.g. SharePoint and Office 365 Users sitting in the Business Data Only group or SQL Server and Dynamics 365 connectors sitting in the No Business Data Allowed group).
Once you save the DLP, it will take a few minutes until it takes effect. Note that a DLP should have a retroactive effect on your applications and flows. I named this policy All Environments EXCEPT Development.
The Default group
You probably noticed that one data group is marked as Default.
The Default data group is where the new connectors fall when they are released and that is where the custom connectors and HTTP connectors and actions fall by default.
I am not going to elaborate about custom connectors or HTTP connectors and actions on this article, but what you need to know is that the Flow team recently added support for custom connectors and HTTP connectors and actions . To learn more about including and managing custom connectors or HTTP connectors and actions in a DLP, please read this article.
Attempting to add both SharePoint and SQL Server data sources in the same application will fail with this error:
Using these connections together conflicts with the company data loss prevention policies.
Attempting to add both SharePoint and SQL Server actions in the same flow will result in this error:
Your flow was created, but it is currently suspended since it uses a combination of connectors that conflict with the company data loss prevention policies or billing restrictions.
Blocking or disabling connectors is not possible. There is no option in PowerApps or Flow that would let you block or disable a particular connector.
You can, however, isolate a connector in its own DLP and thus block the data flow between the connector you've isolated and the rest of the connectors.
I created a policy below where I placed the SQL Server connector in the Business Data Only group. Both this policy and the other one I created above are complementary – this policy will take priority when it comes to integrating the SQL Server connector with other connectors in apps or flows. I named this policy Isolate SQL Server.
This policy will prevent users from creating apps and flows that use a combination of SQL Server and other connectors, however it will not stop users from creating flows or apps that use only the SQL Server connector (e.g. get rows from a table and insert into another table).
Note that, in the All Environments EXCEPT Development DLP, the SQL Server and Dropbox connectors sit in the same data group, but the
Isolate SQL Server will no longer allow that combination because it will supersede the rule set by the All Environments EXCEPT Development DLP governing the SQL Server connector. Attempting to add both SQL Server and Dropbox actions in the same flow will result in this error:
Finally, this is how my DLPs look like: