Power Platform is clearly one of Microsoft’s major priorities. This isn’t surprising; if you look back at the history of low-code/no-code tools, you’ll see that prior platforms, including Visual Basic, Visual FoxPro (remember that?), Apple Hypercard, and Lotus Notes, all enjoyed significant success. Power Platform has become popular because, in many cases, Power Apps, Power Automate, Power Pages, and Copilot Studio make it easier and faster to build and deploy useful automations and applications than traditional development methods. However, there are significant security issues that arise when you move application and automation development “out and down”: away from professional developers and towards end users who are focused more on solving business problems than they are application security or reliability.
The Triad Returns
Old-school security professionals remember the “CIA triad,” but the term’s fallen a little out of favor. Rather than a spy agency, in this case, CIA refers to three fundamental components of system and data security: confidentiality, integrity, and availability. Authentication, privacy, reliability, and all the other “-ilities” can all be subsumed into these three areas. Microsoft promises to provide availability, but confidentiality and data integrity in Power Platform solutions is up to you. With that in mind, I thought it would be interesting to highlight a few of the most significant aspects of Power Platform-specific security for your awareness.
Environmental Separation
Earlier this year, I wrote about Power Platform environments and why you need to have more than one. To recap: the environment is essentially a container that can hold data and applications, with security boundaries applied and enforced. A single tenant can contain multiple environments. By default, every tenant starts with a single default environment, and unless you create additional environments, that’s where all your Power Platform objects and data will go. This has the major advantage of simplicity, but that simplicity comes with a significant drawback, too. You wouldn’t want to store lawn chemicals, your favorite shirt, your food, and your jewelry all in your refrigerator, and it’s not a great idea to put all your Power Platform data and applications into a single environment. There are different ways to use environments for data and application protection. For example, one major automaker I work with has four environments: one is for all user-created applications, and then there are development, test, and production environments for applications created by their IT team. Another large customer I work with has only two environments: one is open to all employees, and one is only for applications that have been reviewed for good development practices by their Power Platform team. Because applications in an environment can only access data sources (including gateways, connectors, data flows, and databases) in that same environment, using multiple environments is an effective way to add security for applications. However, keep in mind that many Power Automate and Copilot Studio projects are built to take advantage of those tools’ access to data in the Microsoft 365 ecosystem; no matter what environment you put a Power Automate flow in, it can still access data in the tenant that owns the environment, so environment isolation isn’t an effective way to control access.
Use Data Policies
You’re probably familiar with data loss prevention (DLP) policies in Microsoft 365. These policies are meant to give you control over what happens to sensitive content; for example, you can create a policy that blocks emails that appear to contain credit-card or social-insurance data. Power Platform has “data policies” that control data flow too, but in a different way: these policies control which services can talk to each other, because they apply to connectors and data flows. Microsoft’s documentation uses the example of preventing business data from being published via Power Automate to a social-media application, and this is a good example because it highlights what these policies are meant to do. You should create policies to group connectors and data flows according to their business significance, then define a policy if there are specific data sources you want to block. If you haven’t already done this, it’s not too late to start.
Don’t Skimp on Access Control
Like every other part of M365, Power Platform supports role-based access control (RBAC). You may not be familiar with all of the administrative roles specific to Power Platform, but you should be, as they exist to control what your admins are able to do in the Power Platform admin center. Power Platform also has a set of controls for defining custom security roles for users. Whereas you probably haven’t spent much time customizing user-level RBAC in M365, it’s more important to do this in Power Platform because these roles control what data tables role holders can see and change, as well as whether users can do things like export application data to Excel or Outlook. By default, Power Platform will map some role access to users based on the licenses you assign them (e.g. Dynamics user licenses will get some level of Dynamics permissions automatically). You should take the time to understand the user-level access controls in Power Platform so that you aren’t accidentally granting excess permissions to users.
Auditing, Monitoring, and Observability
Dataverse, the storage layer that underpins Power Platform, isn’t part of Microsoft 365… so its audit log is completely separate from the Microsoft 365 unified audit log. You must enable it on each environment, and when you do, Dataverse will start auditing a lot of actions that you may not be familiar with. The Dataverse audit log documentation makes a number of assumptions about the reader’s knowledge level; arguably, the most important section is “Configure auditing for one or more tables and columns in Power Apps,” because it tells you specifically how to control auditing for data that is modified by the Power Apps you own. Keep in mind that user authentication and all access to data held anywhere in M365 is still logged, where it always has been. To get a complete picture of what a user did, you’ll need to look in the Entra logs for sign-in, the M365 logs for access or changes to any data held there that your Power Platform solution handles, and the Power Platform logs for changes to data held in Dataverse. It’s worth spending some time to consider what behavior should be auditable when you create, or allow access to, a new application; for example, you probably don’t need to audit every table read for a Power App that shows the cafeteria lunch menu.
You Have to Start Somewhere…
Your organization may not be making much use of Power Platform today, but many are, and it might be more accurate to say you’re not using it much yet. It’s the right time to survey your Power Platform usage, see what flows and apps users have created, design an environment structure to keep the right applications and data under control, and apply appropriate auditing and observability so you can keep an eye on what’s happening. The upside of letting business-focused users create and manage their own business-oriented applications and automations is potentially very large, but so is the downside of a malfunctioning, poorly written, or insecure set of applications or flows. Proceed with caution.
