Network security

HeartAI network security is a central consideration. Deployments of HeartAI are resolvable only internally to the HeartAI network instance or through private network extension.

Network architecture

Further information about the HeartAI network architecture may be found with the following documentation section:

The HeartAI website

The HeartAI website is hosted separately through GitHub Pages.

Azure network security groups

Structured control of network traffic is important for ensuring that external inbound traffic may only access corresponding system endpoints, and external outbound traffic is restricted to only what is required. Similarly, internal traffic may be restricted to strengthen these security postures from within internal networks. Azure network security groups filter network traffic to and from Azure resources in an Azure virtual network. A network security group contains security rules that allow or deny inbound network traffic to, or outbound network traffic from, several types of Azure resources.

HeartAI network security implements the following Azure network security groups:

Network security group Description Network association
sah-heartai-nsg-prod-aue-001 HeartAI default network security group Associates to all subnetworks if no other network security group present
sah-heartai-aro-prod-p4kdl-nsg HeartAI Azure Red Hat OpenShift network security group Associates to subnetworks that are managed by Azure Red Hat OpenShift

Network security groups are restrictive by default and implement a permissive by exception approach - Generally network traffic is denied unless explicitly specified.

Example: Network security group Terraform declaration

Terraform implementation

The HeartAI implementation of Microsoft Azure is managed with the Terraform declarative infrastructure-as-code software framework. Terraform allows for the declaration of system components using configuration files specified with the HashiCorp Configuration Language (HCL). Further information about the HeartAI implementation of Terraform may be found with the following documentation:

The following example shows Terraform declarations to specify the HeartAI default Azure network security group. This implementation coordinates instances of the following Azure components:

Azure component Functionality for network security group
Network security group Specifies configuration for corresponding Azure network security group
resource "azurerm_network_security_group" "nsg_default" {
  name = "sah-heartai-nsg-default-prod-aue-001"
  location = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name

  security_rule {
    name = "AllowVnetInBound"
    description = "Allow inbound traffic from all VMs to all VMs in VNET"
    priority = 100
    direction = "Inbound"
    access = "Allow"
    protocol = "*"
    source_port_range = "*"
    destination_port_range = "*"
    source_address_prefix = "VirtualNetwork"
    destination_address_prefix = "VirtualNetwork"
  }

  security_rule {
    name = "AllowAzureLoadBalancerInBound"
    description = "Allow inbound traffic from Azure Load Balancer"
    priority = 101
    direction = "Inbound"
    access = "Allow"
    protocol = "*"
    source_port_range = "*"
    destination_port_range = "*"
    source_address_prefix = "AzureLoadBalancer"
    destination_address_prefix = "*"
  }

  security_rule {
    name = "DenyAllInBound"
    description = "Deny all inbound traffic"
    priority = 102
    direction = "Inbound"
    access = "Deny"
    protocol = "*"
    source_port_range = "*"
    destination_port_range = "*"
    source_address_prefix = "*"
    destination_address_prefix = "*"
  }

  security_rule {
    name = "AllowVnetOutBound"
    description = "Allow outbound traffic from all VMs to all VMs in VNET"
    priority = 100
    direction = "Outbound"
    access = "Allow"
    protocol = "*"
    source_port_range = "*"
    destination_port_range = "*"
    source_address_prefix = "VirtualNetwork"
    destination_address_prefix = "VirtualNetwork"
  }

  security_rule {
    name = "AllowInternetOutBound"
    description = "Allow outbound traffic from all VMs to Internet"
    priority = 101
    direction = "Outbound"
    access = "Allow"
    protocol = "*"
    source_port_range = "*"
    destination_port_range = "*"
    source_address_prefix = "*"
    destination_address_prefix = "Internet"
  }

  security_rule {
    name = "DenyAllOutBound"
    description = "Deny all outbound traffic"
    priority = 102
    direction = "Outbound"
    access = "Deny"
    protocol = "*"
    source_port_range = "*"
    destination_port_range = "*"
    source_address_prefix = "*"
    destination_address_prefix = "*"
  }

  tags = {
    "Application Name" = var.heartai-environment.application-name
    "Application Owner" = var.heartai-environment.application-owner
    "Environment" = var.heartai-environment.environment
    "Division Department" = var.heartai-environment.division-department
    "Cost Centre" = var.heartai-environment.cost-centre
  }
}

