Azureのリソースをロックする。あとで後悔するかも。

はじめに

あなたは仮想マシンを間違って削除したことありますか？

リソースをロックすることで、それを回避することができます後で後悔することもないでしょう。

意外とリソースのロックは行わてれいないように思われます。特にお客様と同じ環境で構築や開発を行っている場所ではその傾向があると思います。

おさらいを含めてリソースのロックについて説明していきます。

ロックの種類

リソースのロックには2種類あります。読み取り専用と削除です。それぞれユーザーが行える権限は以下です。

違いは変更できるかできないかです。

ネットワークセキュリティグループを例に考えてみたいと思います。

• 読み取り専用：設定情報、ポートやソースなどは表示されて読めるが、規則を追加したり、ポートを変更したり、ソースを変更することができない。そして規則の削除やネットワークセキュリティグループそのものの削除は行えない。
• 削除：ポートやソースなどは表示されて読め、規則を追加したり、ポートを変更したり、ソースを変更することができる。ただし規則の削除やネットワークセキュリティグループそのものの削除は行えない。

例にネットワークセキュリティグループを上げましたが、ほかのリソースでも基本動作は同様です。

ただし、リソースによって対象となる行為（変更となる行為、さくじょとなる行為）が異なるので確認が必要です。まとまってる資料もありません。

考慮事項

思いのほか考慮事項があります。

だれが設定できる

• 所有者
• ユーザーアクセス管理者

この２ロールに、ロックの作成削除を行える権限があります。

これ以外のユーザーに権限を与えたい場合は、カスタムロールを利用して下記の権限を与えます。

• Microsoft.Authorization/*
• Microsoft.Authorization/locks/*

ポータルから確認した場合（Microsoft.Authorization/locks/*）

適用範囲

ロックはスコープで設定されます。

サブスクリプション単位でロックを掛けると、そのサブスクリプションのリソースグループや、リソース全体にロックが掛かります。

リソースグループ単位でロックを掛けると対象のリソースグループと、その中にあるリソースにロックが掛かります。

リソース単位でロックを掛けると対象はそのリソースのみです。

オーバーライド

ロックはオーバーライド（上書き）することができます。

リソースグループに削除のロックを行い、リソースに読み取り専用のロックを行います。

この場合、削除＝変更可能ですが、読み取り専用が上書きされて変更不可になります。

ただし、読み取り専用を削除でオーバーライドすることはできません。

まとめ

ロックを行うことは非常に重要です。特に本番環境でリリース後に行うことが多い作業です。本番環境を間違って削除したくないですもんね。

ただし、留意事項もあるのでいきなり本番環境ではなく検証環境で問題なく動作するか確認してから行ってください。

間違って削除して後悔しないためにもロックすることをお勧めします。