Azure Payment HSM のトラフィック検査
Azure Payment Hardware Security Module (Payment HSM または PHSM) は、Azure クラウドでのリアルタイムかつ重要な支払いトランザクションに暗号化キー操作を提供するベアメタル サービスです。 詳細については、「Azure Payment HSM とは」を参照してください。
Payment HSM のデプロイ時には、ホスト ネットワーク インターフェイスと管理ネットワーク インターフェイスが付属します。 次のような、いくつかのデプロイ シナリオがあります。
上記のすべてのシナリオにおいて、Payment HSM は、委任されたサブネット内の VNet インジェクション サービスです。hsmSubnet と managementHsmSubnet を Microsoft.HardwareSecurityModules/dedicatedHSMs サービスに委任する必要があります。
重要
この FastPathEnabled 機能は、Payment HSM へのアクセスが必要なすべてのサブスクリプションで登録および承認されている必要があります。 また、Payment HSM 委任サブネットをホストしている VNet と、Payment HSM デバイスへの接続を必要とするすべてのピアリングされた VNet で fastpathenabled タグを有効にする必要があります。
fastpathenabled VNet タグを有効にするには、その VNet がデプロイされているサブスクリプションで FastPathEnabled 機能を有効にする必要があります。 リソースが Payment HSM デバイスに接続できるようにするには、両方の手順を完了する必要があります。 詳細については、「FastPathEnabled」を参照してください。
PHSM は、サポートされているトポロジに記載されているように、vWAN トポロジやリージョン間 VNet ピアリングと互換性がありません。 Payment HSM は、次のサブネットに関していくつかのポリシー制限があります。ネットワーク セキュリティ グループ (NSG) とユーザー定義ルート (UDR) は現在サポートされていません。
現在の UDR 制限をバイパスして、Payment HSM 宛てのトラフィックを検査できます。 この記事では、送信元ネットワーク アドレス変換 (SNAT) を使用したファイアウォールとリバース プロキシを使用したファイアウォールの 2 つの方法について説明します。
送信元ネットワーク アドレス変換 (SNAT) を使用したファイアウォール
この設計は、Dedicated HSM ソリューション アーキテクチャに着想を得ています。
ファイアウォールは、PHSM NIC にトラフィックを転送する前にクライアント IP アドレスを SNAT し、戻りトラフィックが自動的にファイアウォールに送り返されることを保証します。 この設計では、Azure Firewall またはサードパーティの FW NVA のいずれかを使用できます。
必要なルート テーブル:
- オンプレミスから PHSM: Payment HSM の VNet 範囲の UDR を含み、中央ハブのファイアウォールを指すルート テーブルが、GatewaySubnet に適用されます。
- スポーク VNet から PHSM: 中央ハブのファイアウォールを指す通常の既定のルートを含むルート テーブルが、スポーク VNet サブネットに適用されます。
結果:
- PHSM サブネットでサポートされていない UDR がクライアント IP で SNAT を実行しているファイアウォールによってアドレス指定されている場合: PHSM にトラフィックを転送すると、戻りトラフィックは自動的にファイアウォールに送り返されます。
- PHSM サブネット上の NSG を使用して適用できないフィルター規則は、ファイアウォールで構成できます。
- スポーク トラフィックと PHSM 環境へのオンプレミス トラフィックの両方がセキュリティで保護されます。
リバース プロキシを使用したファイアウォール
この設計は、ネットワーク セキュリティ チームによって承認されていないファイアウォールで SNAT を実行する場合に適したオプションです。代わりに、ファイアウォールを通過するトラフィックに対して送信元 IP と宛先 IP を変更しないようにする必要があります。
このアーキテクチャでは、PHSM VNet 内の専用サブネットに直接またはピアリングされた VNet にデプロイされたリバース プロキシが使用されます。 PHSM デバイスにトラフィックを送信する代わりに、リバース プロキシ IP に宛先が設定されます。これは、PHSM 委任サブネットの制限がないサブネットにあります。NSG と UDR の両方を構成し、中央ハブのファイアウォールと組み合わせることができます。
このソリューションには、次のようなリバース プロキシが必要です。
- F5 (Azure Marketplace、VM ベース)
- NGINXaaS (Azure Marketplace、PaaS フル マネージド)
- NGINX を使用したリバース プロキシ サーバー (VM ベース)
- HAProxy を使用したリバース プロキシ サーバー (VM ベース)
NGINX (VM ベース) 構成を使用して TCP トラフィックを負荷分散するリバース プロキシ サーバーの例。
# Nginx.conf
stream {
server {
listen 1500;
proxy_pass 10.221.8.4:1500;
}
upstream phsm {
server 10.221.8.5:443;
}
server {
listen 443;
proxy_pass phsm;
proxy_next_upstream on;
}
}
必要なルート テーブル:
- オンプレミスから PHSM: Payment HSM の VNet 範囲の UDR を含み、中央ハブのファイアウォールを指すルート テーブルが、GatewaySubnet に適用されます。
- スポーク VNet から PHSM: 中央ハブのファイアウォールを指す通常の既定のルートを含むルート テーブルが、スポーク VNet サブネットに適用されます。
重要
ゲートウェイ ルートの伝達はリバース プロキシ サブネットで無効にする必要があります。これにより、0/0 UDR でファイアウォール経由の戻りトラフィックを強制できます。
結果:
- PHSM サブネットでサポートされていない UDR は、リバース プロキシ サブネットで構成できます。
- リバース プロキシでクライアント IP を SNAT する場合: PHSM にトラフィックを転送すると、戻りトラフィックは自動的にリバース プロキシに送り返されます。
- PHSM サブネットで NSG を使用して適用できないフィルター規則は、ファイアウォールやリバース プロキシ サブネットに適用される NSG で構成できます。
- スポーク トラフィックと PHSM 環境へのオンプレミス トラフィックの両方がセキュリティで保護されます。