Security Admin Rulesをworkload NSGの代替ではなく、central governance teamが所有するorganization-wide guardrailとして扱う。中央で固定する禁止・必須許可と、application teamへ残すleast-privilege制御を分離し、rule actionごとのNSGへの継続/終了、Private Endpointのcurrent limitation、regional deploymentをacceptance criteriaへ含める。
Security Admin Rulesを理解するための前提
Security Admin RulesはAzure Virtual Network ManagerからVNetへ適用する中央security controlで、NSGより先に評価される。central teamがbaseline guardrailを持ち、workload teamはNSGでapplication固有制御を追加する。 actionはAllow / Always Allow / Deny。Allowはsecurity admin ruleで許可された後もNSG評価へ進むため、workload側でさらに絞り込める。
Always Allowは後続NSG評価を終了してtrafficを許可し、Denyも後続評価を終了して遮断する。例外用途でAlways Allowを乱用するとworkload NSGの防御を迂回する。 Security Admin Ruleは現在VNet levelへ適用され、Network Groupを使って複数VNetへ一元配布する。group membershipとconfiguration deploymentの両方が適用対象を決める。
Microsoft Learnのcurrent documentationではmanaged VNet scope内のPrivate EndpointにはSecurity Admin Rulesが適用されないと明記されている。Private Endpoint protectionを同ルールだけに依存しない。 一つのregionへ複数security admin configurationをそのままdeployするのではなく、必要な複数policy domainは一つのsecurity configuration内の複数rule collectionとして設計する。
deploymentはeventual consistencyで反映される。deploy APIの成功直後だけで全VNetへ適用済みと判定せず、effective rule / representative flowを確認する。
Ownership / Control / Data plane boundary
organization-wide Denyや必須Allowをcentral governance teamが所有する。
subnet/NIC NSGでapplication固有のleast privilegeをworkload teamが所有する。
AllowはNSGへ継続、Always Allow / Denyはsecurity admin ruleで評価終了する。
Private Endpoint等のcurrent coverage limitationを別controlで補完する。
Architecture model
設計判断
| 判断軸 | 推奨する問い | 設計時に固定するもの |
|---|---|---|
| Central baseline | どのflowをorganization-wideに絶対禁止・必須許可とするか。 | rule purpose、source/destination、priority、action、owner。 |
| Action choice | Allowでworkload裁量を残すか、Always Allow / Denyで中央判断を確定するか。 | action rationale、downstream NSG expectation、exception。 |
| Rule collections | environment / trust / exceptionをどのrule collectionへ分離するか。 | collection owner、Network Group binding、priority policy。 |
| Private Endpoint | Security Admin Rules対象外のPrivate Endpoint trafficを何で保護するか。 | NSG/subnet policy、service-side access、Private Link/DNS governance。 |
| Deployment wave | どのregion / groupから適用するか。 | canary、positive/negative flow、stop condition、rollback config。 |
| Exception governance | 一時例外をAlways Allowで作る必要が本当にあるか。 | approval、expiry、compensating control、removal evidence。 |
実装・展開の順序
- 既存NSG baselineをinventoryする。 central guardrailと重複/矛盾しそうなrules、critical management flow、break-glass pathを抽出する。
- central policyを最小化する。 全workload共通で説明できるDeny/AllowだけをSecurity Admin Rulesへ上げ、application固有条件を中央へ吸い上げ過ぎない。
- Network Groupをcanary化する。 representative VNetを少数選び、Private Endpoint有無やNSG patternを含むtest matrixを作る。
- rule actionを検証する。 Allow→NSG継続、Always Allow/Deny→評価終了という期待をpositive / negative flowで実証する。
- region単位にdeployする。 eventual consistencyを考慮してeffective stateが収束してから次waveへ進む。
- exceptionを期限管理する。 temporary Always Allow等はowner/expiryを必須にし、期限後の削除と再testまでchangeを閉じない。
Platform team / Workload team の責任分界
| 領域 | Platform / central team | Workload / application team |
|---|---|---|
| Security baseline | Security Admin Rules、priority standard、Network Group bindingを所有。 | central baselineを前提にapplication固有requirementsを提示。 |
| NSG | 共通template / minimum controlを提示。 | subnet/NIC NSGとapplication least privilegeを実装。 |
| Exceptions | cross-workload例外とbreak-glassを審査。 | 業務理由、期限、対象flow、compensating controlを申請。 |
| Private Endpoint | central coverage limitationと補完standardを定義。 | PE subnet/service-side access/DNSを実装し別途検証。 |
| Verification | effective admin rulesと共通negative testを提供。 | real application journey、NSG hit/effective ruleを確認。 |
Actionごとの評価モデル
| Security Admin action | NSGへ進むか | 設計上の意味 |
|---|---|---|
| Allow | 進む | 中央で候補flowを許可するが、workload NSGはさらにDenyできる。通常の責任分界を維持しやすい。 |
| Always Allow | 進まない | NSGによる後続denyを迂回して必ず許可する。例外・基盤必須flowでもblast radiusを厳格に限定する。 |
| Deny | 進まない | NSGに関係なく中央で遮断する。全社guardrailに向くが、誤適用時の影響が大きい。 |
Verification / review evidence
設計レビューで残す証拠
- Security Admin configuration / rule collection / ruleのsource version
- Network Group membershipとtarget region deployment status
- rule priority / action / source / destinationのreviewed matrix
- 既存NSGとの重複・矛盾一覧
- Private Endpointを含むcoverage gapとcompensating control
- exception owner / expiry / approval / rollback record
runtimeで確認すること
- Deny flowがNSGの許可有無に関係なく遮断されること
- Allow flowがNSGでさらにDeny可能であること
- Always Allow対象だけがNSGを迂回し、範囲外へ広がっていないこと
- canary VNetのeffective security admin rulesが期待versionへ収束すること
- Private Endpoint flowは別controlで期待通り保護されていること
- rollback後にcentral ruleとworkload NSGの合成結果がknown-goodへ戻ること
az network manager security-admin-config list --network-manager-name <manager> --resource-group <rg> -o tableaz network manager list-effective-security-admin-rule --network-manager-name <manager> --resource-group <rg> --virtual-network-name <vnet> -o jsoncCommon failure modes
| 症状 / anti-pattern | 原因になりやすい設計 | 確認・是正 |
|---|---|---|
| NSG Allowなのに通信できない | 上位Security Admin RuleがDeny。 | effective security admin ruleをNSGより先に確認。 |
| NSG Denyなのに通信できる | Always AllowでNSG評価を迂回。 | action typeとrule priorityを確認し、Always Allowの必要性を再審査。 |
| Private Endpointも守られていると思ったが対象外 | Security Admin Rulesのcurrent coverage limitationを設計に反映していない。 | PE用のNSG/service-side/access governanceを別controlとして検証。 |
| deploy直後にVNetごと結果が違う | eventual consistency中に完了判定。 | deployment statusとeffective ruleの収束を待ち、wave gateを定義。 |
| 中央rulesがapplication仕様だらけ | central guardrailとworkload least privilegeの責任分界が崩壊。 | 共通baselineだけ中央へ残し、application固有条件はNSGへ戻す。 |
Change safety / rollback
Current notes — 2026-09-11
Microsoft Learnは現在、managed virtual networkのscopeに入るPrivate EndpointへSecurity Admin Rulesは適用されないと明記している。仕様は更新され得るため、設計・監査時にcurrent coverageを再確認する。