Azure Firewall Managerを理解するための前提
Azure Firewall Managerはcloud-based security perimeterのcentral security policy/route management service。 architectureはSecured virtual hub (Virtual WAN hub)とHub virtual networkの2系統を扱う。
Secured virtual hubではVirtual WANのhub routingとsecurity configurationを統合し、spoke/branch/PaaS/Internet trafficをFirewallへ誘導できる。 Hub virtual networkはcustomer-managed VNetで、Firewall Policyを中央適用しつつpeering/UDR等を自分で設計する。
複数region/subscriptionへFirewallをdeploy/configureし、global parent policy + local child policyのhierarchyを使える。 Firewall Managerを使ってもdata planeのroute、DNS、SNAT、stateful symmetry、logsを個別に検証する必要がある。
Control plane と data plane
仕組み
organization baseline Firewall Policyを定義する。
regional hubをsecured virtual hubまたはhub VNetとして選定する。
Firewall/Policy associationとspoke/branch connectionを構成する。
routing policy/UDRで対象trafficをFirewallへ通す。
Firewall logsとsource NIC/connection routeで実際のinspection pathを検証する。
Packet / decision path
障害時はresource一覧ではなく、同じsource/destination/port/protocolで各enforcement pointを順に追います。
- Virtual WANを既にtransit platformとするならsecured virtual hubを第一候補にする。
- custom routing/NVA/既存hub VNet要件が強ければhub VNet architectureを評価する。
- parent policyはenterprise-wide non-negotiable baselineに限定する。
- regionごとのegress/ingress source IPとfailure domainを明示する。
- central management成功をdata-plane成功と混同しない。
設計判断
| 判断点 | 推奨 | 理由 |
|---|---|---|
| Architecture | Secured virtual hub vs Hub VNetをrouting ownershipで選ぶ。 | managed routeかcustomer UDRかが運用モデルを大きく変える。 |
| Policy hierarchy | global parent + local child。 | 標準化とapplication autonomyを両立。 |
| Region | regional inspection/failoverを設計。 | cross-region hairpinを避ける。 |
| Governance | subscription/RBAC/Policy ownershipをplatform teamへ明示。 | spoke teamがbaselineを迂回しない。 |
確認手順
Azure Portal / Network Watcher
- Firewall Manager → Secured hubs / Firewall policiesで対象regionとassociationを確認。
- Secured hubならConnections/Routing status、hub VNetならpeering/UDRを確認。
- 各Firewallのlogsとspokeからのactual routeを確認。
Verification discipline
- subscription / resource group / resource ID / NIC / direction / 5-tupleを記録する。
- 同じ条件でbefore/afterを比較し、既存sessionとnew connectionを区別する。
- configuration、effective state、logs、application resultを別々の証拠として残す。
- 変更成功はcontrol-plane Succeededではなくobservable data-plane behaviorで判定する。
az network firewall policy list -o table
az network firewall list -o table
az network vhub list -o tableGet-AzFirewallPolicy
Get-AzFirewall障害切り分け
| 症状 | 疑う点 | 証拠 | 次の確認 |
|---|---|---|---|
| Manager上はpolicy適用済みだがbypass | spoke routing/connection propagation | effective route / vHub routing | routingを修正 |
| 一部regionのみrule差 | child policy/association drift | parent/child IDsとRCG diff | hierarchyを標準化 |
| secured hub化後にroute変化 | Virtual WAN managed routing behavior | hub route tables/connection propagation | design matrixへ戻して修正 |
| central rolloutで広範囲障害 | parent policy blast radius | rule hit/log + deployment history | canary region/child validationを導入 |
変更時の確認と rollback
- global parent Policy変更は段階rollout/canaryを前提にする。
- rollbackはPolicy version/associationに加え、secured hub routing changeも戻す。
- regionごとのnew-flow testで復旧を確認する。