AzureでOwnerなのにリソースを削除できない、仮想マシンを再起動できない場合は、RBACの権限不足ではなく、Azure Resource Managerのリソースロックが原因になっている可能性があります。
Ownerはリソースを管理できる強いロールですが、設定済みのロックを自動的に無視できるわけではありません。削除だけが失敗するならCanNotDelete、再起動や設定変更まで失敗するならReadOnlyを疑います。対象リソースだけでなく、リソースグループとサブスクリプションに設定された継承ロックまで確認することが重要です。([Microsoft Learn][1])
Ownerなのに操作できない理由
Azureでは、RBACとリソースロックが別々に評価されます。
RBACは「そのユーザーに操作を許可するか」を決める仕組みです。一方、リソースロックは「権限を持つユーザーであっても、その操作を実行させない」ための保護機能です。
つまり、Ownerに削除権限があっても、対象リソースに削除ロックが設定されていれば削除できません。
Ownerは通常、管理ロックを作成・削除する権限を持っています。しかし、それは「ロックを解除できる」という意味であり、「ロックを残したまま対象操作を実行できる」という意味ではありません。管理ロックはユーザーやロールを横断して適用されます。([Microsoft Learn][1])
RBACとリソースロックの違い
| 項目 | Azure RBAC | リソースロック |
|---|---|---|
| 主な目的 | ユーザーやサービスごとに許可する操作を決める | 誤削除や意図しない変更を防ぐ |
| 判定対象 | ユーザー、グループ、サービスプリンシパルなど | 対象スコープ内のすべてのユーザーとロール |
| Ownerへの影響 | 原則として管理操作を許可する | Ownerの操作も制限する |
| 主な確認場所 | アクセス制御（IAM） | ロック、リソースロック |
| 代表的な症状 | 操作権限がないというエラー | スコープがロックされているというエラー |
エラーに「authorization」「権限がない」といった内容が表示される場合はRBACが疑われます。一方、「locked」「ロックされている」と表示される場合は、リソースロックを優先して確認します。
ただし、エラーメッセージだけで決めつけず、実際のロック設定と割り当てスコープを照合してください。
CanNotDeleteとReadOnlyの違い
Azureのリソースロックには、主に次の2種類があります。
Azureポータルでは「削除」と「読み取り専用」、Azure CLIなどではCanNotDeleteとReadOnlyと表記されます。([Microsoft Learn][1])
| ロックの種類 | 読み取り | 更新・設定変更 | 削除 | VMの開始・再起動 |
|---|---|---|---|---|
| CanNotDelete | 可能 | 原則可能 | 不可 | 原則可能 |
| ReadOnly | 可能 | 不可 | 不可 | 不可になることがある |
削除だけできない場合はCanNotDeleteを疑う
CanNotDeleteは、リソースの読み取りや変更を許可しながら、削除だけを禁止するロックです。
次のような状態なら、CanNotDeleteが有力です。
- リソースの設定変更はできる
- 仮想マシンの再起動はできる
- リソースの削除だけ失敗する
- リソースグループの削除が失敗する
ただし、表面上は更新に見える操作でも、内部的に既存リソースや子リソースの削除を伴う場合があります。そのような処理はCanNotDeleteでも失敗する可能性があります。
再起動や設定変更もできない場合はReadOnlyを疑う
ReadOnlyは、読み取り以外の管理操作を広く制限します。
仮想マシンの開始や再起動は、単純な情報取得ではありません。Azure Resource Managerに対するPOST操作を使用するため、仮想マシンまたは親スコープにReadOnlyロックがあると実行できません。
Microsoft Learnでも、仮想マシンを含むリソースグループに読み取り専用ロックが設定されている場合、すべてのユーザーが仮想マシンを開始・再起動できなくなると説明されています。([Microsoft Learn][1])
ReadOnlyで影響を受ける操作は、明らかな設定変更だけではありません。たとえば、次のような操作も内部的に書き込みやPOSTを使用するため、失敗することがあります。
- 仮想マシンの開始、停止、再起動
- App Serviceプランのスケール変更
- Automation Runbookの開始
- ストレージアカウントキーの一覧表示
- Application Gatewayのバックエンド正常性確認
- 一部のAzureポータル画面での情報取得
「見るだけの操作に見えるのに失敗する」という場合も、ReadOnlyロックを確認してください。
Azureの削除・再起動がロックで拒否されるときの確認方法
リソースロックは親スコープから継承されます。対象リソースの画面に直接設定されたロックだけを見て判断してはいけません。
確認する順序は次のとおりです。
- 対象リソース
- リソースグループ
- サブスクリプション
- 必要に応じて親リソースや子リソース
対象リソースのロックを確認する
Azureポータルで操作対象のリソースを開きます。
左側のメニューから、次のような項目を探してください。
- ロック
- リソースロック
- Settings配下のLocks
表示名や配置はサービスやAzureポータルの更新によって異なる場合があります。見つからない場合は、ポータル上部やリソースメニューの検索機能で「ロック」または「Locks」と検索します。
ロックが見つかったら、次の情報を確認します。
- ロック名
- ロックの種類
- 設定されているスコープ
- メモ
- 継承元
- 管理主体
リソースグループのロックを確認する
対象リソースに直接ロックがなくても、所属するリソースグループに設定されている可能性があります。
対象のリソースグループを開き、設定メニューから「ロック」を確認します。
リソースグループに設定されたロックは、原則としてグループ内のリソースに継承されます。後から追加したリソースも対象です。([Microsoft Learn][1])
サブスクリプションのリソースロックを確認する
リソースグループにもロックがない場合は、サブスクリプションを確認します。
Azureポータルで対象サブスクリプションを開き、「リソースロック」を確認してください。
サブスクリプションにReadOnlyロックが設定されていれば、配下の多くの管理操作が制限されます。影響範囲が非常に広いため、解除する前に設定目的と運用ルールを確認する必要があります。
最も厳しいロックが優先される
複数の階層に異なるロックが設定されている場合は、継承経路の中で最も厳しい制約が優先されます。
たとえば、次の構成を考えます。
| スコープ | ロック |
|---|---|
| サブスクリプション | CanNotDelete |
| リソースグループ | ReadOnly |
| 仮想マシン | なし |
この仮想マシンには、実質的にReadOnlyの制約が適用されます。
子リソースにCanNotDeleteを追加しても、親のReadOnlyを緩和することはできません。ロックの例外設定として機能するわけではないためです。([Microsoft Learn][1])
リソースグループを削除できない場合は子リソースも確認する
リソースグループ自体にロックがなくても、グループ内の子リソースに削除ロックがあると、リソースグループ全体の削除が失敗します。
Azureは、ロックされていないリソースだけを部分的に削除するのではなく、リソースグループの削除操作全体をブロックします。([Microsoft Learn][1])
たとえば、次の状態ではリソースグループを削除できません。
- リソースグループ：ロックなし
- 仮想マシン：ロックなし
- ストレージアカウント：CanNotDelete
- ネットワークインターフェイス：ロックなし
リソースグループを削除するときは、親スコープだけでなく、配下のリソースに直接設定されたロックも確認してください。
Azure CLIで継承ロックを確認する方法
対象リソースが多い場合や、Azureポータルだけでは原因を見つけにくい場合は、Azure CLIで確認できます。
最初に、現在選択されているサブスクリプションを確認します。
az account show --output table別のサブスクリプションを選択する場合は、次のように切り替えます。
az account set --subscription "<サブスクリプション名またはID>"現在のサブスクリプション内にあるロックを一覧表示します。
az lock list --output table特定の仮想マシンに関係するロックを確認する例は次のとおりです。
az lock list --resource "<VM名>" --resource-type "Microsoft.Compute/virtualMachines" --resource-group "<リソースグループ名>" --output tableリソースを指定したaz lock listでは、そのリソースに関連するリソースグループおよびサブスクリプションのロックも確認できます。([Microsoft Learn][2])
子リソースや拡張リソースでは、リソースタイプや親パスの指定が必要になる場合があります。コマンドが対象を返さないときは、サブスクリプション全体の一覧をJSON形式で取得して、ロックIDと対象リソースIDを照合する方法が確実です。
az lock list --output jsonロックを安全に一時解除する手順
本番環境のロックを、エラー解消だけを目的に無断で削除するのは危険です。
次の順序で作業します。
ロックの設定内容を記録する
解除前に、少なくとも次の項目を記録します。
- ロック名
- CanNotDeleteまたはReadOnly
- 設定スコープ
- メモの内容
- ロックを設定した目的
- ARMテンプレートやBicepなどの管理元
- 作業後に戻す担当者
スクリーンショットだけでなく、文字情報として記録しておくと再設定時の間違いを防げます。
解除の承認を得る
ロックは誤操作を防ぐために設定されています。
特に次のスコープの解除は、影響範囲が大きくなります。
- サブスクリプション
- 本番リソースグループ
- 共有ネットワーク
- 共有ストレージ
- バックアップ関連リソース
- 複数システムが利用する基盤リソース
変更管理や承認手続きがある組織では、作業日時、解除対象、実施操作、復旧手順を明確にします。
原因となるロックだけを解除する
複数のロックをまとめて削除せず、対象操作を妨げているロックだけを解除します。
継承されたロックの場合は、子リソース側では解除できません。実際にロックが設定されている親スコープで操作する必要があります。
たとえば、リソースグループのReadOnlyが原因なら、仮想マシン側に設定を追加して回避することはできません。承認後に、リソースグループ側のロックを一時解除します。
必要な操作だけを実施する
ロック解除中は、本来防止されていた操作が可能になります。
作業範囲を広げず、承認された削除、再起動、設定変更だけを実施してください。
削除作業では、対象リソース名、リソースグループ、サブスクリプションを再確認します。似た名前の検証環境と本番環境を取り違えないようにします。
同じスコープと種類でロックを戻す
作業後は、解除前と同じ条件でロックを再作成します。
確認する項目は次のとおりです。
- ロック名が正しいか
- CanNotDeleteとReadOnlyを取り違えていないか
- 元と同じスコープか
- メモが復元されているか
- 対象リソースで制約が再び有効になっているか
リソースに設定されていたロックを、誤ってリソースグループへ戻すと影響範囲が広がります。反対に、リソースグループのロックを個別リソースへ戻すと、保護されないリソースが発生します。
Ownerなのにロック自体を削除できない場合
Ownerであっても、必ずすべてのロックを削除できるとは限りません。
Ownerの割り当てスコープが狭い
Ownerが付与されているスコープを確認してください。
対象リソースだけのOwnerである場合、リソースグループやサブスクリプションに設定されたロックを削除する権限はありません。
例として、次の状態では親ロックを解除できません。
- 仮想マシン：Owner
- リソースグループ：閲覧者
- サブスクリプション：権限なし
- 原因となるロック：リソースグループに設定
ロックの作成・削除には、ロックが存在するスコープでMicrosoft.Authorization/locks/*などの操作権限が必要です。Ownerやユーザーアクセス管理者には通常、この権限が含まれます。([Microsoft Learn][1])
Managed Applicationが所有するロックである
一部のAzureサービスは、サービス内部のインフラストラクチャを管理対象リソースグループに配置し、そのリソースグループへシステム所有のロックを設定します。
この場合、ロックを直接削除しようとすると、システムアプリケーションが所有しているため削除できない旨のエラーが表示されることがあります。
このロックを無理に外そうとしてはいけません。管理対象リソースグループではなく、元となるサービス側から削除や構成変更を実行します。サービスを削除すると、関連する管理対象リソースグループも所定の手順で削除されます。([Microsoft Learn][1])
Infrastructure as Codeで管理されている
ロックがARMテンプレート、Bicep、Terraformなどで管理されている場合、Azureポータルで一時的に削除しても、次回のデプロイで再作成される可能性があります。
手動変更による構成差分を避けるため、次の点を確認します。
- ロック定義を管理しているリポジトリ
- デプロイパイプライン
- 再適用のタイミング
- 手動変更を許容する運用か
- コード側の変更が必要か
緊急作業で一時解除した場合も、コード上の定義と実環境の状態が一致していることを確認してください。
リソースロックはBlobなどのデータ削除を全面的に防げない
リソースロックが保護するのは、主にAzure Resource Managerを通るコントロールプレーン操作です。
Azureの操作は、大きく次の2種類に分けられます。
| 種類 | 主な役割 | 例 |
|---|---|---|
| コントロールプレーン | Azureリソースそのものを管理する | ストレージアカウントの作成、VMの構成変更 |
| データプレーン | リソース内のデータや機能を利用する | Blobの読み書き、データベースへのクエリ |
ストレージアカウントにCanNotDeleteやReadOnlyを設定しても、データプレーン経由で実行されるBlob、キュー、テーブル、ファイルの削除や変更まで一律に防げるわけではありません。([Microsoft Learn][1])
ストレージアカウント自体の削除防止と、保存データの削除防止は分けて設計する必要があります。
データを保護する場合は、サービスに応じて次の対策を組み合わせます。
- データプレーン側のRBAC
- 削除権限の最小化
- 論理削除
- バージョン管理
- 保持期間
- 不変ストレージ
- バックアップ
「ストレージアカウントにロックを付けたから、Blobも削除されない」とは判断しないでください。
よくある失敗と対策
対象リソースのロックしか確認しない
親のリソースグループやサブスクリプションから継承されたロックを見落とすパターンです。
対象リソース、リソースグループ、サブスクリプションの順に確認します。
Ownerならロックを無視できると思う
Ownerはロックを管理できても、ロック中の操作をそのまま通せるわけではありません。
必要な承認を得てロックを解除し、作業後に戻します。
CanNotDeleteとReadOnlyを混同する
削除だけが失敗するならCanNotDelete、再起動や設定変更も失敗するならReadOnlyが有力です。
両方の症状がある場合は、別の階層にReadOnlyがないか確認してください。
念のためすべてのロックを削除する
不要な範囲まで保護を解除すると、別のリソースを誤って変更・削除するリスクが高まります。
原因となるロックとスコープを特定し、必要なものだけを一時解除します。
ロックを別のスコープへ戻してしまう
同じ種類のロックでも、サブスクリプション、リソースグループ、個別リソースでは影響範囲が異なります。
解除前にスコープを記録し、同じ場所へ戻してください。
Managed Applicationの子ロックを直接外そうとする
システム所有のロックは、通常のリソースロックと同じ感覚で扱えません。
管理対象リソースグループを直接操作せず、元となるサービスから削除や変更を実行します。
ロックが原因かを判断するチェックリスト
次の順序で確認すると、原因を切り分けやすくなります。
- 操作対象のディレクトリとサブスクリプションが正しいか確認する
- Ownerがどのスコープに割り当てられているか確認する
- 対象リソースのロックを確認する
- リソースグループのロックを確認する
- サブスクリプションのリソースロックを確認する
- CanNotDeleteとReadOnlyを区別する
- 複数ある場合は最も厳しいロックを特定する
- リソースグループ削除時は子リソースのロックも確認する
- Managed Application由来のロックではないか確認する
- 承認後に必要なロックだけを一時解除する
- 作業後、同じスコープと種類でロックを戻す
Ownerなのに削除や再起動ができないときは、権限を追加する前にリソースロックを確認してください。特に、削除だけを止めるCanNotDeleteと、再起動を含む管理操作を止めるReadOnlyの違いが重要です。
対象リソースにロックが見つからなくても、リソースグループやサブスクリプションから継承されている可能性があります。ロックを解除するときは、設定目的と影響範囲を確認し、必要なロックだけを一時解除して、作業後に元の状態へ戻します。
[1]: https://learn.microsoft.com/ja-jp/azure/azure-resource-manager/management/lock-resources “インフラストラクチャを保護するためにAzure リソースをロックする – Azure Resource Manager | Microsoft Learn”
[2]: https://learn.microsoft.com/ja-jp/cli/azure/lock “az lock | Microsoft Learn”
コメント