【入門編】 SASE環境下でのDNS over HTTPS (DoH) / DNS over TLS (DoT) ブロックとセキュリティバイパス対策 – ゼロトラスト＆エンタープライズセキュリティ実践ガイド

こんにちは！ネットワークセキュリティの世界へようこそ。
ゼロトラストやエンタープライズの現場で日々飛び交う「SASE」や「CASB」、そして何やら難しそうな「DoH / DoT」という言葉……。文字を見ただけで「うっ、頭が痛い……」となっていませんか？

大丈夫です！一歩ずつ、身近な例えを交えながら優しく紐解いていきましょう。今回は、現代のセキュリティ担当者が頭を悩ませる「こっそり通信の抜け穴」と、それをピシャリと塞ぐSASEのスマートな仕組みについて解説しますね。

—

1. そもそもDNSってなぁに？（郵便配達にたとえてみよう）

インターネットの世界へ飛び出すとき、私たちは必ず「DNS（Domain Name System）」という仕組みを使っています。

例えば、お友達に手紙を出すときを想像してください。
「東京都〇〇区……」という住所（IPアドレス）が分かっていれば手紙は届きますが、人間は住所の数字の羅列なんて覚えられませんよね。だから「東京タワー」のような分かりやすい名前（ドメイン名）で手紙を出そうとします。

ここで郵便局の窓口の人が登場します。「東京タワーってどこですか？」と聞くと、窓口の人が「あそこは『151.101..〇〇』という住所ですよ！」と教えてくれる。これがDNSの役割です。

従来のDNSは「中身が丸見えのハガキ」だった

昔のDNSは、私たちが「この住所教えて！」と書いたリクエストを、封もせずに普通のハガキで郵便ポスト（DNSサーバー）に投函していました。
そのため、途中の道すがら（社内ネットワークやプロバイダの回線）で、意地悪な郵便配達員（悪いハッカーや、あるいは社員の通信をこっそり覗き見たいシステム）がハガキをペロッと盗み見て、「ほう、この人は今から怪しいサイトに行こうとしているな」と分かってしまう状態だったのです。

「これじゃプライバシーもセキュリティもあったもんじゃない！」ということで登場したのが、通信を暗号化する技術です。それが DoH (DNS over HTTPS) と DoT (DNS over TLS) です。

—

2. 困った進化：DoH/DoTがセキュリティの「抜け穴」になる理由

通信を暗号化して覗き見を防ぐなんて、素晴らしいことですよね。でも、これが企業のセキュリティ担当者にとっては頭痛の種になります。

先ほどの郵便配達の例で考えてみましょう。
DoHやDoTを使うと、宛先を教てもらうやり取りが「頑丈な鍵付きの金庫（HTTPSやTLSという暗号化技術）」の中にすっぽり隠されてしまいます。

従来のDNS: ハガキだから、学校や会社の門番（企業のファイアウォールやDNSフィルター）が「お、生徒手帳に載ってない危ない場所宛ての手紙だな。没収！」とチェックできた。
DoH / DoT: 頑丈な金庫に入っているため、門番には「何か重い箱が行き来しているな」としか分からない。中身が見えないから、危険なサイト宛ての手紙であっても、そのままスルーして通してしまう。

「会社で禁止されているギャンブルや海外の怪しいサイトに行きたいな」と思った従業員が、このDoH/DoT対応のブラウザ設定をオンにすると、企業の監視の目をすり抜けて自由にアクセスできてしまう――。これが、インフラエンジニアたちが頭を抱える「セキュリティバイパス問題」です。

ここで登場するのが、次世代のセキュリティ基盤である SASE（Secure Access Service Edge） なんです！

—

3. SASEエッジでDoH/DoTをねじ伏せる仕組み

「見えないなら、見るのを諦めるしかないの？」いいえ、そんなことはありません。ゼロトラストの思想では、「社外だろうが社内だろうが、すべての通信は一度私（SASE）の目を通りなさい」と考えます。

