AzureのFirewallでVNet通信を一元管理する方法|NSGとの役割分担とポリシールール設定の実践

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOME > Linux技術 リナックスマスター.JP(Linuxマスター.JP) > Azure > AzureのFirewallでVNet通信を一元管理する方法|NSGとの役割分担とポリシールール設定の実践
「NSGでポートを制御しているのに、どのVMがどのFQDNに接続しているのかログで追えない。悪性IPへの通信をまとめて遮断したいが、サブネットごとにNSGを管理するのが限界になってきた」
NSG(ネットワークセキュリティグループ)はL3/L4レベルのIPとポートを制御できる強力なツールです。しかし本番環境で厳格なゼロトラスト設計が求められると、NSGだけでは壁にぶつかります。アプリケーション層でのFQDNフィルタリング、通信の一元ログ、脅威インテリジェンスによる悪性IP自動遮断。これらはNSGの守備範囲外です。

この記事では、Azure Firewall(az network firewall)を使って、VNet全体の通信を1か所で制御・可視化する方法を解説します。NSGとの役割分担の整理から、Firewall PolicyによるFQDNフィルタリング、Route Table(UDR)との連携でトラフィックをFirewall強制経由にする手順まで、azコマンドの実機ログを交えて説明します。さらにNSG Flow Logsを活用した多層監視の構成についても解説します。

動作確認環境:Azure CLI 2.61 / Azure Firewall Standard SKU / Japan East リージョン(実環境で動作確認済み)

この記事のポイント

・Azure FirewallはNSGとは別レイヤーでFQDN・脅威インテリジェンスを一元制御できる
・Firewall PolicyでDNAT・ネットワーク・アプリケーションの3種ルールを管理する
・UDR(Route Table)でサブネットの全通信をFirewall経由に強制できる
・NSG Flow Logsと組み合わせるとNSGレベルの拒否通信も含めた多層監視が実現できる


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Azure FirewallとNSGの役割分担を整理する

NSGとAzure Firewallはよく「どちらを使うか」と比較されますが、実務では「両方使う」が正解です。それぞれの守備範囲が根本的に異なります。

・NSG(ネットワークセキュリティグループ):L3/L4レベルのIP・ポートフィルタリング。サブネット・NIC単位に直接アタッチ。設定即反映。無料。
・Azure Firewall:L4/L7レベルの集中型ファイアウォール。FQDN・URLフィルタリング、脅威インテリジェンス、全通信の一元ログ(Azure Monitor連携)が可能。有料(Standard SKUで月額約17,000円~)。

NSGは「サブネットの番人」としてIP/ポートの細かい制御を担い、Azure Firewallは「ネットワーク全体の制御ハブ」として高度なポリシーとログ基盤を提供します。この2つを重ねて使うことで、ゼロトラストネットワーク設計の核心部分が実現できます。
機能 NSG Azure Firewall(Standard)
L3/L4 IP・ポートフィルタリング ○ ○
FQDNフィルタリング(*.microsoft.comなど) × ○
脅威インテリジェンス(悪性IP自動遮断) × ○
通信ログ(Flow Logs / 診断ログ) NSG Flow Logs(Network Watcher経由) ○(Azure Monitor / Log Analytics)
DNAT(インバウンドNATポート転送) × ○
費用 無料 有料(Standard約17,000円/月~)
NSGにはNSG Flow Logsという独自のログ機能があります。Azure Network Watcherのサブ機能として実装されており、NSGを通過したすべての通信(許可・拒否とも)をBlob StorageにJSON形式で記録できます。Azure Firewallの診断ログはFirewallを経由した通信のみを対象とするのに対し、NSG Flow LogsはFirewall到達前にNSGで拒否された通信も含めて記録するため、2つを組み合わせることで多層的な通信監視が実現できます。

Azure Firewallの構成要素を理解する

1. SKUの選択(Standard vs Premium)

Azure Firewallには3種類のSKUがあります。

・Basic SKU:開発・テスト用の低コストプラン(本番非推奨)
・Standard SKU:本番環境の標準プラン。FQDN・ネットワーク・NATルール、脅威インテリジェンスをカバー
・Premium SKU:StandardにTLSインスペクション・IDPS(侵入検知防御)・URLカテゴリフィルタリングを追加した上位プラン

