次の方法で共有

コードとしての Azure Policy ワークフローを設計する

  • [アーティクル]

クラウド ガバナンスの取り組みを進めるにつれて、各ポリシー割り当ての管理を、Azure portal 内あるいはさまざまな SDK を通じて手動で行うことから、エンタープライズ規模でより管理しやすい反復可能なものに移行したくなります。 クラウドで大規模なシステムを管理するには、次の 2 つの方法があります。

  • コードとしてのインフラストラクチャ:環境を定義するコンテンツ (Azure Resource Manager テンプレート (ARM テンプレート) から Azure Policy 定義、Azure Blueprints に至るすべてのもの) をソース コードとして処理する方法。
  • DevOps:エンド ユーザーに価値を継続的に提供できる人材、プロセス、製品の集まりです。

コードとしての Azure Policy は、これらのアイデアを組み合わせたものです。 基本的には、ソース管理でポリシー定義を保持し、変更が行われるたびにその変更をテストして検証します。 ただし、これはコードとしてのインフラストラクチャまたは DevOps に対するポリシー関与の範囲とすべきではありません。

検証ステップは、アプリケーション環境や仮想インフラストラクチャのデプロイなど、他の継続的インテグレーションまたは継続的デプロイ (CI/CD) ワークフローのコンポーネントでもある必要があります。 Azure Policy 検証をビルドおよびデプロイ プロセスの初期コンポーネントとすることにより、アプリケーションと運用チームは、運用環境へのデプロイを試行するよりもずっと前に、変更が期待どおりに動作しているかどうかを遅滞なく見つけることができます。

定義と基本情報

コードとしての Azure Policy ワークフローの詳細に進む前に、ポリシー定義とイニシアティブ定義を作成する方法や、それらの定義の割り当てで除外を利用する方法など、いくつかの基本的な概念を理解しておくことが重要です。

ファイル名は、ポリシーまたはイニシアティブの定義の特定の部分および他のポリシー リソースに対応しています。

ファイル形式 ファイルの内容
policy-v#.json そのバージョンのポリシー定義全体
policyset-v#.json そのバージョンのイニシアチブ定義全体
policy-v#.parameters.json ポリシー定義の properties.parameters の部分
policyset-v#.parameters.json イニシアティブ定義の properties.parameters の部分
policy-v#.rules.json ポリシー定義の properties.policyRule の部分
policyset-v#.definitions.json イニシアティブ定義の properties.policyDefinitions の部分
exemptionName.json 特定のリソースまたはスコープを対象とするポリシーの適用除外

ワークフローの概要

コードとしての Azure Policy の推奨される一般的なワークフローは、次の図のようになります。

作成からテスト、デプロイまでの、コードとしての Azure Policy のワークフロー ボックスを示している図。

ソース管理

既存のポリシーとイニシアティブの定義のエクスポートは、PowerShell、CLI、または Azure Resource Graph (ARG) クエリなどのさまざまな方法で行うことができます。 これらの定義を格納するソース管理環境は、GitHub や Azure DevOps など、多くのオプションの中からいずれかを選択することができます。

ポリシー定義を作成および更新する

ポリシー定義は JSON を使用して作成され、ソース管理に格納されます。 各ポリシーには、パラメーター、規則、環境パラメーターなどの独自のファイル セットがあり、これらは同じフォルダーに格納する必要があります。 次の構造は、ソース管理でポリシー定義を維持するための推奨される方法です。

.
|
|- policies/  ________________________ # Root folder for policy resources
|  |- policy1/  ______________________ # Subfolder for a policy
|     |- versions_____________________ # Subfolder for versions of definition
|       |- policy-v#.json _________________ # Policy definition
|       |- policy-v#.parameters.json ______ # Policy definition of parameters
|       |- policy-v#.rules.json ___________ # Policy rule
|     |- assign.<name1>.json _________ # Assignment 1 for this policy definition
|     |- assign.<name2>.json _________ # Assignment 2 for this policy definition
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
      |- exemptions.<name2>/__________ # Subfolder for exemptions on assignment 2
        | - exemptionName.json________ # Exemption for this particular assignment
