Power Platform Security: Back to basics

It’s a new year, let’s start afresh. Following the end of my ALM blog series, I figured it was ideal to start a new series in line with a topic I have recently found myself working on quite a lot. Security within the Power Platform.

Security within Power Platform

When it comes to Dataverse, one of its many attributes that sticks out is its complex security layers that govern user privileges, data access, and data ownership. Unlike a standard database like MS SQL, users are not reliant on hidden, complex code governing RBAC models on the front-end UI side to govern data security or require specific credentials that limit direct access to a database. When it comes to the Power Platform, Dataverse and Power Platform security extends data protection much further than just data access levels. We’re talking about data segmentation, data ownership, data hierarchy, IP restrictions, etc. We’re entering a whole new world.

Security within the Power Platform is not something that just gets pieced together either. There are a lot of moving parts within Dataverse, including product connections and admin governance, that drive a thorough and robust security model.

In this series, I plan to touch on numerous topics related to security within the Power Platform. This includes topics such as user access, data ownership, and complex RBAC models.

Various Security Concepts

We currently have a variety of security concepts to make use of when developing Power Platform solutions. There’s also a whole other side related to adoption before even making use of or developing solutions in an environment.

To give you an idea of the variety, let’s breakdown some of the basic concepts that most of us are probably already familiar with:

Users

The simplest place to start is users. Within the admin portal, admins can manually add AAD users to an environment, granting a user the ability to now access that specific environment. Admins can also remove users from an environment, ultimately revoking their access. This approach is a very manual way of maintaining user access. Once you have access to an environment, users can be granted further access to apps and data.

If you don’t have access to an environment, you will most likely be presented with this error:

Environment Security Groups

Let’s take a slight step backwards to the moment before an environment exists. When creating a new environment, one of the tasks an admin is prompted with is to provide an AAD security group for the environment. When you assign a security group to an environment, the members within that AAD group are then synced to the environment and are granted access. You can assign no security group to an environment; however, by applying a security group, you have a centralised method to grant users access to various environments through AAD.

If your company has an onboarding process, it’s most likely that new users in AAD are auto-assigned to various AAD groups anyway. By aligning your environment access to security groups, you start to streamline user management for your general environments and minimise unnecessary manual intervention. There’s a lot more to cover in this piece in the future.

Business Units

A really fun topic around security is business units and record ownership. Business units practically allow us to segment departmental, organisational or even structural data.

Say you have various departments in your organisation, all having separate accounts, customers, and products. By segmenting these departments into separate business units, each department’s data is secured on a business unit level, preventing external business unit users from accessing that data unless the data’s owning business unit is changed, shared, or access is granted through a security role level.

Teams

Teams further drive user access across business units with security roles and user assignments. When using teams driven by AAD groups, you can also start to streamline user access management. Similar to having an AAD security group assigned to an environment, granting users access to necessary business units and security roles can be driven by teams and managed through AAD.

Teams also open up further collaboration when it comes to data ownership.

Security Roles

Lastly, we touch on security roles. With security roles, we are able to set complex data privileges that grant users permissions to view, create, edit, delete, etc. records within tables.

Additionally, security roles accommodate more than just data privileges, they expand into complex data access levels aligning with business units, teams, and record ownership. Following a structured data ownership model and aligning with the principle of least privilege (PoLP), security roles allow you to start releasing data access slowly when required.

Combined with AAD, teams, and business units, you can start building a phenomenal security model.

Adding Users to an Environment

Let’s jump straight into it, shall we?

In this first scenario, we are simply adding new users to an environment that now requires access to develop a POC solution. Following the manual method of doing so, the first step would be to navigate to the Admin portal (www.admin.powerplatform.com). Under the section Environments, select the appropriate environment, and you should now see a page displaying information about the selected environment.

On the far-left side, there will be an Access section with the option Users listed. If you click on the See All button, you will be redirected to a list of users that currently have access to the environment. To add a new user to this environment, simply click on Add User in the above banner and search for the user you wish to add. Once selected, click on the Add button.

You will then be asked to select preferred security roles for this new user. Being that the users will be developing a POC, you can give them the Basic User and System Customizer roles for now. Once granted, you’re done!

You have successfully added a new user to the environment. Fairly straight, right? This method works when dealing with smaller requests; however, in situations where you are dealing with a couple of hundred users, this method may get a bit tiresome. In the next post, we’ll dive into Environment AAD Security Groups and how we can streamline user access.

Conclusion

Just scraping the surface of Power Platform security, we can already see the complexity of how various security aspects of the Power Platform ultimately start to flow with each other. We can also see that some methods may work at certain times, whereas some methods may need to be optimised for larger scale solutions. It’s great to set up a few business units and maybe create some security groups, but the next step is to understand how these concepts feed into each other, complement each other, and, more importantly, contribute to your larger security model.

This is just the start. Think bigger. I’m talking column security, DLP policies, hierarchy models, record assignment, RBAC models, the principle of least privilege (PoLP), etc.

We’re heading back to basics, but are venturing towards a secure future