As with most services and features within Microsoft 365, Power Automate though great is open by default and allows a bit too much flexibility. For an organization that requires stricter security controls, these features can be too much to allow without a solid security plan. For example, consider working within a restricted, secure, or even medical organization with many legal ramifications if personal or private data leaves the organization when it should not be allowed.

A genuine concern is an ability for end-users to create flows that externally post sensitive data to services not sanctioned by the organization. Power Automate and the eDiscovery Compliance Search application tools within Microsoft 365 are valuable targets for attackers. A study performed in 2020 by Vectra revealed that 71% of the accounts monitored had noticed suspicious activity using Power Automate, and 56% of accounts demonstrated similarly suspicious behavior using eDiscovery components.

Can you imagine what would happen if, all of a sudden personal medical records appeared on social media from a supposedly internal intranet that did not block or control data flow within services like Power Automate? If I was in charge of the security at that organization, I might be looking for another job.

So the question becomes, what security controls exist to control and even block Power Automate?

As with most components in Microsoft 365, security is hierarchical. A few of the security controls and options are:

  • Power Automate Licensing
  • Power Automate environments
  • Cross-tenant inbound and outbound restrictions
  • Policies to prevent data loss
  • Conditional access policies

Licensing

The main boundary for end-users accessing Power Automate is licensing. If the user does not have a license, they cannot access the organizational instance of Power Automate. However, be aware that a free license is auto-provisioned and allows end-users to use it for 90-days. A simple step is to disable ad-hoc subscriptions and trial and developer plans.

# Check the current setting for allowing ad-hoc subscriptions
Get-MsolCompanyInformation | Select AllowAdHocSubscriptions

# Disable ad-hoc subscriptions
Set-MsolCompanySettings -AllowAdHocSubscriptions $false

# Re-check the setting for allowing ad-hoc subscriptions
Get-MsolCompanyInformation | Select AllowAdHocSubscriptions

With ad-hoc subscriptions now blocked, next, we remove trial and developer plans. Complete this by removing the “Internal” and “Viral” properties.

“Internal” consent plans are trial licenses or developer plans that users can sign up for via Power Apps/Power Automate portals. 

“Ad-hoc subscription” or “Viral” consent plans are trial licenses that users can sign themselves up for via https://signup.microsoft.com, or admins can assign to users via Azure Active Directory (Azure AD) or the Microsoft 365 admin portal.

More details: https://docs.microsoft.com/en-us/power-platform/admin/powerapps-powershell#block-trial-licenses-commands

# Install the PowerApps PowerShell Modules
Install-Module -Name Microsoft.PowerApps.Administration.PowerShell
Install-Module -Name Microsoft.PowerApps.PowerShell -AllowClobber

# Connect to PowerApps PowerShell
Add-PowerAppsAccount

# Check the currently allowed plans
Get-AllowedConsentPlans

# Remove "internal" and "viral" plans
Remove-AllowedConsentPlans -Types @("Internal", "Viral")

Administrators can also control the self-service part of purchasing licenses to block or limit departments or users simply paying for the licenses themselves. PowerShell commands are available.

# Install and Import the required PowerShell Module
Install-Module -Name MSCommerce -Force
Import-Module MSCommerce

# Connect to Microsoft 365 Commerce
Connect-MSCommerce

# Check the current status of the self-service capabilities 
Get-MSCommerceProductPolicies -PolicyId AllowSelfServicePurchase

# Block self-service
$policies = Get-MSCommerceProductPolicies `
	-PolicyId AllowSelfServicePurchase | ? {$_.PolicyValue -eq "Enabled" }

$policies | ForEach {
	Update-MSCommerceProductPolicy `
		-PolicyId AllowSelfServicePurchase `
		-ProductId $_.ProductId `
		-Enabled $False 
}

# Re-check the status of the self-service capabilities 
Get-MSCommerceProductPolicies -PolicyId AllowSelfServicePurchase

Environments

