Integration Proxy Service Guide

This is the full guide to go through the purpose of the integration proxy service and how it ensures secure communication from the Microsoft Azure cloud to an organisation's own network.

Introduction

To ensure that integration between cloud hosted digital services and council servers is secure there needs to be a mechanism of ensuring this is the case. Data protection and in particular ensuring sensitive data is treated in a consistently secure manner is vital when working with government/health organisations. IEG4 has taken significant steps to ensure that data is secured at every point in its journey and, reflective of this, is leveraging an industry leading service in the secure transfer of data from its cloud based digital services and local government applications sitting with their network.

IEG4 uses Microsoft Azure, which is the most accredited government cloud hosting solution to host its services and more information about these within Azure can be found here:

https://www.microsoft.com/en-us/trustcenter/compliance/uk-g-cloud

Moreover, IEG4 has leveraged a component of Microsoft Azure called the Azure Service Bus to deliver its Integration Proxy Service, which this document will go on to explain in more detail. The Integration Proxy Service is a windows service that runs on a Council server and its role is to act a secure relay from the council's network and IEG4's Digital Services being provided from the Microsoft Azure Cloud.

The beauty of the Integration Proxy Service is that it can act as a secure relay for n number of digital services and n number of line of business applications. As an example the Integration Proxy Service is used in a single council to:

Retrieve Council Tax Data from a back office app
Retrieve Business Rates Data from a back office app
Retrieve Benefits Data from a back office app
Retrieve bills/letters/payment schedules
Post XML data into Council Tax & Benefits systems
Post XML data into Environmental Health systems
Post XML data into Licensing systems
Post PDFs/Evidence for >100 online forms into different file locations

You can find out more about Microsoft Azure Service Bus which powers the Integration Proxy Service here:

https://docs.microsoft.com/en-us/azure/service-bus-relay/relay-what-is-it

Ensuring the Integration Proxy Service will work

This section will walk through the key elements required, that if followed, will ensure that the integration proxy service will work first time every time.

Server Pre-requisites

The server must be a Windows Server and it must be running a minimum of the .Net Framework 4.6.1. Consequently the following are the servers that can be used:

Windows Server 2016
Windows Server 2012 R2
Windows Server 2012 (64-bit edition)

We would recommend using Windows Server 2016, as 4.6.2 is pre-installed in the OS.

The integration proxy service is only a relay, taking XMLs/PDFs etc and posting them to web services/file locations on different servers. Therefore there is no need for SQL Server or significant disk space on this server.

Reflective of this the minimum hardware requirements for the server are low and we'd recommend prioritising processor and RAM over disk space:

Processor - 1 GHz

RAM - 512MB

Disk Space - 4.5GB

However, given how low these are customers will usually have much higher processor/ RAM.

An outbound connection

The integration proxy service only requires an outbound connection to be put in place. The outbound connection that is made defaults to use:

TCP which uses: Ports 9350 through to 9354 & 5671 & 5672

But can also use HTTP which uses port 80 should be open

The purpose of this outbound connection is to allow the Council's service bus (Integration Integration Services in the network diagram shown later) to communicate to the specific Council's instance in Microsoft Azure.

To ensure that it is the specific Council's instance in Microsoft Azure, the Council specific integration proxy service passes an encrypted message using AES 256 encryption as well as a 'salt' to make this 'handshake' even more secure.

Therefore the connection opened between the service and Microsoft Azure is coupled exclusively between those two points. Once the connection is made it then creates a secure tunnel from the specific Council's instance in Azure to the Council's Integration Proxy Service. It does this using port 443.

Therefore in summary the following ports need to be open outbound:

HTTP - 80

HTTPS - 443

TCP - 9350,9351,9352, 9353, 9354, 5671, 5672

Limiting the outbound connection to an IP range

If the council wishes to go further and make the outbound connection to the specific IP ranges used by Microsoft Azure this is also possible.

In order to ensure outbound only access to Microsoft Azure a specific range of IP addresses needs to be added within the Council's firewall. IEG4 customers will be hosted in Microsoft Azure UK South/West.

The range of IP addresses for Microsoft Azure is updated and so the latest version of this should be downloaded from here:

https://www.microsoft.com/en-gb/download/confirmation.aspx?id=41653

Once downloaded you need to ensure that you only pull out the IP ranges specific to UK South and UK West.

We've extracted these from the file below to illustrate the specific sections but you should do this yourself once you've downloaded the file from the above URL. So the list below illustrates the IP ranges for Azure UK South and West as at the time of writing this document - September 2019:

The reason that the IP range is large is simply to do with the fact that cloud servers use multiple IP ranges to facilitate load balancing across different servers. I.e. you are not opening the council to the entirety of Microsoft Azure UK per se. You are ensuring that the Council's instance in Azure is accessible should it change subnets.

Network Diagram�

The following is the network diagram illustrating the communication / network elements in place. NB IEG4 Integration services = Integration Proxy Service.