2.2データ可視性への影響

前節で監視データ源を選べるようになっても、そのデータがそもそも真実を映していないことがあります。ネットワークには、正当な理由で通信を書き換えたり隠したりする技術が数多くあり、その副作用として監視データの可視性が落ちるのです。たとえばNAT/PATでIPが書き換われば、境界のログに映る「送信元IP」は本当の端末ではなくなり、暗号化が入れば中身は読めません。この節では、可視性を下げる代表的な技術と、アナリストが「見えなくなった情報をどこで取り直すか」を判断する視点を養います。

2.2.1アドレス/経路を書き換える・隠す

• NAT/PAT＝内部の複数プライベートIPを1つのグローバルIP（＋ポート）に変換する。境界より外のログでは送信元がすべて同じグローバルIPに見え、どの内部端末かが分からなくなる。相関には、NAT変換テーブル（誰がいつどのポートを使ったか）や内部側のログとの突き合わせが必要になる。
• ACL（アクセス制御リスト）そのものはフィルタだが、可視性の観点ではログを取らない拒否（silent drop）や許可が、後追い調査で通信の存在を隠すことがある。ACLでミラー/ログ対象を絞りすぎると、監視データに現れない盲点が生まれる。
• ロードバランシング＝複数サーバや経路に通信を分散する。1つの論理的な会話が複数の物理経路やサーバに散るため、単一センサでは全体像が欠け、ログが別々のバックエンドに分断される。相関にはロードバランサのログとバックエンド側ログの結合が要る。

2.2.2中身を包む・匿名化する

• 暗号化＝ペイロードを読めなくする。TLS等で守られた通信は、中身（送信データやコマンド）が監視に映らず、tcpdumpでフルキャプチャしても平文が得られない。対策として、可視化したい箇所での復号（TLSインスペクション）や、中身に頼らないメタデータ（NetFlow・JA3等のフィンガープリント）での相関に切り替える。
• トンネリングとカプセル化＝あるプロトコルを別のプロトコルの中に包む。正当な用途（VPN等）も多いが、本来遮断すべき通信を許可された経路（例：DNSやHTTPS）の中に隠すことができ、単純なポート/プロトコル判定をすり抜ける。中身の検査やアプリ識別（AVC）が無いと見逃す。
• TOR＝通信を複数のノードで多重に暗号化・中継し送信元を匿名化する。境界からは相手が本当の宛先ではなくTOR出口/入口ノードに見えるため、宛先IPベースのレピュテーションや帰属が難しくなる。P2Pは多数のピア同士が直接通信するため、集中サーバのログが無く通信が分散して追いにくい。

あなたはSOCで、境界ファイアウォールのログから「グローバルIP 203.0.113.10 から社外の不審サイトへ大量アクセスがある」というインシデントを調べています。ところが 203.0.113.10 は社内全体のPAT変換後アドレスで、境界ログ上はどの内部端末も同じこのIPに見えます。ここで「送信元は 203.0.113.10」とだけ報告するのは、NATによる可視性低下を見落とした不完全なトリアージです。正しい一手は、外側の宛先IP＋宛先ポート＋時刻を鍵に、NAT/PAT変換テーブル（またはPAT内側ログ）と突き合わせ、その瞬間にそのポートを使っていた本当の内部プライベートIPを割り出すことです。次に、その内部端末の通信が暗号化（HTTPS）されていて中身が見えない場合、tcpdumpで平文は得られません。そこで発想を切り替え、NetFlowのメタデータ（宛先・頻度・バイト数）と、Webフィルタのレピュテーション/カテゴリ、必要ならTLSインスペクション対象への追加を使って、中身に頼らず悪性度を評価します。さらにもし通信がDNSトンネリング（DNSクエリの中にデータを埋め込む形）であれば、53番は多くの環境で許可されているため単純なポリシーをすり抜けます——この場合はクエリ長やサブドメインのエントロピー（ランダムさ）といったメタデータの異常が手掛かりになります。教訓は明確です：可視性を下げる技術（NAT・暗号化・トンネリング・TOR）は「見えない」で終わらせず、「別のどの層・どのログで同じ事実を取り直せるか」を必ず設計する——それがアナリストの相関スキルです。

2.2.3この節のまとめ

• NAT/PATは複数内部端末を1グローバルIPに集約して本当の送信元を隠す。特定には変換表・内側ログとの相関が要る
• 暗号化・トンネリング/カプセル化・TORは中身や実プロトコル・送信元を隠す。メタデータ相関・アプリ識別・レピュテーションで取り直す
• P2P・ロードバランシング・過度なACLログ抑制は通信を分散/分断し盲点を作る。ログ結合とセンサ配置で全体像を回復する