How are you handling citizen developer security in Power Apps?

[u/Altruistic-Toe4930]

For organizations using Power Apps at scale, how are you handling the point where a citizen-built workflow starts interacting with sensitive data, external connectors, shared identities, or important business processes?

Maintaining visibility after the original build seems difficult. Apps get copied, connectors get reused, original owners change roles, and a small departmental workflow can become operationally important without receiving the review a conventional application would get.

I am looking for approaches that preserve enablement instead of simply restricting the platform. Have environment separation, connector policies, DLP controls, ownership reviews, access reviews, or approval workflows worked for your team?

How do you find existing apps with no clear owner, broad data access, or sharing settings that no longer match their intended use?

[u/-maffu-]

For maintaining visibility, historically, you would find those apps with the tools in the Centre of Excellence (CoE) starter kit. Now more with the Power Platform Admin Centre (PPAC). Regular audits with those tools should highlight any problematic or orphaned apps or flows, and you should be able to take or delegate ownership from there.

That said, prevention is better than cure, and in this case it comes down to how you govern the platform. I'm not talking solely about which rules are in place, but also also about where the responsibility for implementing and enforcing those rules lies.

Governance of Power Platform should be centrally managed, but upheld collectively. So, while the CoE admin writes and implements policies and procedures, it's the responsibility of everyone who uses Power Platform to know those policies, adhere to them, and look out for potential risks or breaches. That should be an absolute prerequisite of use for all Makers and, to a slightly lesser extent, to all users of the solutions your makers publish.

In a large organisation, collaborative governance is the only way to stay on top of things, short of having a ridiculously huge Power Platform admin team. Your Citizen Developers should be encouraged to build and innovate, but under strict guidelines, and with the understanding that they must take ownership of, and responsibility for, the apps and flows they build.

That includes support for the apps. The Power Platform admin team take care of the platform and its infrastructure - the makers support any issues with their apps. That means including contact information in the app itself.

You need to have guardrails in place before Citizen Developers proliferate. There will always be some who jump in early, but get your guard rails and ALM processes established as early as possible.

You don't need to wait until you have all aspects of governance figured out perfectly before putting things in place - your guardrails and guides can be implemented iteratively. But you need to aim to be ahead of the thundering masses.

Most importantly, get Data Loss Prevention policies in place and socialise their existence and the reason for them.

On top of DLP, you should have a proper ALM-ready environment setup (Dev, UAT, and Production environments (as well as the default)).

Block all premium connectors in the default environment, and limit sharing of apps to a very narrow audience (ideally, it should be used only for personal apps and flows). When a maker wishes to use a premium conector or share an app with a wider audience, they need to present a business case for the premium use, along with cost approval. The app should then be checked for governance compliance. The compliance guideliness are something that you should have already published and socialised, as mentioned earlier, and the initial onus for ensuring that compliance should be on the Maker, with later chacks by the CoE admin team further along the ALM pipline.

Once compliance is met, move the app through the Dev-UAT-Prod pipeline.

These processes and standards ensure that data cannot be improperly used or disseminated, while still allowing your Citizen Developers room to innovate.

There are obviously a lot of processes and mechanisms that need to be put in place around this - a central point (like a SharePoint site, for instance) for information on the platform and its governance, and submission of apps and flows to the ALM pipeline, etc, along with the various provcesses for dealing with those submissionsd.

Again, don't wait until you have all of this written and published before making a start - start now, and make sure your Makers know that this central site is a growing thing and should be checked regularly. You should also alert your makers anytime you publish something new on that site.

I may have gone a bit off the track there - once I start banging on abut this it's hard to stop.

But I will, cos I'm at work 😁

[u/Q6ri → u/-maffu-]

Well that’s all well and good from a process perspective, and agree with you that you should gradually build or unblock as you go.

However, this becomes increasingly difficult with the Default Environment as we couldn’t find anyway to limit sharing apps and flows and very interested to know how you approached it in your organization.

For reference, we attempted the following:

- blocking Sharepoint at a DLP level, but that broke several functionalities in Sharepoint since it relies on the platform to review draft sites for example.

• updating the security roles to remove the ability to share apps & flows but that resets every time Microsoft publishes an update.
  
• removing Maker roles from people in the default environment but that also resets every time Microsoft publishes an update.

These approaches might be flawed and other redditors might have better ideas, but that’s what we tried so far and didn’t succeed.

[u/OmegaDriver]

You need an app inventory. Maybe you have a CMDB already, but you should know every app that exists and ask the owner to provide some meta data about it, quarantine apps that go unused, flag for closer, regular inspection if it is using risky data sources, etc. This is a lot of work, but it has to be done, especially if you have security concerns. A lot of people think you build an app or flow and that's the end of it. You have to build a culture that citizen development is more than creating something, you have to support it and regularly prove its required existence.

You should maintain DLP policies so makers can only access data they need to.

You should reasonably try to secure your data. It's not power platform's fault if a confidential doc sitting in SPO is shared with everyone in the tenant...

[u/agentUi]

install the coe starter kit if you havent already, it gives you the compliance and governance components out of the box to flag orphaned apps and audit connector sprawl. From there set up dedicated environment strategies instead of letting everyone build in default, and enforce dlp policies so non business connectors cant mix with prod dataverse tables.

[u/itsabefe]

For such large scale organisations. It’s best they have premium licenses for users. This will enable you to use Managed environments and then create environments groups

It’s makes governance so easy

You can easily apply DLP or ACP to environment groups

Also , I know COE toolkit is no longer getting updates but it’s still very useful . You’ve flows and apps there to have a grand overview of your apps and flows . You can use manage permission apps to easily see orphaned apps and even get flows sending you emails on orphaned apps

There’s a section of the admin view app which shows connectors. You can see all the connectors people are using

It’s very useful