AIツールが敵に回るとき：Splunk MCP TAを活用したMCPサーバーのセキュリティ運用

MCP (Model Context Protocol)は、AIアプリケーションが外部のデータソースやツールに接続する方法を標準化することを目的としたオープンソースプロトコルで、Anthropic社によって開発され、2024年11月にリリースされました。Anthropic社は、Claude Desktopの開発中、AIシステムを外部のデータソース、API、ローカルリソースと統合しようとするたびに個別のインテグレーションを実装しなくても済むように、普遍的な標準規格が必要だと考えて、このプロトコルの開発に乗り出しました。

MCPは、実装の容易さとローカルリソースでの使いやすさを重視していることから、AI開発コミュニティで人気を集めています。メッセージ形式にJSON-RPC 2.0を使用し、stdio (標準入出力)、SSE (Server-Sent Events)を使ったHTTP、WebSocket接続など、複数のトランスポート方式をサポートしています。特に、LLMの推論能力とエージェント型アプリケーションを接続するためには欠かせません。

MCPプロトコルを使用すれば、LLMの推論処理で外部サービス、ローカルリソース、その他さまざまなツールに接続できます。一方で、この機能性の高さと接続範囲の拡大が、特にMCP対応アプリケーションの利用とアクセスのセキュリティに関して、さまざまな課題を生んでいます。このブログ記事では、これらの課題について取り上げ、セキュリティアナリストが新たな領域を可視化するために役立つツールをご紹介します。新しいSplunk MCP TAは、MCP対応ワークフローの内部で行われるすべてのやり取りを明らかにすることを目的としています。

新たなツールによってもたらされる新たなセキュリティ課題

LLMがMCPプロトコルを介して内外のリソースやツールにアクセスできるようになった今、それによって生じるいくつかの課題を理解しておくことが重要です。

• MCPを使用するエージェントが悪意のある指示に従ってしまう可能性がある
• MCPの動的な性質により、たとえばコードの生成時に、悪意のある脆弱なコードが混入する可能性がある
• MCPでのやり取りが、ファイルの読み取り、書き込み、変更、削除につながる可能性がある
• 認証のための標準がない
• MCPでのこれらやり取りが一切可視化されていない
• 多くの場合、入力検証の段階ではLLMの解釈を予測できない
• 複数のMCPサーバーに接続してやり取りする場合、認証、認可、ネットワークアクセスが非常に複雑になる
• MCPで複数のデータソースにアクセスする場合、アクセス権限の拡大が必要になり、きめ細かなアクセス制御が難しくなる可能性がある(Jira、メール、カスタマーサービスDBのすべてにアクセスするなど)
• MCP経由でアクセスする外部リソースが、未検証または悪質なものである可能性がある

MCPサーバーを使用するときの動的な挙動は予測できません。そのため、MCP対応ツールやリソースの操作を指示している可能性のあるすべてのプロンプトと指示を厳密に監視する必要があります。この点で、MCPはリスクや脅威をもたらし、増大させます。こうした脅威の一部はエッジ(ファイアウォール、WAFなど)で発生すると考えられてきましたが、今日では、脅威の多くがMCP層で発生していることが確認されています(MCP SQLサーバーとのやり取りでSQLインジェクションが行われるなど)。

MCPサーバーが直面している脅威

現在、脅威を分類するためのフレームワークがいくつか開発されています。その1つがCoalition for Secure AIのModel Context Protocol Securityで、ここではMCPの脅威対象領域が3つのカテゴリに分けられています。

• MCP Specific：MCPのアーキテクチャや設計方針に起因する新たなリスクや脅威
• MCP Contextualized：MCPのコンテキストに応じて異なる形で現れる、またはMCPの導入によって増幅される、既知の脅威
• Conventional Security：広く適用されるセキュリティ脅威、またはレガシーシステム、インフラ、トランスポートの実装方針に起因するセキュリティ脅威

どこから始めるべきか

前述のとおり、MCPのリビジョン2025-06-18では、すべてのメッセージがJSON-RPC 2.0でエンコードされます。Splunk脅威調査チーム(STRT)は、MCPサーバーからのJSON-RPC出力を直接解析できるSplunkテクノロジーアドオン(TA)を公開しました。セキュリティアナリストは、このTAを使って、MCPでのメッセージのやり取りに含まれるメタデータを監視できます。MCPサーバーからJSON-RPCプロトコルメッセージのデータが取り込まれ、解析および分析されます。

このTAは以下を提供します。

• JSON-RPCメッセージの標準フィールドの抽出機能
• MCPプロトコルデータ用の事前設定されたソースタイプ
• MCPサーバー出力を簡単に取得するためのラッパースクリプト
• アプリケーション状態データモデルのCIM準拠

以下のスクリーンショットには、MCPファイルシステムサーバーからのデータの解析結果が表示されています。

この画面からわかるように、このMCPサーバーは、ファイルの書き込みを含むいくつかの操作を実行できます。次の画面に、ファイル作成のデータを示します。また、操作を実行するためにユーザーがMCPサーバーやエージェントに、より高いアクセス権限を付与する場合が多々あるという点も注意が必要です。そのため、エージェントが複数のMCPサーバーを使用する場合などには、制御と監視がより複雑になります。

MCPにはさまざまなタイプがあります。一般的なMCPサーバーには以下のものが含まれます。

