A Deep Dive into Logic Apps vs. Power Automate Security Features

Debating between Logic Apps and Power Automate flows about security? This blog post delves into the essential security differences of both Logic Apps and Power Automate. We’ll explore the security features, security differences and best practices available to protect these workflows from threats, both internal and external. Join me as we provide a hands-on comparison and guide on how to effectively secure your workflows using Logic Apps and Power Automate.

Security comparison overview

Here is a comparison of the security features between Logic Apps Consumption/Standard and Power Automate. Securing workflows with Logic Apps involves different security measures compared to Power Automate. Similar features often have different names on each platform, making a detailed Logic Apps vs. Power Automate security comparison essential:

Public Request Trigger URLs

HTTP request-triggered workflows in Azure are publicly accessible by default. This means they can receive inbound requests from other services, workflows, or users via a URL. Although these URLs include a security token (SAS token), they are still publicly accessible. Let’s explore the public link and configuration options between Logic Apps and Power Automate.

Workflow URL

URLs for these workflows are protected by a SAS token, which provides a small layer of security by making the URL harder to guess. However, the main drawback is that SAS tokens don’t auto-renew and are valid indefinitely. This makes them similar to passwords that can be compromised if exposed.

Power Automate flows and Logic App consumption workflows share the same URL structure. This isn’t surprising since they both operate on the same underlying serverless architecture.

Logic App Consumption & Power Automate structure:
https://{microsoft-host-url}.logic.azure.com:433/workflows/{logic-app-resource-ID}/triggers/manual/paths/invoke&api-version=2016-10-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig={shared-access-signature}

Logic App Standard structure:
https://{logic-app-name}.azurewebsites.net:443/api/{workflow-name}/triggers/{trigger-name}/invoke?api-version=2022-05-01&sp=%2Ftriggers%2F{trigger-name}%2Frun&sv=1.0&sig={shared-access-signature}

SAS token rotation

Logic Apps allow you to rotate or reconfigure SAS tokens for each workflow, boosting security if tokens are leaked or about to expire. Automating key rotation adds an extra layer of defense against unauthorized access.

Administrator Privileges: Only administrators can rotate access keys, making proper security role setup crucial. Use Role-Based Access Control (RBAC) to ensure only authorized users can manage SAS tokens.

Enhancing Security:

• Regular Rotation: Schedule routine intervals for SAS token rotation to minimize risks.
• Monitoring and Auditing: Utilize Azure monitoring tools to track access and changes to SAS tokens, aiding in the detection of potential security issues.
• User Education: Train users on the importance of SAS token security and proper handling procedures.

Azure API Management and Front Door

Backend APIs are crucial entry points to your applications and data, and must be protected from malicious applications and users. In the architecture described below, Azure API Management acts as a gateway between the client and backend, offering various security benefits:

Security Advantages:

• Block Unauthorized Requests: Prevents access from requests lacking proper authorization (missing authorization headers or certificates).
• Block Requests with Insufficient Permissions: Denies access to requests with missing claims or incorrect certificates.
• Rate Limiting: Enforces rate limits per client to prevent abuse.
• Hide Backend URL: Keeps the backend URL hidden from the public.

Centralizing APIs with API Management simplifies management for administrators and security teams.

The example architecture below demonstrates how API Management and Front Door can protect the backend layer from direct access.

Understanding Azure Front Door: A Modern CDN Service

Azure Front Door is a content delivery network (CDN) offering advanced Layer 7 features. These include SSL offload (removing SSL processing from your server), path-based routing (directing traffic based on URL paths), quick failover (rapidly switching to healthy endpoints), and caching (storing content closer to users to speed up access).

Key Features of Azure Front Door

• SSL Offload: Handles secure connections at the network’s edge, allowing your application to focus on content delivery.
• Path-Based Routing: Directs traffic based on URL paths.
• Quick Failover: Switches rapidly to healthy endpoints in case of failure.
• Caching: Stores content closer to users to enhance access speed.

Alternatives to Azure Front Door

• Traffic Manager: A DNS-based service that routes global traffic at Layer 7, similar to traffic management for websites and web services.
• Application Gateway: A Layer 7 load balancer that distributes traffic across servers within a region to optimize performance.
• Load Balancer: Operates at the network layer (Layer 4), balancing incoming network traffic across multiple servers to ensure reliability.
• Nothing: Some companies, (non-enterprises) , may not need these services. They might use API management to connect to API backends. However, integrating Azure Front Door with Virtual Network (VNet) and private endpoints can still offer benefits.

For a detailed comparison and guidance on choosing the right Azure load-balancing solution, check out Microsoft’s comprehensive guide here.

RBAC – Role-Based Access Control

Azure offers several predefined access roles to manage permissions for Logic Apps, connections, and execution history. You can assign these built-in roles to users or groups to control access.

If the default roles don’t meet your needs, Azure allows you to create custom roles tailored to your specific requirements.

