powered by TechFeed
表示モード
Deep Dive

AIの展開にセキュリティが追いつかない — MCPサーバーを「後から気づいた」では遅い理由

10月29日、CSO Onlineが「Securing MCP servers before the AI rollout outpaces security」と題した記事を公開した。「CTOがLLMベースのアプリケーション導入を決め、取締役会も承認した。あなたはその後に聞かされた」——そんな状況が各所で繰り返されているという。AIアプリケーションの展開が先行するなかで、MCPサーバーを安全に実装するための実践的な管理策を詳しく紹介している。

10月29日、CSO Onlineが「Securing MCP servers before the AI rollout outpaces security」と題した記事を公開した。「CTOがLLMベースのアプリケーション導入を決め、取締役会も承認した。あなたはその後に聞かされた」——そんな状況が各所で繰り返されているという。AIアプリケーションの展開が先行するなかで、MCPサーバーを安全に実装するための実践的な管理策を詳しく紹介している。


MCPサーバーとは何か

MCP(Model Context Protocol)サーバーは、1990年代のODBCに近い存在だ。ODBCが登場する以前、アプリケーションはデータベースごとに専用のカスタムコードを持つ必要があった。ODBCは「データベースとの通信方法」を標準化し、各ベンダーがドライバを用意するだけで済む仕組みを作った。

MCPも同じ発想で動く。Anthropicが策定しオープンに公開された標準プロトコルであり、AIアプリが多様な外部ツールやデータソースと接続する際の"共通言語"として機能する。AIアプリは標準化されたメソッドでローカルのMCPホストと通信し、データベース・ファイル共有・CRMなど各ツールがMCPサーバーを通じてネイティブ形式に変換する。つまり、MCPホスト上にドライバを1つ用意すれば、任意のエンドポイントと接続できる。

1つのMCPホストが複数のMCPサーバーにアクセスできるため、スケーラビリティは高い。ただし、それだけリスクの経路も増える。実装が先行しがちな現状で、セキュリティ設計が後回しになりやすい構造的な問題がここにある。


優先して実装すべきMCP管理策

MCPサーバーの実装が進みすぎる前に、以下の要件を定義することが重要だ。

最も重要な2つ:入力検証と最小権限

入力検証・サニタイズは最優先で対処すべき領域だ。外部の間接的なソースからの入力はすべて「信頼できない」として扱い、高リスクと見なす必要がある。具体的には、強力な認証・認可の実装、悪意あるコードやジェイルブレイク試行の検出、機微データや規制対象データのフィルタリングが含まれる。MCPがAIと外部リソースの橋渡しをする構造上、プロンプトインジェクションや間接的な命令注入のリスクが特に高く、入力経路を厳密に管理することが前提となる。

最小権限の原則も同様に重要だ。攻撃者が侵入した際の「爆発半径」を最小化するために、権限設計が鍵を握る。類似したアクセス要件を持つツールをグループ化して複数のMCPサーバーに分散させることで、過剰な権限付与を防げる。また、トークンの有効期限はできる限り短く設定すること。トークンが盗まれた場合のダメージを抑えるためだ。この2点は、他の管理策の効果を最大化するための土台でもある。後述する管理策の多くは、入力検証と最小権限が機能していることを前提として成り立つ。

その他の管理策

以下は上記2点を補完する形で実装すべき管理策だ。それぞれ独立した対策ではなく、組み合わせることで多層防御を構成する。

  • 出力検証・サニタイズ:特定の構造を強制してバリデーションを容易にする。財務レポートなどリスクの高いアウトプットには人間によるレビューを組み込む。AIが生成した出力をそのまま後工程に渡さない、という発想が重要だ。
  • ネットワーク分離:MCPホストをセグメント化し、承認済みのシステム・ポートのみに通信を制限する。侵害が発生した場合の横展開を防ぐ最初の壁となる。
  • サーバーハードニング:CISベンチマークなどの包括的なガイドラインに従って構成する。不要なアカウントの無効化、未使用ポートのクローズが基本。IaC(Infrastructure as Code)を活用してサーバーをエフェメラル(使い捨て)にすることで、侵害の拡大リスクをさらに下げられる。
  • 暗号化:保存時・転送時ともにエンドツーエンドで暗号化し、強力な鍵管理を実施する。
  • ツール管理:MCPホスト上で利用可能なツール数を絞り、各ツールの権限を必要最小限にとどめる。接続先が増えるほど攻撃面が広がるため、不要な接続を排除する姿勢が求められる。
  • サードパーティ評価と契約:外部プロバイダーがSOC 2、HITRUST、ISO 27001/2などの第三者認証を取得していることを確認する。PHI(保護医療情報)が関与する場合はBAA(Business Associate Agreement)の締結が必要だ。
  • 監査・ロギング:AIの動作やプロンプトの詳細なログを維持することで、ハッキング試行やプロンプト悪用を検知する。ログがなければインシデント発生後の原因究明も困難になる。
  • Human-in-the-Loop:高リスクなアクションや重要データを生成する前に、人間による確認ステップを挟む。自動化の恩恵を享受しながらも、最終判断を人間が担う設計は今後のAIガバナンスの基本姿勢となりつつある。

見落とされがちな「本番前テスト」

記事が特に強調するのが、本番前テストの重要性だ。実施すべきテストの例として以下が挙げられている。

  • 偽のPHI、SSN、口座番号などを入力し、センシティブデータが正しくフラグ付け・ブロックされるかを確認する
  • ログインして認証・認可をテストし、参照・アクセスできるツールを確認する
  • インバウンド・アウトバウンドのネットワークフィルタリングをテストし、承認済みシステムのみ到達可能なことを確認する
  • サーバーがハードニングポリシーに従って構成されていることを確認する
  • すべての重要イベント・アクションがロギングされていることを確認する

リスク管理の「伝え方」も重要

CTOが管理策の実装に同意しない、または日程が曖昧なままという状況は珍しくない。その場合、リスク委員会を活用することが有効だ。

技術的なリスクをビジネス言語で伝えることがポイントだ。「生産性の損失」「ダウンタイム」「顧客信頼の喪失」「規制上の罰金」、業界によっては「患者ケアへの影響」「取引エラー」「不公平な保険引受」「労働者の安全」といった観点で説明する。数値化(定量的評価)にこだわらず、定性的に、しかし根拠を説明できる状態で臨むことが推奨されている。

脅威リストの出発点としては、OWASP Top 10 for LLM Applicationsが参照されている。初回のアセスメントではスピードを優先し、発生可能性が「非常に低い」または「低い」脅威は除外してよいとしている。


MCPサーバーを取り巻くセキュリティの議論はまだ成熟段階にあり、実装が先行してしまいやすい領域だ。「後から気づいた」では遅い管理策を、展開の初期段階で定義しておくことが求められる。

詳細はSecuring MCP servers before the AI rollout outpaces securityを参照していただきたい。