2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@Azuroinアディクシィ株式会社

ExpressRoute接続のHub & Spoke環境で実現するPalo Alto VM-SeriesによるSSLインスペクション活用術

Last updated at Posted at 2025-08-28

本記事では、オンプレミスとAzureをExpressRouteで接続し、クラウド側でPalo Alto Networks製ネットワーク仮想アプライアンス（NVA: VM-Series）を用いてSSLインスペクションを行う高度なセキュリティ設計を解説します。

ハブ＆スポークアーキテクチャを前提とし、Hub VNet上にPalo Altoファイアウォールを配置し、スポークサブネットからのトラフィックをNVA経由に強制してインターネットアクセスやオンプレ連携を包括的に制御する流れを示します。

オンプレミス環境にも既存ファイアウォール（物理Palo Altoや他ベンダー機器など）が稼働しているケースを想定し、ポリシー整合や可用性セット活用、Azure Load Balancerを用いた冗長化、SSL復号ポリシーの注意点など、多面的な視点を深堀りします。

1. Azure上でPalo Alto VM-Seriesを活用する意義

1.1 On-premファイアウォールからクラウドへの機能拡張
大企業のハイブリッドネットワークでは、オンプレミスのデータセンターに導入されてきた高度なファイアウォール機能（アプリケーション制御、SSL/TLS復号検査、脅威防御など）をAzureにも拡張したいニーズが増えています。

Azure標準のマネージドFWであるAzure Firewallは構成が簡潔ですが、従来から使い慣れたPalo Alto NetworksのNGFWをVM-Seriesとしてクラウド上に導入することで、高度なポリシー運用の連携や統一管理が可能になります。

例えばPanoramaを介したオンプレおよびクラウド環境のポリシー一元管理や、独自のUTM機能・ワイルドファイア連携などが活かせる点が大きな利点です。

1.2 SSLインスペクションの重要性
近年の通信の多くが暗号化（HTTPS/TLS）されている中で、ネットワーク境界での脅威検知にはSSL復号が鍵となります。

クラウド上に配置したVM-SeriesでSSLインスペクションを行い、マルウェア配布サイトや不正アクセスを可視化・遮断できれば、ゼロトラストに近い保護が得られます。オンプレだけでなくクラウド内のワークロードからのOutbound通信も暗号化されがちなため、ここで復号機能を確保することで東西・南北トラフィックを包括的に監視・制御できます。

2. Hub & Spoke + ExpressRoute接続における全体像

2.1 ハブVNetにNVAを配置
Azureでのハブ＆スポークアーキテクチャでは、Hub VNetにネットワークサービス（ExpressRoute Gateway、VPN Gateway、Azure Firewall、あるいはサードパーティNVAなど）を集約し、スポークVNetはそこを通じてオンプレやインターネットと通信します。

Palo Alto VM-SeriesをハブVNetにデプロイし、スポークのサブネットからのトラフィックをUser Defined Route(UDR)で強制的にNVAへ誘導する構成が基本です。

これによりInbound・Outbound・East-Westを一括でファイアウォール検査できます。Outbound側ではインターネットアクセスをNVA経由にしてSSLインスペクションを実施、Inbound側では外部からの接続をLoad Balancer→NVAにルーティングし、アプリサブネットへの到達を制御します。

2.2 ExpressRouteの有効活用
オンプレとの安定的な接続にはExpressRouteが最適ですが、単一回線の障害リスクを下げるため、複数回線・VPNバックアップなどを併用する高可用性設計が望ましいです。

いずれにせよ、オンプレ→Azureでやってきたトラフィックを必ずNVAに集約し、オンプレからの大容量通信やOutlook/Microsoft 365系SaaSアクセスも含めてクラウドNVAで踏むシナリオも考えられます（オフィスのインターネットブレイクアウトをAzureにオフロードする形）。

この際にAzureおよびNVAでどこまでNAT/SNATするか、オンプレ側でどのようにルート広告するかなどを検討し、非対称経路や二重NATを防ぐ必要があります。

3. VM-Seriesの高可用性とゾーン冗長設計

注：Azure上のVM‑SeriesにおけるHAの用語整理
本記事で扱うHAは、(A) Active/Passive（A/P）HAペア と、(B) Azureのロードバランサを用いたスケールアウト（通称“Active/Active”運用） の2系統です。

A/P HAペア：セッション同期あり。同一リソースグループかつ同一PAN‑OS/VM‑Seriesプラグインで構成し、東西のみならUDR更新で高速切替、北南を含むなら浮動IP再アタッチに数分かかる場合があります。A/Pは “異なる可用性ゾーン（AZ）に跨って配置可能” です。

