Azure Policy

Azure Policyは、Azure リソースの構成を制御または監査するルール（ポリシー定義と呼ばれます）を定義、割り当て、管理できるガバナンス サービスです。操作を実行できるユーザーを制御する RBAC とは異なり、Azure Policy はリソースの最終的な構成として何が許可されるかを制御します。命名規則、承認済みのリソースの種類、必須のセキュリティ構成など、組織の標準を適用するために使用します。

ポリシー定義は、リソースに対して評価する条件と、その条件を満たしたときに適用する効果を定義した JSON ドキュメントです。Azure には、一般的なシナリオに対応する組み込みポリシー定義が数百種類用意されています。組み込みポリシーが要件に合わない場合は、カスタム ポリシー定義を作成することもできます。ポリシー定義は再利用可能なオブジェクトであり、効果を発揮する前にスコープへ割り当てる必要があります。

ポリシー定義の効果によって、ポリシーの条件がトリガーされたときの動作が決まります。主な効果は次のとおりです。Deny — ポリシーに違反するリソースの作成または更新をブロックします。Audit — 操作を許可しますが、コンプライアンス レポートに警告を記録します。Append — 作成前に、タグなどの必須フィールドをリソースへ追加します。Modify — 既存または新規のリソースのプロパティを変更します。DeployIfNotExists — 条件を満たしていない場合に、関連するリソースをデプロイします（例：すべての VM に診断拡張機能をデプロイする）。

ポリシーの割り当ては、管理グループ、サブスクリプション、リソース グループなど、特定のスコープにポリシー定義を適用します。そのスコープと子スコープ内のすべてのリソースが、割り当てられたポリシーに基づいて評価されます。割り当てにはパラメーターを含めることができます。たとえば、許可する Azure リージョンを制限するポリシーをパラメーター化し、同じ定義を異なるリージョン一覧で各管理グループに割り当てられます。

イニシアティブ定義（ポリシー セットとも呼ばれます）は、関連する複数のポリシー定義を、1 つの割り当て可能なパッケージにまとめたものです。20 個のポリシーを個別に割り当てる代わりに、1 つのイニシアティブを割り当てます。Azure には、ISO 27001、NIST SP 800-53、Azure Security Benchmark、PCI DSS などのコンプライアンス フレームワーク向けに、組み込みのイニシアティブが用意されています。たとえば、CIS Microsoft Azure Foundations Benchmark イニシアティブを割り当てると、180 を超えるセキュリティ コントロールに対してサブスクリプションを同時に評価できます。

ポリシーを割り当てると、Azure はスコープ内に既に存在するすべてのリソースを評価し、コンプライアンス レポートを生成します。レポートには、全体のコンプライアンス率（準拠リソース数 / リソース総数）、各リソースのコンプライアンス状態、失敗した具体的なポリシー条件が表示されます。ポリシー イニシアティブ、スコープ、リソースの種類でフィルターできます。非準拠のリソースには違反したポリシー ルールが正確に示されるため、修復の指針になります。

DeployIfNotExists または Modify の効果を持つポリシーでは、Azure に修復タスクを作成させ、既存の非準拠リソースを準拠状態にできます。たとえば、すべての VM に Log Analytics エージェントをデプロイする DeployIfNotExists ポリシーでは、現在エージェントがない既存のすべての VM にエージェントをインストールする修復タスクを実行できます。新しいリソースは作成時に自動的に修復されますが、既存のリソースには明示的な修復タスクが必要です。

特定のリソースをポリシーの対象外にする正当な理由がある場合があります。たとえば、変更できないレガシー リソースや、変更要求に記録された承認済みの例外などです。ポリシーの除外を使用すると、ポリシーをグローバルに削除せずに、特定のリソースまたはリソース グループをポリシーの割り当てから除外できます。除外には、有効期限と、例外の理由を記録するカテゴリ（Waiver または Mitigated）を任意で設定できます。

DeployIfNotExistsは、最も強力なポリシー効果の 1 つです。必要な関連リソースを持たずにリソースが作成されると（例：診断拡張機能のない VM）、ポリシーによって ARM テンプレートのデプロイが自動的にトリガーされ、不足しているコンポーネントが追加されます。これにより Azure Policy を自動構成管理ツールとして利用できます。すべての VM に常に監視エージェントを配置し、すべてのストレージ アカウントで常に高度な脅威対策を有効にし、すべての SQL Database で常に監査を有効にするといった構成を実現できます。

組織は、さまざまなガバナンス シナリオで Azure Policy を使用します。場所の制限 — データ主権の要件により、承認済みの Azure リージョンにのみリソースを配置できるようにします。許可するリソースの種類 — 高額または未承認のサービスのデプロイを防ぎます。タグの適用 — すべてのリソースに CostCentre タグと Environment タグを必須にします。SKU の制限 — 非本番サブスクリプションで、VM サイズをコストに適したティアに制限します。セキュリティ ベースライン — TLS 1.2 以上を適用し、ストレージ アカウントのパブリック ネットワーク アクセスを無効にして、プライベート エンドポイントを必須にします。

RBAC と Azure Policy の役割の違いを理解することが重要です。RBACは、操作を実行できるユーザーを制御します。ID に基づいてアクションを許可または拒否します。Azure Policyは、リソース構成がどのような状態であるべきかを制御します。誰が操作を実行したかに関係なく、プロパティを評価して適用します。適切にガバナンスされた環境では、両方が必要です。RBAC によって承認されたユーザーだけがリソースをデプロイできるようにし、Azure Policy によってそれらのリソースが構成標準に準拠するようにします。

このレッスンで扱った Microsoft Azure Fundamentals (AZ-900) の概念について、理解度を確認しましょう。

このレッスンでは、Azure Policy によって、任意のスコープでリソース構成を制御する条件と効果を定義できること、イニシアティブ定義によって複数のポリシーを、割り当て可能な 1 つのコンプライアンス パッケージにまとめられること、そしてDeployIfNotExists によって、不足しているコンポーネントの自動構成を大規模に適用できることを学びました。次は、Azure リソースを保護するためのリソース タグとリソース ロックについて説明します。