【入門編】 Service Mesh (Istio/Linkerd) におけるサイドカープロキシの通信ログ分析 – インシデントレスポンス & フォレンジック（DFIR）防御ガイド

こんにちは！セキュリティの世界へようこそ。
日々、多くのシステムを守るために奮闘されているインフラ担当者や開発者の皆さん、本当にお疲れ様です。

今回は、最近のモダンなシステム開発でよく使われる「Service Mesh（サービスメッシュ）」、特にその中でこっそり裏方として働いている「サイドカープロキシ（Envoyなど）」の通信ログ分析についてお話しします。

「サイドカープロキシ？なんか難しそうな名前だな……」と思いましたよね？
でも大丈夫です。身近な「家の防犯」にたとえながら、一歩ずつ優しく紐解いていきますので、安心してついてきてくださいね！

—

1. そもそも「サービスメッシュ」と「サイドカー」ってなに？（おうちの防犯にたとえてみよう）

皆さんが住んでいる「家」を想像してみてください。
昔ながらの一軒家なら、玄関の鍵を閉めておけば泥棒は入れませんでしたよね。でも、現代の巨大なマンションやシェアハウスはどうでしょう？建物の中にたくさんの部屋があり、住人同士が廊下を行き来し、宅配ボックスがあったり、来客用エントランスがあったりします。

マイクロサービスという現代のシステムも、これにそっくりです。
昔は一つの大きなプログラム（モノリス）で動いていましたが、今は小さなプログラム（サービスA、サービスB、サービスC……）が、まるでシェアハウスの住人のようにたくさん集まって、お互いに通信しながら動いています。

ここで問題になるのが、「部屋と部屋を行き来する廊下での安全確認」です。
すべてのプログラムのコードの中に、「ちゃんとした身分証を持っているか？」というチェック機能をいちいち書くのは、開発者にとって大変な手間ですし、ミスも起きやすくなります。

そこで登場するのが、「サイドカープロキシ（IstioのEnvoyなど）」です。
これは、すべてのプログラムの「すぐ隣（サイドカー）」にピタッと寄り添う、専用の警備員さんだと思ってください。

プログラム（住人）：自分の仕事（料理や洗濯など）に集中するだけでOK。
サイドカープロキシ（警備員）：部屋のドアの前に立ち、「外部からの怪しい人が来ていないか」「隣の部屋に行く人が正しい権限を持っているか」をすべてチェックして記録します。

この警備員さんたちがネットワーク全体で連携する仕組みを「サービスメッシュ」と呼びます。

—

2. 攻撃者はどこを狙う？――「信頼された内部」の盲点

「警備員がいるなら安心だね！」と思いますよね。
しかし、セキュリティの現場でよくある恐ろしいシナリオがこれです。

「もし、悪意ある侵入者が、警備員の目を盗んで（あるいは警備員同士の通信ルールを悪用して）勝手に隣の部屋に入り込んできたとしたら？」

マイクロサービスの世界では、「同じマンションの住人（内部のサービス）なんだから、きっと安全な人だろう」と、お互いを無条件に信じきっている設計（ゼロトラストになっていない状態）が意外と残っています。
攻撃者はここを突いてきます。外部から直接侵入できなくても、一度どこかの小さな脆弱性を突いて内部に入り込み、「認証をバイパス（すり抜け）した不正な内部トラフィック」を飛ばして、重要データがあるデータベースをこっそり覗き見ようとするのです。

ここで重要になるのが、警備員（Envoyプロキシ）が記録している「アクセスログ」の分析です。警備員は、誰が、いつ、どの部屋へ、どんな身分証を持って訪ねてきたのかを、すべてノートに書き留めています。このノートを読み解くことが、私たちSOC（セキュリティオペレーションセンター）アナリストの腕の見せ所というわけです。

—

3. Envoyのアクセスログを覗いてみよう！

Istioなどのサービスメッシュで一般的に使われるEnvoyプロキシは、通信の記録を細かく残すことができます。
現場でインシデント調査を行う際、私たちが真っ先に確認する「ログのフォーマット設定例」を見てみましょう。

# Istioのメッシュ設定（MeshConfig）におけるアクセスログのカスタマイズ例
# どのサービスから、どのサービスへ、どんな通信があったかを細かく記録します
defaultConfig:
  proxyMetadata:
    # アクセスログを標準出力に出力する設定
    ACCESS_LOG_FORMAT: |
