Azure Policy とはWhat is Azure Policy?

Azure Policy は、組織の標準を適用し、コンプライアンスを大規模に評価するのに役立ちます。Azure Policy helps to enforce organizational standards and to assess compliance at-scale. コンプライアンス ダッシュボードを通じて、環境の全体的な状態を評価するための集計ビューを提供します。これには、リソースごと、およびポリシーごとの粒度でドリルダウンできる機能が備わっています。Through its compliance dashboard, it provides an aggregated view to evaluate the overall state of the environment, with the ability to drill-down to the per-resource, per-policy granularity. 既存のリソースの一括修復と新しいリソースの自動修復を使用して、お客様のリソースでコンプライアンスを実現するのにも便利です。It also helps to bring your resources to compliance through bulk remediation for existing resources and automatic remediation for new resources.

Azure Policy の一般的なユースケースには、リソースの整合性、規制コンプライアンス、セキュリティ、コスト、管理のガバナンスの実装が含まれています。Common use cases for Azure Policy include implementing governance for resource consistency, regulatory compliance, security, cost, and management. これらの一般的なユース ケース用のポリシー定義は、使用を開始できるようにビルトインとして Azure 環境に既に用意されています。Policy definitions for these common use cases are already available in your Azure environment as built-ins to help you get started.

概要Overview

Azure Policy では、Azure 内のリソースのプロパティをビジネス ルールと比較して、それらのリソースを評価します。Azure Policy evaluates resources in Azure by comparing the properties of those resources to business rules. JSON 形式で記述されるこれらのビジネス ルールは、ポリシー定義と呼ばれます。These business rules, described in JSON format, are known as policy definitions. 管理を容易にするために、複数のビジネス ルールをグループ化して、ポリシー イニシアチブ (policySet とも呼ばれます) を作成できます。To simplify management, several business rules can be grouped together to form a policy initiative (sometimes called a policySet). ビジネス ルールを作成すると、ポリシーの定義またはイニシアチブは、Azure でサポートされているリソース (管理グループ、サブスクリプション、リソース グループ、個々のリソースなど) の任意のスコープに割り当てられます。Once your business rules have been formed, the policy definition or initiative is assigned to any scope of resources that Azure supports, such as management groups, subscriptions, resource groups, or individual resources. 割り当ては、その割り当てのスコープ内におけるすべてのリソースに適用されます。The assignment applies to all resources within the scope of that assignment. サブスコープは必要に応じて除外できます。Subscopes can be excluded, if necessary.

Azure Policy では、リソースが準拠しているかどうかを特定するために評価で使用されるロジックの作成に、JSON 形式を使用します。Azure Policy uses a JSON format to form the logic the evaluation uses to determine if a resource is compliant or not. 定義には、メタデータとポリシー規則が含まれています。Definitions include metadata and the policy rule. 定義される規則では、目的とするシナリオに正確に合わせて関数、パラメーター、論理演算子、条件、プロパティの別名を使用できます。The defined rule can use functions, parameters, logical operators, conditions, and property aliases to match exactly the scenario you want. ポリシー規則によって、割り当てのスコープ内のどのリソースが評価されるかが決定されます。The policy rule determines which resources in the scope of the assignment get evaluated.

評価結果を理解するUnderstand evaluation outcomes

リソースは、リソース ライフサイクル、ポリシー割り当てライフサイクル、進行中の定期的なコンプライアンス評価の間に、特定のタイミングで評価されます。Resources are evaluated at specific times during the resource lifecycle, the policy assignment lifecycle, and for regular ongoing compliance evaluation. リソースの評価が行われるタイミングまたはイベントは次のとおりです。The following are the times or events that cause a resource to be evaluated:

  • リソースが、ポリシー割り当てのスコープ内で作成、更新、削除される。A resource is created, updated, or deleted in a scope with a policy assignment.
  • ポリシーまたはイニシアティブがスコープに新たに割り当てられる。A policy or initiative is newly assigned to a scope.
  • 既にスコープに割り当てられているポリシーまたはイニシアティブが更新される。A policy or initiative already assigned to a scope is updated.
  • 標準のコンプライアンス評価サイクルで、24 時間ごとに実行される。During the standard compliance evaluation cycle, which occurs once every 24 hours.

ポリシーの評価が実施されるタイミングと方法の詳細については、「評価のトリガー」を参照してください。For detailed information about when and how policy evaluation happens, see Evaluation triggers.

