次の方法で共有


ポリシー主導のガードレールの採用

ポリシーを使用する前に、Azure ランディング ゾーンの参照実装内でそれが使用される場所と理由を理解する必要があります。 この記事は、Azure 環境内で DeployIfNotExists (DINE) または Modify ポリシーによる変更を防ぐ必要があるかどうかを理解するのに役立ちます。

DINE および Modify ポリシーを使用する理由

DINE および Modify ポリシーは、Azure ランディング ゾーンの参照実装の一部です。 個人および組織が、ランディング ゾーン (サブスクリプションとも呼ばれる)、およびその内部のリソースを確実に準拠状態にするうえで役立ちます。 これらのポリシーにより、Azure 環境の規模が拡大する際にプラットフォームとランディング ゾーンの各チームの運用上の負担が軽減されます。

たとえば、新しいランディング ゾーンのサブスクリプションがプロビジョニングされ、"corp" という管理グループに配置されるというシナリオについて考えてみましょう。 その後、DINE および Modify ポリシーが、このランディング ゾーンのサブスクリプションに対して次のアクションを実行します。

  • Microsoft Defender for Cloud を有効にします。 管理サブスクリプションでの中央 Log Analytics ワークスペースへの Defender for Cloud エクスポートを構成します。
  • ポリシーの割り当てで構成されたポリシー パラメーターに基づいて、サポートされているさまざまなオファリングに対して Defender for Cloud を有効にします。
  • 管理サブスクリプションの中央 Log Analytics ワークスペースに送信されるように Azure アクティビティ ログを構成します。
  • すべてのリソースの診断設定が管理サブスクリプションの中央 Log Analytics ワークスペースに送信されるように構成します。
  • 必要な Azure Monitor エージェントを仮想マシンと Azure 仮想マシン スケール セットにデプロイします。これには、Azure Arc に接続されたサーバーも含まれます。 それらを管理サブスクリプションの中央 Log Analytics ワークスペースに接続します。

注意

前述のオプションは、いつでも、または Azure ランディング ゾーン参照実装のデプロイ中に無効にできます。

上記のリストには、Azure ランディング ゾーン アクセラレータの一部として割り当てられているすべてのポリシーのサブセットが示されています。 Azure ランディング ゾーンの参照実装によって割り当て可能なポリシーの完全なリストについては、「Azure ランディング ゾーンの参照実装に含まれるポリシー」を参照してください。

Azure ランディング ゾーン bicep リポジトリはモジュール化されています。 上記の既定のポリシーは、ALZ の既定のポリシー割り当てモジュールを使用してデプロイできます。

割り当てられているすべてのポリシーは、自分とランディング ゾーンの所有者が準拠状態を維持するのに役立ちます。 実際のワークロード リソースが DINE および Modify ポリシーを使用してデプロイされることはありません。 このいずれの方法もお勧めしません。 詳しくは、「ワークロードをデプロイするには Azure Policy を使用する必要がありますか?」を参照してください。 これらの DINE ポリシーによってデプロイまたは構成されるのは、補助またはサポート リソースまたは設定のみです。

Azure ランディング ゾーンの参照実装では、DINE Azure ポリシーを使用すると、Azure 環境内でポリシー主導のガバナンスを実現するのに役立ちます。 ただし、以下の理由により、DINE および Modify ポリシーのどちらも使用できない場合や、この種の Azure ポリシー結果を有効にする準備が整っていないこともあります。

  • 規制コンプライアンス ポリシー、標準、または法律による制限。
  • Azure 環境内のすべてのアクションに対して人間の承認を必要とする厳格な変更制御プロセス。
  • DINE ポリシーを管理および使用する方法に関する専門知識、経験、理解がない。
  • 補助リソース、サポート リソース、設定を含むすべてのワークロード リソース構成が、ワークロード アプリケーション チームによってコードとしてのインフラストラクチャ (IaC) に定義されているという組織の要件。

上記の例や同様のシナリオがあてはまる場合、この記事は、Azure ランディング ゾーンの概念アーキテクチャの導入方法、およびその設計原則に従う方法を理解するのに役立ちます。 最初は特定のポリシーを使用しないものの、その後、徐々に有効にすることもできます。 目標は、ポリシー主導のガバナンスを実現するのを支援することです。

重要

この記事全体で、適用モードの用語として 2 つの可能な値が使用されています。

  • Disabled または DoNotEnforce
  • Enabled または Default

