Claude Media
MCP tunnelsのセキュリティ — ベストプラクティスと侵害対応手順
MCPAgent SDK解説

MCP tunnelsのセキュリティ — ベストプラクティスと侵害対応手順

MCP tunnelsの3層防御の仕組みと、侵害を疑ったときの対応手順・トンネル廃止手順をまとめています。

読了目安 約10分

MCP tunnelsの3層防御はどこまでを守るか

MCP tunnelsは、プライベートネットワーク内のMCPサーバーへインバウンドポートを開けずに到達させるトンネルです。研究プレビュー段階の機能で、稼働率やサポートの継続を保証するものではなく、トランスポートの土台にはAnthropic以外の第三者(Cloudflare)が使われています。この仕組みが安全かどうかは、アーキテクチャが持つ既定の防御と、利用者側の運用の両方で決まります。まず全体像を押さえます。

外側では、Anthropicとトランスポート提供元(Cloudflare)の間でmTLSとIP検証がかかり、認可されていないクライアントがトンネルに到達すること自体を防ぎます。その内側では、Anthropicのバックエンドとプロキシの間で内側TLSがもう一段張られます。あなたが管理するCA証明書で署名されたサーバー証明書をプロキシが提示するため、トランスポート層のCloudflareや途中の中継はペイロードを読めません。最後に、MCPサーバーごとに設定するOAuthが、認証済みのトンネル通信であってもツールの不正利用を防ぐ役割を担います。この3段目までたどり着いて初めて、リクエストは「認証済みユーザーが許可されたツールを呼んでいる」状態になります。

3層に分かれている理由は、それぞれが守る対象が違うからです。外側のmTLSとIP検証は「そもそもトンネルに繋げる相手」を絞り込み、内側TLSは「繋がった後の中身を誰が読めるか」を絞り込み、OAuthは「読めた上でどのツールを叩けるか」を絞り込みます。どれか1層が突破されても、残りの層が食い止める設計であり、これがAnthropicの言う多層防御の実体です。逆に言えば、OAuthを省略してしまうと3層目が丸ごと欠けた状態で運用することになります。

トンネルは通信を暗号化するが、MCPサーバーへの認証はしない

見落としやすい境界線がひとつあります。トンネルが保証するのは「Anthropicからあなたのプロキシまでの通信が暗号化され、途中経路から読めない」ことだけで、その先のアップストリームMCPサーバーに対する認証は別問題です。MCPサーバーがOAuthやbearerトークンを要求するなら、トンネルを使っていない場合とまったく同じ方法で用意する必要があります。後述のベストプラクティスの筆頭にあるOAuthの必須化は、この境界線を埋めるための対策です。トンネルだけを設定して満足すると、経路は暗号化されていてもサーバー自体は無認証で誰でも呼び出せる、という構成になりかねません。

トランスポート提供者(Cloudflare)から何が見えるか

内側TLSがあるため、Cloudflareはリクエストやレスポンスの中身を読めません。ただし、次の接続メタデータはCloudflare側に渡ります。

  • cloudflaredを動かすホストの送信元IPアドレス
  • cloudflaredのホストフィンガープリント
  • 接続のタイミングと通信量
  • トンネルに割り当てられた*.tunnel.anthropic.comのサブドメイン

Anthropicとの契約でこのテレメトリの利用は制限されており、Cloudflareはこのリサーチプレビューにおけるサブプロセッサという位置づけです。Zero Data RetentionやHIPAA BAAの対象範囲を確認したいチームは、ペイロードは見えないがメタデータは見える、という粒度で自組織のコンプライアンス要件と照らし合わせてください。

確認の観点は2つに分かれます。ペイロードが第三者に渡らないことを前提にする要件は、内側TLSによって満たされます。一方、接続のタイミングや通信量といったメタデータそのものの残存を問題にする要件、たとえばHIPAAのBAA適用範囲の中にこの経路が含まれるかどうかは、Cloudflareがサブプロセッサとして関与する時点で個別に適格性を確認する必要があります。どちらの観点に当てはまるかで、MCP tunnelsを採用してよいかの判断が変わります。

侵害を防ぐために公式が挙げるベストプラクティス

まず認証・認可の層です。すべてのMCPサーバーでOAuthを必須にすることが最初の推奨事項です。MCP認可仕様に沿って設定すれば、トンネルのトランスポート認証に加えてデータ層でのユーザー単位の認可を成立させられます。組織全体でSSOを有効にしておけば、トンネル・フェデレーションルール・サービスアカウントの設定を変更できる管理者に対して、IdP側のセッション制御が及びます。

次にネットワークの層です。allowed_ipsは最小限のCIDR範囲に置き換えるのが、プロキシのSSRF対策として最も効果の大きい設定です。プロキシとcloudflaredが到達できる範囲も、公式が定めるネットワーク要件の宛先だけに制限します。Kubernetesならネットワークポリシー、Composeならホストのファイアウォールルールで絞り込みます。

運用の層では、ログの監視、証明書とトンネルトークンの定期ローテーション(侵害を疑った時点での即時ローテーション含む)が挙げられています。加えて、プロキシイメージの追随とSHA-256ダイジェストでのピン留め、秘密鍵・トークンの保管方法を組織のシークレット管理方針に合わせることも推奨事項です。具体化するなら、Kubernetes環境ではシークレットストア連携ツールでSecretを外部管理に寄せます。Compose環境ではdata/配下のファイルパーミッションを絞り、ホストへの直接アクセスを制限します。加えて、MCPサーバーが公開するツールとデータは、その用途に必要な範囲だけに絞ることも独立した推奨事項です。1つのサーバーに何でも詰め込むと、OAuthで守っていても影響範囲が広がります。