本記事ではStandard SKUを使って解説します。規制産業(金融・医療)や高度なマルウェア対策が必要な場合はPremiumを検討してください。

2. Firewall PolicyとルールコレクションのHierarchy

Azure Firewallのルール設定は3層構造になっています。

・Firewall Policy:複数のFirewallインスタンスにまとめて適用できるポリシー単位
・Rule Collection Group:ルールをグループ化する中間レイヤー(数値が小さいほど優先度が高い)
・Rule Collection:DNATルール・ネットワークルール・アプリケーションルールの3種別

3種のルールコレクションの処理順序は固定です。DNATルール → ネットワークルール → アプリケーションルールの順に評価され、最初にマッチしたルールが適用されます。ネットワークルールで許可した通信は、アプリケーションルールでは再評価されません。

azコマンドでAzure Firewallを構築する手順

前提として、リソースグループ(rg-demo)とVNet(vnet-demo、アドレス空間10.1.0.0/16)が作成済みであることとします。VNet・サブネットの基礎構成については「AzureのVNetとLinux VMをazコマンドで構築する手順」を参照してください。

1. AzureFirewallSubnetとパブリックIPを準備する

Azure Firewallを配置するサブネットの名前はAzureFirewallSubnet(大文字小文字込みで完全一致)でなければなりません。サイズは最小で/26(64アドレス)が必要です。名前や/27以下のサイズではFirewallの作成が失敗します。

# AzureFirewallSubnet を作成(名前は完全一致・/26以上が必須) az network vnet subnet create --resource-group rg-demo --vnet-name vnet-demo --name AzureFirewallSubnet --address-prefix 10.1.2.0/26 # Firewall 用 Standard パブリックIPを作成 az network public-ip create --resource-group rg-demo --name pip-fw-demo --sku Standard --allocation-method Static --zone 1 2 3

実行結果の抜粋(サブスクリプションIDはマスク済み):

{ "addressPrefix": "10.1.2.0/26", "name": "AzureFirewallSubnet", "provisioningState": "Succeeded" }

2. Firewall PolicyとAzure Firewallを作成する

# Firewall Policy を作成(Standard SKU) az network firewall policy create --resource-group rg-demo --name fw-policy-demo --sku Standard # Azure Firewall 本体を作成(デプロイに5~10分かかる) az network firewall create --resource-group rg-demo --name fw-demo --vnet-name vnet-demo --public-ip pip-fw-demo --firewall-policy fw-policy-demo --sku AZFW_VNet --tier Standard

Firewallのデプロイには5分程度かかります。プロビジョニングが完了したらプライベートIPを確認します(このIPが後のUDR設定で使われます)。

az network firewall show --resource-group rg-demo --name fw-demo --query "ipConfigurations[0].privateIPAddress" --output tsv

実行結果(実環境・プライベートIPはマスク済み):

10.1.2.4

3. ネットワークルールコレクションを追加する(HTTPSアウトバウンド許可)

VMサブネット(10.1.1.0/24)からインターネットへのHTTPS(443)とHTTP(80)を許可するネットワークルールを設定します。

# Rule Collection Group を作成 az network firewall policy rule-collection-group create --resource-group rg-demo --policy-name fw-policy-demo --name DefaultRCG --priority 100 # ネットワークルールコレクションを追加(HTTP/HTTPS許可) az network firewall policy rule-collection-group collection add-filter-collection --resource-group rg-demo --policy-name fw-policy-demo --rule-collection-group-name DefaultRCG --name AllowWebOutbound --collection-priority 200 --action Allow --rule-type NetworkRule --rule-name AllowHTTPS --protocols TCP --source-addresses "10.1.1.0/24" --destination-addresses "*" --destination-ports "443" "80"

4. アプリケーションルールコレクションでFQDNフィルタリングを設定する

FQDNベースのフィルタリングはアプリケーションルールコレクションで行います。たとえばMicrosoft系ドメインのみを許可し、それ以外のFQDNへのHTTPSをデフォルトdenyにする構成です。

az network firewall policy rule-collection-group collection add-filter-collection --resource-group rg-demo --policy-name fw-policy-demo --rule-collection-group-name DefaultRCG --name AllowMSFQDN --collection-priority 300 --action Allow --rule-type ApplicationRule --rule-name AllowWindowsUpdate --protocols Https=443 Http=80 --source-addresses "10.1.1.0/24" --target-fqdns "*.microsoft.com" "*.windows.com" "*.windowsupdate.com"

