Azure広場基礎から資格まで、Azureの学びをつなぐ記事を読む
← 記事一覧

Azureの基礎と資格

Azure Policyのauditとdenyの違い|権限があっても作成できない理由

Azure Policyは設定したルールへの適合を評価する仕組み。勉強会の資料置き場を例に、auditとdeny、Azure RBACとの違い、既存リソースが自動修復されるとは限らない理由を整理します。

Azure Policyのauditとdenyの違い|権限があっても作成できない理由の記事タイトル画像
この記事の内容

Azure Policyのauditは、ルールに合わない状態を見つけるための効果です。その要求を止めません。denyは、条件に該当する作成・更新要求を拒否する効果です。 「ポリシーがある」と聞いたら、何を調べ、どんな効果を使っているかまで確認します。

架空の勉強会で、資料を置くストレージを準備する場面を考えましょう。担当のあおいさんには、対象のリソースグループで作成する権限があるものとします。それでも、決めた配置ルールに合わなければ、作成が拒否されることがあります。

RBACの許可と、Policyのルールを分ける

Azure RBACは、誰に、どの範囲で、どんな操作を許可するかを管理します。Azure Policyは、リソースの設定などをルールと照らし合わせて評価します。

今回のルールを「学習用の資料置き場は、決めたリージョンに作る」としましょう。あおいさんに作成権限があっても、作ろうとするストレージがそのルールに合わず、denyが適用されれば要求は拒否されます。作成権限があることは、どんな設定でも作成できる保証ではありません。 Azure PolicyとRBACの関係

ロールやスコープの復習には、Azure RBACとMicrosoft Entraロールの違いを使えます。ここでは、設定のルールと権限を分けるところから先に進みます。

同じ「ルールに合わない」でも、auditとdenyで対応が違う

ポリシーの「効果(effect)」は、条件に該当したときに何をするかを表します。次の表は、対象のストレージが決めたリージョンの条件に合わず、ポリシーの効果を適用する設定になっている場合の、説明用の比較です。

比べる場面 auditの場合 denyの場合
新しく作成しようとする この効果では要求を止めず、非準拠として記録する この効果で作成要求を拒否する
すでに存在するものを評価する 非準拠と判定する 非準拠と判定する

「非準拠」は、評価したポリシーのルールに合っていないという意味です。サービスが停止している、データが壊れた、といった状態を表す言葉ではありません。

作成・更新時のauditは、アクティビティログに警告のイベントを残し、リソースを非準拠にします。定期的な評価では、準拠状態を更新します。auditが止めないことと、操作全体が必ず成功することは別です。 ほかのポリシーや権限、サービス側の条件も関係します。auditの公式説明

一方、Resource Managerで管理するリソースの作成・更新では、denyが該当する要求を拒否します。この記事はこの基本的な場面を扱い、削除を含むすべての操作や、ほかのPolicyの効果を同じ動きだとは説明しません。denyの公式説明

決めたリージョンの条件に合わない資料用ストレージを比べる独自図。新規作成ではauditは記録して要求を止めず、denyは作成要求を拒否する。既存リソースの評価ではどちらも非準拠と判定し、それだけで移動や修復はしない
同じ条件をauditとdenyで比べた概念図です。効果を適用する設定を前提にしています。実際の画面や、特定の組み込みポリシーを操作した結果ではありません。

denyを付けても、今あるストレージが移動するわけではない

今度は、資料置き場を作った後にルールが決まったとします。すでに別のリージョンにあるストレージは、評価の結果、非準拠になることがあります。

denyは、その既存ストレージを指定のリージョンへ移したり、削除したりする機能ではありません。 「新しい要求を拒否すること」と「今あるものを直すこと」を分けて読みましょう。既存リソースへの更新要求にはdenyが影響する場合があるので、「作成済みなら、その後の変更は自由」とも言えません。既存リソースとdenyの評価

評価は、作成・更新や割り当ての変更などをきっかけに行われ、定期的な評価もあります。ルールを割り当てた瞬間に、すべての既存リソースの表示が更新されるとは限りません。 判定結果を見るときは、評価のタイミングも区別します。評価が行われるタイミング

Azure Policyには、modifyやdeployIfNotExistsという別の効果と、既存リソースを修復するタスクもあります。ただし、対応する定義や、変更を実行するマネージドIDの権限などが関わります。非準拠という表示が出ただけで、何でも自動修復されるわけではありません。 修復の対象と仕組み

タグとリソースグループの記事で触れた、タグを適用するポリシーも「ルールを評価するだけなのか、変更する仕組みまで用意するのか」を区別して読むと理解しやすくなります。

ポリシーを読むときは、条件・効果・範囲をそろえる

定義はルールの内容、割り当てはそのルールを適用する設定です。定義が用意されているだけで、すべてのリソースに適用されるわけではありません。割り当てのスコープや除外も確認します。定義と割り当て

また、効果を適用せず評価するDoNotEnforceという割り当て設定もあります。denyという名前だけで判断せず、効果を適用する設定かも確かめます。効果の適用設定

勉強会の説明メモなら、次の三行に分けられます。

  • 条件:資料用ストレージのリージョンが、決めた範囲に合っているか
  • 効果:合わない要求をauditで記録するのか、denyで拒否するのか
  • 範囲:学習用リソースグループの、どのリソースが評価対象になるか

これは考え方を読むための例です。組み込みポリシーごとに対象や例外があるため、この三行をそのまま設定手順には使いません。

最後に、「あおいさんには作成権限がある。配置ルールには合っていない。auditが適用されている」という場面を説明してみてください。

答えは、audit自体はその作成要求を止めないです。同じ場面でdenyが適用されれば、該当する作成要求は拒否されます。そして、すでにあるストレージを評価する話なら、非準拠の判定と実際の修復を分けます。この違いが言えれば、「Policyがあるから大丈夫」で止まらず、設定の意味を一段具体的に読めます。

出典を開く

← 記事一覧へ戻る