ションID: %REQ(x-request-id)%
日時: %START_TIME%
送信元ワークロード: %UPSTREAM_CLUSTER%
メソッド: %REQ(:METHOD)%
パス: %REQ(:PATH)%
レスポンスコード: %RESPONSE_CODE%
認証フラグ: %DYNAMIC_METADATA(istio.authorization:allowed)%
元のクライアントIP: %REQ(x-forwarded-for)%

この設定によって出力されるログ（JSON形式などが一般的です）には、通信の全貌が記録されます。
新人の皆さんがまず注目してほしいのは、次の3つのポイントです。

1. %REQ(x-forwarded-for)% : 本当に外から来たのか、内部の別のサービスからリレーされたのか。
2. %RESPONSE_CODE% : 通信が成功したか（200）、拒否されたか（403、401）。
3. %DYNAMIC_METADATA(istio.authorization:allowed)% : Istioのアクセスポリシー（安全確認ルール）によって許可された通信かどうか。

—

4. 異常な通信パターンを見つけ出す！現場の分析手法

では、実際のインシデント現場では、このログからどうやって不正を見つけるのでしょうか？
代表的な2つのパターンを解説します。

パターンA：認証バイパス（ルールをすり抜けた不正アクセス）

本来、サービスBへは「サービスA」からしかアクセスしてはいけないというルールがあるとします。しかし、攻撃者が何らかの方法でそのルールをすり抜け、直接サービスBのサイドカーにリクエストを送った場合、ログには次のような矛盾が生じます。

*「通常の正規ルートを通っていないのに、レスポンスコードが 200（成功）になっている」*
*「送信元（Upstream）のラベルが、許可されていない予期せぬコンテナ名になっている」*

パターンB：横方向への移動（ラテラルムーブメント）

一つのコンテナが乗っ取られた後、攻撃者はネットワーク内をキョロキョロと見回し、他のコンテナへ次々と不正な通信を試みます（これを「スキャン」や「プロビング」と呼びます）。
サイドカーのログを時系列で並べたとき、「1台のサービスから、短時間に何十もの異なるマイクロサービスへ異常なリクエストが飛んでいる（パスがバラバラ、あるいは /admin や /debug など機密性の高いパスばかりを狙っている）」というログが見つかった場合、それは確実に内部侵害のサインです。

—

5. 一歩ずつ実践！今日からできる対策とログ監視のコツ

「ログの大切さはわかったけど、毎日こんなの見てられないよ！」という方へ。
現場で実践している、現実的なアプローチをステップ順にお伝えしますね。

① Istioの「AuthorizationPolicy」で厳格に縛る

まずは、お互いの通信を「デフォルト拒否（Deny All）」の状態にし、必要な通信だけをホワイトリスト形式で許可するポリシーを書きましょう。

# 例：frontendサービスからのみ、backendサービスへのアクセスを許可するポリシー
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: "backend-allow-frontend"
  namespace: "default"
spec:
  selector:
    matchLabels:
      app: backend # 守る対象のサービス
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/frontend-service-account"] # 許可する送信元の身分証（Service Account）

このように身分証（TLS証明書に基づくSPIFFE IDなど）を厳格にチェックする設定を入れておくだけで、偽造された通信はサイドカーが自動でブロックしてくれます。

② SIEMやログ分析ツールで「異常値」をアラート化する

すべてのログを目視でチェックするのは不可能です。
ログ収集基盤（Elasticsearch、Loki、Splunkなど）を使い、以下のような条件にヒットしたらSlackやTeamsに通知が飛ぶようにクエリ（検索条件）を設定しておきましょう。

RESPONSE_CODE が 403（拒否）なのに、同じ送信元IPから数秒間に100回以上リクエストが来ている（総当たり攻撃の兆候）
機密データを扱うAPIパス（例: /api/v1/secrets）に対して、通常はアクセスしないはずの古いバージョンのサービスからのアクセスがある

—

おわりに：焦らず、一歩ずつセキュリティを強固にしていこう

サービスメッシュやサイドカープロキシのログ分析は、最初は暗号のように見えるかもしれません。
でも、「どの家（サービス）の、どの警備員（プロキシ）が、誰を通したのか」という視点を持つだけで、ログの見え方はガラリと変わります。

完璧なセキュリティを最初から目指す必要はありません。まずは身の回りの防犯（ログの出力確認や、基本的なアクセス制御の導入）から、一歩ずつ確実に進めていきましょう！
あなたのその丁寧なログ分析が、組織のシステムを重大なインシデントから救う大きな力になります。応援しています！