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
Today I’m going to speak about another important Best practice, Tips and Tricks that you need to take into consideration while you are designing and maintaining your business processes (Logic Apps): Protect your Logic Apps.
#19 Protect your Logic Apps
Security is a hot and important topic these days, especially with increasingly 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. 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.
Using API Management to expose the Logic App
Of course, that are HTTP triggered based. You can only expose an Azure Logic App that exposes an HTTP endpoint on your APIM and are inside your Azure Subscription (the same subscription in which your APIM is created). And this way, no one is calling our Logic App directly, but instead, all calls need to go through API Management.
When you expose Logic Apps Consumption or Standard (without VNet integration) using an HTTP Request trigger, it is a publicly exposed endpoint. Native, the endpoint is secured via a couple of mechanisms, including HTTPs and a SAS token. Every request endpoint on a logic app has a Shared Access Signature (SAS) in the endpoint’s URL, which follows this format:
https://<request-endpoint-URI>sp=<permissions>sv=<SAS-version>sig=<signature>
Each URL contains the sp, sv, and sig query parameter as described in this table:
sp |
Specifies permissions for the allowed HTTP methods to use. |
sv |
Specifies the SAS version to use for generating the signature. |
sig |
Specifies the signature to use for authenticating access to the trigger. This signature is generated by using the SHA256 algorithm with a secret access key on all the URL paths and properties. This key is kept encrypted, stored with the logic app, and is never exposed or published. Your logic app authorizes only triggers with a valid signature created with the secret key. |
The main purpose of the SAS token associated with our Logic App is for Authentication and Authorization. But having those details in the URL can be problematic. Anyone who knows these token details can easily be sent inappropriate requests.
The API Management out-of-the-box Access control configuration settings will provide additional security measures beyond IP address filtering. We are also able to take advantage of additional capabilities by placing Azure API Management (APIM) in front of our Logic Apps. Once our Logic App has been ingested, we can apply additional policies to our APIM configuration, including transformations, rate limiting, caching, IP filters, and additional security schemes, beyond the SAS token that Logic Apps provide, including Basic, OAuth 2.0 and Azure Active Directory also adding the possibility to use APIM Subscriptions to control who can invoke them.
Not all are advantages, of course. One of the disadvantages of having API Management in front of our Logic Apps is, of course, additional costs.
I’m not going to explain here how you can expose your Logic Apps on API Management because I already wrote a series of articles explaining in details these tasks. You can read and learn more about this topic here:
- How to Expose and protect Logic App using Azure API Management (Part 1) – Exposing the Logic App
- How to Expose and protect Logic App using Azure API Management (Part 3) – Exposing multiple Logic Apps in a single API
Implement IP Addressing Restriction
You can add further security to our Logic Apps by restricting or allowing specific IP addresses. This is a good policy, for example, to implement with the previous one: Using API Management to expose the Logic App.
Azure Logic Apps allow you to limit access to not only trigger the Logic Apps but also to the inputs and outputs in your logic app’s run history so that only requests from specific IP address ranges can view that data. For example, to block anyone from accessing inputs and outputs, you can specify the following:
- An IP address range such as 192.168.1.73-192.168.1.100 (xxx.xxx.xxx.xxx-xxx.xxx.xxx.xxx).
- Or a Classless Inter-Domain Routing (CIDR) format like 192.168.1.73/32 (xxx.xxx.xxx.xxx/xx)
Only a person with administrator permissions can remove this restriction, which provides the possibility for “just-in-time” access to your logic app’s data. You can specify the IP ranges to restrict either by using the Azure portal or in an Azure Resource Manager template that you use for Logic App deployment.
Once again, I’m not going to explain here how you can implement IP Addressing restrictions on our Logic Apps on API Management because I already wrote a series of articles explaining these tasks in detail. You can read and learn more about this topic here:
Stay tuned for the following Logic App Best practices, Tips, and Tricks.
