Slide 1
Slide 1 text
脅威をモデリングして
MCPのセキュリティ対策を考えよう
2025/06/17 - MCP導入における脅威モデリングのすゝめ
GMO Flatt Security株式会社
Norihide Saito / Azara
Slide 2
Slide 2 text
自己紹介
講演・コミュニティ活動
名前 Norihide Saito / Azara
所属
国内 JPCERT/CC JSAC 2024 登壇・ベストスピーカー賞
国内 BSides Tokyo 2024 登壇
国内 SECCON 2022 Domestic
国内 ISOG-J ワーキングループ1での活動
国内 CloudSec JP Organizer
その他 Cloud Security expert of GMO internet group
国際
国際 AWS Community Builder - Security
国外 BSides Las Vegas 2024 登壇
Slide 3
Slide 3 text
Our Mission
エンジニアの背中を預かる
より多くのエンジニアがものづくりに集中できる社会を、
セキュリティ面からつくる会社
Slide 4
Slide 4 text
脆弱性診断・ペネトレーションテストを
プロフェッショナル / SaaSで多角的に提供
手動・高度診断
コード・仕様の分析も行い、
専門家が脆弱性を網羅的に発見
自動・継続診断
クラウド・Webアプリをまるごと
継続的に診断するSaaS
提供サービス
提供サービス
Slide 5
Slide 5 text
MCPを対象にした診断(プロフェッショナルサービス)
Slide 6
Slide 6 text
本発表について
弊社の
を補足するお話をします
実質書き下ろしです。
MCPにおけるセキュリティ考慮事項と実装における観点
Slide 7
Slide 7 text
本発表はこのような人を想定して作っています
生成AIを用いた
ソフトウェアを作る人
生成AI関連の
セキュリティを学ぶ人
AIを育てるすべての人たちへ
生成AIを用いた
ソフトウェアを守る人
Slide 8
Slide 8 text
本発表の目的
1 MCPやそれらを取り巻くセキュリティ課題を理解する
2 脅威がどこに存在するかを理解し、
適切なセキュリティ施策をとれるようにする
3 MCPサーバーをプロダクトとして提供する際の
セキュリティ施策や認可・権限について理解する
4 MCPとその周辺の脅威やリスクを理解する
Slide 9
Slide 9 text
本発表の目的
まったくわからん...
↓
(周辺のセキュリティ対策を調べるとっかかりを得られた状態)
すこしわかる
Slide 10
Slide 10 text
目次
1 MCPにおけるセキュリティ
2 脅威のモデリングと開発現場へのセキュリティFB
3 自社プロダクトとして提供
4 まとめ + おまけ
Slide 11
Slide 11 text
01
MCPにおけるセキュリティ
Slide 12
Slide 12 text
MCP周辺の全体像
MCP Spec
Client Server
Host LLM
外部リソース
内部リソース
内部のファイルやソフトウェア、コマンドの操作など
Slide 13
Slide 13 text
MCPと周辺におけるセキュリティ課題の大別
MCP Serverにおける
リスク・脅威
利用における
リスク・脅威
MCP Host + Clientにおける
リスク・脅威
(生成AI Application)
Slide 14
Slide 14 text
MCP Host + Clientにおけるリスク・脅威
MCP Host + Clientにおける
リスク・脅威
※正確には生成AI Application全般におけるリスク・脅威
攻撃者の目的
攻撃者による
生成AIアプリの制御と
ツールへのアクセス
情報の抜き取りや機能の悪用など
Slide 15
Slide 15 text
MCP Host + Clientにおけるリスク・脅威
MCP Host + Clientにおける
リスク・脅威
※正確には生成AI Application全般におけるリスク・脅威
1 意図しないプロンプトの注入
2 ツール利用における
混乱・意図しない実行
3 攻撃者による
生成AI Applicationの恒久的制御
手段の一例
Slide 16
Slide 16 text
MCP Host + Clientにおけるリスク・脅威
生成AIアプリケーション
(MCP Host +MCP Client)
悪性のMCP Server
MCP Server - A
攻撃の一例
1
3 4
5
2
６
悪意のあるプロンプトの注入
1 Init時に悪性のMCP Serverに接続
2 Init時に悪意のあるプロンプトを返却
3 悪意のあるプロンプトをLLMへ入力
４
本来アクセスをしたくない/させたくない
MCP Serverのツールを実行を指示
※図の場合は、MCP Server - Aへアクセス後にその結果を悪性のMCP
Serverへ送るように指示
5 通常の処理
6 結果を悪性のMCP Serverに送信
Slide 17
Slide 17 text
MCP Serverにおけるリスク・脅威
攻撃者の目的
MCP Serverにおける
リスク・脅威
攻撃者による
ツールの悪用 +
付与された権限の悪用
または、権限の付与された認証情報の取得
Slide 18
Slide 18 text
MCP Serverにおけるリスク・脅威
MCP Serverにおける
リスク・脅威
1 認可制御の不備
2 権限の過剰付与と
権限の取り扱いに関する設計不備
3 設定や実装の不備を悪用
→単純な設定ミスやOWASP Top 10などの脆弱性
手段の一例
Slide 19
Slide 19 text
MCP Serverにおけるリスク・脅威
MCP Server
攻撃の一例
認可制御の不備と不正な操作
1 リモートに公開されている
MCP Serverへ未認証状態のアクセス
2 検証を行わず操作を行うことが可能
3 操作の結果
クラウドサービスなどを操作する
1
2
3
Slide 20
Slide 20 text
利用や統合におけるリスク・脅威
攻撃者の目的
利用や統合における
リスク・脅威
一つのシステムとしての
脆弱性を用いて
攻撃者の制御下におく
Slide 21
Slide 21 text
利用や統合におけるリスク・脅威
1 データの汚染による
間接プロンプトインジェクション
2 自動化を想定した際の
Notificationの副作用
2 複数のMCP Serverが
存在する場合の悪性相互作用
利用や統合における
リスク・脅威
手段の一例
Slide 22
Slide 22 text
利用や統合におけるリスク・脅威
1 データの更新されたことをMCP Serverに伝達
悪性のプロンプトが含まれる
2 Notificationを基にデータを取得
3 悪意のあるプロンプトをLLMへ入力
４ 悪意のある制御やツールの悪用を指示
5 ツール実行などが”常に許可”であることによる
攻撃者による生成AIアプリの制御
データ汚染もとのアプリを起点に
生成AIアプリを攻撃者が完全な制御下に
生成AIアプリケーション
(MCP Host +MCP Client)
Backend API
MCP Server
攻撃の一例
3
5
4 1
2
Notificationを用いた自動化と
データ汚染による
間接プロンプトインジェクション
Slide 23
Slide 23 text
このような課題を設計や実装で解決するためには？
1 システム全体像の把握と資産の整理
→ “誰(操作主体)”が”なに(資産)”を”どのように(操作)”するかを明確にする
2 自社の制御下に何があり、制御できないものの整理
→ “制御できるもの”と”できないもの”を切り分け、個別に施策を練る
3 取り巻く脅威と考えられる侵入経路の把握
自身がMCPに関連する何かを提供する際に、顧客や情報を守るため
に”設計”や”実装”レベルで対策できることはなんなのだろうか？
Slide 24
Slide 24 text
設計や実装、ドキュメントで解決するためには？
自社の制御下に存在する
資産保護の対策・施策
MCPサーバーやAI Agentの機能レベルの
設計や実装のセキュリティ対策・要件の定義
利用者の端末や
想定される利用用途におけるリスクの低m
機能レベルの設計や実装より少し幅を広げてセキュリティに関する設計・実u
ドキュメンテーションや必要な権限セットの列挙などベストプラクティスの定義
Slide 25
Slide 25 text
章まとめ
1 MCPのリスク・脅威としているが実状は
Webアプリケーションと同様のリスク・脅威と近しい
2 単一では脅威度が低いものでも、
利用の仕方によっては脅威となるものが存在する
→自動化された生成AIアプリケーション + 汚染されたデータを基にしたプロンプ
トインジェクションと攻撃者による制御のような例
3 実装で対応できるものと、そうでないものが存在する
→「ツール実行時に確実に操作者の許可を求める」や「同時に利用するMCP
Serverの制約」などの、現時点では「運用でカバー」のような対応になるものが
存在する
Slide 26
Slide 26 text
02
脅威のモデリング -
AIがアクセスできる情報源 / リソース
Slide 27
Slide 27 text
脅威をモデリングする際の要点
1 脅威のモデリングにおいて大切なことと考え方
2 設計において権限と認可の所在を認識
3 意図しないリソース汚染の可能性の確認
4 機微情報の所在を認識
5 人間の介在を要するかの確認
Slide 28
Slide 28 text
MCPなどのシステムで脅威をモデリングする意義
利用者の要求
提供者として
r MCP Serverであっても、
Webをベースとしたプロダクトと同じ水準でのセキュリティを求めB
r セキュア・バイ・デフォルトを求める時代
r セキュリティインシデントはどのようなものであっても、
プロダクトや会社の信頼や信用を貶めてしまう恐れがある
どこから始めるかを見極めるために”脅威をモデリング”が有効
Slide 29
Slide 29 text
特に生成AIアプリ(MCPも含む)は重要
新しい技術 + 未知のセキュリティリスクを
発見しやすくする
※ここで言う「未知 」は「ベストプラクティスやリスクが整理され公にされていない状況」
攻撃者にも
柔軟で従順なLLMだからこそ脅威を把握したい
Slide 30
Slide 30 text
脅威をモデリングする術を知る
手法は色々あるけど...
手段を知るより、
根本的な価値観や考え方を大事に
STRIDE PASTA VAST SQUARE
Slide 31
Slide 31 text
何を大切にすればいいんだろうか？
1 チェックシート 問題発見と修正する文化
よりも
→ 手段と目的を逆転させない
2 プロセス・
方法論・ツール 話し合いや理解
よりも
→対話をもとに妥協点や解決を探る
3 セキュリティやプライバシー について理解する旅である
→自分事にとらえ咀嚼して理解する
4 脅威を理解可能なモデル
を話すのではなく にする
→誰もが理解できるものに落とし込む
脅威の詳細
5 ではなく を
♻️継続的に改良
→セキュリティや製品、状況の変化に柔軟に対応する
一度
Slide 32
Slide 32 text
脅威をモデリングする意義を原則から改めて考える
1 最も効果的な活用方法は
早期かつ頻繁な分析を通したシステムのセキュリティ向上
2 開発組織のやり方に合わせてシステム変更のたびに
変化に合わせて、扱いやすい対象範囲に絞って実施すべき
3 モデリングされた成果物は関係者がセキュリティにおいて
「役にたつ」と感じたときに意味をなす
4 関係者と共通認識をつくり、その認識を文章化する
結果として効果や進捗を測ることができる
https://www.threatmodelingmanifesto.org/#principles
Slide 33
Slide 33 text
脅威をモデリングする意義を原則から改めて考える
1 最も効果的な活用方法は
早期かつ頻繁な分析を通したシステムのセキュリティ向上
2 開発組織のやり方に合わせてシステム変更のたびに
変化に合わせて、扱いやすい対象範囲に絞って実施すべき
3 モデリングされた成果物は関係者がセキュリティにおいて
「役にたつ」と感じたときに意味をなす
4 関係者と共通認識をつくり、その認識を文章化する
結果として効果や進捗を測ることができる
https://www.threatmodelingmanifesto.org/#principles
Slide 34
Slide 34 text
Re: 脅威をモデリングする術を知る
共通の言語や理解のしやすさをするためのツール
根本的な価値観や考え方に基づいた
ツールやフレームワークの選定
STRIDE PASTA VAST SQUARE
Slide 35
Slide 35 text
今回はSTRIDEっぽくやってみる
S Spoofing of user identity - 偽造
T Tampering - 改ざん
R Repudiation - 否認
I Information disclosure - 情報漏洩
D Denial of service - サービス拒否
E Elevation of privilege - 権限昇格
STRIDEとは
Slide 36
Slide 36 text
自社プロダクト(MCPも含む)のモデリング
IdP
Web Application
MCP Server
DB
1
2
4
5
6 7
8
9
10
11
N1
N2
N3
12
3
B3
B1
B2
B6
B4
B5
MCP利用フロー 通知フロー Web Appのフロー
1 AI Agentに入力
2 認証を行いAccess Tokenの取得(Init時のみ)
3 認証後Access Tokenの払い出し(Init時のみ)
4 LLMに入力
5 LLM が出力、Toolを使う許可を求める
6 Toolを利用する場合、MCP Serverへ
7 APIへリクエスト
8 DBへQuery実行
DBから情報取得
10 APIからレスポンス
11 MCP Serverからレスポンス
12 チャットの出力
N1 非同期処理や特定の処理の通知を送る
N2 ユーザーにツール利用や処理の継続を促す
その後は、1-12までMCP利用フローと同じ
もの。
B1 認証を行いAccess Tokenの取得
B2 認証後Access Tokenを払出す
B3 アプリケーションにリクエスト
B4 DBへQuery実行
B5 DBから結果を取得
B6 アプリケーションからレスポンス
※分かりやすくするためにグラフィカルにしていますが
もう少しシンプルで問題ありません。
Slide 37
Slide 37 text
MCPサーバー(プロダクト)を取り巻く脅威の想定
IdP
Web Application
MCP Server TA06
アプリに悪意のある入力をする
攻撃者
DB
TA03
認可制御の回避を
行う攻撃者
TA04
過剰な通信を行い
サービス停止を試みる
TA05
MCP Serverに付与される
認証情報の奪取
TA02
悪意のあるMCP Serverの
設置を行う攻撃者
TA01: 悪意のある命令を含んだPDFの配布
※TA = 脅威エージェント(Threat Agents)で
資産の悪用や損害を与える攻撃者
Slide 38
Slide 38 text
再掲 - 設計や実装で解決するためには？
自社の制御下に存在する
資産保護の対策・施策
MCPサーバーやAI Agentの機能レベルの
設計や実装のセキュリティ対策・要件の定義
利用者の端末や
想定される利用用途におけるリスクの低j
機能レベルの設計や実装より少し幅を広げてセキュリティに関する設計・実r
ドキュメンテーションや必要な権限セットの列挙などベストプラクティスの定義
Slide 39
Slide 39 text
MCPサーバー(プロダクト)を取り巻く脅威の想定
IdP
Web Application
MCP Server TA06
アプリに悪意のある入力をする
攻撃者
DB
自社の制御下に存在する資産と
それらを取り巻く脅威
設計への反映や
悪用可能な実装不備がないか
調査や修正
Slide 40
Slide 40 text
TA03: 認可制御の回避を行う攻撃者
MCP Serverにおけるリスク・脅威の再掲
MCP Server
攻撃
認可制御の不備と不正な操作
1 リモートに公開されている
MCP Serverへ未認証状態のアクセス
2 検証を行わず操作を行うことが可能
3 操作の結果
クラウドサービスなどを操作する
1
2
3
Slide 41
Slide 41 text
TA06: アプリに悪意のある入力をする攻撃者
利用や統合におけるリスク・脅威の再掲
1 データの更新されたことをMCP Serverに伝達
悪性のプロンプトが含まれる
2 Notificationを基にデータを取得
3 悪意のあるプロンプトをLLMへ入力
４ 悪意のある制御やツールの悪用を指示
5 ツール実行などが”常に許可”であることによる
攻撃者による生成AIアプリの制御
データ汚染もとのアプリを起点に
生成AIアプリを攻撃者が完全な制御下に
生成AIアプリケーション
(MCP Host +MCP Client)
Backend API
MCP Server
攻撃
3
5
4 1
2
Notificationを用いた自動化と
データ汚染による
間接プロンプトインジェクション
Slide 42
Slide 42 text
MCPサーバー(プロダクト)を取り巻く脅威の想定
TA02
悪意のあるMCP Serverの
設置を行う攻撃者
TA01: 悪意のある命令を含んだPDFの配布
利用者の端末や想定される
利用用途における脅威
※自社の制御下に存在しない脅威
利用におけるベストプラクティスや
注意喚起などを行う
Slide 43
Slide 43 text
TA02: 悪意のあるMCP Serverの設置を行う攻撃者
MCP Host + Clientにおけるリスク・脅威の再掲
生成AIアプリケーション
(MCP Host +MCP Client)
悪性のMCP Server
MCP Server - A
攻撃の一例
1
3 4
5
2
６
悪意のあるプロンプトの注入
1 Init時に悪性のMCP Serverに接続
2 Init時に悪意のあるプロンプトを返却
3 悪意のあるプロンプトをLLMへ入力
４
本来アクセスをしたくない/させたくない
MCP Serverのツールを実行を指示
※図の場合は、MCP Server - Aへアクセス後にその結果を悪性のMCP
Serverへ送るように指示
5 通常の処理
6 結果を悪性のMCP Serverに送信
Slide 44
Slide 44 text
1 脅威のモデリングは職人芸や
知識ベースのではない”関係者が全員でやる”ための手法
2
脅威が”なに(資産)”を”どのように(操作)”するかを
明確にしてリスクやその対策を文章化・モデル化でき
現場に落とし込むことができる
3 セキュリティにおける未知を洗い出し、
開発におけるセキュリティの道標を作ることができる
章まとめ
脅威をモデリングする意義と開発へのフィードバック
Slide 45
Slide 45 text
03
プロダクトとして
開発・提供する際の勘所
Slide 46
Slide 46 text
MCPサーバー(プロダクト)を取り巻く脅威(再掲)
IdP
Web Application
MCP Server TA06
アプリに悪意のある入力をする
攻撃者
DB
TA03
認可制御の回避を
行う攻撃者
TA04
過剰な通信を行い
サービス停止を試みる
TA05
MCP Serverに付与される
認証情報の奪取
TA02
悪意のあるMCP Serverの
設置を行う攻撃者
TA01: 悪意のある命令を含んだPDFの配布
※TA = 脅威エージェント(Threat Agents)で
資産の悪用や損害を与える攻撃者
Slide 47
Slide 47 text
MCPサーバーそのものに限った範囲で見ていく
IdP
Web Application
MCP Server
DB
TA03
認可制御の回避を
行う攻撃者
TA04
過剰な通信を行い
サービス停止を試みる
TA05
MCP Serverに付与される
認証情報の奪取
Slide 48
Slide 48 text
プロダクトとして開発・提供する際の勘所
1 MCP Serverは誰が触れていいのか？
→MCP Serverにおける認可制御と権限設計
2 MCP Serverの先のものは誰が話されていいのか？
→MCP ServerとSaaSなどの認可委譲の設計
3 MCP Serverはどの程度接続可能なのか？
→Streamable HTTPだからこその課題への対策(継続的な接続の維持など)
Slide 49
Slide 49 text
今回話すもの
1 MCP Serverは誰が触れていいのか？
→MCP Serverにおける認可制御と権限設計
2 MCP Serverの先のものは誰が話されていいのか？
→MCP ServerとSaaSなどの認可委譲の設計
3 MCP Serverはどの程度接続可能なのか？
→Streamable HTTPだからこその課題への対策(継続的な接続の維持など)
Slide 50
Slide 50 text
今回話すもの
1 MCP Serverは誰が触れていいのか？
→MCP Serverにおける認可制御と権限設計
2 MCP Serverの先のものは誰が話されていいのか？
→MCP ServerとSaaSなどの認可委譲の設計
3 MCP Serverはどの程度接続可能なのか？
→Streamable HTTPだからこその課題への対策(継続的な接続の維持など)
Slide 51
Slide 51 text
リモートMCPサーバーのシステム設計
Record - A2
プロダクトとしてMCPサーバーを提供する場合の構成例
IdP
MCP Server
Object Storage
Object Storage
Backend API - B
Backend API - A
DB - Table B
DB - Table A
Record - A1
Record - B1
Record - B2
Object - 1
Object - 2
tool
tool / resource
tool
Slide 52
Slide 52 text
tool
リモートMCPサーバーのシステム設計
Record - A2
プロダクトとし
てのMCPサーバーとし
て新規開発する箇所
tool
tool / resource
tool
Record - A2
IdP
MCP Server
Object Storage
Object Storage
Backend API - B
Backend API - A
DB - Table B
DB - Table A
Record - A1
Record - B1
Record - B2
Object - 1
Object - 2
Webで公開されるプロダクトと共通のシステム
新規開発
tool / resource
tool
Slide 53
Slide 53 text
リモートMCPサーバーの権限管理と認可制御
IdP
MCP Server
Object Storage
Object Storage
Backend API - B
Backend API - A
DB - Table B
DB - Table A
Record - A1
Record - B1
Record - B2
Record - A2
Q. プロダクトとして提供リモートMCPサーバーの認可制御は何に基づいて考えるべき?
Object - 1
Object - 2
tool
tool / resource
tool
Slide 54
Slide 54 text
リモートMCPサーバーの権限管理と認可制御
IdP
MCP Server
Object Storage
Object Storage
Backend API - B
Backend API - A
DB - Table B
DB - Table A
Record - A1
Record - B1
Record - B2
Record - A2
A. 既存のプロダクトの権限を基に、IdPから払い出されたAccess Tokenを用いて判断する
※JWTでAccess Tokenを払い出している場合は、JWTの検証時にscopesなどを基に操作の可否を判断する。
Object - 1
Object - 2
tool
tool / resource
tool
IdP側でユーザーの権限を管理し、
ユーザーの用いるAccess Tokenに
Scopesとして付与するのが
望ましい
Slide 55
Slide 55 text
リモートMCPサーバーの権限管理と認可制御
IdP
MCP Server
Object Storage
Object Storage
Backend API - B
Backend API - A
DB - Table B
DB - Table A
Record - A1
Record - B1
Record - B2
Record - A2
A. 既存のプロダクトの権限を基に、IdPから払い出されたAccess Tokenを用いて判断する
※JWTでAccess Tokenを払い出している場合は、JWTの検証時にscopesなどを基に操作の可否を判断する。
Object - 1
Object - 2
tool
tool / resource
tool
権限の検証をMCP Serverで
行う以外にBackend API側でも
実施していると、誤った操作が
されにくくなる
Slide 56
Slide 56 text
リモートMCPサーバーの権限管理と認可制御
IdP
MCP Server
Object Storage
Object Storage
Backend API - B
Backend API - A
DB - Table B
DB - Table A
Record - A1
Record - B1
Record - B2
Record - A2
A. 既存のプロダクトの権限を基に、IdPから払い出されたAccess Tokenを用いて判断する
※JWTでAccess Tokenを払い出している場合は、JWTの検証時にscopesなどを基に操作の可否を判断する。
Object - 1
Object - 2
tool
tool / resource
tool
Object Storageなどの
リソースへ直接操作を行う場合
MCP Server側の検証とともに
ABACを用いたアクセス制御を
推奨します
Slide 57
Slide 57 text
今回話すもの
1 MCP Serverは誰が触れていいのか？
→MCP Serverにおける認可制御と権限設計
2 MCP Serverの先のものは誰が話されていいのか？
→MCP ServerとSaaSなどの認可委譲の設計
3 MCP Serverはどの程度接続可能なのか？
→Streamable HTTPだからこその課題への対策(継続的な接続の維持など)
Slide 58
Slide 58 text
資格情報の管理
リモートMCPサーバーからSaaSのAPIを操作するサービスの構成例
IdP
MCP Server Backend API -
Slackの操作
Backend API - A DB - Table A
Slack API
Slack IdP
tool
tool
Slide 59
Slide 59 text
資格情報の受け渡しにおける課題
Q. 資格情報の受け渡しや設定はどのようにすべきか？
IdP
MCP Server Backend API -
Slackの操作
Backend API - A DB - Table A
Slack API
tool
tool
Slide 60
Slide 60 text
資格情報を固定化して利用する
実装例1. 固定の資格情報を用いてBackend API側で認可制御をする
※Slackの場合はアプリ用のAPI Keyを資格情報として用いる
IdP
MCP Server Backend API -
Slackの操作
Backend API - A DB - Table A
Slack API
tool
tool
アプリ用のAPI Keyは
与えられた権限の範囲であれば、
すべてのチャンネルやDMに対して
閲覧や操作ができるので、
場合によってはかなり危険
Slide 61
Slide 61 text
認可委譲を用いてユーザー毎の資格情報を利用する
実装例2. OAuthを用いた認可委譲
※Slackの場合はBot User用のAPI Keyを資格情報として用いて
OAuthを用いて認可委譲を行う
IdP
MCP Server Backend API -
Slackの操作
Backend API - A DB - Table A
資格情報の保管
KVSなど
Slack API
Slack IdP
tool
tool
認可委譲の場合、サービスが求める権限を
個々のユーザーが許可することで、権限を
アプリケーションに移譲することができる
この場合、ユーザーのできることがアプリ
ケーションのできることになるので、権限
の超越などは発生しにくい
Slide 62
Slide 62 text
資格情報の扱い
実装例2.
OAuthを用いた認可委譲
実装例1.
固定の資格情報を用いて
Backend API側で認可制御をする
どちらを採用するかはサービス特性次第だが、
多くの場合ユーザーのできること = サーバーからできることにする方が、
攻撃からのリスクを減らすことができます。
1 MCP Specで定義される
第三者サービス連携の手法
2 サーバーの操作できること = ユーザーの権限
なのでシンプルでわかりやすい
1 連携対象となるサービスが固定で、
操作範囲も明確な場合、管理のコストが低い
2
Backend APIが既存で存在する場合などは
MCP Specに則るより安価に利用できる
※ただし、セキュリティ上の懸念が存在する場合がある
Slide 63
Slide 63 text
章まとめ
1 認可制御は通常のWebアプリケーションの権限に準拠
2 MCP Serverへの権限の付与は用途に応じて行う
3 積極的な認可委譲を推奨
Slide 64
Slide 64 text
おまけ
AI Agentの一機能として
開発・提供する際の勘所
Slide 65
Slide 65 text
AI Agentの一機能として開発・提供する際の勘所
1 どこからプロンプトの材料を取得するのか？
→ 間接プロンプトインジェクションの可能性を考える
2 過剰な権限や機能を利用できないか？
→ 通信を扱うエージェントが機微情報にアクセスできないか
3 エージェントの思考は利用者が確認できるか？
→ ログや思考を確認できる状態にする
あわせて、攻撃者がコントロールしていた際に中断可能にする
4 分離単位は最適なのか？
→ AI Agentのコンテキストの分離が適切な単位で分離されているか
Slide 66
Slide 66 text
AI Agentの一機能として開発・提供する際の勘所
RAG × セキュリティ
検索拡張生成を用いるLLMアプリ
における実装ガイドライン
AI時代の
認可制御入門
AI破産を防ぐために
LLM API利用におけるEconomic DoSのリスクと対策
プロンプト
インジェクション対策
様々な攻撃パターンから学ぶセキュリティのリスク
Amazon
Bedrock
活用の生成AIアプリケーション
セキュリティリスクと対策
MCP・AIエージェント開発
LLMの
外部通信・連携
セキュリティ
LLMガードレールの
活用法と役割を正しく理解する
前
編
セキュリティ考慮事項と
実装における観点
LLM / 生成AIアプリケーションの
セキュリティリスクと対策
後
編
セキュリティ考慮事項と
実装における観点
Slide 67
Slide 67 text
04
まとめ
Slide 68
Slide 68 text
まとめ
1 脅威をモデリングしてセキュリティリスクの可視化をする
2 MCP Serverを開発する際は
”権限”・”責任分解点”・”Web Appと同じ対策”を意識
3 LLMが何を触れて、何を触ってはいけないかを意識
4 人間の関与や強制的な中断を可能にする