次の方法で共有

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

  • [アーティクル]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次のステップ