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.
Further information about the HeartAI network architecture may be found with the following documentation section:
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
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:
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.
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.
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
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: heartai-hello-world-prod-gw-cert
namespace: heartai-ossm-control-plane
spec:
secretName: heartai-hello-world-prod-gw-cert
duration: 2160h0m0s
renewBefore: 360h0m0s
subject:
organizations:
- heartai
privateKey:
algorithm: RSA
encoding: PKCS1
size: 2048
usages:
- server auth
dnsNames:
- hello.prod.apps.aro.sah.heartai.net
issuerRef:
name: letsencrypt
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)