Azure Resource Locks入門｜ReadOnlyロックとDeleteロックで本番リソースの誤削除・誤変更を防ぐ実践ガイド

「本番のAzure VMを誤って削除してしまった」「誰かがリソースグループごと消した」——こんなインシデントを耳にするたびに、クラウドの怖さを実感します。オンプレミスの時代であれば、変更管理プロセスや物理的な制限でリソースを守れていました。しかしAzureでは、権限さえあればポータルから数クリックで本番DBを削除できてしまいます。

この記事では、Azure Resource Locksを使った本番リソースの保護について、オンプレ経験者にもわかりやすく解説します。DeleteロックとReadOnlyロックの違い、スコープの設計、ポータル・CLI・Bicepによる設定手順、そして実務でハマる落とし穴まで、現場で即使える知識をまとめました。

なぜAzure Resource Locksが必要なのか

オンプレミス環境では、本番サーバーに手を加えるには通常、変更申請→承認→実施というプロセスが必要でした。物理ラックへのアクセス制限や、VMwareのvCenter権限管理もあり、誤って本番VMを削除するシナリオは現実的には起こりにくい環境でした。

Azureに移行すると、この「摩擦」がなくなります。IAMで権限を持っていれば、ポータルにログインして「削除」ボタンを押せばリソースは即座に消えます。削除確認ダイアログはありますが、「はい」を押すだけです。

加えて、以下のようなシナリオでも誤削除が起こりえます。

・Terraform/Bicepの誤操作: `terraform destroy` を本番リソースグループに対して実行してしまう
・スクリプトのバグ: リソースを列挙して削除するスクリプトが本番を対象にしてしまう
・Azure Portalの操作ミス: リソースを間違えて選択したまま削除を実行する
・ロールの権限過多: 開発者に必要以上の権限を与えており、本番リソースを変更できてしまう

Azure Resource Locksはこうした誤操作をシステム的に防ぐ最後の防衛線です。Azure Policy（コンプライアンスチェック）やIAM（アクセス制御）と組み合わせることで、多層防御を実現します。

Azure Resource Locksの種類と動作

Azure Resource Locksには2種類あります。

1. Delete（CanNotDelete）ロック

最もよく使われるロックです。リソースの削除を防ぎますが、設定変更や更新は引き続き可能です。本番VM・データベース・ストレージアカウントなど、運用中に設定変更が発生するリソースに向いています。

ポータルではロック名を「Delete」と表示しているドキュメントと「CanNotDelete」と表示しているものがありますが、同じものです（APIレベルの値は `CanNotDelete`）。

2. ReadOnly ロック

削除だけでなく変更も防ぎます。Azure CLIでいえば `GET` 系操作しか受け付けず、`PUT`/`PATCH`/`DELETE` はすべて拒否されます。設定変更が不要な参照用リソースや、変更を完全に凍結したいリソースに使います。

ただし、ReadOnlyは想定外の動作を引き起こしやすいため、後述するように適用範囲に注意が必要です。

スコープの継承

Resource Locksはスコープの上位から下位に継承されます。

・サブスクリプションレベル: そのサブスクリプション内の全リソースグループ・リソースに適用
・リソースグループレベル: そのリソースグループ内の全リソースに適用（最もよく使う設定）
・リソース個別: 特定のリソースのみに適用

実務では**本番リソースグループ全体にDeleteロックをかける**のが最もシンプルで効果的です。

ロックの設定手順

1. Azure ポータルでの設定

1. Azureポータルで対象のリソースグループ（またはリソース）を開く
2. 左メニューの「設定」→「ロック」をクリック
3. 「＋追加」をクリック
4. ロック名（例: `prod-rg-delete-lock`）を入力
5. ロックの種類で「削除」（Delete）または「読み取り専用」（ReadOnly）を選択
6. 「OK」をクリック

設定後、そのリソースグループ内のVMやDBを削除しようとすると「ロックのため削除できません」というエラーが表示されます。

2. Azure CLIでの設定

# リソースグループにDeleteロックを設定
az lock create \
  --name prod-rg-delete-lock \
  --resource-group myProductionRG \
  --lock-type CanNotDelete \
  --notes "本番環境の誤削除防止のためのロック"

# ロックの確認
az lock list --resource-group myProductionRG --output table

# ロックの削除（ロック削除には Microsoft.Authorization/locks/delete 権限が必要）
az lock delete \
  --name prod-rg-delete-lock \
  --resource-group myProductionRG

3. Bicep（ARM テンプレート）での設定

Infrastructure as Code で本番環境を管理している場合、ロックもコードに含めることで設定漏れを防げます。

# Bicep でリソースグループにロックを設定する例
# リソースグループスコープで実行する（targetScope を設定）

targetScope = 'resourceGroup'

resource rgLock 'Microsoft.Authorization/locks@2020-05-01' = {
  name: 'prod-rg-delete-lock'
  properties: {
    level: 'CanNotDelete'
    notes: '本番環境の誤削除防止のためのロック'
  }
}

Terraformの場合は `azurerm_management_lock` リソースを使います。

# Terraform でリソースグループにDeleteロックを設定
resource "azurerm_management_lock" "prod_rg_lock" {
  name       = "prod-rg-delete-lock"
  scope      = azurerm_resource_group.production.id
  lock_level = "CanNotDelete"
  notes      = "本番環境の誤削除防止のためのロック"
}

4. ロック変更に必要な権限

Resource Locksの追加・変更・削除には `Microsoft.Authorization/locks/*` 操作が必要です。組み込みロールでは以下が該当します。

・Owner: ロックの作成・変更・削除が可能
・User Access Administrator: ロックの作成・変更・削除が可能
・Contributor: ロックを変更・削除できない（作成も不可）
・Reader: ロックの参照のみ可能

