In this next post in my series on solution architecture, at this point focusing on security, we’ll take a look at data loss prevention options within the Power Platform and we’ll focus on the high level on the understanding a solution architect should have here in order to be able to design an appropriate security model for solutions.
What is data loss prevention in Power Platform?
So friends, let’s discuss DLP… Within the Power Platform we have some functionality whereby we can implement these things called ‘Data loss prevention’ policies, which effectively act as walls around our platform which prevent users and makers accidentally pushing data in the wrong direction! They allow administrators to govern the connectors that can be used in the platform and which areas (environments) of the platform they can be used in. Simple right! Cool make sure ya know the thing then architects! 🫶
Exploring the functionality
So within DLP we basically create policies and assign connectors to various groups, and then assign those policies either tenant wide or to specific environments.
The groups that we can assign connectors to are ‘business’, ‘non-business’ and ‘blocked’. Now I’m hoping blocked is fairly self explanatory but the other too are used in this sense…
- Business – Connectors which hold and interact with business data only
- Non-Business – Connectors that interact with and access non-business data
Connectors from say the business category, can only be used with other connectors in that same category within an app or flow. So we couldn’t build an app that uses both business and non-business connectors within an environment with that relevant policy applied.
Solution architects role
So it’s super important for a solution architect to have a good understanding of DLP when it comes to implementing a security model for implementations. This could simply be platform governance that is being implemented or it could be requirements looked at as part of a solution implementation but it’s important that the structure is put in place with these first at the tenant level and exceptions are then granted later for connectors that need to be used in specific environments which have justification provided.
What’s coming up?
So friends stay tuned! In the next post we’ll look more closely at some of the principles we touched on in my last post around security roles but more closely focused on how they’re applied and more broadly how access to Dataverse is controlled. Stay tuned to learn about these topics and what a solution architect should be familiar with in these areas! 🚀