Security and Compliance in PowerApps and Flow

In my previous article, I’ve brought you closer to the main recipients of PowerApps and Microsoft Flow. In the third part I will take a closer look at the security management in PowerPlatform. And as I promised from the beginning: it will be honest. You will learn from me about things that you do not read in the documentation. Also when you should pay extra attention to security and compliance when working with PowerApps and Flow.

Disclaimer

When I started working on this part, I just wanted to discuss issues related to PowerApps and Flow security. With time it turned out that describing the security of a small piece of the service (eg connectors) it is very easy to inadvertently move several threads, each of which should be discussed a little bit more (eg is OAUTH2 secured communication safe? Is the public availability of our services and cloud a good idea?). Not even to say that the security and compliance tools are dependent on the license.

So finally I realized (I admit, a bit too late, hence this post appeared with a slight delay) that in order for this article not to turn into a book, it should be reduced. Therefore, I made the decision that I should only remain on issues related strictly to PowerPlatform. If any topic seems to you that could appear, and it isn’t, then you’re probably right. However, this was a conscious and necessary decision. If you think that it would be worth discussing a topic, let me know in a comment – I will definitely answer. If on the other hand you would like to take a full picture of security, then I recommend watching people like Tomasz Onyszko czy Kamil Bączyk, who in the area of ​​security are one of the best I know.

Security by Design

Going back to the merits.

The reason why I took care of this subject is simple: IT puts a lot of emphasis on security. And the reason is very simple: unauthorized access to data can result in huge property losses. In order not to look far in 2016, it turned out that information on a total of about 3 billion users leaked from the popular (back then) Yahoo site. This resulted in losses of $ 50 million in compensation, $ 350 million in the lower acquisition of Yahoo by Verizon and an additional $ 35 million for dragging the closure of the data leak. A total of $ 435m loss. But this is not the end of problems, because the company’s value is not only a hard currency. It’s also customers. You have been working on their trust for years and you can lose them in a moment. Making up for such a loss is very difficult and very expensive.

Trust is the currency of the future

And that’s why IT engineers put security first. Microsoft even says that it designs its services in such a way that they will be safe first, and then they design the rest: Security-by-design . The questions that appeared in the first part of this series of posts are a living example of the inquisitiveness that engineers apply when it comes to security and management, because they are aware of possible consequences.

Security and Governance in PowerApps and Flow

Security and Governance of solution built with based on PowerPlatform I’ll split on following parts:

  1. Licenses
  2. Connectors
  3. User Context
  4. App sharing & versioning
  5. Environments & Data Policies

Below I will briefly describe what a given form of security is and what to watch out for when using it. However, as I would like to avoid entering into technical nuances, I will refer to more extensive sources.

Licenses

Licenses are a way to assign user permissions to any work with a given platform. In the Office365 admin panel, as long as we have the appropriate permissions, we can easily assign or take away licenses for the product or application to the user.

What to watch out

Licenses specify general access to the application, but do not define the level of permissions (read-only, edit, delete etc.). When allocating licenses to someone remember to ensure the appropriate level of rights in the application (the service) itself .

Connectors

As I described the idea of connectors in thesecond part of this seriesit is one of the foundations of PowerPlatform. PowerApps and Flow users have access to over 200 connectors. And if that was not enough, they can build their own connector or use HTTP connectors to connect to any REST / GRAPH API supporting service

The use of such connectors is very simple and easily accessible. After selecting any connector, the user will have access to its methods. Of course, only to those that the provider implemented. However, the supplier is obliged to ensure that the connector provides the appropriate quality of security (authentication), support and SLA. What is important, the supplier must also prove that he owns the website to which the published connector connects. Thanks to this, there will not be a situation when suddenly third companies will start racing for the title of the best supplier of connectors, producing 10 of the same connections, thus littering the collection of connectors.

WHAT TO WATCH OUT

Connectors in the heads of many give a question whether, besides being easy, they are also safe? While safe can mean a lot:

  • Is the data sent using them will not be intercepted and changed along the way?
  • Will the data reach where we want it to go?
  • How to control from which a connector can a given user use?
  • Where can one find the call logs of a given connector?

First of all, communication with the use of connectors is definitely secure. For this purpose Microsoft enforces the use of proven standards to secure transmission data.

However, at the moment the connectors have a modest layer of managing rights to them and putting down logs. For example, we can define who can create applications (and thus use connectors), but we can not define who the connectors can be used. Similarly, we will not find options to define whiteliste URLs for HTTP connectors or to extract logs containing the URL and body connections made.

Communication with the use of connectors is secure, but their governance is modest…yet

User Context

Basically, this topic fits the previous fragment with connectors, but I would like it to sound good – the user working with connectors works ONLY in his own context. In other words, when working with, for example, PowerApps, you should think of a view of the data to which the user has access. If you should not have something to do or the application would have to work in the context of an account with higher rights, then I do not recommend doing it with PowerApps.

However, theory is just a theory. In life, as everyone knows. I have seen different approaches in IT myself. And I’m not surprised by the serious and large companies that used the usual excel file as their database. Because at the end of the day the effect counts (read: money), not best practices and safe architecture (we only care about it when it starts to threaten the “effect”;)). So sometimes it happens that:

  • you may need to carry out the operation on higher privileges. Then, for this purpose, you can apply the Flow trick that I wrote in this article.
  • based on the group O365 to which the user belongs, you want to limit the visibility of certain controls on the screen. Then you can use the Office365 groups connector available in PowerApps. If the view is limited based on the SharePoint group, the matter gets a bit complicated, but with the help of Flow and Graph API there is a way to go.

