TL

Cloud Service

Azure Firewall Manager

複数の Azure Firewall とセキュリティポリシーを横断的に一元管理し、ハブ&スポークやセキュアハブの境界防御を中央集権化。組織全体のルールを階層的に継承させる管理プレーン。AWS の Firewall Manager に近い。

中級セキュリティ運用上の優秀性
最終更新: 2026-06-28公式ドキュメント ↗
TL;DR要点だけ先に
  • 1.複数の Azure Firewall とポリシーをまとめて統制する管理プレーン。
  • 2.親ポリシーを子へ継承し、全社共通ルールと拠点固有ルールを両立。
  • 3.ハブ仮想ネットワークとセキュアハブの両構成で境界防御を中央集約。

解決する課題

ファイアウォールが拠点・リージョン・部門ごとに乱立すると、ルールの重複や設定漏れ、ポリシーのドリフトが避けられません。Azure Firewall Manager は、複数の Azure Firewall とそのポリシーを横断的に統制し、共通ルールを中央から配布する管理プレーンとして働きます。

  • 複数リージョン・複数の Azure Firewall に同じセキュリティポリシーを一貫して適用したい
  • 全社共通の禁止ルールと、各拠点固有のルールを階層的に分離して管理したい
  • ハブ仮想ネットワークやセキュアハブの境界防御を、1か所から見渡して運用したい
  • ファイアウォールの構成ドリフト(個別の手作業による設定差異)をガバナンスで抑え込みたい
  • 仮想 WAN のハブを通る通信を、まとめてファイアウォールへ誘導して検査したい

主要概念と用語

  • Azure Firewall Manager(ファイアウォールマネージャー): 複数の Azure Firewall とファイアウォールポリシーを一元管理する管理プレーン。ファイアウォール自体を提供するのではなく、その統制と配布を担う
  • ファイアウォールポリシー(Firewall Policy): ルールやしきい値、脅威インテリジェンス設定などをまとめた、Azure Firewall に適用する設定の入れ物。複数のファイアウォールへ再利用でき、リージョンをまたいで共有できる
  • 親ポリシーと子ポリシー(ポリシー継承): 上位の親ポリシーを下位の子ポリシーが継承する階層構造。親で定めた全社共通ルールが子に引き継がれ、子は固有ルールを追加できる
  • ルールコレクショングループ / ルールコレクション: ポリシー内のルールをまとめる階層。優先度に基づいて評価順が決まり、ネットワークルール・アプリケーションルール・DNAT ルールを分類して保持する
  • ハブ仮想ネットワーク(Hub Virtual Network): 自分で構築・運用するハブ&スポーク構成の中央 VNet に Azure Firewall を配置する形態。トポロジは自分で制御する
  • セキュアハブ(Secured Virtual Hub): Azure Virtual WAN の仮想ハブに Azure Firewall を組み込み、ハブ自体を検査ポイントにした形態。ルーティングをマネージドに任せられる
  • 脅威インテリジェンス(Threat Intelligence): Microsoft の脅威情報フィードに基づき、既知の悪性 IP やドメインへの通信を警告またはブロックする機能。ポリシー単位で設定する

仕様・制限・クォータ

  • 管理プレーンであり課金の主体ではない: Firewall Manager 自体は中央管理の枠組みで、実体として動くのはあくまで各 Azure Firewall。料金はファイアウォールとポリシー側に紐づく
  • 2つの配置形態を扱う: 自前で組むハブ仮想ネットワーク型と、Virtual WAN のセキュアハブ型の双方を一元管理できる
  • ポリシーはリージョン横断で共有: 1つのファイアウォールポリシーを複数リージョンの複数ファイアウォールに割り当てられる。親子継承で共通部分を集約する
  • SKU とポリシー種別の対応: Premium 機能(TLS インスペクション、IDPS、URL フィルタリングなど)を使うにはファイアウォールとポリシーの双方が Premium である必要がある。Standard ポリシーを Premium ファイアウォールに使うことは可能だが、その逆は制限される
  • ルールの上限: ポリシーあたりのルールコレクショングループ数や総ルール数、IP グループのサイズなどに上限がある。数値は変動するため定性的に捉え、最新の公式ドキュメントで確認する
  • 従来のクラシックルール(Firewall 単体のルール)からの移行: クラシックルールはファイアウォールポリシーへ移行でき、Firewall Manager で集中管理する形が推奨される

内部の仕組み

