Azure ネットワーク設計ガイド
- 山崎行政書士事務所
- 3月11日
- 読了時間: 30分
1. Azure Virtual Network (VNet) 設計
CIDR ブロックの選定
アドレス空間の計画: 仮想ネットワークにはRFC1918のプライベートIPアドレス空間 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 など) からCIDRブロックを選定します。選定したVNetのCIDRは、オンプレミスを含む組織内の他ネットワークと重複しないようにします
IPアドレスの不足や競合を避けるため、将来の拡張も見据えて十分なアドレス範囲を確保します。また小さすぎるネットワークは避け、必要に応じて大きめのアドレス空間を確保する方が柔軟性が高く管理も容易です
複数のVNetを作成する場合も、各VNet間でIPが重ならないように計画します。
アドレス範囲のサイズ: Azure仮想ネットワークでは、CIDR最小サイズは /29 (8アドレス) で、最大は /2 です
ただし各サブネットでは最初の4アドレスと最後の1アドレスの合計5つがAzureによって予約されるため、有効に使えるのはその残りです
たとえば /29 サブネット（8アドレス）の場合、利用可能なIPは3つだけになります。このため、VNet全体や主要なサブネットには将来的な余裕を持たせ、必要最小よりも少し大きめのCIDRを割り当てることがベストプラクティスです
サブネット分割
セグメント化: VNet内のアドレス空間は、用途やセキュリティゾーンごとに複数のサブネットへ論理分割します。例えばDMZ用にApplication Gatewayを置くサブネット、Webサーバ用サブネット、Appサーバ用サブネット、DBなどデータ層サブネット、そしてAzure Firewallなど共通セキュリティサービス用サブネットに分ける構成が一般的です。サブネットごとに役割を明確に分離することで、ネットワークアクセス制御（NSGやNVAによるフィルタ）が施しやすくなり、不要な通信を制限できます
サブネットのサイズと予約: 各サブネットはVNet全体を使い切るような割り当てにせず、将来の増設に備えてアドレス空間の一部を未使用として残すのが望ましいです
。例えば「Web」「App」「Data」といった層ごとにサブネットを分ける際、現在必要なサイズに加えて将来のサーバ増設分も見込んでおきます。また一度作成したVNetに後から新しいサブネットや追加のCIDRを割り当てることも可能ですが、最初からある程度余裕をもって設計することで再設計やアドレス変更の手間を減らせます
Azureでは1つのVNetに作成できるサブネット数は最大3000までと十分な上限がありますが、用途ごとに明確にサブネットを分離し、同一用途のリソースは同一サブネット内にまとめる方針が管理を簡素化します。
IPアドレス設計のベストプラクティス
重複回避と一貫性: 前述の通り、Azure上のIPレンジはオンプレミスや他VNetと重ならないようにします
特に将来VNet間ピアリングやVPN/ExpressRouteで接続する可能性がある場合、重複があるとルーティングできません。また各サブネットのアドレス範囲はわかりやすく、用途が推測できるように命名規則（例えば10.1.0.0/24をWeb、10.1.1.0/24をAppなど）を整えます。サブネットごとのIP利用状況は、Azureが自動で割り当てを行うDHCP方式のため、静的IPが必要なVMなどではアドレス予約 (static IP) をAzure側設定で行います。Azureではサブネットごとに5つのIPが内部利用で確保され
、特に小さいサブネットでは割合が大きくなるため、必要に応じてサブネットサイズを上げることも検討します。
例: 仮に10.0.0.0/16をVNetに採用した場合、10.0.0.0/24を「FrontEnd(Web)サブネット」、10.0.1.0/24を「Appサブネット」、10.0.2.0/24を「DBサブネット」、10.0.255.0/27を「GatewaySubnet」(VPN/ER接続用)といった形で割り当てます。このように未使用アドレス(例では10.0.3.0～10.0.254.0の範囲)を十分残しておけば、将来新たなサブネット（例えば「バッチ処理用サブネット」など）を追加する余地ができます。ポイント: Azureでは一度サブネットを作成すると縮小できないため、最初に過度に大きく取りすぎるのは避けつつ、将来を見据えた設計バランスが重要です。
2. Subnet / NSG / Application Gateway / Firewall の設計
Application Gateway の専用サブネット要件
専用サブネット: Azure Application Gateway (以下AppGW) をデプロイするには、AppGW専用のサブネットを用意する必要があります
AppGWのサブネットには他のリソースを混在させることはできません。これはAppGWが内部でマネージドなスケールアウトを行うため、同一サブネット内にはAppGWインスタンス以外を置かない制約となっています
1つのAppGWサブネットに、単一のAppGWデプロイメントに属する複数インスタンス（スケールユニット）が配置されますが、別のAppGW（別のデプロイ）を追加配置することも可能です
。なおSKUの混在は不可で、v1とv2のAppGWを同一サブネットに混ぜることはできません。
サブネットサイズ: AppGWサブネットのプレフィックスは、AppGWインスタンス数とフロントエンドIPの有無に応じて十分なIPアドレス数が必要です。たとえばプライベートフロントエンドIPなしで15インスタンスまでスケールする想定なら、5つの予約IPに加え15個＝計20個以上のIPを含むサブネット（/27以上）が必要になります
フロントエンドIPを持つ場合はその分も追加します。AppGW v2では自動スケーリングが可能なため、最大インスタンス数を踏まえて余裕を持たせたサブネット (/24程度など) が推奨されます。
NSGとの関係: Application GatewayのサブネットにはNSG（ネットワークセキュリティグループ）を適用しないことが推奨されます。NSGでAppGWの制御トラフィックを誤ってブロックすると、正常なプロビジョニングや機能に支障が出る可能性があるためです
特にv2 SKUではフルマネージドでヘルスプローブなども行われるため、AppGWサブネットへのNSG適用は慎重に検討すべきです。
WAF 機能の利用方法 (検出/防止モード)
Application GatewayのWAF（Web Application Firewall）機能では、ポリシーの動作モードを「検出 (Detection)」または「防止 (Prevention)」に設定できます。検出モードでは、WAF規則にマッチした攻撃パターンがあってもブロックはせず、イベントをログに記録するのみです
これにより本番環境に適用する前のテスト段階で、どのトラフィックがWAFに検知されるかを確認できます
一方、防止モードでは検知された悪意あるリクエストを実際にブロックし、同時にイベントを記録します
。運用開始直後はまず検出モードで誤検知（フォルスポジティブ）がないか様子を見て、必要な例外ルール設定を行った後に防止モードへ切り替えるのが安全な手順です。
WAFはOWASPのCore Rule Setに基づくシグネチャで一般的な攻撃（SQLインジェクションやXSSなど）からWebアプリを保護します
各アプリに対しカスタムWAFポリシーを作成し、AppGW全体またはリスナー単位で紐付けることで、サイトごとに異なるルール適用も可能です
WAFログはAzure MonitorやDefender for Cloudと連携してモニタリングでき、攻撃トレンドの分析やアラート発砲にも利用されます
Azure Firewall のサブネット要件とルール設計
専用サブネットとサイズ: Azure Firewallをデプロイする際も、Firewall専用のサブネットが必要です。サブネット名は必ず AzureFirewallSubnet とし、サイズは少なくとも /26 (64アドレス) を確保します
/26以上であれば自動スケールに十分なIPが割り当てられ、より大きなプレフィックスを指定してもそれ以上のインスタンスは現時点で使用しないため、/26が推奨サイズとなります
このサブネットにはAzure Firewall以外のリソースは置かないでください。またAzureFirewallSubnetには原則NSGを適用しません（適用するとFirewallの管理トラフィックまで遮断する恐れがあるため）
Firewall自体が許可/拒否ルールを持つため、サブネットレベルでのNSGによる追加制御は不要です。
ルール設計: Azure Firewallは3種類のルール（ルールコレクション）を使用してトラフィックを制御します
:
アプリケーション ルール: 発信元サブネット/仮想ネットワークからインターネットや他VNet宛のHTTP/S トラフィックを、FQDNベースで許可/拒否します。ドメイン名単位でのフィルタリングにより、たとえばAzure Storageの特定アカウントへのみ通信許可するといった制御が可能です
。
ネットワーク ルール: L3/L4レベルで、送信元IP/送信先IP/ポート/プロトコルの組み合わせによって通信を許可/拒否します
。例えばオンプレミス特定ネットワーク宛のTCP 1433番（SQL)だけ許可する、といった細かい設定が可能です。
NAT ルール: 受信 (Ingress) トラフィックのポート転送に使用します。Firewallに割り当てたパブリックIPの特定ポートへの通信を内部のIP:ポートに転送する設定で、オンプレミスからAzure内サーバへのRDP/SSHや、自社Webサーバ公開時に利用します。
Azure Firewall Policyを用いて複数のAzure Firewallに共通のルールセットを一元管理することもできます。設計上は「すべて拒否」から始め、必要な通信を最小限許可するアプローチを取ります。加えてAzure Firewallには悪意あるIPに対する脅威インテリジェンスベースのフィルタ機能もあり、既知の悪性IPリストからの通信をアラートや拒否する設定も可能です。
Web/App/Data サブネットのNSG設計ベストプラクティス
役割ごとのサブネットにNSG: WebサーバやAppサーバなどを配置する各サブネットには、ネットワークセキュリティグループ(NSG)を適用してサブネット間トラフィックを制御します。Azureでは同一VNet内サブネット間はデフォルトで自由にルーティング可能なため、NSGを使って不要な横方向 (East-West) 通信を遮断する必要があります
NSGはステートフルなフィルタであり、5タプル（送信元/送信先IP、ポート、プロトコル、方向）のルールで許可/拒否を設定します
ベストプラクティスとして、同じセキュリティ境界や役割のVMは同一サブネットに配置し、そのサブネットに対応するNSGで必要な通信だけを許可するようにします
例: 「Webサブネット」のNSGでは、インターネットやAppGWサブネットからのHTTP/HTTPS (例: TCP 80,443) のみを許可し、他のポートは拒否します。「Appサブネット」のNSGでは、送信元をWebサブネットに限定してアプリケーションポート(例: TCP 8080など)を許可、データベースサブネット宛のSQLポートのみ許可、その他は拒否します。「Dataサブネット」（例: SQL Serverがある）のNSGでは、送信元をAppサブネットからの1433/TCPのみに絞り込み、必要に応じてバックアップ用のストレージや管理用端末からの特定ポートだけ許可します。これらNSGルールにより各層間の通信が最小限に抑えられ、万一Web層が侵害されても他の層への不正侵入を遅延・検知できます（マイクロセグメンテーションの実現）。
サービスタグとASG: NSGルールでは送受信元にIPアドレスだけでなくAzureのサービスタグ（Azureが提供するサービスごとのIP範囲ラベル）やアプリケーションセキュリティグループ(ASG) を使用すると管理が容易になります
サービスタグを使えば、例えばAzureLoadBalancerやInternetといったタグで範囲指定が可能です。ASGは自分で定義するリソースの論理グループで、VMにASGを割り当てておけばNSGルールの対象/送信先にASG名を使って指定できます
これにより、IPアドレスの変更や複数VMへの一括ルール適用が簡単になり、ルール管理をシンプルにできます。
デフォルトルール: NSGには既定でインバウンド/アウトバウンドそれぞれに数個のデフォルトルールがあり、例えばVNet内部の通信を許可するルールやInternet宛のOutbound許可ルールが含まれます。これらは優先度が低く設定されており、必要に応じてより高優先度のカスタム拒否ルールで上書きできます。すべてのカスタムルールの評価後、マッチしない通信はデフォルトで拒否(DenyAll)されるため、基本的には必要な許可ルールだけを作成すれば残りは拒否となります。
ユーザー定義ルート (UDR) を活用したトラフィック制御
Azureの既定ルーティング: Azureでは各サブネットにシステムルートが自動生成され、同じVNet内の他サブネット宛やピアリング接続経由のVNet宛、オンプレミスへのルート (BGP経由) などが既定で有効になります
しかしセキュリティや監査上、トラフィックを一旦ファイアウォールやNVA(Network Virtual Appliance)に集約したいケースがあります。そうした場合にユーザー定義ルート(UDR) を設定して、特定の宛先への経路のNextHopをカスタマイズします。UDRはサブネット単位でカスタムルートテーブルを作成し適用することで、デフォルトのシステムルートをオーバーライドできます
たとえばインターネット宛 (0.0.0.0/0) トラフィックはすべてAzure Firewallに送るよう、各サブネットにデフォルトルートを設定する、という使い方が典型です
トラフィックパターン制御例: 上記のようにUDRで既定ルートをFirewall経由にすることで、アウトバウンド通信はすべてFirewall経由となり、Firewallのネットワーク/アプリケーションルールで厳格に制御できます
。一方、インターネットからのHTTP(S)リクエストはAzure FirewallではなくWAF経由(AppGWのパブリックIP)に直接来るようにします
。これによりInboundはWAFが、OutboundはFirewallが処理を担当し、双方を組み合わせて多段防御を実現します
。
加えて、複数のスポークVNetがあるHub-Spoke構成では、スポークからHubのNVA/Firewallへデフォルトルートを向けるUDRを適用することで、スポーク間やスポークからオンプレミスへのトラフィックを一度Hub経由に集約できます
。これは強制トンネリングとも呼ばれ、スポークからインターネットへ直接出ずに必ず中央のFirewallを経由させる構成などで用いられます。UDRではプレフィックスとしてAzureサービスタグ（例えばAzureStorageやAzureMonitor）も指定可能で、特定サービス宛の通信だけ別経路にする、といった柔軟な経路制御も可能です
。
3. オンプレミスとの接続
Site-to-Site VPN の設計と GatewaySubnet
VPN GatewayとGatewaySubnet: オンプレミスとAzureをIPsec VPNで接続する場合、Azure側に仮想ネットワークゲートウェイ(VPN Gateway)をデプロイします。VPN Gatewayを設置するには、VNet上にGatewaySubnetという特別なサブネットを作成する必要があります
。名前は必ずGatewaySubnet とし、他の名前を付けたりVMを置いたりしないでください
。このサブネット内のIPはすべてゲートウェイ用にAzureが消費するため、十分なサイズを確保します
。推奨されるサイズは/27以上で
、/29など最小サイズでも動作はしますが、将来Active-Active構成にしたりポイント対サイトVPNを併用する場合などIPが不足する恐れがあります。/27(32 IP)を確保しておけば、ゲートウェイの冗長化や新しい接続追加にも対応しやすくなります
。
高可用性構成: VPN Gateway自体は内部で自動的に冗長化されています。既定ではActive-Standby構成で2つのインスタンスが作成され、一方がプライマリとして機能します
。オプションでアクティブ/アクティブモードを有効にすると、VPN接続を2本張りそれぞれのインスタンスが同時稼働します。オンプレミス側にも冗長VPN装置もしくは2経路の設定を行うことで、片系統障害時にも自動フェイルオーバーが可能です。BGPを有効にすれば経路の自動切替えが行われ、手動設定よりも信頼性が向上します（ただし小規模環境でBGP未使用の場合は静的ルートの管理に注意が必要です）。また、VPN Gateway用のパブリックIPはStandard SKUを使えば静的割り当てが可能で
、オンプレ側ファイアウォールで許可するIPを固定できます。
ExpressRoute を利用した高可用性接続
専用線による接続: ミッションクリティカルなシステムや安定した帯域が必要なケースでは、Site-to-Site VPNではなくAzure ExpressRoute(ER)を使用します。ExpressRouteはインターネットを経由せずにオンプレミスとAzureデータセンター間を専用線で接続するサービスです。ER回線は通常、信頼性のため冗長構成が組まれます。具体的には、異なる2つの物理経路（プライマリ/セカンダリ）でMicrosoft Edgeルーターとオンプレミス側設備を接続し、ひとつのER回線回復力を高めます
。標準的なER回線契約にはデフォルトで冗長経路が含まれ、片方の経路に障害が発生しても自動的にもう一方にフェイルオーバーします（BGPルーティングで経路制御）
。
ゲートウェイの配置: ExpressRoute接続をVNetに引き込むには、VNet側にExpressRoute Gateway（仮想ネットワークゲートウェイをERモードで作成）を配置します
。これはVPN Gatewayとは別のGatewaySubnetを利用できますが、一般的には1つのGatewaySubnetに対しVPNとERの両機能を持つゲートウェイを統合して作成可能です。ER Gatewayもゾーン冗長やActive-Active構成ができ、ExpressRoute自体の冗長経路と合わせて非常に高い可用性となります。またExpressRoute接続は帯域保証があり、遅延もインターネットVPNより低く抑えられます。Microsoft Peeringを利用すればMicrosoft 365やDynamics 365などのSaaSにも専用経路でアクセスでき、セキュアかつ安定したハイブリッド接続を実現できます
。
VPN併用フェイルオーバー: 万一両系統の専用回線が断になった場合に備えて、インターネットVPNを冗長経路として構成することも可能です。AzureではひとつのVNetにERとVPNを両用する構成がサポートされており
、通常時はExpressRoute経由、障害時に自動的にVPNに切り替えることができます（この場合も重複しない経路広告とBGPのメトリクス調整がポイントです）。
Hub-Spoke アーキテクチャの考え方
ハブ＆スポークモデル: 複数のVNetを展開する場合、ネットワーク設計としてHub-Spokeアーキテクチャが広く採用されています
。Hub VNetとは共通サービス（VPN/ERゲートウェイ、Azure Firewall、オンプレミス接続、監視・ジャンプサーバ、共有DNSなど）を集約する中心VNetであり、Spoke VNetは各アプリケーション環境や部署ごとのワークロードをホストする個別VNetです
。スポークはハブとのみピアリング接続し、スポーク同士は直接つながずハブ経由で相互通信します。この非透過的(非transitive)接続によりスポーク間の通信を集中的に制御・監査でき、セキュリティを高められます。
メリット: Hubに集中ゲートウェイやFirewallを配置することで、各スポークからそれらを共有利用できコスト効率が上がります。例えば10個のスポークVNetがある場合でも、1つのHub上VPNゲートウェイで全スポークへのオンプレ接続を賄えるため、ゲートウェイを各スポークに作るよりコスト削減になります。またセキュリティも一元管理しやすくなり、Firewallポリシーや監視を中央集約できます。Hub-Spokeはオンプレとの接続シナリオだけでなく、スポーク間通信の集約（データ集約先や共通のサービスへのアクセス）にも有用です。Hubとスポークはサブスクリプションをまたいでも接続可能なので、大規模環境で部門ごとにサブスクリプションを分けつつネットワークはHubで集約するといった設計も可能です
。
考慮点: Hub-Spokeではハブが単一障害点にならないよう冗長化やスケーラビリティに注意します。ハブVNet自体はAzure標準で高可用ですが、内部のFirewallやゲートウェイはそれぞれ冗長化設定を有効化する必要があります。また通信経路がハブ集中になるため、ハブの帯域やスループット上限（例えばAzure FirewallのスループットやVPNゲートウェイの帯域プラン）を把握し、必要ならスケーリングやプラン変更を行います。スポークが増えすぎた場合には複数のHubをリージョンや機能別に構成し、ハブ間ピアリングで接続するマルチハブ構成も検討します
。Azure Virtual WANを使うと、マネージドなHub-Spoke（仮想ハブとスケーラブルVPN/ER集約）が利用でき、大規模環境では運用負荷軽減につながります
。
4. トラフィックフローとセキュリティ
Azureネットワーク全体のトラフィックフロー概要
Azure上の典型的な3層構成 (Web-App-DB) ＋セキュリティサービス (WAF/Firewall) の場合、トラフィックフローは以下のようになります。インターネットからのユーザ要求はまずパブリックIPを持つAppGW(WAF)に到達し、そこでHTTP(S)の検査・ロードバランシングが行われた後、バックエンドプール内のWebサーバVMへ転送されます
。Webサーバからの応答や、次段のAppサーバへのリクエストはVNet内で直接ルーティングされますが、その際各サブネットのNSGがポリシーに沿ってパケットを許可します。Appサーバは必要に応じてDBサーバにクエリを投げ、結果を取得してWebサーバ経由でユーザに応答が返ります。この一連のEast-West通信は基本的にAzureの自動ルーティングによりシームレスに行われます。
アウトバウンド（Azure内からインターネット方向）通信は、NSG既定では許可されていますが、企業ポリシー上すべての外向き通信を記録・制御するためAzure Firewall経由とするケースが多いです
。その場合、前述のUDR設定により既定ルート(0.0.0.0/0)をFirewallに向け、各VMのインターネット行トラフィックをFirewallのSNATを通すようにします。Firewallは許可ポリシーに合致した通信のみをインターネットへ転送し、不許可のものはドロップします
。
一方オンプレミスからAzureへのトラフィックは、VPN/ExpressRoute Gateway経由でハブVNetに入り、そこから目的のサブネットへルーティングされます。必要に応じてHubのFirewallでプロトコルや宛先IPベースのフィルタが行われた後、スポークVNet上のターゲットに届きます。同様にAzureからオンプレミスへの通信も、ハブで集約してからVPN/ERトンネルを通じて送出されます。Hub-Spoke構成ではスポーク間通信も一度Hubに集約されるため、異なるスポークにあるリソース同士のやり取りも監査・制御下に置けます。
AppGW → Web → App → Data 間のルーティング設計
前述のとおり、同一VNet内のサブネット間通信は既定で可能ですが、セキュリティグループ(NSG)によって必要な経路だけを許可するのが基本です
。AppGWからWebサーバへの通信では、AppGWは内部的に動的ポートを使ってバックエンドにアクセスするため、WebサブネットNSGでは送信元にAppGWサブネットを指定し必要ポート(例:80)を許可します。WebサーバからAppサーバへの通信は、AppサブネットNSGで送信元をWebサブネットからの流入に限定し、必要ポート(例:アプリケーションポート)のみ許可します。AppサーバからDBサーバへのDBクエリは、DBサブネットNSGでAppサブネットからのDBポート(例:1433)のみ許可します。逆方向の応答トラフィックはNSGがステートフルであるため、許可したセッションについては自動で戻り通信も許可されます。
ルーティング制御: 単一VNet内であれば基本的にシステムルートが宛先サブネットへ直接パケットを送りますが、セキュリティ要件によっては内部トラフィックであってもNVA/Firewall経由としたい場合があります。例えばWebサブネットからDBサブネットへの直通を禁止し、一旦Appサーバを経由させる（3層モデルの原則）ことが該当します
。Azure上ではこれはアプリケーションアーキテクチャの問題であり、ネットワーク的には同一サブネット間以外は特に制限なく到達できるため、きちんとアプリケーションの中でレイヤ分けしておくことが重要です。どうしてもネットワークレベルで経路を強制する場合、高度な方法としてカスタムルートで意図的に遠回りさせることもありますが、通常は不要です。基本は各層間の通信をNSGで最小化し、直接通信する必要がないパスは遮断する方針となります。
AppGWとFirewallの配置: WAF(AppGW)とAzure Firewallの両方を導入する場合、その配置によってトラフィックフローが異なります。一般的なパターンは次の2つです: (1) 並列配置: AppGWとFirewallをそれぞれ独立に配置し、InboundのWebトラフィックはWAF経由、Outboundや非HTTPトラフィックはFirewall経由とする
。(2) 直列配置: インターネットからのトラフィックをまずWAFで受け、その後Firewallを通過させてからバックエンドに届けるパターンです
。後者ではFirewallで内部通信も含め全トラフィックを集中的に検査できますが、レイテンシーが増加します。Azure Firewall Premiumの場合、TLS終端とIDPS機能で暗号化トラフィックも深堀検査できるため、ゼロトラストを徹底したい場合にWAF+Firewall直列配置が採用されます
。設計上は要件に応じてこれらパターンを使い分けます。
外部SaaSやAPIへの接続方法
クラウド環境から外部のSaaSサービスや他社APIにアクセスするケースでは、通信経路とセキュリティの両面を考慮します。まずアーキテクチャ上、外部サービスが提供するプライベート接続オプションがあるか確認します。例えばAzureが提供するサービスの場合、Private LinkによってプライベートIP経由で接続しVNet内トラフィックに閉じ込めることが可能です。外部SaaSでもVPN接続や専用線オプションがある場合はセキュアです。しかし多くの一般的APIはインターネット越しのアクセスとなるため、その際はOutbound通信の制御が重要です。
前述のAzure Firewallのアプリケーションルールを活用すれば、外部ドメイン（FQDN）単位で通信を許可できます
。例えば特定のAPIホスト名だけ許可し、それ以外のインターネット先は遮断する設定ができます
。NSGだけでは宛先IPアドレスベースの許可しかできず、相手側のIPが変動するようなSaaSには対応しづらいですが、FirewallのFQDNフィルタであればホスト名で制御でき比較的柔軟です
。また、外部サービス側でアクセス元IPの制限がある場合、Azure側から出るトラフィックの送信元グローバルIPを固定化する必要があります。そのためにAzure FirewallやNAT Gatewayを使用し、VNetからのOutboundを特定の固定IP (FirewallやNAT GWに割り当てたPublic IP) に変換するようにします。
加えて、例えばAzure上に仮想アプライアンス（プロキシサーバやAPIゲートウェイ）を配置し、外部APIとの通信を代行させる方法もあります。この場合、アプリケーションからはそのプロキシに向けて通信し、プロキシが外部とやり取りすることで、Outbound通信先をプロキシだけに限定することができます。いずれにせよ外部との通信は監視と最小権限化が重要であり、必要な行先だけホワイトリスト方式で許可するのがベストプラクティスです。
NSGフローログやAzure Monitorを活用した可視化・監査
NSGフローログ: Azure Network Watcherの機能として、NSGで許可/拒否したトラフィックのログを取得できます。NSGフローログを有効化すると、一定間隔で各NSGごとの通信フロー情報（送信元IP、宛先IP、ポート、プロトコル、許可/拒否、バイト数等）がストレージに記録されます
。この生ログは非常に膨大ですが、Network Watcherのトラフィック分析 (Traffic Analytics) 機能を使うと、自動集計と視覚化が可能です
。トラフィック分析ではLog Analyticsワークスペース上でフローログを集計し、どのNSGでトラフィックが多いか、通信元・先のトップ、プロトコルの内訳、異常なポートスキャンの兆候などをダッシュボードで確認できます。ネットワークのホットスポットや不審な通信の検知に役立つため、特に大規模環境ではフローログ＋トラフィック分析の活用が推奨されます
。
Azure Monitor と診断ログ: Azure Monitorを用いれば、Azure FirewallやAppGWのWAFログ、VPN接続ログなど各種ネットワークサービスの診断ログ/メトリックも一元的に収集・分析できます。たとえばAppGW WAFのアラート件数を可視化したり、Firewallの拒否トラフィック統計をLog Analyticsでクエリして特定IPの通信を洗い出す、といったことが可能です。Azure Monitorアラートを設定すれば、重要なネットワークイベント（例えばWAFがSQLインジェクション攻撃を検知、Firewallが重大な脅威インジケーターをブロック、VPNトンネルダウン等）が発生した際に即座に通知を受け取れます。さらに、Defender for Cloudを利用するとNSGやFirewallのルール設定ミス、過度な許可設定の検出などセキュリティアセスメントが提供されます。
監査とコンプライアンス: 金融や医療分野などではネットワーク経路の監査証跡が求められることがあります。Azureでは上記ログ機能により「誰が・いつ・どこに通信したか」を追跡可能です。Flow Logは5チタプルベースの接続ログ、FirewallログはアプリケーションレベルのURLやFQDNも記録され、WAFログには攻撃シグネチャIDまで含まれます。これらを活用し、定期的に異常値や違反アクセスをレビューする運用プロセスを設けることで、ネットワークのセキュリティインシデントを早期に発見・対応できます。
5. 設計・運用のベストプラクティス
多層防御の考え方 (L3/L4/L7)
クラウドネットワークにおいても「多層防御 (Defense in Depth)」の原則が重要です。これは、単一のセキュリティ対策に依存せず、複数の層で防御を重ねる戦略です。具体的には、ネットワーク層(L3)・トランスポート層(L4)の対策と、アプリケーション層(L7)の対策を組み合わせます。それぞれの例を挙げると:
L3/L4レベル: NSGによるIP/ポートベースのフィルタリング、Azure FirewallやNVAによるパケットインスペクション、DDoS Protection StandardによるL3/L4レベルのDDoS緩和など。これらは基本的なネットワーク侵入やスキャンを阻止します。
L7レベル: Application GatewayのWAFや、Azure Front DoorのWAF、API Managementの検証など、HTTP/HTTPSのペイロードやURIに踏み込んだ防御。
で述べられるように、WAFはWebアプリ攻撃に特化した保護を提供し、Azure Firewall Premiumのような次世代FWはそれ以外の汎用的脅威を検知します。両者を補完的に用いることでセキュリティを強化できます
例えばインターネットからの攻撃トラフィックは、まずWAFでSQLiやXSSといった攻撃をブロック
、更に通過したものにもFirewallで既知のマルウェアサイトやボットネットへの通信をブロック、といった二段構えにできます。万一内部からの不正通信が発生してもFirewallで阻止でき、WAFだけではカバーできない領域を補います
。このように各レイヤでの防御策を組み合わせることで、セキュリティホールを最小化し、攻撃の深部到達を遅らせる効果があります。
高可用性のための設計 (ゾーン冗長, 可用性セット, BGPルートなど)
可用性ゾーン(AZ)対応: Azureのリージョン内障害に備えるには、可能なサービスは可用性ゾーン冗長構成を使います。Application Gateway v2やVPN Gateway、Azure FirewallなどはAZ対応SKUが提供されており、デプロイ時にゾーンを「ゾーン冗長」にすると自動的に異なるAZ上で冗長化されます。例えばApp Gateway v2をゾーン冗長にすると、バックエンドプールVMがゾーン分散している場合でもどのゾーンからのトラフィックにもサービスを提供できます
。VMについては可用性セットもしくは可用性ゾーンを用いて冗長化します。可用性セットは同一データセンター内で障害ドメインを分ける仕組み、可用性ゾーンは物理的に分離されたDC間で冗長化する仕組みです。99.95%以上のVM SLAを達成するにはこれらを適用する必要があります。
グローバル冗長: 単一リージョンが大規模障害に陥るリスクに備える場合、マルチリージョンDR構成とトラフィックマネジメントが必要です。Azure Traffic ManagerやFront Doorを使って、複数リージョンのApp Gatewayにフェイルオーバーする仕組みが考えられます
。データ層もGeo冗長なストレージや、Azure SQLのAuto-failoverグループなどを活用し、リージョン障害時に自動/手動で切り替え可能なように設計します。
ネットワークのHA: VPN GatewayやExpressRouteではBGPを活用した冗長経路構成がベストプラクティスです。BGPは経路を動的に学習・切替するため、スタティックルートよりフェイルオーバーがスムーズです。Active-Active VPNでは両経路にBGPを設定し、優先経路をメトリクスで制御します。ExpressRouteでは回線自体が冗長ですが、万が一両方断の場合にVPNに自動フェイルオーバーさせるには、オンプレ側でBGPピアの優先度を調整し、VPN経路をバックアップ扱いにするよう設定します。Azure Firewall自体はマネージドで冗長化されますが、NVAを使う場合はNFVのHA機能（例えばペア冗長 or Azure LB経由の冗長化）を構築します。
また、経路設計ではユーザ定義ルートの冗長性も検討します。単一路由先ではなく、Azure Route Serverを使ってNVAとBGPピアを張り、NVA冗長ペアから動的にルートをアドバタイズさせる構成にすると、NVA障害時に経路を引き下げて自動フェイルオーバーする、といった高度なHA構成も可能です
。
コスト管理と最適化戦略
リソース共有: ネットワーク設計段階からコスト意識も重要です。例えばAzure FirewallやVPN Gatewayは単体で一定費用がかかるため、Hub-Spoke構成にして複数ワークロードで共有すると全体コストを下げられます。一方でトラフィック量が多すぎるとスケーリングが必要になるため、適切なサイズのHubを用意しつつ、共有できるものは共有するバランスを取ります。
サービス選定: マネージドサービスを活用することで運用コスト削減と同時に、結果的に総コスト低減につながることがあります。例としてAzure Bastionを導入すればジャンプボックス用のVMを常時起動する必要がなくなり、運用負荷とVM費用を削減できます。通信帯域コストも考慮が必要です。Azure内のVNetピアリングは同一リージョン内なら安価ですが、異なるリージョン間ではデータ転送料金が発生します。可能な限り同じリージョン内で完結させ、どうしてもリージョンを跨ぐ場合は必要最小限のデータだけ送る設計にします。ExpressRouteは初期費用が高めですが、大量データ転送時の従量課金はインターネット経由より低廉な場合が多く、帯域やセキュリティ要求に応じてVPNとのコスト・メリット比較を行います。
スケーラビリティと自動停止: ネットワークアプライアンス系（FirewallやVPN Gatewayなど）はスケーリングユニットが限られますが、必要以上に大規模なSKUを選定するとコスト増になります。まずは中小規模から始め、モニタリングでスケールポイントに近づいたら上位SKUに変更するといった段階的アプローチが良いでしょう。また開発・検証環境では夜間にVPN GatewayやBastionを自動停止する、AppGWやFirewallは必要時のみ起動するなどのスケジューリングでコスト最適化できます。Azure Cost Management + Advisorのレポートを活用し、未使用のパブリックIPや不要になったGatewey、過大な帯域プランなどがないか定期的に棚卸しする運用も取り入れます。
6. 必要な図の作成
Azure ネットワーク全体の構成図
以下の図は、典型的なHub-Spokeネットワークアーキテクチャの概略です。左側にオンプレミス環境があり、VPN/ExpressRoute経由で中央のHub VNetに接続されています。Hub VNet内にはAzure FirewallやVPN Gatewayなどの共有サービスが配置され、右側の複数のSpoke VNet（各アプリケーションのサブネット群）とピアリング接続されています。これによりスポーク間やスポーク-オンプレ間の通信はハブを経由して集中的に管理・監査されます。
ハブ＆スポーク型ネットワーク構成の例。中央のHub VNet (Connectivity)にAzure FirewallやExpressRoute/VPN Gateway、DNSなどを集約し、各ワークロードはSpoke VNet (Landing zone)に分離されている
上図では、左側「Connectivity subscription」にHub VNet (Region 1)があり、その中にAzure FirewallやExpressRoute/VPN Gateway、Azure DDoS保護、Private DNSなどが属しています。右側「Landing zone subscription」にアプリケーション用のVNetがあり、内部にサブネット (例: Web/App/Data) とリソースグループ単位のリソース（Key Vaultや共有サービス）が配置されています。HubとSpokeはVNetピアリングで接続され、トラフィックはAzureのバックボーンネットワーク経由で転送されます
。このモデルによりネットワークを論理的に分離しつつ集中管理する基盤が提供されます。
Application Gateway の詳細設計図
次の図は、Application Gateway (WAF機能付き) を用いたWebアプリ防御の概念図です。インターネット上のクライアントからのリクエストはAppGWに送られ、WAFモジュールで検査されます。悪意のある攻撃（例: XSS, SQLインジェクション）はそこでブロックされ、正常なリクエストのみがバックエンドのWebサーバ群（Site1やSite2）に転送されます。
Application Gateway WAFによるWebアプリ防御の模式図。悪意あるリクエスト(XSS攻撃やSQLi)はWAFによってブロックされ、正常なリクエストのみがバックエンドサイトに届く
このようにAppGWのWAFはアプリケーション層の攻撃をリアルタイムに検知・遮断し、バックエンドのWebサーバを保護します。AppGW自体はL7のロードバランサ機能も持ち、Site1, Site2のように複数のWebアプリケーションを単一のゲートウェイでホスト可能です
。WAFポリシーをリスナーごとに分ければ、サイトごとに異なるセキュリティルールを適用することもできます。図のようにWAFで防げる攻撃は防ぎ、万一すり抜けた場合もバックエンドサーバ側のセキュリティ（Webフレームワークの検証やホストのNSG）で多層的に守るのが理想です。
VNet/Subnet 分割の模式図
以下の図は、Azure上で3層アプリケーションを構築する際のVNetとサブネット分割の一例です。左端にインターネットとの入り口としてパブリックロードバランサやWAFを配置し、その背後にDMZ的なNVA（Network Virtual Appliance、サードパーティFirewall等）層、続いてWebサブネット、ビジネスロジック用のAppサブネット、データベースサブネットが並んでいます。それぞれの層でAzureのNSGやロードバランサを用いて、内部トラフィックのみ通過を許可し外部との直接通信を遮断しています。
Azure上における典型的N層アーキテクチャのネットワーク図。インターネットからの入口にNVAクラスタを置き、以降Web層・アプリ層・データ層とサブネット分離。各層間はロードバランサ経由で接続され、NSGにより不要なアクセスは遮断される
図では、外部からのトラフィックはまずインターネット側のゲートウェイ（例えばApp GatewayやAzure Front Door、NVAのパケットフィルタ）を通り、DMZにあたるNVA（図中のFirewallアイコン部分）で検査されます。その後Web層のロードバランサに受け渡され、複数のWeb VMに配送されます。Web層からは内部のApp層LB経由でApp VM群に通信し、App層からデータ層のSQLサーバプライマリ/セカンダリにアクセスします。各サブネットにはそれぞれ対応するNSGが紐づいており、例えばWeb層NSGは外部LBとApp層LBからの通信だけ許可、App層NSGはWeb層LBとデータ層SQLからの通信だけ許可、といった具合に階層間のみ通信できるセキュリティ境界を設定します
。これにより、例えばWeb VMが乗っ取られても直接DBにアクセスすることはネットワーク的に不可能で、被害を食い止められます。
NSGやFirewallのフロー図
最後に、Azure上でInbound/OutboundトラフィックがどのようにWAFとFirewallを通過し、どこで許可・拒否されるかのフローを示した図を紹介します。Inbound (受信) パスでは、クライアントのHTTPSリクエストがAppGW+WAFに届き、そこでL7フィルタリングされた後、バックエンドのVMに届けられます。一方Outbound (送信) パスでは、VMからのインターネット接続はデフォルトルートによりAzure Firewallに転送され、Firewallがポリシーに基づき外部への通信を許可した上でインターネットへ出て行きます。
AzureにおけるIngressトラフィックフローの例。インターネットからのHTTPSはApp Gateway (WAF) のパブリックIPに送られ(➊)、WAF検査後バックエンドVM(➋)に配送。応答は同じ経路を戻り(➍)、Outbound通信や非HTTP通信はFirewall経由で制御される(図では省略)
AzureにおけるEgressトラフィックフローの例。VMからのインターネット宛通信(➊)はUDRによりAzure Firewall(➋)へ送られ、Firewallで許可されたものだけがインターネットへ転送(➌)される。Firewallは必要に応じてDNS名解決(➍)を行い、ログとともに通信を制御する
上記Ingress/Egressの図に示すように、NSGとWAF、Firewallが連携して多段階のトラフィック管理を行います。Ingress図では①クライアントからAppGW (WAF) へHTTPS通信、②WAFで検査後に内部Webサブネット上のVMへ転送、③（図略）VMからDB等内部通信、④VMからAppGW経由でクライアントへ応答という流れです。一方Egress図では①VMからのアウトバウンド通信はカスタムルートによりFirewallへ集められ、②Firewallでポリシーにマッチした通信だけを③外部インターネットへ転送します。不許可のものはFirewallで破棄されログに記録されます。FirewallはFQDNフィルタやプロトコル制御、必要に応じて④DNS名前解決を行いIPを取得してから転送します。このように、AzureネットワークではWAFとFirewall、NSG、UDRを組み合わせて適材適所のトラフィックコントロールを実現できます。設計段階では各コンポーネントの役割分担を明確にし、運用段階ではログを収集・分析してポリシーの継続的な改善を図ることが肝要です。
Comentarios