Azure Policy とは

[アーティクル]
04/17/2024

Azure Policy は、組織の標準を適用し、コンプライアンスを大規模に評価するのに役立ちます。コンプライアンスダッシュボードを通じて、環境の全体的な状態を評価するための集計ビューを提供します。これには、リソースごと、およびポリシーごとの粒度でドリルダウンできる機能が備わっています。既存のリソースの一括修復と新しいリソースの自動修復を使用して、お客様のリソースでコンプライアンスを実現するのにも便利です。

注意

修復の詳細については、「Azure Policy を使って準拠していないリソースを修復する」を参照してください。

Azure Policy の一般的なユースケースには、リソースの整合性、規制コンプライアンス、セキュリティ、コスト、管理のガバナンスの実装が含まれています。これらの一般的なユースケース用のポリシー定義は、使用を開始できるようにビルトインとして Azure 環境に既に用意されています。

具体的には、Azure Policy で適用できる便利なガバナンスアクションには、次のようなものがあります。

チームが許可されたリージョンにのみ Azure リソースをデプロイするようにする
分類タグの一貫した適用を実施する
Log Analytics ワークスペースに診断ログを送信するようにリソースに要求する

Azure Arc の導入により、ポリシーベースのガバナンスをさまざまなクラウドプロバイダー全体、さらにはローカルデータセンターに拡張できることを認識することが重要です。

Azure Policy のデータとオブジェクトはすべて、暗号化された状態で保存されます。詳細については、「保存時の Azure データの暗号化」を参照してください。

概要

Azure Policy では、Azure 内のリソースのプロパティをビジネスルールと比較して、それらのリソースとアクションを評価します。 JSON 形式で記述されるこれらのビジネスルールは、ポリシー定義と呼ばれます。管理を容易にするために、複数のビジネスルールをグループ化して、ポリシーイニシアティブ (policySet とも呼ばれます) を作成できます。ビジネスルールを作成すると、ポリシーの定義またはイニシアティブは、Azure でサポートされているリソース (管理グループ、サブスクリプション、リソースグループ、個々のリソースなど) の任意のスコープに割り当てられます。割り当ては、その割り当ての Resource Manager スコープ内のすべてのリソースに適用されます。サブスコープは必要に応じて除外できます。詳細については、Azure Policy のスコープに関するページを参照してください。

Azure Policy では、リソースが準拠しているかどうかを特定するために評価で使用されるロジックの作成に、JSON 形式を使用します。定義には、メタデータとポリシー規則が含まれています。定義される規則では、目的とするシナリオに正確に合わせて関数、パラメーター、論理演算子、条件、プロパティの別名を使用できます。ポリシー規則によって、割り当てのスコープ内のどのリソースが評価されるかが決定されます。

評価結果を理解する

リソースは、リソースライフサイクル、ポリシー割り当てライフサイクル、進行中の定期的なコンプライアンス評価の間に、特定のタイミングで評価されます。リソースの評価が行われるタイミングまたはイベントは次のとおりです。

ポリシー割り当てを使用してリソースがスコープ内で作成または更新される。
ポリシーまたはイニシアティブがスコープに新たに割り当てられる。
既にスコープに割り当てられているポリシーまたはイニシアティブが更新される。
標準のコンプライアンス評価サイクルで、24 時間ごとに実行される。

ポリシーの評価が実施されるタイミングと方法の詳細については、「評価のトリガー」を参照してください。

評価への対応を制御する

準拠していないリソースを処理するためのビジネスルールは、組織によって大きく異なります。たとえば、組織がプラットフォームで準拠していないリソースに対応する方法には、以下のようなものがあります。

リソースの変更を拒否する
リソースへの変更をログに記録する
変更前にリソースを変更する
変更後にリソースを変更する
準拠している関連リソースをデプロイする
リソースに対するアクションをブロックする

Azure Policy では、効果を適用して、これらの各ビジネス対応を実現できます。効果は、ポリシー定義のポリシールールの部分で設定されます。

準拠していないリソースを修復する

