There is a substantial amount of documentation available for organisations that have already adopted the Power Platform to a relatively mature extent, via Dynamics 365 or premium licenses. Instead of discussing the Centre of Excellence and other advanced topics, I’m going to take a step back and imagine an organisation that is starting to use the Power Platform with Microsoft 365 licenses.
Power Apps and Power Automate for Microsoft 365
The Power Apps and Power Automate licenses that come with Microsoft / Office 365 are intended to give Users the ability to extend the Office experience.
TIP: For more detailed information, visit the Microsoft Learn ‘Licensing overview for Microsoft Power Platform‘ and scroll to the ‘Power Apps and Power Automate for Microsoft 365’ section.
There are limitations:
- Your tenant will only have one environment known as the ‘Default’ environment.
- Your licensed Users will only be able to connect to and consume non-premium services including SharePoint Online, Microsoft Teams and Exchange Online.
However, if the ‘Default’ environment is not governed well, then issues can arise such as confidential data leakage.
Starter for 10
There is a list of steps an Administrator can do:
1. Create an ‘Environment Strategy’ Document
Create a living document. On day one this may be a bullet point list of areas you want to review. Update the document as you progress and your requirements mature. You may decide to share this within the ‘Power Platform hub’ (see point 5).
2. Communicate intent
Microsoft suggests that “One of the key challenges for the Power Platform Center of Excellence (CoE) team is to communicate the intended uses of the default environment.”. Your organisation may already be actively using the Power Platform, so communicating the planned changes before they are put into place gives others the opportunity to:
- Give feedback
- Ask for help
TIP: A ‘Power Platform hub’ can be a good option for sharing this information (see point 5).
3. Limit the number of Users with Admin roles.
There are two levels, the Power Platform Service and the Power Platform Environment(s).
Power Platform Service
Accounts with the Power Platform Administrator role have the keys to the kingdom (service). They can manage who can access an environment and what role they can play (e.g., what they can access) within that environment. Similar to a Microsoft recommendation of limiting the number of Global Administrators within a tenant, the number of Power Platform administrators should also be limited.
TIP: Depending on your organisation’s licenses, you may be able to manage these highly privileged roles using Privileged Identity Management (PIM).
Power Platform Environment
Each Power Platform environment has a set of predefined security roles, the following of which are the most privileged and should have limited membership.
Environment without a Dataverse database (not relevant for the ‘Default’ environment):
- Environment Admin – can perform all administrative actions on an environment…
- Environment Maker – Can create new resources associated with an environment, including apps, connections, custom APIs, gateways, and flows using Microsoft Power Automate. However, this role doesn’t have privileges to access data in an environment.
Environment with a Dataverse database, for example, the ‘Default’ environment:
- System Administrator – Has full permission to customize or administer the environment, including creating, modifying, and assigning security roles. Can view all data in the environment.
- System Customizer – Has full permission to customize the environment. Can view all custom table data in the environment. However, users with this role can only view records that they create in Account, Contact, and Activity tables.
TIP: See the Microsoft Learn article ‘Configure user security in an environment‘ for more information about ‘Predefined security roles’.
4. Rename the ‘Default’ environment
Microsoft recommends renaming the ‘Default’ environment to ‘Personal Productivity’ to help manage the expectations of administrators and users and communicate intent (see point 1).
5. Use the Power Platform hub
To quote Microsoft, “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.
See ‘Create an internal Microsoft Power Platform hub’ for more information.
6. Establish a data loss prevention policy
Creating a data loss prevention (DLP) policy for the ‘Default’ and other environments can protect the organisation’s data by defining what connectors can be consumed. DLP policies can be created at the tenant or environment level and are managed from the ‘Power Platform admin centre’. For more information, see ‘Create a data loss prevention (DLP) policy’.
As a Power Platform Administrator, consider creating:
- A tenant-level policy that spans all environments with exceptions, for example, production environments. In Microsoft’s words “keep the available connectors in this policy limited to Office 365 and other standard microservices, and block access to everything else.” And consider:
- Blocking all new connectors by setting the ‘Blocked’ group as the default.
- Limit custom connectors with a rule to block all URL patterns and add exceptions where required.
- One or more tenant-level policies specifically for environments that are excluded from the previous policy and work with the owners of these environments to decide on which connectors to block or add to the “business” or “non-business” groups.
TIP: All Microsoft-owned standard connectors and Common Data Service connectors cannot be blocked.
As a System Administrator or System Customiser, you may consider creating a DLP policy to block additional connectors within your environment. However, note that DLP policies cannot override tenant-wide DLP policies.
TIP: The names ‘business’ and ‘non-business’ are simply labels. The grouping of the connectors themselves is of significance, not the name of the group they’re placed in.
7. Limit sharing with everyone
Makers can share their apps with individual users and security groups, including “everyone in the organisation”. Microsoft suggests “disabling the Share with Everyone feature in Power Platform. With that restriction in place, only a small group of administrators may share an application with everyone in the environment.” See ‘Limit sharing with everyone’ for details on how to apply this change.
8. Secure integration with Exchange
Work with the Exchange administrator to consider creating rules that limit sending emails from apps and flows. For more information see ‘Secure integration with Exchange’.
9. Apply cross-tenant isolation
In Microsoft’s words, “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.”
Consider turning cross-tenant isolation on and “…specify an explicit allowlist of tenants that they want to enable inbound, outbound, or both, which will bypass tenant isolation controls when configured.” For more information see ‘Cross-tenant inbound and outbound restrictions’.
10. Communicate & Support
This is a repeat of the first point. Ensure that you communicate the changes to everyone within your organisation and let them know who they can turn to if they require help. Without good communication and support, you risk undoing all the good work done to secure the Power Platform and risk others introducing ‘Shadow IT’ to work around your restrictions.
And Next…
This is just the start of your journey. As your organisation’s Power Platform usage matures, and hopefully before lots of mission-critical Apps and Flows have been created, consider:
- Installing the Power Platform Centre of Excellence (CoE) Starter Kit. The CoE requires a managed environment and premium licenses but in return, it will provide much more visibility as to how your organisation is using the Power Platform.
- Creating a ‘Power User Environment’. This environment should use a more permissive DLP policy. The ‘Makers’ list should be managed via a SharePoint list and approval Flow.
- Custom Environments for Teams and Projects. These environments are for those that have “business unit-specific use cases or application lifecycle management scenarios”.
- Continual Review. Regularly review your Power Platform usage and policies to ensure they remain effective and relevant.
And don’t forget to update the ‘Environment Strategy’ document and communicate all changes. This will ensure everyone in your organisation is kept informed and can contribute to the ongoing development and success of your Power Platform strategy.
Conclusion
This article guides organisations using the Power Platform with Microsoft 365 licenses. It highlights the ‘Default’ environment’s limitations and potential issues.
It provides a roadmap for administrators, including creating an ‘Environment Strategy’ document, managing roles, using the Power Platform hub, establishing a data loss prevention policy, securing integration with Exchange, applying cross-tenant isolation, and ensuring effective communication and support.
As usage matures, it recommends installing the CoE Starter Kit, creating a ‘Power User Environment’, custom environments, and continuous review.
The importance of updating the ‘Environment Strategy’ document and communicating changes is emphasised. The article offers a framework for a secure, efficient Power Platform implementation and continuous improvement.