CTOのためのMCPアクセス管理アーキテクチャ

ゲートウェイは信頼境界です

ゲートウェイでは、リクエストを送るユーザー、利用するクライアント、接続先、ツールとリソース、適用するポリシーのバージョンをまとめて確認できます。これらの情報をもとに、システム基盤の担当チームは実行前に一貫した判断を行えます。

アーキテクチャ上の間違いは、ルーティングを承認として扱うことです。ゲートウェイは、自身の対象者と認証情報を検証し、上流の同意境界を維持し、機能またはリソースの範囲が不明な場合はフェールクローズする必要があります。

例示的なシナリオ: ツールの形状が変化する

上流のツールが読み取りを書き込みに変更する新しい引数を追加すると想像してください。 JSON を転送するだけのゲートウェイは、ポリシーとレビュー モデルが遅れている間も動作し続ける可能性があります。管理対象のアクセス経路は、スキーマと機能の変更をレビュー入力として扱います。これは例示的な設計シナリオであり、報告されたイベントではありません。

パスを個別の段階としてモデル化します。つまり、認証、認可、必要に応じて承認の取得、意図の記録、ディスパッチ、プロバイダーの結果の分類です。この分離により、再試行と不確実な書き込みが偶然ではなく明示的に行われます。

アーキテクチャのチェックリスト

接続をスケーリングする前に、次の質問に対する答えを書き留めてください。

• どの MCP クライアントがサポートされていますか?また、そのバージョンと構成はどのように検証されますか?
• アップストリーム ID、スコープ、同意、トークン オーディエンスはゲートウェイ ID からどのように分離されていますか?
• レビューされたツール、スキーマ、リソース、ポリシーのバージョンはどこに保存され、変更されますか?
• 承認は正確なプリンシパル、引数、スキーマ、有効期限、および使用回数にどのようにバインドされますか?
• タイムアウトとあいまいなプロバイダー書き込みはどのように表現され、調整されるのでしょうか?
• どの制御が出力、プライベート接続、保持、バックアップ、リカバリを強制しますか?

Durin による有界評価

Durin は、プラットフォーム チームに、ID、デフォルト許可ポリシーのチェック、オプションの承認または不許可の制御、スコープ指定された接続、監査など、実行するための具体的なリクエスト パスを提供します。評価ワークスペースは、プロバイダーをアクティブ化する前にモデルを検証できます。検出、リモート プロバイダーのアクティベーション、ホストされた ID、プライベート接続、および運用保証は、本番環境の信頼チェックです。

その境界を使用して、アーキテクチャの決定記録を構築します。ゲートウェイが証明する機能、ネットワークまたはクライアントが証明する必要がある機能、本番公開前に通過する必要があるゲートに名前を付けます。