How HSBC built its PayMe for Business app on Microsoft Azure

Introduction

I recently read a blog post and watched a video on how HSBC built their PayMe for Business app hosted entirely in the could using Microsoft Azure. This is a great example of how to create an application using a highly secure cloud-native microservices architecture. While the blog post and video cover some great information it didn’t go into as much detail as I wanted and left me with some unanswered questions. That is the reason why I’m writing this blog post. I want to detail the information they covered but also hypothesise how they solved problems which they did not cover. Please see the references section at the bottom of this blog post for links to the original blog post and video.

What does the app do?

It allows a business to receive payments in realtime by the use of 2 mobile devices. 1 being the consumer’s device and the other being the business’s device. I assume the business enters an amount for the payment and somehow it sets up a payment request which is then displayed on the business’s mobile device which displays a QR code. The customer then opens the app on their mobile device, scans the QR code, authorizes the payment via facial recognition (Face ID) or fingerprint (Touch ID), the payment is then processed by the Payment transactions microservice and both parties are then notified that the payment has been completed.

What is the software’s architecture?

There are 13 microservices which run on Azure Kubernetes services. The microservices are the User profile, Business profile, Onboarding, Payment transactions, Payment reporting, Security authentications, Social, Timeline, Notifications, QR code service, Optical character recognition, FAQ, Messages microservices.

Each microservice runs independently as each microservice contains its own set of isolated resources. For instance, the Payment transactions microservice contains its own instance of Azure Key Vault, Azure Database for MySQL, Redis cache, Azure Event Hub, Azure Blob Storage, Azure Application Insights. So far this is a pretty standard microservices architecture.

What makes this software architecture different?

This is where I got interested.

Each microservice contains its own instance of Azure Key Vault where it’s secrets which are required for communicating with other services are stored. This means that there is no application-wide (or even worse company-wide) secrets management system which can be compromised hence not allowing a hacker to obtain application/company-wide access. So if a hacker compromises one microservice or instance of Azure Key Vault then they would only have access to the services which that microservice has access to and only at the same level of access as that microservice has. A hacker would need to compromise each microservice one by one to gain full control of the application.

Each microservice runs within its own VNET with a network security group (NSG) with a default deny rule for all inbound and outbound traffic. Explicit allow rules are created for each resource which a microservice is required to communicate with. This means that only traffic which is required for this microservice to function enters or exits the VNET.

Virtual network (VNET) service endpoints are used to securely communicate with Azure services which are typically running in a public cloud and are publically accessible over a direct connection. This extends your VNET’s private address space and identity of your VNET to the Azure services so that the traffic always remains on the Microsoft Azure backbone network and never traverses the public internet. This allows HSBC’s Cyber Security team to treat this traffic as if it was within the perimeter of a secured private network synonymous to an on-premise data centre or corporate network.

References:

How HSBC built its PayMe for Business app on Microsoft Azure blog post HSBC’s PayMe for Business app | How we built it in Azure video Virtual Network Service Endpoints