Azure Policy とは

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

注意

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

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

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 では、だれが変更を行ったかや、だれが変更を行うアクセス許可を持っているかに関係なく、リソースがお客様のビジネス ルールに準拠した状態になります。 ポリシー定義イニシアティブ定義割り当てなどの一部の 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 のすべての "読み取り" 操作にアクセスできます。

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

注意

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

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

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

メモ

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

Azure Virtual Network Manager (プレビュー) を使用した Azure Policy に対する特別なアクセス許可の要件

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

Azure Virtual Network Manager 動的グループ ポリシーを作成、編集、または削除するには、前に説明したように適切な読み取りおよび書き込み Azure ポリシー RBAC アクセス許可が必要になるだけでなく、ネットワーク グループに参加するアクセス許可も必要になります。

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

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

Azure Policy は、Arc 対応リソースを含め、サブスクリプションレベルまたはそれ以下のレベルにあるすべての Azure リソースを評価します。 マシン構成Azure Kubernetes ServiceAzure Key Vault などの特定のリソース プロバイダーについては、設定とオブジェクトを管理するための詳細な統合機能があります。 詳細については、リソース プロバイダーのモードに関するページを参照してください。

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

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

  • 最初は拒否効果ではなく監査効果を使用して、環境内のリソースに対するポリシー定義の影響を追跡します。 アプリケーションを自動スケーリングするスクリプトが既にある場合、拒否効果を設定すると、このような自動化タスクが妨げられる場合があります。

  • 定義と割り当てを作成するときは、組織階層を考慮します。 管理グループやサブスクリプション レベルのような高いレベルで定義を作成することをお勧めします。 それから、次の子レベルで割り当てを作成します。 管理グループで定義を作成した場合、その管理グループ内にあるサブスクリプションまたはリソース グループまで割り当ての対象にできます。

  • 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」(ポリシー評価のトリガー) をご覧ください。

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

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

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

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

イニシアティブ定義

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

メモ

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

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

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

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

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

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

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

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

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

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

割り当て

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

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

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

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

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

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

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

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

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

次のステップ

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