“Active/Active”表記：Azureでは伝統的なA/A HAペア（状態同期A/A）を前提とせず、Azure Load Balancer / Gateway Load Balancer 等のクラウドネイティブLBで複数インスタンスに分散するアーキテクチャを指します（ノード障害時は当該セッションは切断され得る前提）。

3.1 Active/Passive vs Active/Active
Azure上のPalo AltoはActive/Passive HAペア構成が従来の主流で、セッション同期が可能です。

しかしフェイルオーバーに数十秒～数分程度のダウンが発生する場合があり、アプリに影響しうる点に留意が必要です。

加えてAzureではL2グラティアルスARPが使えないため、フェイルオーバー時にPublic IPをプライマリからセカンダリへ移すためのAPI呼び出しが入るなど特有の実装となります。

これに対しActive/Active(スケールアウト)方式はロードバランサを活用し複数ファイアウォールでトラフィックを分散する形をとります。

セッションを同期しないためインスタンス障害時に当該セッションは切れますが、冗長性と性能面ではより優れています。

FAQ：A/Pは「同一AZのみ」では？
旧資料では同一AZ強制の時期がありましたが、現行ドキュメントではA/Pを“異なるAZに跨って”配置可能と明記されています。運用中のPAN‑OS/VM‑Seriesプラグインのバージョン差により挙動・前提が変わるため、導入時は最新版ドキュメントの要件とプラグイン同一バージョンを必ず確認してください。

3.2 可用性ゾーン活用
可能なリージョンであれば、可用性ゾーンをまたいだ配置が理想的です。Palo Alto公式の設計ガイドでは「各ゾーンに片系ずつVM-Seriesを配置し、Azure Standard Load Balancerゾーン冗長を利用してインバウンド/アウトバウンドをまとめる」例が示されます。

これによりDCレベル障害に耐えうる HAが得られます。

ゾーンごとにパブリックIPが別になる場合はLBのフロントエンドIPで単一化する形となり、内部通信もInternal LBを併用します。

4. トラフィック制御（UDR・戻り経路・SNAT設計）

4.1 UDR強制ルート
スポークのサブネットにはデフォルトルート(0.0.0.0/0)をVM-SeriesのTrust側IPやInternal LB IPへ向けるUDRを適用します。AzureのBGP経路よりUDRが優先されるため、オンプレ宛／インターネット宛を一旦NVAに送れる形です。

オンプレミス用プレフィックスもUDRでNVAへ誘導するか、BGP経路を優先するかは要件次第です。一般にすべてNVAでスキャンしたいなら全通信をNVAに集約するコンセプトが自然です。

4.2 非対称経路とSNAT
Outbound通信でファイアウォールがSSLインスペクションしつつセッション管理するため、戻り通信が常に同じVM-Seriesインスタンスに返ってくるよう設計します。

ロードバランサ(Internal LB)経由型なら5タプルハッシュで同一インスタンスがアサインされるのでSNAT不要の場合もあります。反面、Active/ActiveスケールアウトでLBをInboundのみに使う構成などでは、各ファイアウォールでOutbound SNATするほうが確実に対称ルーティングを保ちやすいです。

大規模環境ではSNATポート枯渇対策として複数パブリックIPを割り当てる等が必要になります。

4.3 インバウンドはPublic LB or Direct IP
外部からの接続（Inbound）もAzure Standard Load Balancerを使うか、各FWインスタンスにPublic IPを直付けするかで大きく設計が変わります。

LBを使うとHAが簡易化し単一のGlobal IPを共有できますが、SNAT・プローブ・ヘルスチェック設定のオーバーヘッドが増えます。

直付け方式は単純だがフェイルオーバー時にIP移動が必要、さらにスケールアウトが難しいなどのトレードオフがあります。

5. SSL復号ポリシー適用上のポイント

5.1 ルート証明書配布・信頼設定
Palo AltoのSSL Forward Proxy機能を有効にするには、復号時に差し替える中間証明書をファイアウォールにインポートし、クライアント側にもそのCAを信頼させる必要があります。

オンプレドメイン端末はGPOで証明書を配布できるが、AzureのVM群や一部BYOD端末にも導入が必要です。自己署名CAではなく企業の内部CAが理想的で、チェーンが整合するよう管理を徹底します。

5.2 Pinningや例外サイト
金融系サービスやセキュリティ製品では証明書ピンニングを実施しており、中間者復号を拒否されるケースがあります。こうした通信はSSL Decryption Policyで除外（no-decrypt）する必要があります。

