Oracle Cloud InfrastructureでのMCPサーバーの保護 (2026/04/20)

Oracle Cloud InfrastructureでのMCPサーバーの保護 (2026/04/20)

https://www.ateam-oracle.com/securing-mcp-servers-on-oracle-cloud-infrastructure

投稿者:Ramesh Balajepalli | Master Principal Cloud Architect

AIは、企業システムの構築と運用方法を変革しつつあります。モデルコンテキストプロトコル(MCP)を用いることで、AIアシスタントは質問に答えるだけでなく、データベース、API、ファイル、ビジネスワークフローといった実際のシステムと連携できるようになります。これは新たな機会を生み出す一方で、新たなセキュリティ上の責任も伴います。

MCPサーバーは、AI搭載アプリケーションと、そのアプリケーションがアクセスできるシステムとの間に位置します。そのため、実際には非常に重要な制御ポイントとなります。リクエストの受信、アクセス権限の強制、機密データの保護、そしてアクションの可視性と範囲の確保といった役割を担います。慎重に設計しないと、過剰なアクセス権限、データ漏洩、または不正使用につながる可能性があります。

MCP環境のセキュリティ確保は、単一の機能だけでは実現できません。ID管理、ネットワーク設計、シークレット管理、ログ記録、運用制御など、複数の要素にわたる多層的なアプローチが必要です。Oracle Cloud Infrastructureは、これらの制御を実用的かつ管理しやすい方法で適用するための構成要素を提供します。

MCPサーバーとは何か、そしてなぜセキュリティが重要なのか?

モデルコンテキストプロトコル(MCP)は、AIアシスタントがツールやシステムに構造化された方法で接続できるようにするオープンスタンダードです。MCPサーバーを介して、AIアプリケーションは情報を取得したり、サービスを呼び出したり、ユーザーに代わってアクションを実行したりできます。

そのため、MCPサーバーは従来のアプリケーションバックエンドとは異なります。予測可能なアプリケーショントラフィックのみを処理するのではなく、自然言語、間接的なワークフロー、または動的に選択されたツールによって形成されるリクエストを受け取る可能性があります。セキュリティ上の根本的な課題は新しいものではありませんが、セキュリティ対策が不十分な場合の影響はより深刻になる可能性があります。MCPサーバーに過剰な権限が付与されていたり、隔離が不十分だったりすると、ミスによる影響範囲が急速に拡大する可能性があります。

目標は単純明快だ。すべてのリクエストは認証され、すべてのアクションは制限され、すべてのバックエンド呼び出しは最小権限の原則に従い、すべての重要なイベントはログに記録されるべきである。

MCPについてさらに詳しく知りたい場合は、こちらのページを参照してください。

一般的なリスクと、OCIがそれらに対処する方法

1. MCPサーバーへの認証なしアクセス

MCPエンドポイントが強力な認証なしでアクセス可能な場合、それは明らかな攻撃対象となります。強制的なIDレイヤーのない公開サービスは、すぐに発見され、ツールの起動、データの照会、ワークフローのトリガーなどに悪用される可能性があります。

適切なアプローチは、MCPサーバーがリクエストを処理する前に認証を要求することです。OCI Identity Domainsは、OAuth 2.0とトークンベースのアクセス制御を通じて、このための基盤を提供します。クライアントはまず認証を行い、有効期限の短いトークンをMCPサーバーに提示します。サーバーはそのトークンを検証し、トークンに含まれるクレームを使用して、呼び出し元が実行できる操作を判断します。

Oracle Cloudサービスへのアクセスにおいては、IDの伝播は慎重に、かつサポートされている場合にのみ処理する必要があります。すべてのダウンストリームアクションで共有認証情報に依存するのではなく、アーキテクチャは適切な場合にはユーザーコンテキストを保持し、アクセス決定が元の呼び出し元と一致するようにする必要があります。これにより、広範なサービスIDがすべてのユーザーにとってのショートカットとして使用されるリスクが軽減されます。

ユーザーIDが正しく伝播されている場合でも、機密性の高い操作については、IAMルートレベルで明示的な拒否ポリシーを定義することが有効な場合が多い。これらのポリシーはガードレールとして機能し、アプリケーションの動作、設定ミス、ポリシーの逸脱に関わらず、特定のアクションが確実にブロックされるようにする。

安全なユーザー伝播パターンの実装に関する詳細については、こちらのページを参照してください。

原則は単純だ。まず認証を行い、すべてのリクエストを検証し、可能な限り共有IDを避ける。

2. MCPサーバーをインターネットに直接公開する

公共インターネットに直接接続されたサーバーは、スキャン攻撃、プロービング攻撃、トラフィックベースの攻撃に即座に晒されます。強力な認証システムを導入したとしても、不必要な公開は運用リスクを高めます。

