Azure Policy を活用したリソース構成ガバナンスの実践

Tech

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

Azure Policy を活用したリソース構成ガバナンスの実践

クラウド環境におけるリソースのガバナンスは、セキュリティ、コンプライアンス、コスト最適化を実現するために不可欠です。本記事では、Azure Policy を活用して Azure リソースの構成ガバナンスを効果的に実践する方法について、アーキテクチャ、設定手順、運用監視、セキュリティ、コスト最適化、そして一般的な落とし穴までを詳細に解説します。

アーキテクチャ

Azure Policy は、Azure 環境全体で組織の標準を適用し、コンプライアンスを評価するためのガバナンスサービスです。リソースが特定の構成要件に準拠しているかどうかを監査し、場合によっては自動的に修正したり、非準拠のリソース作成を拒否したりできます。

Azure Policy の主要な構成要素は以下の通りです [1, 2]:

  • ポリシー定義: 適用するルールと効果（例: 監査、拒否、変更、デプロイIfNotExists）を記述した JSON ドキュメントです。

  • イニシアティブ定義: 関連する複数のポリシー定義をグループ化したものです。Azure Security Benchmark (ASB) などの業界標準や規制要件に合わせた多数の組み込みイニシアティブが存在します。

  • ポリシー割り当て: ポリシー定義またはイニシアティブ定義を特定のスコープ（管理グループ、サブスクリプション、リソースグループ）に適用するものです。割り当て時にパラメーターを指定できます。

これらの要素が連携し、以下のフローでリソースのライフサイクル全体にわたるガバナンスを確立します。

flowchart TD
    A["開発者/運用者"] --> |リソース作成/更新要求| B("Azure Resource Manager")
    B --> |評価要求| C["Azure Policy エンジン"]
    C --> D{"ポリシー定義と割り当て"}
    D -- 拒否 (Deny) --> E["リソース作成/更新失敗"]
    D -- 監査 (Audit) --> F["コンプライアンス非準拠"]
    D -- 修正/作成 (DeployIfNotExists/Modify) --> G["自動修正/作成"]
    D -- 準拠 (Compliant) --> H["リソース作成/更新成功"]

    C --> |評価結果| I["Azure Activity Log / Azure Monitor"]
    F --> J["監視ツール/アラート"]
    G --> K["準拠リソース"]
    H --> L["準拠リソース"]

    subgraph Policy評価フロー
        B -- 評価要求 --> C
        C --> D
        D -- 効果適用 --> E
        D -- 効果適用 --> F
        D -- 効果適用 --> G
        D -- 効果適用 --> H
    end

Azure Policy エンジンは、リソースが作成または更新される際にそのリクエストを傍受し、割り当てられたポリシー定義に照らして評価します。ポリシーの効果に基づいて、リソースの作成を拒否したり、非準拠としてフラグ付けしたり、自動的に構成を修正したりします [2]。

設定手順

ここでは、Azure CLI を使用して、特定のストレージアカウント SKU のみ許可するカスタムポリシーを定義し、割り当てる手順を解説します。

1. カスタムポリシー定義の作成

まず、許可するストレージアカウントの SKU (例: Standard_LRS, Premium_LRS) を指定するカスタムポリシー定義 JSON ファイル (allowed-storage-skus.json) を作成します。

{
  "properties": {
    "displayName": "Allowed Storage Account SKUs",
    "description": "This policy ensures that only specified storage account SKUs are allowed.",
    "mode": "All",
    "parameters": {
      "listOfAllowedSKUs": {
        "type": "Array",
        "metadata": {
          "displayName": "Allowed SKUs",
          "description": "The list of storage account SKUs that can be created."
        }
      }
    },
    "policyRule": {
      "if": {
        "allOf": [
          {
            "field": "type",
            "equals": "Microsoft.Storage/storageAccounts"
          },
          {
            "not": {
            "field": "Microsoft.Storage/storageAccounts/sku.name",
            "in": "[parameters('listOfAllowedSKUs')]"
            }
          }
        ]
      },
      "then": {
        "effect": "Deny"
      }
    }
  }
}

2. ポリシー定義の発行

作成した JSON ファイルを使用して、Azure にカスタムポリシー定義を発行します。

# ポリシー定義の発行


# 前提: Azure CLI がインストールされ、Azure にログイン済みであること


