Requirement 1—Install and maintain a firewall configuration to protect cardholder data.
Further documentation:
1.1.1 A formal process for approving and testing all network connections and changes to the firewall and router configurations.
With IaC, infrastructure is managed through a descriptive model that uses a versioning system.
You'll need to use a combination of various network controls, including Azure Firewall, network security groups (NSGs), and the Kubernetes NetworkPolicy resource.
Minimise the number of people who can access and modify network controls. Define roles and clear responsibilities to teams.
1.1.2 Current network diagram that identifies all connections between the cardholder data environment and other networks, including any wireless networks
As part of your documentation, maintain a network flow diagram that shows the incoming and outgoing traffic with security controls.
This includes traffic flow from other networks including any wireless network to the CDE.
The diagram should also show flows within the cluster.
1.1.3 Current diagram that shows all cardholder data flows across systems and networks.
As part of your documentation, include a data flow diagram that shows how data is protected at rest and in transit.
The diagram should show how data flows to and from the workload and what information is passed from one resource to another.
Add a step as part of the change management process, to update the data flow diagram.
1.1.4 Requirements for a firewall at each Internet connection and between any demilitarised zone (DMZ) and the internal network zone.
Have a clear definition of what defines the boundary of a DMZ.
Azure Application Gateway integrated web application firewall (WAF) is used as the traffic router and for securing inbound (ingress) traffic to the cluster.
Azure Firewall is used to secure all outbound (egress) traffic from any network and its subnets.
Pod-to-pod communication is TLS-encrypted. Use the mTLS mesh if possible.
NSGs are added to secure traffic between the cluster and other components within the infrastructure. Inbound and outbound rules are well defined.
Only traffic from the virtual network is allowed.
Each node pool is in a dedicated subnet.
Apply NetworkPolicy on in-cluster communications, starting with a zero-trust network and opening paths as needed.
All namespaces (except kube-system, gatekeeper-system, and other AKS-provided namespaces) have restrictive NetworkPolicy applied.
Make sure you open paths for readiness, liveliness, and startup probes.
Open the path to oms-agent so that node-level metrics can be sent.
Standardize ports across the workloads so that you can provide a consistent NetworkPolicy and Azure Policy for the allowed container ports.
1.1.5 Description of groups, roles, and responsibilities for management of network components.
Define network segments based on the components involved in the infrastructure.
Identify implemented controls for each network segment.
Ensure that the documentation covers the breadth of the network infrastructure and has sufficient details on ownership and responsibilities.
Define the roles and responsibilities of the team members responsible for each control and network segment.
Start with a deny-all strategy. Give permission only when there's a business need or a role justification.
1.1.6 Documentation of business justification and approval for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure
Have detailed documentation that describes the services, protocols, and ports used in the network controls.
Deny all except for explicitly allowed ports.
Document business justification and documented security features if the use of insecure protocols can't be avoided. (Table headers: Rule, Protocol:Port, Source, Destination, Justification)
Firewall rules must be scoped exclusively to their related resources.
1.1.7 Requirement to review firewall and router rule sets at least every six months.
Have processes at least every six months to review the network configurations and the scoped rules:
Azure Firewall rules.
NSG rules.
Azure Application Gateway and WAF rules.
Native Kubernetes network policies.
Firewall controls on the applicable Azure resources.
Container Registry network rules.
Azure Vault network rules.
Database network rules.
Any other network controls you have added to the architecture.
Document the review procedure. Who performed it. When it was performed. What actions were taken.
1.2.1 Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment, and specifically deny all other traffic.
Azure Virtual Network cannot be directly reached by the public internet.
All inbound (or ingress) traffic must go through an intermediate traffic router. (APIM, App Gateway, Front Door)
All components in the network can reach public endpoints.
Outbound (or egress) traffic must be explicitly secured allowing only secure ciphers and TLS 1.2 or later.
Azure Application Gateway (or Front Door) integrated WAF intercepts all HTTP(S) ingress traffic and routes inspected traffic to the cluster.
WAF denies all traffic that is not TLS-encrypted.
WAF denies all traffic outside the port range for control plane communication from the Azure infrastructure.
WAF denies all health probes requests that are sent by entities other than the internal load balancer in the cluster.
Azure Firewall is used to secure all outbound (egress) traffic from trusted and untrusted networks.
Azure Firewall is provisioned in a subnet of the hub network.
Enforce Azure Firewall as the single egress point, user-defined routes (UDRs) are used on subnets that are capable of generating egress traffic.
Azure Firewall rules are applied in order that traffic is only allowed from specific sources to go to specific targets.
Use an HTTP proxy for monitoring and securing outbound (egress) traffic, from the cluster to external resources.
Azure Firewall to limit egress traffic to just go to the HTTP proxy.
Azure Private Link is used wherever possible (Databases, Azure Vault, Container Registry, etc).
The NSGs, on subnets that have node pools, deny any SSH access to its nodes.
Process in place for just-in-time emergency access while still maintaining the deny-all principle.
The NSG, on the subnet that has the jump box for running management tools, denies all traffic except from Azure Bastion in the hub network.
The NSGs, on subnets that have the private endpoints to Azure Key Vault and Azure Container Registry, deny all traffic except from the internal load balancer and the traffic over Azure Private Link.
1.2.2 Secure and synchronise router configuration files.
Infrastructure as Code (IaC) is used to detect the delta between the actual deployed state and the desired state.
The deployment assets, such as ARM templates, are source-controlled so that you have the history of all changes.
Information from Azure activity logs, deployment pipeline logs, and Azure deployment logs are collected and stored according to the companies data retention policy.
Kubernetes network policies also follow the source-controlled flow.
Process established to access the configuration history by retrieving the git logs for cluster configuration (such as network policies), Git history, deployment logs (such as Flux) and API logs.
1.2.3 Install perimeter firewalls between all wireless networks and the cardholder data environment, and configure these firewalls to deny or, if traffic is necessary for business purposes, permit only authorised traffic between the wireless environment and the cardholder data environment.
AKS nodes and the node pools are not reachable from wireless networks.
Requests to the Kubernetes API server must be denied from wireless networks.
Access to AKS nodes and the Kubernetes API is restricted to authorised and secured subnets.
Access from on-premisses to the spoke network is limited.
1.3.1 Implement a DMZ to limit inbound traffic to only system components that provide authorised publicly accessible services, protocols, and ports.
Do not configure public IP addresses on the node pool nodes. They must be deployed in private subnets.
Use Azure Policy to ensure Kubernetes don't expose a public load balancer. Traffic within the cluster must be routed through internal load balancers.
Only expose internal load balancers to Azure Application Gateway integrated with WAF.
All network controls should specify source, destination, port, and protocol restrictions, where applicable.
Do not expose the API server to the internet. When you run the cluster in private mode, the endpoint is not exposed and communication between the node pools and the API server is over a private network.
1.3.2 Limit inbound Internet traffic to IP addresses within the DMZ.
Add an NSG to the subnet with the internal load balancer in the cluster network.
Configure NSG rules to only allow traffic from the subnet that has Azure Application Gateway integrated with WAF.
Implement Kubernetes NetworkPolicies to restrict ingress traffic to pods within the AKS cluster.
Test the network configuration to ensure that traffic is being properly restricted.
1.3.3 Implement anti-spoofing measures to detect and block forged source IP addresses from entering the network.
Azure implements network filtering to prevent spoofed traffic and restrict incoming and outgoing traffic to trusted platform components.
1.3.4 Do not allow unauthorised outbound traffic from the cardholder data environment to the Internet.
Enforce all outbound (egress) traffic from the AKS cluster to go through Azure Firewall by using user-defined routes (UDRs) on all cluster subnets. This includes subnets with system and user node pools.
Limit outbound traffic by adding NSGs on subnets with node pools.
Use Kubernetes NetworkPolicies to restrict ingress and egress traffic from the pods.
Use a service mesh to handle additional policies. For example, if you only allow TLS-encrypted traffic between pods, the service mesh proxy can handle the TLS verification.
Prevent addition of public IP addresses to the networks within the CDE unless by subnets explicitly authorised, such as the Firewall subnets.
Use an HTTP proxy, in addition to Azure Firewall, to limit outbound (egress) traffic from the AKS cluster to the internet.
Use Azure Monitor Private Link Service (AMPLS) to have logs from Container insights sent over a secure, private connection to Azure Monitor. Understand the impact of enabling AMPLS.
1.3.5 Permit only "established" connections into the network.
Azure implements network filtering to prevent spoofed traffic and restrict incoming and outgoing traffic to trusted platform components. The Azure network is segregated to separate customer traffic from management traffic.
1.3.6 Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks.
Expose your storage systems only over a private network, by using Private Link.
Restrict access from the node pool subnet(s) that require it.
Keep state out of the cluster and in its own dedicated security zone.
1.3.7 Do not disclose private IP addresses and routing information to unauthorised parties.
Use a private AKS cluster.
Use a private DNS zone with the private AKS cluster.
Set “enablePrivateClusterPublicFQDN” to FALSE to prevent disclosure of your control plane's private IP address.
Use Azure Policy to enforce the use of private clusters without public DNS records.
Use a private DNS zone for routing between the subnet that has Azure Application Gateway integrated with WAF, and the subnet that has the internal load balancer.
Ensure that no HTTP responses include any private IP information in the headers or body.
Ensure that logs that might contain IP and DNS records are not exposed outside of operational needs.
1.4 Install personal firewall software or equivalent functionality on any portable computing devices that connect to the Internet when outside the network, and which are also used to access the CDE.
The private cluster is managed by the AKS control plane.
You don't have access to nodes directly.
For doing administrative tasks you'll need to use management tools such as kubectl from a separate compute resource.
Use an air-gapped jump box where you can run the AKS control plane commands.
Inbound and outbound traffic from the jump box must be restricted and secure.
If VPN is used for access, make sure the client machine is managed by corporate policy and all conditional access policies are in place.
Jump box is in a separate subnet in the spoke network.
Inbound access to the jump box is restricted by using an NSG that only allows access through Azure Bastion over SSH.
Outbound traffic from the jump box is restricted by using a UDR that forces HTTPs traffic to go through Azure Firewall. Including public endpoints managed by the Azure management plane (Azure Backbone).
1.5 Ensure that security policies and operational procedures for managing firewalls are documented, in use, and known to all affected parties.
Maintain thorough documentation about the process and policies.
Document the management of Azure Firewall rules that segment the AKS cluster.
People operating regulated environments must be educated, informed, and incentivised to support the security assurances.