SASE（サセ）は、クラウド上にある強力なセキュリティの関所です。ユーザーが社内にいようが、カフェで仕事をしていようが、すべての通信がこのSASEエッジを経由します。

ここでSASEは、次のような巧妙かつ力強いアプローチでDoH/DoTを制御します。

1. 特定（識別）: 通信の暗号化が始まる前の「あ、この宛先は有名なパブリックDNSサーバー（例：Googleの8.8.8.8やCloudflareの1.1.1.1など）だな」という宛先IPや挙動を瞬時に見抜きます。
2. 遮断（ブロック）: 「うちの会社では、社外の勝手なDNS金庫を使うのは禁止！」と、その通信をピシャリと遮断します。
3. 強制フォワード（リダイレクト）: 「どうしても名前解決が必要なら、当社の安全な社内DNSサーバーを使いなさい」と、通信を強制的に会社の指定ルートへ方向転換させます。

—

4. 実務で役立つ設定イメージを見てみよう

「理屈は分かったけれど、実際の現場ではどうやって設定するの？」
ここからは、主要なSASE製品や次世代ファイアウォール（NGFW）などでよく見られる、DoH/DoTブロックのポリシー設定のイメージを覗いてみましょう。

今回は、疑似的な設定ファイル（YAML形式）を例に、どのようにルールが書かれているかを見てみます。難しく考えず、「こういう風に機械に命令しているんだな」と眺めてみてくださいね。

# SASE / セキュリティゲートウェイのDNS制御ポリシー設定例
security_policy:
  name: "Enforce-Corporate-DNS-Policy"
  description: "社員が勝手に暗号化DNS(DoH/DoT)を使って社内フィルターを迂回するのを防ぐ"
  
  # ターゲットとなるユーザーグループ
  target_users:
    - "all-employees@example.com"

  # ルール1: パブリックなDoHサービスへのアクセスを検知してブロック
  doh_blocking_rule:
    action: "block" # 容赦なく遮断！
    known_doh_providers:
      - name: "Google Public DNS (DoH)"
        destination_ip: "8.8.8.8"
        sni_pattern: "dns.google"
      - name: "Cloudflare (DoH)"
        destination_ip: "1.1.1.1"
        sni_pattern: "cloudflare-dns.com"
    log_alert: true # セキュリティチームにアラートを飛ばす

  # ルール2: 不正なDNSリクエストを会社の安全なDNSへ強制転送
  dns_redirection:
    action: "redirect"
    fallback_dns_server: "10.100.0.53" # 社内のセキュアなDNSサーバーのIP
    message_to_user: "社内セキュリティポリシーにより、指定外のDNS利用は禁止されています。"

このように、「この宛先に行こうとしたら怪しいな、ブロックしよう」「こっちの安全なルートに誘導しよう」というルールをSASEのエッジ側で一括管理することで、会社全体のエンドポイント（PCやスマホ）の安全を守っているのです。

—

5. まとめ：これからのネットワークエンジニアに求められる視点

いかがでしたでしょうか？
DoHやDoTは、プライバシーを守るための素晴らしい技術である一方、企業のセキュリティをすり抜ける「もろ刃の剣」でもあります。

昔のように「会社のLANケーブルに繋がっていれば安全」という境界防御の時代は終わりました。
今は、どこから接続してもSASEというクラウドの関所が通信を監視し、隠し事（DoHによるバイパス）を見破るゼロトラストの姿勢が不可欠です。

インフラやネットワークの世界に初めて触れるときは、覚える用語が多くて圧倒されてしまうかもしれません。でも、「郵便配達」や「道路の関所」といった身近なイメージに置き換えてみると、技術の本質がスッと見えてきます。

ぜひ、日々の業務や学習の中で「このパケットは今、どこを通って、誰に見られているんだろう？」と想像を膨らませてみてくださいね。あなたのネットワークセキュリティの旅を、これからも応援しています！