If you use PowerApps to control access (eg by conditionally hiding the controls), remember that the user will still have access to the data in the source (eg on the SharePoint list)

WHAT TO WATCH OUT

Some connectors do not use the user context and require a service account – an example is the example of SQL connector. Then, when using the application, the user’s context is not taken into account. The connection works within the context of the given service account. This means that if the user had the additional ability to create an application, he could use the connector to get to any board or view to which the service account has access (!). It is worth remembering. But there is a way shown by PowerApps guru – Shane Young. This method uses an additional environment (so-called environment) and appropriate permissions on it. More in the video below:

App sharing & versioning

For each application, you can define users who can use it and edit it.

In the above image, pay attention to the information at the co-owner checkbox: even if we add the user as co-owner, he will not be able to delete the application or change the owner.

On this occasion, we can observe one more interesting thing – the CDS connector has an additional option of role management:

CDS has extra permissions model (security roles) . Only CDS.

Each application, apart from the sharing option, also has a versioning mechanism.

Each time the application is saved, it will leave a separate entry in the repository. Thanks to this, we can go back to any version at any time. In addition, the publicly available version for everyone is marked with the appropriate label. So the versioning mechanism allows you to sleep peacefully, that if any of the Co-owners spoils in the application, everything will be able to recover.

WHAT TO WATCH OUT

As I wrote, co-owers can not delete the PowerApps application – only owner can do it. But if he does, then there is NO way to reverse it. So it is worth to export your application from time to time in a safe place.

Export full versions of your applications. If you ever lose them for some reason, the exported packages will be your last resort.

Environments & Data Policies

Environment, are special containers for applications and connectors under tenant. Tenant can have many environments, and each environment can contain a lot of applications and connectors. What is important, environments do not share content with each other, and what’s more, each of them can have a unique definition of macros and users. Users can use the content of the environment. Makeers can create their own apps in it. It is easy to imagine the example architecture of environments in the organization: production, testing and development.

In addition to environment permissions, you can also define Data Policies, which are special rules about which connectors can share information with each other.

For the above example, no PowerApps or Flow application can display any of the “Business data only” connectors and the connector from the “No business data allowed” group at the same time. When this happens, we will see an error while trying to add an unacceptable connector

What’s important – the created policy works immediately on all applications. Where they find unlicensed connectors, they simply stop reporting data. In the case of Flow, they will be turned off.

Environments are containers for applications and connectors in the organization. The minimum recommended set of environments is Production and Test.

WHAT TO WATCH OUT

As in the case of connectors, governance of environments and policies is still modest. And sometimes it would be useful to be able to exclude certain connectors from use. Or at least limit the people who can use them. Because the division into business data and non-business data alone does not protect the organization from the fact that someone builds 2 apps and combines them, for example, with an excel file. So if you put the utmost caution to data security, you can still give yourself a moment to improve the above mentioned tools. As I observe Microsoft’s actions, it is a matter of time when the tools for governance and security will be upheld.

So if there are any dangers to be considered with each of the above options, is there any sense now to use PowerApps and Flow?

PowerPlatform is not a cure for everything

If you’ve read my previous entry, you know that PowerApps and Flow are not meant to replace 100% of solutions. They are to replace 80% of these small and simple applications that accelerate daily work, while saving time and energy for programmers. Thanks to this, they can deal with more difficult cases than the hundredth implementation of the task list. Because knowing life will not be a standard implementation anyway. This time, the requirements will be difficult for someone from marketing who will come up with the idea that he wants to have integration with this service whose developer has just left the company and you will need to learn this site first. That is a month of work … unless the quote is raised two times to put an intern behind the keyboard. And then there will only be moans, shock and disbelief that a simple application to organize meetings took 3 times as much and cost 5x more than initially assumed (intern makes mistakes, mistakes must be corrected).

The art of choice

The solutions built on the basis of low-code platforms are therefore about knowledge, knowledge of the possibilities of various ready-made services (not only Microsoft), understanding of their flexibility and, above all, understanding of business. And paraphrasing the famous joke (choose 2 of 3ech: fast, cheap, good), projects in a company operating at the interface between business and IT would like to be done by a person who:

  1. He understands business well
  2. Has a tooling understanding
  3. He has specialist technical skills

Choose 2 of the above.

The art of compromise

PowerApps and Microsoft Flow is a lever that does not give the user more than he could, but allows him to do things more easily and on a larger scale. This, of course, is a compromise between work streamlining and configurability. Between trust and control. But isn’t it a fundamental trend in IT?. If this were not the case, then we would still write in assembler and we would not create languages that would allow us to write faster and easier, frameworks implementing complex operations using one method, and we would not build Open Source solutions. The demand for programmers is not diminishing, so solutions are built up as simple as possible to be adopted by new adepts.

My point is that programmers should be more in number (thus creates a natural stratification). And they themselves are relieved of simple tasks (especially when it can be done by someone else just as quickly and not worse).

Summarizing

PowerPlatform gives you some control and information security mechanisms. So far, it’s still modest, but with time it will certainly be developed (as announced during MBAS2019). But I doubt that they will reach the level of configurability and control that gives us a written inhouse .NET application embedded on IIS installed on our on-premis server. However, it seems to me that PowerApps and Flow does not even start on such a race against full code .NET app. It is like a fast agile car that you can take to move around a city. And if you want to go to war, take a tank.