Azure Policyによるガバナンスとコンプライアンス

Microsoft 365・Azureカテゴリを表すパンダのイラスト Microsoft 365・Azure
2026.01.11

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

Azure Policyによるガバナンスとコンプライアンス

クラウド環境の利用が拡大するにつれて、セキュリティ、コスト、運用の一貫性を確保するためのガバナンスとコンプライアンスの重要性が増しています。Microsoft Azureでは、Azure Policyがこの課題に対応するための中核的なサービスとして機能します。本記事では、Azure Policyを用いた効果的なガバナンスとコンプライアンスの実現方法について、アーキテクチャ、設定、運用、セキュリティ、コスト最適化の観点から解説します。

アーキテクチャ概要

Azure Policyは、Azure環境内のリソースが組織の定める基準や法規制に準拠していることを評価および強制するサービスです[1]。これは、主に以下の3つのコンポーネントで構成されます。

  1. ポリシー定義 (Policy Definition): 評価される条件と、その条件が満たされた場合に実行される効果（例: 拒否、監査、変更、デプロイIfNotExists）を記述したJSONドキュメントです。組み込みポリシーとカスタムポリシーがあります。

  2. イニシアティブ定義 (Initiative Definition): 複数のポリシー定義をまとめたセットです。これにより、共通の目的（例: PCI DSSコンプライアンス）を持つポリシー群を一括で管理・割り当てできます。

  3. ポリシー割り当て (Policy Assignment): ポリシー定義またはイニシアティブ定義を特定のスコープ（管理グループ、サブスクリプション、リソースグループ）に適用する行為です。割り当て時に除外するリソースを指定することも可能です。

Azure Policyは、リソースの作成・更新時、および既存リソースの定期的なコンプライアンススキャン（通常24時間ごと）によって評価されます[1]。2024年07月23日には、Guest Configurationにおける自動修復サポートが一般提供開始され、Azure VM内部のOSやアプリケーション構成のコンプライアンス自動修正が可能になりました[2]。

以下に、Azure Policyによるガバナンスのワークフローを示します。

flowchart TD
    A["管理者/CI/CDパイプライン"] --|リソースデプロイ/更新要求|--> B("Azure Resource Manager");
    B --|リソースプロバイダーへ転送|--> C{"Azure Policyエンジン"};
    C --|ポリシー定義とスコープを評価|--> D["ポリシー定義"];
    C --|割り当てられたポリシーを参照|--> E["ポリシー割り当て"];
    D --|条件に一致し|--> C;
    E --|スコープ内で適用|--> C;
    C --|効果を決定|--> F{"ポリシー効果"};
    F --|Denyの場合|--> G["デプロイ拒否"];
    F --|Auditの場合|--> H["非準拠としてログ記録"];
    F --|DeployIfNotExists/Modifyの場合|--> I["準拠リソースを自動デプロイ/修正"];
    I --> J["準拠リソース"];
    H --> K["非準拠リソース"];
    K --|手動修復または|--> L["修復タスク"];
    L --> J;
    J --> M["継続的なコンプライアンス評価"];
    M --|非準拠検出|--> K;

    subgraph "Azure Policyの構成要素"
        D
        E
    end
    subgraph "ガバナンスフロー"
        A --> B --> C --> F
        F --> G
        F --> H
        F --> I
        I --> J
        H --> K
        K --> L
        L --> J
        J --> M
        M --> K
    end

設定手順

ここでは、特定のAzure VM SKUのデプロイを禁止するポリシーをAzure CLIを用いて設定する手順を示します。

  1. ポリシー定義の作成: まず、許可しないVM SKUを指定するポリシー定義を作成します。ここでは、Standard_B1ls のVMを禁止する例です。

    # policyDefinition.json

{
  "if": {
    "allOf": [
      {
        "field": "type",
        "equals": "Microsoft.Compute/virtualMachines"
      },
      {
        "field": "Microsoft.Compute/virtualMachines/sku.name",
        "equals": "Standard_B1ls"
      }
    ]
  },
  "then": {
    "effect": "Deny"
  }
}

    このJSONファイルを policyDefinition.json として保存し、以下のコマンドでポリシー定義を作成します。

    az policy definition create \
  --name "deny-b1ls-vm-sku" \
  --display-name "Standard_B1ls VM SKUのデプロイ禁止" \
  --description "コスト最適化のため、Standard_B1lsの仮想マシンのデプロイを禁止します。" \
  --rules "policyDefinition.json" \
  --mode All

    • --name: ポリシー定義の一意な名前。

    • --display-name: Azure Portalで表示される名前。

    • --description: ポリシーの説明。

    • --rules: ポリシー定義のJSONファイルパス。

    • --mode: ポリシーが評価するリソースの種類 (All はほとんどのリソースをカバー)。

  2. ポリシーの割り当て: 作成したポリシー定義を特定のスコープ（例: サブスクリプション）に割り当てます。

    # 現在のサブスクリプションIDを取得