Firewall Manager は、ファイアウォールポリシーという再利用可能な設定単位を中心に動きます。ポリシーを作って複数の Azure Firewall に関連付けると、各ファイアウォールがそのルールセットに従って通信を検査します。

  • ポリシー継承: 親ポリシーで全社共通ルールを定義し、子ポリシーがそれを継承する。子は親のルールを上書きせず、自身の固有ルールを追加する。これにより共通ガバナンスと拠点裁量を両立できる
  • 評価順序: ルールはルールコレクショングループとルールコレクションの優先度に基づいて評価される。親ポリシーのルールが子のルールより先に評価されるため、全社禁止ルールを確実に先行させられる
  • セキュアハブでのルーティング: Virtual WAN のセキュアハブでは、ルーティングインテント(ルーティングポリシー)と組み合わせ、ハブを通る東西(VNet 間)・南北(インターネット向け)の通信をファイアウォールへ強制的に引き込んで検査する
  • DNS と脅威インテリジェンス: ポリシーで DNS プロキシや FQDN ベースのルール、脅威インテリジェンスのモード(警告のみ/警告とブロック)を一括設定し、傘下のファイアウォールへ反映する
ファイアウォール本体との役割分担

Azure Firewall がトラフィックを実際に検査・遮断する「データプレーン」だとすれば、Firewall Manager はそのルールを設計・配布し、複数台を束ねて統制する「管理プレーン」です。1台だけを運用するなら Firewall 単体でも足りますが、台数が増えるほど中央管理の価値が効きます。

設計パターン / ベストプラクティス

  • 共通ルールは親ポリシーへ: 全社で禁止すべき宛先や許可すべき基盤サービスを親ポリシーに集約し、各環境の子ポリシーへ継承させる。共通部分の修正が1か所で済む
  • 環境ごとに子ポリシー: 本番・検証・部門別などで子ポリシーを分け、固有ルールはそこへ閉じ込める。最小権限と変更影響範囲の限定を両立する
  • 大規模・多リージョンで採用価値が高い: ファイアウォールが1台だけなら Firewall 単体で十分。複数台・複数リージョンに同一ガバナンスを効かせたい場面で真価が出る
  • セキュアハブで検査を集約: Virtual WAN を使うなら、自前のハブ VNet にファイアウォールを置く代わりにセキュアハブを採り、ルーティングインテントで通信を強制検査する
  • IP グループで宛先を共通化: よく使う IP レンジを IP グループにまとめ、複数ルール・複数ポリシーから参照して保守性を上げる
  • IaC で宣言的に管理: ポリシーと継承関係を Bicep / Terraform で記述し、ルール差分をレビュー可能にしてドリフトを防ぐ

運用・監視

  • Azure Monitor / ファイアウォールログ: 各 Azure Firewall のアプリケーションルールログ・ネットワークルールログ・DNAT ログ・脅威インテリジェンスログを Log Analytics へ集約し、横断的に分析する
  • ポリシーアナリティクス: ルールのヒット状況や重複・未使用ルールを分析し、ポリシーの整理・最適化に役立てる機能を活用する
  • 継承関係の可視化: 親子ポリシーの構造とどのファイアウォールにどのポリシーが割り当たっているかを定期的に棚卸しし、意図しない継承や孤立ポリシーを検出する
  • 変更管理: ポリシー更新は傘下の複数ファイアウォールへ波及するため、変更前に影響範囲を確認し、段階的に適用する。IaC のレビューと組み合わせると安全
  • メトリクスの監視: スループット、SNAT ポート使用率、ヘルス状態などをファイアウォール単位で監視し、容量とパフォーマンスを把握する

コスト

Firewall Manager 自体は中央管理の枠組みであり、コストの主体は管理対象の Azure Firewall とそのデータ処理です。台数とデータ量、そして必要な SKU(Standard / Premium)で見積もりが決まります。

コスト要素課金の考え方メモ
Azure Firewall 稼働ファイアウォール単位の時間課金デプロイ台数に比例して増える
データ処理処理したデータ量に応じた課金通過トラフィックが多いほど増加
Premium 機能Premium SKU の上位料金TLS 検査や IDPS を使うと高くなる
セキュアハブVirtual WAN ハブ側のコストも発生ハブとファイアウォールの両方を見積もる
Firewall Manager管理プレーン自体の独立課金は限定的コストはファイアウォール側に紐づく
台数が増えるとコストが積み上がる

ファイアウォールは稼働しているだけで基礎課金が発生し、台数とデータ処理量で増えていきます。リージョンごとに無条件で増やすのではなく、検査が本当に必要な境界に絞り、共通ポリシーで統制してから台数を決めると過剰投資を避けられます。