|
|  |- policy2/  ______________________ # Subfolder for a policy
|     |- versions_____________________ # Subfolder for versions of definition
|       |- policy-v#.json _________________ # Policy definition
|       |- policy-v#.parameters.json ______ # Policy definition of parameters
|       |- policy-v#.rules.json ___________ # Policy rule
|     |- assign.<name1>.json _________ # Assignment 1 for this policy definition
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
|

新しいポリシーまたは新しいバージョンを追加した場合、または既存のポリシーまたはバージョンを更新した場合は、ワークフローによって Azure のポリシー定義が自動的に更新されます。 新しいポリシー定義または更新されたポリシー定義のテストについては、後の手順で説明します。

イニシアチブ定義を作成および更新する

イニシアティブ定義は、ポリシー定義と同じフォルダーに格納する必要がある JSON ファイルを使用して作成されます。 イニシアティブ定義では、ポリシー定義が既に存在している必要があるため、ポリシーのソースがソース管理で更新されて Azure で更新されるまで、イニシアティブ定義の作成および更新を行うことはできません。 次の構造は、ソース管理でイニシアチブ定義を維持するための推奨される方法です。

.
|
|- initiatives/ ______________________ # Root folder for initiatives
|  |- init1/ _________________________ # Subfolder for an initiative
|     |- versions ____________________ # Subfolder for versions of initiative
|       |- policyset.json ______________ # Initiative definition
|       |- policyset.definitions.json __ # Initiative list of policies
|       |- policyset.parameters.json ___ # Initiative definition of parameters
|     |- assign.<name1>.json _________ # Assignment 1 for this policy initiative
|     |- assign.<name2>.json _________ # Assignment 2 for this policy initiative
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
      |- exemptions.<name2>/__________ # Subfolder for exemptions on assignment 2
        | - exemptionName.json________ # Exemption for this particular assignment
|
|  |- init2/ _________________________ # Subfolder for an initiative
|     |- versions ____________________ # Subfolder for versions of initiative
|       |- policyset.json ______________ # Initiative definition
|       |- policyset.definitions.json __ # Initiative list of policies
|       |- policyset.parameters.json ___ # Initiative definition of parameters
|     |- assign.<name1>.json _________ # Assignment 1 for this policy initiative
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
|

ポリシー定義と同様に、既存のイニシアティブを追加または更新した場合、ワークフローは Azure のイニシアティブ定義を自動的に更新するはずです。 新しいイニシアチブ定義または更新されたイニシアチブ定義のテストについては、後の手順で説明します。

Note

ポリシーのデプロイには、GitHub ワークフローや Azure Pipelines などの一元デプロイ メカニズムの使用をお勧めします。 これにより、確認済みのポリシー リソースだけが環境にデプロイされ、段階的で一元的なデプロイ メカニズムが使われるようになります。 ポリシー リソースに対する "書き込み" アクセス許可は、デプロイに使用されている ID に制限できます。

更新された定義をテストおよび検証する

自動化によって、新たに作成または更新されたポリシーまたはイニシアチブの定義が取得され、Azure 内のオブジェクトが更新された後で、行った変更をテストします。 ポリシーまたはその一部であるイニシアチブは、運用環境から最も遠い環境のリソースに割り当てる必要があります。 通常、この環境は開発環境です。

Note

このステップでは、Azure 環境内のポリシー定義の統合テストを行っています。これは、定義作成プロセスの間に行う必要のあるポリシー定義の機能の検証とは別のものです。

割り当てでは、enforcementMode を disabled にして、リソースの作成と更新がブロックされず、既存のリソースが、更新されたポリシー定義に準拠していることを引き続き監査されるようにする必要があります。 enforcementMode を使用する場合でも、割り当てスコープは、ポリシーの検証用のリソース グループまたはサブスクリプションのいずれかにすることをお勧めします。

Note

