Skip to content

Infrastructure Networking & Security

Network Topolgy

Our networking topology is based on a three tier architecture consisting of the following Azure resources:

  • One virtual network per environment within the UK South region i.e., vnet-<environment>-uksouth-001.
  • 10.100.0.0/16, 10.110.0.0/16 and 10.120.0.0/16 are reserved for development, nonproduction and production environments respectively.
  • Each virtual network has three types of subnets dedicated to each tier in the architecture i.e., web, middle, data.
  • Each virtual network has four subnets i.e., two web , one middle, one data.
  • One web and one middle subnets are delegated to Azure App Service i.e., snet-web-<environment>-uksouth-001, snet-middle-<environment>-uksouth-001
  • One data subnet is delegated to Azure Database for MySQL i.e., snet-data-<environment>-uksouth-001
  • One web subnet is used by the Azure Application Gateway i.e., snet-web-<environment>-uksouth-002

Azure App Service Security

Default Security Features

Our frontend web application and backend REST APIs are hosted on Azure App Service, which includes the following security features by default:

  • Each application runs inside an dedicated and secure environment called a sandbox which isolates its execution from other customers' applications on the same machine.
  • VM instances and runtime software are regularly updated to address newly discovered vulnerabilities. App Service is a Platform-as-a-Service, which means that the OS and application stack are managed by Azure and we only manage our applications and their data.
  • App settings and connection strings are stored encrypted in Azure, and they're decrypted only before being injected into your app's process memory when the app starts. The encryption keys are rotated regularly. Communication of secrets such as connection strings, between our backend APIs and our SQL Database stays within Azure and doesn't cross any network boundaries.
  • 24-hour threat management protects the infrastructure and platform against malware, distributed denial-of-service (DDoS), man-in-the-middle (MITM), and other threats.

Additional Azure Security Recommendations

Our frontend web application and backend APIs have been configured to include the following additional Azure security recommendations:

  • Accessible only over HTTPS with an Azure App Service provided certificate.
  • HTTP to HTTPS traffic redirection to protect against unencrypted connections and ensure data in transit is protected from network layer eavesdropping attacks.
  • Enforced industry standard recommended TLS encryption version 1.2 for all clients connecting to our applications.
  • Frontend application and backend APIs use managed identities to access the Storage Account and Azure Database for MySQL.
  • Frontend application and backend APIs are periodically (weekly) audited for newer versions of their runtimes and updated to address security flaws or to include additional functionality.
  • Backend APIs have Cross-Origin Resource Sharing (CORS) enabled to restrict access to the frontend web application's domain.
  • Backend APIs use virtual Network integration and a point-to-site VPN to access the Azure Database for MySQL.

Azure Database for MySQL

  • Encryption in transit is enforced by default, which protects against "man in the middle" attacks by encrypting the data stream between the database server and our backend APIs. Backend APIs must present the Azure Certificate Authority (CA) certificate to establish a connection over SSL with the Azure Database for MySQL server.
  • Encryption at rest is enforced by default using Microsoft's managed keys. Data, including backups, are encrypted on disk and this encryption is always on and can't be disabled. The encryption uses FIPS 140-2 validated cryptographic module and an AES 256-bit cipher for the Azure storage encryption.
  • Integrated with our Virtual Network (Vnet) to lock down access to the database server to only our virtual network infrastructure i.e., backend APIs.
  • Integrated with Azure Private DNS zones to provide a reliable, secure DNS service to manage and resolve domain names in a virtual network without the need to add a custom DNS solution i.e., privatelink.mysql.database.azure.com.
  • Defined the following security rules using Azure Network Security Groups to lock down access to the database server to only the backend APIs:
    • allow_ingress_from_middle_to_data - Allow ingress access on TCP port 3306 from the middle subnet IP range to the data subnet.
    • deny_ingress_from_web_to_data - Deny ingress access on TCP port 3306 from the web subnet IP range to the data subnet.
  • Data files are backed up daily and transaction logs are backed up every five minutes. The backups are retained for 7 days in Development and Non Production and 30 days in Production.

Azure Key Vault

  • All secrets in our Key Vault are stored encrypted and decrypted automatically on retrieval by authorised principals and applications. Key Vault encrypts the secrets at rest with a hierarchy of encryption keys, with all keys in that hierarchy are protected by modules that are FIPS 140-2 compliant. This encryption is transparent, and requires no action from the user.
  • Each HTTP request to the Key Vault data plane is authenticated and authorised independently of other requests, to establish the identity of the caller and which operations the caller can execute.
  • Our Key Vault or objects are protect against malicious or accidental deletion with the soft delete and purge protection features enabled.

Azure Storage Account

  • Data in Azure Storage is encrypted and decrypted transparently using 256-bit AES encryption, one of the strongest block ciphers available, and is FIPS 140-2 compliant.
  • Data is encrypted at rest using a customer-managed Azure Key Vault key with automated key rotation enabled.
  • Secure transfer to the storage account is enabled, which enforces all requests to the storage account to be made over HTTPS.
  • Enforced industry standard recommended TLS encryption version 1.2 for all backend APIs accessing the storage account.
  • Blob public access is disabled, which ensures tht no anonymous access to blobs within the storage account is permitted, regardless of underlying ACL configurations.