FQDNフィルタリングを使う場合、Azure FirewallはDNSプロキシとして機能させる必要があります(Firewall PolicyのDNS設定でEnableに変更)。
Azureのネットワーク設計をハンズオン形式で体系的に学びたい方は、現役エンジニアが解説するAzure実践講座もあわせて活用ください。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、20年以上の運用経験を持つ現役エンジニアが基礎から教えます。
Azure対応セミナーの詳細を見る >>

Route Table(UDR)でVMのトラフィックをFirewall経由に強制する

Azure Firewallを作成しただけでは、VMのトラフィックはFirewallを経由しません。VMサブネットのRoute Tableを編集し、デフォルトルートのネクストホップをFirewallのプライベートIPに向ける必要があります。Route TableとUDRの詳細な解説は「AzureのRoute TableとUser Defined Routeを設定する方法」を参照してください。

1. Route TableをFirewallのプライベートIPに向ける

# Firewall のプライベートIPを変数に格納 FW_IP=$(az network firewall show --resource-group rg-demo --name fw-demo --query "ipConfigurations[0].privateIPAddress" --output tsv) # Route Table を作成 az network route-table create --resource-group rg-demo --name rt-to-fw # デフォルトルートをFirewall経由に設定(0.0.0.0/0 → FW プライベートIP) az network route-table route create --resource-group rg-demo --route-table-name rt-to-fw --name DefaultViaFW --address-prefix 0.0.0.0/0 --next-hop-type VirtualAppliance --next-hop-ip-address "$FW_IP"

2. VMサブネットにRoute Tableを関連付ける

az network vnet subnet update --resource-group rg-demo --vnet-name vnet-demo --name snet-private --route-table rt-to-fw

関連付け後、VMのNICで有効ルートを確認します。

az network nic show-effective-route-table --resource-group rg-demo --name vm01-nic --query "value[?addressPrefix=='0.0.0.0/0']" --output table

実行結果(実環境・プライベートIPはマスク済み):

AddressPrefix NextHopType NextHopIpAddress Source State --------------- ---------------- ------------------ -------- ------ 0.0.0.0/0 VirtualAppliance 10.1.2.4 User Active 0.0.0.0/0 Internet None Default Invalid

「Source」列が「User」のUDRがActiveになり、デフォルトのInternetルートがInvalidになっていれば正常です。以降、VMからのアウトバウンドはすべてFirewall(10.1.2.4)を経由します。

動作確認(実機ログによる検証)

1. アウトバウンドIPがFirewallのパブリックIPになっているか確認する

VMにSSH接続し、アウトバウンドIPを確認します。

# VMにSSH接続後、アウトバウンドIPを確認 curl -s https://ifconfig.me

実行結果(FirewallのパブリックIPが返れば正常):

203.0.113.xxx

Firewallに付与したパブリックIP(pip-fw-demo)と一致すれば、トラフィックがFirewallを経由しています。VMのNICに直接パブリックIPを付与していない環境では、このチェックだけで十分です。

2. Firewallのアクティビティログをazコマンドで確認する

Log Analytics Workspaceへの診断設定を有効にすると、すべての通信ログをKQLで検索できます。診断設定の有効化は以下の通りです。

# Log Analytics Workspace を作成(既存のものがあれば不要) az monitor log-analytics workspace create --resource-group rg-demo --workspace-name la-fw-demo # Firewall の診断設定を有効にする(ワークスペースIDを取得して設定) WS_ID=$(az monitor log-analytics workspace show --resource-group rg-demo --workspace-name la-fw-demo --query id --output tsv) az monitor diagnostic-settings create --name fw-diagnostics --resource $(az network firewall show --resource-group rg-demo --name fw-demo --query id --output tsv) --workspace "$WS_ID" --logs '[{"category":"AzureFirewallNetworkRule","enabled":true},{"category":"AzureFirewallApplicationRule","enabled":true}]'

設定後、Log AnalyticsでネットワークルールのログをKQLで参照できます。

# Log Analytics クエリ例(AzureFirewallNetworkRule のログ確認) # Azure Portal の Log Analytics Workspace → Logs で実行 AzureDiagnostics | where Category == "AzureFirewallNetworkRule" | project TimeGenerated, msg_s, Action_s | limit 20

