Shared Power Platform Environment Security Model

[BrokenWookie74]

Looking for some best practices on security and data segregation as it pertains to Dataverse (understand that SharePoint, SQL, etcetera, has their own security models) within a shared environment.

Context: I have proposed an architecture and governance strategy for test (sandbox) and production environments for a large subsidiary that each individual business unit actually operates essentially as self-governed startups. I have a production environment and test environment for each of their top level divisional structures. Two reasons for this; 1) It's not reasonable to manage 300+ PP environments to represent every business unit, 2) we chargeback the subsidiaries usage to their budgets. So, you might be thinking, "Okay...but, the PP is user license based...". Correct it is, and ALL of their users have E5s, but that really only gets you PowerBI Pro in the context of the Power Platform, it doesn't get you premium connectors, Dataverse capacity, etcetera. For this reason, we're utilizing billing policies so premium usage can be accrued within Azure workloads which can then be charged back to our EA spend, and those generated Azure resources can be tagged to our Finance department knows who to charge that spend back to.

Takes a breath: All that said, given that we're expecting to have multiple business unit's managed solutions sharing environment space within their respective division's PP environments. What's the best way to ensure that there's no cross contamination of access between solutions?

We're not intending to utilize any of the "core"/built-in tables generally speaking, save Users or aadUsers, but solutions will use custom tables.

From what I gather, the best way is create PP "Business Units" and custom security roles for each distinct user group needing access. Grant the custom roles BU access to just the specific tables needed, and assign to the app/solution.

[ChrisPiasecki]

Hi @BrokenWookie74,

At a high level, what you described can be a reasonable approach from a security perspective. Create child business units under the root business unit as-needed, and use security roles to provide permissions to the tables needed and scoped at business unit or whatever level of granularity required. Assign the security role(s) to the appropriate apps and you should be good to go.

Ensure users and developers do not have any system customizer or system administrator role (if required to troubleshoot, grant your developers temporary elevated privileges).

Ensure development for each solution is performed in isolated environments. There should not be multiple unmanaged solutions in one development environment because that introduces potential cross contamination issues.

Now, keep in mind that a shared environment requires additional governance around release/change management to minimize impacts to other business areas when deploying solutions. If all the applications similar operational characteristics (uptime requirments, hours of operations, recovery objectives, etc.), then it's easier to manage scheduled downtime and other operational tasks. 

If you have some apps that are mission critical with different SLAs, you should consider moving those workloads into dedicated environments to reduce operational risk. 

Note that you can apply a billing policy to multiple environments, so from a chargeback tracking perspective you should be fine. 

---
Please click Accept as Solution if my post answered your question. This will help others find solutions to similar questions. If you like my post and/or find it helpful, please consider giving it a Thumbs Up.