評価への対応を制御するControl the response to an evaluation

準拠していないリソースを処理するためのビジネス ルールは、組織によって大きく異なります。Business rules for handling non-compliant resources vary widely between organizations. たとえば、組織がプラットフォームで準拠していないリソースに対応する方法には、以下のようなものがあります。Examples of how an organization wants the platform to respond to a non-complaint resource include:

  • リソースの変更を拒否するDeny the resource change
  • リソースへの変更をログに記録するLog the change to the resource
  • 変更前にリソースを変更するAlter the resource before the change
  • 変更後にリソースを変更するAlter the resource after the change
  • 準拠している関連リソースをデプロイするDeploy related compliant resources

Azure Policy では、効果を適用して、これらの各ビジネス対応を実現できます。Azure Policy makes each of these business responses possible through the application of effects. 効果は、ポリシー定義ポリシー規則の部分で設定されます。Effects are set in the policy rule portion of the policy definition.

準拠していないリソースを修復するRemediate non-compliant resources

これらの影響は主にリソースの作成時または更新時にリソースに影響を与えますが、Azure Policy では、準拠していない既存のリソースを変更せずに、そのリソースを処理することもできます。While these effects primarily affect a resource when the resource is created or updated, Azure Policy also supports dealing with existing non-compliant resources without needing to alter that resource. 既存のリソースを準拠させる方法の詳細については、リソースの修復に関するページを参照してください。For more information about making existing resources compliant, see remediating resources.

ビデオの概要Video overview

次の Azure Policy の概要は、ビルド 2018 に基づいています。The following overview of Azure Policy is from Build 2018. スライドまたはビデオのダウンロードについては、チャンネル 9 の「Govern your Azure environment through Azure Policy」(Azure Policy による Azure 環境の管理) を参照してください。For slides or video download, visit Govern your Azure environment through Azure Policy on Channel 9.

作業の開始Getting started

Azure Policy と RBACAzure Policy and RBAC

Azure Policy とロールベースのアクセス制御 (RBAC) には、いくつかの主要な違いがあります。There are a few key differences between Azure Policy and role-based access control (RBAC). Azure Policy では、Resource Manager で表されるリソースのプロパティと一部のリソースプロバイダーのプロパティを調査することによって状態を評価します。Azure Policy evaluates state by examining properties on resources that are represented in Resource Manager and properties of some Resource Providers. Azure Policy によってアクション ("操作" とも呼ばれる) が制限されることはありません。Azure Policy doesn't restrict actions (also called operations). Azure Policy では、だれが変更を行ったかや、だれが変更を行うアクセス許可を持っているかに関係なく、リソースがお客様のビジネス ルールに準拠した状態になります。Azure Policy ensures that resource state is compliant to your business rules without concern for who made the change or who has permission to make a change.

RBAC の焦点は、さまざまなスコープでのユーザー操作の管理にあります。RBAC focuses on managing user actions at different scopes. アクションの制御が必要な場合は、RBAC が使用に適したツールになります。If control of an action is required, then RBAC is the correct tool to use. あるユーザーがアクションを実行するためのアクセス権を持っていても、結果としてリソースが準拠していない場合、その作成や更新は Azure Policy によってブロックされます。Even if an individual has access to perform an action, if the result is a non-compliant resource, Azure Policy still blocks the create or update.

RBAC と Azure Policy を組み合わせることによって、Azure で完全なスコープの制御を実現できます。The combination of RBAC and Azure Policy provide full scope control in Azure.

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

Azure Policy は、次の 2 つのリソース プロバイダーにおいて、いくつかのアクセス許可 (操作) を有しています。Azure Policy has several permissions, known as operations, in two Resource Providers:

Azure Policy のリソースに対するアクセス許可は、さまざまな組み込みロールによって与えられます。Many Built-in roles grant permission to Azure Policy resources. リソース ポリシーの共同作成者ロールには、Azure Policy のほとんどの操作が含まれます。The Resource Policy Contributor role includes most Azure Policy operations. 所有者は完全な権限を持っています。Owner has full rights. 共同作成者閲覧者はどちらも、Azure Policy のすべての "読み取り" 操作にアクセスできます。Both Contributor and Reader have access to all read Azure Policy operations. 共同作成者はリソースの修復をトリガーできますが、定義や割り当てを "作成" することはできません。Contributor may trigger resource remediation, but can't create definitions or assignments.

