Welcome again to another Logic Apps Best practices, Tips, and Tricks. In my previous blog posts, I talked about some of the most essential best practices you should have while working with the Azure Logic App:
And some tips and tricks:
- #4 Using Scopes
- #5 Delete comments
- #6 Error handling configure run after settings
- #7 Learn from failures
- #8 Expressions nightmare
- #9 Control your connectors (API connections)
- #10 Fix connectors (or API connections)
- #11 Connectors naming convention
- #12 Choose your developer tools properly
- #13 Logic App (Standard) vs (Consumption)
- #14 Implement good governance policies
- #15 get the error message
- #16 roll back to a previous version of an Azure Logic App Consumption
- #17 using other HTTP Methods then POST
- #18 Foreach Parallelism
- #19 Protect your Logic Apps (Part I) – Using API Management to expose the Logic App and Implement IP Addressing Restriction
Today I’m going to continue to speak about how to Protect your Logic Apps. But today we are going to address how you can Secure data in the run history by using obfuscation.
Protect your Logic Apps
Once again, security is a hot and essential topic, especially with increasing cyber attacks happening each day, driving companies crazy. But, it was always an important topic that, most of the time, companies didn’t invest too much time and effort into. Unfortunately, sometimes we feel that this subject when from 8 to 80! And now companies sometimes exaggerate security since they don’t dominate the topic as you would expect, so the old logic is implemented: better safe than sorry.
Logic Apps are not different from anything else. We should and need to guarantee security in our processes. There are several ways to secure your Logic Apps. We have seen in my previous post:
- How to expose the Logic App in API Management to guarantee another layer of security on top of Logic Apps.
- And how to implement IP restrictions to accept only requests from the API Management.
Today we will address another vital security topic: How to use obfuscation to secure data in the run history.
Secure data in the run history by using obfuscation
It is quite normal to use Azure Key Vault to store secrets like usernames and passwords or keys. I mention Key Vault because it is where we usually keep these private values that need to be secure. After all, they can provide security breaches and unauthorized access to systems or confidential data. Still, it can be other services like SQL database, App Settings, and so on. In this sample, we are going to use Key Vault.
But people need to remember that by default, these values are visible for all persons who have access to the run history of the Logic Apps.
So, we spend a lot of time identifying all the critical information that needs to be kept and stored encrypted, and just a few people can access it. The developers often don’t have access to the Key Vault in production environments or access to these pieces of information. And in a few minutes, developers can destroy all the security – hehe!
You may say: yes, Sandro, but you need to have access to the Logic App run history! We can limit access to the run history!
Yes, I know all of that, and it is true. Azure Logic Apps has the following specific roles:
- Logic App Contributor: This lets you manage logic apps, but you can’t change access to them.
- Logic App Operator: This lets you read, enable, and disable logic apps, but you can’t edit or update them.
- Contributor: Grants full access to manage all resources but doesn’t allow you to assign roles in Azure RBAC, manage assignments in Azure Blueprints, or share image galleries.
The same doesn’t apply to Logic App Standard. Microsoft is still working to have more fine access to them. But there is a more substantial probability that things may fail in production at some point in time or especially on the first days after going live. And access to the Run History is usually given to the team of developers or people that need to monitor these integrations – using, for example, Privileged Identity Management for a few hours – to go and see why or to have a better overview of why it is failing. At that point in time, they will have access to this confidential information.
Just a note that: During a Logic App run, all the data is encrypted during transit by using Transport Layer Security (TLS) and at rest. You can check out more here: Secure access and data in Azure Logic Apps.
Luckily for us, Logic App allows us to secure these values by using a feature called obfuscation.
Azure Logic App obfuscation feature allows us to secure the inputs and outputs of a trigger or action inside our Logic App. When you obscure the inputs or outputs on a trigger or action, Azure Logic Apps doesn’t send the secured data to Azure Log Analytics. Also, you can’t add tracked properties to that trigger or action for monitoring. Nevertheless, when you obscure the inputs or outputs on a trigger or action:
- The data is still transferred “normally” to other actions, which means that you can use and link them to other actions below.
- Because these data are not sent to Azure Log Analytics, that means that you cannot see them visibly in the Logic App runs.
In our scenario, you want to protect our password, so we need at least to obscure the output of the Key Vault action. To do that, we need to:
- On the Get Secret action, click on the three dots (…) and select Settings.
- On the Settings panel, enable the Secure Outputs option.
- If we want to be even more secure, no one needs to know what is the secret name; otherwise, if they gain access to the Key Vault, they can easily find where to look – of course, in this situation, you are with a different and more critical security breach. In this case, we can also obscure the inputs of that action by enabling the Secure Inputs option.
- Click Done.
Now, if we rerun the Logic App, we will see that we no longer have access to this information on the run history.
Now another thing that you need to be aware of is that we have secured that confidential information on the Get secret action, and as I mentioned above, this data will still be transferred “normally” to other actions. That means if we use this information in other actions you will still not see this information in the inputs of that action or actions… but… and this is what is important for you to know. That private information can appear again in an insecure way on the output of that action. An excellent example of that is we set a variable with that value:
- We will see that the input content is not available
- but we will see the password and the key vault name in the output of that action
Important, you don’t use support Variables to store confidential information because we cannot use obfuscation in Variables. In that cases, we can use a Compose action to achieve the same goal, and in there, we can use obfuscation.
So it is important for developers to have best practices on how to use these fields inside the Logic App,
Stay tuned for the following Logic App Best practices, Tips, and Tricks.