Azure ネットワーク設計ガイド
- 山崎行政書士事務所
- 9月11日
- 読了時間: 8分
— App Gateway (WAF) / Azure Firewall / NSG / VPN・ExpressRoute 連携 —
著者：山崎行政書士事務所 クラウド法務・アーキテクチャ支援チーム
発行日：2025-09-11
要旨（Abstract）
本稿は、エンタープライズ Azure 環境における VNet／サブネット分割／NSG／Azure Firewall／WAF（Application Gateway）／オンプレ接続（VPN・ExpressRoute） を統合した実装可能な設計論を示す。特に Application Gateway (以下、AppGW) の専用サブネット設計、NSG の最小許可ルール、UDR の是非、**Azure Firewall（Premium の IDPS/TLS 検査を含む）**との組み合わせ、NAT Gateway 優先度、GatewaySubnet の制約を、**運用証跡（Evidence Pack）**まで含めて体系化する。最後に、法務×技術の両利きで設計と監査適合をやり切るための支援方法（PR）を付す。
キーワード：VNet, Subnet, NSG, Application Gateway, WAF_v2, Azure Firewall, IDPS, TLS Inspection, NAT Gateway, DDoS Protection, Private Link, VPN Gateway, ExpressRoute, UDR, Service Tags, GatewaySubnet, AzureBastionSubnet, Virtual Network Flow Logs
0. 要点（はじめに）
VNet のアドレス計画は重複回避と将来拡張を最優先（十分な CIDR / 空き IP を確保）。
AppGW は専用サブネット必須。NSG/UDR の制約があるため設計順序に注意。
Azure Firewall はハブ集約し、アウトバウンド集中制御（URL/FQDN、IDPS、TLS 検査［Premium］）を担う。
オンプレ接続（VPN/ExpressRoute）は GatewaySubnet に集約。GatewaySubnet への NSG と 0.0.0.0/0 UDR は非サポート。
DDoS（Network/IP Protection）＋WAF（Prevention）で L3/4 と L7 を多層防御。
ログは Virtual Network Flow Logs（NSG Flow Logs は段階的廃止予定）へ集約し、Sentinel/Log Analytics で相関分析。
1. ネットワーク構成図（ハブ＆スポーク例）
Internet
│ (Public IP, DDoS)
┌──────▼─────────┐
│ App Gateway │ WAF_v2 (Prevention)
│ (Subnet: AppGW)│ FE: Public / Private
└──────┬─────────┘
│ (L7 ルーティング)
┌─────────┼───────────┐
│ │ │
[Web Subnet] │ (Option) Private Link 経由の
│ (AppGWのみ許可) PaaS/PE 到達
▼ │
[App Subnet] │
│ │
▼ │
[Data Subnet] │
│ │
UDR: 0.0.0.0/0 → Firewall
│
┌────▼─────────────────────┐
│ Azure Firewall │ Premium: IDPS / TLS Inspection
│ (AzureFirewallSubnet) │ (NAT Gateway 併用可)
└────┬─────────────────────┘
│
│ GatewaySubnet (NSG/0.0.0.0/0 UDR 非サポート)
┌────▼───────┐
│ VPN/ER GW │ （Allow gateway transit / Use remote gateways）
└────┬───────┘
│
On-Prem
2. VNet / IP アドレス設計
2.1 CIDR 設計の原則
例：VNet 全体 10.0.0.0/16。オンプレ／他 VNet との重複は厳禁。
将来のスケール（サブネット追加／AppGW・Firewall のスケールアウト）を見込んで余裕あるプレフィックスを確保。
2.2 サブネット例（用途別に最小権限で分離）
AppGW Subnet（専用）：例 10.0.0.0/24 （AppGW 以外のリソース不可、v1 と v2 の混在不可）
AzureFirewallSubnet（専用名・/26 必須）：例 10.0.1.0/26
AzureFirewallManagementSubnet（/26 必須；強制トンネル時など）：例 10.0.2.0/26
GatewaySubnet（必須名）：例 10.0.255.0/27
AzureBastionSubnet（/26 以上・必須名）
Web / App / Data / Management：用途ごとに分割（例：/27〜/26）
専用名が必要：AzureFirewallSubnet / AzureFirewallManagementSubnet / GatewaySubnet / AzureBastionSubnet。AppGW サブネットは AppGW 専用、UDR は原則適用しない（詳細は §3 を参照）。
3. AppGW / NSG / UDR / Firewall 設計（重要ポイント）
3.1 AppGW（WAF）サブネットと NSG
専用サブネット必須。
NSG ルール（代表例）Inbound（サブネットに対して）
GatewayManager → 65200–65535/TCP Allow（AppGW 管理・正常性）
AzureLoadBalancer Allow（既定ルールを上書きしない）
クライアント→リスナー：80/443 等（送信元：Internet または許可元 IP 範囲、宛先：AppGW サブネット or フロントエンド IP）
それ以外は Deny（最下位）Outbound
Internet Allow（AppGW の管理・更新・ログ送信に必要。明示 Deny 禁止）
バックエンド宛て Allow：Web/App など必要ポート（80/443 等）
UDR の取り扱い
AppGW サブネットへの UDR 適用は原則非推奨。特に 0.0.0.0/0 の強制トンネル（NVA/Firewall/オンプレ）は v2 で非サポート。
ハブ側から既定ルートが伝播する場合は BGP 伝播の無効化などで影響回避。
TLS/証明書
フロントエンドは信頼局発行のサーバ証明書（SAN を FQDN と整合）。Key Vault 連携推奨。
エンドツーエンド TLS 時はバックエンドの FQDN/SNI・信頼鎖に留意。
mTLS が必要な場合は WAF ポリシーの対応機能（最新状態を確認）またはアプリ側で実装。
Private 接続
AppGW Private Link を用いて、別 VNet/サブスクリプションからプライベート到達を構成可能（DNS 設計とセット）。
3.2 Azure Firewall（ハブ集中：Premium 推奨）
サブネット要件：AzureFirewallSubnet /26 必須。強制トンネルを構成する場合は AzureFirewallManagementSubnet /26 必須。
NSG：Firewall サブネットへ NSG は不要・非推奨（動作阻害リスク）。制御は Firewall ポリシー＋周辺 NSG/UDR で行う。
アウトバウンド集約：スポーク各サブネットの UDR で 0.0.0.0/0 → Firewall を明示。
Premium 機能：IDPS（署名ベース）、TLS Inspection、URL フィルタリング。TLS 検査では Key Vault 連携の中間 CA 設定とクライアント信頼が要件。
強制トンネル：Firewall 自体の 0.0.0.0/0 をオンプレへ送る構成では Management NIC 経由で管理通信を分離。DNAT は非対応（非対称ルーティング回避）。
3.3 NAT Gateway（イグレス固定化）
SNAT ポート拡張と送信元グローバル IP の固定化に有効。
優先度：NAT Gateway は Azure Firewall よりも優先されるため、Firewall 経由の統制が必要なら UDR で次ホップを Firewall に明示。
ハブ統合パターン：Firewall と統合しつつ スケーラブルなイグレスを実現。
3.4 Web / App / Data サブネットの NSG 最小例
Web：送信元＝AppGW サブネット（または AppGW の FE 範囲）の 80/443 のみ Allow。Internet からの直接到達は Deny。
App：送信元＝Web、宛先＝App の業務ポートのみ Allow。
Data：送信元＝App、宛先＝DB ポートのみ Allow（例：1433/5432）。それ以外 Deny。
管理系（Bastion/Jumpbox 等）は専用サブネットで分離。
4. オンプレミス接続（Site-to-Site VPN / ExpressRoute）
GatewaySubnet（必須名）を用意。NSG 適用と 0.0.0.0/0 の UDR は非サポート。
ハブ＆スポーク：ハブの VPN/ER GW に集約し、スポークは VNet ピアリングで連携。
ハブ側：Allow gateway transit
スポーク側：Use remote gateways
必要に応じて Allow forwarded traffic を有効化。
BGP：経路集約・フィルタ方針を設計。オンプレからの既定ルート広告はAppGW/Firewall 管理通信に悪影響を与えないよう配慮。
5. 代表的トラフィックフロー
(A) インターネット → Web システム
Client → AppGW (443/TLS)：WAF が L7 検査（Prevention）
AppGW → Web（80/443 等。送信元 AppGW のみを NSG で許可）
Web → App（最小ポート）
App → Data（DB ポート限定）
(B) アウトバウンド（外部 API/SaaS 等）
パターン1：Firewall 経由（各サブネット UDR で 0.0.0.0/0 → Firewall、Firewall で FQDN/カテゴリ制御）
パターン2：NAT Gateway 直接（送信元固定。統制要件に応じて選択）
(C) オンプレ ↔ Azure
On-Prem ⇄ GatewaySubnet（VPN/ER） ⇄ Hub ⇄ Spoke（Peering）
双方向とも NSG/Firewall で最小権限に。
6. セキュリティ／高可用性／運用ガイド
多層防御：DDoS（L3/4）＋WAF（L7）＋NSG（L3/4）＋Firewall（L3/4/7）。
WAF ポリシー：Detection→調整→Prevention の段階移行。誤検知はカスタムルール／除外で調整。
可用性：AppGW/Firewall の ゾーン冗長や SKU 選定を要件に合わせ最適化。
DNS/証明書：Key Vault で一元管理、自動ローテーション。
監視/ログ：Virtual Network Flow Logs、AppGW アクセス/WAF ログ、Firewall ログを Log Analytics に集約し、Sentinel で相関。
変更管理：UDR 変更が経路に与える影響を有効ルートで検証。
ガバナンス：Service Tags（Internet/VirtualNetwork/AzureMonitor/GatewayManager 等）と ASG を活用。Azure Policy で NSG 未割当や DDoS 未適用を検知。
Bastion：AzureBastionSubnet は /26 以上を厳守。
7. よくある落とし穴（チェックリスト）
AppGW サブネットへ 0.0.0.0/0 UDR（v2 強制トンネル非サポート）を入れていないか。
GatewayManager 65200–65535/TCP と AzureLoadBalancer Allow を AppGW サブネットの NSG で許可しているか。
GatewaySubnet に NSG または 0.0.0.0/0 UDR を設定していないか（非サポート）。
AzureFirewallSubnet / AzureFirewallManagementSubnet が /26 を満たし、NSG を付けていないか。
NAT Gateway 併用時に優先度で Firewall をバイパスしていないか（UDR 明示）。
Web サブネットで AppGW 以外からの 80/443 を拒否しているか。
NSG Flow Logs を継続利用していないか（Virtual Network Flow Logs へ移行済みか）。
DDoS Network/IP Protection をパブリック入口のある VNetで有効化しているか。
8. 参考 NSG/UDR の最小例（スケッチ）
AppGW Subnet — NSG（優先度は環境に合わせて調整）
Inbound:
Allow_In_GatewayManager_65200_65535 : Src=GatewayManager, Dst=Any, DstPort=65200-65535, TCP Allow
Allow_In_AzureLoadBalancer : Src=AzureLoadBalancer, Dst=Any, Any, Allow
Allow_In_Client_443_80 : Src=Internet or AllowList, Dst=AppGW Subnet/FE IP, 443,80, TCP Allow
Deny_In_All : Any → Any, Deny (lowest)
Outbound:
Allow_Out_Internet : Any → Internet, Any, Allow（明示 Deny 禁止）
Allow_Out_To_Backend : AppGW Subnet → Web/App Subnet, 443/80 等, Allow
Web Subnet — NSG
Inbound:
Allow_In_From_AppGW_443_80 : Src=AppGW Subnet, Dst=Web Subnet, 443/80, Allow
Deny_In_From_Internet : Src=Internet, Dst=Web Subnet, Any, Deny
Spoke 各サブネット — UDR（Firewall 経由の例）
0.0.0.0/0 → Next hop: Virtual appliance (Azure Firewall)
<On-Prem Prefixes> → Next hop: Virtual network gateway
注意：AppGW サブネットはUDR 原則なし。BGP 既定ルートの影響や例外シナリオは都度検証。
9. コスト観点（概略）
AppGW（WAF 有無、容量単位、オートスケール、ルール数）
Azure Firewall（データ処理量、ポリシー階層、IDPS/TLS）
NAT Gateway（時間課金＋データ処理・SNAT ポート）
Public IP（Standard / ゾーン冗長）、DDoS（Network/IP Protection）
Log Analytics／Sentinel（取り込み量・保持期間）→ 設計段階で トラフィック見積とログ保持方針を決め、料金計算ツールで事前試算。
10. まとめ
AppGW は専用サブネット＋正しい NSG（GatewayManager/ALB 許可、クライアント 80/443、その他 Deny）。UDR は原則不要。
アウトバウンドは Firewall に集約。NAT Gateway 併用時は優先度と UDRを明確化。
GatewaySubnet には NSG/0.0.0.0/0 UDR を付けない。
DDoS＋WAF＋NSG＋Firewall の多層化、Virtual Network Flow Logs への移行と Sentinel での継続監視を標準化。
Bastion / Firewall サブネットの /26 などサブネット命名・サイズ要件は初期段階で固定。
11. 山崎行政書士事務所のご支援（PR）
法務（DPA/SCC/契約・監査）× 技術（NSG/Firewall/WAF/UDR/Peering）を同じチームで設計・実装・証跡化します。
ゼロトラスト前提のネットワーク標準（AppGW/Firewall/NAT/Peering/Policy）を**テンプレート（Bicep/TF）**で提供。
Evidence Pack（アーキ図／NSG・UDR 定義／WAF/Firewall ポリシー／有効ルート／運用 Runbook／監査ダッシュボード）を監査提出レベルで整備。
既存環境の差分是正（例外の棚卸し・期限管理・再評価ループ）から移行計画まで伴走。
初回ディスカッション論点例・AppGW サブネットの NSG/UDR 設計は最新制約に適合しているか？・Firewall Premium の IDPS/TLS は要件か？証明書配布・検査対象の線引きは？・NAT 優先度と UDR の整合は取れているか？・GatewaySubnet／Bastion のサイズ・ポリシーは適正か？・Flow Logs の移行計画（NSG → VNet）は完了しているか？
コメント