「MCP」が危ない――使うなら無視できない“5大リスク”とその解決策:生成AI時代の“新標準”に隠れた課題
生成AIツールと外部システムとの連携を促進する「Model Context Protocol」(MCP)。そのセキュリティリスクは、どのようなものなのだろうか。主要な5つのセキュリティリスクと、その対策を確認しよう。
2024年11月にAI(人工知能)ツールベンダーAnthropicが公開した「Model Context Protocol」(MCP)は、生成AIツールと他のシステムを接続するための標準規格として急速に普及している。登場して間もないものの、MCPはさまざまなベンダーやAI専門家の間で採用が進む。
相当な数の「MCPサーバ」がさまざまなところで稼働し、生成AIクライアント(生成AIツールのフロントエンドアプリケーション)から、さまざまなアプリケーションやサービスへの接続を実現している。MCPサーバとは、生成AIクライアントに対して外部サービスやデータへのアクセス手段を提供するサーバプログラムのことを指す。
MCPの大きな懸念は、それがもたらすセキュリティリスクだ。MCPには、これまでに幾つかの脆弱(ぜいじゃく)性が見つかっている他、セキュリティのメカニズムや管理体制がまだ十分ではない。ユーザーはMCPの仕組みや関連するセキュリティリスク、脆弱性の軽減策を理解することが必要だ。
MCPはどのようにAIモデルと外部サービスを接続するのか
生成AIクライアントは、MCPサーバから次の3種類の要素を取得して利用できる。
- リソース
- 生成AIクライアントが読み込むデータ。ローカルファイルに加え、API(アプリケーションプログラミングインタフェース)を通じて外部システムから取得するデータを含む。
- ツール
- MCPサーバが提供する機能や処理手段。生成AIクライアントは、MCPサーバを通じてこれらを呼び出すことで、APIによる連携やデータ操作といったタスクを実行できる。
- プロンプト
- 特定の処理を実行するために使用する、プロンプト(生成AIクライアントに対する指示)の作成済みテンプレート。生成AIクライアントが目的に沿った内容を出力できるように補助する。
リソースやツール、プロンプトを提供する外部サービス(サードパーティーサービス)と通信するには、MCPサーバは事前にそのサービスとの認証を済ませておかなければならない。具体的にはMCPサーバが動作するコンピュータ(以下、MCPホスト)に、APIキー(APIを利用するための認証情報)やシークレット(認証用の秘密情報)などの認証情報を保存し、サードパーティーサービスとの通信のセキュリティを確保する。
MCP仕様の2025年3月版は、標準仕様「OAuth」に準拠した認可方式を正式に選択肢として位置付けた。サードパーティーサービスにアクセスする場合には、OAuthの利用を推奨している。生成AIクライアントはOAuthを利用する場合、MCPサーバを介して取得したサードパーティーサービスのアクセストークン(認可用の資格情報)を用いることで、そのサービスのAPIにアクセスできる。ただしOAuthを必須化したわけではなく、APIキーなどのローカルな認証情報によってアクセスする実装が依然として一般的だ。
MCPの5つのセキュリティリスクと軽減策
生成AIクライアントがサードパーティーサービスの呼び出しやデータの利用、コマンドの実行などを、安全な手順で実行できるようにするために、MCPは役立つ。ただしMCPは、その仕組みの特性上、適切に管理できないとセキュリティリスクが生じる可能性がある。MCPのセキュリティリスクとして特に重要なのは、以下の5つだ。
- 認証情報の漏えい
- セキュリティ未検証のMCPサーバの存在
- プロンプトインジェクション攻撃
- 生成AIツールに悪意のあるプロンプトを送って、意図しない動作を引き起こす攻撃。
- MCPサーバへの攻撃
- マルウェアや不正な処理
1.認証情報の漏えい
最も重要なMCPのリスクは、認証情報の漏えいだ。MCP準拠の生成AIクライアントは、設定ファイルにAPIキーやシークレットといった認証情報を保存し、これらのデータをサードパーティーサービスにアクセスする際に使用することがある。攻撃者が生成AIクライアントに侵入した場合、保存されている認証情報を使って、クラウドサービスや社内システムに不正アクセスできてしまう可能性が否定できない。
MCPサーバがOAuth認証を実装している場合、これを利用することで、認証情報の漏えいリスクを軽減できる。Cloudflareの同名CDN(コンテンツデリバリーネットワーク)サービスや、MicrosoftのAPI管理サービス「Azure API Management」など、OAuth認証を提供するプロキシコンポーネント(認証ゲートウェイ)をMCPサーバの前段に設置することでも、同様のリスク軽減が可能だ。
OAuthを利用できない場合の選択肢として、認証情報をMCPサーバの設定ファイルに直接書き込んで運用する方法がある。ただし、この方法は情報漏えいや管理負担増大のリスクを伴うため、安全性を確保できる環境に限って採用すべきだ。
MCPサーバを利用する際には、生成AIクライアントに認証情報を渡す方法を検討する必要がある。運用形態によっては、設定ファイルをクライアントデバイスに配布する手法を採用することもある。ただし設定ファイルを安全かつ効率的に管理する決定的な方法は、まだ確立されていない。暫定的な手段としては、ユーザーが生成AIクライアントにアクセスするための仮想デスクトップインフラ(VDI)を用意し、設定ファイルをそのVDI内に集中的に配置する方法がある。この方式であればAPIキーを一元管理でき、クライアントデバイスごとに設定ファイルを配布する必要がない。
2.セキュリティ未検証のMCPサーバの存在
公開中のMCPサーバの中には、コミュニティーメンバーや個人開発者が作成したものが相当数ある。こうしたMCPサーバの中には、機能していても継続的に保守されていなかったり、脆弱性が放置されていたりするものが存在し得る。正常に動作しているように見せかけながら、認証情報を抜き取る目的のMCPサーバが紛れている危険性は否定できない。
このようなリスクを避けるには、開発元が明確で、信頼性が検証済みのMCPサーバのみを使用することが重要だ。例えばGitHubが、同名ソースコード共有サービスで公開している「GitHub MCP Server」のように、公式または提供元が明確なリポジトリ(ソースコード格納庫)から入手できるMCPサーバを選ぶとよい。Microsoftなど、一部のベンダーは自社で確認したMCPサーバの一覧を公開している場合があるため、導入前には提供元や更新状況、ライセンスなどを確認することが大切だ。
3.プロンプトインジェクション攻撃
MCPを利用する場合、プロンプトインジェクション攻撃に起因するリスクが発生し得る。MCPでは、サードパーティーサービスと連携するためのリソースやツール、プロンプトに関する定義情報(メタデータ)が、生成AIクライアントに渡る。信頼性の低いMCPサーバを利用すると、こうしたメタデータが不適切な指示や悪意ある内容を含んでいても、ユーザーが気付きにくい。生成AIクライアントがそれを正規の設定や入力として処理すると、データ漏えいや不正操作につながる恐れがある。こうしたリスクを避けるには、開発元や運用体制が明確で、信頼性を検証済みのMCPサーバやサードパーティーサービスのみを利用することが重要だ。
4.MCPサーバへの攻撃
コミュニティーが公開しているMCPサーバのソースコードを、攻撃者が書き換えてマルウェアや不正な動作を仕込む可能性がある。MCPサーバのインストールには一般的に、「pip」「npm」といったスクリプト言語用のパッケージ管理ツールを使う。これらのパッケージ管理ツールは、指定のパッケージを外部のリポジトリから自動的に取得してインストールする仕組みを持つ。そのため事前にユーザーが中身を確認せずに導入してしまう可能性がある。
不正要素の混入を見抜くには、本来であれば「パッケージアナライザー」など、パッケージの内容や依存関係を解析する専用ツールを使う必要がある。そうしたツールを導入していない場合、MCPサーバやその関連モジュール(MCPコンポーネント)が改ざんされているかどうかを見分けるのは難しい。
5.マルウェアや不正な処理
MCPサーバは、実装によってはMCPホストでコマンドやファイル操作を実行できる。そのため攻撃者が、あらかじめMCPサーバやその関連パッケージを改ざんして仕込んでいたマルウェアや不正な処理を、そのコンピュータで実行できてしまう危険性がある。ユーザーがMCPサーバに付与している権限や実行範囲を十分に把握していないと、こうした危険性に気付けず、被害が表面化しやすくなる。
生成AIクライアントはMCPサーバに接続することで、そのMCPサーバが提供するリソースやツール、プロンプトを呼び出せるようになる。これらを呼び出す際、生成AIクライアントがユーザーに対して利用許可を求めることがある。この許可は個別の処理単位ではなく、その後に実行する関連要素全体への包括的な許可となる場合がある。ユーザーは、許可対象となるリソースやツール、プロンプトの挙動を全て把握できるとは限らない。そのため結果としてファイル削除や設定変更など、意図しない操作を許してしまう可能性がある。
MCPサーバを安全に運用するためには、幾つかの対策がある。
1つ目は、信頼できる隔離環境でMCPサーバを実行することだ。例えばMCPホストのOSから分離したコンテナで動かすことで、MCPサーバがアクセス可能な範囲を制限できる。一部のMCPサーバはコンテナ実行用の設定やイメージを用意しており、オープンソースのコンテナ管理ツール「Docker」向けのMCPコンポーネント集(いわゆる「MCP Hub」)で公開されているものもある。
2つ目は、不必要なコマンドを実行できないようにMCPサーバの動作を制限することだ。特にファイルの操作や実行を伴う機能を無効化する設定は効果がある。一般的にはMCPホストごとに設定が必要な点に注意が必要だ。推奨の運用方法として、MCPサーバに渡すAPIキーを読み取り専用の権限に限定し、書き込みや実行権限を持たせないことが挙げられる。これにより、万一悪用された場合の被害範囲を限定しやすくなる。
Copyright © ITmedia, Inc. All Rights Reserved.