本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
Azure Policyカスタム定義とコンプライアンス
Azure Policyは、Azureリソースが組織の標準、規制要件、およびSLAに準拠していることを保証するための強力なガバナンスツールです。組み込みポリシーに加えて、カスタムポリシーを定義することで、特定のビジネスニーズに合わせた柔軟なコンプライアンス管理を実現できます。本記事では、Azure Policyのカスタム定義に焦点を当て、そのアーキテクチャから設定、運用監視、セキュリティ、コスト最適化、そして一般的な落とし穴までをクラウドアーキテクトの視点から解説します。
アーキテクチャ
Azure Policyは、Azureの管理階層（管理グループ、サブスクリプション、リソースグループ、リソース）にわたって適用され、リソースの作成・更新時、または定期的な評価サイクルでリソースの構成を監査・強制します。
カスタムポリシー定義は、以下のようなライフサイクルを経てコンプライアンスを評価し、必要に応じて是正措置を講じます。
graph TD
A["ポリシー定義の作成"] --> B("JSON定義: ルール, 効果, パラメータ");
B --> C{"カスタムポリシー定義"};
C --> D["イニシアティブ定義への追加"];
D --> E["ポリシー割り当ての作成"];
E -->|"スコープ指定"| F("管理グループ / サブスクリプション / リソースグループ")
E -->|"パラメータ値設定"| G("割り当てパラメータ")
E --> H["ポリシー割り当て"];
H --> I{"リソースの作成・更新"};
I -->|"評価"| J["Azure Policyエンジン"]
J -->|"準拠?"| K{"はい"}
J -->|"非準拠?"| L{"いいえ"}
K --> M["リソースは許可/作成"];
L --> N["効果の適用"];
N -->|"Audit"| O["コンプライアンスレポートに記録"]
N -->|"Deny"| P["リソース作成/更新を拒否"]
N -->|"DeployIfNotExists"| Q["修復タスクで自動デプロイ"]
N -->|"Modify"| R["修復タスクで自動変更"]
O --> S["コンプライアンスダッシュボード"];
P --> S;
Q --> S;
R --> S;[1]
主要コンポーネント:
ポリシー定義 (Policy Definition): リソースが評価される条件と、その条件が満たされた場合に適用される効果（Audit, Deny, DeployIfNotExists, Modifyなど）を記述したJSONドキュメントです。
イニシアティブ定義 (Initiative Definition): 複数のポリシー定義（組み込みおよびカスタム）をグループ化するもので、共通の目的（例: PCI DSSコンプライアンス）を持つポリシーセットを一括で割り当てることができます。
ポリシー割り当て (Policy Assignment): ポリシー定義またはイニシアティブ定義を特定のスコープ（管理グループ、サブスクリプション、リソースグループ）に適用する行為です。パラメータを定義することで、割り当てごとに異なる振る舞いをさせることができます。
設定手順
ここでは、特定のVM SKUの使用を禁止するカスタムポリシー定義を作成し、割り当てる手順をAzure CLIで示します。
1. カスタムポリシー定義の作成
AllowedVmSku.jsonというファイルにポリシー定義を記述します。この例では、Standard_B1ls SKUの使用を禁止します。
{
"properties": {
"displayName": "Allowed VM SKU",
"description": "このポリシーは、指定されたVM SKU以外の仮想マシンのデプロイを禁止します。",
"mode": "Indexed",
"parameters": {
"listOfAllowedSKUs": {
"type": "Array",
"metadata": {
"displayName": "許可されるVM SKUのリスト",
"description": "このポリシーによって許可されるVM SKUのリストです。"
}
}
},
"policyRule": {
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Compute/virtualMachines"
},
{
"not": {
"field": "Microsoft.Compute/virtualMachines/sku.name",
"in": "[parameters('listOfAllowedSKUs')]"
}
}
]
},
"then": {
"effect": "Deny"
}
}
}
}
このポリシー定義をAzureに登録します。
# ポリシー定義ファイルをAzureにアップロード
# --name: ポリシー定義の一意の識別子
# --display-name: Azure Portalで表示される名前
# --description: ポリシーの説明
# --rules: ポリシー定義のJSONファイルパス
# --mode: ポリシーを評価するリソースの種類 ('Indexed'または'All')
az policy definition create \
--name "AllowedVmSkuPolicy" \
--display-name "許可されたVM SKUのみを使用" \
--description "組織で許可されていないVM SKUのデプロイを禁止するポリシーです。" \
--rules "AllowedVmSku.json" \
--mode All
[2]
2. ポリシーの割り当て
定義したポリシーを特定のサブスクリプションまたはリソースグループに割り当てます。ここでは、your-subscription-id を対象とし、Standard_B1ls 以外のSKUを許可します。
# ポリシー割り当て
# --name: 割り当ての一意の識別子
# --display-name: Azure Portalで表示される名前
# --policy: 割り当てるポリシー定義の名前またはID
# --scope: ポリシーを適用するスコープ (例: /subscriptions/{subscriptionId} または /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName})
# --params: ポリシー定義で定義されたパラメータに渡すJSON形式の値
az policy assignment create \
--name "AllowedVmSkuAssignment" \
--display-name "VM SKU許可リスト (Deny B1ls)" \
--policy "AllowedVmSkuPolicy" \
--scope "/subscriptions/your-subscription-id" \
--params '{ "listOfAllowedSKUs": { "value": ["Standard_D2s_v3", "Standard_E4s_v3"] } }'
[3]
注: 上記の例ではStandard_B1lsを禁止するものでしたが、listOfAllowedSKUsパラメーターで許可するSKUを明示的に指定することで、それ以外のすべてのSKUを禁止できます。
3. 修復タスクの実行 (DeployIfNotExists / Modify効果の場合)
DeployIfNotExistsやModify効果を持つポリシーの場合、既存の非準拠リソースをポリシーに準拠させるために修復タスクが必要です。修復タスクにはマネージドIDが必要で、そのIDには対象リソースに対する適切な権限（例: Contributorロール）が必要です。
# 修復タスクの作成 # --name: 修復タスクの名前 # --policy-assignment: 修復するポリシー割り当ての名前またはID # --location: マネージドIDを作成する場所 (割り当てと同じリージョンが推奨) # 修復タスクが正常に実行されるためには、割り当てに紐付けられたマネージドIDに適切な権限が付与されている必要があります。 az policy remediation create \ --name "VMTagRemediation" \ --policy-assignment "TaggingPolicyAssignment" \ --location "eastus"
[4]
運用監視
Azure Policyの運用監視は、リソースのコンプライアンス状態を把握し、問題を迅速に特定するために不可欠です。
Azure Portal コンプライアンスダッシュボード: Azure Portalの「Policy」サービスで、割り当てられたポリシーの全体的なコンプライアンス状態を一目で確認できます。非準拠リソース、非準拠の理由、適用された効果などがグラフィカルに表示されます。
Azure Monitor Logs (Log Analytics): ポリシー評価のログをLog Analyticsワークスペースに送信し、詳細な分析を行うことができます。Kusto Query Language (KQL) を使用して、特定の期間の非準拠イベントを検索したり、トレンドを分析したりできます。
# Log Analyticsでのポリシー評価ログのクエリ例 (JST: 2024年5月15日) # PolicyEventsテーブルから過去24時間のDenyイベントを検索 PolicyEvents | where TimeGenerated > ago(24h) | where PolicyAssignmentId contains "AllowedVmSkuAssignment" // 上記で割り当てたポリシーのIDに置換 | where IsCompliant == false | project TimeGenerated, ResourceId, PolicyDefinitionName, PolicyAssignmentName, PolicyAssignmentScope, AdditionalData | sort by TimeGenerated desc
Azure Monitor アラート: 特定のポリシーが非準拠になった場合や、非準拠リソースの数が増加した場合にアラートを設定できます。これにより、自動的に関係者に通知し、対応を促すことが可能です。
セキュリティ
Azure Policyは、Azure環境のセキュリティ体制を強化する上で重要な役割を果たします。
アイデンティティと権限境界 (Azure RBAC):
ポリシー定義の作成/編集: 「Policy Contributor」ロールが必要です。
ポリシーの割り当て: 「Resource Policy Contributor」ロールが必要です。このロールは、管理グループ、サブスクリプション、リソースグループレベルで割り当てられます。
コンプライアンスデータの読み取り: 「Policy Insights Data Reader」ロールが必要です。
修復タスクのマネージドID:
DeployIfNotExistsやModify効果を持つポリシーの修復タスクを実行する場合、ポリシー割り当てに設定されたマネージドIDが、対象リソースに対して必要な操作を実行するための適切なRBACロール（例: Contributor、Network Contributorなど）を持っている必要があります。これは最小特権の原則に従って慎重に割り当てるべきです。
Azure Defender for Cloud との統合: Azure Policyは、Azure Defender for Cloudのセキュリティ推奨事項を適用するために使用されます。例えば、特定のセキュリティ設定（ディスク暗号化、NSGルールなど）がすべてのリソースに適用されていることをポリシーで強制できます。
条件付きアクセス (Conditional Access): Azure Policy自体が条件付きアクセスと直接統合されるわけではありませんが、ポリシーによってAzureリソースへのアクセスを制御し、条件付きアクセスと組み合わせて、データプレーンレベルとコントロールプレーンレベルの両方でセキュリティを強化することができます。
コスト
Azure Policyサービス自体は無料です。しかし、ポリシーの適用によって間接的にコストに影響を与える可能性があります。
コスト最適化への貢献:
高価なSKUの制限: 「Deny」効果を持つポリシーを使用して、高価なVM SKUやストレージタイプなどのデプロイを禁止し、コスト超過を防ぐことができます。
リソースタグ付けの強制: 「Audit」「Append」「Modify」効果のポリシーにより、すべてのリソースにコストセンターやプロジェクトなどのタグ付けを義務付け、コスト配分とチャージバックを容易にし、コスト可視性を向上させます。
未使用リソースの防止: 特定の期間使用されていないリソースを監査し、削除を促すポリシー（直接削除ではなく、警告や特定タグの追加など）を設定することで、リソースの浪費を防ぎます。
ポリシーによるコスト発生: 「DeployIfNotExists」効果のポリシーで新しいリソース（例: Log Analyticsワークスペース、Diagnostics設定）がデプロイされた場合、そのリソースに対して通常のAzure料金が発生します。
落とし穴
Azure Policyを効果的に使用するためには、以下の一般的な落とし穴を認識し、回避することが重要です。
「拒否 (Deny)」効果の乱用:
Deny効果を広範囲のスコープで適用すると、予期せぬサービスの中断や開発作業のブロックを引き起こす可能性があります。最初はAudit効果で影響を確認し、段階的にDenyへ移行することを推奨します。スコープの不適切さ: ポリシーの割り当てスコープが広すぎると、影響が大きくなりすぎ、狭すぎるとコンプライアンスの穴が生じます。管理グループ階層を考慮し、適切なスコープで割り当てを行うことが重要です。
テスト不足: カスタムポリシーを本番環境にデプロイする前に、開発/テスト環境で徹底的にテストし、意図しない副作用がないことを確認する必要があります。
Audit効果での事前検証が特に有効です。DeployIfNotExistsにおけるマネージドIDの権限不足: 修復タスクを実行するマネージドIDに、必要な操作を実行するためのRBAC権限が付与されていない場合、修復は失敗します。必要な権限を最小限の範囲で付与し、動作を確認することが重要です。複雑すぎるポリシー定義: あまりにも複雑なポリシー定義は、理解が困難になり、メンテナンスが難しくなります。可能であれば、複数のシンプルなポリシーに分割し、イニシアティブでまとめることを検討してください。
まとめ
Azure Policyのカスタム定義は、Azure環境のガバナンスとコンプライアンスを強化するための強力なツールです。正確なアーキテクチャの理解、計画的な設定、継続的な運用監視、そしてセキュリティとコストへの配慮を通じて、組織固有の要件を満たす効果的なコンプライアンス体制を構築できます。特に、「拒否 (Deny)」効果の使用には慎重なテストと段階的な適用が不可欠であり、修復タスクにおけるマネージドIDの権限管理も重要な考慮事項です。これらのベストプラクティスに従うことで、Azure環境の信頼性とセキュリティを向上させることができます。
参照情報:
Azure Policy とは – Azure Policy | Microsoft Learn (更新日: 2024年4月25日, Microsoft)
Azure Policy の定義の構造 – Azure Policy | Microsoft Learn (更新日: 2024年4月11日, Microsoft)
Azure CLI を使用してポリシーを割り当てる – Azure Policy | Microsoft Learn (更新日: 2024年4月11日, Microsoft)
Azure Policy で非準拠リソースを修復する方法 – Azure Policy | Microsoft Learn (更新日: 2024年4月25日, Microsoft)
