今回は Azure Policy の効果の1つである DenyAction 効果について検証してみたいと思います。この効果を使うことで、リソースに対する特定のアクションのみを拒否することができるようになります。
更新履歴
日付 | 内容 |
---|---|
2025/05/25 | 初版作成 |
効果とは
Azure Policy では、ポリシーがどのように評価され、どのような動作をするかを「効果」と呼ばれる設定で定義します。
効果にはいくつかの種類があります。
例:
- Append: リソース作成/更新時にフィールドを追加または上書きします
- Audit: リソースを監査しログエントリを生成しますが、変更はしません
- AuditIfNotExists: 特定のリソースが存在しない場合に監査ログを生成します
- Deny: リソースの作成や更新を拒否します
- DenyAction: リソースに対する特定のアクションのみを拒否します
- DeployIfNotExists: リソースが存在しない場合に関連リソースをデプロイします
- Disabled: ポリシーの評価を無効化します
- Manual: リソース遵守に関して手動の操作が必要であることを示します
- Modify: リソースのプロパティを自動的に修正します
効果の詳細については、Azure Policy の効果について | Microsoft Learn を参照してください。
また、Azure Policy の DeployIfNotExists
効果の詳細については、以前の記事「Azure Policy -DeployIfNotExists- のタイミングをコントロールし隊 – クラウドを勉強し隊」も併せてご覧ください。
今回は DenyAction に焦点を当てて検証していきます。
DenyAction とは
DenyAction は、Azure Policy の効果の1つで、リソースに対する特定のアクションのみを拒否することができます。
従来の Deny 効果との主な違いは、リソースの作成・更新を全面的に拒否するのではなく、特定のアクションのみを拒否できる点にあります。
例えば、以下のような場合に役立ちます:
- リソースの削除は拒否したいが、更新は許可したい
- リソースの特定の操作のみを制限したい
DenyAction: リソースへの特定のアクションのみを拒否し、他のアクションは許可します。
DenyAction の制限事項
DenyAction 効果には以下の制限事項があります:
- 現在サポートされているアクションは DELETE のみ: DenyAction は現在、削除操作のみをブロックするために使用されます。
- 403 (Forbidden) エラー: DenyAction によってブロックされたリクエストは 403 (Forbidden) エラーとして返されます。Azure Portal では、これはポリシー割り当てによってブロックされたデプロイとして表示されます。
- ロックアウト防止のための除外: 以下のリソースタイプは DenyAction の適用から除外されており、これにより管理者がポリシー自体を管理できなくなる状況を防いでいます:
- Microsoft.Authorization/policyAssignments
- Microsoft.Authorization/denyAssignments
- Microsoft.Blueprint/blueprintAssignments
- Microsoft.Resources/deploymentStacks
- Microsoft.Resources/subscriptions
- Microsoft.Authorization/locks
カスケード動作
DenyAction は「カスケード動作」をサポートしており、親リソース(例えばリソースグループ)に対する削除操作が試行された場合の挙動を制御できます。
カスケード動作は cascadeBehaviors
プロパティで設定でき、既定値は Deny です。
削除する親の種類によって動作が異なります。
詳しくは Azure Policy 定義の denyAction 効果 - Azure Policy | Microsoft Learn を見てください
ざっくり手順
- Azure Policy 定義を作成
- ポリシー定義をスコープに割り当て
- 動作を検証(当該リソースの削除)
- 動作を検証(リソースグループの削除)
1. Azure Policy 定義を作成
DenyAction 効果を使用するポリシーを作成します。今回は、仮想マシンの削除操作を拒否するポリシーを例として作成します。
以下は、仮想マシンの削除操作を拒否するポリシー定義の例です:
|
|
このポリシー定義では:
"effect": "denyAction"
で DenyAction 効果を指定しています"actionNames": ["delete"]
で削除アクションを拒否しています
ポリシー定義を Azure Portal で作成します
2. ポリシー定義をスコープに割り当て
作成したポリシー定義を、サブスクリプションやリソースグループなどのスコープに割り当てます。
Azure Portal からポリシーを割り当てる場合:
- Azure Portal で 「ポリシー」 に移動します
- 「定義」 をクリックします
- 作成したポリシー定義 「Deny virtual machine deletion」 を選択します
- 「割り当て」 をクリックします
- 割り当てるスコープを選択し、ポリシーを割り当てます
このポリシー割り当ての適用時間ですが、以前までは 30分という表記だった気がしますが、今回試すと 5 ~ 15分という表記になっていました
3. 動作を検証(当該リソースの削除)
ポリシーが適用されたら、仮想マシンに対する削除操作を試して動作を確認します。
- 対象のスコープ内に仮想マシンを作成します
- 作成した仮想マシンを削除しようとします
- 削除操作が拒否され、エラーメッセージが表示されることを確認します

想定通り、削除操作が拒否されました
4. 動作を検証(リソースグループの削除)
次に、リソースグループの削除操作を試して、カスケード動作を確認します。
想定通り、リソースグループの削除は拒否されました
まとめ
Azure Policy の DenyAction 効果は、リソースに対する特定のアクションのみを制限したい場合に非常に便利です。従来の Deny 効果と異なり、きめ細かい制御が可能となり、運用の柔軟性を維持しながらセキュリティを強化することができます。
特に、以下のような場合に DenyAction の使用を検討することをお勧めします:
- リソースの削除を防ぎたいが、更新は許可したい場合
- 特定の操作のみを制限したい場合(ただし、現在は Delete アクションのみがサポートされています)
- リソースグループの削除からリソースを保護したい場合(カスケード動作の活用)
ただし、現時点では DenyAction がサポートするアクションは DELETE のみであることに注意が必要です。適切に設計された DenyAction ポリシーは、Azure リソースを保護しながらも、運用チームの日常的な作業を妨げることなく、バランスの取れたガバナンスを実現することができます。