Logic App Consumption workflows

Logic App Standard workflows

At the time of writing Logic app standard RBAC roles are in preview.

Power Automate workflows

Power Automate provides less flexibility, all the below roles provide access to power automate flows.

Power Automate Flow Co-Owner

In Power Automate, you can add a co-owner to a flow. A co-owner has full control over the flow. They can:

• Add or remove other users as owners
• Access the run history
• Update, edit, or delete the flow

This feature is useful for sharing a specific flow with another user. However, keep in mind that if a flow is part of a solution, it will automatically be shared with everyone who has access to that solution.

To add a co-owner, open the workflow, navigate to “Co-owners,” and edit the settings.

Restrict Access by IP Range for Logic Apps

To secure your Logic App, you can restrict access based on IP ranges. This allows you to specify one or more IP addresses or ranges that can send traffic to your Logic App. Only an admin can remove this restriction.

Implementing IP restrictions (or a Virtual Network, see later) is an effective way to secure backend services without additional costs.

1. Enhanced Security: By limiting access to specific IP addresses, you protect your backend services from public exposure without extra cost.
2. Fixed IP with API Management: API Management has a fixed IP address. This ensures that clients must go through the API Management layer, blocking any direct access to your Logic App URL.
3. Cost Efficiency: Requests from unauthorized IPs are rejected at the network layer before they reach your application. This means there are no executions counted and no additional costs incurred, which is beneficial for consumption-based pricing.

Logic App Consumption

Steps on how to configure IP address restriction on logic app consumption:
Settings -> Workflow settings -> Access control configuration > Allowed inbound IP addresses, select Specific IP ranges.

Logic App Standard

Steps on how to configure IP address restriction on logic app standard:
Settings -> Networking -> Incoming Trafic -> Access restriction

VNET & Private endpoints

Securing your applications is crucial for any enterprise, especially when dealing with cloud services. In this section, we’ll explore how Virtual Network (VNet) and Private Links can enhance the security of Azure Logic Apps.

Proper planning and setup are crucial for ensuring secure and efficient connectivity for Azure Logic Apps.

Why VNET?

Virtual Networks (VNETs) are a go-to for many enterprises. They offer secure communication within the same region and are relatively low-cost compared to traditional on-premises networks. Within the same region, VNETs are relatively cheap and hassle-free compared to connecting physical cables to an on-premises network. However, be aware that pricing depends on the volume of inbound and outbound data transfer per GB.

Benefits of VNet Integration:

• Isolation: VNets isolate your Logic Apps within a private network, reducing exposure to the public internet.
• Enhanced Security: They keep data traffic within Azure’s backbone.
• Advanced Networking: You can control traffic flow with subnets and network security groups.

Private Endpoint

Private Link allows you to access Azure PaaS services over a private endpoint within your network, restricting inbound traffic and turning off public access. This ensures that traffic originates from within your private network, protecting inbound HTTP requests and creating a private inbound IP address.

Restrict Inbound Traffic: Using Private Link, you can restrict inbound traffic to your Logic Apps, ensuring that only traffic from your internal network is allowed.

Combining VNet and Private Endpoints

Using VNet and Private Endpoints together provides robust security for both inbound and outbound traffic, a strategy often employed in Azure landing zones for enterprise environments. Here’s how you can use them:

• Example 1: Connect your Logic App to an Azure SQL Server without exposing it to the public internet.
• Example 2: Securely connect Azure API Management (APIM) to your Logic Apps. See the drawing architecture below:

Resources for Further Learning

To learn more about securing Azure Logic Apps with Private Endpoints and VPNs, check out these helpful YouTube videos:

• Securing Azure Logic Apps (Standard) with Private Endpoints
• Connecting Azure Logic Apps (Standard) Instance to a VNET

For detailed steps on configuring VPNs and Private Links for Logic Apps, refer to the official Microsoft guide: Secure Logic Apps with VNET and Private Endpoint.

Data Loss Prevention (DLP)

Organizations handle sensitive information like financial details, proprietary data, credit card numbers, health records, and social security numbers. To protect this data and lower the risk of it being shared with the wrong people, we use a strategy called data loss prevention (DLP). This helps prevent users from sharing sensitive information with those who shouldn’t have access to it.

At its essence, DLP focuses on limiting access to specific pre-built connectors, thereby managing outbound connections to avoid data leaks. It involves defining and implementing policies that restrict the creation or use of connections for connectors defined unsafe or unnecessary. For instance, for security purposes, you might decide to block connections to certain social media platforms or other services and systems.

Limitations:

• No User-Level Controls: DLP policies apply to entire environments, not individual users.
• Potential for Workarounds: Users might find ways around DLP, and it can’t cover all security gaps.

In my experience, DLP policies in Power Platform are generally more user-friendly for newcomers compared to Azure policies for Logic Apps, due to the wizard-style configuration interface. On the other hand, Azure policies demand a bit of a learning curve but offer a broader and more comprehensive approach to enforcing organizational standards and ensuring compliance at a larger scale.

