【入門編】 CASBのシャドーIT検出におけるDNSログ（ポート53）およびNetFlow/IPFIXの解析フロー – ゼロトラスト＆エンタープライズセキュリティ実践ガイド

こんにちは！ネットワークやセキュリティの世界に足を踏み入れたばかりの皆さん、日々のインフラ学習お疲れ様です。

「ゼロトラスト」や「SASE（サセ）」という言葉、最近本当によく耳にしますよね。「社内だから安全」というこれまでの常識が通用しなくなり、どこにいても、どんなデバイスからでも安全にクラウドへアクセスする仕組みが求められています。

そのSASEの重要な構成要素の一つがCASB（キャスブ：Cloud Access Security Broker）です。社内の従業員がどんなクラウドサービス（SaaS）を使っているかを可視化し、コントロールしてくれる頼もしい存在なのですが……ここで一つ、現場のネットワークエンジニアを悩ませる「大きな壁」があります。

それは、「プロキシ（代理人）を通らない通信」の存在です。

「会社から指定された安全な門（プロキシサーバー）を通ってインターネットに行きなさい」と言っているのに、賢い従業員（あるいは野良アプリ）が、その門をスルーして裏口からこっそり外の世界と通信してしまう……いわゆるシャドーITですね。

「プロキシを通っていないなら、見えないのでは？」と思いますよね。いいえ、そんなことはありません！今回は、プロキシの網をすり抜ける通信を、CASBがどうやって暴き出しているのか。その裏側にある「DNSログ」と「NetFlow/IPFIX」の解析フローを、身近な例えを交えながら一緒に一歩ずつ紐解いていきましょう！

—

1. プロキシを通らない通信、どうやって見つけるの？（郵便配達の例え）

まず、なぜプロキシを通らない通信が見つけられるのか、現実世界の「郵便配達」に例えて考えてみましょう。

会社（オフィスネットワーク）から手紙を送る時、本来なら会社の「総務部（プロキシサーバー）」を一斉に通して外に発送するルールになっています。総務部を通れば、「誰が、どこ宛ての手紙を出したか」が完璧に記録に残りますよね。

しかし、中には総務部を通さず、オフィスの隅にある「社内専用の郵便ポスト（ルーターやファイアウォール）」に直接手紙を投函してしまう人がいます。これでは総務部は手紙の内容や宛先を把握できません。

でも、ちょっと待ってください。
たとえ総務部を通らなくても、「会社の中央郵便局（ルーターやDNSサーバー）」を通る時や、郵便物をトラックに積み込んで走り出す瞬間（NetFlow）」には、必ず足あとが残るはずです。

• 宛先を探す瞬間： 「○○という宛先（ドメイン）の住所を教えてください！」と案内所（DNSサーバー）に必ず聞きに行きます。
• 荷物を運ぶ瞬間： 「A地点からB地点へ、これだけの重さの荷物（パケット）が流れていきました」という運行記録（NetFlow）がトラックのタコグラフに残ります。

CASBのシャドーIT検出は、この「案内所への聞き込み記録（DNSログ）」と「トラックの運行記録（NetFlow）」をこっそり収集し、「おや、誰も許可していない怪しい宛先へ頻繁に手紙を出しているぞ……？」と見つけ出す仕組みなんです。

—

2. 第一の武器：DNSログ（ポート53）の解析フロー

私たちがブラウザに salesforce.com や dropbox.com と打ち込んだ時、パソコンはまず「そのサービスのIPアドレスを教えて！」とDNSサーバーに問い合わせを行います。この通信に使われるのが、おなじみのポート53番です。

CASBやファイアウォールは、社内のDNSサーバー（あるいはクラウド型DNS）が受け取ったクエリ（問い合わせ）のログを監視しています。

DNSログ解析の流れ

1. 問い合わせの発生： 社員のPCが、未知のSaaS（例：app.shadow-storage.io）の名前解決をDNSに要求します。
2. ログの収集： DNSサーバーは、「だれ（社内IP）が、どのドメイン（宛先名）を調べたか」というログを吐き出します。
3. CASBでのプロファイリング： CASBはこのDNSログを吸い上げ、あらかじめ登録されている「既知の安全なSaaSリスト」と突き合わせます。
4. シャドーITのあぶり出し： リストにない未知のドメインや、リスクの高いクラウドストレージへの問い合わせが多発している場合、「おや？」と検知のフラグが立ちます。

ここで、実際にネットワーク機器やログ収集サーバーで使われるような、DNSログを解析・フィルタリングするイメージのPythonスクリプトを見てみましょう。難しく考えず、雰囲気を味わってみてくださいね。

# 【サンプルコード】DNSクエリログから怪しいドメインを抽出するイメージ
# ゼロトラスト環境において、プロキシ未経由のシャドーITをDNSログからあぶり出す簡易スクリプト

import re

# ダミーのDNSクエリログ（実際はSyslogやSIEMから取得します）
dns_logs = [
    "202X-10-01 10:15:22 client=192.168.1.50 qname=api.slack.com type=A",       # 許可されたSaaS
    "202X-10-01 10:16:05 client=192.168.1.50 qname=unknown-storage-app.net type=A", # ★怪しいシャドーITの可能性
    "202X-10-01 10:20:11 client=192.168.1.88 qname=www.google.com type=A",     # 一般的なWeb閲覧
    "202X-10-01 10:25:40 client=192.168.1.88 qname=free-file-transfer.xyz type=A" # ★怪しいファイル転送
]

