Setting up some key tenant restrictions is a good starting point to establish a robust Power Platform governance in a secure way, as suggested in this other post.

• Carefully assign the Power Platform Tenant Administrator role
• Define the Power Platform Tenant Settings
• Secure your Power Platform Tenant with Cross-Tenant Isolation
• Don’t wait to set up a default tenant DLP Policy

Carefully assign the Power Platform Tenant Administrator role

The Power Platform Administrator role can be assigned to provide elevated permissions over the platform (official documentation here). Users with this role:

• Have the system administrator role automatically assigned on each Environments. In other words, they can perform any administrator operations on any given environment,
• Are able to change some Power Platform related settings at tenant level that apply to the entire tenant. Users who only have the environment system administrator role on an environment cannot modify such settings,
• Have such administrator privileges over the Power Platform, Dynamics 365 and Power BI, although Dynamics and Power BI have also their respective dedicated administrator role,
• Do not have such elevated privileges outside the Power Platform. For instance this role does not grant administrator permissions over SharePoint, for which there is a dedicated administrator role.

Using this role is a good way to avoid granting the Global Administrator role to too many people. Although for some isolated operations the Power Platform Administrator role might not be enough, it is enough in most situations.

Users who are responsible for the platform Governance for the organization should have this role. However and as for the Global Administrator role, you do not want to grant this role to too many individuals which could lead to accountability and stability issues. Essentially the users with this role will be the gate keepers of the tenant restrictions to secure the platform.

Define the Power Platform Tenant Settings

From the Admin Center

Power Platform Administrators have access to some tenant settings from the Power Platform Admin Center.

Although each setting is worth reviewing and considering, let’s focus on the few below.

Environment creation settings

• Production environment assignments: this setting allows to restrict who can create new standard environments. If set to “Only specific admins”, then only tenant administrators will be able to create new Environments.
• Trial environment assignments: same principle but for the Trial environments which expire automatically after 30 days.
• Developer environment assignments: same principle for developer environments. This is another type of environments and it is for development only. They have some capacity limits and are associated with the users requesting them.

For wide organizations, setting the above settings to “Only specific admins” can be a good way to keep control over the tenant and ensure an appropriate configuration for each new environment. I personally like the concept of the developer environments, though it is important to implement the necessary controls to ensure Makers cannot use such environments to bypass other restrictions. For an organization starting with the governance, I would suggest to set all the above settings to “only specific admins”.

Add-on assignments and Tenant Analytics settings

The two other settings below are also interesting:

• Add-on capacity assignments: this allows to restrict who can allocate the addons purchased in the tenant to environments (such as the AI Builder Capacity, Power Automate Process, etc…). As for the environment creation settings, setting it to “Only specific admins” will only allow tenant admins to allocate them. Again, this can be a good way to start, especially for wide organizations. Let’s imagine that you have dedicated environments for each department. If the HR department purchases some addons, you want to make sure that they are the ones who will be able to use these addons, and that a system administrator of an other environment will not mistakenly allocate them to their environments instead.
• Analytics: this allows to access some tenant level reporting from the admin center. System Administrators will only see the data related to the environments they are an admin of, and tenant admins will see everything. Though the feature is valuable, it is important to note that once turned on, the analytics metrics will be stored in the default environment. Depending on the business and environments regions it can clash with certain regulations.

From PowerShell

Not all the Power Platform tenant settings are available from the admin center. More tenant restrictions are manageable with PowerShell to secure the Platform. Tenant admins can use the Microsoft.PowerApps.Administration.PowerShell module to manage them with the Get-TenantSettings and Set-TenantSettings cmdlets.

Let’s look at a few more below.

disablePortalsCreationByNonAdminUsers

Once set to “true”, it restricts the creation of Power Pages Apps (ex “Power Apps Portals”) to tenant admins only. Tenant admins will be able to provision such Power Pages apps in an environment and still hand them over to the system admins afterwards to manage and administrate the app. Since is is fairly easy to misconfigure a Power Pages app and expose data publicly and anonymously, it is a setting worth considering for organizations. The code below shows how to set it to true for a tenant:

$set = Get-TenantSettings
$set.disablePortalsCreationByNonAdminUsers = $true
Set-TenantSettings $set

powerPlatform.powerApps.disableShareWithEveryone

Setting this to “true” will hide the option to share Canvas Apps with “Everyone in [org name]” for Makers. Only tenant admins will be able to use this option.

Though sharing a Canvas App does not share the underlying data, it is a best practice to only share an App with the users who need to use it. Using this setting can encourage Makers to define the right audience for their Apps. Admin can also leverage this setting to enforce a standard process whenever an App does need sharing with the entire tenant. However, for it to be a success, Makers will likely need suitable alternatives to share an App with a region or department, which could be achieved with well-defined Azure dynamic groups for instance. The code below shows how to set this setting to true:

$set = Get-TenantSettings
$set.powerPlatform.powerApps.disableShareWithEveryone = $true
Set-TenantSettings $set

Secure the Power Platform with Tenant Isolation

Tenant isolation is a feature now available from the Power Platform Admin Center.

What prevents your Makers from creating their own tenants and creating Flows and Apps with the SharePoint connector to interact with your company data? And what prevents them from creating Flows and Apps in your own tenant but to integrate with the SharePoint sites from a tenant that does not belong to your organizations? This can be a risk particularly high when working with consultants. Well, Tenant Isolation is the answer.

It allows to restrict inbound and outbound connections for connectors supporting Azure AD-based authentication. Once turned on, all inbound and outbound connections are blocked for Power Apps Canvas Apps and Power Automate Flows. Tenant admins can whitelist other tenants for inbound, outbound, or both way connections.

This functionality has been around for a while though it used to not be manageable directly from the admin center. I would recommend to leverage this feature and refer to the comprehensive Microsoft documentation about this topic.

Don’t wait to set up a default tenant DLP Policy

Hard to speak about how to secure the Power Platform with tenant restrictions without mentioning DLP Policies. Power Platform Data loss prevention (DLP) policies are essentially what allows admin to define the connectors that Makers can and cannot use in an environment. Managing DLP Policies is key to govern the platform, since each of the 1000+ connectors available today allow to integrate with services that might not be suitable for the organization.

The topic of connector and environment strategy is a topic in itself. It will not be described in depth here as it deserves a dedicated post. Defining which connectors to allow, block, or to ask an approval for and on which environment can take time. However, any organization starting to establish a governance for the platform should get familiar with this concept and start by setting up a restrictive DLP Policy which will apply by default to any new environments. Indeed it is possible to set up a policy which will apply to all environments unless specifically excluded from it. It will restrict a minimum any new environment by default. The organization’s strategy and governance will mature in time to define if/when/how Makers should access more connectors.

Here are my recommendations with regards to this DLP Policy

• Only the default policy should have the scope “Exclude certain environments”. This will avoid confusion when more policies and environments start emerging,
• The default connector group should be set to “Blocked”. This will ensure new connectors won’t appear without the knowledge of the admins,
• When a new policy is set for a specific environment, this environment should be excluded from the default policy.