カスタムポリシーの作成手順について

Published: feedback 共有

私たちの要件を満たすカスタムポリシーを作成したいです。

サポートリクエストを起票することで要件を満たすポリシーを作成してくれませんか?

回答

大変恐縮ながら、サポートリクエストでは、

Azure Policy や ARM Template、各種クエリ等の開発依頼を受け付けておりません。

必要に応じてサンプル等のご提供をさせて頂く場合もございますが、

基本的には、製品のご利用方法や仕様などについて公開情報をもととしたご案内をいたしておりまして、

お客様が Azure Policy の定義や ARM テンプレートの作成をするにあたりお役に立つ情報のご提供を行っております。



「カスタムポリシーでの対応を行いたいが、作成方法が分からない」という方も多いかと思います。

本記事では、カスタムポリシーの作成手順についてご案内します。

<Azure Policy の作成の基礎について>

カスタムポリシーの作成方法の大まかな流れは下記の資料が参考になるかと思います。

チュートリアル:カスタム ポリシー定義の作成 - Azure Policy | Microsoft Learn



Azure Policy の構造については下記の資料を一度ご確認下さい。

ポリシー定義の構造の基本の詳細 - Azure Policy | Microsoft Learn



Azure Policy の効果については下記の資料をご確認下さい。

Azure Policy 定義の効果の基本 - Azure Policy | Microsoft Learn



カスタムポリシーを作成する際には、上記の資料、

特に Azure Policy の構造に関する資料と、Azure Policy の効果に関する資料を参照頂きながら、

作業をするケースが多いかと思います。

<ビルトインポリシーについて>

ビルトイン(組み込みの)ポリシーも数多く用意されております。

まずは、目的のポリシーに極力近しいビルトインポリシーを探してみると良いかと思います。

下記の資料では、提供されている組み込みのポリシーが記載されております。

組み込みのポリシー定義の一覧 - Azure Policy | Microsoft Learn



サービスによっては、サービスの資料中にて、そのサービスに関するポリシーをまとめている例もございます。

こちらの方が目的に近いポリシーを探すことが容易かとも思います。

一例として、Azure VM や Azure Storage の場合は下記の様な資料がございました。

Azure Virtual Machines 用の組み込みポリシー定義 - Azure Virtual Machines | Microsoft Learn

Azure Storage 用の組み込みポリシー定義 | Microsoft Learn



監査対象のプロパティが異なっていたとしても、

対象の type など、ある程度は一致する部分があるかとは思いますので、

ビルトインポリシーをひな型として、カスタムポリシーを作成されると良いかと思います。

<カスタムポリシーの作成例について>

下記のWebサイト、”AzAdvertizer” ではカスタムポリシーの作成例を確認することが可能です。

AzPolicyAdvertizer (azadvertizer.net)



AzAdvertizer は Microsoft の従業員によって開発されていますが、

Microsoft のサービスや製品ではないことにご注意ください。

つまり、ここで掲載されているポリシーについてサポートなどは提供されておりません。

また、このサイトの問題や掲載されているポリシーの問題についてはお問い合わせを受け付けておりません。



ご利用者様自身で検証頂く必要はございますが、

より目的に近しいポリシーのひな型が見つかる可能性もございます。

ビルトインポリシーと合わせて、AzPolicyAdvertizer もご確認頂き、

ご希望のポリシーにより近いカスタムポリシーを、

作成されるカスタムポリシーのひな型として選択頂くと良いかと思います。

<エイリアスの確認方法について>

そもそも、Azure Policy はデプロイされる ARM Template、

あるいは既存のリソースの構成を ARM Template で取得することによって、プロパティを確認しています。

プロパティを確認した際に、条件に一致しているかどうかを確認の上、制限している構成に一致していれば、

ポリシーの効果を適用するというものです。



よって、カスタムポリシーを作成する上では、

作成したいリソースの ARM Template のリファレンスもご確認頂くと良いかと思います。

一例として、Azure VM や Azure Storage の ARM Template リファレンスを下記に記載します。

Microsoft.Compute/virtualMachines - Bicep, ARM template & Terraform AzAPI reference | Microsoft Learn

Microsoft.Storage/storageAccounts - Bicep, ARM template & Terraform AzAPI reference | Microsoft Learn



「(対象のサービス名) ARM Template リファレンス」

などと検索頂くと、上記の様なリファレンスがご確認頂けるかと思います。



上述のビルトインポリシーや ARM Template リファレンスから、

対象のリソースのタイプを特定します。

例)Microsoft.Storage/storageAccounts

また、ARM Template リファレンスを確認し、監査したい目的のプロパティのパスを特定します。

例)properties.publicNetworkAccess

対象のプロパティに入る値についても確認しておきます。

例)publicNetworkAccess の場合、’Disabled’ または ‘Enabled’

対象のプロパティのパスを確認しましたが、

実は、Azure Policy の定義において、監査をするプロパティの指定方法は ARM Template と同じパスではなく、

Azure Policy 用のエイリアスが定義されており、このエイリアスを利用して対象の項目を監査します。



エイリアスの確認方法については下記の資料をご確認下さい。

ポリシー定義構造の別名の詳細 - Azure Policy | Microsoft Learn



端的には、例えば Azure Storage のエイリアスの場合、

下記の様なPowershellコマンドでご確認頂くことが可能です。