# 社内で利用が許可されている（あるいはホワイトリストに登録されている）ドメインのパターン
whitelist_patterns = [
    r"slack\.com$",
    r"google\.com$",
    r"microsoft\.com$"
]

def analyze_dns_logs(logs):
    print("--- [CASB連携] DNSログからのシャドーIT検出シミュレーション ---")
    for log in logs:
        # qname（問い合わせドメイン）を抽出
        match = re.search(r"qname=([^\s]+)", log)
        if match:
            domain = match.group(1)
            # ホワイトリストに一致するかチェック
            is_whitelisted = any(re.search(pattern, domain) for pattern in whitelist_patterns)
            
            if not is_whitelisted:
                print(f"[警告] 未承認のドメインへのアクセスを検知しました -> ドメイン: {domain} (ログ: {log})")
            else:
                print(f"[正常] 許可されたドメインです -> {domain}")

# 実行
if __name__ == "__main__":
    analyze_dns_logs(dns_logs)

このように、DNSログを監視することで、「そもそも誰がそのサービスの名前を調べたか」という初期の足あとを確実に捉えることができるのです。

—

3. 第二の武器：NetFlow / IPFIX によるトラフィックプロファイリング

名前解決（DNS）の次は、実際にデータが流れる通信そのものの監視です。ここで登場するのがNetFlowやその標準規格であるIPFIXです。

「パケットの中身（通信の中身）」を丸ごと覗き見するのは、プライバシーの観点や暗号化（HTTPS/TLS）の普及によって非常に難しくなっています。そこで使われるのが、通信の「メタデータ（要約情報）」だけを記録するNetFlowです。

郵便物にたとえるなら、中身の手紙は封がされていて読めませんが、「誰から（送信元IP）、誰宛てに（宛先IP・ポート）、どれくらいの重さの荷物（バイト数）が、何分間やり取りされたか」という伝票の控えを見るイメージですね。

NetFlow/IPFIX解析のポイント

CASBやコレクターサーバーは、ルーターや次世代ファイアウォール（NGFW）から送られてくるNetFlowレコードを受け取り、次のようなプロファイリングを行います。

1. 通信先の特定： 宛先IPアドレスから、どのクラウド事業者のサーバー群と通信しているかを特定します。（※多くの大手SaaSはIPアドレスレンジを公開しています）
2. 通信量の異常検知： 「普段はあまり通信しない宛先に対して、深夜に何GBもの巨大なデータが流れているぞ」といった、データ持ち出し（Exfiltration）の兆候を捉えます。
3. プロキシバイパスの発見： プロキシサーバー（通常は特定のIPやポートを通るはず）を経由していない、直結のHTTPS（ポート443）通信が大量発生している端末を特定します。

ここで、ネットワーク機器（Ciscoルーターなど）でNetFlowを有効化するための基本的な設定コマンドの例を見てみましょう。

! 【設定サンプル】CiscoルーターにおけるNetFlow（Flexible NetFlow）の基本設定イメージ
! 社内ネットワークの出口ルーターでトラフィックのメタデータを収集し、CASBコレクターへ転送します

! 1. 記録するデータの項目（フローレコード）を定義する
flow record CASB_ShadowIT_Record
 match ipv4 source address
 match ipv4 destination address
 match transport source-port
 match transport destination-port
 match ip protocol
 collect counter bytes
 collect counter packets
 collect timestamp absolute first
 collect timestamp absolute second

! 2. フローをどこに送るか（コレクターのIPアドレス）を定義する
flow exporter CASB_Collector_Exporter
 destination 192.168.100.10  ! CASBコレクターやSIEMのIPアドレス
 transport udp 2055          ! NetFlowの標準的なUDPポート
 export-protocol ipfix       ! 標準規格であるIPFIXを使用

! 3. モニター（監視の枠組み）を作成し、レコードとエクスポーターを紐付ける
flow monitor CASB_Monitor
 record CASB_ShadowIT_Record
 exporter CASB_Collector_Exporter
 cache timeout active 60     ! 長期接続のフローも60秒ごとに区切って送信

! 4. 社内からインターネットへ向かうインターフェースに適用する
interface GigabitEthernet0/0
 description Inside Network to Internet
 ip flow monitor CASB_Monitor input

このように、ルーターレベルでトラフィックの「宛先」「通信量」「ポート番号」を常に集計し、CASB側へ流し込むことで、プロキシの裏をかく通信であっても完全に網をかけることができるのです。

—

4. 現場のエンジニアが知っておくべき「まとめ」と心構え

いかがでしたでしょうか？ 今回は、プロキシを介さない直接通信や未知のSaaS利用を検出するための「DNSログ」と「NetFlow/IPFIX」の仕組みについて解説しました。

• DNSログ（ポート53）： 「どこに行こうとしているか（名前解決の段階）」の足あとを捉える。
• NetFlow/IPFIX： 「どれだけの量、どこへ通信しているか（メタデータの段階）」の運行記録を捉える。

ゼロトラストの基本は「誰も信用しない、すべてを検証する」です。「社内からプロキシを通っていないから大丈夫」ではなく、「プロキシを通っていない通信こそ、DNSやNetFlowの網で裏から暴いてやる！」という多層防御の視点が、これからのインフラエンジニアには求められます。

難解な用語やプロトコルも、身近な例えに置き換えて一つずつ紐解いていけば、決して怖くありません。ぜひ今日の学びを、日々の業務やインフラの設計・運用に活かしてみてくださいね。

それでは、また次回の技術解説でお会いしましょう！