リソース ポリシーの概要

リソース ポリシーを使用すると、組織内のリソースの規則を確立することができます。 規則を定義することによって、コストを制御し、リソースをより簡単に管理することができます。 たとえば、特定の種類の仮想マシンのみが許可されるように指定したり、すべてのリソースに特定のタグが付けられることを要求したりすることができます。 ポリシーは、すべての子リソースが継承します。 したがって、リソース グループに適用されたポリシーは、そのリソース グループのすべてのリソースに適用されます。

ポリシーについて理解するための概念は、次の 2 つです。

  • ポリシー定義 - いつポリシーが適用され、どのようなアクションが行われるかを記述します
  • ポリシー割り当て - ポリシー定義をスコープ (サブスクリプションまたはリソース グループ) に適用します

このトピックでは、ポリシー定義を中心に説明します。 ポリシー割り当ての詳細については、「Use Azure portal to assign and manage resource policies」(Azure Portal によるリソース ポリシーの割り当てと管理) または「Assign and manage policies through script」(リソース ポリシーの割り当てと管理) を参照してください。

Azure には、いくつかの組み込みのポリシー定義が用意されているので、定義が必要なポリシーの数を減らすことができます。 組み込みのポリシー定義が目的のシナリオでうまく機能する場合は、スコープに割り当てる際にその定義を使用します。

リソースの作成と更新 (PUT 操作と PATCH 操作) を行うときに、ポリシーが評価されます。

注意

現時点では、タグ、種類、場所をサポートしていない、Microsoft.Resources/deployments のようなリソースの種類は、ポリシーによる評価の対象となりません。 このサポートは、今後追加される予定です。 下位互換性の問題を回避するためには、ポリシーの作成時に種類を明示的に指定する必要があります。 たとえば、種類が指定されていないタグ ポリシーは、すべての種類に適用されます。 そのような場合、タグをサポートしていない入れ子になったリソースがあり、デプロイ リソースの種類がポリシーの評価に追加されていると、テンプレートのデプロイに失敗する可能性があります。

RBAC との違いは何か。

ポリシーとロールベースのアクセス制御 (RBAC) には、いくつかの主要な違いがあります。 RBAC は、さまざまなスコープでのユーザーの操作に焦点を当てています。 たとえば、目的のスコープでリソース グループの共同作成者ロールに追加されると、そのリソース グループに変更を加えられるようになります。 ポリシーは、デプロイ中のリソース プロパティに焦点を当てます。 たとえば、ポリシーを介して、プロビジョニング可能なリソースの種類を制御したり、リソースをプロビジョニングできる場所を制限したりできます。 RBAC とは異なり、ポリシーは既定で許可し、明示的に否認するシステムです。

ポリシーを使用するには、RBAC で認証される必要があります。 具体的には、アカウントには次のものが必要です。

  • ポリシーを定義するための Microsoft.Authorization/policydefinitions/write アクセス許可
  • ポリシーを割り当てるための Microsoft.Authorization/policyassignments/write アクセス許可

これらのアクセス許可は、共同作成者ロールには含まれていません。

ポリシー定義の構造

ポリシー定義を作成するには、JSON を使用します。 ポリシー定義には、以下のものに対する要素が含まれています。

  • parameters
  • 表示名
  • description
  • ポリシー規則
    • 論理評価
    • 効果

次の例は、リソースがデプロイされる場所を制限するポリシーを示しています。

{
  "properties": {
    "parameters": {
      "allowedLocations": {
        "type": "array",
        "metadata": {
          "description": "The list of locations that can be specified when deploying resources",
          "strongType": "location",
          "displayName": "Allowed locations"
        }
      }
    },
    "displayName": "Allowed locations",
    "description": "This policy enables you to restrict the locations your organization can specify when deploying resources.",
    "policyRule": {
      "if": {
        "not": {
          "field": "location",
          "in": "[parameters('allowedLocations')]"
        }
      },
      "then": {
        "effect": "deny"
      }
    }
  }
}

パラメーター

パラメーターを使用すると、ポリシー定義の数を減らすことで、ポリシーの管理を単純化できます。 リソース プロパティに対してポリシーを定義し (リソースをデプロイできる場所を制限するなど)、定義にパラメーターを含めます。 その後、そのポリシー定義を別のシナリオで再利用する場合は、ポリシーを割り当てるときに別の値を渡します (サブスクリプションに対する 1 組の場所を指定するなど)。

パラメーターは、ポリシーの定義を作成するときに宣言します。

"parameters": {
  "allowedLocations": {
    "type": "array",
    "metadata": {
      "description": "The list of allowed locations for resources.",
      "displayName": "Allowed locations"
    }
  }
}

パラメーターの型は、文字列または配列のどちらも可能です。 メタデータ プロパティは、Azure Portal などでわかりやすい情報を表示するために使用されます。

ポリシー規則では、次の構文でパラメーターを参照します。

{ 
    "field": "location",
    "in": "[parameters('allowedLocations')]"
}

表示名と説明

ポリシー定義を識別し、使用される際のコンテキストを指定するには、displayNamedescription を使用します。

ポリシー規則

ポリシー規則は、IfThen ブロックで構成されています。 If ブロックでは、いつポリシーが適用されるかを指定する、1 つ以上の条件を定義します。 これらの条件に論理演算子を適用して、ポリシーのシナリオを細かく定義することができます。 Then ブロックでは、If 条件が満たされる場合に生じる効果を定義します。

{
  "if": {
    <condition> | <logical operator>
  },
  "then": {
    "effect": "deny | audit | append"
  }
}

論理演算子

サポートされている論理演算子は、次のとおりです。

  • "not": {condition or operator}
  • "allOf": [{condition or operator},{condition or operator}]
  • "anyOf": [{condition or operator},{condition or operator}]

not 構文は、条件の結果を反転します。 allOf 構文 (And 論理演算に似ています) では、すべての条件が真である必要があります。 anyOf 構文 (Or 論理演算に似ています) では、1 つ以上の条件が真である必要があります。

論理演算子は、入れ子にすることができます。 次の例は、And 演算内で入れ子になっている Not 演算を示しています。

"if": {
  "allOf": [
    {
      "not": {
        "field": "tags",
        "containsKey": "application"
      }
    },
    {
      "field": "type",
      "equals": "Microsoft.Storage/storageAccounts"
    }
  ]
},

条件

条件は、フィールドが特定の基準を満たすかどうかを評価します。 サポートされている条件は次のとおりです。

  • "equals": "value"
  • "like": "value"
  • "match": "value"
  • "contains": "value"
  • "in": ["value1","value2"]
  • "containsKey": "keyName"
  • "exists": "bool"

like 条件を使用する場合は、値にワイルドカード (*) を指定することができます。

match 条件を使うときは、任意の数字を表す # や任意の文字を表す ? のほか、具体的な文字を指定することができます。 その例については、「命名規則の設定」を参照してください。

フィールド

条件は、フィールドを使用して構成されます。 フィールドは、リソースの状態の記述に使用されるリソース要求ペイロード内のプロパティを表します。

次のフィールドがサポートされています。

  • name
  • kind
  • type
  • location
  • tags
  • tags.*
  • プロパティのエイリアス

