Secure deployments
One key element of administering a Power Platform deployment is to consider security. Security is crucial to ensuring that everyone has access to only the data they need, and also ensuring that business data isn't accessed by people or applications that shouldn't.
Establishing a DLP strategy
One of the first things that you should consider when deploying a Power Platform solution is to establish a Data loss prevention (DLP) policy. DLP policies act as guardrails to help prevent users from unintentionally exposing organizational data and protect information security in the tenant. DLP policies control whether a connector is enabled in each environment and which connectors can be used together. Connectors are classified as either business data only, no business data allowed, or blocked. A connector in the business data only group can only be used in an app or flow with other connectors from the business data group. For example, you might want to create an application that uses the Microsoft Dataverse connecter and a third-party connector. If you classify the Microsoft Dataverse connector as a business data connector, you'll only be able to use the third-party connector in the same app if it's also classified as a business data connector.
Establishing your DLP policies go hand-in-hand with your environment strategy.
Connector classification
Business and non-business classifications create boundaries around connectors and define which connectors can be used together in a given app or flow. Connectors can be classified into the following groups using DLP policies:
Business: A Power App or Power Automate flow can use one or more connectors from a business group. If a Power App or Power Automate flow uses a business connector, it can't use any non-business connector.
Non-business: A Power App or Power Automate flow can use one or more connectors from a non-business group. If a Power App or Power Automate flow uses a non-business connector, it can't use any business connector.
Blocked: No Power App or Power Automate flow can use a blocked connector. All Microsoft-owned premium connectors and third-party connectors (standard and premium) can be blocked. Microsoft-owned standard connectors and Common Data Service connectors can't be blocked, though.
Strategies for creating DLP policies
As discussed previously, as an administrator taking over an environment or starting to support use of Power Apps and Power Automate, DLP policies should be one of the first things you set up. This ensures a base set of policies is in place. You can then focus on handling exceptions and creating targeted DLP policies that implement approved exceptions.
We recommend the following starting point for DLP policies for shared user and team productivity environments:
Create a DLP spanning all environments except selected ones (for example, your production environments). By this DLP, limit the available connectors to Office 365 and other standard microservices, and block access to all other connectors. Apply this DLP to the default training environments, and any new environments that are created.
Create more permissive DLP policies, appropriate for your organization, for your shared user and team productivity environments. These DLPs could allow makers to use connectors like Azure services in addition to the Office 365 services. The connectors available in these environments depend on your organization and where it stores business data.
We recommend the following starting point for DLP policies for production (business unit and project) environments:
Exclude these environments from your shared user and team productivity DLP policies.
Work with business units to establish which connectors and connector combinations they use, and create a tenant policy to include only the selected environments.
Environment admins can use environment DLP policies to categorize custom connectors as business-data, only where necessary.
In addition, we also recommend:
Creating a minimal number of DLP policies per environment. There's no strict hierarchy between tenant and environment policies. At design and runtime, all of the DLP policies for an app or flow's environment are evaluated together to determine whether the app or flow is in compliance with DLP policies. Multiple DLP policies applied to one environment will fragment your connector space in complicated ways and might make it difficult to understand issues your makers are facing.
Using tenant level DLP policies for central management wherever possible; using environment policies only to categorize custom connectors or by exception.
With this in place, decide how you'll handle exceptions. You can:
Deny the request.
Add the connector to the default DLP policy.
Add the environment to the All Except list of the global default DLP, and create a use-case-specific DLP policy with the exception included.
Example: Contoso's DLP strategy
Let’s look at how Contoso Corporation, a sample organization, set up their DLP policies. Contoso's DLP policy setup ties in closely with their environment strategy. Contoso admins want to support user and team productivity scenarios and business applications and manage Center of Excellence (CoE) activity.
Contoso's environment and DLP strategy consists of the following to create a tiered approach:
A tenant-wide restrictive DLP policy that applies to all environments in the tenant, except some specific environments that they've excluded. This policy also applies to the default environment. Contoso admins limit the available connectors in this policy to Office 365 and other standard micro-services; they block access to all other connectors.
Contoso admins have created a shared environment where users can create apps for user and team productivity use cases. This environment has an associated tenant-level DLP policy that isn't as restrictive as the default policy; it allows makers to use connectors like Azure services, in addition to the Office 365 services. Because this is a non-default environment, admins can actively control who has access to the environment.
In addition, for the business units to create line-of-business applications, they have created development, test, and production environments for their tax and audit subsidiaries across various countries. The environment maker access to these environments is carefully managed, and appropriate first-and third-party connectors are made available using tenant-level DLP policies in consultation with the business unit stakeholders.
Similarly, dev/test/production environments are created for Central IT to develop and roll out applications. These business application scenarios typically have a well-defined set of connectors that need to be made available for makers, testers, and users in these environments. Access to these connectors is managed using a dedicated tenant-level policy.
Contoso also has a special purpose environment dedicated to their CoE activities. The DLP policy for this environment remains high-touch due to the experimental nature of the theory team's work. Tenant admins have delegated DLP management for this environment directly to a trusted environment admin from the CoE team, excluding it from all tenant-level policies. This environment is managed solely by the environment-level DLP policy, which is an exception rather than the rule at Contoso.
As expected, any new environments that are created in Contoso maps to the original all-environments policy.
This setup of tenant-centric DLP policies doesn't prevent environment admins from coming up with their own environment-level DLP policies, if they want to introduce other restrictions or classify custom connectors.
You can learn more about creating DLP policies here: Plan and manage your Microsoft Power Platform environment.