Secure the default environment
Every employee in your organization has access to the default Power Platform environment. As a Power Platform admin, you need to consider ways to secure that environment while keeping it accessible for makers' personal productivity uses. This article provides suggestions.
Assign administrator roles judiciously
Consider whether your admin users need to have the Power Platform administrator role. Would the environment admin or system administrator role be more appropriate? In any case, limit the more powerful Power Platform admin role to just a few users. Learn more about administering Power Platform environments.
Communicate intent
One of the key challenges for the Power Platform Center of Excellence (CoE) team is to communicate the intended uses of the default environment. Here are some recommendations.
Rename the default environment
The default environment is created with the name TenantName (default). You can change the environment name to something more descriptive, like Personal Productivity Environment, to clearly call out the intent.
Use the Power Platform hub
The Microsoft Power Platform hub is a SharePoint communication site template. It provides a starting point for a central source of information for makers about your organization's use of Power Platform. Starter content and page templates make it easy to offer makers information like:
- Personal productivity use cases
- How to build apps and flows
- Where to build apps and flows
- How to reach out to the CoE support team
- Rules around integrating with external services
Add links to any other internal resources your makers might find helpful.
Limit sharing with everyone
Makers can share their apps with other individual users and security groups. By default, sharing with your entire organization, or Everyone, is disabled. Consider using a gated process around widely used apps to enforce policies and requirements like these:
- Security review policy
- Business review policy
- Application Lifecycle Management (ALM) requirements
- User experience and branding requirements
The Share with Everyone feature is disabled by default in Power Platform. We recommend you keep this setting disabled to limit the overexposure of canvas apps with unintended users. The Everyone group for your organization contains all users who have ever logged into your tenant, which includes guests and internal members. It's not just all internal employees within your tenant. Additionally, the membership of the Everyone group can't be edited nor viewed. To learn more about the Everyone group, go to /windows-server/identity/ad-ds/manage/understand-special-identities-groups#everyone.
If you would like to share with all internal employees or a large group of people, consider sharing with an existing security group of those members or creating a security group and sharing your app with that security group.
When Share with Everyone is disabled, only a small group of administrators can share an application with everyone in the environment. If you're an administrator, you can run the following PowerShell command if you need to enable sharing with Everyone.
First, open PowerShell as an administrator and log into your Power Apps account by running this command.
Add-PowerAppsAccountRun the Get-TenantSettings cmdlet to get the list of your organization's tenant settings as an object.
The
powerPlatform.PowerAppsobject includes three flags:
Run the following PowerShell commands to get the settings object and set the variable disableShareWithEveryone to $false.
$settings=Get-TenantSettings $settings.powerPlatform.powerApps.disableShareWithEveryone=$falseRun the
Set-TenantSettingscmdlet with the settings object to allow makers to share their apps with everyone in the tenant.Set-TenantSettings $settingsTo disable sharing with Everyone, follow the same steps but set
$settings.powerPlatform.powerApps.disableShareWithEveryone = $true.
Establish a data loss prevention policy
Another way to secure the default environment is to create a data loss prevention (DLP) policy for it. Having a DLP policy in place is especially critical for the default environment because all employees in your organization have access to it. Here are some recommendations to help you enforce the policy.
Customize the DLP governance message
Customize the error message that's displayed if a maker creates an app that violates your organization's DLP policy. Direct the maker to your organization's Power Platform Hub and provide your CoE team's email address.
As the CoE team refines the DLP policy over time, you might inadvertently break some apps. Make sure the DLP policy violation message contains contact details or a link to more information to provide a way forward for makers.
Use the following PowerShell cmdlets to customize the governance policy message:
| Command | Description |
|---|---|
| Set-PowerAppDlpErrorSettings | Set governance message |
| Set-PowerAppDlpErrorSettings | Update governance message |
Block new connectors in the default environment
By default, all new connectors are placed in the Nonbusiness group of your DLP policy. You can always change the default group to either Business or Blocked. For a DLP policy that is applied to the default environment, we recommend that you configure the Blocked group as the default to make sure that new connectors remain unusable until they have been reviewed by one of your administrators.
Limit makers to prebuilt connectors
Restrict makers to only basic, nonblockable connectors to prevent access to the rest.
Move all the connectors that can't be blocked to the business data group.
Move all the connectors that can be blocked to the blocked data group.
Limit custom connectors
Custom connectors integrate an app or flow with a home-grown service. These services are intended for technical users like developers. It's a good idea to reduce the footprint of APIs built by your organization that can be invoked from apps or flows in the default environment. To prevent makers from creating and using custom connectors for APIs in the default environment, create a rule to block all URL patterns.
To allow makers to access some APIs (for example, a service that returns a list of company holidays), configure multiple rules that classify different URL patterns into the business and nonbusiness data groups. Make sure that connections always use the HTTPS protocol. Learn more about DLP policy for custom connectors.
Secure integration with Exchange
The Office 365 Outlook connector is one of the standard connectors that can't be blocked. It allows makers to send, delete, and reply to email messages in the mailboxes they have access to. The risk with this connector is also one of its most powerful capabilities—the ability to send an email. For instance, a maker might create a flow that sends an email blast.
Your organization's Exchange administrator can set up rules on the Exchange server to prevent emails from being sent from apps. It's also possible to exclude specific flows or apps from the rules set up to block outgoing emails. You can combine these rules with an allowed list of email addresses to make sure that email from apps and flows can only be sent from a small group of mailboxes.
When an app or flow sends an email using the Office 365 Outlook connector, it inserts specific SMTP headers in the message. You can use reserved phrases in the headers to identify whether an email originated from a flow or app.
The SMTP header inserted in an email sent from a flow looks like the following example:
x-ms-mail-application: Microsoft Power Automate;
User-Agent: azure-logic-apps/1.0 (workflow 2321aaccfeaf4d7a8fb792e29c056b03;version 08585414259577874539) microsoft-flow/1.0
x-ms-mail-operation-type: Send
x-ms-mail-environment-id: 0c5781e0-65ec-ecd7-b964-fd94b2c8e71b
Header details
The following table describes the values that can appear in the x-ms-mail-application header depending on the service used:
| Service | Value |
|---|---|
| Power Automate | Microsoft Power Automate; User-Agent: azure-logic-apps/1.0 (workflow <GUID>; version <version number>) microsoft-flow/1.0 |
| Power Apps | Microsoft Power Apps; User-Agent: PowerApps/ (; AppName= <app name>) |
The following table describes the values that can appear in the x-ms-mail-operation-type header depending on the action being performed:
| Value | Description |
|---|---|
| Reply | For reply email operations |
| Forward | For forward email operations |
| Send | For send email operations including, SendEmailWithOptions and SendApprovalEmail |
The x-ms-mail-environment-id header contains the environment ID value. The presence of this header depends on the product you're using:
- In Power Apps, it's always present.
- In Power Automate, it's present only in connections created after July 2020.
- In Logic Apps, it's never present.
Potential Exchange rules for the default environment
Here are some email actions you might want to block using Exchange rules.
Block outbound emails to external recipients: Block all outbound emails sent to external recipients from Power Automate and Power Apps. This rule prevents makers from sending emails to partners, vendors, or clients from their apps or flows.
Block outbound forwarding: Block all outbound emails forwarded to external recipients from Power Automate and Power Apps where the sender isn't from an allowed list of mailboxes. This rule prevents makers from creating a flow that automatically forwards inbound emails to an external recipient.
Exceptions to consider with email block rules
Here are some potential exceptions to the Exchange rules to block email to add flexibility:
Exempt specific apps and flows: Add an exemption list to the rules suggested earlier so that approved apps or flows can send email to external recipients.
Organization-level allowlist: In this scenario, it makes sense to move the solution into a dedicated environment. If several flows in the environment have to send outbound emails, you can create a blanket exception rule to allow outbound emails from that environment. The maker and admin permission on that environment must be tightly controlled and limited.
For more information about how to set up the appropriate exfiltration rules for Power Platform related email traffic, go to Email exfiltration controls for connectors.
Apply cross-tenant isolation
Power Platform has a system of connectors based on Microsoft Entra that enable authorized Microsoft Entra users to connect apps and flows to data stores. Tenant isolation governs the movement of data from Microsoft Entra authorized data sources to and from their tenant.
Tenant isolation is applied at the tenant level and affects all environments in the tenant, including the default environment. Since all employees are makers in the default environment, configuring a robust tenant isolation policy is critical to securing the environment. We recommended that you explicitly configure the tenants that your employees can connect to. All the other tenants should be covered by default rules that block both inbound and outbound flow of data.
Power Platform tenant isolation is different from Microsoft Entra ID-wide tenant restriction. It doesn't affect Microsoft Entra ID-based access outside of Power Platform. It works only for connectors using Microsoft Entra ID-based authentication, such as the Office 365 Outlook and SharePoint connectors.
See also
Restrict cross-tenant inbound and outbound access (preview)
Get-PowerAppTenantIsolationPolicy (Microsoft.PowerApps.Administration.PowerShell)