Palo AltoではURL/Categoryベースの除外設定が容易なので、事前にマルチクラウドサービスや重要機関サイト等のカテゴリを洗い出し、復号しないルールに加えておきます。

5.3 パフォーマンスとSKU選定
SSL復号はCPUに負荷が高く、大量のHTTPSアクセスを捌くには大きめSKU (例: VM-500/700)やDSv3以上インスタンスが要る場合があります。

Palo Altoの計算ツールやPoC測定で最大同時セッションやTLSハンドシェイク負荷を見極め、リソース不足によるスループット低下や高CPUアラートを未然に防ぎます。

スケールアウトする場合も、ロードバランサのセッションハッシュ計算やSNAT資源を十分見込むことが重要です。

6. オンプレミス機器との設定移行・ポリシー連携

6.1 Panoramaによる一元管理
同じPalo Altoをオンプレとクラウド両方に持っているなら、Panoramaを使ってセキュリティポリシーやオブジェクトを一元管理できます。

PanoramaにはAzureにデプロイできる仮想アプライアンス版もあり、オンプレFWとVM-SeriesのアプリケーションフィルタやURLカテゴリ、脅威プロファイルなどを共通化可能です。

移行時はオンプレのポリシーをPanoramaに統合し、新規にクラウド用のゾーン/インターフェース名を紐づける形で整合させます。

6.2 異ベンダー連携
オンプレが他社ファイアウォール（Fortinet/Cisco等）でも、Azure上のVM-Seriesを導入できますが、ポリシー整合は手動で行う必要があります。

例えばオンプレのACLやURLフィルタをクラウドで同様に記述し、脅威対策レベルを合わせたりする作業が発生します。

また、セッションの引き継ぎは当然できないため、オンプレFW→クラウドFWへ途中で経路切り替えする際は新たにTCP接続を張り直す点に留意します。

6.3 段階移行
最初はテストスポークVNetで小規模に導入し、問題無ければ本番サブネットへUDRを切り替えていく方法が安全です。

オンプレ発→Azure行きのトラフィックを徐々にNVAルートに変更し、クラウドFW上でログを確認。問題がなければ社内全サブネットを対象とする形に拡大できます。

7. Azure Firewallとの住み分け（ハイブリッド構成例）

7.1 双方の強みを活かす
Azure Firewallはマネージドでスケーラブル、FQDNタグやThreat Intelligenceによる簡易制御が強み。

一方、Palo Altoには細かいアプリ識別・ユーザID連携・SSL復号制御が充実。要件次第では両者を併用して多層防御を行えます。

例えばOffice 365などAzureサービスタグで管理しやすい通信はAzure Firewallが受け、一般Webや社内システム通信はVM-Seriesが検査する、といった分散もあり得ます。

構成上はルーティングループを防ぐため、いずれかがOutbound NATし一方はBypassとするなど役割を明確にする必要があります。

7.2 簡易と高度の両立
大半のシンプルなポートフィルタやFQDN許可はAzure Firewall、詳細なSSLインスペクションやエグゼクティブ端末への高レベル防御はVM-Series、と住み分ける例もあります。

ただし管理が煩雑になりやすいので、よく要件を吟味し、二重運用のメリットが上回るか検討しましょう。

サードパーティNVAの費用も考慮し、コストパフォーマンスや導入運用体制をバランスさせます。

8. スケーラビリティ・SNAT枯渇・オートスケールへの対処

8.1 スケールアウトアプローチ
用語注記：本節の“Active/Active”はA/AのHAペア構成を意味しません。Azure（Gateway）Load Balancer によるスケールアウト運用を指します（状態同期は行わない／LBのハッシュで同一フローを同一ノードに送る設計）。

大量トラフィックやピーク時負荷が想定される場合はロードバランサを用いたActive/Activeスケールアウトが有力です。複数VM-Seriesをバックエンドプールに登録し、5タプルごとに振り分ける。

セッションの継続性は同一ハッシュでアフィニティが保たれるため問題ありません。

ただし個別インスタンス障害時に該当セッションは切れる点を許容する必要があります。

クラウド環境で大量のトラフィックをさばくには最も現実的な選択肢であり、スケールアウト数を増やせば理論的には数Gbps～数十Gbps級まで拡張可能です。

ただし各VMのAzure NIC上限やPalo AltoライセンスSKUの上限もあるため、あらかじめPoCで実測することが推奨されます。

8.2 オートスケール
Palo Alto自身は標準機能としてオートスケールを実装していませんが、TerraformテンプレートやPanoramaスクリプトと組み合わせ、VMSSで仮想マシンを自動追加/削除するシナリオがコミュニティで検証済みです。

