Azure ネットワーク設計

１. Azure Virtual Network (VNet) 設計

1-1. アドレス設計 (IP Addressing)

1. CIDR ブロックの選定

   • 例：10.0.0.0/16 を VNet 全体に割り当てる。

   • オンプレミス環境との IP 重複を避け、将来の拡張余地 (サブネット追加・スケールアウト) を考慮した十分な範囲を確保する。

2. サブネットの切り分け
   一般的に、以下のようなサブネットを用意するケースが多いです（サンプルアドレス例を示します）。

   • AppGW Subnet: 10.0.0.0/28

     • Application Gateway 専用サブネット（AppGW は専用サブネットが必須）

   • Firewall Subnet (任意): 10.0.0.16/28

     • Azure Firewall を使う場合は専用サブネットが必須 (名前は AzureFirewallSubnet とする必要がある)

   • Web Subnet: 10.0.0.32/27

     • Web tier 用の仮想マシンや App Service Environment などを配置

   • App (Application) Subnet: 10.0.0.64/27

     • アプリケーション ロジック層 (API, App Server など)

   • Data Subnet: 10.0.0.96/26

     • DB、キャッシュ、ストレージなど

   • Management Subnet (任意): 10.0.0.192/27

     • Bastion / 管理用 Jumpbox などを配置し、運用管理を分離

※ サブネットには用途ごとに NSG やルーティングを個別に設定できるため、役割・セキュリティ要件に応じて細かく分割することが推奨されます。

2. Subnet / NSG / Application Gateway / Firewall の設計

2-1. Application Gateway (AppGW) サブネット

1. AppGW Subnet の要件

   • Application Gateway には 専用サブネット が必要。

   • WAF 機能を有効にして L7 レイヤ（HTTP/HTTPS）での攻撃を検知・防御 (OWASP Top10 対策等)。

   • サブネット内に NSG を適用する場合、AppGW で必要な管理ポートやヘルスチェックの通信をブロックしないように注意。

2. AppGW サブネットの NSG 例

   • 送信元：Internet (任意のパブリックIP) からポート 80/443 へのインバウンドを許可（ただし本番環境は 443 のみ推奨、80 はリダイレクト用途など最小限に留める）。

   • AppGW からバックエンドサブネット（Web Subnet 等）へのHTTP/HTTPS の通信を許可。

   • AppGW のヘルスチェックや診断ログ送信のために必要な Azure 管理エンドポイント（AzureMonitor など）への通信を許可。

3. WAF モード

   • Detection モード: 攻撃パターンを検知してログを残すがブロックはしない。

   • Prevention モード: 攻撃をブロックし、リアルタイムで防御。

   • 本番運用時は Prevention モードにし、テスト期間などは Detection モードで誤検知を確認してから切り替えるのが一般的。

2-2. Azure Firewall サブネット（任意）

• 名前: AzureFirewallSubnet（固定。Azure Firewall ではサブネット名が必須）

• 特徴:

  • L3～L4 レイヤでの送受信を制御（アウトバウンド FQDN ベースフィルタ、宛先 IP/ポート制限 など）。

  • Web カテゴリベースの URL フィルタリングも実施可能。

  • VNet 全体の送信トラフィックをすべて Azure Firewall にルーティングし、インターネット接続を一元管理するハブとして利用するケースが多い（Hub-Spoke アーキテクチャ）。

• NSG との併用:

  • Azure Firewall サブネット自体には NSG を付けない（推奨パターンとしては付けないのがベストプラクティス）。

  • 代わりに、他のサブネット側の NSG + ユーザー定義ルート (UDR) でトラフィックを Firewall に集約。

2-3. Web Subnet / App Subnet / Data Subnet

• Web Subnet

  • バックエンドプール（Webサーバやアプリコンポーネント）を配置。

  • NSG でのインバウンドは、送信元: AppGW Subnet の TCP/443 のみ許可する（最小権限）。

  • インターネットからの直接アクセスは基本的にブロック (AppGW 経由のみ)。

  • 必要があれば、ユーザー定義ルート (UDR) を設定して、Outbound (Internet への通信) は Azure Firewall 経由にする。

• App Subnet

  • アプリケーション層の VM やコンテナ (AKS) などを配置する場合も同様に、通信元・通信先を Web Subnet / Data Subnet / 管理用サブネット に限定。

  • DB への接続 (TCP/1433 等) を許可する場合は、送信先: Data Subnet への特定ポートのみを NSG で開ける。

• Data Subnet

  • Azure SQL Managed Instance, Azure Database for PostgreSQL などを配置する場合もサブネット要件に従う。

  • 外部からの直接アクセスは遮断し、アプリケーション層や管理サブネットからのみアクセスを許可。

  • Data Subnet への NSG ルールは原則拒否ベースとし、厳選した宛先・ポートのみを開放。

2-4. NSG のベストプラクティス

1. 許可ルール最小化:

   • Inbound/Outbound ルールともに必要最小限のポートと送信元/宛先に絞る。

   • 具体的には「AppGW Subnet → Web Subnet (TCP/443) を許可」のように、送信元やポートを限定する。

2. ステートフル動作:

   • NSG はステートフルなので、Inbound 方向に許可したコネクションの戻りトラフィックは Outbound 側で自動的に許可されることに留意。

3. サービス タグ (Service Tag):

   • Microsoft Azure が提供する「Internet」「VirtualNetwork」「AzureMonitor」などのサービスタグを使い、Azure の管理トラフィックを簡易に許可/拒否できる。

   • AppGW が利用する Azure インフラへのアクセスを Service Tag を用いて許可するケースが多い。