より堅牢な設計としては、MCPサーバーを仮想クラウドネットワーク内のプライベートサブネットに配置する方法があります。パブリックトラフィックは、制御されたエントリポイントとして機能するOCIロードバランサーで終端させる必要があります。OCI Webアプリケーションファイアウォールをそのエントリポイントの前に配置することで、HTTPトラフィックがアプリケーション層に到達する前に検査およびフィルタリングすることができます。

ネットワーク内では、ネットワークセキュリティグループによって、通信を必要なポートと送信元のみに制限する必要があります。これにより、エッジでのフィルタリングされた受信、ロードバランサーでのトラフィック制御、そしてMCPインスタンス自体に対する明示的なネットワークポリシーといった、複数の制御レイヤーが構築されます。

その結果、攻撃対象領域が大幅に縮小し、公開アクセスと非公開実行の分離がより明確になる。

3. ネットワーク全体にわたる横方向の移動

MCPサーバーが侵害された場合、まず最初に懸念されるのは、そのサーバーが環境内の他のシステムへの侵入経路として悪用される可能性があるかどうかです。内部セグメンテーションがなければ、あるホストで発生した問題は、そのホストをはるかに超えて拡散する可能性があります。

OCIは、階層型ネットワーク制御によってこの問題に対処します。ネットワークセキュリティグループは、どのシステムがどのポートで通信できるかを制限します。ゼロトラストパケットルーティングは、広範なネットワークの想定ではなく、セキュリティ属性に基づいた通信ポリシーを適用することで、不要なアクセスをさらに削減できます。

目的は、MCPサーバーが真に必要とするシステムのみにアクセスできるようにすることです。特定のデータベース、オブジェクトストア、または内部サービスとのみ通信する必要がある場合は、ネットワークパスはそれだけに限定されるべきです。それ以外の通信はデフォルトで拒否されるべきです。

適切なセグメンテーションはインシデントを完全に排除するものではないが、インシデントが拡散する範囲を制限する。

4. 機密データが誤ったユーザーまたはシステムに渡ってしまう

AI接続システムにおける最も一般的な設計ミスの一つは、すべてのユーザーに代わってデータにアクセスするために、広範な共有サービスアカウントを使用することです。これは開発を簡素化するかもしれませんが、データの分離を弱め、最小権限の原則を徹底することを困難にします。

より安全なアプローチは、下流のアクセス制御が、リクエストを開始したユーザーまたは業務機能に対して意図された権限を反映するようにすることです。データベースを基盤とするアーキテクチャでは、これはアプリケーション層での不必要な過剰なアクセスを避け、可能な限りデータベース固有の制御を利用することを意味します。

Oracle Databaseは、行レベルの制御、列レベルの保護、ユーザースコープのアクセスパターンなど、強力な機能を提供します。これらの制御は、すべてのアクセスを単一の共有認証情報に集約するのではなく、意味のあるIDや役割のコンテキストを維持するようにアプリケーションアーキテクチャが設計されている場合に最も効果を発揮します。

Oracle Databaseの最新バージョンでは、AIやセマンティック検索ワークロードで使用されるベクトルデータなど、複数の種類のデータの保存もサポートされています。これらのデータタイプがMCP接続システムの一部となるにつれて、構造化データと非構造化データ全体にわたって一貫したアクセス制御と暗号化ポリシーを適用することがますます重要になります。

アクセス制御に加えて、保存データの保護も最優先事項として扱うべきです。OCIオブジェクトストレージに保存されているナレッジベースなどのエンタープライズデータ、およびデータベースに保存されているアプリケーションデータは、顧客管理キーを使用してOCI Vaultで暗号化する必要があります。これにより、基盤となるストレージにアクセスされた場合でもデータが保護され、明示的に承認されたIDのみが復号化して使用できるようになります。また、暗号化制御をアプリケーション層から独立させることで、職務分掌も強化されます。

OCI Data Safeは、Oracle Databaseを脅威から保護するために特別に設計されています。機密データの検出、ユーザーリスク分析、アクティビティ監査、SQLファイアウォールなどの機能に加え、アクセスパターンに関する詳細な情報を提供します。これにより、組織はデータへのアクセス方法を把握し、異常またはリスクの高い動作を早期に検出できます。

5. 盗難または漏洩したAPIキーとパスワード

静的認証情報は、クラウド環境における最も回避可能なリスクの一つです。コード、設定ファイル、またはサーバー環境に保存された機密情報は、コピー、コミット、再利用され、そして忘れ去られる可能性があります。これらが漏洩した場合、多くの場合、即座に永続的なアクセス権限を与えてしまいます。

