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.

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

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

copyresource "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:

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

copyresource "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.

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.

Example implementation components

The following examples show cert-manager implementation components:

• cert-manager Issuer

copyapiVersion: 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

• RFC1421 - Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures
• RFC1422 - Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management
• RFC1423 - Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers
• RFC1424 - Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services

The Transport Layer Security (TLS) protocol

• RFC2246 - The Transport Layer Security (TLS) Protocol Version 1.0
• RFC4346 - The Transport Layer Security (TLS) Protocol Version 1.1
• RFC5246 - The Transport Layer Security (TLS) Protocol Version 1.2
• RFC8446 - The Transport Layer Security (TLS) Protocol Version 1.3

Automatic Certificate Management Environment (ACME)

• RFC8555 - Automatic Certificate Management Environment (ACME)