• Filesystem (@modelcontextprotocol/server-filesystem)：ファイル操作
• GitHub (@modelcontextprotocol/server-github)：リポジトリ管理
• Memory (@modelcontextprotocol/server-memory)：ナレッジグラフストレージ
• Fetch (@modelcontextprotocol/server-fetch)：Webコンテンツの取得
• Git (@modelcontextprotocol/server-git)：Gitリポジトリツール

以下には、Splunk MCP TAによって処理された、Postgres MCPサーバーとのやり取りのデータ例が示されています。ここでは、MCPを介して実際にクエリーが実行されているのがわかります。一部のクエリーは悪質な用途に使われる可能性もあるもので、MCPサーバーを利用するうえでのさらなる問題を示しています。MCPサーバーに送られる指示はその動的な性質上、予測できないため、コード生成に利用する場合や、この例のようにSQLインジェクションが可能なケースでは、リスクがさらに高まります。

この問題をさらに複雑にしているのが、同じ指示でも文脈によって意味が変わるため、どの指示が悪質でどの指示が安全であるかを区別するのが非常に難しい点です。

MCPサーバーの利用リスクを大幅に高める根本的な要因は3つあります。1つ目は、内部リソース(ファイル、データベース、アプリケーション)に直接アクセスでき、場合によっては高い権限でアクセスできること、2つ目は、未検証または脆弱な外部リソース(Webサイト、API、インターネットコンテンツ)にアクセスする可能性があること、3つ目は、付与されたアクセス権限によっては内部ネットワークの境界の外にデータを移動できること、特に複数のツール、API、MCPサーバーを使用するエージェントを介する場合、境界を超えて送受信されるデータの流れを把握できず検証できなくなることです。

Splunk MCP TAを使えば、これまでアクセスも把握もできなかったこれらのデータを可視化および監視できます。これによって得られたデータを利用することで、MCPとのやり取りの中から、悪質な意図を含む可能性のあるデータを検出するための分析手法を開発できます。

Splunkによる分析

MCPを介したやり取りを可視化できれば、データと操作の流れを詳しく理解してその性質を見極めるための分析手法を開発できます。以下に、Splunk MCP TAで解析したMCPの操作をSplunkで表示した画面の例を示します。

権限昇格の試み

上の画面では、Postgres MCPサーバーにクエリーを実行して、一部のユーザーの権限を昇格しようとしていることがわかります。MCPのさらなる問題は、従来の脅威ベクトルを新たな形態のラッパーに覆い隠した状態で侵入させてしまうということです。以前であれば、SQLインジェクションのような脅威は通常、WAFによってエッジで検出できましたが、MCPサーバーとエージェントを使用する場合は、AIに指示の「意図」を解釈させることで実行できるため、内外のバックエンドまで到達できてしまいます。

次の例では、mcp.methodにsearch_filesを指定してparam.patternsフィールドから機密性の高い用語を検出できることがわかります。

これらの例から、MCPサーバーが高い権限を獲得してAPIキーやSSHキーにアクセスする状況が容易に想像できます。これもまた、特に公認の正式なMCPリポジトリや検証済みのMCPリポジトリが存在しない場合に、監視が不可欠であることを示す良い例です。

次の例は、同じロジックで、MCP Githubサーバーを組織への偵察活動に悪用できることを示しています。不正なMCPサーバーと乗っ取られたエージェントが、機密情報へのアクセスと窃取に利用される危険性がよくわかります。

MCPサーバーを利用することによってリスクが増幅する仕組みを実際の例を見ながら理解したところで、次に、現時点で考えられる、これらのリスクへの対処または緩和方法をご紹介します。

• 未知で未検証のMCPサーバーをインストールしない
• 信頼できない、検証されていない、または未知のドメインやAPIエンドポイントをブロックする
• これらのMCPサーバーの権限と相互接続を制限する
• エージェントのロジックやワークフローが最小権限の原則や職務分掌を上書きできないようにする
• 認証と認可を必須にする(現時点で最も実効性のある対策はOAuthトークンを使用することです)
• MCPサーバーのログ収集と監視を必須にする(対象には、アクセス、操作に関するメタデータ、セマンティックデータを必ず含めます)
• MCPサーバーが使用するリソースやツールに対しても、従来のセキュリティツールによる保護を適用する(DBプロキシ、WAF、ファイアウォール、EDRなど)
• MCPサーバーが使用する外部ツールやソース、そのトレーニングデータは、信頼できるものでも検証する(モデルの汚染、ドリフト、リソースハイジャックに注意する必要があります)
• タイムアウト、レート制限、コストガードを導入する
• 可能であればサンドボックスを使用する(隔離されたコンテナなど)
• MCP、LLM、エージェントのレッドチームテスト、ペネトレーションテスト、脆弱性評価を実施する

上記の対策は、MCPとエージェントの利用に伴うリスクの軽減に役立ちますが、MCPサーバーの安全基準を確立するには、まだ多くの作業が必要です。

STRTは、それらの処理を可視化し実用的なデータを収集するための新しい強力なツールをリリースしました。今後は、MCPサーバーが直面する個々の脅威に対処するためのコンテンツをリリースしていく予定です。

現在、AIの導入が急速に進むとともに、対処すべき重大なリスクも急増しています。慎重に進めていきましょう。

このブログはこちらの英語ブログの翻訳、山村 悟史によるレビューです。