これらの影響は主にリソースの作成時または更新時にリソースに影響を与えますが、Azure Policy では、準拠していない既存のリソースを変更せずに、そのリソースを処理することもできます。既存のリソースを準拠させる方法の詳細については、リソースの修復に関するページを参照してください。

ビデオの概要

次の Azure Policy の概要は、ビルド 2018 に基づいています。スライドまたはビデオのダウンロードについては、チャンネル 9 の「Govern your Azure environment through Azure Policy」(Azure Policy による Azure 環境の管理) を参照してください。

作業の開始

Azure Policy と Azure RBAC

Azure Policy と Azure ロールベースのアクセス制御 (Azure RBAC) には、いくつかの主要な違いがあります。 Azure Policy では、Resource Manager で表されるリソースのプロパティと一部のリソースプロバイダーのプロパティを調査することによって状態を評価します。 Azure Policy では、だれが変更を行ったかや、だれが変更を行うアクセス許可を持っているかに関係なく、リソースがお客様のビジネスルールに準拠した状態になります。 Azure Policy では、DenyAction 効果により、リソースに対する特定のアクションをブロックすることもできます。ポリシー定義、イニシアティブ定義、割り当てなどの一部の Azure Policy リソースは、すべてのユーザーに表示されます。この設計により、すべてのユーザーとサービスに対して、その環境でどのようなポリシールールが設定されているかの透明性が実現されます。

Azure RBAC の焦点は、さまざまなスコープでのユーザー操作の管理にあります。ユーザー情報に基づいてアクションの制御が必要な場合は、Azure RBAC が使用に適したツールになります。あるユーザーがアクションを実行するためのアクセス権を持っていても、結果としてリソースが準拠していない場合、その作成や更新は Azure Policy によってブロックされます。

Azure RBAC と Azure Policy を組み合わせることによって、Azure で完全なスコープの制御を実現できます。

Azure Policy における Azure RBAC アクセス許可

Azure Policy には、次の 2 つのリソースプロバイダーで操作と呼ばれるいくつかのアクセス許可があります。

Azure Policy のリソースに対するアクセス許可は、さまざまな組み込みロールによって与えられます。 リソースポリシーの共同作成者ロールには、Azure Policy のほとんどの操作が含まれます。 所有者は完全な権限を持っています。 共同作成者と閲覧者はどちらも、Azure Policy のすべての "読み取り" 操作にアクセスできます。

共同作成者はリソースの修復をトリガーできますが、定義や割り当てを "作成" または "更新" することはできません。 deployIfNotExists や modify 割り当てのマネージド ID に対して必要なアクセス許可を与えるには、ユーザーアクセス管理者が必要です。

注意

定義、イニシアティブ、割り当てを含むすべての Azure Policy オブジェクトは、適用されるスコープのすべてのロールで読み取り可能です。たとえば、Azure サブスクリプションをスコープとするポリシー割り当ては、サブスクリプションスコープ以下のすべてのロール所有者が読み取り可能です。

いずれの組み込みロールにも必要なアクセス許可がない場合は、カスタムロールを作成してください。

Azure Policy の操作は、Azure 環境に大きな影響を与える可能性があります。タスクを実行するために必要な最小限の権限セットのみを割り当てる必要があり、これらのアクセス許可を必要としないユーザーに付与することはできません。

Note

deployIfNotExists ポリシー割り当てまたは modify ポリシー割り当てのマネージド ID には、対象となるリソースを作成したり更新したりするための十分なアクセス許可が必要です。詳細については、修復用のポリシー定義の構成に関するページを参照してください。

Azure Virtual Network Manager を使用した Azure Policy に対する特別なアクセス許可の要件

Azure Virtual Network Manager (プレビュー) を使用すると、クラウドインフラストラクチャ全体で一貫した管理ポリシーとセキュリティポリシーを複数の Azure 仮想ネットワーク (VNet) に適用できます。 Azure Virtual Network Manager (AVNM) 動的グループは、Azure Policy 定義を使用して、それらのグループの VNet メンバーシップを評価します。

