1. はじめに
Azure Policy を触り始めて、どうしても Effect (効果)の意味が分からないという方はいらっしゃいませんか？有名なものだと DeployIfNotExists といったパラメータがあります。
公式ドキュメント : Azure Policy の効果について に解説されているのですが、イマイチ理解ができないといった方も多いのではと思い、ちょっと自分の頭の整理も兼ねて整理してみたいと思います。
2. そもそも Azure Policy の Effect って何？
Azure Policy が条件にマッチした際に、どのような行動を起こすのかを定義するのが effect です。
以下が Azure Policy の基本となる構文になります。
{
"if": {
<condition> | <logical operator> //条件にマッチしたら
},
"then": { // 以下の効果を実施する
"effect": "deny | audit | append | auditIfNotExists | deployIfNotExists | disabled"
}
}
2021.8 現在、Azure Policy では以下の Effect がサポートされています。
| 優先順位 | Effect | 概要 |
|---|---|---|
| 1 | Disabled | Policy 定義が有効なのか無効なのかどうかを判定する |
| 2 | Append | 作成中または更新中に要求されたリソースにフィールドを追加する |
| 2 | Modify | 作成時または更新時に、サブスクリプションまたはリソースのプロパティまたはタグを追加、更新、または削除する |
| 3 | Deny | 定義された基準に一致していないものを拒否する |
| 4 | Audit | 監査ログに記録を残す (Azure Activity Log) |
| 5 | AuditIfNotExists | if 条件下のリソースに対して、監査ログに記録を行う (リソース プロバイダーでリソースの作成/更新要求が処理された後に実行される) |
| 6 | DeployIfNotExists | 条件が満たされたときにテンプレートのデプロイを実行する >(リソース プロバイダーでリソースの作成/更新要求が処理された後に実行される) |
3.サンプル例
Disabled = テスト用途（無効化）
テスト用途。状況をテストする場合や、効果がポリシー定義によってパラメーター化されている場合に役立ちます。
Append = 設定パラメータ等の付加
対象のリソースに対して、設定のパラメータを付加します。代表的なものにタグ付与があります。
- タグとその値のリソース グループへの追加
- Azure Cosmos DB キー ベースのメタデータ書き込みアクセスを無効にする必要がある
Modify = パラメータの修正
作成時または更新時に、サブスクリプションまたはリソースのプロパティまたはタグを追加、更新、または削除するために使用されます。
Deny = 拒否!
作成されるリソースを止めるために用いることができます。
デフォルト定義されたルールの多くは、audit、deny、disable の三択を Effect 効果で選べるようになっており、ポリシーにマッチした条件について、監査するか、拒否するかを選べるようになっています。
Audit = 監査として記録する
作成されるリソースに対して、監査記録として残します。アラート条件で通知したり、Azure Activity Log 経由で後で調査するなどの方法が考えられます。
AuditIfNotExits = 監査として記録する（基本設定されていないといけないリソース）
Audit と同様ですが、IfNotExits の条件にある通り、基本的にポリシー対象がリソース内に存在していることを前提にチェックする効果です。企業のベースライン準拠や、セキュリティなどは、基本的に「その設定が行われていること」をチェックするため、既存環境の設定などの洗い出し、監査を目的に使う効果になります。
AuditInfNotExits で動作する組み込みの定義ルールは以下のようなものがあります。
DeployIfNotExits ルールと被るものも多いですが、セキュリティ監査のルールが多いように思います。
- 一覧に含まれる仮想マシン イメージの仮想マシン スケール セットでは Log Analytics エージェントを有効にする必要がある
- アクティビティ ログがあるコンテナーを含むストレージ アカウントは、BYOK を使用して暗号化する必要がある
- 仮想マシンに Log Analytics エージェントをインストールする必要がある
DeployIfNotExits = 強制ポリシーとして適用させる
AuditIfNotExits をさらに強化した効果であり、IfNotExits の条件に無かった場合、テンプレートをデプロイするポリシーになります。強制化といった設計ができますね。
公式ドキュメントにも記載がある通り、デプロイはサブスクリプションまたはリソースの作成または更新要求が処理され、成功を示す状態コードが返されてから約 15 分後に実行されます。
DeployInfNotExits で動作する組み込みの定義ルールは以下のようなものがあります。
診断ログを自動有効にする、エージェントを自動導入するなどのポリシーが多いように思えます。
- デプロイ - Log Analytics エージェントを Windows 仮想マシンで有効になるように構成する
- Linux 仮想マシン用の Dependency Agent のデプロイ
- Batch アカウントの診断設定をイベント ハブにデプロイする
- Data Lake Analytics の診断設定をイベント ハブにデプロイする
4. Azure Policy が提供しているルールの一覧
公式ドキュメントに「Azure Policy の組み込みのポリシー定義」が公開されています。こちらを見ると、各ポリシー毎の Effect 効果が分かるので、それぞれどのようなアクションが行われるのか分かるようになっています。
5.まとめ
Azure Policy の定義済みポリシーだけを眺めていても、どのような影響を与えるのか分からなかったのですが、Effect を理解しておくことで目的に対するポリシー効果などを使い分けるのか分かるのではないかと思います。どなたかの参考になれば幸いです。
＊本稿は、個人の見解に基づいた内容であり、所属する会社の公式見解ではありません。また、いかなる保証を与えるものでもありません。正式な情報は、各製品の販売元にご確認ください。