より良い方法は、可能な限りサーバー上に長期保存可能な認証情報を保存しないことです。コンピュートインスタンスは、インスタンスプリンシパルを使用して、ディスクにAPIキーを埋め込むことなくOCIサービスへの認証を行うことができます。これにより、主要な運用リスクの一つが解消されます。

サードパーティのAPIキーや、より強力なフェデレーションパターンをサポートしていないシステムの認証情報など、外部の機密情報が必要な場合は、OCI Secrets Managementサービスを中央ストアとして使用する必要があります。機密情報は暗号化されたまま保持され、アクセスはポリシーによって制御され、取得状況は監査可能です。

これにより、機密情報の取り扱いがアプリケーションバンドルから切り離され、その目的のために設計された管理対象の制御プレーンに移行されます。

6.AIが悪意を持って操作され、有害な行動をとる

プロンプトインジェクションは、AI接続システムにおける最も重要なセキュリティ上の懸念事項の一つです。コンテンツ、ツール出力、またはユーザー入力に隠された悪意のある命令は、モデルが意図したワークフローとは異なる動作を実行するように仕向ける可能性があります。

これは単一の制御策だけで解決できる問題ではありません。最も効果的な防御策は、アーキテクチャ上の制約です。MCPサーバーを介して公開されるツールは、範囲を限定し、明示的に承認され、最小権限の原則に従う必要があります。モデルは、周辺システムが独自に正当化できないような操作を実行するための広範なアクセス権を持つべきではありません。

IAMポリシーは重要な厳格な境界を提供します。たとえモデルが悪意のある操作を試みるように仕向けられたとしても、MCPサーバーとその関連IDが実際に実行を許可されている範囲によって制約されるべきです。機密性の高い操作には明示的な分離が必要であり、重要なアクションは決してモデルの推論のみに依存してはなりません。

MCPロードバランサーの前に設置されたWebアプリケーションファイアウォールは、不正なリクエストトラフィックや悪用されたリクエストトラフィックをフィルタリングすることでHTTPレイヤーに貢献できますが、プロンプトインジェクションは主にアプリケーション、認証、およびツール設計の問題として扱うべきです。最も効果的な制御策は、権限を厳密に制限すること、信頼できるツール定義を用いること、明示的な検証を行うこと、そしてそもそもどのようなアクションが許可されているのかを厳密に見直すことです。

7.AIコールの急増と予想外のコスト増加

AI接続サービスは、リクエストがループしたり、繰り返し発生したり、予期せず規模が拡大したりすると、膨大なデータ使用量を発生させる可能性があります。場合によっては、攻撃者の目的はデータ窃盗ではなく、単にコストを吊り上げることだけかもしれません。

これは、トラフィック制御、サービス制限、および支出可視化を組み合わせることで最も効果的に対処できます。エッジでのレート制限は、不正なリクエストパターンがアプリケーションに到達する前に抑制するのに役立ちます。アプリケーション層では、MCPツールに再試行、繰り返し呼び出し、およびファンアウト動作に関するガードレールを含める必要があります。

コスト監視も不可欠です。基準となる支出額は定期的に見直し、異常な増加を早期に検知できるようアラートを設定する必要があります。コスト管理はセキュリティとは別個のものとして議論されることが多いですが、AIシステムにおいては密接に関連しています。無制限の利用を生み出すために悪用される可能性のあるサービスは、財務面と運用面の両方でリスクとなります。

8.設定ミスによるセキュリティ上の脆弱性

クラウド環境は柔軟性に富み、強力な利点を持つ一方で、正しく設定しないとリスクを招く可能性があります。パブリックストレージバケット、過度に広範なポリシー、あるいはログ設定の不備などは、アプリケーション自体が適切に設計されていても、知らず知らずのうちにリスクを発生させる可能性があります。

OCI Cloud Guardは、危険な構成や疑わしい状態がないか環境を継続的に評価します。露出したリソースや保護機能の不足といった問題を特定し、これらの状態が発生した場合の対応ワークフローをサポートします。

セキュリティゾーンは、特定の種類の危険な設定がそもそも作成されないようにすることで、セキュリティをさらに強化します。これは、検出のみの場合よりも効果的な場合が多いです。後から間違いが見つかることを期待するのではなく、プラットフォームは既知の高リスクパターンを事前にブロックできます。

これは、MCP関連のワークロードにおいて特に有用です。MCP関連のワークロードでは、アプリケーションロジック自体と同様に、周囲のインフラストラクチャも厳密に管理する必要があるからです。

9. AIが実際に行ったことの明確な監査証跡がない

AIと連携したワークフローがデータにアクセスしたり、ツールを呼び出したり、下流サービスをトリガーしたりする場合、それらのアクションは事後的に可視化されなければなりません。意味のあるログがなければ、インシデント対応は推測に頼ることになります。

