Logic Apps are awesome, creating “no code” workflows to connect systems or orchestrate a process is a great way to integrate systems in your datacenter or in Azure. Looking at how to secure them is crucial for a production ready environment.

This a long article. So grab a drink, a snack and read on…

Introduction – The customer and their requirements

Working recently with a customer that had the requirement to process images, video, and digital text files. The process required their team to manually sort the large volumes of data; sorting, tagging, and organizing that data for another team to process. The large amount of data made it difficult for the team to not only sort and organize the files, but then also caused issues with referencing the data at a later point in time.

The customer was looking to leverage Logic Apps to build secure data enrichment workflows and allow them to interface with multiple secure PaaS and SaaS offerings within Azure. This would help them to accelerate processing their data, but also gain better understanding as to the content in their data. The project was looking to process video and image data using Logic Apps to retrieve data from media to better identify people, scenarios and locations.

The customers’ data was all classed as ‘sensitive data’, thus requiring the use of secure transit and storage of their data. Data could not persist outside of the system, as well as securing access to the sensitive data to only specific individuals. The concerns regarding the security of the system, as well as the concerns around data at rest and in transit shaped the design of the solution.

Logic Apps allow you to persist data in a storage container, or database, accessing it through its corresponding connectors. Logic Apps rely on Azure Storage to store data, meaning that the data is automatically encrypted at rest (enabled by default on Azure Storage). Azure Storage also uses managed keys to encrypt the data, the encryption provided the level of security and compliance required by Contoso.

Knowledge of how Logic Apps work and how to secure them was fundamental to the success of this project.

Technical Solution

The solution designed and delivered for the customer aimed at building an orchestrated workflow that allowed for the transacting of secure data. The workflow system would also need to interact with several PaaS (Platform as a Service) and SaaS (Software as a Service) entities in a completely secure manner.

The decision to use Logic Apps was based on the following:

• Contoso’s ability to maintain the solution with ease
• The existing customer coding experience and cloud familiarity
• The ease of designing, maintaining and modifying a Logic App

While as a team we did review other technical options, we went with Logic Apps in the end. My colleague Martin Kearn wrote an awesome blog comparing Logic Apps to Durable Functions.

Architecture

The diagram below displays the high-level workflow of the Logic Apps, taking note that 4 Logic Apps were utilized, as well as functions to supplement. We’re going to focus on the Logic Apps, other resources are referenced to note the interaction and overall workflow.

Diagram 1 – Logic App Workflow Overview

The details of the design decisions will be discussed in more detail below.

Securing a Logic App

There are several methods that you can use to secure your Logic Apps, the decision on what security features to use is down entirely to the design and the requirements of your particular solution. I have walked you through an overview of the various options are below (and can be referenced here):

Implement an ISE (Isolated Service Environment)

An ISE is also known as a single tenant Logic App. It provides a dedicated environment (instead of a shared environment) in which to build and maintain the Logic Apps, as well as the storage component. It is highly recommended to do when there is a requirement to integrate your Logic App into a VNet. The ISE isolates your environment away from the shared platform model, providing your resources protection from other tenants in the multi-tenanted model. With this option there is a cost associated to having this configured.

Use of HTTP Triggers and TLS

Inbound calls to a Logic App can be configured using a request-based trigger, these triggers can use an HTTP Webhook. These triggers are secured with TLS (Transport Layer Security), creating a secure handshake.

Manage Endpoint URLs

When a Logic App is created, it generates an endpoint url that allows you to connect to the Logic App. Within each URL is a Shared Access Signature (SAS), these allow you to securely access the Logic Apps’ URL after creation. To further secure the endpoint on the Logic App you can regenerate the access keys, create an expiring URL, or create a URL with a primary and secondary key.

Azure Active Directory Open Authentication (Azure AD OAuth)

Azure AD OAuth allows the definition of an authorization policy against the Azure Logic Apps using tokens. Authorizations can be added to HTTP requests and trigger outputs.

API Management to expose the Logic App

Implementing the Azure API Management service can expose a private or public endpoint for the Logic App, exposing it as an API. This comes with additional feature benefits such monitoring, security polices and authorization protocols (Azure AD OAuth, client certificate etc).

 IP Addressing Restriction

Logic Apps have the ability to limit which clients can call the and trigger the Logic App, allowing specification of IP Addresses.

Abstract the Logic App Designer

Using Azure RBAC (Role-Based Access Control) there is an ability assign customized roles to your users in the Azure subscription. With this is the ability to obfuscate the Designer from users, preventing visibility to items such as run history data, connectors, and input/outputs from the Azure Logic App.

Secure Parameters

When using secrets or making a Logic App deployable across different environments, implementing the use of parameters allows not only the ability to re-use a Logic App, but also to secure the secrets that are in use. The Logic App defines its parameters in the ‘parameters’ file, calls them during the run and it means that the resource definition is not accessible when viewing the resource after deployment (or providing access in plain text). To further secure secrets, the use of Azure Key Vault can be integrated into the solution.