大きな実装コストがかかるほか、セッションを跨いだスケールインで問題ないか（セッションが落ちてもよいか）を検討する必要があります。

最終的にはPanorama APIを用いて新VMを自動登録し、ポリシー同期・ライセンス付与するフローを構築します。

大規模CDNやSaaS事業者であれば導入事例もあり得ますが、通常のエンタープライズ環境ではまず固定本数のFWインスタンスで十分対応できることが多いでしょう。

8.3 SNAT枯渇回避
大量のOutboundセッションが一つのIPでNATされると送信元ポート数(65535)が不足します。対策として複数パブリックIPプールをファイアウォールに設定し、ラウンドロビンで変換アドレスを使う形が有効です。

またAzure NAT Gatewayには数十万ポート枯渇対策機能があるものの、Palo Altoがトラフィックを握る本構成ではNAT Gatewayを挟めないため、自力でパブリックIPを増やすしかありません。

もし複数インスタンスに分散できるなら、各FWがそれぞれ別IPプールでNATする形にすれば1台あたりのポート枯渇を防ぎやすくなります。

9. 導入事例・運用Tips

Palo Alto HAでヘルスプローブ設定: Azure Load Balancerでヘルスチェックを実施する際、FWが168.63.129.16宛のプローブを逆インターフェースから返してしまい、LB判定が常時Failになる例があります。

対応として宛先168.63.129.16のパケットを必ず受信IFから返すPBFを設定するのが定石です。

MTUマイグレーションで大容量East-West通信: 大規模DBレプリケーションをAzureへ移したが、VM-Series経由で暗号化通信がMTU断片化を起こして性能劣化したケース。

MSSクランプをFW側で適切に設定し解決。

フェイルオーバーテスト計画: HAペアのPrimaryを意図的にシャットダウンし、数秒～数十秒で切り替わるか確認。オンプレルーターやDNSなども含め総合テストしておくことで、本番障害時に問題なく立ち上がる。

TerraformとPanorama連携: TerraformでVNet・NIC・LBを作成後、Panoramaでインターフェース設定・ポリシー投入を自動実行する仕組みがある。大規模環境で更新が頻繁な場合に有効。

ログ分析: Azure Monitor + Sentinelと連携し、Palo AltoのCEFログを集約。Outbound SSL復号でブロックした脅威サイトやマルウェア通信をSIEMダッシュボードに表示し、NOC/SOCチームが素早く検知・対応できるよう運用する。

まとめ

Hub & Spokeアーキテクチャ + ExpressRoute接続という大規模なAzureネットワーク環境で、Palo Alto VM-SeriesをNVAとして導入し、SSLインスペクションをはじめとする高度なNGFW機能を実装するには以下の総合的な設計が鍵となります。

可用性設計: Active/Passive or Active/Active構成、可用性ゾーン（AZ）活用、冗長NIC・負荷分散設計などでクラウド固有の制約を克服しつつHAを担保。

ルーティング/UDR: スポークからNVAへの強制経路と、戻り経路の対称性を確保するSNAT・LB設定。ExpressRouteやVPNを併用するならBGPコスト調整で経路が二重化しないよう留意。

SSL復号ポリシー: 企業CAから発行された中間証明書を用いてForward Proxyモードを実装。証明書の配布や除外ドメイン設定、Pinningサイト対策。

オンプレ機器との連携: Panoramaでポリシー集中管理、あるいは異ベンダーFWとはポリシーの二重管理。セッション同期は不可なので非対称経路を防ぐ工夫が不可欠。

スケーラビリティ: 大量通信に備えスケールアウトやSNATポート拡張を検討。オートスケールは高度だがTerraformやPanorama連携で可能性あり。

運用ログ/監視: Syslog, CEF, Azure Monitor, Sentinelを活用して可視化・アラート運用し、障害や脅威を早期検知。定期フェイルオーバーテストで確実性を高める。

これらを組み合わせることで、オンプレミスからクラウドへのセキュアな移行やゼロトラストに近いアプリケーションレイヤ防御を実現でき、企業ネットワークのクラウド活用を一層推進できます。
複雑な構成ゆえPoCで小規模検証を行い、設計を煮詰めたうえで本番環境をIaCでデプロイするとリスクを抑えられるでしょう。

参考リンク集（公式）

アーキテクチャ / Hub & Spoke / 経路制御

ExpressRoute（設計・共存）

NVA / ロードバランサ

Palo Alto VM‑Series on Azure（HA / テンプレート）

SSL/TLS 復号（インスペクション）

ルーティング/対称性/トラブルシュート

ログ / SIEM（Microsoft Sentinel）

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?