Azure portal では、適用モードについて Disabled と Enabled が使用されています。 Azure Resource Manager (ARM) テンプレートとその他の API インターフェイスでは、同じオプションに対して DoNotEnforce と Default が使用されています。

詳細については、「適用モード」を参照してください。

組織で DINE および Modify ポリシーを使用できないと思われる場合、この記事では、ポリシーによる Azure 環境への自動的な変更を防ぐ (無効にするとも言います) 方法について説明します。

注意

この操作は永続的ではありません。 後で、DINE または Modify ポリシーを使用することにした場合は、プラットフォーム チームのメンバーがポリシーをいつでも再び有効にできます。

詳しくは、フェーズ 2 とフェーズ 3 を参照してください。

リソース セレクターのサポートは、安全なデプロイ プラクティス (SDP) が確実に遵守されるように、ポリシー主導のガバナンスにも適用されます。 リソース セレクターは、リソースの場所、リソースの種類、リソースに場所が設定されているかどうかなどの要因に基づいて、ポリシー割り当てを段階的にロールアウトする機能を備えています。 詳細については、こちらのドキュメントをご覧ください

アプローチの概要

次の図は、推奨される段階的なアプローチの概要を示しています。

DINE フェーズの概要を示す図。

  1. 次のようにして、ポリシー割り当てで、適用モードDoNotEnforce に設定します。
    • この機能を使用すると、基になるポリシー定義を変更することなく、割り当ての動作を変更して、効率的に監査のみのポリシーにすることができます。
    • また、この方法では、必要な場合には、修復タスクを使用し、非準拠のリソースに対して手動修復タスクを行うこともできます。
  2. ポリシー割り当てで適用モードDefault に設定して、DINE ポリシー割り当ての自動修復を縮小されたスコープで再び有効にします。
    • 環境全体 (サンドボックス管理グループなど) を使用することを選択できます。
    • または、重要ではないワークロード サブスクリプションを使用することもできます。
  3. Azure 環境全体の残りの DINE ポリシーのポリシー割り当てで、適用モードDefault に設定します。

一部のお客様は、規制コンプライアンスの制限により、フェーズ 1 を通過できません。 これは問題ではなく、必要に応じてこの状態を維持するようにサポートされます。 他のお客様は、フェーズ 2 とフェーズ 3 に進み、DINE および Modify ポリシーを完全に採用し、Azure 環境のポリシー主導ガバナンスを支援できます。

注意

この記事で紹介されているシナリオとアプローチは、大多数のお客様を対象としたものではなく、また推奨されるものでもありません。 ご使用の環境にポリシーが適しているか、必要かどうかを判断する前に、「DINE および Modify ポリシーを使用する理由」というセクションを確認してください。

フェーズ 1: DINE および Modify ポリシーの自動化アクションを無効にする

ポリシーを割り当てる場合、既定では、ポリシー定義で定義されている効果が適用されます。 ポリシー定義はそのままにしておくことをお勧めします。 たとえば、ポリシー割り当てを DeployIfNotExists のままにします。

ポリシー定義やその効果を変更する代わりに、ポリシーの割り当てでこの機能を使用することで、最小限の労力でこの動作に影響を与えることができます。

Azure portal を使用して適用モードを Disabled に設定する

このスクリーンショットは、Azure portal を使用して、ポリシーの割り当ての適用モードを Disabled に設定する方法を示しています。 Disabled は DoNotEnforce とも呼ばれます。

Azure portal で強制モードを無効にする。

ARM テンプレートを使用して適用モードを DoNotEnforce に設定する

このコード例は、ARM テンプレートを使用して、ポリシーの割り当てで enforcementModeDoNotEnforce に設定する方法を示しています。 DoNotEnforceDisabled とも呼ばれます。

{
  "type": "Microsoft.Authorization/policyAssignments",
  "apiVersion": "2019-09-01",
  "name": "PolicyAssignmentName",
  "location": "[deployment().location]",
  "properties": {
    "description": "PolicyAssignmentDescription",
    "policyDefinitionId": "[parameters('policyDefinitionId')]",
    "enforcementMode": "DoNotEnforce"
    … // other properties removed for display purposes
  }
}

適用モードを使用すると、ユーザーは、ポリシーを開始することも、Azure Activity ログのエントリをトリガーすることもなく、既存のリソースに対する効果を確認できます。 このシナリオは、一般に "What If" と呼ばれ、安全な展開のプラクティスに沿っています。

