|
| 1 | +--- |
| 2 | +title: Azure Payment HSM traffic inspection |
| 3 | +description: Guiance on how to bypass the UDR restriction and inspect traffic destined to an Azure Payment HSM. |
| 4 | +services: payment-hsm |
| 5 | +ms.service: payment-hsm |
| 6 | +author: dawlysd |
| 7 | +ms.author: dasantiago |
| 8 | +ms.topic: quickstart |
| 9 | +ms.date: 04/06/2023 |
| 10 | +--- |
| 11 | + |
| 12 | +# Azure Payment HSM traffic inspection |
| 13 | + |
| 14 | +Azure Payment Hardware Security Module (Payment HSM or PHSM) is a [bare-metal service](overview.md) providing cryptographic key operations for real-time and critical payment transactions in the Azure cloud. For more information, see [What is Azure Payment HSM?](overview.md). |
| 15 | + |
| 16 | +When Payment HSM is deployed, it comes with a host network interface and a management network interface. There are several deployment scenarios: |
| 17 | + |
| 18 | +1. [With host and management ports in same VNet](create-payment-hsm.md?tabs=azure-cli) |
| 19 | +2. [With host and management ports in different VNets](create-different-vnet.md?tabs=azure-cli) |
| 20 | +3. [With host and management port with IP addresses in different VNets](create-different-ip-addresses.md?tabs=azure-cli) |
| 21 | + |
| 22 | +In all of the above scenarios, Payment HSM is a VNet-injected service in a delegated subnet: `hsmSubnet` and `managementHsmSubnet` must be delegated to `Microsoft.HardwareSecurityModules/dedicatedHSMs` service. |
| 23 | + |
| 24 | +> [!IMPORTANT] |
| 25 | +> The `FastPathEnabled` feature must be [registered and approved](register-payment-hsm-resource-providers.md?tabs=azure-cli#register-the-resource-providers-and-features) on all subscriptions that need access to Payment HSM. You must also enable the `fastpathenabled` tag on the VNet hosting the Payment HSM delegated subnet and on every peered VNet requiring [connectivity to the Payment HSM devices](peer-vnets.md?tabs=azure-cli). |
| 26 | +> |
| 27 | +> For the `fastpathenabled` VNet tag to be valid, the `FastPathEnabled` feature must be enabled on the subscription where that VNet is deployed. Both steps must be completed to enable resources to connect to the Payment HSM devices. For more information, see [FastPathEnabled](fastpathenabled.md). |
| 28 | +
|
| 29 | +PHSM isn't compatible with vWAN topologies or cross region VNet peering, as listed in the [topology supported](solution-design.md#supported-topologies). Payment HSM comes with some policy [restrictions](solution-design.md#constraints) on these subnets: **Network Security Groups (NSGs) and User-Defined Routes (UDRs) are currently not supported**. |
| 30 | + |
| 31 | +It's possible to bypass the current UDR restriction and inspect traffic destined to a Payment HSM. This article presents two ways: a firewall with source network address translation (SNAT), and a firewall with reverse proxy. |
| 32 | + |
| 33 | +## Firewall with source network address translation (SNAT) |
| 34 | + |
| 35 | +This design is inspired by the [Dedicated HSM solution architecture](../dedicated-hsm/networking.md#solution-architecture). |
| 36 | + |
| 37 | +The firewall **SNATs the client IP address** before forwarding traffic to the PHSM NIC, guaranteeing that the return traffic will automatically be directed back to the Firewall. Either an Azure Firewall or a third party FW NVA can be used in this design. |
| 38 | + |
| 39 | +:::image type="content" source="./media/firewall-snat-architecture-diagram.png" alt-text="Architecture diagram of the firewall with SNAT" lightbox="./media/firewall-snat-architecture-diagram.png"::: |
| 40 | + |
| 41 | +Route tables required: |
| 42 | +- On-premises to PHSM: a Route Table containing a UDR for the Payment HSM VNet range and pointing to the central hub Firewall is applied to the GatewaySubnet. |
| 43 | +- Spoke VNet(s) to PHSM: a Route Table containing the usual default route pointing to the central hub Firewall is applied to the Spoke VNet(s) subnets. |
| 44 | + |
| 45 | +Results: |
| 46 | +- UDRs not being supported on the PHSM subnet is addressed by the Firewall doing SNAT on the client IP: when forwarding traffic to PHSM, the return traffic will automatically be directed back to the Firewall. |
| 47 | +- Filtering rules that cannot be enforced using NSGs on the PHSM subnet can be configured on the Firewall. |
| 48 | +- Both Spoke traffic and on-premises traffic to the PHSM environment are secured. |
| 49 | + |
| 50 | +## Firewall with reverse proxy |
| 51 | + |
| 52 | +This design is a good option when performing SNAT on a Firewall that has not been approved by network security teams, requiring instead to keep the source and destination IPs unchanged for traffic crossing the Firewall. |
| 53 | + |
| 54 | +This architecture uses a reverse proxy, deployed in a dedicated subnet in the PHSM VNet directly or in a peered VNet. Instead of sending traffic to the PHSM devices, the destination is set to the reverse proxy IP, located in a subnet that does not have the restrictions of the PHSM delegated subnet: both NSGs and UDRs can be configured, and combined with a Firewall in the central hub. |
| 55 | + |
| 56 | +:::image type="content" source="./media/firewall-reverse-proxy-architecture-diagram.png" alt-text="Architecture diagram of the firewall with reverse proxy" lightbox="./media/firewall-reverse-proxy-architecture-diagram.png"::: |
| 57 | + |
| 58 | +This solution requires a reverse proxy, such as: |
| 59 | + |
| 60 | +- F5 (Azure Marketplace; VM-based) |
| 61 | +- NGINXaaS (Azure Marketplace; PaaS fully managed) |
| 62 | +- Reverse proxy Server using NGINX (VM-based) |
| 63 | +- Reverse proxy Server using HAProxy (VM-based) |
| 64 | + |
| 65 | +Example of reverse proxy Server using NGINX (VM-based) configuration: |
| 66 | + |
| 67 | +```conf |
| 68 | +# Nginx.conf |
| 69 | +stream { |
| 70 | + server { |
| 71 | + listen 1500; |
| 72 | + proxy_pass 10.221.8.4:1500; |
| 73 | + } |
| 74 | +
|
| 75 | + upstream phsm { |
| 76 | + server 10.221.8.5:443; |
| 77 | + } |
| 78 | +
|
| 79 | + server { |
| 80 | + listen 443; |
| 81 | + proxy_pass phsm; |
| 82 | + proxy_next_upstream on; |
| 83 | + } |
| 84 | +} |
| 85 | +``` |
| 86 | + |
| 87 | +Route tables required: |
| 88 | +- On-premises to PHSM: a Route Table containing a UDR for the Payment HSM VNet range and pointing to the central hub Firewall is applied to the GatewaySubnet. |
| 89 | +- Spoke VNet(s) to PHSM: a Route Table containing the usual default route pointing to the central hub Firewall is applied to the Spoke VNet(s) subnets. |
| 90 | + |
| 91 | +> [!IMPORTANT] |
| 92 | +> Gateway Route propagation must be disabled on the reverse proxy subnet, so that a 0/0 UDR is enough to force the return traffic via the firewall. |
| 93 | +
|
| 94 | +Results: |
| 95 | +- UDRs not being supported on the PHSM subnet can be configured on the reverse proxy subnet. |
| 96 | +- The reverse proxy SNATs the client IP: when forwarding traffic to PHSM, the return traffic will automatically be directed back to the reverse proxy. |
| 97 | +- Filtering rules that cannot be enforced using NSGs on the PHSM subnet can be configured on the Firewall and/or on NSGs applied to the reverse proxy subnet. |
| 98 | +- Both Spoke traffic and on-premises traffic to the PHSM environment are secured. |
| 99 | + |
| 100 | +## Next steps |
| 101 | + |
| 102 | +- [What is Azure Payment HSM?](overview.md) |
| 103 | +- [Azure Payment HSM solution design](solution-design.md) |
| 104 | +- [Azure Payment HSM deployment scenarios](deployment-scenarios.md) |
| 105 | +- [Get started with Azure Payment HSM](getting-started.md) |
| 106 | +- [Create a payment HSM](create-payment-hsm.md) |
| 107 | +- [Frequently asked questions](faq.yml) |
0 commit comments