Secure deployments
One key element of administrating a Power Platform deployment is to consider security. Security is crucial to ensuring that everyone has access to only the data that they need, but also to ensure that data business isn't accessed by people or applications that shouldn't access it.
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) strategy. DLP policies act as guardrails designed to help prevent users from unintentionally exposing organizational data and to protect information security in the tenant. DLP policies enforce rules for which connectors are enabled for 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 with other connectors from that group in the same app or flow. For example, someone might want to create an application that applies 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 apply the third-party connector if it's also classified as a business data connector.
Establishing your DLP policies will go hand in hand with your environment strategy.
Connector classification
Business and non-business classifications draw boundaries around what connectors can be used together in a given app or flow. Connectors can be classified across the following groups using DLP policies:
Business: A given Power App or Power Automate resource can use one or more connectors from a business group. If a Power App or Power Automate resource uses a business connector, it can't use any non-business connector.
Non-business: A given Power App or Power Automate resource can use one or more connectors from a non-business group. If a Power App or Power Automate resource uses a non-business connector, it can't use any business connector.
Blocked: No Power App or Power Automate resource can use a connector from a blocked group. All Microsoft-owned premium connectors and third-party connectors (standard and premium) can be blocked. All Microsoft-owned standard connectors and Common Data Service connectors can't be blocked.
Strategies for creating DLP policies
As mentioned 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, and you can then focus on handling exceptions and creating targeted DLP policies that implement these exceptions once approved.
We recommend the following starting point for DLP policies for shared user and team productivity environments:
Create a policy spanning all environments except selected ones (for example, your production environments), keep the available connectors in this policy limited to Office 365 and other standard microservices, and block access to everything else. This policy will apply to the default environment, and to training environments you have for running internal training events. Additionally, this policy will also apply to any new environments that will be created.
Create appropriate and more permissive DLP policies for your shared user and team productivity environments. These policies could allow makers to use connectors like Azure services in addition to the Office 365 services. The connectors available in these environments will depend on your organization, and where your organization stores business data.
We recommend the following starting point for DLP policies for production (business unit and project) environments:
Exclude those environments from shared user and team productivity policies.
Work with the business unit and project to establish which connectors and connector combinations they'll use and create a tenant policy to include the selected environments only.
Environment admins of those environments can use environment policies to categorize custom connectors as business-data only, if necessary.
In addition to the above, we also recommend:
Creating a minimal number of policies per environment. There's no strict hierarchy between tenant and environment policies, and at design and runtime, all policies that are applicable to the environment in which the app or flow resides are evaluated together to decide whether the resource is in compliance or violation of 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.
Centrally managing DLP Policies using tenant level policies, and using environment policies only to categorize custom connectors or in exception cases.
With this in place, plan how to handle exceptions. You can:
Deny the request.
Add the connector to the default DLP policy.
Add the environments to the All Except list for 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, our sample organization for this guidance, set up their DLP policies. The setup of their DLP policies ties in closely with their environment strategy. Contoso admins want to support user and team productivity scenarios and business applications, in addition to Center of Excellence (CoE) activity management.
The environment and DLP strategy Contoso admins have applied here consists of:
A tenant-wide restrictive DLP policy that applies to all environments in the tenant except some specific environments that they've excluded from the policy scope. Admins intend to keep the available connectors in this policy limited to Office 365 and other standard micro-services by blocking access to everything else. This policy will also apply to the default environment.
Contoso admins have created another shared environment for users to create apps for user and team productivity use cases. This environment has an associated tenant-level DLP policy that isn't as risk-averse as a default policy and 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 the environment maker list for it. This is a tiered approach to shared user and team productivity environment and associated DLP settings.
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's use to develop and roll out relevant or right 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 Center of Excellence activities. In Contoso, the DLP policy for the special purpose environment will remain high touch given the experimental nature of the theory teams book. In this case, tenant admins have delegated DLP management for this environment directly to a trusted environment admin of the CoE team and excluded it from a school of all tenant-level policies. This environment is managed only 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 will map 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 to classify custom connectors.
You can learn more about creating DLP policies here: Plan and manage your Microsoft Power Platform environment.