いずれの組み込みロールにも必要なアクセス許可がない場合は、カスタム ロールを作成してください。If none of the Built-in roles have the permissions required, create a custom role.

注意

deployIfNotExists ポリシー割り当てのマネージド ID には、テンプレートに含まれているリソースを作成または更新するのに十分なアクセス許可が必要です。The managed identity of a deployIfNotExists policy assignment needs enough permissions to create or update resources included in the template. 詳細については、修復用のポリシー定義の構成に関するページを参照してください。For more information, see Configure policy definitions for remediation.

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

Azure Policy では Azure 内のすべてのリソースを評価します。Azure Policy evaluates all resources in Azure. ゲスト構成Azure Kubernetes ServiceAzure Key Vault などの特定のリソース プロバイダーについては、設定とオブジェクトを管理するための緊密な統合があります。For certain resource providers such as Guest Configuration, Azure Kubernetes Service, and Azure Key Vault, there's a deeper integration for managing settings and objects. 詳細については、リソース プロバイダーのモードに関するページを参照してください。To find out more, see Resource Provider modes.

ポリシー管理に関する推奨事項Recommendations for managing policies

留意すべきいくつかの指摘とヒントを次に示します。Here are a few pointers and tips to keep in mind:

  • 最初は拒否効果ではなく監査効果を使用して、環境内のリソースに対するポリシー定義の影響を追跡します。Start with an audit effect instead of a deny effect to track impact of your policy definition on the resources in your environment. アプリケーションを自動スケーリングするスクリプトが既にある場合、拒否効果を設定すると、このような自動化タスクが妨げられる場合があります。If you have scripts already in place to autoscale your applications, setting a deny effect may hinder such automation tasks already in place.

  • 定義と割り当てを作成するときは、組織階層を考慮します。Consider organizational hierarchies when creating definitions and assignments. 管理グループやサブスクリプション レベルのような高いレベルで定義を作成することをお勧めします。We recommend creating definitions at higher levels such as the management group or subscription level. それから、次の子レベルで割り当てを作成します。Then, create the assignment at the next child level. 管理グループで定義を作成した場合、その管理グループ内にあるサブスクリプションまたはリソース グループまで割り当ての対象にできます。If you create a definition at a management group, the assignment can be scoped down to a subscription or resource group within that management group.

  • 1 つのポリシー定義の場合でも、イニシアチブ定義を作成して割り当てることをお勧めします。We recommend creating and assigning initiative definitions even for a single policy definition. たとえば、ポリシー定義 policyDefA をイニシアチブ定義 initiativeDefC の下に作成します。For example, you have policy definition policyDefA and create it under initiative definition initiativeDefC. 後で policyDefA に似た目標の別のポリシー定義 policyDefB を作成する場合、それを initiativeDefC の下に追加して、まとめて追跡できます。If you create another policy definition later for policyDefB with goals similar to policyDefA, you can add it under initiativeDefC and track them together.

  • イニシアチブ割り当てを作成してあると、そのイニシアチブに追加されたポリシー定義もそのイニシアチブ割り当ての一部になります。Once you've created an initiative assignment, policy definitions added to the initiative also become part of that initiatives assignments.

  • イニシアチブ割り当てが評価されたときは、イニシアチブ内のすべてのポリシーも評価されます。When an initiative assignment is evaluated, all policies within the initiative are also evaluated. ポリシーを個別に評価する必要がある場合は、ポリシーをイニシアティブに含めないことをお勧めします。If you need to evaluate a policy individually, it's better to not include it in an initiative.

Azure Policy のオブジェクトAzure Policy objects

ポリシー定義Policy definition

Azure Policy でポリシーを作成して実装する手順は、ポリシー定義の作成から始まります。The journey of creating and implementing a policy in Azure Policy begins with creating a policy definition. すべてのポリシー定義に、ポリシーが適用される条件があります。Every policy definition has conditions under which it's enforced. また、条件が満たされた場合に実現される効果も定義されています。And, it has a defined effect that takes place if the conditions are met.

