クラウド環境
コンテナを活用してAIシステムのMCPインフラセキュリティを強化
MCPはAIシステムに恩恵をもたらす一方、新たな攻撃対象になる可能性もあります。対策として、MCPのコンテナ化と最小権限の原則を組み合わせたアプローチが有効です。
- 本稿は、MCPのセキュリティ強化をテーマとするシリーズの続編であり、コンテナを活用した保護対策に焦点をあてます。
- 以前のレポートでは、MCPサーバの過度な露出やシークレット管理の不備について取り上げ、プライベートデータの安全性が損なわれている点を指摘してきました。
- 放置状態のMCPサーバリポジトリは、AIサプライチェーン攻撃のリスクを生み出します。これを回避するために、検証済みのMCPサーバを利用することが推奨されます。
- MCPサーバのコンテナ化と最小権限の原則を組み合わせることで、AIセキュリティを大幅に向上できます。
はじめに
トレンドマイクロでは、AIシステムを支える「MCP（Model Context Protocol）」のセキュリティ強化に向けた取り組みを続けています。今回は、MCPサーバをコンテナに格納して保護するアプローチに着目し、その効果をクラウドワークロードの安全性向上やリスク軽減といった観点から評価しました。MCPは、AIアプリケーションがデータベースやAPIなどのサービスと自然言語でやり取りできるようにする仕組みであり、オープンソース標準となっています。これにより、LLM（Large Language Model：大規模言語モデル）を中心とする大規模かつ複雑なワークフローを、一層構築しやすくなります。
MCPは企業や組織にさまざまな恩恵をもたらしますが、一方でアタックサーフェス（攻撃対象領域）を広げるという側面もあるため、追加のセキュリティ対策が必要となります。そこで本稿では、「コンテナ」を活用してMCPサーバの安全性を高める方法について解説します。注意点として、コンテナは必ずしも安全性を保証するものではありません。不適切な用法は、かえって「安全だろう」という誤認識を生む可能性があります。本稿では、こうした危険性についても詳しく取り上げます。
以上に加え、放置状態のMCPサーバ・リポジトリがAIサプライチェーン攻撃に悪用される懸念や、コンテナ型MCPサーバを安全に設計する上で役立つ実践的対策についても、併せて解説します。
なぜMCPサーバが必要なのか
MCPの導入によって生じるセキュリティリスクを評価することは確かに重要ですが、まず、本当にMCPが必要であるかを見極めることが望まれます。そのためには、直面している問題の解決にLLMの推論やツールのオーケストレーションがどのように役立つかを明確化する必要があります。場合によっては、CLIやSDKを直接呼び出す方がジョブ構成を単純化でき、アタックサーフェスを狭められる可能性もあります。
LLMは、MCPサーバが提供するデータやツールと組み合わさることで、非決定論的（同じ入力に対して異なる出力を返すことがある）に動くアプリケーションの強い味方となります。しかし今回、実際に公開されているMCPサーバの数やその説明を調べた限り、SSHやコンテナレジストリのために本当にMCPが必要とされているのか、単に攻撃経路を増やしてしまっているのではないか、という疑問が生じます。
処理対象の入力データが複雑で整理されていない場合や、複数ツールを連携させたい場合、または人手の判断を組み込ませたい場合、MCPは確かに良い選択肢です。しかし、処理内容が決定論的でその範囲も明確に定まっている場合（例：単一のSSHコマンドを実行する、レジストリのタグ一覧を取得する、鍵をローテーションする）、よりシンプルな方式を選択肢に含めるべきです。
このように、MCPの強みを活用しながらも、不用意に攻撃経路を増やさないことが重要です。全てのワークフローや自動化タスクにLLMアプリケーションが必要とされているわけではありません。
検討の結果としてMCPが確かに有益と判断された場合は、可能な限り「標準入出力（stdio）」モードの利用が望まれます。このモードでは、MCPサーバがローカルプロセスとして動作し、クライアントとの通信を標準入出力経由で行います。TCPポートを開かければ、ネットワークへの露出を抑制できます。
コンテナによってMCPのセキュリティを強化
以降、コンテナを活用してMCPのセキュリティを強化する方法について解説します。また、22,000件のMCPリポジトリを対象とする調査を通して発見されたセキュリティ課題についても、併せて報告します。
MCPサーバの機能をサンドボックス化
MCPサーバによっては、リモートからのネットワーク呼び出しに対してローカルなシステムリソースを公開する形で、情報流出のリスクを抱えている場合があります。これは脆弱性というよりも機能的な仕様ですが、リスクを抑えて最悪の事態を避けるためにも、対策が求められます。
今回はデモとして、自動ブラウザ操作AI「Playwright MCP」を用いた攻撃の概念実証（PoC：Proof of Concept）を作成しました。ドキュメントに基づくと、HTTP転送を有効にしたスタンドアローン型のMCPサーバは、全てのクライアントに対してシステムリソースへのアクセスを許可します。
はじめに、Playwright MCPサーバに対して、アカウント情報を含むファイル「/etc/passwd」にアクセスするように指示しました。今回のサーバは、コンテナ内に隔離されています。しかし、プロセス自体をサンドボックス化していない場合、MCPサーバへのアクセス手段を持つ攻撃者であれば、機密性の高いローカルファイルを入手できる可能性があります。結果、サーバプロセスの権限設定に応じて、システムの認証情報ファイルやSSH鍵、クラウドアカウント認証情報などが流出するリスクが発生します。
また、MCPサーバがローカルホストからしか利用できないものと想定するべきではありません。必要な設定が施されていない限り、MCPサーバは全てのネットワークインターフェースを受信対象とします。仮にMCPサーバがローカルホストのインターフェースにしか露出していない場合でも、他のローカルユーザがMCPサーバの機能を悪用し、権限昇格などを試みる恐れがあります。MCPサーバが完全にネットワークに露出している場合のリスクは、さらに深刻なものとなります。
MCPの露出に関する実態を調べた結果、残念ながら、インターネットに露出したPlaywright MCP用サーバ・インスタンスが9件発見されました。
HTTPやSSE（Server-Sent-End）を通してMCPを操作するのは確かに便利ですが、先述の「標準入出力モード」に比べると、アタックサーフェスが拡大します。危険な設定例として、ネットワークで待ち受けるオプションを用いてMCPサーバを起動し、さらに「0.0.0.0（全インターフェース）」にバインドする方式が挙げられます。この場合、同じネットワーク上のどのホストからでも、MCPツールにアクセスできるようになります（クラウドやNATに設定不備があると、さらに広範に及ぶ可能性もある）。仮に「ただの一時的なローカルテストだから」という理由があったとしても、その間に同じネットワーク内の同僚や共有ラボのサブネット、オフィス内のポートスキャンによって容易に発見され、操作される恐れがあります。
以上を踏まえると、MCPサーバをコンテナ内で動かす際には、ネットワークアクセスを必要最小限に留めることが重要です。特に、ホスト側のネットワークをコンテナ向けに共有する設定（下記のオプション）は、避けることを推奨します。
--network=host
また、MCPサーバに付与する権限や機能は、常に機能上必要な最小限に抑えるべきです。こうした対策により、水平移動・内部活動（Lateral Movement）のリスクが軽減されます。
「読み取り専用による保護」と「サードパーティーへのセキュリティ委譲」
前回の調査では、認証機構を持たないMCPサーバが外部公開され、プライベートなデータソースが情報流出のリスクに晒されている点を指摘しました。初期のMCPプロトコル仕様では、認証や認可に関する議論が行われていませんでした。一方、現在の仕様では、認可が「オプション」として扱われています。しかし、前回の調査では、サーバ構築用MCPフレームワークに含まれる認証機能が、実際には広く採用されていないことが判明しました。結果、MCPのセキュリティは、完全にDevOpsチームやサードパーティー製ソリューションに委ねられています。
こうした懸念がユーザから挙がったことを受け、各コミュニティの開発者は、MCPサーバにセキュリティ機能や読み込み専用機能を組み込み始めています。しかし、他のコードベース同様、バグの可能性は常に存在します。実際、今回調査した22,000件のMCPサーバのうち、6,032件に読み込み専用のセキュリティ機能が見られましたが、その全てが適切に構成、実装されていたわけではありません。
今回の分析では、下記に示す2種の脆弱性が確認されました。
- 読み取り専用の保護機能をLLMに任せきっている：こうした方式では、偶発的または意図的にLLMがMCPツール側の説明を無視し、想定の保護機能をすり抜けてしまうリスクがある。また、LLMを介さずにMCPツールに直接アクセスされた場合も、保護機能が全く働かないことになる。
- 機能実装上の不備がある：例として、MCPツールの入力フィルタリングに先立って行うべきバリデーションや変換処理が欠落している、引数埋め込み文への考慮漏れによってフィルタリングを回避できてしまう、などのケースが挙げられる。
- サードパーティー製コンポーネントに不備がある：オープンソースライブラリやクローズドソースライブラリの依存関係に脆弱性が潜んでいる、などのパターンが考えられる。
読み取り専用機能の抜け道や、利便性を優先した危険なコマンド実装は、攻撃者や不正なAIエージェントによって悪用される可能性があります。すでにトレンドマイクロでは、「Zero Day Initiative」を通して複数の脆弱性を報告してきました。こうした脆弱性を避ける上で有効な対策を、下記に示します。
- MCPサーバコンテナがデフォルト状態で安全だと過信しない。デフォルトはあくまでも出発点と捉え、利用環境に合わせたセキュリティ調整を細かく行う。
- LLMやMCP側の「セキュリティ機能」のみに頼るのではなく、データソース側のアクセストークンや権限設定を細かく調整する。
- MCP専用のアクセストークンを作成し、「読み取り専用」に設定する。
さらに、MCPサーバ用コンテナの権限や機能を制限することで、水平移動・内部活動のリスクを削減できます。例えば、リンクされたデータソース以外へのネットワークアクセスを禁止することにより、他のプライベートなデータソースに対するアクセスを遮断できます。
MCPサーバがリモートコード実行の脆弱性を抱えている場合でも、権限や機能が制限されていれば、基盤ホストなどへのアクセスを阻止できる可能性が高まります。コンテナ自体は侵害されるかも知れませんが、少なくとも、簡単にはシステム侵害に至らせない仕組みが追加されます。
コンテナ隔離のアプローチは、MCPサーバを介したプライベートネットワークへの水平移動や、他サービスの不正利用を防止できる可能性が、確かにあります。
しかし、コンテナ隔離の措置を取っていても、過大な権限を持つプライベートアクセストークンを運用しているのであれば、それが水平移動・内部活動に悪用され、クラウドサービス上のデータソースにアクセスされる恐れがあります。こうした事態を防ぐためには、コンテナ隔離に加え、RBAC（ロールベースアクセス制御）を適切に設定し、最小権限やゼロトラスト・ポリシーといった基本原則を守ることが重要です。
認証情報の露出
APIやデータベース、クラウドアカウント、社内ツールといったプライベートなデータソースへのアクセスには、認証情報（いわゆるシークレット）が必要となります。MCPサーバをコンテナ内に安全にデプロイすることで、MCPの動作に必須でない認証情報（コンテナ内に格納されない）へのアクセスを防ぐことは可能ですが、全ての認証情報を完全に保護できるわけではありません。
コンテナを利用すれば、的確なシークレット管理を通して情報流出のリスクを抑制できます。しかし、過去の報告でも述べたように、それは「不適切な運用習慣」を埋め合わせるものではありません。
MCPサーバの評判と利用状況
MCPが最初に出現したのは、2024年10月のことです。以降、MCPサーバリポジトリの件数は、22,000以上にまで急増しました。ここで生じる疑問は、「個々のMCPサーバが安全かつ信頼できる設計になっているかを、どのように判別するか」という点です。
今回の調査では、MCPマーケットプレイス上で入手可能な22,000件以上のMCPサーバ・コードリポジトリを分析しました。これらのマーケットプレイスでは、さまざまなMCPサーバの一覧が提示され、対応する機能説明や利用可能なツール、デプロイ設定などの情報も添えられています。さらに重要な点として、開発ソースコード・リポジトリへのリンクも含まれています。
しかし、行き先のコードリポジトリ自体が削除されている、または非公開に設定されているケースが、746件見つかりました。対象のMCPサーバは、マーケットプレイスの一覧に残されているものの、ソースコードのリポジトリはすでになく、いわば「宙ぶらりんの参照構造」を形成しています。
こうした状況は、かなり危険です。例えば、元の管理ユーザが本当に活動を止めている場合、同じリポジトリ名を取得した第三者により、放置状態のエントリを「復活」させられてしまう恐れがあります。
GitHubのユーザ名が一度解放されると、誰でも同名で再登録できるようになります。そこに目をつけた攻撃者は、元の管理者と同じユーザ名を受け継いでリポジトリを再作成し、以前と似たアドレスの配下に不正なバージョンのMCPサーバを配備する可能性があります。マーケットプレイス内のリンクを辿ったユーザ側では、それが不正なものと知る由もなく、真っ先にクローン作成に走ることも多いでしょう。これは、マーケットプレイスの信頼を逆手にとった手口であり、AI時代におけるサプライチェーン攻撃の典型例と言えます。
多量に存在するMCPサーバの森をかき分けて、その一つ一つの安全性を見極めていくのは、非常に骨の折れる作業となります。対策として、検証済みのMCPサーバ用コンテナイメージを利用することが挙げられます。特に、ベンダー署名付きのコンテナイメージを用いるようにすれば、コードの真正性を保証し、改ざんバージョンや旧バージョンを誤って稼働させるリスクを軽減できます。
MCPサーバをコンテナ内で動かすことで追加の隔離層が生まれ、サーバ侵害に伴う影響を低減できます。また、イメージ検証とコンテナ隔離の両者を組み合わせることで、エコシステムの急拡大に伴う「信頼性」と「メンテナンス性」の課題に対処しやすくなります。
なお、検証済みのコンテナイメージを用いることで、非公式、脆弱、不正なイメージを誤って利用するリスクは確かに減らせますが、ベンダーやコンテナレジストリ自体が侵害されるサプライチェーン攻撃までは防げません。安全性が完全に保証されたわけではないことに、注意する必要があります。
コンテナ化に伴う最小権限の原則
MCPのセキュリティ対策においては、「最小権限の原則」を遵守することが、極めて重要です。この原則は簡潔で、測定しやすく、チェックリスト方式で検証できます。ソフトウェアにバグはつきものであり、MCPサーバも例外ではありません。攻撃者がMCPサーバ上でコードを実行するに至った場合でも、せめて、過大な権限を持つトークンや強力なOS機能を持つプロセスが稼働している状況だけは、避けたいところです。
一連のリスクを軽減する現実的な対策として、サーバの機能や権限を制限することが挙げられます。この方式ならば、テストを行いやすく、ルールとして運用し、監査対象に加えることも可能です。
MCPサーバをコンテナ内で稼働させる際のベストプラクティスを、下記に示します。
- IDやトークンの管理：
- 各MCPサーバに対し、専用のサービスアカウントやクライアントIDを割り当てる。サーバやツール間で同一トークンを使い回さない。
- 短期間だけ有効な認証情報（OIDCやSTS）を使用し、TTL（有効期限）を日単位ではなく分単位で設定する。
- トークンのスコープは、必要なAPIや操作のみに限定する。ワイルドカード指定は避ける。
- 可能な限り、トークンをアクセス対象サービス（オーディエンス）や発行元（オリジン）に紐づける。リフレッシュ操作は、必要な場合にのみ有効化する。
- プロセスやコンテナの実行環境：
- ルート権限では実行しない。全てのケイパビリティを除去した上で、本当に必要なものだけを追加し（多くの場合、追加は不要）、オプション「no-new-privileges」を有効化する。
- ルートファイルシステムを読み取り専用にする。必要に応じて、小容量の書き込み領域「tmpfs」をマウントする。
- 「seccompのデフォルトプロファイル」や「AppArmorプロファイル」、「SELinuxプロファイル」を有効化する。
- イメージ内にシェルを含めない（bashやパッケージマネージャを本番イメージに入れない）。
- ファイルシステムとマウント：
- サーバが必要とするディレクトリのみをマウントし、可能な限り読み取り専用にする。
- DockerソケットやSSHエージェント、クラウドCLIプロファイル、自身のホームディレクトリを決してマウントしない。
- ネットワーク送信：
- デフォルトでは、すべての送信を拒否する。サーバがアクセスする必要のあるエンドポイント（例：特定のAPIホスト名）のみを許可する。
- HTTPやSSEを使う場合は、「127.0.0.1」にバインドする。可能ならば、リスニング用ソケットを避けて標準入出力（stdio）を使用する。
- ツールの用法：
- 高リスクのツール（ファイル書き込み、シェル、クラウド管理）はデフォルトで無効化しておき、必要な場合のみ、個別に有効化する。
- コマンドやパス、リソースに関しては、ブラックリスト方式ではなくホワイトリスト方式で制限する。
- シークレットの管理：
- 認証情報のハードコーディングは避け、必要な場合にVault（専用の保管庫）などからオンデマンドで取得する。
MCPサーバのコンテナを長期的に存続させないこと、個々のアクセストークンを単一のAPIに限定することが理想的です。さらに、コンテナに書き込み用マウントやシェル、不要なLinuxケイパビリティを持たせないこと、ネットワークアクセスの範囲を最小限に抑えることが推奨されます。こうした最小権限の原則を徹底することで、仮にサーバが侵害されても、その影響は小範囲にとどまり、検知も行いやすくなります。
また、見落とされがちで重要な強化策が、コンテナ内のプロセスを非ルートユーザとして実行することです。コンテナは隔離環境を提供しますが、もしコンテナのプロセスがルートで動いていて、攻撃者がアプリケーションからコンテナ環境に抜け出した場合、ルートの権限を引き継ぎ、被害を拡大させる恐れがあります。
さらに安全性を高めるための考慮事項として、トレンドマイクロによる過去のレポートでは、「distroless」のイメージによるコンテナ最小化、ベンダー提供コンテナを強化するためのカスタムコンテナ、Docker内で特権コンテナを稼働させるリスクやその対策について、取り上げています。
今回分析した22,000件のMCP関連GitHubリポジトリのうち、Dockerfileを含むものは5,414件あり、コンテナ化の対応がとられていました。しかし、その中で明示的に低権限ユーザを設定していたのは、わずか1,276件にとどまります。反対に、ルートを積極的に利用しているものが96件確認されました。残りの大半は、ベースイメージのデフォルトユーザ（多くの場合、ルート）に依存していました。
（https://github.com/thomasgazzoni/vsc-mcp/blob/master/Dockerfile）
以上の発見事項は、「デフォルトで安全」という見方に大きな問題が潜んでいることを示しています。コンテナは確かに有効な保護機構を提供しますが、コンテナ内の権限を調整しないまま運用すると、セキュリティモデルの全体が崩れ、MCPサーバは権限昇格攻撃に晒されます。言い換えれば、提供されているMCPコンテナが常に安全とは限らず、個別での評価と調整が求められます。
企業や組織では、MCPがもたらす業務運用上の効果を慎重に評価し、そのメリットが確認された場合は、広がるアタックサーフェスを保護することが重要です。最小権限の原則に従ったコンテナ化は、MCP利用に伴うセキュリティリスクをカバーするための現実的なアプローチと言えます。
コンテナによってMCPを強化する際には、さらにコンテナインフラやソフトウェアサプライチェーン、ランタイム、その間で動作するプロセスを保護するために、適切なセキュリティツールやポリシーを導入することが推奨されます。
セキュリティソリューション「Trend Vision One™ Container Security」は、高度なコンテナイメージ・スキャンやポリシー準拠の管理制御、ランタイム保護、検知・応答機能を備え、透明性や簡潔性を保ちながら、エンド対エンドのコンテナセキュリティを確保します。本ソリューションによって企業や組織では、コンテナ内に潜む脆弱性やマルウェア、コンプライアンス違反といったリスクを早期に検知し、被害が発生する前に封じ込めることが可能です。
「Trend Vision One™ Security Operations」は、新たなセキュリティレイヤーによってAIスタックを手厚く保護します。その強みは、業界屈指の網羅性を有するネイティブセンサーであり、具体的な行動に繋がる情報を提供するとともに、中央管理の行き届いた可視性や、迅速な対応を実現します。「Security Operations」は、以下の3コンポーネントから構成されています。
- Agentic SIEM：膨大なデータを取り込み、リアルタイムで脅威を検知する。
- Agentic SOAR：AIを活用したSOCワークフローによって手作業を削減し、対応の効率化を実現する。
- XDR：ネイティブおよびサードパーティーのテレメトリ情報を統合し、単一のコンソールから業界屈指の網羅性を備えたセンサーを管理する。
参考記事：
Using Containers to Secure Your MCP Infrastructure
By: Alfredo Oliveira, David Fiser
翻訳：清水 浩平（Core Technology Marketing, Trend Micro™ Research）