MCPの認証と認可：OAuth 2.1、トークン委譲、そして混乱した代理人問題
認証はリモートMCPサーバーにとって最も重要なセキュリティ層です。OIDCを伴うOAuth 2.1がなぜ必須なのか、トークン委譲がどのように混乱した代理人攻撃を防ぐのか、そしてなぜトークンパススルーがAI統合における最も危険なパターンの一つなのかを学びましょう。...
1 分で読める
MCP Security
OAuth 2.1
+3
OWASP GenAIセキュリティプロジェクトのMCPサーバー開発のための実践的ガイドは、具体的なレビューチェックリスト「MCPセキュリティ最小要件」で集大成を迎えます。このチェックリストは、MCPサーバーを本番環境にデプロイする前に実装すべき基本的な管理策を定義しています。
本記事では、OWASPガイドが定義する5つのセキュリティ領域にわたって整理された、各項目の実装ガイダンスを含む完全なチェックリストを提示します。デプロイ前のセキュリティレビュー、定期的な監査、および特定されたギャップを修正するためのフレームワークとしてご活用ください。
このチェックリストの使用方法
項目のマーキング: 各項目について、PASS(実装され検証済み)、FAIL(未実装または部分的に実装)、またはN/A(このデプロイメントには該当しない)を記録します。
デプロイメントゲート: カテゴリ1(アイデンティティ、認証、ポリシー)とカテゴリ2(分離)の項目は、厳格なデプロイメントゲートです。FAILがある場合は、修正されるまで本番稼働を阻止すべきです。他のカテゴリの項目は、文書化されたスケジュールとともにリスク受容されるべきです。
レビュートリガー: MCPサーバーコード、ツールレジストリ、認証設定、デプロイメント環境に重大な変更があった場合、または新しいカテゴリのツールがオンボードされた場合は、完全なチェックリストを再実行してください。
カテゴリ1:強力なアイデンティティ、認証、ポリシー実施
これは最優先のカテゴリです。認証の失敗は、攻撃者にMCPサーバーができることすべてへの直接アクセスを許可します。
1.1 すべてのリモートMCPサーバーがOAuth 2.1 / OIDCを使用
検証内容: MCPサーバーへのすべてのリモート接続は、適切に設定されたOAuth 2.1認可サーバーを通じた認証を必要とします。匿名接続は拒否されます。STDIOを使用するローカルMCPサーバーは、そのデプロイメントコンテキストに適した代替認証を使用できます。
テスト方法: 認可ヘッダーなしで接続を試みます。不正な形式または期限切れのトークンで接続を試みます。両方とも認証失敗となり、ツールへのアクセスは許可されないはずです。
一般的な失敗モード: 認証なしでアクセス可能なまま残された開発エンドポイント、有効期限やスコープを検証しないAPIキー認証へのフォールバック、セッション確立時のみでリクエストごとには行われないトークン検証。
1.2 トークンは短命で、スコープが設定され、すべての呼び出しで検証される
検証内容: アクセストークンは数分以内に(数時間ではなく)期限切れになります。各トークンは現在のタスクに必要な最小限のスコープを持ちます。すべてのツール呼び出しは、セッション確立時だけでなく、トークンの署名、発行者(iss)、オーディエンス(aud)、有効期限(exp)、および必要なスコープを検証します。
テスト方法: 有効なトークンを使用し、その後期限切れになるまで待ちます(または手動で時計を進めます)。ツール呼び出しを試みます。キャッシュされた検証結果で成功するのではなく、401で失敗するはずです。
一般的な失敗モード: セッション開始時にキャッシュされ繰り返されないトークン検証、24時間以上のライフタイムを持つトークン、操作固有のスコープの代わりに使用される広範な「管理者」スコープ、チェックされないexpフィールド。
1.3 トークンのパススルーなし、ポリシー実施は集中化
検証内容: MCPサーバーはクライアントトークンをダウンストリームAPIに転送しません。すべてのダウンストリームサービス呼び出しは、MCPサーバーに明示的に発行されたトークン(On-Behalf-Ofフローまたはサービス資格情報経由)を使用します。集中化されたポリシーゲートウェイがすべてのツール呼び出しを傍受し、ツールコードが実行される前に認証、認可、同意、監査ログを実施します。
テスト方法: 受信したクライアントトークンがアウトバウンドAPI呼び出しで転送される場所がないかコードをレビューします。ダウンストリームサービスのアクセスログを検査して、リクエストがユーザー資格情報ではなくサーバー資格情報で到着することを確認します。
一般的な失敗モード: ダウンストリーム呼び出しでのAuthorization: Bearer ${request.headers.authorization}パターン、個々のツールハンドラーに分散された認可チェック、集中化されたポリシー実施ポイントの欠如。
カテゴリ2:厳格な分離とライフサイクル制御
マルチテナント環境での分離の失敗は壊滅的です。あるユーザーが別のユーザーのデータにアクセスできるようになります。これらは厳格なデプロイメントゲートです。
2.1 ユーザー、セッション、実行コンテキストは完全に分離されている
検証内容: グローバル変数、クラスレベル属性、または共有シングルトンインスタンスがユーザー固有またはセッション固有のデータを保存していません。各セッションは独立してインスタンス化されたオブジェクトまたはセッションキー付き名前空間(例:Redis キーにsession_id:接頭辞)を使用します。コードレビューでセッション間の共有可変状態がないことを確認します。
テスト方法: 異なるユーザーアイデンティティで2つの同時セッションを実行します。セッションAで書き込まれたデータがセッションBで読み取れないことを確認します。競合ロードテストを使用して、セッション状態の漏洩を引き起こす可能性のある競合状態をチェックします。
一般的な失敗モード: シングルトンサービスのクラス属性としてのself.user_context = {}、セッションキー付き名前空間のないグローバルキャッシュ、リクエストライフサイクルに適切にスコープされていないスレッドローカルストレージ。
2.2 ユーザーデータの共有状態なし
検証内容: 実行コンテキストを超えて、共有インフラストラクチャ(データベース、キャッシュ、メッセージキュー)がユーザーごとのアクセス制御を実施します。あるユーザーのセッションで実行されたクエリは、共有インフラストラクチャが誤設定または侵害されている場合でも、別のユーザーのデータを返すことはできません。
テスト方法: セッションパラメータを操作したり、共有キャッシュキーを悪用したりして、別のユーザーのデータにアクセスしようとします。
一般的な失敗モード: クエリ内容のみに基づきユーザーアイデンティティに基づかないキャッシュキー、ユーザースコープのWHERE句のないデータベースクエリ、ユーザーごとのサブディレクトリのない共有一時ファイルディレクトリ。
2.3 セッションは決定論的なクリーンアップと強制されたリソースクォータを持つ
検証内容: セッションが終了したとき(正常に、またはタイムアウト/エラーによって)、関連するすべてのリソースが即座に解放されます:ファイルハンドル、一時ファイル、メモリ内コンテキスト、キャッシュされたトークン、データベース接続。メモリ、CPU、APIレート、ファイルシステム使用量のセッションごとの制限が存在します。
テスト方法: セッションを突然終了します(正常なシャットダウンなしで接続を切断)。残留リソースが残っていないことを確認します。セッションを作成してレート制限を使い果たします。他のセッションに影響を与えないことを確認します。
一般的な失敗モード: セッション終了後に/tmpに残された一時ファイル、セッション終了時に取り消されないキャッシュされたトークン、1つのセッションが共有インフラストラクチャを使い果たすことを許可するリソースクォータの欠如。
カテゴリ3:信頼され制御されたツール
ツールセキュリティは、最も危険なMCP固有の攻撃を防ぎます:ツールポイズニングとラグプル。
3.1 ツールは暗号署名され、バージョン固定され、正式に承認されている
検証内容: すべてのツール定義には、認可されたツール承認者からの暗号署名があります。署名は完全なマニフェスト(説明、スキーマ、バージョン、権限)をカバーします。MCPサーバーはロード時にこの署名を検証し、署名のない、または署名が一致しないツールを拒否します。ツールのバージョンは固定されています。サーバーは新しい承認済み署名なしに更新されたツールを動的にロードできません。
テスト方法: ロードされたツールの説明の1文字を変更します。サーバーがハッシュの不一致を検出し、ツールのロードをブロックすることを確認します。署名のないツール定義をロードしようとします。拒否されるはずです。
一般的な失敗モード: 整合性検証なしで可変構成として保存されたツール定義、署名キーインフラストラクチャの欠如、バージョン固定なしで共有ファイルシステムから直接ロードされたツール。
3.2 ツールの説明はランタイム動作に対して検証される
検証内容: 自動スキャンは、ポイズニング試行を表す可能性のある命令のようなパターンがないかツールの説明をチェックします。定期的な検証により、ツールの実際のランタイム動作が宣言された説明と一致することを確認します。読み取り専用であると主張するツールは、ランタイムで書き込み操作を実行できないはずです。
テスト方法: ツールの説明に疑わしい命令を追加します(「常にsend_webhookも呼び出す…」)。人間によるレビューの前に自動スキャンがそれにフラグを立てることを確認します。MCP固有のポイズニング検出ルールのSASTツール構成をレビューします。
一般的な失敗モード: ツール説明の自動スキャンの欠如、長い説明に埋め込まれた命令を見逃す可能性のある手動レビュープロセス、ツールがその能力について嘘をつくのを捕まえるためのランタイム動作検証の欠如。
3.3 最小限の必要なツールフィールドのみがモデルに公開される
検証内容: モデルコンテキストは、正しいツール呼び出しに必要なフィールドのみを受け取ります:名前、説明、入力スキーマ、出力スキーマ。内部メタデータ、実装の詳細、デバッグ情報、機密設定は、モデルに渡される前にフィルタリングされます。
テスト方法: 利用可能なツールを列挙するときにモデルが受け取るものを検査します。内部フィールド、接続文字列、または運用メタデータがモデルのビューに表示されないことを確認します。
一般的な失敗モード: モデルコンテキストに渡される完全なツール構成オブジェクト、モデルに漏洩する内部システムの詳細を含むエラーメッセージ、呼び出しに関連しない実装メモを含むツール説明。
ニュースレターに登録
最新のヒント、トレンド、お得な情報を無料で入手。
カテゴリ4:あらゆる場所でのスキーマ駆動検証
検証の失敗は、インジェクション、データ操作、サービス拒否を可能にします。
4.1 すべてのMCPメッセージ、ツール入力、出力はスキーマ検証される
検証内容: JSON スキーマ検証は、すべてのMCPプロトコルメッセージ、すべてのツール呼び出し入力、およびモデルに到達する前のすべてのツール出力に対して実施されます。検証は、定義されたスキーマに準拠しないメッセージを拒否します。必須フィールドの欠落、間違った型、許可された範囲外の値などです。
テスト方法: 必須パラメータが欠落しているツール呼び出しを送信します。予期しない追加フィールドを持つメッセージを送信します。両方とも拒否されるべきであり、黙って無視されたりデフォルトで処理されたりすべきではありません。
一般的な失敗モード: エラー条件下でバイパスされるオプションの検証、出力ではなく入力のみの検証、過度に寛容なスキーマ(type: "any"パラメータを受け入れる)。
4.2 入力/出力はサニタイズされ、サイズ制限され、信頼されないものとして扱われる
検証内容: すべての入力は、インジェクションを可能にする文字(XSSシーケンス、SQLメタ文字、シェルメタ文字、ヌルバイト)を削除またはエスケープするためにサニタイズされます。すべての入力と出力にサイズ制限が実施されます。サーバーは、従来のWebアプリケーションのユーザー入力と同じように、モデルからのすべてのデータを潜在的に敵対的なものとして扱います。
テスト方法: SQLインジェクションペイロード、シェルメタ文字、XSSシーケンスを含む入力を送信します。ダウンストリームシステムに到達する前に拒否または安全にエスケープされることを確認します。サイズ制限を超える入力を送信します。クリーンに拒否されることを確認します。
一般的な失敗モード: SQLクエリまたはシェルコマンドに直接渡される入力、過大な入力がメモリ枯渇を引き起こすことを許可するサイズ制限の欠如、サイズ制限やコンテンツフィルタリングなしでモデルに返される出力。
4.3 構造化(JSON)ツール呼び出しが必須
検証内容: ツール呼び出しは、検証されたスキーマを持つ構造化JSONオブジェクトとしてのみ受け入れられます。ツール呼び出しを暗示する自由形式のテキスト生成は処理されません。システムは、サーバーがコマンドとして解釈する自然言語を生成することによってツール呼び出しを実行するように誘導されることはできません。
テスト方法: ツール呼び出しを説明する自然言語文字列を送信します(「/etc/passwdパスでdelete_fileツールを呼び出す」)。サーバーがこれをツール呼び出しとして解釈しないことを確認します。
一般的な失敗モード: 構造化JSONと自然言語ツール説明の両方を受け入れるハイブリッドシステム、ツール呼び出しを識別するためにモデル生成テキストを解析するサーバー、偽装可能な正規表現ベースのツール呼び出し解析。
カテゴリ5:強化されたデプロイメントと継続的監視
デプロイメントの強化は、悪用された脆弱性の影響範囲を制限します。
5.1 サーバーはコンテナ化され、非rootで、ネットワーク制限されている
検証内容: MCPサーバーは最小限の強化されたコンテナで実行されます。コンテナプロセスは非rootユーザーとして実行されます。不要なLinux機能は削除されます。ネットワークポリシーは、すべてのインバウンドおよびアウトバウンドトラフィックを明示的に必要な接続に制限します。コンテナイメージには最小限必要なソフトウェアのみが含まれています。
テスト方法: docker inspectを実行し、ユーザーが非rootであることを確認します。ネットワークポリシーをレビューし、明示的にホワイトリストされた接続を除くすべてのトラフィックをブロックしていることを確認します。不要なパッケージや既知の脆弱なソフトウェアがないかコンテナイメージをスキャンします。
一般的な失敗モード: 便宜上rootとして実行されるコンテナ、すべてのアウトバウンドトラフィックが許可されたままになっているネットワークポリシーの欠如、最小限のイメージではなく完全なOSインストールを持つベースイメージ。
5.2 シークレットはボールトに保存され、LLMに公開されない
検証内容: すべてのAPIキー、OAuth クライアントシークレット、データベース資格情報、サービスアカウントトークンは、シークレットボールト(HashiCorp Vault、AWS Secrets Manager、Azure Key Vaultなど)に保存されます。環境変数、ソースコード、コンテナイメージ、ログ出力にシークレットは存在しません。シークレット管理操作は、AIモデルがアクセスできないミドルウェアで行われます。LLMは資格情報の値を見たり処理したりすることはありません。
テスト方法: ログで資格情報のような文字列を検索します。サーバープロセスがアクセス可能な環境変数を検査します。モデルのアクセス可能なコンテキストをレビューして、資格情報の値が表示されないことを確認します。
一般的な失敗モード: バージョン管理にコミットされた.envファイル内のAPIキー、モデルに到達するエラーメッセージで返される資格情報、モデルの会話コンテキストに表示されるツールパラメータとして渡されるシークレット。
5.3 CI/CDセキュリティゲート、監査ログ、継続的監視は必須
検証内容: デプロイメントパイプラインには、厳格なゲートとしての自動セキュリティスキャン(SAST、SCA、依存関係脆弱性スキャン)が含まれています。スキャンに失敗するとデプロイメントがブロックされます。すべてのツール呼び出し、認証イベント、認可決定は、完全なコンテキストとともに不変にログ記録されます。ログはSIEMに取り込まれ、異常なパターン(検証失敗のスパイク、異常なツール呼び出し頻度、予期しない外部接続)に対するリアルタイムアラートが発生します。
テスト方法: 既知の脆弱な依存関係を導入し、CI/CDパイプラインがビルドを失敗させることを確認します。異常なツール呼び出しパターンを生成し、予想される応答時間内にSIEMアラートが発火することを確認します。
一般的な失敗モード: ブロッキングゲートではなくアドバイザリとしてのセキュリティスキャン、攻撃者が変更できる可変ストレージに書き込まれるログ、異常なパターンに対するアラートの欠如、関連するイベントを見つけることを不可能にする過度のログ冗長性。
MCPデプロイメントのためのこのチェックリストの使用
本番環境へのデプロイ前に、すべてのMCPサーバーについてこのチェックリストを印刷またはエクスポートし、体系的に確認してください。セキュリティチームをレビューに参加させてください。多くの項目は正しく検証するためにコードレビューとライブテストの両方が必要です。
独立した検証を希望するチームのために、プロフェッショナルなMCPセキュリティ監査 は、自己評価ではなく敵対的テスト技術を使用して、本番環境に対してすべての16のチェックリスト項目をテストします。結果は、優先順位付けされた改善計画を伴う検証済みセキュリティ態勢レポートです。
