PowerApps security considerations

In this blog post within this series, we have focused on points related to the communication from PowerApps to the backend database: https://rb.gy/9ac480

In this last blog post that wraps up this series, we will be covering some points worth keeping in mind when building applications with PowerApps, in relation to security.

Some of the applications that we produce to be used in the business, will have confidential data or sensitive data that should not be shared across departments.

Depending on how the backend is set up, the tables having these sensitive data might be in the same database. For example, ERP solutions can have Company Accounts data, Customer related data and Inventory related data all in the same database, maybe under different schemas – but still part of the same database.

Now let’s say we are about to create a PowerApps solution to maintain Customer information. However, as part of the organization policy, this information should not be shared across other departments apart from the intended users.

We are developing the application in the common organizational PowerApps environment. This is the single default environment that is automatically generated by PowerApps in every tenancy and which is automatically shared and available by all users in that tenant. This is normally distinguishable by the text “(default)” after the environment name:

When the application is being developed, the SQL datasource needs to be added to the application. The specific Customers tables that are required as part of this application are specifically added, with none of the others being part of the application. A service login account, which has access to the entire database, has been used to log in and access the datasource within the PowerApps. And as required, this connection has the credentials saved in the application itself, so that the user can use the application and get the required information. This also avoids the need to add or give access to each specific user to the database itself.

Since we have added the connection to the application only, and moreover having included only the required tables in that application, we would assume that security is in control. Don’t assume that only the users who have access to the application can see the information, since that is what is visible from inside the application itself. SINCE…

For every environment, PowerApps retains the list of connections made to any one of its applications – and this list can be accessed before loading the application itself, when inside the environment.

And you will note that if you are to create a new application inside that specific environment, the user is able to choose from the already existing connections in that environment. Moreover, since this will be the same connection that is being used in the original application that it has been added to, it will have the credentials saved. Now the good news is, you cannot see the password. BUT…

If you are to create a new application and add an existing connection, you do not need to re-input the credentials, and could hence add the same connection to the datasource. Now we have said, that the default environment is common to all users in the tenancy. And this means, that any user, that is willing to create a new application inside that default environment is going to have access to that connection and can use it inside her/his new application. So maybe the user could access the Customer tables that have been used inside that application? NOT ONLY…

That connection would be to the database and not table specific. Thus, when someone is going to add the existing connection (without having to re-input credentials) to the new application, they would be able to choose any other table within the same database. And this might hence turn into a security flaw or loop hole.

There are some measures that one can take to avoid and/or mitigate such potential flaws.

1. Not using default environment to build and share applications from. Other non-default environments include isolation boundaries. This means it will be treated as a separate, containerized space, that does not communicate with other environments, and cannot use other Environment’s resources. And it also allows the possibility to set Environment Admins and Environment Makers from the Admin Centre.This is in addition to setting access for application users.  The Environment Admin is the top level, with administrative rights to also add other users in addition to application creation and other rights – and allows the Environment to be see in Admin Centre tab.
   
   The environment Maker will not see the environment in the Admin Centre tab, but can access it from the top-right environment dropdown and can create new resources within it.
   Hence in the eventuality that we need to ensure that the users do not have access to connections in the environment, we can just add them as application users, and not in Environment Admin or Maker. This will only give them access to the application and not to the environment level. And likewise, the Environment Admin or Maker does not technically have to have access to all the applications within the environment. But if they are Environment Admins, would still be able to control the application/s within. And if an application is created and not shared with the Environment Admin, the Environment Admin can still share it with himself/herself, and give himself/herself edit control (from Admin Centre). Environment Makers will only see applications they created or that are shared with them.If someone is added as a co-owner on an application, they might still see the environment name that the application is in when they open the application for editing. But they can only apply changes to the application itself, and not to anything else in the environment (which will be restricted and hidden for them). The environment will not be shown to them in the Admin Centre list for configurations.
2. Another alternative could be to create a specific login, user and role at the database level, and grant access to specific schemas or tables that you are comfortable with the applications users to see/ access.This option still needs to be applied in caution if done in replacement of the other option. Since all departments might be accessing the default environment, what is fine to be seen and access by the application users, can still be unsafe to be shared by other environment users. However, as a best practice, doing this in conjunction with a new non-default environment would help further in security control.In all cases, keep in mind, that filtering at application level, with the datasource connection being unfiltered, could still pose a risk. Likewise using the same user that has access to all tables, and just selecting the tables in PowerApps connections (rather than granting access to roles at SQL level) has to be done cautiously especially in default environment.
3. Another way is to make use of Data Loss Prevention policies configured in the Admin Centre. This allows a way of combining and/or segregating a set of connections within business and non-business data groups. For example, if certain connections are targeting external audience, like social media or marketing automation platforms (non-business data), it might be safer to contain these separately from the sensitive internal connections (business data). This way the connections cannot be used in conjunction with a risk of compromising data safety. Until policies are set, all connections are grouped as non-business data by default, within one group. Attempting to use a connection classified as business data with one classified as non-business data within a Data Loss Prevention policy, in one application for that environment, will result in an error (on adding the second connection) as below:
   
   Only Environment Admins, admin of Azure AD tenancy, or Office 365 Global Admin will have access to create these policies, and the policies could be set to apply to only one, all environments except specifics or all environments. With this said, these policies will not be preferred over and override any tenant-wide policies.

This brings to an end this blog series. Feel free to get in touch or exchange any ideas with us or views – either on the comments below or even on twitter: @bonello_jason