Authenticate to connectors

Each type of available connector to an Azure Logic App uses some form of authentication, this allows secure access to the other resources and secures transfer of data (if required).

Solution Detail and Security Hardening

One of the key deliverables in this project was securing the data. This included securing the data at rest but also the transfer of data. The securing of the Logic Apps relied on several technologies to ensure the security standards were obtained.

The Logic Apps were secured using the following technologies:

• Restricting Inbound/Outbound IP addressing from the Logic Apps to storage
• Secure TLS through HTTP triggers
• Securing Parameters
• Active Directory authentication
• SAS URI for secure storage access
• Monitoring for end to end visibility

Networking, Routing and Allow Lists

The use of VNets is not supported when deploying Logic Apps unless Logic Apps are deployed to an ISE (Integrated Service Environment). This would have allowed the customer to keep all of their resources in the same region, but was cost prohibitive to the project. While there were some challenges to overcome in the routing configuration, it fully accomplished the network routing and security requirements that were set forth by the customer.

The Logic Apps had a requirement to send/receive data to the storage accounts as well as other services (Video Indexer and Cognitive services, etc.). There was a requirement to ensure that traffic did not access resources unless approved, the use of private endpoints for the storage accounts  and IP allow lists were used to ensure that the storage account was not publicly accessible. For the storage account, enabling “Allow trusted Microsoft Services” was not feasible, because the customer wanted granular control for specific services to access their data. This could have been done using Service Tags, but the Azure Storage Account firewall does not support service tags, which led the project team to use IP allow lists.

For the wider project, the customer required the use of VNets to allow for network segmentation between resources and deployment environments. A challenge that presented itself from this, was that Azure’s SDN (Software Defined Network) on the backbone did not allow the Logic Apps and the storage accounts to reside in the same region. The limitation arises from the use of the IP configuration on the storage firewall. Logic Apps have a limitation on the outbound IP address that is created when the resource is deployed.

Local communication in the physical datacenter SDN prevents the use of internal IP allow lists as documented here. When a Logic App was deployed, it would generate an internal IP address to region (ex. 10.10.10.x). storage account by default used a ‘deny all’ rule, it is not possible to add an IP address in the same range to the allow list on the firewall.

The workaround was found in the Azure documentation, connecting to storage behind a firewall. The article advised that the Logic Apps and the storage accounts must be placed in different regions. When a Logic App is deployed, the outbound IP address generated can be added to the allow list for the connectors of the Logic App. In our specific case, a Logic App would be deployed, the outbound IP addresses listed would then be added to the allow list for the storage account that it required access to. Resulting in a secure connection and an explicit allow list to the resources required.

HTTP Actions

Several of the Logic Apps deployed in this project were configured with HTTP triggered endpoints. By using an HTTP triggered endpoint, this enabled TLS and fully supported encryption.

To access external services located outside Azure, secure authentication was required. The primary example is the use of video indexer to the video workflow logic app. Video indexer (VI) is a publicly facing service. This required the use of a generated access token to allow a secure authentication from the logic app to the Video Indexer service, allowing for a secure transaction of data.

In the Logic App deployment, we were able to create the connector from the Logic App to the Video Indexer service by securely storing and calling the URL, VI account ID, and access token for the connector. The diagram referenced here is an example of the video workflow that was deployed.

Example of the video workflow

Service Bus Connector

The architecture diagram displays the use of the Azure Service Bus service, which was placed in front of the ‘orchestration workflow’ Logic App.

The Service Bus provided a connector to the workflow allowing it to use it as a queue for incoming messages. This allowed the data to be queued for the Logic App, allowing for traceability of each incoming message. The Service Bus could only be accessed when triggered from the specific service.  Azure Service Bus also supports SAS (Shared Access Signature) and Active Directory authentication.

Implementing an Azure Service Bus prevents from having to implement complex try/catch logic or losing incoming messages/data into the Logic App. Configuring a Servics Bus allows the reliable processing of messages which prevents to loss of data in the transaction which could have major impact to the integrity of the data being processed.

Securing Parameters

When generating a Logic App from the Azure portal there is a parameters configuration that must be considered. Since the team was looking to not only secure the logic app itself, but also its hard coded data. Another driving factor was that we were deploying these Logic Apps into multiple environments for the customer. When a logic app template is exported the parameters are exposed, to secure this, the parameters were defined as ‘securestring’ or ‘secureobject’ types. Examples of parameters we needed to pass securely are authentication keys for Azure Cognitive Services or Azure Functions.

The parameters from a logic app workflow also had the requirement to be referenced by Terraform for deployment. Securing the parameters was paramount not only when a developer exported a template, but also in the reference code in the repository. To further secure the logic app, the workflow can be obfuscated in the workflow visualizer from within the Azure Portal. Although that was not done during this project as access was locked down to the required developers and the UI was required for Logic App design and export.

