MCP のセキュリティ：コンテナ化と Red Hat OpenShift の統合

過去 3 回の記事では、 現在の脅威の状況の分析、 堅牢な認証と認可の実装、および重要なロギングおよびランタイムのセキュリティ対策の調査を通じて、保護された Model Context Protocol (MCP) エコシステムの基礎について確認しました。これらは、誰が何にアクセスできるか、それらのやり取りをどのように監視するかに焦点を当てるものでした。今回は、これらのシステムが存在する物理環境と仮想環境に焦点を移します。 

もちろん、セキュリティを重視した開発がすべての課題に対応するわけではなく、これが対応できるのはその半分にすぎません。セキュリティ保護の脆弱な MCP サーバーをデプロイすると、最も堅牢なコードさえも無効になってしまう可能性があります。これは、安全ではないネットワークインターフェースにバインドされていたという理由だけで、認証されていない公開サーバーの脆弱性が悪用された、最近の NeighborJack 攻撃などのインシデントが示すとおりです。業界が高度に自律的なエージェント型 AI へと移行する中、デプロイメントを保護して安全を確保することの重要性はかつてないほど高まっています。 

この記事では、 Red Hat のテクノロジー、とりわけコンテナ化と Red Hat OpenShift を活用して、非 root コンテナ、読み取り専用ファイルシステム、および厳密なネットワークポリシーを使用する「セキュリティファースト」のデプロイメントを作成し、本番環境の MCP サーバーをより効果的に保護する方法について説明します。

インフラストラクチャの保護

堅牢なコードは不可欠ですが、 MCP サーバーのセキュリティ体制は、その環境によって左右されます。Red Hat は、組み込みの分離機能やカーネルレベルのセキュリティ機能を利用するために、 MCP サーバーをコンテナ内にデプロイすることを推奨しています。OpenShift と統合することで、デプロイメントを大幅に堅牢化できる、セキュリティ重視の高度なデフォルト設定をすぐに利用できるようになります。真に「セキュリティファースト」な MCP デプロイメントを実現するには、戦略において次の 3 つの柱に重点を置く必要があります。

1.ランタイム環境の堅牢化

攻撃者が足がかりを得るのを防ぐには、オペレーティングシステム (OS) レベルでコンテナの動作を制限する必要があります。

• 非 root での実行：MCP サーバーは、決して root 権限で実行しないでください。これにより、プロンプト注入などによってツールがリスクに晒された場合でも、攻撃者がホストレベルのファイルやデバイスインターフェースにアクセスするのを防ぎます。
• 読み取り専用ファイルシステムの強制：root ファイルシステムを読み取り専用としてマウントすることで、tool poisoning (ツール汚染) や不正な永続化から保護します。書き込みを /tmp などの特定のディレクトリに制限することで、攻撃者がサーバーの動作を変更したりマルウェアを埋め込んだりすることを困難にします。
• 危険な機能の破棄：API 呼び出しやファイル I/O など、ほとんどの MCP 機能は高度なカーネル権限を必要としません。たとえば、 capDrop: ["ALL"]) を使用してすべての Linux 機能を明示的に破棄することで、カーネルを経由した権限昇格を防ぐことができます。

2.攻撃対象領域の最小化

潜在的な侵害の影響範囲を縮小する方法は、コンテナイメージ自体から始まります。

• 最小限のベースイメージの使用する：Universal Base Image (UBI) の minimal イメージまたは distroless イメージを使用してサーバーを構築します。シェル、コンパイラ、不要なユーティリティを除外することで、侵入後に攻撃者が横展開するのに必要となるツールそのものを排除できます。
• Red Hat Quay による自動スキャン：Quay でイメージをホストすることで、継続的な脆弱性スキャンが可能になります。これにより、Python や Node.js の依存関係によって、既知の共通脆弱性識別子 (CVE) が本番環境に導入されないようにします。
• カーネルの堅牢化：OpenShift では、デフォルトの SELinux の強制適用を維持し、サーバーをネットワークおよびファイル操作に不可欠なシステム呼び出しのみに制限する seccomp プロファイルを適用する必要があります。

3.ネットワーク分離とトラフィック制御

最後に、 MCP サーバーがインフラストラクチャの他の部分と通信する方法を厳密に制御する必要があります。

• ゼロトラストネットワーク：OpenShift NetworkPolicies を使用して、許可されたサービス (特定のエージェントゲートウェイなど) のみが MCP サーバーに到達できるようにします。
• 保護された Egress：サーバーが気象情報ツールやデータツールなどの外部 API を呼び出す必要がある場合は、送信トラフィックをそれらの特定のドメインのみに制限します。
• 高度な保護：機密性の高い環境向けに、Red Hat OpenShift Service Mesh は相互トランスポート層セキュリティ (mTLS) とクライアントごとの認証を提供し、アプリケーションレベルの OAuth の上に ID ベースのセキュリティ層を追加します。

単なるデプロイにとどまらず、これらの OpenShift ネイティブのセキュリティ重視の機能を活用することで、外部の脅威や内部の脆弱性の悪用から MCP ツールを保護する、堅牢な基盤を構築できます。

まとめ

MCP サーバーのデプロイは、単にコードを実行するだけにとどまりません。重要なのは、AI 駆動型のエコシステム固有の圧力に耐えられる、強固な境界を構築することです。この記事で紹介したように、Red Hat OpenShift とコンテナ化を統合することで、非 root 実行から厳格なネットワークポリシーに至るまで、ツールがセキュリティリスクとなるのを防ぐために必要なガードレールを提供できます。 

デプロイ環境についても、ソースコードと同様に、セキュリティを重視した厳格な管理を行ってください。そうすることで、機能的な PoC と、堅牢で本番環境に対応したサービスとの間のギャップを埋めることができます。より強力なエージェント型 AI システムの開発を進めるにあたり、これらのインフラストラクチャに関するベストプラクティスを実践し続けることで、現在の脆弱性と将来の新たな脅威の両方からシステムを防御することができます。