OCI監査ログはOCIサービスへの呼び出しを記録し、VCNフローログはネットワークレベルの可視性を提供します。これらは重要ですが、それだけでは十分ではありません。MCPサーバーは、意味のあるツール呼び出しごとに構造化されたアプリケーションログも出力する必要があります。これには、リクエストを開始したユーザー、使用されたツール、接続されたバックエンド、発生したアクションの種類、および成功したか失敗したかの情報が含まれるべきです。

OCI Service Connector Hubは、ログストリームを下流システムにルーティングして保持および分析するのに役立ちます。そこから、組織はログをストレージに一元化したり、好みの分析および監視スタックに転送したりできます。

重要な点は、AIの活動が単なるインフラストラクチャのノイズではなく、ビジネス活動として観測可能である必要があるということです。ログ記録によって、調査、説明、改善に必要な詳細情報を含めて、何が起こったのかを再現できるようにする必要があります。

10. 微妙な行動変化と低ノイズの悪用

すべての攻撃が目立つわけではありません。最も見つけにくい問題の中には、一見するとごく普通に見えるものがあります。例えば、送信トラフィックの緩やかな増加、新しい宛先への繰り返しアクセス、あるいは時間とともに変化するツール使用の安定したパターンなどです。

この種の MCP 特有の挙動検出に対するデフォルトの解決策として提示できる単一のマネージド OCI サービスは存在しません。より正確には、利用可能な OCI 構成要素と組織独自の監視スタックから構築されたカスタム検出パイプラインとして捉えるべきです。

例えば、組織はVCNフローログとMCPアプリケーションログを中央ストアにルーティングし、接続数、ツール呼び出し率、データ量、エラーパターンなどの運用特性を抽出し、ルールやカスタム分析を用いてこれらのシグナルを評価することができます。OCI AIデータプラットフォームサービスを利用することで、大量の運用データとセキュリティデータを収集、整理、分析し、チームがより高度な検出パイプラインを構築し、これらのシグナルから有益なインサイトを引き出すことができます。そして、動作が想定されるベースラインから逸脱した場合に、運用チームにアラートを送信できます。

このアプローチは、事前に定義されたシグネチャだけでなく、環境固有の通常のパターンに焦点を当てているため、価値があります。しかし、これはMCPワークロード向けの単純な組み込み型管理セキュリティ機能ではなく、カスタム監視および検出アーキテクチャとして説明されるべきです。

11. サーバーインスタンスへの管理権限のないアクセス

管理者権限は必要だが、常時管理者権限を晒す必要はない。SSHを常時開いたままにしておくと、不必要な攻撃対象となり、管理が困難な長期的なアクセス経路が生じる。

OCI Bastionは、管理ポートを常時開放することなく、時間制限付きかつID認識型のプライベートリソースへのアクセスを可能にすることで、より優れたパターンを提供します。アクセスは必要な時に特定のユーザーに紐付けられ、プラットフォームを通じてログに記録されます。

これにより、セキュリティと説明責任の両方が向上します。静かに継続する常時アクセスではなく、管理者によるアクセスは明確かつ限定的になり、追跡可能になります。

MCPのセキュリティは単一の制御ではなく、レイヤリングが重要です

単一のサービスだけで MCP デプロイメントを安全にすることはできません。真のセキュリティは、強力な ID 管理、プライベート ネットワークへの配置、厳密なアクセス許可、安全なシークレット処理、構造化されたログ記録、および規律ある運用監視を組み合わせることによって実現されます。これは、AI に接続されたシステムでは特に当てはまります。ワークフローが強力になるほど、各レイヤーの境界をより慎重に設定する必要があります。MCP サーバーは、単なるアプリケーションのエンドポイントとして扱われるべきではありません。ポリシー適用ポイント、信頼境界、および運用リスクのサーフェスが同時に存在するのです。Oracle Cloud Infrastructure は、アクセスを明示し、影響範囲を制限し、システム動作を可視化することで、この階層型モデルを構築するために必要なサービスを提供します。これらの基盤に加えて、OCI の AI サービス (OCI Generative AI Service、OCI Generative AI Agents、OCI AI Data Platform など) は、プライベート推論エンドポイント、エージェント レベルのガードレール、きめ細かなデータ アクセス制御など、より高度なサービスネイティブのセキュリティ機能も提供します。これらの機能は、AI アーキテクチャが複雑化するにつれて不可欠になります。

コメント

このブログの人気の投稿

Oracle Database 19cサポート・タイムラインの重要な更新 (2024/11/20)

ミリ秒の問題: BCCグループとOCIが市場データ・パフォーマンスを再定義する方法(AWSに対するベンチマークを使用) (2025/11/13)

OCIのカスタム・ルート表を使用した詳細なルーティング制御 (2025/02/27)