The goal of using On-Premises Gateways is to enable Azure Logic Apps and Sentinel Playbooks to work with on-premises resources. Many organizations implement security products inside their private networks, without wanting to expose them to the internet.

SOCs all over the world implement local, on-premises SOAR solutions such as Splunk SOAR (on-premises) for these reasons, while Microsoft also offers a strong set of tools.

Using On-Premises Data Gateways, I aim at showcasing that Azure Logic Apps' capabilities go beyond public-facing infrastructure and cloud-based solutions.

Links:

• Install an on-premises data gateway | Microsoft Learn
• Connect to on-premises data sources - Azure Logic Apps | Microsoft Learn
• The Ultimate Guide to Connecting to On-Premise API’s using Azure Logic Apps | by Navaneeth Sen | Medium

What are Data Gateways

One of the most important considerations when connecting Azure Logic Apps to internal resources is security.

• On-Premises Data Gateways are installed on a host within the local network
• The host sents requests TO the Azure Cloud, meaning that the host must not be publicly accessible to work (NAT)
• Through a local AD Join, access can be monitored, restricted and adjusted as wished

Basically, an On-Premises Data Gateway is an application you install on an internal windows host, which will send requests to the azure cloud, receive instructions from Logic Apps, and then forward them to internal resources.

This setup enables cloud services to send requests to the gateway, which forwards those instructions to the designated internal resources. It ensures that your data remains on-premises while still leveraging the power of Azure cloud services.

Requirements

To run On-Premises Data Gateways, the following prerequisites must be met:

• On-Premises Host running On-Premises Gateway
  • Windows Host within the Network
  • .NET 4.8
  • Domain joined if resources within AD should be accessed
  • For Server instances → Core is not supported
• A user within the Entra ID Tenant with “Gateway Administrator” Role
  • This role could not be found, Contributor was used instead (not recommended for prod implementations)

Test Lab Setup

1. Create Hyper-V VM (template: Windows 11 dev environment)
2. Enable nested virtualization using Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true
3. Install python on WSL
4. Download and run the Gateway Installer (see below)

Download On-premises data gateway from Official Microsoft Download Center

Keep your data in Power BI, PowerApps, Logic Apps, and Power Automate up to date using the on-premises data gateway

Microsoft Store - Download Center

You will then be forwarded to the “Create Gateway” blade within Azure Portal.

You can then go ahead and test the implementation by running a local HTTP webserver via python3 -m http.server 8080, simulating an API we wish to access:

Then create a Logic App to interact with it:

• You can choose the Trigger as you wish
• The connector used to interact with On-Premises resources must be “HTTP with Entra ID” in order to be able to work with the gateway

You can then validate that the request was successful by going to Run history and selecting your last run:

Where to go from here

Enable playbooks to perform actions on your on-premises infrastructure leverages your possibilities regarding automation, while I focus on:

• Sentinel as a SOAR: While usually implemented as a SIEM/SOAR combination, Data Gateways enable SOCs to use Sentinel as a standalone SOAR through forwarding alerts from on-premises sources.
• Automated Investigation: Having the ability to store data on-premise and query it using Logic Apps enables security professionals to acquire more evidence during investigations.
• Automated Response: With Logic Apps/Playbooks being able to perform actions on on-premises infrastructure, more response possibilities arise as local security tooling can be utilized.

Thank you for reading my blog post!