Azure Virtual Network Manager 動的グループポリシーを作成、編集、または削除するには、次のものが必要です。

基になるポリシーに対する Azure RBAC の読み取りおよび書き込みアクセス許可
ネットワークグループに参加するための Azure RBAC アクセス許可 (Classic Admin 承認はサポートされていません)。

具体的には、必要なリソースプロバイダーのアクセス許可は Microsoft.Network/networkManagers/networkGroups/join/action です。

重要

AVNM 動的グループを変更するには、Azure RBAC ロールの割り当てのみを使用してアクセス権を付与する必要があります。 Classic Admin/レガシ承認はサポートされていません。つまり、アカウントに共同管理者サブスクリプションロールのみが割り当てられた場合、AVNM 動的グループに対するアクセス許可は付与されません。

Azure Policy の対象となるリソース

ポリシーは管理グループレベルで割り当てることができますが、評価されるのはサブスクリプションまたはリソースグループレベルのリソースのみです。

マシン構成、Azure Kubernetes Service、Azure Key Vault などの特定のリソースプロバイダーについては、設定とオブジェクトを管理するための詳細な統合機能があります。詳細については、リソースプロバイダーのモードに移動してください。

ポリシー管理に関する推奨事項

留意すべきいくつかの指摘とヒントを次に示します。

最初は強制 (deny、modify、deployIfNotExist) 効果ではなく audit または auditIfNotExist 効果を使用して、環境内のリソースに対するポリシー定義の影響を追跡します。アプリケーションを自動スケーリングするスクリプトが既にある場合、強制効果を設定すると、既に設定されているそのような自動化タスクが妨げられる場合があります。
定義と割り当てを作成するときは、組織階層を考慮します。管理グループやサブスクリプションレベルのような高いレベルで定義を作成することをお勧めします。それから、次の子レベルで割り当てを作成します。管理グループで定義を作成した場合、その管理グループ内にあるサブスクリプションまたはリソースグループまで割り当ての対象にできます。
1 つのポリシー定義で始める場合でも、イニシアチブ定義を作成して割り当てることをお勧めします。これにより、後で管理する割り当ての数を増やすことなく、ポリシー定義をイニシアチブに追加できます。
- たとえば、ポリシー定義 policyDefA を作成し、これをイニシアチブ定義 initiativeDefC の下に追加するとします。後で policyDefA に似た目標の別のポリシー定義 policyDefB を作成する場合、それを initiativeDefC の下に追加して、まとめて追跡できます。
- イニシアティブ割り当てを作成してあると、そのイニシアティブに追加されたポリシー定義もそのイニシアティブ割り当ての一部になります。
- イニシアティブ割り当てが評価されたときは、イニシアティブ内のすべてのポリシーも評価されます。ポリシーを個別に評価する必要がある場合は、ポリシーをイニシアティブに含めないことをお勧めします。
ポリシーの定義、イニシアティブ、割り当ての変更に関する手動レビューを使用して、Azure Policy リソースをコードとして管理します。推奨されるパターンとツールの詳細については、「コードとしての Azure Policy ワークフローを設計する」を参照してください。

Azure Policy のオブジェクト

ポリシー定義

Azure Policy でポリシーを作成して実装する手順は、ポリシー定義の作成から始まります。すべてのポリシー定義に、ポリシーが適用される条件があります。また、条件が満たされた場合に実現される効果も定義されています。

Azure Policy には、既定で使うことができる組み込みポリシーがいくつかあります。次に例を示します。

許可されているストレージアカウントの SKU (拒否):展開されているストレージアカウントが SKU サイズの設定内であるかどうかを判断します。その効果として、定義されている SKU サイズの設定に準拠していないすべてのストレージアカウントが拒否されます。
使用できるリソースの種類 (拒否):展開できるリソースの種類を定義します。その効果として、この定義済みリストの一部ではないすべてのリソースが拒否されます。
許可されている場所 (拒否):新しいリソースに使用できる場所を制限します。その効果は、geo コンプライアンス要件を強制するために使用されます。
許可されている仮想マシン SKU (拒否):展開できる仮想マシンの SKU の設定を指定します。
リソースへのタグの追加 (変更):展開要求によって指定されていない場合に、必要なタグとその既定値を適用します。
許可されていないリソースの種類 (拒否):リストのリソースの種類が展開されないようにします。