侵害を疑ったときの対応手順

トンネルトークン、TLS秘密鍵、プロキシを動かすホストのいずれかが侵害された疑いがあるときは、次の順で対応します。

  1. トンネルスタックを止める。Helmならhelm uninstall mcp-tunnel -n mcp-tunnel、Composeならdocker compose down --timeout 0で即座に停止します。
  2. アップストリームのMCPサーバーを切り離す。Managed Agentセッションの構成から該当サーバーを外します。Messages APIのmcp_serversブロックへのURL指定もやめます。
  3. トンネルをアーカイブする。アーカイブするとトンネルトークンが無効化され、ドメインも切り離されます。Console上の「MCP tunnels」一覧から操作するか、APIで実行します。
  4. Anthropicサポートへ報告する。疑わしい侵害はサポートへ連絡します。
  5. 下流の資格情報をローテーションする。新しいトンネルを再発行し、影響を受けたMCPサーバーが発行していたOAuthトークンも入れ替えます。
  6. ログを確認してから復旧する。新しいトンネルを稼働させる前に、疑わしい期間のプロキシ・cloudflared・MCPサーバーのログを確認します。
# Helm環境でのスタック停止
helm uninstall mcp-tunnel -n mcp-tunnel
 
# Docker Compose環境での即時停止
docker compose down --timeout 0

トンネルを完全に廃止する手順

使わなくなったトンネルは、保存された資格情報ごと片付けます。手順は侵害対応とほぼ同じ骨格ですが、緊急停止(--timeout 0)ではなく通常のシャットダウンで構いません。

  1. スタックを停止する。Helmならhelm uninstall mcp-tunnel -n mcp-tunnel、Composeならdocker compose down。
  2. トンネルをアーカイブする。Console上の「MCP tunnels」一覧から操作します。
  3. 保存済みの資格情報を削除する。
# Helm: setupコンポーネントが作成したSecretを削除
kubectl -n mcp-tunnel delete secret \
  mcp-tunnel mcp-tunnel-token mcp-tunnel-cert \
  --ignore-not-found
 
# Docker Compose: 秘密鍵・証明書・トークンが入るdataディレクトリを削除
sudo rm -rf data

Compose環境で手動フロー(setupコンポーネントを使わない構成)を取っていた場合、トンネルトークンはシェル環境変数側にも残っている可能性があります。data/の削除だけでなく、環境変数の消し込みも忘れずに行います。config/ディレクトリとdocker-compose.yaml自体には秘密情報が含まれないため、同じ構成で再度トンネルを立てる予定があるなら残しておいても問題ありません。

MCP tunnelsのセキュリティ責任分担は何を意味するか

公式のシェアード・レスポンシビリティ表を見ると、Anthropicが持つ責任は3項目、利用者組織が持つ責任は7項目です。

Anthropicが持つ責任(3項目)利用者組織が持つ責任(7項目)
トンネルへのアクセス制御利用者組織が持つ責任(7項目)通信内容全般と第三者利用規約(Cloudflareの規約含む)への準拠
プロキシへ接続する前のCA証明書検証利用者組織が持つ責任(7項目)デプロイガイダンスの遵守
自組織が所有するトンネル以外へClaudeがリクエストを送らないことの保証利用者組織が持つ責任(7項目)トンネルトークンとTLS秘密鍵の保護
利用者組織が持つ責任(7項目)サーバー証明書の管理と期限前の更新
利用者組織が持つ責任(7項目)各MCPサーバーのOAuth設定
利用者組織が持つ責任(7項目)プロキシとMCPサーバーのネットワークアクセス制限
利用者組織が持つ責任(7項目)侵害を疑った場合のAnthropicへの通知

これは、一般的なSaaSコネクタでベンダー側が肩代わりする部分の多くを、MCP tunnelsでは利用者自身が運用する設計だということを意味します。証明書の更新を--renew-beforeでcron化していないチームや、allowed_ipsをデフォルトのRFC1918のまま広く開けているチームは要注意です。この表の右列のどこに自分の運用の穴があるかを一度洗い出す価値があります。

証明書の期限管理を仕組みに落とすなら、setup renew-cert --renew-before=720hをHelmの日次CronJobやComposeのcronに登録しておくのがもっとも手間の少ない形です。有効期限まで30日を切ったときだけ実際に証明書が更新されるため、期限を手動で追いかけて更新を忘れるリスクから解放されます。トンネルトークン側も、侵害を疑った場合や定期ポリシーに沿ってsetup init --token-versionの値を変えて再実行すれば、証明書には手を付けずトークンだけを入れ替えられます。

まとめ

3層防御(外側mTLS+IP検証、内側TLS、各MCPサーバーのOAuth)は既定で有効です。ただしallowed_ipsの絞り込み、資格情報のローテーション、ネットワーク到達範囲の制限は利用者側の設定次第です。侵害を疑ったら「スタック停止 → 切り離し → アーカイブ → 報告 → ローテーション → ログ確認」の順を崩さず進めます。トンネルを使い終えたときも同じ順序の縮小版(停止 → アーカイブ → 資格情報削除)で片付ければ、古いトンネルトークンやTLS秘密鍵が誰にも使われないまま社内ネットワーク上に残り続ける事態を防げます。MCPサーバー単位の権限設計そのものはMCPセキュリティガイドを、トンネルの利用先となるManaged Agentsの全体設計も合わせて確認してください。トンネルより上のレイヤーの抜け漏れにも気づきやすくなります。

この記事を共有:XはてブLinkedIn

関連する記事

MCP をもっと見る →