Networking RBAC / Least Privilegeを理解するための前提
Network ContributorはMicrosoft.Network/*を中心にネットワーク管理を許可するが、VMのdeploy/manage権限そのものは付与しない。 DNS Zone ContributorとPrivate DNS Zone Contributorは対象scopeが異なり、Private DNS Zone Contributorはリンク先VNetを管理する権限ではない。
role assignmentはmanagement group→subscription→resource group→resourceのscope inheritanceを考慮してeffective accessを判断する。 Network Watcherの機能にはOwner/Contributor/Network Contributor、または必要actionを含むcustom roleが必要になる。
障害対応で権限不足を見たときは「role名」だけでなくprincipal・scope・inheritance・deny assignment/PIM状態を証拠化する。
Control plane と Data plane
仕組みと設計上の意味
Azure RBACはcontrol planeへの認可であり、NSGやFirewall ruleそのものとは別のsecurity planeです。Network Contributorを持つユーザーがnetwork configurationを変更できても、そのユーザー自身がVMへSSHできるとは限りません。逆にVM login roleを持っていてもVNet/NSGを変更できるとは限りません。
ネットワーク運用では「Network Contributorをsubscription全体に付ける」のが簡単ですが、blast radiusが大きくなります。landing zoneやcentral connectivityでは、shared hub RG、spoke RG、DNS zone、Network Watcherなど責務ごとにscopeを分け、PIM/時間制限を併用する方が監査しやすくなります。
Operational / decision path
対象scopeと時刻を固定し、read-only evidence → 判断 → change → same testで再検証の順を崩さない。
- principalのobject IDを確定し、表示名だけで判断しない。
- 対象resource IDと親scopeを固定する。
- direct assignmentとinherited assignmentを列挙し、role definitionのActions/NotActions/DataActionsを確認する。
- Network Watcher等の実行actionが必要なら、その操作に必要なpermissionを照合する。
- temporary elevationを使った場合は終了後にassignment/PIM状態を再確認する。
設計判断
| 判断点 | 推奨 | 理由 |
|---|---|---|
| Assignment scope | 最小の責務scopeへ付与 | subscription-wide Network Contributorを常設しない |
| Operations | read-only調査とchange権限を分離 | incidentで見る人と変更する人の責務を分けられる |
| Shared services | hub/DNS/securityを別scopeで管理 | spoke operatorがcentral networkを誤変更するのを防ぐ |
| Automation | service principal/managed identityを個別化 | 人間の権限とpipeline権限を混ぜない |
確認手順
Azure Portal
- 対象resource → Access control (IAM) → Role assignmentsでThis resource/Inheritedを確認。
- Role definitionsからNetwork Contributor等のActions/NotActionsを確認。
- PIMを使用している場合はeligible/active assignmentと有効期限も確認。
Evidence contract
Read-only first: 以下のCLI/PowerShellは原則として参照系から開始します。コメントでMUTATINGと示した操作は、必要性・scope・rollbackを確認した後にのみ実行します。
# read-only: 対象scopeのassignment
az role assignment list --scope <resource-id-or-scope> --all --include-inherited -o table
# principalを固定して確認
az role assignment list --assignee-object-id <object-id> --all --include-inherited --fill-principal-name false -o jsonc
# built-in role definition
az role definition list --name "Network Contributor" -o jsoncGet-AzRoleAssignment -Scope <resource-id-or-scope> -IncludeClassicAdministrators:$false |
Select-Object DisplayName, ObjectId, RoleDefinitionName, Scope
Get-AzRoleDefinition -Name "Network Contributor" |
Select-Object Name, Actions, NotActions, DataActions, NotDataActions障害切り分け
| 症状 | 疑う点 | 証拠 | 次の確認 |
|---|---|---|---|
| Portalは見えるが変更できない | Reader/inherited roleのみ、PIM inactive | IAM + role assignment list | 必要actionをrole definitionで照合 |
| Network Watcher toolがAuthorizationFailed | diagnostic action不足 | error action string + role definition | custom role/Network Contributor scopeを確認 |
| DNSは変更できるがVNet link操作に失敗 | zone権限とVNet権限のscope差 | 両resourceのIAM | linked VNet側permissionを確認 |
| 突然権限が消えた | PIM expiry/assignment removal/deny | Activity Log + PIM history | principal IDと時刻を相関 |
変更・rollback
- 権限追加は最小scope・最短時間から始め、問題切り分け目的でOwnerを恒久付与しない。
- custom role変更はActionsのワイルドカード拡大をreviewし、既存assignmentへの影響も確認する。
- role assignment削除前にautomation principalか人間かを識別し、deployment/monitoring停止を避ける。
- rollbackは元のrole assignment ID/scope/role definitionを記録してから行い、変更後は実際の操作でleast-privilege境界を確認する。