Contributorロールを持つユーザーはリソースを自由に変更できますが、ロックを削除して削除操作を実行することはできません。このため、本番リソースグループにDeleteロックをかけておけば、Contributor権限の開発者が誤って削除することを防げます。

料金の仕組み

Azure Resource Locksの利用は**無料**です。ロックの数や種類に関わらず追加コストは発生しません。

なお、ロックを設定し忘れて誤削除が起きた場合の「復旧コスト」は別の話です。VM・ディスクは削除後にリストアするにはAzure Backupが必要で、バックアップを取っていなければ原状回復は困難です。ロック設定の手間は数分ですが、誤削除後の復旧作業は数時間から場合によっては不可能になることもあります。コスト面だけ見ても、ロックの導入は明らかにペイします。

応用・実務Tips

本番リソースグループ全体への一括適用パターン

最もシンプルかつ効果的なのが、本番リソースグループ全体にDeleteロックをかけるパターンです。個々のリソースにかける必要がなく、新しくリソースを追加しても自動的にロックが継承されます。

# 本番リソースグループ一覧を取得してロックを一括設定するサンプル（Azure CLI）
for rg in $(az group list --query "[?tags.Environment=='Production'].name" -o tsv); do
  az lock create \
    --name "prod-delete-lock" \
    --resource-group "$rg" \
    --lock-type CanNotDelete \
    --notes "本番環境の誤削除防止"
  echo "ロックを設定しました: $rg"
done

Azure Policyと組み合わせた多層防御

Azure Policyと組み合わせることで、「本番リソースグループには必ずDeleteロックが設定されていること」をコンプライアンスルールとして自動チェックできます。ロックが設定されていないリソースグループをポリシーで検知し、アラートや自動修復で対応する多層防御が実現します。

タグと組み合わせた管理

リソースグループに `Environment: Production` タグを付け、タグ一致条件でロック管理スクリプトを動かすパターンもよく使われます。新規にリソースグループを作成した担当者がロック設定を忘れても、定期的なAzure Automationジョブで補完できます。

デプロイ時のロック解除・再設定パターン

CI/CDパイプラインでインフラをデプロイする場合、ロックがあるとリソースの変更・削除が失敗することがあります。このケースでは以下の手順を自動化します。

1. デプロイ前にロックを削除（Service PrincipalにOwnerまたはUser Access Administratorロールを付与）
2. Bicep/TerraformでInfrastructureをデプロイ
3. デプロイ後にロックを再設定

パイプラインのサービスプリンシパルにはOwner権限が必要なため、そのSPの権限管理を厳重にすることがポイントです。

よくあるトラブルと対処法

ReadOnlyロックでVMが起動・停止できなくなる

VMにReadOnlyロックをかけると、VMの起動・停止操作も「変更」とみなされてブロックされます。これはAzure VMの状態変更がAPIの `POST` ではなく内部的に `PUT` 相当で処理されるためです。

本番VMは通常Deleteロックで十分です。ReadOnlyが必要な場面（設定変更を完全に凍結したい場合）は、ロックの影響範囲を事前に検証環境で確認してから適用してください。

ストレージアカウントへのReadOnlyがAzure Filesに影響する

Azure FilesをマウントしているストレージアカウントにReadOnlyロックをかけると、ファイル共有の読み書きが失敗することがあります。ストレージアカウントへの書き込み操作がブロックされるためです。Deleteロックに留めておくのが安全です。

「ロックのため操作を実行できません」エラーの確認方法

削除や変更が失敗したとき、エラーメッセージに `ScopeLocked` または `ConflictLock` が含まれていればロックが原因です。Azure Portalでリソースの「ロック」ブレードを確認するか、以下のCLIで確認します。

# 特定リソースグループに設定されているロックを確認
az lock list --resource-group myProductionRG --output table

# サブスクリプション全体のロック一覧を確認
az lock list --output table

子リソースは削除できるのに親が消せない

リソースグループにDeleteロックをかけている場合、リソースグループ内の個別リソース（VM、ディスクなど）はロックを持たないため、個別リソースの削除は成功することがあります。リソースグループ自体を削除しようとするとロックでブロックされます。

「リソースグループごと消したい」という操作を防ぐのがリソースグループレベルのDeleteロックの主な用途です。配下の個別リソースも守りたい場合は、個別リソースにもロックを追加するか、IAMのContributorロールの見直し（本番へのDeleteアクセスを制限）と組み合わせます。

Terraformが apply/destroy でエラーになる

Terraformの `terraform destroy` がロックのためにエラーになるのは正常な動作です。本番環境のDestroyを誤実行から守るためにロックを設定しているからです。CI/CDパイプラインでDestroyを実行する場合は、前述のロック解除・再設定パターンを組み込んでください。開発・ステージング環境はロックなし、本番はロックありという構成が一般的です。

本記事のまとめ

Azure Resource Locksは、Azureガバナンスの中で最もシンプルかつ即効性の高いリソース保護手段です。

・Delete（CanNotDelete）ロックは、削除を防ぎつつ変更は許可する。本番リソースグループ全体への適用が基本パターン
・ReadOnlyロックは、削除も変更も防ぐが、VMやストレージへの適用は想定外の副作用が出やすいため事前検証が必要
・ロック変更には Owner または User Access Administrator ロールが必要。Contributorはロックを外せない
・BicepやTerraformでロックをコード管理することで、新規リソース追加時の設定漏れを防げる
・Azure PolicyやAzure Automationと組み合わせることで、「本番リソースグループには必ずDeleteロックが存在する」という状態を継続的に保証できる

オンプレミス時代の変更管理プロセスが持っていた「物理的・手続き的な摩擦」を、クラウドではResource Locksが代替します。本番環境を構築したら、ロックの設定を忘れずに。