Prevent Data Leakage using Data Loss Prevention Policies (DLP)

Microsoft Flow (and PowerApps) are transformational technologies that target a broad audience. Whether you are a pro developer, power user or information worker, Power Platform technologies can improve your productivity.

One of the core capabilities of the Power Platform is the vast number of connectors that are available. There is no way to disable or delete connectors from the platform. As a result, flow makers may be able to wire-up connections from core business applications to consumer-based services that don’t align with organizational standards/policies. For example, an organization may not want a user to connect to a SharePoint List and then share that SharePoint data on Twitter.

By default, no Data Loss Prevention (DLP) policies exist. This means the SharePoint – Twitter scenario that was just mentioned is possible. To prevent this scenario from occurring, we need to establish a Data Loss Prevent (DLP) policy. An Environment Administrator, or Tenant Administrator, can create a DLP policy from the Flow Admin Center.

When creating a DLP policy, the first decision that needs to be made is the scope in which the DLP policy should be applied. A Tenant Administrator can apply a DLP policy to all environments, where as an Environment Administrator can only apply a DLP policy to the environment it owns.

With our environment(s) selected, we can now arrange our connectors into two different data groups:

• Business data only
• No business data allowed

We can think of these data groups as different buckets. Within each bucket, we can drop connectors into it that we want to allow to communicate with each other. However, we cannot have a connector in one bucket (or data group) to talk to another bucket (or data group). For example, if we look at the sample configuration below, the following scenarios exist:

When a user tries to create a flow that violates these DLP rules their flow will be disabled and cannot run until they change their flow to comply with DLP rules. Also note there is a runtime job that runs periodically that will catch any flows that violate DLP rules. This is very helpful in scenarios where someone changes or adds a new DLP rule and you want to apply it to existing flows.

Also note that you can specify a Default data group. What this means is that when new connectors are added to an environment, they will be automatically be placed in the Default data group.

Conclusion

We can use DLP rules to prevent business data from leaving the organization through connectors that have been deemed non-business related. Setup these rules to avoid future surprises.