🤖

Azure Policyの基本のキ（定義の読み方）

2021/05/28に公開

Azure

policy

tech

はじめに

Azureでセキュリティを担保する機能の一つとして、Azure Policyという機能があります。
Security Centerなどでも使われていて、下の記事でも軽く触れたことがあるのですが、

とても大事かつ基本となる機能にもかかわらず、使いこなそうと思うと細かいところがなかなか難しい…。結局、Azure Policyって何ができるのかよくわからないんだよね！という声をよく聞きます。
ということで、Azure Policyについてポイントを書いていこうと思います。

Azure Policyとは

Azureポリシーは、リソースの設定状態の良し悪しを事前に定義し、違反した場合に警告、あるいは違反ができないように禁止してくれるサービスです。
よく例にあがるのは「Storage Accountは特定のリージョンにのみ、作ってよい」だとか「SQL Databaseでは透過的暗号化（TDE）が有効でなければならない」だとか。リソースはこうあるべきだ／こうなってはいけない、を定義して監視します。

AWSでいうところのConfigルールみたいなサービスですね。

普通の権限（Azure RBAC）の考え方はまず「ユーザー"xxxxxxx@xxxxxxx.onmicrosoft.com"」は「ストレージアカウントを作ってよい／ダメ」とか「SQL Databaseを起動してよい／ダメ」といったことを制御するのに対して、Azureポリシーはリソース側の状態を制御するのが特徴です。
言い換えると、普通の権限は主語「ユーザーなどのプリンシパル」が何をやって良いかを定義するのに対して、Azure Policyでは主語「リソース」がどういう状態になって良いのかを定義します。

どちらかだけでセキュリティを担保できるものではなく、組み合わせて制御していくということを抑えましょう。

Policy定義の基本

もともと、Azure公式の組み込みのポリシーが大量に登録されており、有効化するだけで使える状態になっているポリシーが多くあります。ただ、何を制御しているか読めるようにならないと守りたいことが守れてるのかわからないので、まずは定義の書き方の基本を抑えます、
また、ポリシーの書き方をマスターすれば、自分で定義を書いて「カスタムポリシー」として利用することもできるので、この定義の読み解き方を「基本のキ」として抑えれば、あとは制御し放題です。

サンプルポリシー

ポリシーはJSONでルールを記述して定義します。その基本構造について、公式ドキュメントで説明されているサンプルを対象に解説します。

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

このポリシーは、
This policy enables you to restrict the locations your organization can specify when deploying resources.
ということで、「事前に許可したリージョン以外にはリソースを作成できない」という効果を持っています。

ポリシー定義の解説

定義の中に出てくる要素は下記の通りです。ぶっちゃけて言えば一番大事なのは「policyRule」のところなので、それ以外についてはなんとなく雰囲気でわかってれば十分です。

displayName

登録したポリシーの表示名です。Azureポータル上にこの名前で表示されるので、わかりやすい名前をつけます。

description

displayNameとセットで説明文として表示されます。狭い範囲（環境・メンバー）で使うならこれも適当でもなんとでもなりますが、わかりやすい説明文をつけておきます。

mode

ここは少しわかりづらくなっています。大きく分けて２パターンあります。

Resource Manager のモード

ほとんどのポリシーで「リソースマネージャーのモード」を使います。リソースマネージャーのモード、の中で細かく２つに分かれており、どちらかを指定します。

all: リソースグループ、サブスクリプション、およびすべてのリソースの種類を評価します
indexed: タグと場所をサポートするリソースの種類のみを評価
基本的には「all」を指定しておけば良いのですが、「indexed」を指定するのは、タグ・場所を制御したい場合で、サンプルポリシーがまさにそのパターンです。「all」を指定していてもポリシーとしては動きますが、仮に「場所」や「タグ」をサポートしていないリソースを作成する場合に不都合が出ます。「indexed」を指定しておけばスルーしてくるれるのに対し、「all」を指定していると無理やり評価してしまい、 NGと判定されてしまう…という動きをします。。。

リソースプロバイダーのモード

リソースプロバイダーのモードでは、ARMで直接管理していない一部のリソースを制御することができます。リソースマネージャーのモードに比べて、後から出てきた機能のため、あまりまだ充実していません。
2021年5月現在、正式にサポートされているのは「ubernetes クラスターを管理するための Microsoft.Kubernetes.Data」のみで、プレビューとして「AKSのアドミッションコントローラー規則を管理するための Microsoft.ContainerService.Data」「KeyVaultでコンテナーと証明書を管理するためのMicrosoft.KeyVault.Data」の２つがあります。
リソースレイヤと、データレイヤで操作がわかれているようなリソースが対象になってきそうです。この後追加されるとしたら、StorageAccountあたりでしょうか…？

metadata

この項目には、何を入れても良いようです。ただ、組み込みのポリシーではいくつか定番の情報があり、「version」や「preview」といった情報が入っています。

parameters

policyRuleの中で使われる条件を、変数化することができます。サンプルの例で言えば、
「allowedLocations」というパラメータを定義しており、その初期値（default value）として「east us」を指定しています。
Azureポリシーを環境に適用するときに、変数化されている項目に何を入れるか指定・変更することができるのですが、このサンプルポリシーの場合は「リソースを作成できるリージョン」を変数化し、何も指定しなければ「east us」にのみリソースを作成できるという意味になっています。

policyRule

この項目が、Azureポリシーを理解する上での一番のキモになっています。policyRuleはさらに２つのブロックに分かれていて、「if」節と「then」節になっています。

「if」節

リソースを作成したり、設定値を変更した際にAzureポリシーが働き、if節に書かれた条件にマッチするか判定します。サンプルの例で言えば作成したリソースの「location」というパラメータが、allowedLocationsという変数（配列）に含まれていない場合・・・という条件になりますので、「parameters」の項に書いた通り、デフォルトではeast us以外の場合・・・という条件です。

「then」節

if節にマッチしたリソースだった場合、then節に書かれた効果が発動します。
一番基本となる制御は「audit」です。「監査」であるため、if節に引っかかるリソースはポリシー違反として「アクティビティログへの警告の出力」と「ポリシー管理画面での違反の表示」が行われます。
このサンプルにおいては「deny」という制御が書かれており、リソースの作成がdeny（＝拒否）される制御がかかります。よって、「指定したリージョン以外にはリソースが作成できない」という効果になるわけですね。
効果の種類はたくさんあり、どれをどう使いこなすかというだけでまた１記事かけてしまうので、これは次回に回すこととします。

おわりに

Azureポリシーの基本のキとして定義の解説を書きました。この知識をベースとして、policyRuleのif-thenをどう書くか？を深掘りしていきますが、長くなりすぎるのでいったん切りたいと思います。
if節にどういう条件を判定させるか／then節でどういう制御をかけるか、何ができないのか…を抑えておくことがAzureポリシーを使いこなすコツになりますので、次回はそういった話を書いていこうと思います。