これらのポリシー定義 (組み込み定義とカスタム定義の両方) を実装するには、割り当てを行う必要があります。こうしたポリシーを割り当てるには、Azure Portal、PowerShell、または Azure CLI を使用します。

ポリシーの割り当てやポリシーの更新など、いくつかの異なるアクションでポリシーの評価が行われます。完全な一覧については、「Policy evaluation triggers」(ポリシー評価のトリガー) をご覧ください。

ポリシー定義の構造の詳細については、ポリシー定義の構造に関するページを参照してください。

ポリシーパラメーターは、作成する必要があるポリシー定義の数を減らしてポリシーの管理を簡素化するのに役立ちます。ポリシー定義を作成するときにパラメーターを定義して、ポリシー定義を汎用化できます。その後、そのポリシー定義を、さまざまなシナリオで再利用できます。これを行うには、ポリシー定義を割り当てるときに、さまざまな値を渡します。たとえば、サブスクリプションに対して一連の場所を指定します。

パラメーターは、ポリシー定義を作成するときに定義します。パラメーターを定義するときは、名前と、必要に応じて値を指定します。たとえば、"場所" というポリシーのパラメーターを定義できます。その後、ポリシーを割り当てるときに、EastUS、WestUS など、さまざまな値を指定できます。

ポリシーパラメーターについて詳しくは、定義の構造でのパラメーターに関する項目をご覧ください。

イニシアティブ定義

イニシアティブ定義は、単一の包括的なゴールを達成することを目的として調整されたポリシー定義のコレクションです。イニシアティブ定義により、ポリシー定義の管理と割り当てが簡素化されます。簡素化するには、一連のポリシーを 1 つのアイテムとしてグループ化します。たとえば、Microsoft Defender for Cloud で監視を有効にするというタイトルでイニシアティブを作成し、Microsoft Defender for Cloud インスタンスで利用できるすべてのセキュリティ推奨を監視することを目標とします。

Note

Azure CLI や Azure PowerShell などの SDK では、PolicySet という名前のプロパティとパラメーターを使用して、イニシアティブを参照します。

このイニシアティブでは、次のようなポリシー定義を作成します。

暗号化されていない SQL Database を Microsoft Defender for Cloud で監視する - 暗号化されていない SQL データベースとサーバーを監視します。
OS の脆弱性を Microsoft Defender for Cloud で監視する - 構成されているベースラインを満たしていないサーバーを監視します。
エンドポイント保護の不足を Microsoft Defender for Cloud で監視する - エンドポイント保護エージェントがインストールされていないサーバーを監視します。

ポリシーパラメーターと同様に、イニシアティブパラメーターは冗長性を減らすことでイニシアティブの管理を簡素化できます。イニシアティブパラメーターは、イニシアティブ内のポリシー定義によって使われるパラメーターです。

たとえば、イニシアティブ定義 initiativeC にポリシー定義 policyA と policyB が含まれており、それぞれのポリシー定義が異なる種類のパラメーターを予期しているというシナリオについて考えてみましょう。

ポリシー	パラメーターの名前	パラメーターの型	Note
policyA	allowedLocations	array	このパラメーターは、パラメーターの型が配列として定義されているため、文字列のリストが値として必要です。
policyB	allowedSingleLocation	string	このパラメーターは、パラメーターの型が文字列として定義されているため、1 つの単語が値として必要です。

このシナリオで initiativeC のイニシアティブパラメーターを定義する場合、3 つのオプションがあります。