Azure Network Watcher

Azure Network Watcher provides tools to monitor, diagnose, log, and view metrics of resources in an Azure virtual network. Network Watcher is further integrated with backing Storage Accounts and Log Analytics workspaces, to provide the functionalities of Azure Traffic analytics:

References

Further information about these approaches may be found with the following external references:

Example: Azure Network Watcher Terraform declaration

The following example shows Terraform declarations to specify an Azure Virtual Network with a corresponding Azure Network Watcher. This implementation coordinates instances of the following Azure components:

Azure component Functionality for Azure Virtual Network
Private DNS Provides private name resolution for Azure Storage Account network endpoints within the corresponding Azure Private DNS zone
Virtual Network Configures and deploys an Azure Virtual Network
Network Watcher Integrates an instance of Azure Network Watcher to a corresponding Azure Virtual Network
resource "azurerm_private_dns_zone" "heartai-dns-private" {
  name = "sah.heartai.net"
  resource_group_name = azurerm_resource_group.rg.name

  tags = {
    "Application Name" = var.heartai-environment.application-name
    "Application Owner" = var.heartai-environment.application-owner
    "Environment" = var.heartai-environment.environment
    "Division Department" = var.heartai-environment.division-department
    "Cost Centre" = var.heartai-environment.cost-centre
  }
}

resource "azurerm_virtual_network" "vnet" {
  name = "sah-heartai-vnet-prod-aue-001"
  location = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  address_space = [
    var.vnet-prod-aue-001-address-space.vnet]

  tags = {
    "Application Name" = var.heartai-environment.application-name
    "Application Owner" = var.heartai-environment.application-owner
    "Environment" = var.heartai-environment.environment
    "Division Department" = var.heartai-environment.division-department
    "Cost Centre" = var.heartai-environment.cost-centre
  }
}

resource "azurerm_subnet" "snet_aroworker" {
  name = "sah-heartai-snet-aroworker-prod-aue-001"
  resource_group_name = azurerm_resource_group.rg.name
  virtual_network_name = azurerm_virtual_network.vnet.name
  address_prefixes = [
    var.vnet-prod-aue-001-address-space.snet1]
  service_endpoints = [
    "Microsoft.ContainerRegistry"]
  enforce_private_link_endpoint_network_policies = true
}

resource "azurerm_subnet" "snet_aromaster" {
  name = "sah-heartai-snet-aromaster-prod-aue-002"
  resource_group_name = azurerm_resource_group.rg.name
  virtual_network_name = azurerm_virtual_network.vnet.name
  address_prefixes = [
    var.vnet-prod-aue-001-address-space.snet2]
  service_endpoints = [
    "Microsoft.ContainerRegistry"]
  enforce_private_link_service_network_policies = true
}

resource "azurerm_subnet" "snet_vpn_gateway" {
  name = "GatewaySubnet"
  resource_group_name = azurerm_resource_group.rg.name
  virtual_network_name = azurerm_virtual_network.vnet.name
  address_prefixes = [
    var.vnet-prod-aue-001-address-space.snet3]
  enforce_private_link_endpoint_network_policies = true
}

resource "azurerm_subnet" "snet_paas" {
  name = "sah-heartai-snet-paas-prod-aue-004"
  resource_group_name = azurerm_resource_group.rg.name
  virtual_network_name = azurerm_virtual_network.vnet.name
  address_prefixes = [
    var.vnet-prod-aue-001-address-space.snet4]
  enforce_private_link_endpoint_network_policies = true
}

resource "azurerm_network_watcher" "network_watcher" {
  name = "NetworkWatcher_australiaeast"
  location = "australiaeast"
  resource_group_name = "NetworkWatcherRG"

  tags = {
    "Application Name" = var.heartai-environment.application-name
    "Application Owner" = var.heartai-environment.application-owner
    "Environment" = var.heartai-environment.environment
    "Division Department" = var.heartai-environment.division-department
    "Cost Centre" = var.heartai-environment.cost-centre
  }
}