SUBSCRIPTION_ID=$(az account show --query id --output tsv)

az policy assignment create \
  --name "deny-b1ls-vm-sku-assignment" \
  --display-name "Standard_B1ls VM SKUのデプロイ禁止（サブスクリプション全体）" \
  --scope "/subscriptions/${SUBSCRIPTION_ID}" \
  --policy "deny-b1ls-vm-sku" \
  --description "サブスクリプション内のすべてのリソースでStandard_B1lsのVMデプロイを禁止します。"

    • --name: ポリシー割り当ての一意な名前。

    • --scope: ポリシーを適用するスコープ（管理グループ、サブスクリプション、リソースグループ）。

    • --policy: 割り当てるポリシー定義の名前またはID。

これで、指定されたサブスクリプション内で Standard_B1ls SKUを持つVMをデプロイしようとすると、Azure Policyによって拒否されます。

運用監視

Azure Policyが正しく機能しているかを監視し、コンプライアンス状況を把握することは運用上不可欠です。

  • Azure Portalでの監視: Azure Portalの「Policy」サービスには、コンプライアンスダッシュボードが用意されており、現在のコンプライアンス状態、非準拠リソース、割り当てられたポリシーごとの準拠率などを一目で確認できます[1]。

  • Azure Monitor Logsとの統合: Azure Policyの評価イベントや修復タスクのログは、Azure Monitor Logsに送信できます。これにより、ログクエリ（KQL）を使用して、特定の非準拠イベントを検出したり、時系列でのコンプライアンストレンドを分析したりすることが可能です。

    # Azure Policyに関するログを検索するKQLの例

AzureActivity
| where OperationNameValue contains "Microsoft.Authorization/policyAssignments" or OperationNameValue contains "Microsoft.Authorization/policyDefinitions"
| where ActivityStatus == "Failure"
| project TimeGenerated, Caller, OperationName, Status, Properties
| sort by TimeGenerated desc

  • Microsoft Defender for Cloudとの連携: Microsoft Defender for Cloudは、Azure Policyと緊密に連携し、Azure Security Benchmark (ASB) などのセキュリティ標準に基づいた推奨事項を生成します[4]。Azure Policyは、これらの推奨事項を強制するメカニズムとして機能し、セキュリティスコアの向上に貢献します。

  • 修復タスクの監視: DeployIfNotExists や Modify 効果を持つポリシーが適用された場合、自動修復が行われます。修復タスクの成功・失敗は、Azure PortalのPolicyサービスから確認できます。失敗した場合は、マネージドIDの権限不足が原因であることが多いため、その権限を確認・修正する必要があります[6]。

セキュリティ

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

  • Microsoft Entra ID (旧 Azure AD) とRBAC: Azure Policyの作成、割り当て、管理には、Microsoft Entra IDによるロールベースのアクセス制御 (RBAC) が不可欠です。ポリシー定義の作成には「ポリシー共同作成者」、割り当てには「リソースポリシー共同作成者」などのロールが必要です[1][3]。これにより、適切な権限を持つユーザーのみがガバナンスルールを変更できるようになります。ポリシー自体も、リソースへのアクセスを制限する効果を持つことがあります。

  • 条件付きアクセス (CA) との役割分担: Azure Policyは主にリソースの構成とデプロイ時のコンプライアンスを強制します。一方、Microsoft Entra IDの条件付きアクセスはユーザーの認証とアクセス時の条件（例: デバイス準拠、場所、多要素認証）を制御します。これらは異なるレイヤーで動作し、相互補完的にセキュリティを強化します。

  • セキュリティベースラインの強制: Azure Policyは、Microsoftが提供するAzure Security Benchmark (ASB) や、CIS Benchmark、NISTなどの業界標準に基づいた組み込みイニシアティブを提供します。これらを割り当てることで、自動的にセキュリティベースラインを組織全体で強制し、設定ミスや脆弱性の発生を未然に防ぎます[4]。例えば、特定のポートがインターネットに公開されていないか、暗号化が強制されているかなどを監査・拒否できます。

コスト