3. NSG Flow Logsを有効化してNSG通過トラフィックも記録する

Azure Firewallの診断ログはFirewallを経由した通信のみを対象とします。Firewall到達前にNSGで拒否された通信はFirewallのログには記録されません。NSG Flow Logsを組み合わせると、NSGレベルで拒否された通信も含めて多層的に記録できます。

NSG Flow LogsはAzure Network Watcherのサブ機能です。ストレージアカウントを用意してFlow Logsを有効にすると、NSGを通過したすべての通信がBlob StorageにJSON形式で1時間ごとに出力されます。

# Network Watcherの存在を確認する(VNet作成時にjapaneastで自動有効化) az network watcher list -o table # NSG Flow Logs用ストレージアカウントを作成する az storage account create --name stflowlogsdemo --resource-group rg-demo --location japaneast --sku Standard_LRS --kind StorageV2 # 対象NSGのリソースIDを取得する NSG_ID=$(az network nsg show --resource-group rg-demo --name nsg-snet-private --query id -o tsv) # NSG Flow Logsを有効化する(バージョン2) az network watcher flow-log create --resource-group NetworkWatcherRG --location japaneast --name fw-nsg-flowlog --nsg "$NSG_ID" --storage-account $(az storage account show --name stflowlogsdemo --resource-group rg-demo --query id -o tsv) --enabled true --format JSON --log-version 2 --retention 7

バージョン2を指定するとflowTuplesにバイト数・パケット数・接続状態が追加されるため、帯域分析や異常通信の切り分けに活用できます。ログはBlob Storageのコンテナーに出力され、flowTuplesのフォーマットは「タイムスタンプ, 送信元IP, 宛先IP, 送信元Port, 宛先Port, プロトコル, 方向, アクション, 状態, 送信パケット, 送信バイト, 受信パケット, 受信バイト」です。

Traffic Analyticsを有効にすると、既存のLog Analytics WorkspaceでKQLを使って通信パターンを集計できます。

# Traffic Analyticsを有効化する(la-fw-demoを共用) az network watcher flow-log update --resource-group NetworkWatcherRG --location japaneast --name fw-nsg-flowlog --traffic-analytics true --workspace "$WS_ID" --interval 10 # KQLでNSG通過トラフィックを集計する(Log Analytics Workspaceで実行) # AzureNetworkAnalytics_CL # | where TimeGenerated > ago(1d) # | where SubType_s == "FlowLog" # | summarize FlowCount = count() by SrcIP_s, DestIP_s, DestPort_d # | sort by FlowCount desc # | take 20

Azure FirewallのログとNSG Flow Logsを1つのLog Analytics Workspaceに集約することで、Firewall経由の通信とNSGでの拒否通信を一元的にKQLで分析できます。最初のデータが表示されるまで30分程度かかるため、設定後しばらく待ってからクエリを実行してください。

トラブルシュート・よくあるエラーと対処

1. サブネット名エラー「AzureFirewallSubnet が見つからない」

Firewallを作成しようとして「The virtual network for Azure Firewall must contain a subnet named 'AzureFirewallSubnet'」エラーが出る場合、サブネット名が完全一致していない(大文字小文字の誤りなど)ことが原因です。名前は必ず「AzureFirewallSubnet」で作成してください。また、/27以下のサイズでもエラーになります(/26以上が必須)。

# サブネット名とサイズを確認 az network vnet subnet list --resource-group rg-demo --vnet-name vnet-demo --query "[].{Name:name, Prefix:addressPrefix}" --output table

2. VMからインターネットに出られない(ルール評価の誤り)

UDRを設定したのにVMからcurlが失敗する場合、以下の順序で確認します。

・ルールコレクションの優先度を確認する:数値が小さいほど先に評価されます。DenyAllルールが低い優先度数値(例: 100)でAllowルールが高い優先度数値(例: 200)の場合、Denyが先に評価されます。
・FirewallにパブリックIPがアタッチされているか: でIPが存在するか確認します。
・Route Tableのネクストホップが正しいか:FirewallのプライベートIPとrt-to-fwのネクストホップが一致しているかチェックします。

# Firewallのプロビジョニング状態とIPを確認 az network firewall show --resource-group rg-demo --name fw-demo --query "{state:provisioningState, privateIP:ipConfigurations[0].privateIPAddress, publicIP:ipConfigurations[0].publicIpAddress.id}" --output table

3. 脅威インテリジェンスをAlertモードからDenyに強化する

Firewall PolicyのThreat Intelligence ModeをデフォルトのAlertからDenyに変更すると、既知の悪性IP・FQDNへの通信が自動遮断されます。

az network firewall policy update --resource-group rg-demo --name fw-policy-demo --threat-intel-mode Deny

遮断ログはLog AnalyticsのAzureDiagnosticsテーブル(Category: AzureFirewallThreatIntelLog)に記録されます。

また、ポートの疎通確認は自分のPC上でLinuxコマンドを使うか、VMからのcurl・ncコマンドで行います。Linuxのポート確認コマンド一覧も切り分けの参考にしてください。

4. NSG Flow Logsのログが出力されない

NSG Flow LogsはNSGを通過した通信のみ記録します。VMのNICまたはサブネットにNSGがアタッチされていない場合はログが出力されません。AWSではVPCレベルでFlow Logsを取得できますが、AzureではNSGの存在を必ず確認してください。また、Network WatcherがリージョンにあることとFlow Logsが有効(Enabled: True)になっていることを合わせて確認します。

# VMのNICにNSGがアタッチされているか確認する az network nic show --resource-group rg-demo --name vm01-nic --query "networkSecurityGroup.id" -o tsv # NSG Flow Logsの有効状態を確認する az network watcher flow-log show --resource-group NetworkWatcherRG --location japaneast --name fw-nsg-flowlog --query "{Enabled:enabled, NSG:targetResourceId}" -o table

本記事のまとめ

Azure FirewallでVNet通信を一元管理するポイントをまとめます。
やりたいこと コマンド
AzureFirewallSubnetを作成する az network vnet subnet create --name AzureFirewallSubnet --address-prefix xx.xx.xx.xx/26
Firewall PolicyをStandard SKUで作成する az network firewall policy create --sku Standard
Azure Firewallを作成する az network firewall create --firewall-policy fw-policy名 --sku AZFW_VNet --tier Standard
FirewallのプライベートIPを確認する az network firewall show --query "ipConfigurations[0].privateIPAddress"
ネットワークルールコレクションを追加する az network firewall policy rule-collection-group collection add-filter-collection --rule-type NetworkRule
FQDNフィルタリングを設定する az network firewall policy rule-collection-group collection add-filter-collection --rule-type ApplicationRule --target-fqdns
全通信をFirewall経由に強制するUDRを設定する az network route-table route create --next-hop-type VirtualAppliance --next-hop-ip-address FW_IP
脅威インテリジェンスをDenyモードに設定する az network firewall policy update --threat-intel-mode Deny
NSG Flow Logsを有効化する az network watcher flow-log create --location japaneast --nsg NSG-ID --storage-account STORAGE-ID --enabled true --log-version 2
NSG Flow LogsにTraffic Analyticsを追加する az network watcher flow-log update --traffic-analytics true --workspace WS-ID --interval 10
NSGがサブネット・NIC単位の「番人」であるのに対し、Azure Firewallは「ネットワーク全体の制御ハブ」として機能します。この2つを組み合わせることで、L3からL7まで一貫したゼロトラストネットワーク設計が実現できます。

UDR(Route Table)でトラフィックをFirewall経由に強制することが、一元ログ・FQDNフィルタリング・脅威インテリジェンスをすべて活かすための前提条件です。Route Tableのネクストホップには必ずFirewallのプライベートIPを指定し、デプロイ後は有効ルートの確認(az network nic show-effective-route-table)で意図した通りにルーティングされているか検証する習慣をつけましょう。

さらにNSG Flow Logsを組み合わせると、Firewall経由の通信ログとNSGレベルの拒否通信ログを同一のLog Analytics Workspaceで集約でき、多層的な通信監視が実現できます。Firewall診断ログとNSG Flow Logsの2つを有効にすることで、通信経路のあらゆるレイヤーで可視性が確保されます。

次に読む記事
・Linux ポート確認の全コマンド
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、20年以上の運用経験を持つ現役エンジニアが基礎から教えます。
Azure対応セミナーの詳細を見る >>

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。