Azure DDoS protection

Denial-of-service (DoS) and distributed denial-of-service (DDoS) attacks are an inherent security risk to endpoints that are exposed to external networks, particularly with network exposure to the public internet. A typical DoS attacker will flood exposed network endpoints with network traffic in an attempt to overwhelm network resources or expose a network vulnerability. This traffic may appear to be expected network traffic and may interact with network endpoints in a way that aligns with expected functionality. The malicious nature of the traffic is due to high volume, in an attempt to deny network availability, or through the purposeful misuse of network endpoints, for example to brute force a password or to attempt to expose a buffer overflow. These DoS attacks become more nefarious when the attacker utilises a distributed network of hostile resources, confounding attempts to detect and mitigate attacks originating from a single host. Microsoft Azure provides integrated DDoS protection that protects every property within Azure’s infrastructure. The HeartAI system implements instances of Azure DDoS Protection Standard, which provides the following security features:

  • Native platform integration.
  • Turnkey protection.
  • Always-on traffic monitoring.
  • Adaptive tuning.
  • Multi-Layered protection.
  • Extensive mitigation scale.
  • Attack analytics.
  • Attack metrics.
  • Attack alerting
  • DDoS Rapid Response.
  • Cost guarantee.

The following networks are secured with Azure DDoS Protection Standard:

Azure network DDoS protection plan DDoS protection type
sah-heartai-vnet-prod-aue-001 sag-xg-tier0-ddos-plan Azure DDoS Protection Standard
sah-heartai-vnet-kv-aue-001 sag-xg-tier0-ddos-plan Azure DDoS Protection Standard

Azure environment certificate management

Service endpoints provided by Microsoft Azure are managed by Microsoft with the certificate authority DigiCert Global Root G2.

OpenShift internal network encryption

Encryption over TLS occurs wherever possible for internal and external network communication. For example, service instances may communicate with each other via TCP over TLS, HTTPS, or WebSockets Secure. Similarly, backing services, such as persistent data stores, communicate with service instances through these mechanisms. Encryption also occurs for communication within OpenShift environments between the system control plane and compute nodes as well as between system components. The combined functionality of these approaches allows HeartAI network instances to be implemented as zero trust networks. The HeartAI OpenShift environment provides automated approaches for certificate issuance and management. This is primarily managed with the certificate management software cert-manager. cert-manager automates the issuance of certificates by utilising the ACME protocol, which also supports certificate rotation and revocation.

Service architecture

Please refer to the documentation section Service architecture for an overview of the HeartAI system service architecture.

OpenShift external network encryption

OpenShift routes natively supports the exposure of system service endpoints and allows the establishment of TLS-encrypted connections. The system OpenShift implementation natively supports the following methods of TLS connection:

TLS connection type Description
Passthrough Server certificates from downstream server passed through the edge router and presented to requesting agent. TLS encryption occurs end-to-end from requesting agent to downstream server.
Re-encryption The edge router presents its server certificate to the requesting agent, and the edge router itself requests a server certificate from the downstream server. TLS encryption occurs both between the requesting agent and the edge router, and the edge router and the downstream server.
Edge termination The edge router presents its server certificate to the the requesting agent, but the edge router does not request a server certificate from the downstream server. TLS encryption occurs between the requesting agent and the edge router, but not between the edge router and the downstream server.

For purposes of security, HeartAI only implements the passthrough and re-encryption methods of TLS connections. The following sections describe how certificates are managed within the HeartAI OpenShift environment.

Certificate management within OpenShift environment

Within HeartAI OpenShift environment provides automated approaches for certificate issuance and management. This is primarily coordinated with the certificate management software cert-manager. cert-manager automates the issuance of certificates by utilising the ACME protocol, which also supports certificate rotation and revocation. The corresponding certificate authority is Let’s Encrypt. The preferred challenge mechanism to prove HeartAI domain ownership is with the DNS01 challenge. cert-manager performs this challenge by communicating with the HeartAI global domain name servers that are implemented with Cloudflare DNS. This allows HeartAI domain hostnames to issue trustable certificates.

Domain name architecture

