利用者目線で考える、MCPを安全に使うために

Transcript

1. 利⽤者⽬線で考える、MCPを安全に使うために 2025.06.17 MCP導⼊における脅威モデリングのすゝめ hamayanhamayan
2. hamayanhamayan  ⾃⼰紹介 GMO Flatt Security株式会社 {Corporate,Security} Engineer 毎週CTF ※ に勤しむ⽇曜Webセキュリティ愛好家 ※ 競技化されたセキュリティのコンテストです。楽しいので皆さんも是⾮
3.  今⽇お話しすること
 利⽤者側からMCPをどう安全に使っていくかをテーマに、オムニバス形式でお伝えします。 • 悪意あるMCP Server • 権限付与について • 制御できないLLMとMCP 利⽤者 LLMアプリ (MCP Host/Client) MCP Server 3rd party サービス 実⾏環境
4. 悪意あるMCP Server
5.  MCP Serverの提供形態 MCP Serverの提供形態は⼤きく2つ。 ローカル MCP Server ⼿元でMCP Serverを起動して利⽤する形 リモート MCP Server ネットワーク経由でhttpを使って接続する形 簡単に作成‧公開ができるので有志による実装がたくさんあり、その中には、悪意あるMCP Serverも...
6.  ローカル MCP Server ⼿元でMCP Serverを起動して利⽤する形 • npx • uvx • docker などが主流 悪意を持ったMCP Serverや サプライチェーン攻撃の危険性 https://github.com/GoogleCloudPlatform/cloud-run-mcp "cloud-run": { "command": "npx", "args": ["-y", "https://github.com/GoogleCloudPlatform/ cloud-run-mcp"] } https://github.com/modelcontextprotocol/servers/blob/ main/src/time/README.md "time": { "command": "uvx", "args": ["mcp-server-time"] } https://github.com/grafana/mcp-grafana "grafana": { "command": "docker", "args": [ "run", "--rm", "-i", "-e", "GRAFANA_URL", "-e", "GRAFANA_API_KEY", "mcp/grafana", "-t", "stdio" ], "env": { "GRAFANA_URL": "http://localhost:3000", "GRAFANA_API_KEY": "<your service account token>" } }
7.  ローカル MCP Server • これまでと同様の対策 ◦ 提供元は信頼できるか ▪ MCP公式が提供しているもの ▪ サービス事業者が公式で提供しているもの ◦ 導⼊後に悪性化する可能性を考慮したピンニング • 有志が作ったMCP Server ◦ MCP Serverは実装が軽いことも多いので、実装が⾒られるなら軽くレビューするのがオススメ ▪ 中を⾒るとAPI呼び出しをwrapしているだけとか ◦ 弊社のTakumiに聞いてみるのも良い • MCPの接続設定はかなり⾃由に書けるため、追加で権限を絞るハードニングが⾏える ◦ 例えば... ◦ npxによる起動 → dockerで包んで起動 : コンテナ上に動作を制限させる ◦ npxによる起動 → deno上での実⾏ : ネットワーク制限などのより厳しい制限をつける ※ ※ 具体的な実装は「MCPにおけるセキュリティ考慮事項と実装における観点（前編）」https://blog.flatt.tech/entry/mcp_security_first の 「悪性な MCP Server を実⾏した場合の実⾏環境への影響」をご参照ください
8.  リモートMCP Server ネットワーク経由でhttpを使って接続する形 • 提供元は信頼できるか ◦ サービス事業者が公式で提供しているもの ◦ リモート公開だとソースコードが確認できず、チェックしずらい • サービスを繋げるリモートMCP Serverの場合、間に⼊るMCP Serverが権限を持ってしまう ◦ 信頼できる例として、Zapier MCPのような権限を持っているプラットフォームがMCPによっ て、その権限を呼び出せるようにしているものもある LLMアプリ (MCP Host/Client) リモート MCP Server 3rd party サービス
9. 権限付与について
10.  権限の与え⽅ 外部のWebサービスを利⽤するようなMCP Serverは何らかの⽅法で権限を与える必要がある。 • API KeyやToken • OAuth どういう形を選択するのが安全だろうか。
11.  OAuthがオススメ OAuthがオススメです。GitHub Remote MCP Server と VSCode 構成を例にしてみよう。 を.vscode/mcp.jsonに追記する。 初回利⽤時に、ブラウザを起動してOAuthのフローが始まる。許可をするとアクセストークンがVSCodeに払 い出され、利⽤可能になる。 以前は、LLMアプリ側がサポートしていないことも多かったが、今はサポートが進んでいる。 https://github.com/github/github-mcp-server "github-remote": { "type": "http", "url": "https://api.githubcopilot.com/mcp/" }
12.  OAuthがオススメ - 理由1 設定ファイルをpushできる • プロジェクト全体でMCP Server設定を共有したい場合 ※ にmcp.jsonをpushできる • 権限取得時は、各々のアカウントで⾏うので、共通認証情報を撲滅できる • 誤プッシュしても⼤丈夫 https://github.com/github/github-mcp-server "github-remote": { "type": "http", "url": "https://api.githubcopilot.com/mcp/" } ※ 他にも、Claude Codeの.mcp.jsonはレポジトリにpushすることを想定しており、共有するケースは考えられる https://docs.anthropic.com/en/docs/claude-code/mcp
13.  OAuthがオススメ - 理由2 LLMアプリによっては、トークンをより安全に保管してくれる • VSCodeでは、トークンは暗号化した状態で保存される • 平⽂でのファイル保存や環境変数での保存に⽐べて格段に安全になる https://github.com/github/github-mcp-server "github-remote": { "type": "http", "url": "https://api.githubcopilot.com/mcp/" }
14.  OAuthがオススメ - 補⾜ 公式が提供するリモートMCP Serverが利⽤できると最⾼ • 公式がリモートMCP Serverを提供できると、アクセス権が第三者に保持されない • API利⽤のケースと⽐較しても、利⽤するエンドポイントは公式提供のものを使うのが⾃然な形 LLMアプリ (MCP Host/Client) 第三者 MCP Server 3rd party サービス
15.  OAuthがオススメ - 補⾜ 公式が提供するリモートMCP Serverが利⽤できると最⾼ • 公式がリモートMCP Serverを提供できると、アクセス権が第三者に保持されない • API利⽤のケースと⽐較しても、利⽤するエンドポイントは公式提供のものを使うのが⾃然な形 LLMアプリ (MCP Host/Client) 公式 MCP Server 3rd party サービス
16.  API Keyが必要な時 MCP ServerによってはAPI Keyのような認証情報を渡すしか無い場合もある。以下のような懸念がある。 • 認証情報が1つのファイルにまとまっていて、かつ、暗号化されておらず、漏洩時リスクが⾼い • VSCodeのmcp.jsonやClaude Codeの.mcp.jsonが誤ってpushされるかも LLMアプリによってはMCPの設定ファイルの⼀部を直接書かず、外部から差し込むように設定できる。 例えば、VSCodeのVariables referenceという記法を使うと、設定ファイルに平⽂で直に書いていた認証 情報を環境変数から埋めこむこともできたり、起動時に都度⼊⼒させることができる。 "Perplexity": { "type": "stdio", "command": "docker", "args": ["run","-i","--rm","-e","PERPLEXITY_API_KEY","mcp/perplexity-ask"], "env": { "PERPLEXITY_API_KEY","${input:perplexity-key}" } # inputによる外部差し込み }
17. 制御できないLLMとMCP
18.  制御できないLLM こんな経験ありませんか？ • 設定したMCP Serverを使って欲しかったが、うまく使ってくれない • 使う予定なかったけど、とあるMCP Serverが使われた LLMの挙動は指⽰をすることはできますが、完璧にはコントロールできない。 どういった問題が発⽣しうるでしょうか？
19.  問題１：LLMの暴⾛
 複数のMCP Serverを接続していると、LLMは組み合わ せて利⽤してくれますが、どのように組み合わせて使 うかの細かい部分は、LLMが決定する。 LLMは情報の機密性を理解できず、機密性の⾼い情報 が外部に漏洩するかもしれない。 複数のMCP Serverを繋げると発⽣しうる最⼤のリス クはそれぞれの要素の掛け算になる。
20.  問題２：悪意あるMCP ServerがLLMを騙す
 悪意あるMCP Serverがあった場合に、悪意ある応答 によって、LLMの動きを操作する攻撃がいくつか提唱 されている。 • Tool Poisoning ※1 • Tool Name Conflicts ※2 • MCP Server経由で何らかの汚染されたデータが 送られてくるかも ※1: https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks ※2: https://arxiv.org/html/2503.23278
21.  制御できないLLM LLMの決定はプロンプトや⼊⼒に左右され、また、 ⼈間が完全にコントロールできない • 利⽤者の意図していない⾏動を取るかも • 攻撃者の悪意ある差し込みの影響を受けるかも LLMにMCPを繋げるにあたって考えるべきは どうリスクコントロールをしていくか
22.  ⼈間による承認 ⼀番確実な⽅法は、⼈間による承認 どのMCP ServerとToolを使うか どういう引数を与えるか ⼀時的に許可するか / 常に許可するか 初回は承認を求めて、許可されたら⾃動許可にする
23.  ⼈間による承認 ⼀番確実な⽅法は、⼈間による承認 でも、⼈間は本当に承認時にチェックしているのか • ⼈間はちゃんと確認しない • 重要部分をうまく隠して承認させるような攻撃 テクニック ※ もある ⼿動承認を最⼩化していくために • うまくリスクの最⼤値を下げて、⾃動承認に切り 替える • ⼈間による承認が多すぎる場合は、利⽤⽅法を ⾒直す必要がある • 最終的には全部⾃動承認しても⼤丈夫にする ※ https://invariantlabs.ai/blog/whatsapp-mcp-exploited
24.  不要なMCP ServerやToolの無効化 不要なMCP ServerやToolを無効化することでもLLMの⾏動を制限することができる。 • MCP Server毎だけでなく、Tool毎に設定が可能 • ⽤途に応じたプロジェクトを作成し、必要最低限のMCP Serverを設定する
25.  サンドボックスの活⽤ LLMアプリとMCP Serverの両⽅をサンドボックス環境に⼊れて、実⾏環境を隔離することで実⾏時の リスクを限定させる。 • （数ヶ⽉前は、専⽤の別のPCを⽤意してぶん回すということをしていましたが...） • Claude Codeでは、devcontainerを使って隔離環境を作成し、全て⾃動承認するやり⽅を提唱 している ※ ※ https://docs.anthropic.com/ja/docs/claude-code/security
26. おわりに
27.  おわりに
 利⽤者側からMCPをどう安全に使っていくかをお伝えしてきました。 • 悪意あるMCP Server • 権限付与について • 制御できないLLMとMCP 以前、MCP前編の記事 ※ を書いてから1ヶ⽉くらいが経ちますが、 （特にLLMアプリ側の）状況が当時よりも良くなっているように思います。 これからもどんどん良くなっていくことを期待して、MCPを使い倒しましょう！ ※ https://blog.flatt.tech/entry/mcp_security_first
28.  Takumi - ⽇本初‧セキュリティ診断AIエージェント https://flatt.tech/takumi
29.  Takumi - ⽇本初‧セキュリティ診断AIエージェント https://flatt.tech/takumi
30. 利⽤者⽬線で考える、MCPを安全に使うために 2025.06.17 MCP導⼊における脅威モデリングのすゝめ hamayanhamayan