セキュリティ

  • 共通ガバナンスの強制: 親ポリシーで全社共通の禁止・許可ルールを定義し、子ポリシーへ確実に継承させて、拠点ごとのルール抜けを防ぐ
  • 脅威インテリジェンスの有効化: Microsoft の脅威情報フィードに基づく既知の悪性 IP・ドメインへの通信を、ポリシー単位で警告またはブロックに設定する
  • Premium の高度検査: 要件に応じて TLS インスペクション、IDPS(侵入検知防止)、URL フィルタリングを Premium で有効化し、暗号化通信や既知攻撃を検査する
  • 中央集約の検査ポイント: セキュアハブやハブ仮想ネットワークに検査を集約し、東西・南北の通信を必ずファイアウォール経由にして素通りを防ぐ
  • 最小権限の管理: ポリシーやファイアウォールの変更権限を RBAC で絞り、構成変更を監査ログで追跡する
アンチパターン

ファイアウォールを各リージョンに配置しただけで安心し、ルーティング(セキュアハブのルーティングインテントやハブ VNet のユーザー定義ルート)で通信を実際にファイアウォール経由へ誘導していないと、スポーク間トラフィックが検査されずに素通りします。ポリシーの統制と経路設定はセットで考える必要があります。

関連サービス・比較

Firewall Manager は AWS の AWS Firewall Manager に概念が近く、複数の防御リソースを横断的に統制し、共通ポリシーを組織全体へ配布する管理層という点で対応します。実際にトラフィックを検査する Azure Firewall 本体とは役割が異なる点を整理します。

観点Azure Firewall ManagerAzure Firewall 単体
役割複数ファイアウォールとポリシーの統制トラフィックを検査・遮断する実体
管理単位ポリシーと親子継承で中央集約個々のファイアウォールごとに設定
適用範囲複数リージョン・複数台を横断そのファイアウォールの境界のみ
対応形態ハブ VNet とセキュアハブの両方配置された VNet またはハブ内
向く規模多リージョン・多台のガバナンス単一境界・少数台の防御
AWS の対応AWS Firewall Manager に近いAWS Network Firewall に近い
使い分けの軸

守りたい境界が1つだけなら Azure Firewall 単体で足り、複数台に同じガバナンスを一貫適用したいなら Firewall Manager で統制する、という具合に「台数とガバナンス要件」で選ぶと迷いにくくなります。

ハンズオン / CLI例

# リソースグループを作成
az group create --name fwmgr-rg --location japaneast

# 親となるファイアウォールポリシー(全社共通ルールの土台)を作成
az network firewall policy create \
  --resource-group fwmgr-rg \
  --name corp-base-policy \
  --location japaneast \
  --sku Standard \
  --threat-intel-mode Alert

# 親ポリシーを継承する子ポリシー(環境固有ルール用)を作成
az network firewall policy create \
  --resource-group fwmgr-rg \
  --name prod-policy \
  --location japaneast \
  --sku Standard \
  --base-policy corp-base-policy

# 子ポリシーにルールコレクショングループを追加
az network firewall policy rule-collection-group create \
  --resource-group fwmgr-rg \
  --policy-name prod-policy \
  --name prod-app-rules \
  --priority 200

# アプリケーションルール(許可する FQDN)をコレクションへ追加
az network firewall policy rule-collection-group collection add-filter-collection \
  --resource-group fwmgr-rg \
  --policy-name prod-policy \
  --rule-collection-group-name prod-app-rules \
  --name allow-updates \
  --collection-priority 210 \
  --action Allow \
  --rule-name allow-windowsupdate \
  --rule-type ApplicationRule \
  --target-fqdns "*.update.microsoft.com" \
  --source-addresses "10.0.0.0/16" \
  --protocols Https=443

# 作成済みの Azure Firewall に子ポリシーを関連付ける
az network firewall update \
  --resource-group fwmgr-rg \
  --name prod-firewall \
  --firewall-policy prod-policy

Azure Service

Azure Firewall Managerを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

ネットワーキング

比較で見る軸

クラウド: Azure / カテゴリ: ネットワーキング / 難易度: intermediate

導入後に効く点

親ポリシーを子へ継承し、全社共通ルールと拠点固有ルールを両立。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
Azure
カテゴリ
ネットワーキング
難易度
intermediate
関連資格
設計柱
security / operational

判断チェックリスト

  • 自社の用途が「ネットワーキング / security」に近いか確認する。
  • 強みである「複数の Azure Firewall とポリシーをまとめて統制する管理プレーン。」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

ネットワーキングsecurityoperational