はじめに
こちらは エーピーコミュニケーションズ Advent Calendar 2025 15日目の記事です。
こんにちは。ACS事業部の青木です。
あなたの組織では、Azure Firewallを使っていますか？
Azure Firewallを組織で使おうとするときに大変なのが、「どうやって増えていくルールを管理するか？」ということです。
あらかじめ整理しておかないと、「ルールが増えすぎて管理不能になった」「どのルールがどこに効いているのかわからない」となってしまいます。
セキュリティ対策のために導入するものである以上、このような事態は避けたいものです。
今回は、そんな事態を避けるために、 Microsoftの推奨プラクティスをベースに「運用を見据えた Azure Firewall ポリシー設計」のベストプラクティスを考えてみましたのでご紹介します。
これから Azure Firewall ポリシーを導入しようとしている方や、新規設計を行う方の参考になれば幸いです。
前提事項
今回の設計が前提としている環境と、組織体制について説明します。
ネットワーク構成：ハブアンドスポーク構成
まず、今回のポリシー前提とするネットワーク構成は以下のような ハブアンドスポーク構成 を前提としています。
(ワークロードのアイコンとしてAKSを用いていますが一例です。VMでもFunctionでもApp Serviceでも問題ありません)
ハブスポークは様々なパターンがありますが、スポーク側でWAF、ハブ側でAzure Firewallを使用するパターンの構成を採用しています。
今回の構成のハブとスポーク、それぞれの役割について簡単に説明します。
- ハブ: Azure Firewall を配置し、全通信の監視・制御を行う集約地点。
- インターネットからのHTTP(S)以外のプロトコルのインバウンド通信を受信し、プライベートIPアドレスに変換
- オンプレミスおよび各スポークのシステムからの通信はすべてハブを経由し、そのすべての通信をAzure Firewallで監視・制御
- スポーク: 各システム（ワークロード）が配置される場所。
- インターネットからのシステムへのHTTP(S)インバウンド通信を受信し、通信を監視
- システムからのアウトバウンド通信はハブ VNet側のAzure Firewallを通って通信
こちらの構成について詳しくは、以下のページを参照してみてください。
また、そもそもハブスポーク構成って何？という方はこちらもおすすめです。
また、今回はハブ側の管理権限を持つのはプラットフォームチーム、スポーク側の管理権限を持つのはアプリケーションチームという前提でお話をしたいと思います。
そのため、プラットフォームチームがガバナンスを効かせつつ、アプリケーションチームはシステムが正常に稼働するために必要な許可ルールなどの情報をプラットフォームチームに提供するイメージです。
Azure Firewall ポリシー周りの基本知識
続いて、Azure Firewall ポリシーの設計を理解するうえで最低限必要な知識についても説明したいと思います。
そんなこと知ってるよ！という方は読み飛ばしていただいて構いません。
FirewallインスタンスとFirewall ポリシーの役割について
Azure Firewallには、主要のコンポーネントとしてFirewall ポリシーとFirewallインスタンスが存在します。
Firewallポリシーはルールのリストであり、Firewallインスタンスが実際にルールの処理を行うという間柄です。
また、仕様上Firewallインスタンスには一つのFirewallポリシーしか適用することができませんが、複数のFirewallポリシー同士で親子関係を作ったうえでFirewallインスタンスに子のFirewallポリシーを適用することで、継承元である親ポリシーのルールも自動的に評価されます。
評価順序は 親ポリシー → 子ポリシー となり、親で拒否された通信は子で許可することはできません。これにより、全社的なセキュリティポリシーを強制することが可能になります。
Firewall ポリシーの構成について
Firewall ポリシーには、Rule Collection Group、Rule Collection、Ruleの三種類の階層が存在します。
図にするとこんな感じです。
それぞれ簡単に説明します。
Rule Collection Group（RCG）
- 一番上の階層で、1個以上のRule Collectionを持ちます。
- 優先度の概念を持ち、番号が少ないほど先に評価されます。
Rule Collection（RC）
- RCGの中に存在し、1個以上のRuleを持ちます。
- RCGと同様に優先度の概念を持ち、番号が少ないほど先に評価されます。
Rule Collectionには、トラフィックの種類（DNAT / Network / Application）とアクションの種類(Allow / Deny)によって合計5つの種類に分類されます。
分類 (ルール種別 - アクション) 説明 DNAT Azure Firewall が持つパブリック IP アドレスに届いたトラフィックを、プライベート IP アドレスに変換するためのルール Network - 許可 IP アドレス (L3/L4) ベースの通信を 許可 するためのルール Network - 拒否 IP アドレス (L3/L4) ベースの通信を 拒否 するためのルール Application - 許可 ドメイン・URL (L7) ベースの通信を 許可 するためのルール Application - 拒否 ドメイン・URL (L7) ベースの通信を 拒否 するためのルール
Rule
- RCの中に存在し、具体的なルールの内容が定義されています。
- 優先度の概念は持たないリスト形式になっており、上のRuleから順番に評価されます。
評価順序について
最後に評価順序についてまとめます。
押さえておくべきポイントは、大きく分けて三つです。
①必ずDNATルール、Networkルール、Applicationルールの順番で評価を行う
②RCGの優先度の番号が小さい順、その次にRCの優先度の番号が小さい順で評価を行う。
③親子関係を持っているポリシーの場合は、親ポリシーの評価が優先される。
ここは非常に重要なポイントであり混乱しやすいポイントでもあるため、ぜひ以下のページを読んでいただき理解していただきたいと思います。
（ここで詳しく説明すると文章量が多くなりすぎてしまうため、割愛します）
Azure Firewall ポリシーの設計について
ここでようやく、今回作成したAzure Firewall ポリシーの設計について触れていきます。
まず、親子関係を作るポリシーは同一リージョンである必要があるため、Azure Firewall ポリシーは同じリージョンに2種類作成し、親子関係（継承）を設定します。
それぞれ以下のような役割でポリシーを分けています。
- 親ポリシー（Parent Policy）
- 役割: 全社的なガバナンス、セキュリティベースラインを適用する際に利用。
- 適用範囲: 全システム共通の許可・拒否ルール。
- 子ポリシー（Child Policy）
- 役割: 各システム固有の通信要件への対応。
- 適用範囲: 各スポーク内のシステムに必要な個別ルール。
そのうえで、以下についてそれぞれ説明します。
- 親ポリシーの設計方針
- 子ポリシーの設計方針
- ポリシー共通: RC内部の優先度とルール
1. 親ポリシーの設計方針
親ポリシーは「全社共通で遵守すべき通信要件」について定める必要があるため、以下の4つの RCG を用意しました。
まずはこの4種類から始めてみて、別カテゴリを増やす必要性を感じたら増やすとよいでしょう。
| RCG | 目的 | RCの分割単位 |
|---|---|---|
| セキュリティ | セキュリティ上、アクセスさせないIPやドメインのブロック | 脅威の種類ごと |
| 共通基盤 | 各種ワークロードが稼働するために必要なアクセス先へを許可するルールなど、全社的に必要な通信 | ワークロードの種類ごと |
| 運用監視 | 監視エージェント、バックアップ、ログ転送などの通信 | ツールごと |
| オンプレ環境 | 全社共通で接続が必要なオンプレミスリソースへの通信 | 接続先環境ごと |
親ポリシーの優先度範囲
親ポリシーはシンプルに 100 刻みで設定します。
| RCG | 優先度 |
|---|---|
| セキュリティ | 100 |
| 共通基盤 | 200 |
| 運用監視 | 300 |
| オンプレ環境 | 400 |
2. 子ポリシーの設計方針
子ポリシーは、各スポーク（システム）ごとの要件に関連した設定を保持します。
そのため以下のように、スポークごとにRCGを作成して管理していきます（スポークの数=RCGの数）。
- スポークその1: 部門Aのシステム①本番環境
- スポークその2: 部門Aのシステム①開発環境
- スポークその3: 部門Bのシステム①開発環境
- スポークその4: 部門Bのシステム②開発環境
子ポリシーの優先度範囲
子ポリシーはシステム数が増えるため、桁を増やして管理します。 まず、部門単位で大きな枠を確保します。以下は一例です。
| Group種類 | Priority範囲 |
|---|---|
| 部門A | 1000 ~ 1999 |
| 部門B | 2000 ~ 2999 |
| 部門C | 3000 ~ 3999 |
その上で、各枠の中で 「スポーク（環境）」単位 に数値を割り当てます。
以下は一例です。
| Group種類 | 設定値の例 |
|---|---|
| システム① 開発環境 | 1001 |
| システム① 検証環境 | 1002 |
| システム① 本番環境 | 1003 |
| システム② 開発環境 | 1004 |
| システム② 検証環境 | 2001 (部門Bの先頭) |
| システム② 本番環境 | 2002 |
このように枠を決めておくことで、将来システムが増えた際も設計の手戻りが少なくなります。
【注意】子ポリシーの設計上発生するルールの抜け穴を防ぐ
子ポリシーで個別にルールを書かせると、どうしても「とりあえず Any で通しちゃえ」という甘い設定が発生しがちです。また、優先度の設計上、もしも高い優先度を持つRCGで緩いルールを書かれると、後続のルールが無効化されるリスクがあります。
それを防ぐため、以下のガイドラインを制定し、可能であればAzure Policyで操作を禁止します。
- Source (送信元):
*,Any,0.0.0.0/0の使用を禁止。必ず送信元を絞らせる。 - Destination (宛先):
*,Any,0.0.0.0/0の使用は許可するが、その場合は 宛先プロトコル（ポート）での*指定を禁止 する。（「どこからでも、どこへでも、全ポート許可」というルールを作らせない）
運用ルールをドキュメントに書くだけでなく、Azure Policy でシステム的に縛ることで、長期間運用してもポリシーが崩壊しないように工夫しています。
3. ポリシー共通: RC内部の優先度とルール
RCGの中にある、個々のRCについては、アクション種別ごとに優先度を定義することで管理を楽にします。
| ルール種別 | アクション | Priority範囲 |
|---|---|---|
| DNAT | - | 1000 ~ 1999 |
| Network | Deny | 2000 ~ 2999 |
| Network | Allow | 3000 ~ 3999 |
| Application | Deny | 4000 ~ 4999 |
| Application | Allow | 5000 ~ 5999 |
ポイント： * 明示的な Deny ルールを Allow よりも高い優先度（小さい数値）に設定することで、意図しない許可を防ぎます。 * Azure Firewall のルール処理ロジックとして、DNAT → Network → Application の順に評価されるため、この特性と合わせて設計する必要があります。
おわりに
あくまでも今回の設計は一例です。
ハブスポーク構成や組織の特性によってベストな設計は変わるため、グループの切り方や優先度設計は組織の要件に合わせて自由に変更いただくのが良いと思います。
ただ、どんな構成にしろ大切なのは「今後の運用・拡張性までしっかり考えられた構成になっているか？」という視点を忘れないことです。
本ブログをきっかけに、Azure Firewallの構成について考えてみるきっかけにしていただけたら大変うれしく思います。 ぜひこれを機会に、Azure Firewallに触れてみてください。
ここまでお読みいただき、ありがとうございました。
ACS事業部のご紹介
私達ACS事業部はクラウドネイティブ技術、Azure AI サービス、Platform Engineering、AI駆動開発支援などを通して、攻めのDX成功に向けた開発者体験・開発生産性の向上・内製化のご支援をしております。
www.ap-com.co.jp
また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。
www.ap-com.co.jp
