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 に対して必要なアクセス許可を与えるには、ユーザー アクセス管理者 が必要です。 すべてのポリシー オブジェクトは、スコープのすべてのロールから読み取ることができるようになります。

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

注意

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

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

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

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

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

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

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

  • 1 つのポリシー定義の場合でも、イニシアチブ定義を作成して割り当てることをお勧めします。 たとえば、ポリシー定義 policyDefA をイニシアチブ定義 initiativeDefC の下に作成します。 後で policyDefA に似た目標の別のポリシー定義 policyDefB を作成する場合、それを initiativeDefC の下に追加して、まとめて追跡できます。

  • イニシアチブ割り当てを作成してあると、そのイニシアチブに追加されたポリシー定義もそのイニシアチブ割り当ての一部になります。

  • イニシアチブ割り当てが評価されたときは、イニシアチブ内のすべてのポリシーも評価されます。 ポリシーを個別に評価する必要がある場合は、ポリシーをイニシアティブに含めないことをお勧めします。

Azure Policy のオブジェクト

ポリシー定義

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

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

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

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

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

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

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

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

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

イニシアチブ定義

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

注意

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

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

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

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

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

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

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

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

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

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

代入

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

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

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

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

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

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

Where 対象 最大数
Scope ポリシーの定義 500
Scope イニシアチブ定義 200
Tenant イニシアチブ定義 2,500
Scope ポリシーとイニシアティブの割り当て 200
スコープ 適用除外 1000
ポリシー定義 パラメーター 20
イニシアチブ定義 ポリシー 1000
イニシアチブ定義 パラメーター 300
ポリシーとイニシアティブの割り当て 除外 (notScopes) 400
ポリシー規則 入れ子になった条件 512
修復タスク リソース 500

次のステップ

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