こんにちは！セキュリティの世界へようこそ。インシデントレスポンスやデジタルフォレンジックの世界では、日々さまざまなサイバー攻撃の痕跡を追いかけています。
今回は、最近のモダンなシステム開発でよく使われる「Service Mesh（サービスメッシュ）」と、そこで行われる「mTLS（相互TLS認証）」の失敗ログに焦点を当ててみたいと思います。
「なんだか難しそうな名前だな……」と思いましたか？大丈夫です！身近な例え話を交えながら、一歩ずつ優しく紐解いていきますので、安心して読み進めてくださいね。
—
1. 家の鍵で例える「mTLS」の仕組み
まずは、Service Meshの世界で行われている通信の安全を守る仕組みについて、私たちの身近な「お家のセキュリティ」に例えて考えてみましょう。
皆さんが暮らすマンションを想像してみてください。
マンションのエントランスにはオートロックがあって、住人のカードキーや暗証番号がなければ中に入れませんよね。さらに、それぞれの部屋に入る時にも鍵が必要です。
これをWebのシステムに置き換えてみましょう。
最近のシステムは、いくつもの小さなプログラム（「マイクロサービス」と呼びます）が、お互いに連携して全体として大きなアプリを動かしています。「ユーザー情報を管理するサービス」や「お買い物カゴを管理するサービス」などが、社内のネットワーク（マンションの廊下）を通じておしゃべりをしている状態です。
ここで普通の通信をしていると、もし悪い人がマンションの廊下にこっそり忍び込んだ場合、部屋と部屋の間で行われている会話（データのやり取り）が丸見えになってしまいます。
そこで登場するのが mTLS（Mutual TLS / 相互TLS認証） です。
通常のTLS（鍵のかかった通信）は、「ここ本当に安全なお店（サーバー）ですか？」と、私たちがサーバーを確認するだけ（片方向）でした。しかし、mTLSは「通信するお互いが、お互いの身分証（クライアント証明書）を確認し合う」という仕組みです。
- サービスA「私はサービスAです。身分証を見せてください」
- サービスB「はい、これが私の身分証です。そちらも身分証を見せてください」
- サービスA「確認できました。では安全にお話ししましょう」
これがmTLSです。マンションの住人同士が、部屋に入る前に必ずお互いの顔と身分証をチェックし合うような、非常に堅牢な防犯システムなんですね。
—
2. 攻撃者はどこを狙う？ mTLSの「失敗ログ」が教えてくれること
では、この頑丈な仕組みに対して、悪い人（攻撃者）はどんな悪だくみをするでしょうか？
もし攻撃者が何らかの手口で社内ネットワークの片隅に侵入できたとします。彼らは、他の大切な部屋（サービス）のドアをガチャガチャと開けようと試みます。あるいは、本物のサービスになりすまして、隣の部屋から機密データを盗み出そうとします。
しかし、そこには強力なmTLSというオートロックがあります。
当然、攻撃者は正しい身分証（証明書）を持っていません。そのため、サービス間の通信を試みても、認証に失敗してしまいます。
ここで、セキュリティのプロである私たちSOCアナリストや、日々システムを支える開発者の出番です。
Service Mesh（例えば Istio や Linkerd など）は、この「身分証の確認に失敗した瞬間」を、しっかりとログに残してくれています。
- 「あれ？ サービスAになりすました誰かが、正しい身分証を出せずにドアの前で追い返されているぞ？」
- 「このIPアドレス、本来はアクセスしてこない部署のコンテナじゃないか？」
このように、mTLSの失敗ログは、内部ネットワークに潜む不審者の存在や、不正なスキャン（偵察活動）をいち早く察知するための「防犯カメラの映像」そのものなのです。
—
3. ログを実際に見てみよう（Istioのアクセスログ分析）
それでは、実務でよく使われるService Meshの一つである「Istio」を例に、実際のログとその対策を見ていきましょう。
例えば、IstioのEnvoyプロキシが出力するアクセスログやエラーログには、mTLSのハンドシェイクが失敗した際、次のような情報が記録されます。
{
"time": "202X-10-24T12:34:56.789Z",
"instance_ip": "10.244.1.15",
"downstream_remote_address": "10.244.3.44:54321",
"reporter": "destination",
"response_code": 503,
"response_flags": "UF",
"connection_termination_details": "TLS error: 268435581:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED",
"upstream_cluster": "outbound|80||payment-service.default.svc.cluster.local"
}このログの中身を、優しく分解して読んでみましょう。
1. downstream_remote_address: "10.244.3.44:54321"
- アクセスを試みた相手のIPアドレスとポート番号です。「どの部屋の誰が」やってきたのか分かります。
2. response_code: 503 / response_flags: "UF"
- 「Upstream failure（上流への接続失敗）」を意味します。通信が正常に確立できず、エラーになったことが分かります。
3. connection_termination_details: "...CERTIFICATE_VERIFY_FAILED"
- ここが一番のポイントです！ 「証明書の検証に失敗しました」というエラーです。つまり、相手が提示した身分証が偽物だったり、期限切れだったり、そもそも身分証を持っていなかったりしたために、追い返したという決定的な証拠になります。
もし、自社の管理下にあるはずのない不審なIPアドレスから、この CERTIFICATE_VERIFY_FAILED のログが大量に発生していたら……？
それは間違いなく、内部ネットワークからの不正なスキャンや、未許可のコンテナによる侵入・なりすましトライアルを意味しています。
—
4. 実務で役立つ！監視と防御のための設定アプローチ
「ログの大切さは分かったけれど、日々の開発やインフラ構築でどう活かせばいいの？」という方のために、具体的な設定や対策の一例をご紹介します。
Service Mesh（Istioなど）では、サービス間の通信ポリシーを PeerAuthentication という設定でコントロールできます。以下は、厳格なmTLS（STRICTモード）を強制するための設定ファイル（YAML）のサンプルです。
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: production-system # 守りたいシステムがある名前空間を指定します
spec:
mtls:
# STRICTを設定することで、暗号化されていない通信や、
# mTLSの証明書を持たない不審なアクセスを一切拒否します。
mode: STRICT一歩ずつ進めるインシデント対策のステップ
1. まずは「PERMISSIVE（ゆるふわ）モード」から始めてもOK
- いきなり
STRICTにすると、既存のアプリの通信まで壊してしまうことがあります。最初は通信を許可しつつログだけを取るモードから始め、安全を確認しながら厳格化していきましょう。
2. 失敗ログのアラート化
- 先ほど紹介した
CERTIFICATE_VERIFY_FAILEDやresponse_flagsが短時間に何回も発生した際、SlackやTeams、セキュリティ監視ツール（SIEMなど）に通知が飛ぶように設定しておきます。これが現場での「サイレン」の役割を果たします。
3. 定期的なログの振り返り
- 「たまに知らないIPからアクセスが来ているけれど、テスト環境の古いコンテナが消し忘れられていただけだった」といった社内のミスを発見するきっかけにもなります。
—
おわりに
いかがでしたでしょうか？
「Service MeshにおけるmTLSの失敗ログ分析」と聞くと、なんだかとても難解でエンジニアの遠い世界の話に聞こえたかもしれません。
しかし本質は、「お家の防犯カメラが、怪しい不審者のドアガチャ（不正な侵入試行）を記録してくれている」という、とてもシンプルで泥臭い防衛の仕組みです。
セキュリティは、一度に完璧な要塞を作る必要はありません。まずは仕組みを知り、ログという「足跡」に目を向けることから、安全なシステム作りは始まります。
日々の開発やインフラ運用の中で、ほんの少しだけ「通信の裏側で誰が身分証を見せ合っているか」を意識してみてください。あなたのその小さな気づきが、組織を重大なインシデントから救う第一歩になりますよ。
それでは、また次回のセキュリティ解説でお会いしましょう！一歩ずつ、確実に学んでいきましょうね。
コメント