リソースの種類に固有のプロパティにアクセスするには、プロパティのエイリアスを使用します。 サポートされているエイリアスは次のとおりです。

  • Microsoft.CDN/profiles/sku.name
  • Microsoft.Compute/virtualMachines/imageOffer
  • Microsoft.Compute/virtualMachines/imagePublisher
  • Microsoft.Compute/virtualMachines/sku.name
  • Microsoft.Compute/virtualMachines/imageSku
  • Microsoft.Compute/virtualMachines/imageVersion
  • Microsoft.SQL/servers/databases/edition
  • Microsoft.SQL/servers/databases/elasticPoolName
  • Microsoft.SQL/servers/databases/requestedServiceObjectiveId
  • Microsoft.SQL/servers/databases/requestedServiceObjectiveName
  • Microsoft.SQL/servers/elasticPools/dtu
  • Microsoft.SQL/servers/elasticPools/edition
  • Microsoft.SQL/servers/version
  • Microsoft.Storage/storageAccounts/accessTier
  • Microsoft.Storage/storageAccounts/enableBlobEncryption
  • Microsoft.Storage/storageAccounts/sku.name
  • Microsoft.Web/serverFarms/sku.name

効果

ポリシーでは、denyauditappend の 3 種類の効果がサポートされています。

  • deny は監査ログでイベントを生成し、要求は失敗します
  • audit は監査ログで警告イベントを生成しますが、要求は失敗しません
  • append は定義済みのフィールド セットを要求に追加します

append の場合、次のように詳細を指定する必要があります。

"effect": "append",
"details": [
  {
    "field": "field name",
    "value": "value of the field"
  }
]

値には文字列または JSON 形式オブジェクトを指定できます。

ポリシーの例

以下のトピックに、ポリシーの例があります。

許可されるリソースの場所

どの場所が許可されるかを指定するには、「ポリシー定義の構造」セクションの例を参照してください。 このポリシー定義を割り当てるには、リソース ID が /providers/Microsoft.Authorization/policyDefinitions/e56962a6-4747-49cd-b67b-bf8b01975c4c の組み込みポリシーを使用します。

許可されないリソースの場所

どの場所が許可されないかを指定するには、次のポリシー定義を使用します。

{
  "properties": {
    "parameters": {
      "notAllowedLocations": {
        "type": "array",
        "metadata": {
          "description": "The list of locations that are not allowed when deploying resources",
          "strongType": "location",
          "displayName": "Not allowed locations"
        }
      }
    },
    "displayName": "Not allowed locations",
    "description": "This policy enables you to block locations that your organization can specify when deploying resources.",
    "policyRule": {
      "if": {
        "field": "location",
        "in": "[parameters('notAllowedLocations')]"
      },
      "then": {
        "effect": "deny"
      }
    }
  }
}

許可されるリソースの種類

次の例は、種類が Microsoft.Resources、Microsoft.Compute、Microsoft.Storage、Microsoft.Network であるリソースのみのデプロイを許可するポリシーを示しています。 他はすべて拒否されます。

{
  "if": {
    "not": {
      "anyOf": [
        {
          "field": "type",
          "like": "Microsoft.Resources/*"
        },
        {
          "field": "type",
          "like": "Microsoft.Compute/*"
        },
        {
          "field": "type",
          "like": "Microsoft.Storage/*"
        },
        {
          "field": "type",
          "like": "Microsoft.Network/*"
        }
      ]
    }
  },
  "then": {
    "effect": "deny"
  }
}

命名規則の設定

次の例では、like の条件でサポートされているワイルドカードが使用されています。 この条件は、名前が指定のパターン (namePrefix*nameSuffix) と一致する場合、要求を拒否するように指定しています。

{
  "if": {
    "not": {
      "field": "name",
      "like": "namePrefix*nameSuffix"
    }
  },
  "then": {
    "effect": "deny"
  }
}

特定のパターンと一致するリソース名を指定するには、match 条件を使います。 次の例は、contoso で始まりその後に 6 つの文字が続く名前と一致します。

{
  "if": {
    "not": {
      "field": "name",
      "match": "contoso??????"
    }
  },
  "then": {
    "effect": "deny"
  }
}

2 桁の数字 + ダッシュ + 3 つの文字 + ダッシュ + 4 桁の数字から成る日付パターンは、次のように入力します。

{
  "if": {
    "field": "tags.date",
    "match": "##-???-####"
  },
  "then": {
    "effect": "deny"
  }
}

次のステップ