適用モードDoNotEnforce に設定されている場合であっても、修復タスクを手動でトリガーすることができます。 特定の非準拠リソースを修復できます。 また、適用モードが Default に設定されている場合における DINE または Modify ポリシーによる実行内容を確認することもできます。

重要

適用モードが DoNotEnforce に設定されている場合、Azure Activity ログのエントリは生成されません。 非準拠リソースが作成されたら通知を受け取るようにしたい場合は、この点を考慮してください。

フェーズ 1 の状態を永続的に維持する

アプローチの概要」セクションで取り上げたように、お客様によっては、要件に応じてより長い期間、時には永続的にフェーズ 1 に留まらなければならないことがあります。 どのような長さの期間であってもこの状態は有効であり、お客様はその状態に留まることができます。

永続的に、あるいは長期 (年単位) にわたってこの状態に留まらなければならない場合もあります。 その場合、AuditIfNotExists (AINE) ポリシー結果と、関連する定義を採用し、適用モードを Default に戻すほうが良いことがあります。

注意

AINE ポリシーの使用に変更し、適用モードを Default に設定しても、DINE を無効にするという同じ目標を達成できることに変わりありません。

フェーズ 1 の長期的または永続的なアプローチとして DINE から AINE に変更し、適用モードを Default に戻すと、ポリシー コンプライアンスの状態に関する Azure のアクティビティ ログ エントリが再び利用できるようになります。 プラットフォーム管理操作全体で、これらのログ エントリから自動化ワークフローを構築できます。

手動修復タスクを実行する機能は失われることになります。 DINE ポリシーとは異なり AINE ポリシーでは、自動にせよ手動にせよ、デプロイは実行されません。

AuditIfNotExists ポリシーの割り当て効果を受け入れて許可するよう、忘れずにポリシー定義を更新してください。

次の表は、オプションと、さまざまな種類のポリシー結果と適用モードの組み合わせでの影響をまとめたものです。

ポリシー効果 実施モード アクティビティ ログ エントリ 修復処理
DINE Enabled または Default はい 作成またはリソースの更新後に、プラットフォームによる修復が大規模にトリガーされます。 ポリシー割り当ての前に依存リソースが変更されている、または既に存在する場合は、修復タスクを手動で作成する必要があります。
DINE Disabled または DoNotEnforce No 修復タスクを手動で作成する必要があります。
変更 Enabled または Default はい 作成または更新中の自動修復。
変更 Disabled または DoNotEnforce No 修復タスクを手動で作成する必要があります。
拒否 Enabled または Default はい 作成または更新が拒否されます。
拒否 Disabled または DoNotEnforce No 作成または更新は許可されます。 手動修復が必要です。
監査/AINE Enabled または Default はい 手動修復が必要です。
監査/AINE Disabled または DoNotEnforce No 手動修復が必要です。

注意

Azure Policy 状態変更イベントに対応する」のガイダンスを確認して、ポリシー状態イベントに基づいて独自の自動化を構築する予定の場合、Azure Policy との Azure Event Grid 統合を使用することが適切なアプローチになるかどうかを理解する必要があります。

フェーズ 2: 特定のポリシーまたは縮小されたスコープで DINE および Modify ポリシーを有効にする

このフェーズでは、ポリシーの割り当てで適用モードを Default に設定する方法について説明します。

フェーズ 1 を完了したら、DINE および Modify ポリシーの完全自動化機能を特定のポリシーまたは限定された範囲でテストし、試すことができます。 サンドボックス管理グループまたは非運用ワークロード サブスクリプションを使用することができます。

この手順を実行するには、まず DINE および Modify ポリシーの完全な自動化機能をテストおよび試行するために使用されるポリシーまたは縮小されたスコープを特定する必要があります。

注意

エンタープライズ規模のプラットフォームのテスト アプローチを確認し、実装することができます。 このようにして、同じテナント内にある独立した管理グループ階層で、ポリシーおよびその他のプラットフォームの変更をテストできます。

このアプローチは、"カナリア" デプロイとも呼ばれます。

次の表に、スコープとポリシーのいくつかの推奨例を示します。

