新しい Azure ポリシー定義の影響を評価する

  • [アーティクル]

Azure Policy は、Azure リソースをビジネス標準に準拠させるニーズに対応するように管理するための強力なツールです。 ユーザー、プロセス、またはパイプラインによってリソースが作成または更新されるときに、Azure Policy によって要求が確認されます。 ポリシー定義の効果が Modify、Append、または DeployIfNotExists の場合は、ポリシーによって要求が変更されるか、または追加されます。 ポリシー定義の効果が Audit または AuditIfNotExists の場合は、ポリシーによって、新規および更新されたリソースに対してアクティビティ ログ エントリが作成されます。 また、ポリシー定義の効果が Deny または DenyAction の場合は、ポリシーによって要求の作成または変更が停止されます。

これらの結果は、ポリシーが正しく定義されていることがわかっている場合にのみ必要です。 ただし、新しいポリシーによって作業が変更されたりブロックされたりする前に、ポリシーが意図したとおりに動作することを検証することが重要です。 検証では、意図したリソースのみが非準拠であると判断され、準拠しているリソースが誤って結果に含まれないことを確認する必要があります ("擬陽性" と呼ばれます)。

新しいポリシー定義を検証するには、次の手順を実行することをお勧めします。

  • ポリシーを厳密に定義する
  • ポリシーの有効性をテストする
  • 新規または更新されたリソース要求を監査する
  • ポリシーをリソースに展開する
  • 継続的な監視

ポリシーを厳密に定義する

ビジネス ポリシーがポリシー定義として実装される方法、および Azure リソースと他の Azure サービスとの関係を、理解することが重要です。 このステップでは、要件を明らかにし、リソースのプロパティを決定します。 ただし、ビジネス ポリシーの狭い定義を超えて視野を広くすることも重要です。 たとえば、ポリシーでは "すべての仮想マシンは ... でなければならない" と指定されていますか。 HDInsight や AKS など、VM を利用する他の Azure サービスについてはどうでしょうか。 ポリシーを定義するときは、このポリシーが他のサービスで使用されているリソースにどのように影響するかを考慮する必要があります。

このため、ポリシー定義は、可能な限り厳密に定義し、準拠を評価する必要があるリソースとプロパティに対象を絞る必要があります。

ポリシーの有効性をテストする

新しいポリシー定義で新しいリソースまたは更新されたリソースを管理する前に、テスト リソース グループなど、既存リソースの限られたサブセットがどのように評価されるか確認することをお勧めします。 Azure Policy VS Code 拡張機能を利用すると、オンデマンド評価スキャンを使用する既存の Azure リソースに対する定義の分離されたテストが可能になります。 Dev 環境では、ポリシー割り当てで強制モード ''無効'' (DoNotEnforce) を使用して定義を割り当てて、効果がトリガーされたり、アクティビティ ログ エントリが作成されないようにすることもできます。

このステップでは、ワークフローに影響を与えずに、既存のリソースに対する新しいポリシーのコンプライアンス結果を評価することができます。 準拠しているリソースが非準拠として表示されないこと ("擬陽性") および非準拠と想定されるすべてのリソースが正しくマークされることを確認します。 リソースの最初のサブセットが想定どおりに検証された後、評価をより多くの既存のリソースとより多くの範囲に徐々に拡大します。

この方法で既存のリソースを評価することで、新しいポリシーを完全に実装する前に、非準拠リソースを修復することもできます。 このクリーンアップは、手動で行うことも、ポリシー定義の効果が DeployIfNotExists または Modify である場合は修復タスクで行うこともできます。

DeployIfNotExist のポリシー定義では、ARM テンプレートのデプロイ時に発生する変更を検証してテストするために Azure Resource Manager テンプレートの what if を活用する必要があります。

新規または更新されたリソースを監査する

既存リソースが新しいポリシー定義によって正しくレポートされることを検証したら、次に、リソースが作成または更新されたときのポリシーの影響を確認します。 ポリシー定義で効果のパラメーター化がサポートされている場合は、Audit または AuditIfNotExist を使用します。 この構成を使用すると、リソースの作成と更新を監視して、非準拠リソースに対する Azure アクティビティ ログのエントリが新しいポリシー定義によってトリガーされ、既存の作業または要求に影響がないことを確認できます。

ポリシー定義に一致するリソースの更新と新規作成の両方を行って、Audit または AuditIfNotExist 効果が想定どおりに正しくトリガーされるのを確認することをお勧めします。 Audit または AuditIfNotExist 効果をトリガーする新しいポリシー定義によって影響を受けてはならないリソース要求に注意してください。 このような影響を受けるリソースは擬陽性のもう 1 つの例であり、完全に実装する前にポリシー定義で修正する必要があります。

このテスト ステージでポリシー定義を変更した場合は、既存リソースの監査から検証プロセスをやり直すことをお勧めします。 新規リソースまたは更新リソースの "擬陽性" に対してポリシー定義を変更すると、既存のリソースにも影響する可能性があります。

ポリシーをリソースに展開する

既存リソースと新規または更新リソースの要求の両方で新しいポリシー定義の検証が完了したら、ポリシーの実装プロセスを始めます。 最初は、すべてのリソースのサブセット (リソース グループなど) に対して、新しいポリシー定義のポリシー割り当てを作成することをお勧めします。 ポリシー割り当て内の resourceSelectors プロパティを使用して、リソースの種類または場所でさらにフィルター処理できます。初期デプロイを検証した後、ポリシーの範囲をリソース グループとしてより広範に広げます。 初期デプロイを検証した後、resourceSelector フィルターを調整して、より多くの場所やリソースの種類をターゲットにするか、割り当てを削除して、サブスクリプションや管理グループなどのより広い範囲で新しいものに置き換えることで、ポリシーの影響を拡大します。 新しいポリシー定義の対象となるリソースの全範囲に割り当てられるまで、この段階的なロールアウトを続行します。

ロールアウトの間に、新しいポリシー定義から除外する必要があるリソースが見つかった場合は、次のいずれかの方法で対処します。

  • 意図しない影響が経るように、ポリシー定義をより明示的に更新します
  • ポリシー割り当ての範囲を変更します (割り当てを削除して新しい割り当てを作成します)
  • ポリシー割り当ての除外リストにリソースのグループを追加します

範囲 (レベルまたは除外) の変更を完全に検証し、セキュリティとコンプライアンスの組織に連絡して、カバレッジにギャップがないことを確認する必要があります。

ポリシーとコンプライアンスを監視する

ポリシー定義の実装と割り当てが最後のステップではありません。 新しいポリシー定義に対するリソースのコンプライアンス レベルを継続的に監視し、非準拠デバイスが識別された場合に対して適切な Azure Monitor のアラートと通知をセットアップします。 また、ポリシー定義および関連する割り当てを定期的に評価し、ポリシー定義がビジネス ポリシーとコンプライアンス ニーズを満たしていることを検証することもお勧めします。 不要になった場合は、ポリシーを削除する必要があります。 また、ポリシーは基になる Azure リソースが進化を遂げ、新しいプロパティと機能が追加されるたびに、随時更新する必要があります。

次のステップ