All secrets in the project were stored in Azure Key Vault. Each deployment environment maintained its own Key Vault with the secrets for that environment. This is a requirement that was set forth by the customer to ensure the secrets and environments were completely segmented from each other. While Key Vault connectors can be configured from within the Logic App workflow, we opted to secure our parameters and then had to pass them into Terraform upon deployment.

Azure Active Directory (RBAC)

Azure Active Directory uses RBAC (Role Based Access Control) was leveraged throughout the customer project. Access to the Logic Apps were controlled using RBAC, with least amount of privileged access granted. RBAC was used to define access requirements to the Azure Portal for the users. The use of RBAC to further abstract access to the Logic Apps was not feasible during the project. As the Logic Apps Designer was required to modify and maintain them in the developer environment, there was not an option (nor requirement) to further restrict access. However, in the production environment, all access was restricted. Another option could have been to require developers to modify the Logic Apps from the VSCode Logic Apps extension. This was not feasible during the project as the developer environment ran from a Devcontainer, the Logics Apps VSCode extension did not provide the user experience required.

In the deployment pipeline an Azure Service Principal was used to authenticate from the pipeline to the resources. Keeping the access from all aspects controlled using RBAC throughout the project.

SAS URL

Every time Logic App is triggered it generates a SAS (Shared Access Signature) URL as an output. This output was saved as a parameter then it was passed into the deployment variables required by Terraform, saving the URL each time a new deployment took place. A new URL was generated when a Logic App was deployed. A key design decision was made to use expiring SAS URL’s to various services (Video Indexer as a case in point) ensuring that data was always at rest and secure in the environment. Data was never actually transferred out of the secure environment, and an expiring SAS URL prevented long term access to that endpoint.

By implementing parameters in the workflow, it prevented the SAS URL from being visible during the deployment and processing phase. To further secure the URL’s, they can be stored and referenced from an Azure Key Vault, keeping all secrets accessible only from the deployment and workflows themselves.

Monitoring

While monitoring itself doesn’t provide a security type of service, it allows for end-to-end visibility of the solution and what is occurring, or potentially failing. Azure Log Analytics provided full monitoring of the solution, giving visibility to when a trigger occurs, fails or some other type of action needs to be taken. Monitoring not only provides a tracing capability, but also fulfills many compliance requirements.

Limitations, Workarounds and Other Considerations

Use of 2 regions in Azure

As highlighted above, the SDN (Software Defined Network) complexities presented when using outbound IP allow lists prevented the Logic Apps from being deployed into the same region as the storage accounts.

The workaround deployed the Logic Apps into a paired region (North Europe), when deployed the outbound IP address was outside the ‘deny all’ range on the storage firewall which resided in the West Europe region. A Logic App can be deployed into any (non-Government) region, but for the purposes of this project and data sovereignty, a paired region was chosen.

When deployed to a paired region, considerations such as cost, data sovereignty and performance are considered. As this project did not have an SLA against Logic App response times this solution posed the greatest resolution for the customer.  There was no noticeable degradation in response times in the Logic Apps during this project when they were deployed to North Europe.

Security Hardening Limitations

The following areas have been identified as potential limitations of hardening a Logic App implementation:

• Logic Apps share their compute space with other customers as they are a shared service, while there is logical separation, there is not a physical separation in the datacenter. The management of the Logic App is done in isolation but triggering the Logic App also depends on hardware resources in the datacenter.
• Logic Apps do not natively support VNet integration, unless deployed into an ISE (Integrated Service Environment). The ISE does allow for reserved compute and is a managed service, the cost outweighed the benefits for this project.
• Whilst feasible, deploying an ISE environment is cost prohibitive.

Key Learnings

If you’ve read this far, wow, thank you for sticking it out…

• Review the use case and design before deploying Logic Apps, consider the security and networking requirements from the inception.
  • Review all networking requirements in the environment, deciding what access is required and what resources need access to each other.

Review the security practices that need to be implemented as this will affect not only the networking, but what features to enable when deploying Logic Apps

If you want to read how we deployed the Logic Apps using Terraform read this.

This blog is part of Azure Week. Check it out for more great content!

About the Author:

April is a senior cloud advocate for Microsoft specializing in application transformation and DevOps ways of working. Her focus is working on Microsoft Azure to take customers of a journey from legacy technology, to serverless and containers, where code comes first, while enabling them to take full advantage of DevOps. April was previously a cloud consultant and solution architect for various partners in the UK and brings her years of experience in helping customers plan their journey.

In April’s spare time she spends time outdoors hiking, skiing or scuba diving.  She is also a triathlete competing in Ironman and Half Ironman triathlons.

April is often asked to present at events to showcase the latest Microsoft technologies and also to present live demos that are industry specific and applicable to real life use cases.  

Reference:

Edwards, A. (2021). Securing Azure Logic Apps. Available at: https://azapril.dev/2021/05/06/securing-logic-apps/ [Accessed: 7th July 2021].