Cloud Service
Azure Firewall Manager
複数の Azure Firewall とセキュリティポリシーを横断的に一元管理し、ハブ&スポークやセキュアハブの境界防御を中央集権化。組織全体のルールを階層的に継承させる管理プレーン。AWS の Firewall Manager に近い。
- 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 Manager | Azure 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、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。