Further information about the HeartAI domain name architecture may be found with the following documentation section:

Example implementation components

The following examples show cert-manager implementation components:

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt
  namespace: heartai-ossm-control-plane
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: [email protected]
    privateKeySecretRef:
      name: letsencrypt
    solvers:
      - dns01:
          cloudflare:
            email: [email protected]
            apiTokenSecretRef:
              name: cloudflare-api-token
              key: api-token

External services certificate management

In addition to HeartAI-managed certificates, certificates for the following HeartAI services are managed by the corresponding external service provider:

External service Service provider Hostname Description Certificate protocol Certificate authority Challenge protocol
HeartAI website GitHub Pages www.heartai.net HeartAI website and documentation. ACME Cloudflare Inc DNS01
HeartAI Postman Postman postman.heartai.net HeartAI Postman implementation. ACME Cloudflare Inc DNS01

Network endpoint encryption overview

The HeartAI team takes network security very seriously. The default security posture of HeartAI network endpoints is for encryption everywhere, with single or mutual TLS authentication enforced where appropriate.

The following table provides an overview of HeartAI network endpoint encryption:

Network endpoint Certificate authentication usages Encryption policy Network scope
Azure Storage Server, client Mutual TLS enforced Corresponding Azure Private DNS zone and OpenShift DNS zones.
Azure Database for PostgreSQL Server Single TLS enforced Corresponding Azure Private DNS zone and OpenShift DNS zones only within the Istio service mesh.
OpenShift external service endpoints Server Single TLS enforced Corresponding Azure Private DNS zone, OpenShift DNS zones, and private network extension.
OpenShift Service Mesh peer endpoints Server, client Mutual TLS enforced Corresponding OpenShift DNS zones only within the Istio service mesh.
Strimzi Kafka bootstrap endpoints Server Single TLS enforced Corresponding OpenShift DNS zones only within the Istio service mesh.
Strimzi Kafka broker endpoints Server Single TLS enforced Corresponding OpenShift DNS zones only within the Istio service mesh.
Akka Artery Remoting endpoints Server, client Mutual TLS enforced Corresponding OpenShift DNS zones only within the service-level Akka Cluster.

TLS specifications

The following table shows examples (non-exhaustive) of TLS specifications for HeartAI network endpoints:

Network endpoint Hostname Certificate authority Certificate protocol Certificate challenge mechanism TLS version Cipher suite Key strength
HeartAI website www.heartai.net Cloudflare Inc ACME DNS01 TLS 1.3 TLS_AES_128_GCM_SHA256 128 bit
HeartAI Postman postman.heartai.net Cloudflare Inc ACME DNS01 TLS 1.3 TLS_AES_128_GCM_SHA256 128 bit
Azure Database for PostgreSQL sah-heartai-psql-prod-aue-001.postgres.database.azure.com DigiCert Global Root G2 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 256 bit
HeartAI default network ingress endpoints *.apps.aro.sah.heartai.net Sectigo Limited TLS 1.3 TLS_AES_256_GCM_SHA384 256 bit
HeartAI keycloak endpoint keycloak.apps.aro.sah.heartai.net Let’s Encrypt ACME DNS01 TLS 1.3 TLS_AES_256_GCM_SHA384 256 bit
HeartAI pgadmin endpoint pgadmin.apps.aro.sah.heartai.net Let’s Encrypt ACME DNS01 TLS 1.3 TLS_AES_256_GCM_SHA384 256 bit
HeartAI service endpoints [service].[env].apps.aro.sah.heartai.net Let’s Encrypt ACME DNS01 TLS 1.3 TLS_AES_256_GCM_SHA384 256 bit
HeartAI client endpoints [client].[env].apps.aro.sah.heartai.net Let’s Encrypt ACME DNS01 TLS 1.3 TLS_AES_256_GCM_SHA384 256 bit

Development environment configuration

For system development environments, localhost network routing is implemented with Traefik. Traefik supports TLS-encryption through certificate self-signing.

Specification references

The HeartAI system network security refers to the following specifications:

The Privacy-Enhanced Mail format

The Transport Layer Security (TLS) protocol

Automatic Certificate Management Environment (ACME)