A key difference between DLP for the Power Platform and Logic Apps is their scope: DLP for the Power Platform applies rules at the environment level, while Azure provides the flexibility to establish more detailed and granular rules specifically for the Azure environment.

Logic App

Azure Policy is a tool for enforcing organizational standards and assessing compliance across Azure resources. It works by evaluating Azure resources and actions against business rules expressed in JSON format as policy definitions. These definitions can be grouped into policy initiatives for easier management.

These policies can be assigned to any Azure-supported scope, such as management groups, subscriptions, resource groups, or individual resources, affecting all resources within that scope.

Below is an example of how to restrict Instagram connectors for logic app workflows:

Microsoft has written an excellent step-by-step guide on how to configure DLP for logic apps:
https://learn.microsoft.com/en-us/azure/logic-apps/block-connections-connectors

Power Automate

To protect business data, Power Automate gives you the ability to create and enforce policies that define which connectors can access and share it. The policies that define how data can be shared are referred to as data loss prevention (DLP) policies.

Through DLP policies, you can track and monitor how data is being used across your Power Platform applications. This includes seeing what data is accessed and by whom, helping you manage compliance and security providing data analysis within the Power Platform ecosystem.

Microsoft has an extensive step-by-step guide available on how to configure DLP on Power Platform for environment-level policies:
https://learn.microsoft.com/en-us/power-platform/admin/prevent-data-loss

Managed identity

Managed identities eliminate the need for storing and managing sensitive information like passwords and secrets. The best part? They can’t expire, be misconfigured, or leak, offering a solid layer of security for your applications.

In Logic Apps, you have two types of managed identities:

• User-Assigned Managed Identity: Offers flexibility and is not tied to any specific resource. You can use and manage this identity across multiple resources, making it ideal for complex scenarios.
• System-Assigned Managed Identity: This is directly tied to your Logic App’s lifecycle. It’s automatically created and deleted with the Logic App, simplifying management for straightforward use cases.

Understanding the Limitations, depending on your plan:

• Logic App Consumption Plan: You can only use one managed identity at a time.
• Logic App Standard Plan: Using both user-assigned and system-assigned identities simultaneously.

Before you start into using managed identities, check if your preferred connectors support this feature. Not all connectors do, and knowing this upfront will help you plan your Logic App workflows more effectively.

To enable a Logic App to access a resource, simply assign the necessary RBAC roles to its managed identity. This approach ensures that your Logic App has the exact permissions it needs, maintaining security and efficiency.

My take on securing a HTTP trigger for Power Automate flow

As you can see from the above pieces of information, securing business workflows with Power Automate have far less options compared to Logic apps. This is somehow expected as Power Automate targets self-service scenarios for “Office workers, business users, SharePoint administrators”, whilst logic app targets Advanced integrations for “Pro integrators and developers, IT pros”.

There are however a few settings that can be configured on the HTTP request trigger to tweak the access restriction a bit.

Tenant Access Restriction

This is a setting that is only available for the Power Automate trigger. It restricts access to the endpoint to either:

• Any user in my tenant: All users within the same tenant
• Specific users in my tenant: A selection of users within the tenant
• Anyone: anonymous (publicly available)

The trigger evaluates the incoming Authorization token created by Entra ID and verifies if the user has access. Users without required access will receive an HTTP 403 unauthorized.

The user that calls the HTTP trigger needs to have “Power Automate” API permissions on Entra ID configured. The setup is somehow cumbersome, however, there is a great step-by-step guide available here: https://forwardforever.com/using-oauth-authentication-for-http-request-triggers-in-power-automate

Enable basic authentication

Adding custom security header validations is a simple way to improve security. Triggers in Azure allow you to set conditional rules. If the condition isn’t met, the request is rejected, and the client gets an HTTP error response. There’s no execution count on this flow.

Here’s an example of basic username and password validation, but you can also use your own Auth-Key or custom header:

equals(triggerOutputs()['headers']?['Authorization'],' Basic dXNlcm5hbWUxOnBhc3N3b3JkMTIz')

Takeaway

When comparing Logic Apps (Consumption & Standard) and Power Automate, it’s clear that their security features differ significantly. This makes it crucial to assess your security needs, compliance requirements, and cost implications before deciding which technology to use for your project.

1. Security Requirements: Evaluate the specific security features each platform offers. Logic Apps Standard, for instance, provides more advanced security controls compared to Power Automate.
2. Compliance Considerations: Ensure the chosen technology meets your organization’s compliance standards. This includes data encryption, access controls, and logging capabilities.
3. Cost Implications: Understand the cost differences associated with the security features of each platform. More robust security often comes with higher costs.
4. Decision Making: Choose the technology that aligns best with your project’s security and compliance needs from the start. Migrating from one platform to another later can be complex and expensive.