4. Log 分析:

   • NSG Flow Logs (Network Watcher) を有効化して通信を可視化。セキュリティ監査・トラブルシュートに活用。

3. オンプレとの接続

3-1. Site-to-Site VPN

• VPN Gateway を使用し、インターネット経由で拠点（オンプレ）と Azure の VNet を暗号化トンネルで接続。

• 帯域やレイテンシの制約があるため、開発・検証用途や比較的軽量なワークロード向けに適している。

• 必要サブネット: GatewaySubnet を VNet 内に作成 (10.0.255.0/27 など推奨。必ず GatewaySubnet という名前)。

• NSG の適用: GatewaySubnet に NSG を付与しない、または注意深く設定するのが推奨（GateWay が必要な管理トラフィックをブロックしないようにする）。

3-2. ExpressRoute

• 専用線による高帯域・低レイテンシ。

• SLA やセキュリティ面で厳格な要件がある金融機関・大企業向け。

• Hub-Spoke アーキテクチャで中央の Hub VNet に ExpressRoute Gateway を置き、Spoke VNet へピアリングする形を取ることが多い。

• AppGW のインバウンドトラフィックを Public IP から受ける場合、オンプレ通信との経路分離をどう行うか、UDR の設計（発信トラフィックを Firewall 経由にするかなど）を吟味する必要がある。

4. トラフィック フロー例（全体像）

1. インターネット ユーザー → (443) → Public IP (AppGW)

   • AppGW Subnet が受け取り、WAF (Prevention モード) で L7 検査。

   • 正常トラフィックのみ Web Subnet へ転送。

2. AppGW Subnet → Web Subnet (HTTP/HTTPS)

   • NSG で送信元を AppGW Subnet のみ許可し、送信先ポートを 80/443 に制限。

   • Webサーバは AppGW 以外からの直接アクセスを拒否。

3. Web サーバ (Web Subnet) → App Subnet (API サーバ等)

   • TCP/8080 など業務アプリ特有のポートで通信する場合は、NSG ルールで許可。

4. App Subnet → Data Subnet (DB)

   • TCP/1433 (SQL) や 5432 (PostgreSQL) などを限定許可。

5. Outbound (外部 SaaS や API への接続)

   • アプリケーションが外部 API を呼び出す必要がある場合、

     • (A) 直接インターネットへ出る → Web Subnet / App Subnet の NSG で宛先ポートを限定

     • (B) Azure Firewall 経由にする → UDR を使い、デフォルト 0.0.0.0/0 を Firewall にルーティングし、Firewall ルールで制御。

6. オンプレミスとの通信 (Site-to-Site VPN / ExpressRoute)

   • GatewaySubnet を経由し、オンプレのプライベート ネットワーク（例：192.168.x.x/24）と相互ルーティング。

   • 必要に応じて、ファイアウォールや NSG ルールで通信を制限。

5. 設計・運用上のポイント

1. セキュリティ レイヤの多層化

   • L7 レベル（AppGW WAF）だけでなく、L3/L4 レベル（NSG、Azure Firewall）でも通信を最小化し、セキュリティを高める。

   • アプリケーション側でも認証・認可、HTTPS 強制、リクエスト検証を実施。

2. 高可用性の確保

   • AppGW をゾーン冗長 (Zonal) でデプロイする、または Azure Firewall と組み合わせて可用性を確保する。

   • 各サブネットのリソースは可用性セット（VM の場合）や可用性ゾーン（AZ）を活用し、単一障害点を排除。

3. ログの集中管理

   • Application Gateway Access Log / Firewall Log / NSG Flow Log / Azure Monitor / Sentinel 等を連携し、可視化・分析を行う。

   • WAF でブロックされたリクエストの内容を確認し、誤検知があればルール調整。

4. 将来的な拡張に備えたアドレス空間

   • 新たにサブネットを追加する可能性がある場合、/24 など十分な範囲を初期から確保。

   • オンプレとのピアリング数が増える場合に備え、Hub-Spoke モデルへの拡張を念頭に置く。

5. コスト管理

   • Azure Firewall / AppGW WAF は従量課金が発生（例：Firewall の転送量、AppGW のスケールユニット）。

   • ネットワーク設計段階で推定コストを試算し、想定超過しないようにアーキテクチャを検討。

6. まとめ

• VNet / Subnet 設計では、将来の拡張性とセキュリティ要件に合わせてサブネットを細分化し、役割ごとのアクセス制御を明確にすることが重要です。

• Application Gateway (WAF) はインターネットからの入口として L7 レイヤでのセキュリティを担い、サブネット設計・NSG ルールと整合性を取る必要があります。

• Azure Firewall を導入する場合は、インバウンド・アウトバウンドともに集中管理・監視できるため、エンタープライズ環境でのセキュリティ強化に有効です。

• オンプレとの接続は Site-to-Site VPN か ExpressRoute を選択し、ゲートウェイ サブネットとルーティング設計を最適化します。

• 運用フェーズでは NSG Flow Logs や AppGW WAF Logs 等を一元的に集約し、トラフィック監視や脅威分析を継続的に行うことで、高い信頼性とセキュリティを維持できます。

これらのポイントを踏まえたネットワーク詳細設計を行うことで、可用性・セキュリティ・拡張性・コストのバランスを保ちながら、Azure 上に堅牢なインフラ基盤を構築することが可能です。