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

[アーティクル]
06/01/2023

ポリシーを使用する前に、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 フェーズの概要を示す図。

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

{
  "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 テンプレートを使用して、ポリシーの割り当てで enforcementMode を Default に設定する方法を示しています。 Default は Enabled とも呼ばれます。

{
  "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 を使用するステートフル管理エクスペリエンスを提供します。一般に、複雑な要件を持つ大規模なポリシー管理シナリオに適しています。

次の方法で共有