Environments are spaces to store, manage, and share organizational business data, apps, chatbots, and flows. It also functions as a logical container based on different roles, security requirements, or target audiences. For example, you could choose to build all custom applications within a single environment. You might also define development, test, and production environments. You can also correspond environments with specific departments or groups of users to control data flow.

When creating applications within an environment, they are only allowed to connect to corresponding components within the same environment. An app would only connect to provisioned data connectors, gateways, flows, and database databases in that environment.

Cross-tenant inbound and outbound restrictions

Power Platform tenant isolation ability is available with two options: one-way or two-way restriction. Power Platform tenant isolation only works for connectors using Azure Active Directory (AAD) based authentication. Organizations can specify a list of tenants that users can access using cross-tenant restrictions. Azure Active Directory (AAD) then exclusively grants access to these permitted tenants using Azure AD-based tenant restriction.

One-way tenant isolation or inbound isolation will block connection attempts to your tenant from other tenants.

Two-way tenant isolation will block connection attempts to your tenant from other tenants.

NOTE: If you need to block connectors that use external identity providers such as Microsoft or Google accounts, you must create a data loss prevention policy and classify the connector under the blocked group.

Enabling cross-tenant isolation for Power Apps and Power Automate requires raising a support ticket in the Power Platform admin center.

Policies to prevent data loss

Power Automate provides the ability to control the dissemination of data via its connectors by using data loss prevention policies. Depending on the selected category determines how end-users can use the connectors. You can assign either business, non-business, or blocked as the category.

Connectors that host business-use data should use business as the assigned category, and connectors that host personal data should use non-business. All connectors are placed in the non-business group by default when creating policies. Any connectors you want to keep from being used across one or more environments should be classified as blocked. You cannot share data across connectors located in different groups. Although you cannot share data within services in other groups, you can share it with services within the same group. For example, if you have SharePoint and Salesforce in the same group, data is shareable between them. If you have SharePoint within business and Twitter in non-business, information is not shareable between them. When categorizing services as blocked, that connector enforces blocking. For example, if you place Twitter in the blocked group, end-users cannot create a flow that uses the Twitter connector.

NOTE: You cannot block many of the out-of-the-box connectors such as SharePoint, Yammer, Microsoft Teams. Defender for Cloud Apps, to name a few.

Data loss prevention policies are assignable at the tenant or environment level. Polices are created within the Power Platform admin center or via PowerShell. Each connector, if allowed, is assignable to either business, non-business, or blocked.

The scope of the policy is set to either all or selected environments. You can also exclude specific environments.

Once you create a policy, a backgrounds job executes to implement the required policy., From this point, any modifications also execute a background job for updating.

Conditional access policies

Conditional access is a core feature built into Azure Active Directory (AAD). It allows organizations to control when users can access applications and services. If you are looking to block and prevent any Power Platform services such as Power Automate, this is the tool. Simply creating a policy that enforces Multi-factor authentication (MFA) will break nearly every part of the flow creation process due to the authentication mechanism now required. To understand some of the issues, you can read more here:

https://docs.microsoft.com/en-us/troubleshoot/power-platform/power-automate/conditional-access-and-multi-factor-authentication-in-flow#more-information

When creating conditional access policies, you must add Microsoft Power Apps and Microsoft Flow. To create a Conditional Access Policy, access the Azure portal and navigate to the Azure Active Directory (AAD) blade. Next, click Security, and then click Conditional Access.

As with any conditional access policy, set the name, user, and group assignments and select the two applications.

Lastly, set any Conditions, followed by the Grant controls such as block. The next time end-users try to access the Power Platform services, a message will stop them and explain why they do not have access.

As you can see, there are different ways of locking down access to Power Automate, some easy, some complicated. There are also other tools and services that you can use to protect further. Hopefully, this gives you an idea of what you can begin with. Then you can grow into other options such as blocking service principles within Azure Active Directory (AAD) or even using Defender for Cloud Apps.