強制モードは便利ですが、これはさまざまな条件下でポリシー定義を完全にテストすることの代替手段ではありません。 ポリシー定義は、PUT および PATCH REST API 呼び出し、準拠リソースおよび非準拠リソース、およびリソースに不足しているプロパティなどのエッジ ケースを使用してテストする必要があります。

割り当てがデプロイされたら、Azure Policy SDK、Azure Pipelines のセキュリティとコンプライアンス評価タスク、または Azure Resource Graph (ARG) クエリ (サンプルを参照) を使用して、新しい割り当てのコンプライアンス データを取得します。 ポリシーと割り当てをテストするために使用される環境には、さまざまなコンプライアンスの状態を持つリソースが必要です。 コードの適切な単体テストと同様に、リソースが想定どおりに評価され、偽陽性や偽陰性がないことをテストする必要があります。 期待したもののみにテストおよび検証を行った場合、予期しないまたは未確認の影響をポリシーから受ける可能性があります。 詳細については、「新しい Azure ポリシー定義の影響を評価する」を参照してください。

修復タスクを有効にする

割り当ての検証が期待どおりである場合、次の手順では修復を検証します。 deployIfNotExists または modify を使用するポリシーでは、関連する修復タスクをトリガーして、非準拠状態からリソースを修正し、準拠状態にすることができます。

リソースを修復するための最初の手順は、ポリシー割り当てに、ポリシー定義に定義されたロール割り当てを付与することです。 このロール割り当てによって、ポリシー割り当ての管理対象 ID に、リソースの準拠性を保つために必要な変更を行う十分な権限が与えられます。

ポリシー割り当てに適切な権限が付与されたら、ポリシー SDK を使用して、非準拠であることがわかっている一連のリソースに対して修復タスクをトリガーします。 続行する前に、これらの修復されたタスクに対して以下の 3 つのテストを完了する必要があります。

  • 修復タスクが正常に完了したことを検証します
  • ポリシーの評価を実行して、ポリシーのコンプライアンス結果が期待どおりに更新されていることを確認します
  • リソースに対して環境単体テストを直接実行し、プロパティが変更されたことを検証します

更新されたポリシー評価結果と環境の両方をテストすると、修復タスクによって予期された内容が変更されたこと、およびポリシー定義によってコンプライアンスが想定どおりに変更されたことの確認が直接行われます。

強制割り当てを更新する

すべての検証ゲートが完了したら、enforcementMode を enabled にするように割り当てを更新します。 この変更は、まずは運用環境から遠く離れた同じ環境内で行うことをお勧めします。 リソースの作成とリソースの更新の間に、目的の効果が適用されることを検証します。 その環境が想定どおりに動作することが確認されたら、その次の環境を含むように変更のスコープを設定してゆき、ポリシーが運用リソースにデプロイされるまでこの操作を行う必要があります。

プロセス統合評価

コードとしての Azure Policy の一般的なワークフローでは、ポリシーとイニシアチブを開発して大規模な環境にデプロイします。 しかし、アプリケーションのデプロイや、インフラストラクチャを作成するための ARM テンプレートの実行など、Azure でリソースをデプロイまたは作成するワークフローのデプロイ プロセスには、ポリシーの評価が含まれている必要があります。

このような場合、テスト サブスクリプションまたはリソース グループに対するアプリケーションまたはインフラストラクチャのデプロイが完了した後で、既存のすべてのポリシーとイニシアチブのスコープ検査の検証のために、ポリシーの評価を行う必要があります。 このような環境では enforcementMode が disabled として構成されている場合もありますが、アプリケーションまたはインフラストラクチャのデプロイがポリシー定義に違反しているかどうかを早期に把握しておくと便利です。 したがって、このポリシーの評価はこれらのワークフローの 1 つの手順であり、非準拠のリソースを作成するデプロイメントを不合格とする必要があります。

確認

この記事では、コードとしての Azure Policy の一般的なワークフローについて、またポリシーの評価が他のデプロイ ワークフローの一部であるべき場合について説明しました。 このワークフローは、スクリプト化した手順と、トリガーに基づく自動化をサポートするすべての環境で使用できます。

次のステップ