目的... これらのスコープから選択します 使用するポリシーの例
- DINE と Modify 自動修復機能のテスト。
- 完全なデプロイ プロセスと CI/CD パイプライン (テストを含む) がどのような影響を受ける可能性があるかを確認する。
- ワークロードがどのような影響を受ける可能性があるかを確認する。
- サンドボックス サブスクリプション
- サンドボックス管理グループ
- 非運用ワークロード ランディング ゾーン サブスクリプション
- エンタープライズ規模の "カナリア" 環境
- 指定された Log Analytics ワークスペースにストリーミングするように Azure アクティビティ ログを構成する。
- Defender for Cloud の構成をデプロイする。
- VM または仮想マシン スケール セットに対して Azure Monitor を有効にする。
- Azure サービスに診断設定をデプロイする。
- イニシアティブ内の特定のサービスのみを有効にする可能性がある。

また、制限されたスコープまたはリソースのセットに対して手動修復タスクを使用して、これらのポリシーが環境にどのように影響するかをテストすることもできます。 修正タスクの作成方法について詳しくは、Azure Policy の資料である「修復タスクを作成する」を参照してください。

ポリシーと、それに割り当てる縮小されたスコープを特定した後、次の手順として、ポリシーを割り当て、適用モードを Default に設定します。 ポリシー結果、たとえば DeployIfNotExists または Modify などは、選択した縮小されたスコープでそのままにします。

Azure portal を使用して適用モードを Enabled に設定する

このスクリーンショットは、Azure portal を使用して、ポリシーの割り当てで適用モードを [Enabled] に設定する方法を示しています。 Enabled は Default とも呼ばれます。

Azure portalで強制モードを有効に設定するスクリーンショット。

ARM テンプレートを使用して適用モードを Default に設定する

このコード例は、ARM テンプレートを使用して、ポリシーの割り当てで enforcementModeDefault に設定する方法を示しています。 DefaultEnabled とも呼ばれます。

{
  "type": "Microsoft.Authorization/policyAssignments",
  "apiVersion": "2019-09-01",
  "name": "PolicyAssignmentName",
  "location": "[deployment().location]",
  "properties": {
    "description": "PolicyAssignmentDescription",
    "policyDefinitionId": "[parameters('policyDefinitionId')]",
    "enforcementMode": "Default"
    … // other properties removed for display purposes
  }
}

テスト

このフェーズの最後の手順は、必要なテストを実行することです。 DINE または Modify ポリシーがワークロード、コード、ツール、プロセスに影響を与え、変更を加えたかどうか、およびその方法を検証できます。

複数のテストを実行して、ワークロードのライフサイクル全体をキャプチャします。 DINE または Modify ポリシーによって変更が行われたかどうか、およびその方法を十分に理解できます。

テストの例をいくつか次に示します。

  • ワークロードの初期デプロイ。
  • ワークロードへのコードまたはアプリケーションのデプロイ。
  • Day 2 オペレーションとワークロードの管理。
  • ワークロードの使用停止。

フェーズ 3: すべての場所で DINE および Modify ポリシーを有効にする

このフェーズでは、ポリシーの割り当てで適用モードを Default に設定する方法について説明します。

フェーズ 2 の終了時に行ったテストが正常に完了したと想定しています。 または、DINE または Modify ポリシーがワークロードに対してどのように作用するかを現時点で理解できているかもしれません。 それで次に、Azure 環境の他の部分に、DINE および Modify ポリシーの使用を広げることができます。

続行するには、フェーズ 2 の手順と同様の手順を実行します。 今回は、Azure 環境全体のすべての DINE および Modify ポリシー割り当てで、適用モードを Default に設定します。

このフェーズで実行する手順の概要を次に示します。

  • フェーズ 2 中のテスト用に特別に使用された割り当てを削除します。
  • Azure 環境の各 DINE および Modify ポリシーの割り当てを確認し、適用モードを Default に設定します。 このプロセスについては、フェーズ 2 の例に示されています。
  • 修復タスクを作成する」に示されているガイダンスに従って、コンプライアンスに違反している既存のリソースについて、修復タスクを作成します。 新しいリソースは、ポリシー ルールと存在条件に合致すれば、自動的に修正されます。

フェーズ 3 でも、Azure 環境のすべての DINE および Modify ポリシーに関して適用モードを Default に設定することをお勧めしますが、この選択は省略可能です。 この選択は、ニーズや要件に合わせて、ポリシーごとに行うことができます。

高度なポリシー管理

大規模な Azure Policy の高度な管理については、ポリシーを管理するための Enterprise Policy as Code (EPAC) の実装を検討してください。 EPAC は、IaC を使用するステートフル管理エクスペリエンスを提供します。 一般に、複雑な要件を持つ大規模なポリシー管理シナリオに適しています。