Azure Policyは直接的なコスト削減ツールではありませんが、間接的にコスト最適化に大きく貢献します。

  • リソースSKU/リージョン制限: 前述の例のように、不必要な高価なVM SKUのデプロイを禁止したり、承認された低コストのリージョンへのデプロイのみを許可したりすることで、予期せぬコスト発生を防ぎます。

  • タグ付けの強制: Azure Policyは、すべてのリソースに特定のタグ（例: CostCenter, Project, Owner）の付与を強制できます。これにより、コスト管理部門はタグに基づいてリソースのコストを追跡し、責任の所在を明確にすることで、予算管理と最適化を容易にします[5]。

  • 未使用リソースの検出/削除支援: 直接未使用リソースを削除する機能はないものの、特定の期間以上使用されていないリソースを監査するポリシーを作成し、レポートに基づいて手動または自動修復（DeployIfNotExistsでアラートを生成するなど）で対処することで、コストを削減できます。

  • リザーブドインスタンス/Azure Hybrid Benefitの適用推奨: Azure Policyは、リザーブドインスタンスやAzure Hybrid Benefitの利用を強制する直接的な機能は持ちません。しかし、これらの特典が適用可能なリソースタイプのみを許可したり、タグ付けを通じて利用状況を可視化したりすることで、コスト効率の良いリソース利用を促進する間接的な役割を果たすことができます。

落とし穴と対策

Azure Policyの効果を最大化するためには、よくある落とし穴を理解し、適切に対処する必要があります。

  • 広すぎるスコープでの Deny 効果: 特にテストなしで広範なスコープ（例: 管理グループ全体）に Deny 効果のポリシーを適用すると、既存のワークロードやデプロイパイプラインに予期せぬ影響を与え、業務を停止させる可能性があります。

    • 対策: まず Audit 効果で適用し、非準拠リソースを特定して影響を評価します。その後、段階的に Deny へと切り替えるか、除外ルールを慎重に設定します。

  • 除外の乱用: 非準拠リソースを除外機能で対処しすぎると、ガバナンスの抜け穴となり、全体のコンプライアンスレベルが低下します。

    • 対策: 除外は一時的または例外的な場合に限定し、定期的にレビューして恒久的な解決策を模索します。除外理由を詳細に記録することも重要です。

  • ポリシー定義の複雑化: 1つのポリシー定義に多くの条件やロジックを含めすぎると、可読性やメンテナンス性が低下します。

    • 対策: 可能な限りシンプルで単一責任の原則に基づいたポリシーを作成し、関連するポリシーはイニシアティブにまとめることを推奨します[3]。

  • 修復タスクの権限不足: DeployIfNotExists や Modify 効果のポリシーで自動修復が失敗する場合、多くは修復を実行するマネージドIDに、必要なリソースへの適切なRBAC権限が付与されていないことが原因です[6]。

    • 対策: 修復タスクのマネージドIDに、対象リソースタイプに対する「共同作成者」などの適切なロールを、最小限のスコープで割り当てます。

  • テスト環境での検証不足: 本番環境へのポリシー適用前に、十分なテストが行われないと、予期せぬ問題が発生します。

    • 対策: 開発/テスト環境で新しいポリシーやイニシアティブを十分にテストし、CI/CDパイプラインにポリシーコンプライアンスの検証ステップを組み込むことを検討します。

まとめ

Azure Policyは、クラウド環境のデプロイ、構成、セキュリティ、コスト管理において、組織のガバナンスとコンプライアンスを自動化・強化するための不可欠なツールです。本記事で解説したアーキテクチャ、設定手順、運用監視、セキュリティ連携、コスト最適化の観点を踏まえ、組織の要件に合わせたAzure Policy戦略を策定することで、セキュアで効率的かつコンプライアンスに準拠したクラウド運用を実現できます。特に、2024年07月23日のGuest Configuration自動修復サポートの一般提供開始は、Azure VM内部のコンプライアンス維持に大きな前進をもたらしました[2]。継続的なポリシーのレビューと改善を通じて、変化するビジネス要件と規制環境に対応していくことが重要です。

文書情報

記事タイトル
Azure Policyによるガバナンスとコンプライアンス
作成日
更新日
Source URL
https://papanda925.com/?p=5084

ライセンス: 本記事のうち、当サイトが権利を有する本文・自作図表は、特記なき限り CC BY 4.0 で利用できます。生成AIを活用して作成・編集した内容を含みます。コードについて、別途ライセンス表示またはリンク先GitHubリポジトリのライセンスがある場合は、その条件を優先します。引用・第三者資料・画像・商標等は本ライセンスの対象外です。 利用ポリシー

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