In this next post as part of my series on architecting solutions for the Power Platform I’d like to continue to talk about the topic of implementing security solutions as part of the wider solutions we design for the Power Platform, focusing on what we can do at the environment level specifically! Stay tuned for more content on Power Platform security coming up in this series soon friends! 🔒 🚀
What are environments?
Power Platform environments are like containers that hold your apps, data, and settings. You can use them to separate your work from your personal stuff, or to manage different projects or teams. Environments are easy to create and manage, and you can switch between them anytime you want. Now lets explore some of the layers that exist within environment security for Power Platform.
Microsoft Entra ID
Microsoft Entra ID is the layer at which authentication works for the Power Platform. Similar to any other Microsoft Cloud products and services using SSO and the one identity provided by Microsoft Entra ID, we have authentication out the box using this platform which has several features Power Platform is able to use such as conditional access, identity and access management, B2B guest users and partners and more.
There is an important thing to remember here with the way that Power Platform is backed by Microsoft Entra ID. Suddenly the group of people that are possibilities for accessing things within the Power Platform aka the low-code platform of our choosing, is everyone in our Microsoft tenant. So if you’re one of those organisations with a share all policy, and you apply this to your apps, don’t expect that the only people with access will be those you’re familiar with ‘having access to Power Platform’… because it could in fact be everyone in your Microsoft Entra ID tenant.
Restricting cross-tenant operations
Using Microsoft Entra ID backed functionality, the Power Platform has features around ‘tenant isolation’ which lets organisations specify the list of tenants that their users are permitted to access or vice versa the tenants that people can connect from.
Learn more about tenant isolation at Microsoft Learn here – Restrict cross-tenant inbound and outbound access – Power Platform | Microsoft Learn
Restrict access to environments with security groups
As a default setting a user with a Power Apps or Power Automate license may be able to access any unsecured environments in a tenant. Using Microsoft Entra ID security groups allows administrators to put a layer of governance over this area of the platform, preventing any access to environments unless a user is within a specific security group.
Solution relevant and granular level access control with security roles
Finally we get to the really useful stuff where we can control security and access control within the environment level and down from there using security roles. These effectively give us different levels of access to different operations or tables within an environment. There are a number of these which are automatically assigned to users based on Microsoft Entra ID roles they may have such as Global admins, Power Platform Admins and CSP Delegated admins have full administration to Power Platform services in the tenant, though after those security roles are applied at the environment level to control access there forward.
It’s important for solution architects to have a very good understanding of how security modelling works in the Power Platform, specifically around security roles and how they’re applied using the organisational structures, and user structures within the Power Platform too!
Learn more about security roles below, and stay tuned for the next part of this series friends! 🚀
Security roles and privileges – Power Platform | Microsoft Learn