DNS セキュリティ ポリシーを使ってみた

検証にあたっての事前準備

まず、今回 DNS セキュリティ ポリシーをリンクする検証環境を作成します。今回は、以下のような検証環境を作成しました。

・リソース グループ
名前 　　　　　: testDNSSecurity

・Azure VM
コンピュータ名 : testDNSSecurity
OS                  : Windows (Windows Server 2022 Datacenter)
サイズ 　　　　: Standard B2ms (2 vcpu 数、8 GiB メモリ)
リージョン 　　: Japan East

・VNet
名前 　　　　　: testDNSSecurity-vnet
リージョン 　　: Japan East

・Log Analytics ワークスペース
名前 　　　　　: testDNSSecurityPolicy-la
リージョン 　　: Japan East

次に、Azure portal を使用して DNS セキュリティ ポリシーを作成します。

まず、Azure portal の [ホーム] ページで DNS セキュリティ ポリシーを検索し、[+ 作成] を選択します。

[基本] タブで、[サブスクリプション] 、 [リソース グループ]、[インスタンス名] 、[リージョン] を設定します。
その際、DNS セキュリティ ポリシーを設定する VNet と同じリージョンに構築する必要があります。
今回は以下のように設定します。
インスタンス名 : testDNSSecurityPolicy
リージョン 　　: Japan East

次に、[仮想ネットワークのリンク] タブで、DNS セキュリティ ポリシーを適用させる VNet を選択します。

[DNSトラフィック規則] のタブで DNS ドメイン リストを作成し、ドメインに対して許可 / 拒否 / アラートの規則を作成します。
今回は、以下のような 2 つのドメイン リストを作成しました。

名前 　　　　　: Deny-testDNSSecurityPolicy
ドメイン名 　　: www.yahoo.co.jp

名前 　　　　　: Alert-testDNSSecurityPolicy
ドメイン名 　　: www.google.co.jp

また、作成したドメイン リストを用いた DNS トラフィックルールを構成し、適用させます。

DNS ログを表示するには、作成した DNS セキュリティ ポリシーで、任意の Log Analytics ワークスペースに診断設定を構成する必要があります。
今回は、診断設定名を "testDNSSecurityPolicy-logs" と設定し、以下のように構成します。

検証前の構築は以上です。

機能検証

まず、検証環境の VM に RDP 接続をし、ドメイン リストに設定していないドメインに対して、名前解決を実行します。

拒否に設定したドメイン "www.yahoo.co.jp" に対しては、対象の IP が表示されないため、拒否ルールが適用されていそうです。

アラートに設定したドメイン "www.google.co.jp" に対しては、対象の IP が表示され、通常の許可された通信と同じように動作しているように見えます。

次に、設定した Log Analytics ワークスペースで DNS ログがどのように表れているのか確認します。

ログを確認すると、実行した全ての名前解決のログが確認できました。

また、ドメイン リストに設定していない名前解決、拒否ルールに設定した名前解決、アラート ルールに設定した名前解決のログは、それぞれ以下のように表記されています。

・ドメイン リストに設定していない名前解決

・拒否ルールに設定した名前解決

・アラート ルールに設定した名前解決

上記の結果から、設定したルールに基づいて以下のように "ResolverPolicyRuleAction" の値が変化することが分かります。

　・名前解決を実行したドメインがドメイン リストに設定されていない場合、 "No Match" と記録される。
　・名前解決を実行したドメインがドメイン リストに拒否ルールとして設定されている場合、"Deny" と記録される。
　・名前解決を実行したドメインがドメイン リストにアラート ルールとして設定されている場合、"None" と記録される。

また、DNS ドメイン リストに「.（ドット）」を設定すると、すべてのドメインを対象とすることになっていました。
この特性を利用して、ドットを含むドメイン リストを「拒否ルール」として設定し、許可したいドメインだけを別のドメイン リストに登録して「許可ルール」として設定することで、ホワイトリスト形式に本機能を利用することができました。

アラート ルールの作成

最後に、アラート ルールとして設定したドメイン リストに関するログが検出した時に、実際にアラートが動作するか検証します。
機能検証の結果から、ドメイン リストにアラート ルールとして設定されているドメインのログが生じた場合、"ResolverPolicyRuleAction" の値が "None" と記録されることがわかりました。
よって、Log Analytics ワークスペースの画面から、以下の画像のような検索クエリに対してアラート ルールを設定します。

また、アラート ロジック、アクション グループは以下のように設定しました。

・アクション グループ
名前 　　　　　: testDNSSecurity-ActionGroup
リージョン 　　: グローバル
通知タイプ 　　: 電子メール

上記の設定の下、アラートに設定したドメイン "www.google.co.jp" に対して再度名前解決を実行し、アラートを動作させてみます。

実行後に設定通り、警告のメールが届きました。

アラートに設定したドメイン リストに関するログが検出した場合でも、Azure Portal 上での表記の変化は見られませんでした。

※ おまけとして、DNS セキュリティ ポリシーがどのような経路のログを収集しているのか調べてみます。
まず新たに VM を 1 台構築し、ドメイン参加することで、設定された DNS サーバーを Azure Provided DNS（IP: 168.63.129.16）から変更します。

先ほどと同様の DNS セキュリティ ポリシーを適用した環境で上記の VM を用いて機能検証したところ、正常に動作しませんでした。

・拒否ルールに設定したドメインに対して名前解決が成功

・Log Analytics ワークスペースにも拒否ルールが実行された形跡なし

本機能は Azure Provided DNS（IP: 168.63.129.16）のログを収集していると考えられ、カスタム DNS を用いる場合は注意が必要です。

まとめ

いかがでしたか。実際に使用してみて感じたメリット/デメリットは以下の通りです。

メリット
・DNS トラフィックのみを、簡単な操作でログ収集できる
・ルールの構成が NSG などと同じ優先度付きルールであり、柔軟な制御が可能

デメリット
・アラート設定はあるが、実際にアラートを動作させるには Log Analytics ワークスペースを用いてアラート ルールを作成する必要があり、運用負荷が高い
・ドメイン情報を自動更新する仕組みがなく全て手動登録であるため、運用負荷が高い

DNS セキュリティ ポリシーは、従来の DNS 監視では難しかった「DNS トラフィックのみの制御」をシンプルに実現できる点で非常に有用です。
一方で、アラート設定やドメイン リスト管理の自動化など、さらなる改善が期待されます。
今後、これらの機能が追加されることで、より使いやすい DNS セキュリティ対策の重要な機能になる可能性があると感じました。