このイニシアティブ内でポリシー定義のパラメーターを使用します。この例では、allowedLocations と allowedSingleLocation が initiativeC のイニシアティブパラメーターになります。
このイニシアティブ定義内でポリシー定義のパラメーターに値を指定します。この例では、policyA のパラメーター - allowedLocations および policyB のパラメーター - allowedSingleLocation に場所のリストを提供できます。このイニシアティブを割り当てるときに値を指定することもできます。
このイニシアティブを割り当てるときに使うことができる "値" オプションのリストを指定します。このイニシアティブを割り当てるときは、イニシアティブ内のポリシー定義から継承したパラメーターは、この指定されたリストの値だけを持つことができます。

イニシアティブ定義で値のオプションを作成すると、イニシアティブの割り当てで別の値を入力することは、リストの一部ではないためできません。

イニシアティブ定義の構造の詳細については、イニシアティブ定義の構造に関するページを参照してください。

代入

割り当ては、特定のスコープに割り当てられたポリシーの定義またはイニシアティブです。このスコープの範囲は、管理グループから個々のリソースまでです。 "スコープ" という用語は、定義が割り当てられる、すべてのリソース、リソースグループ、サブスクリプション、または管理グループのことを指します。割り当ては、すべての子リソースによって継承されます。この設計は、リソースグループに適用された定義が、そのリソースグループ内のリソースにも適用されることを意味します。ただし、サブスコープを割り当てから除外できます。

たとえば、サブスクリプションスコープで、ネットワークリソースの作成を禁止する定義を割り当てることができます。ネットワークインフラストラクチャを対象としたリソースグループを、そのサブスクリプション内で除外できます。その後、このネットワークリソースグループへのアクセスは、信頼できるユーザーに許可し、そのユーザーがネットワークリソースを作成できるようにします。

別の例として、リソースの種類の許可リスト定義を管理グループレベルで割り当てたいとしましょう。そのうえで、より制限の緩やかな (より多くのリソースの種類を許可する) ポリシーを子管理グループまたはサブスクリプションに直接割り当てます。しかし、この例はうまくいきません。Azure Policy は明示的な拒否のシステムであるためです。代わりに、管理グループレベルの割り当てから、子管理グループまたはサブスクリプションを除外する必要があります。そのうえで、より制限の緩やかな定義を子管理グループまたはサブスクリプションレベルで割り当てます。いずれかの割り当てでリソースが拒否される場合、拒否割り当てに変更を加えることが、そのリソースを許可する唯一の方法となります。

ポリシーの割り当てでは、リソースを評価するときに、割り当てられた定義またはイニシアティブの最新の状態が常に使用されます。既に割り当てられているポリシーの定義が変更された場合、その定義の既存の割り当てではすべて、評価時に更新されたロジックが使用されます。

ポータルを使用した割り当ての設定の詳細については、ポリシー割り当てを作成し、Azure 環境内の準拠していないリソースを特定する方法に関するページを参照してください。 PowerShellとAzure CLI の場合の手順も利用することができます。割り当て構造の詳細については、割り当て構造に関するページを参照してください。

Azure Policy オブジェクトの最大数

Azure Policy では、オブジェクトの種類ごとに最大数があります。定義について、スコープ というエントリは管理グループまたはサブスクリプションを意味します。割り当てと除外の場合、"スコープ" というエントリは管理グループ、サブスクリプション、リソースグループ、または個々のリソースを意味します。

Where	対象	最大数
Scope	ポリシーの定義	500
Scope	イニシアティブ定義	200
Tenant	イニシアティブ定義	2,500
Scope	ポリシーとイニシアティブの割り当て	200
スコープ	適用除外	1000
ポリシー定義	パラメーター	20
イニシアティブ定義	ポリシー	1000
イニシアティブ定義	パラメーター	400
ポリシーとイニシアティブの割り当て	除外 (notScopes)	400
ポリシー規則	入れ子になった条件	512
修復タスク	リソース	50,000
ポリシー定義、イニシアティブ、または割り当ての要求本文	バイト	1,048,576

ポリシー規則には、条件の数とその複雑さについての追加の制限があります。詳細については、「ポリシー規則の制限」を参照してください。

次のステップ

これで、Azure Policy の概要といくつかの主要な概念に関する説明は終了です。推奨される次の手順は以下のとおりです。

次の方法で共有