Azure Policy には、既定で使うことができる組み込みポリシーがいくつかあります。In Azure Policy, we offer several built-in policies that are available by default. 次に例を示します。For example:

  • 許可されているストレージ アカウントの SKU (拒否):展開されているストレージ アカウントが SKU サイズの設定内であるかどうかを判断します。Allowed Storage Account SKUs (Deny): Determines if a storage account being deployed is within a set of SKU sizes. その効果として、定義されている SKU サイズの設定に準拠していないすべてのストレージ アカウントが拒否されます。Its effect is to deny all storage accounts that don't adhere to the set of defined SKU sizes.
  • 使用できるリソースの種類 (拒否):展開できるリソースの種類を定義します。Allowed Resource Type (Deny): Defines the resource types that you can deploy. その効果として、この定義済みリストの一部ではないすべてのリソースが拒否されます。Its effect is to deny all resources that aren't part of this defined list.
  • 許可されている場所 (拒否):新しいリソースに使用できる場所を制限します。Allowed Locations (Deny): Restricts the available locations for new resources. その効果は、geo コンプライアンス要件を強制するために使用されます。Its effect is used to enforce your geo-compliance requirements.
  • 許可されている仮想マシン SKU (拒否):展開できる仮想マシンの SKU の設定を指定します。Allowed Virtual Machine SKUs (Deny): Specifies a set of virtual machine SKUs that you can deploy.
  • リソースへのタグの追加 (変更):展開要求によって指定されていない場合に、必要なタグとその既定値を適用します。Add a tag to resources (Modify): Applies a required tag and its default value if it's not specified by the deploy request.
  • タグとその既定値の追加 (追加):必要なタグとその値をリソースに適用します。Append tag and its default value (Append): Enforces a required tag and its value to a resource.
  • 許可されていないリソースの種類 (拒否):リストのリソースの種類が展開されないようにします。Not allowed resource types (Deny): Prevents a list of resource types from being deployed.

これらのポリシー定義 (組み込み定義とカスタム定義の両方) を実装するには、割り当てを行う必要があります。To implement these policy definitions (both built-in and custom definitions), you'll need to assign them. こうしたポリシーを割り当てるには、Azure Portal、PowerShell、または Azure CLI を使用します。You can assign any of these policies through the Azure portal, PowerShell, or Azure CLI.

ポリシーの割り当てやポリシーの更新など、いくつかの異なるアクションでポリシーの評価が行われます。Policy evaluation happens with several different actions, such as policy assignment or policy updates. 完全な一覧については、「Policy evaluation triggers」(ポリシー評価のトリガー) をご覧ください。For a complete list, see Policy evaluation triggers.

ポリシー定義の構造の詳細については、ポリシー定義の構造に関するページを参照してください。To learn more about the structures of policy definitions, review Policy Definition Structure.

ポリシー パラメーターは、作成する必要があるポリシー定義の数を減らしてポリシーの管理を簡素化するのに役立ちます。Policy parameters help simplify your policy management by reducing the number of policy definitions you must create. ポリシー定義を作成するときにパラメーターを定義して、ポリシー定義を汎用化できます。You can define parameters when creating a policy definition to make it more generic. その後、そのポリシー定義を、さまざまなシナリオで再利用できます。Then you can reuse that policy definition for different scenarios. これを行うには、ポリシー定義を割り当てるときに、さまざまな値を渡します。You do so by passing in different values when assigning the policy definition. たとえば、サブスクリプションに対して一連の場所を指定します。For example, specifying one set of locations for a subscription.

パラメーターは、ポリシー定義を作成するときに定義します。Parameters are defined when creating a policy definition. パラメーターを定義するときは、名前と、必要に応じて値を指定します。When a parameter is defined, it's given a name and optionally given a value. たとえば、"場所" というポリシーのパラメーターを定義できます。For example, you could define a parameter for a policy titled location. その後、ポリシーを割り当てるときに、EastUSWestUS など、さまざまな値を指定できます。Then you can give it different values such as EastUS or WestUS when assigning a policy.

ポリシー パラメーターについて詳しくは、定義の構造でのパラメーターに関する項目をご覧ください。For more information about policy parameters, see Definition structure - Parameters.

イニシアチブ定義Initiative definition

イニシアチブ定義は、単一の包括的なゴールを達成することを目的として調整されたポリシー定義のコレクションです。An initiative definition is a collection of policy definitions that are tailored towards achieving a singular overarching goal. イニシアチブ定義により、ポリシー定義の管理と割り当てが簡素化されます。Initiative definitions simplify managing and assigning policy definitions. 簡素化するには、一連のポリシーを 1 つのアイテムとしてグループ化します。They simplify by grouping a set of policies as one single item. たとえば、Azure Security Center で利用可能なすべてのセキュリティ推奨事項を監視することを目的とする、"Azure Security Center での監視を有効にする" というタイトルのイニシアチブを作成できます。For example, you could create an initiative titled Enable Monitoring in Azure Security Center, with a goal to monitor all the available security recommendations in your Azure Security Center.