# `your-subscription-id` を実際のサブスクリプションIDに置き換えてください。


# このポリシーは2024年7月29日に定義されます。

az policy definition create \
  --name "Allowed-Storage-SKUs" \
  --display-name "Allowed Storage Account SKUs (Custom)" \
  --description "Allows only specified storage account SKUs." \
  --rules "allowed-storage-skus.json" \
  --subscription "your-subscription-id"

3. ポリシー割り当ての実施

次に、このポリシー定義を特定のスコープ（例: 特定のサブスクリプション）に割り当てます。この例では、Standard_LRS と Premium_LRS の SKU のみを許可します。

# ポリシー割り当ての実施


# ポリシー定義のIDは、発行時に自動生成されるか、az policy definition show で確認できます。


# この割り当ては2024年7月29日に有効になります。

POLICY_DEFINITION_ID=$(az policy definition show \
  --name "Allowed-Storage-SKUs" \
  --subscription "your-subscription-id" \
  --query id \
  --output tsv)

ASSIGNMENT_NAME="restrict-storage-skus-assignment"
SCOPE="/subscriptions/your-subscription-id" # スコープを管理グループ、リソースグループに変更可能

az policy assignment create \
  --name $ASSIGNMENT_NAME \
  --scope $SCOPE \
  --policy $POLICY_DEFINITION_ID \
  --display-name "Restrict Storage Account SKUs" \
  --description "Allows only Standard_LRS and Premium_LRS storage accounts." \
  --params '{ "listOfAllowedSKUs": { "value": ["Standard_LRS", "Premium_LRS"] } }'

マネージドIDと権限付与

deployIfNotExists または modify 効果を持つポリシーを使用する場合、Azure Policy はリソースを作成または変更するためのアクセス許可を必要とします [5]。このために、ポリシー割り当て時にマネージド ID (システム割り当てまたはユーザー割り当て) を作成し、必要な RBAC ロール (例: 仮想ネットワーク共同作成者、Contributor など) を付与する必要があります。

# deployIfNotExists ポリシー割り当ての例（マネージドID使用）


# この例は一般的な形式であり、具体的なポリシー定義と権限により変動します。

az policy assignment create \
  --name "auto-tag-resources-assignment" \
  --scope "/subscriptions/your-subscription-id" \
  --policy "/providers/Microsoft.Authorization/policyDefinitions/add-tag-to-resources" \
  --location "eastus" \
  --identity-type SystemAssigned \
  --role "Contributor" # ポリシーがリソースを変更するために必要なロール

運用監視

Azure Policy の効果的な運用には、継続的なコンプライアンス監視が不可欠です。

コンプライアンス状態の確認

Azure Portal、Azure CLI、または Azure Resource Graph を使用して、ポリシーのコンプライアンス状態を確認できます [6]。

# サブスクリプション全体のコンプライアンス状態を確認


# 2024年7月29日時点の評価結果を取得します。

az policy state list \
  --subscription "your-subscription-id" \
  --expand PolicyAssignment \
  --query "[].{Resource:resourceId, ComplianceState:complianceState, PolicyAssignment:policyAssignmentId, PolicyDefinition:policyDefinitionName}"

# 特定のリソースグループ内の特定のポリシー割り当てに違反しているリソースを確認

az policy state list \
  --resource-group "your-resource-group" \
  --policy-assignment "restrict-storage-skus-assignment" \
  --query "[].{Resource:resourceId, ComplianceState:complianceState}"

Azure Monitor と Log Analytics による監視

Azure Policy の評価イベントは Azure Activity Log に記録されます。これを Log Analytics Workspace に送信し、Azure Monitor を使用してカスタムクエリやアラートを設定することで、リアルタイムに近い形でポリシー違反を検知し、対応を自動化できます [7]。 例えば、deny 効果がトリガーされた際にアラートを生成し、運用チームに通知する、といった運用が可能です。

セキュリティ