1
2
$allAliases = Get-AzPolicyAlias -NamespaceMatch 'Microsoft.storage' -ResourceTypeMatch 'storageAccounts'
$allAliases.Aliases

エイリアスの中から、上記の例に挙げたような、

properties.publicNetworkAccess を監査するためのエイリアスを探すと、

Microsoft.Storage/storageAccounts/publicNetworkAccess

image-5431be42-f4d8-4f48-adad-2a12742276a9.png

であることが分かります。

なお、エイリアスが提供されていない場合もございます。

その場合はそのプロパティを監査するカスタムポリシーを作成することができません。


<実際に作成してみる>

以上がカスタムポリシーを作成する際のヒントとなりますが、

最後に、実際にカスタムポリシーを作成してみます。



今回は、Azure Storage のポリシーを作成してみます。

「ストレージアカウントのSKUを制限しつつ、ストレージアカウントのパブリックネットワークアクセスも制限したい」

という想定で、

「ストレージアカウントの SKU が許可されたものではない、またはパブリックネットワークアクセスが有効になっていたら、作成や更新を拒否する」

というカスタムポリシーを作成してみます。



まずはひな型となるポリシーを探してみます。

下記のポリシーが目的のポリシーに近そうです。



「ストレージ アカウントを許可されている SKU で制限する必要がある」

(/providers/Microsoft.Authorization/policyDefinitions/7433c107-6db4-4ad1-b57a-a76dce0154a1)



ここに、

「またはパブリックネットワークアクセスが有効になっていたら」

という条件を追加する方針でカスタムポリシーを作ります。

パブリックネットワークアクセスを設定している Azure Storage 上のプロパティは、

“エイリアスの確認方法について” の章に記載した方法で確認をすると、

properties.publicNetworkAccess

であることが分かります。また、その項目を監査するためのエイリアスは、

Microsoft.Storage/storageAccounts/publicNetworkAccess

でした。

よって、ポリシー定義の条件に、

「”Microsoft.Storage/storageAccounts/publicNetworkAccess” が、Enabled であれば」

という条件を追加すればよいことが分かります。



複数の条件を取り入れる際には、allOf、または anyOf を利用してルールを定義します。

詳細は下記の資料をご参照下さい。

ポリシー定義の構造ポリシー ルールの詳細 - Azure Policy | Microsoft Learn



簡潔には、allOf は論理式で言う”AND”、文章で表現するところの “かつ” であり、

anyOf は論理式で言う”OR”、文章で表現するところの “または” に該当します。



これらのことを踏まえて、

「ストレージアカウントの SKU が許可されたものではない、またはパブリックネットワークアクセスが有効になっていたら」

という条件は、Azure Policy の条件としては下記の3つの条件に分解できます。

  1. リソースのタイプが “Microsoft.StorageAccounts” である
  2. “Microsoft.Storage/storageAccounts/sku.name” が許可された SKU に当てはまらない
  3. “Microsoft.Storage/storageAccounts/publicNetworkAccess” が、Enabledである

1、2は既に発見しているビルトインポリシーに記載があるので、その形式を参考にします。

3の条件を1、2とどのようにつなぐと正しいかを考えると、

1 AND (2 OR 3)

であることが分かります。

また「拒否する」という効果は “deny” が該当します。



以上の事から、ビルトインポリシー「ストレージ アカウントを許可されている SKU で制限する必要がある」をもとに、

下記の様なポリシーを作ります。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
{
"mode": "Indexed",
"policyRule": {
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Storage/storageAccounts"
},
{
"anyOf": [
{
"not": {
"field": "Microsoft.Storage/storageAccounts/sku.name",
"in": "[parameters('listOfAllowedSKUs')]"
}
},
{
"field": "Microsoft.Storage/storageAccounts/publicNetworkAccess",
"equals": "Enabled"
}
]
}
]
},
"then": {
"effect": "deny"
}
},
"parameters": {
"listOfAllowedSKUs": {
"type": "Array",
"metadata": {
"displayName": "許可されている SKU",
"description": "ストレージ アカウントに指定できる SKU の一覧。",
"strongType": "StorageSKUs"
}
}
}
}

anyOf の中身、及び effect の部分がビルトインポリシーから変更した箇所となります。



=========================



上述の様な流れでカスタムポリシーを作成していきます。

なお、ポリシーは割り当ててから実際に評価を実施して、コンプライアンス結果に反映するまでに時間がかかります。

ポリシーを割り当てた後、明示的に下記の監査を実行するコマンドを実施頂き、

実行完了をお待ち頂くと良いかと思います。

az policy state | Microsoft Learn

Start-AzPolicyComplianceScan (Az.PolicyInsights) | Microsoft Learn



上記の様な流れでカスタムポリシーを作成します。

カスタムポリシーを作成した上で、ご希望のような動作にならない、

という場合にはサポートリクエストを起票頂き、作成されたカスタムポリシーと共にお問い合わせ頂けますと幸いです。

参考ドキュメント

Policy 作成のヒント集 - Japan PaaS Support Team Blog (azure.github.io)






2024 年 7 月 18 日時点の内容となります。

本記事の内容は予告なく変更される場合がございますので予めご了承ください。



※本情報の内容(添付文書、リンク先などを含む)は、作成日時点でのものであり、予告なく変更される場合があります。