制御不能な暗号化の闇を断つ：SASE環境におけるDoH/DoTの「強制可視化」戦略
ネットワークエンジニアの皆さん、現場でお疲れ様です。最近、こんな「見えない壁」にぶち当たっていませんか？
「SASEでWebフィルタリングを完璧に設定したはずなのに、なぜかユーザーが禁止サイトにアクセスできている」
「DNSログがごっそり抜け落ちていて、フォレンジックが全く役に立たない」
その犯人は、ブラウザの設定一つで簡単に有効化できる DoH (DNS over HTTPS) や DoT (DNS over TLS) です。これらはプライバシー保護の旗印のもと、我々セキュリティ管理者の「監視の目」をくぐり抜けるための強力なトンネルとして悪用されがちです。
今日は、SASEエッジという「戦場」で、この暗号化された通信をどうやって引きずり出し、我々のコントロール下に置くか。その泥臭い実務テクニックを伝授しましょう。
—
なぜDoH/DoTが「セキュリティの穴」になるのか
従来のDNSは UDP/53 で平文通信されていました。これならSASEのエッジやファイアウォールでパケットをキャプチャし、クエリを覗き見るのは容易です。しかし、DoH は TCP/443 を、DoT は TCP/853 を使用します。
SASEの立場から見ると、DoH は「ただのHTTPSトラフィック」と区別がつきません。結果として、ポリシーを回避したユーザーは、SASEのDNSフィルタリングを完全にバイパスして、Google Public DNS (8.8.8.8) や Cloudflare (1.1.1.1) に直接名前解決を投げられてしまうわけです。
SASEエッジでの迎撃：3つの鉄則
SASE環境でこのバイパスを防ぐには、単に「遮断」するだけでなく、インフラ側で「強制」する戦略が必要です。
1. DoT（TCP/853）の強制的破棄
DoT は専用ポート 853 を使うため、検知と遮断は比較的簡単です。SASEのファイアウォールポリシーで、社内ネットワークから外部への TCP/853 を一律で Deny に設定します。これだけで、多くのレガシーなDoTクライアントは沈黙します。
2. DoH（TCP/443）の「識別」と「リダイレクト」
厄介なのは DoH です。これを止めるには、SASEのCASB/SWG（Secure Web Gateway）機能で、既知のDoHプロバイダーのドメインリストをブラックリスト化するのが王道です。
しかし、最近の先進的なSASEプラットフォームでは、さらに踏み込んで 「DoHクエリのインターセプト」 が可能です。ユーザーが https://dns.google/dns-query に向けて投げたパケットをSASE側で横取りし、その中身を解凍して社内のDNS検査エンジンに流し込む。これが現代のエンタープライズセキュリティの標準解です。
3. Canary Domainによる無効化（ブラウザ制御）
ブラウザ側で「自分は今、保護されたネットワークにいる」と認識させるために、特定のドメイン（use-application-dns.net など）に対するDNSクエリの結果を操作し、ブラウザのDoH機能を自動的にオフにする仕組みも併用すべきです。
—
実践：検証環境でのデバッグと動作確認
エンジニアとして、まずは自分の環境で「どうやってDoHがバイパスされるか」を再現してみるのが近道です。
PythonによるDoHリクエストのシミュレーション
以下のコードで、SASEを通さない「生」のDoHリクエストを投げることができます。これを実行したとき、SASEのログにクエリ内容が残るかを確認してください。
import requests
# GoogleのDoHエンドポイントを叩く
# AcceptヘッダーでDNSメッセージ形式を指定するのがポイント
url = "https://dns.google/resolve?name=example.com&type=A"
response = requests.get(url, headers={"Accept": "application/dns-json"})
if response.status_code == 200:
# 応答が返ってくれば、SASEのDNSフィルタリングをバイパス成功
print("レスポンス取得成功:", response.json())
else:
print("遮断されたか、通信エラーです")curlによるDoT（TCP/853）の疎通確認
SASEの境界で 853 ポートがブロックされているか確認する最もシンプルなコマンドです。
# タイムアウトが発生すればポリシー適用済み、接続されれば穴があります
curl -v --connect-timeout 5 dns://8.8.8.8:853—
運用保守担当者へのアドバイス
「全遮断」は時に大きな副作用を生みます。特に、開発環境や一部のSaaSが独自のDoHを利用して通信している場合、いきなりブロックすると「インターネットが繋がらない」という阿鼻叫喚のヘルプデスク案件が爆増します。
1. まずはログモード（Audit Mode）で適用する: SASEのログを確認し、どのクライアントがどのDoHプロバイダーを叩いているか、1週間ほどサイレント監視してください。
2. 例外リストの作成: 業務上必要なプロキシやVPNソフトウェアがDoHを使っている場合は、それらの宛先を特定し、ポリシーの例外設定に加えます。
3. ブラウザ設定の強制（GPO/MDM）: ネットワーク側での遮断と並行して、EdgeやChromeのポリシー設定（DNSOverHttpsMode）を「Off」に強制設定するMDM構成プロファイルを配布しましょう。
セキュリティは「イタチごっこ」です。しかし、ネットワークの挙動を深く理解し、パケットの流れを制御できる我々が守りを固めれば、攻撃者や無防備なユーザーの逃げ道は確実に狭まります。
現場の皆さん、設定の変更は慎重に、しかしポリシーの適用は大胆に。また次回の現場でお会いしましょう。
コメント