Azure Policy は、セキュリティ態勢を強化するための重要なツールです。

  • Azure Security Benchmark (ASB) との連携: ASB は、Microsoft が推奨するセキュリティとコンプライアンスのベストプラクティスをまとめたものです。Azure Policy は、ASB のコントロールを実装するための組み込みイニシアティブを提供しており、これらを割り当てることで、クラウド環境のセキュリティベースラインを容易に確立できます。

  • アイデンティティと権限境界:

    • Azure RBAC: Azure Policy の管理自体にも RBAC が適用されます。ポリシー定義の作成には「ポリシー共同作成者」、割り当てには「リソースポリシー共同作成者」または「所有者」ロールが必要です [4]。これにより、ポリシーガバナンスの権限が適切に分離され、不正なポリシー変更を防ぎます。

    • Entra ID (旧 Azure Active Directory): ポリシーの割り当てを行うユーザーや、マネージド ID が Azure AD を介して認証・認可されます。deployIfNotExists や modify ポリシーがリソースに変更を加える場合、そのマネージド ID には Azure AD を通じた最小特権の原則に基づく適切な RBAC ロールが付与されている必要があります [5]。

    • 条件付きアクセス (CA): Azure Policy はリソース構成ガバナンス、CA はアクセスガバナンスという異なる役割を持ちますが、セキュリティ戦略全体の中で相互補完的です。Policyでリソースのセキュリティ設定（例: SSH公開ポート制限）を強制し、CAでそのリソースへのアクセス条件（例: 特定デバイスからのアクセスのみ許可）を制御することで、多層防御が実現されます。

コスト最適化

Azure Policy は、クラウドコストの最適化においても強力なツールとなります [8]。

  • SKU の制限: 特定の高性能または高価な SKU (例: VM の高コストなシリーズ、高IOPSストレージ) の使用を禁止または監査するポリシーを設定し、コスト超過を防ぎます。

  • タグ付けの強制: 課金部門、プロジェクト、環境などのタグ付けを強制するポリシーを導入することで、リソースの所有者や目的を明確にし、コストの可視性を高め、不要なリソースの特定を容易にします。

  • リージョン制限: データ主権やコストの理由から、特定のアジュールリージョンへのリソースデプロイを許可しないポリシーを設定します。

  • リザーブドインスタンスの利用促進: リザーブドインスタンスが利用可能なリソースタイプについて、デプロイ時にリザーブドインスタンス利用を検証するポリシーを導入することで、コスト削減を促進します。

落とし穴

Azure Policy を効果的に運用するためには、以下の一般的な落とし穴に注意が必要です [9]。

  • スコープの誤設定: ポリシー割り当てのスコープを過度に広げすぎると意図しない影響を与える可能性があり、狭すぎるとガバナンスが不十分になる可能性があります。管理グループ、サブスクリプション、リソースグループの階層を理解し、適切なスコープを選択することが重要です。

  • 除外の乱用: 特定のリソースやリソースグループをポリシーから除外することは可能ですが、乱用するとガバナンスの穴となる可能性があります。明確な理由と承認プロセスに基づいて、最小限に留めるべきです。

  • ポリシーの競合: 複数のポリシーが同じリソースに適用され、異なる効果（例: 一方は許可、他方は拒否）を持つ場合、競合が発生する可能性があります。Deny 効果は常に優先されます。ポリシー設計時にイニシアティブによるグループ化や、適切な評価順序を考慮する必要があります。

  • 効果の理解不足: Audit, Deny, DeployIfNotExists, Modify, Disable など、各効果の動作を正確に理解しておくことが重要です。特に DeployIfNotExists や Modify は、マネージド ID に付与された権限に基づいてリソースに変更を加えるため、注意深いテストが必要です。

  • コンプライアンス評価の遅延: ポリシー評価は、リソース作成/更新時だけでなく、定期的なスキャン（通常24時間ごと）でも行われます。リアルタイムの評価ではないことを認識し、緊急性の高いコンプライアンス要件には Deny 効果を積極的に使用することを検討してください。

まとめ

Azure Policy は、Azure 環境におけるリソース構成ガバナンスを確立するための強力かつ柔軟なサービスです。アーキテクチャの理解、計画的なポリシー定義と割り当て、継続的な監視、適切なセキュリティ対策、そしてコスト最適化の活用を通じて、組織はクラウド環境の統制を強化し、セキュリティ、コンプライアンス、運用効率、そしてコストパフォーマンスを向上させることができます。2024年7月29日現在、Azure Policyは引き続き進化しており、その機能と適用範囲は拡大し続けています。本記事で解説した内容を参考に、ご自身のAzure環境に最適なガバナンス戦略を構築してください。

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました