🐥

Azure Policy でDenyが効かないパターン（後編）にAppendで対処する

2021/07/06に公開

Azure

policy

compliance

tech

はじめにと振り返り

前回の記事で、Azure PolicyでDeny効果を使いたいのに効かないパターンということで、
「App Service（Web Apps）でhttpsonlyというパラメータをtrueで強制したい」という例を取り上げました。

Azure PolicyでDeny効果を使う場合、AzureポータルからWeb Appsをデプロイする場合、そのリクエストにはhttpsonlyというパラメータが含まれないため、↓のような条件をDenyしてもすり抜けてしまいます。

          {
            "field": "Microsoft.Web/sites/httpsOnly",
            "equals": "false"
          }

ということで今回は「httpsonlyがfalseなAppServiceを作らせない」を目標に対策を考えてみます。

対策

対策案１（対象パラメータの存在チェックを行う）

まず、前回のポリシーを下記のように書き換えるパターンを考えてみます。
1つ目の条件で「httpsonlyがfalseの場合」、又は
2つ目の条件で「httpsonlyパラメータが存在しない場合」にDeny、
という形で制御することができます。

     "policyRule": {
         "if": {
	    "anyOf": [
              {
                "field": "Microsoft.Web/sites/httpsOnly",
                "equals": "false"
              },
              {
                "field": "Microsoft.Web/sites/httpsOnly",
                "exists": "false"
              }
    	    ]
	 }

このように記述することで、
・前者の条件により、Azureポータルからのデプロイ（httpsonlyパラメータが存在しないリクエスト＝httpsonlyがfalseのまま出来上がってしまう）を禁止することができますし、
・後者の条件により、明示的にhttpsonly=falseを指定して、ARMテンプレートなどでデプロイしようとしてもDeny効果が発動することとなります。もちろん、一度デプロイされたWebAppsの設定変更時にも効果がありますね。

以上から、一番守りたい要件である「リソースを危険な状態でデプロイしてしまう」「リソースを危険な状態に設定変更してしまう」ことを防ぐことが可能です。
可能なのですが…この場合は「ポータルからのデプロイが出来ない」ということになってしまいます。皆さんコレ、困りませんか？
インフラを管理する者としては危険なことをさせないのが最優先ですので、開発者に対してガードレールを敷きたいのですが・・・不必要に縛らずに出来るだけ緩いガードレールにしたいものです。

ポチポチっとGUIでリソースなんか作らないよ！全部AzureDevOps使ってCI/CDしてるからね！インフラは全部コード化されてるよ！なんてかっこいいことが言えればいいんですけどね。

対策案２（対象パラメータを強制的に追加する）

ということで、もう少し柔軟に制御したいパターンが対策案２です。Deny効果だと難しいので、Append効果を使います。（少なくとも、私には思いつかなかったので！）

        "policyRule": {
            "if": {
                "field": "type",
                "equals": "Microsoft.Web/sites"
            },
            "then": {
                "effect": "Append",
                "details": [
                    {
                        "field": "Microsoft.Web/sites/httpsOnly",
                        "value": "true"
                    }
                ]
            }
        }

このように、httpsonlyという条件をif節に書くのではなく、then節であるAppend効果の中に記載します。すると、「リクエストにこのパラメータが含まれていなかったら勝手に追加してくれる」「リクエストの中に相反するパラメータが含まれていたら、Deny効果として振る舞ってくれる」という素敵な動き方をします。
この効果であれば、AzureポータルでのGUI操作を過剰に塞ぐことなく、安全に運用できるということですね。

具体的な動きを見てみる

では、対策案②を試してみましょう。下記のAppend効果のポリシーを設定し、AppServiceを作成してみます。

{
    "name": "testappendpolicy",
    "type": "Microsoft.Authorization/policyDefinitions",
    "properties": {
        "displayName": "test-append-policy",
        "policyType": "Custom",
        "mode": "All",
        "description": "HTTPSを使用することを強制します。",
        "metadata": {
            "version":  "1.0.0"
        },
        "parameters": {
            "effect": {
                "type": "String",
                "metadata": {
                    "displayName": "エフェクト",
                    "description": "ポリシーの実行を有効または無効にします"
                },
                "allowedValues": [
                    "Append",
                    "Disabled"
                ],
                "defaultValue": "Append"
            }
        },
        "policyRule": {
            "if": {
                "field": "type",
                "equals": "Microsoft.Web/sites"
            },
            "then": {
                "effect": "[parameters('effect')]",
                "details": [
                    {
                        "field": "Microsoft.Web/sites/httpsOnly",
                        "value": "true"
                    }
                ]
            }
        }
    }
}

この状態でWebAppsを１つデプロイしてみます。前回の記事の通り、ポリシー未設定の状態でデプロイすると、出来上がったリソースの「TLS/SSL の設定」の「HTTPS のみ」がオフとなっていましたが…無事に「HTTPS のみ」がオンになっています！

もちろん、事前に自分で設定したわけではなく、↓のようにAppend効果が働いたことが、アクティビティログにも残っています。

AppendとDenyの使い分け

以上の動きをみると、リクエストに制御対象のパラメータが必ず含まれる場合はDeny効果で良いのですが、逆に含まれない場合はAppend効果を使わないと、意図した制御は難しくなっています。
どのパラメータがリクエストに含まれていて、何が含まれないかはドキュメントなどをあたってみても見当たりませんでしたので、現時点ではおそらく試してみるしか解決方法はありません。
おそらく、CLIやREST APIのドキュメントで必須パラメータになっているかどうかで判断できそうですが…ドキュメントで見当たらない以上、検証してみるしかなさそうです。
DenyやAppend効果でブロックした上で、さらに意図せずすり抜けた場合にも対応できるよう、Audit効果のポリシーなどと組み合わせて、取りこぼしが無いように（防ぎたい設定に気付けるように）しておくことが重要だと思います。

おわりに

Azure PolicyでDeny効果がうまく動かなかったパターンと、それにAppend効果で対処できた話を書きました。
Append効果のポリシーは、ググってもあまり活用例とか解説が見当たらなかったので、この記事に行き着いた皆様の役に立てれば幸いです。こうやればもっとうまく守れるのに〜みたいな話があればぜひ教えてください。