注意

Azure CLI や Azure PowerShell などの SDK では、PolicySet という名前のプロパティとパラメーターを使用して、イニシアチブを参照します。The SDK, such as Azure CLI and Azure PowerShell, use properties and parameters named PolicySet to refer to initiatives.

このイニシアチブでは、次のようなポリシー定義を作成します。Under this initiative, you would have policy definitions such as:

  • 暗号化されていない SQL Database を Security Center で監視する – 暗号化されていない SQL データベースとサーバーを監視します。Monitor unencrypted SQL Database in Security Center – For monitoring unencrypted SQL databases and servers.
  • OS の脆弱性を Security Center で監視する – 構成されているベースラインを満たしていないサーバーを監視します。Monitor OS vulnerabilities in Security Center – For monitoring servers that don't satisfy the configured baseline.
  • 不足している Endpoint Protection を Security Center で監視する – Endpoint Protection エージェントがインストールされていないサーバーを監視します。Monitor missing Endpoint Protection in Security Center – For monitoring servers without an installed endpoint protection agent.

ポリシー パラメーターと同様に、イニシアチブ パラメーターは冗長性を減らすことでイニシアチブの管理を簡素化できます。Like policy parameters, initiative parameters help simplify initiative management by reducing redundancy. イニシアチブ パラメーターは、イニシアチブ内のポリシー定義によって使われるパラメーターです。Initiative parameters are parameters being used by the policy definitions within the initiative.

たとえば、イニシアチブ定義 initiativeC にポリシー定義 policyApolicyB が含まれており、それぞれのポリシー定義が異なる種類のパラメーターを予期しているというシナリオについて考えてみましょう。For example, take a scenario where you have an initiative definition - initiativeC, with policy definitions policyA and policyB each expecting a different type of parameter:

ポリシーPolicy パラメーターの名前Name of parameter パラメーターの型Type of parameter NoteNote
policyApolicyA allowedLocationsallowedLocations arrayarray このパラメーターは、パラメーターの型が配列として定義されているため、文字列のリストが値として必要です。This parameter expects a list of strings for a value since the parameter type has been defined as an array
policyBpolicyB allowedSingleLocationallowedSingleLocation stringstring このパラメーターは、パラメーターの型が文字列として定義されているため、1 つの単語が値として必要です。This parameter expects one word for a value since the parameter type has been defined as a string

このシナリオで initiativeC のイニシアチブ パラメーターを定義する場合、3 つのオプションがあります。In this scenario, when defining the initiative parameters for initiativeC, you have three options:

  • このイニシアチブ内でポリシー定義のパラメーターを使用します。この例では、allowedLocationsallowedSingleLocationinitiativeC のイニシアチブ パラメーターになります。Use the parameters of the policy definitions within this initiative: In this example, allowedLocations and allowedSingleLocation become initiative parameters for initiativeC.
  • このイニシアチブ定義内でポリシー定義のパラメーターに値を指定します。Provide values to the parameters of the policy definitions within this initiative definition. この例では、policyA のパラメーター – allowedLocations および policyB のパラメーター – allowedSingleLocation に場所のリストを提供できます。In this example, you can provide a list of locations to policyA's parameter – allowedLocations and policyB's parameter – allowedSingleLocation. このイニシアチブを割り当てるときに値を指定することもできます。You can also provide values when assigning this initiative.
  • このイニシアチブを割り当てるときに使うことができる "" オプションのリストを指定します。Provide a list of value options that can be used when assigning this initiative. このイニシアチブを割り当てるときは、イニシアチブ内のポリシー定義から継承したパラメーターは、この指定されたリストの値だけを持つことができます。When you assign this initiative, the inherited parameters from the policy definitions within the initiative, can only have values from this provided list.

イニシアチブ定義で値のオプションを作成すると、イニシアチブの割り当てで別の値を入力することは、リストの一部ではないためできません。When creating value options in an initiative definition, you're unable to input a different value during the initiative assignment because it's not part of the list.

イニシアチブ定義の構造の詳細については、イニシアチブ定義の構造に関するページを参照してください。To learn more about the structures of initiative definitions, review Initiative Definition Structure.

代入Assignments

