Power Platform Security
In this latest blog post we continue to build up our Power Platform implementation based around our Scalable Governance Model. We’ve described how our Environment, DLP, and Governance Strategies build on top of the model… We’re now going to have a look at which security controls we might align to sizes Small to X-Large.
Firstly let’s think about what we’re securing. Of course we want to keep our organisation and people safe but when we think and talk about Security in this context we’re thinking about how we secure our underlying data and systems. With this in mind we’re going to place Data at the center of our conversations.
There are multiple levels we can use to describe the controls. We can look at the controls through different lenses - Platform Level Security, Use Case Enablement Security, Use Case Security.
As with previous posts I’ve translated how I view this into a drawing. Below you’ll see how I look at these controls. At the bottom of the picture is the data and I’ve the layered up security opportunities as we get further away from that specific solution data up to how we isolate our tenant and ensure we’re consciously enabling connectivity to other tenants if we want / need to.
So let’s get into looking at these controls. These are all topics in their own right so to avoid writing a Power Platform equivalent of ‘War and Peace’ I’m just going to give an overview of each at this stage. Let’s start with the most granular levels around security for specific use cases.
Use Case Security - These are the most granular of controls and the considerations around how we design, architect, and implement our specific use case, within our wider governance framework.
Data / Systems Access - Our first step is looking at the security of our data or systems. Power Platform won’t provide extra rights than are already there. If I’ve shared my data with ‘Everyone’ in my organisation (even if they don’t know that) then my PP solution may just make that more available. If my system access allows me to create, read, update, and delete items, but I’m not aware of it, then creating or an App or Flow may expose functionality that’s not been actively promoted.
Solution Architecture - We can think of this of how we construct our solution to solve our use case. This may be approaches such as segregating functionality / capabilities into different solutions to remove risk of people doing things we don’t want them to. This may be creating a separate Admin App instead of building roles into a single solution. Or it may be that our user facing solution enables them to submit and maintain their data and then use appropriately licensed services to bring that into a higher risk data set or system.
Connectors - This is one of the obvious security controls - Connectors are how our solutions connect to data sources, systems, or services. If we don’t make them available then people can’t connect to those sources. Or we may opt to create a custom connector if we’re not happy with the functionality or control that an ‘out of the box’ connector provides.
Connector controls - Within an increasing number of connectors there is also more granularity being provided. Within some connector controls we’re able to specify which actions we want to allow people to perform e.g. we might be happy for them to read but don’t want them to update or delete. We can also specify allowed endpoints for some of the connectors too so we can ensure that only a specific database or table or view is connected to by that connector.
Use Case Enablement Security - This is how we configure elements of the platform that provide a security wrapper around our Solution to protect it. Our governance framework that enables safe and secure use of the platform.
DLP Strategy - We went into more depth in the previous blog post on DLP Strategy so I won’t do it here but to remind you - This is how we bring multiple connectors together to allow them to be used in a use case by those who have access to an environment (another previous blog post) where they’re applied.
Environment Assignment - This is how we apply those DLP policies to one or more environments - We can apply them to ALL Environments, or specific environments, or we can set a rule like ‘All EXCEPT… x, y, z’ to ensure that any new environments that are created will have a DLP policy applied to them by default to keep us secure.
Managed Environment Controls - We took a deeper look at all of the Managed Environment controls in the Environment Strategy post. Let’s remind ourselves of the key controls that apply to security. (See this Microsoft Learn article for more detail)
Dataverse IP Cooking Binding - When using Dataverse a cookie captures the IP address of the user. If this is captured and reused by a malicious agent it identifies the different IP address of the agent and prevents access.
IP Firewall - This enables us to specify an IP range of allowed device addresses who are able to access Dataverse in that environment to control who has access and from where.
Customer Managed Key for data at rest - Data is secured at rest using a Microsoft Managed Key by default. With Managed Environments an organisation can use their own Managed Key to ensure that it’s only their organisation who have access to their data.
Virtual Network support - This enables connection to other systems, services, and data sources to be routed through a Virtual Network within Azure rather than traffic going via the public internet to further reduce the likelihood of external access to any data.
Environment Access Management - This is how we make our environments and the connectors in our DLP policy available to specific people to do specific tasks. Outside of the Default Environment to do this we have to actively grant access and roles to people. We control who can make solutions in that environment. We control who can use solutions in that environment.
On Premises Data Gateways - Another tool in our security tool box that manages what On Premises data is exposed to the cloud, and who can access it through which environment.
Platform Level Security - These are the controls which can be applied across the whole tenant.
Conditional Access - We can use Azure Entra ID (formally Azure Active Directory) Conditional Access policies to specify key criteria for devices that can access our tenant - These might be things like specific locations, requiring Multi-Factor Authentication, Organisation Managed Devices etc. More detail here on Microsoft Learn
Tenant Access - This is our general access control. Either an individual needs an Active Director account in our tenant, or has been granted access through a guest account etc. A variation on this would be externally Power Pages where we may permit users (we can choose what registration / authentication, or not) to interact with data within a specified Dataverse instance.
Tenant Isolation - And then thinking outside of our tenant / core tenant… We can ensure that our tenant can only connect to tenants that we permit through whitelisting. You can only connect to resources within our tenant unless we’ve allowed access to xyz.anothertenantname.com
So as you can see! There are a LOT of security controls at our disposal to ensure that we can apply these in the most appropriate was to secure our solutions. If we think about the scalable governance model and how we describe use cases and solutions in terms of different levels of risk we can tailor these controls to be appropriate to those levels. Some controls apply across the tenant to give us a core level of security and safety, but although providing additional security, we may only see value in mitigating risk for our Large or X-Large solutions… Every organisation’s risk acceptance level is different and also varies across industries and regulatory needs. Hopefully this post gives a good general overview and highlights the ‘T- Shirt Sizes’ where you might find get most value from them!
If you find this post or any other of my posts useful please subscribe below to make sure you don’t miss out on future posts when they’re published! :)