割り当ては、特定のスコープ内で実行するように割り当てられたポリシーの定義またはイニシアチブです。An assignment is a policy definition or initiative that has been assigned to take place within a specific scope. このスコープの範囲は、管理グループから個々のリソースまでです。This scope could range from a management group to an individual resource. "スコープ" という用語は、定義が割り当てられる、すべてのリソース、リソース グループ、サブスクリプション、または管理グループのことを指します。The term scope refers to all the resources, resource groups, subscriptions, or management groups that the definition is assigned to. 割り当ては、すべての子リソースによって継承されます。Assignments are inherited by all child resources. この設計は、リソース グループに適用された定義が、そのリソース グループ内のリソースにも適用されることを意味します。This design means that a definition applied to a resource group is also applied to resources in that resource group. ただし、サブスコープを割り当てから除外できます。However, you can exclude a subscope from the assignment.

たとえば、サブスクリプション スコープで、ネットワーク リソースの作成を禁止する定義を割り当てることができます。For example, at the subscription scope, you can assign a definition that prevents the creation of networking resources. ネットワーク インフラストラクチャを対象としたリソース グループを、そのサブスクリプション内で除外できます。You could exclude a resource group in that subscription that is intended for networking infrastructure. その後、このネットワーク リソース グループへのアクセスは、信頼できるユーザーに許可し、そのユーザーがネットワーク リソースを作成できるようにします。You then grant access to this networking resource group to users that you trust with creating networking resources.

別の例として、リソースの種類の許可リスト定義を管理グループ レベルで割り当てたいとしましょう。In another example, you might want to assign a resource type allow list definition at the management group level. そのうえで、より制限の緩やかな (より多くのリソースの種類を許可する) ポリシーを子管理グループまたはサブスクリプションに直接割り当てます。Then you assign a more permissive policy (allowing more resource types) on a child management group or even directly on subscriptions. しかし、この例はうまくいきません。Azure Policy は明示的な拒否のシステムであるためです。However, this example wouldn't work because Azure Policy is an explicit deny system. 代わりに、管理グループレベルの割り当てから、子管理グループまたはサブスクリプションを除外する必要があります。Instead, you need to exclude the child management group or subscription from the management group-level assignment. そのうえで、より制限の緩やかな定義を子管理グループまたはサブスクリプション レベルで割り当てます。Then, assign the more permissive definition on the child management group or subscription level. いずれかの割り当てでリソースが拒否される場合、拒否割り当てに変更を加えることが、そのリソースを許可する唯一の方法となります。If any assignment results in a resource getting denied, then the only way to allow the resource is to modify the denying assignment.

ポータルを使用した割り当ての設定の詳細については、ポリシー割り当てを作成し、Azure 環境内の準拠していないリソースを特定する方法に関するページを参照してください。For more information on setting assignments through the portal, see Create a policy assignment to identify non-compliant resources in your Azure environment. PowerShellAzure CLI の場合の手順も利用することができます。Steps for PowerShell and Azure CLI are also available. 割り当て構造の詳細については、割り当て構造に関するページを参照してください。For information on the assignment structure, see Assignments Structure.

Azure Policy オブジェクトの最大数Maximum count of Azure Policy objects

Azure Policy では、オブジェクトの種類ごとに最大数があります。There's a maximum count for each object type for Azure Policy. Scope というエントリは、サブスクリプションまたは管理グループのいずれかを意味します。An entry of Scope means either the subscription or the management group.

WhereWhere 対象What 最大数Maximum count
ScopeScope ポリシーの定義Policy definitions 500500
ScopeScope イニシアチブ定義Initiative definitions 100100
TenantTenant イニシアチブ定義Initiative definitions 2,5002,500
ScopeScope ポリシーとイニシアティブの割り当てPolicy or initiative assignments 100100
ポリシー定義Policy definition パラメーターParameters 2020
イニシアチブ定義Initiative definition ポリシーPolicies 100100
イニシアチブ定義Initiative definition パラメーターParameters 100100
ポリシーとイニシアティブの割り当てPolicy or initiative assignments 除外 (notScopes)Exclusions (notScopes) 400400
ポリシー規則Policy rule 入れ子になった条件Nested conditionals 512512
修復タスクRemediation task リソースResources 500500

次のステップNext steps

これで、Azure Policy の概要といくつかの主要な概念に関する説明は終了です。推奨される次の手順は以下のとおりです。Now that you have an overview of Azure Policy and some of the key concepts, here are the suggested next steps: