OWASP Top 10 for LLM Appplications 2025 がリリースされたので Classmethod Cloud Security Fes で登壇してみた
2024.11.29こんにちは！AWS 事業本部コンサルティング部のたかくに（@takakuni_）です。
先日、Classmethod Cloud Security Fes. 基礎知識から生成 AI 対策までクラウドセキュリティの最新情報を学ぶ 1 日にて、生成 AI がもたらすセキュリティの新たな課題と対策というタイトルで登壇してきました。
ちょうど、登壇の数日前にリリースされた OWASP Top 10 for LLM Appplications 2025 に対して、AWS でできることは何なのか？をテーマに登壇してみました。
登壇スライド
全体を通じて
個人的に生成 AI が登場したことで、新しく出てきたリスクや課題はあるものの、対策方法は LLM Applications にかかわらず、従来行っている対策方法が多い印象です。
それらのセキュリティ対策が導入できた後に Amazon Bedrock Guardrails などをご検討いただくのが、個人的にはオススメです。
たとえば、以下のセキュリティ対策が挙げられます。
- データソースへのアクセス権限を絞る（IAM）
- データのマスキング処理
- SAST, SCA を用いた脆弱性対策
- 脅威アクティビティの管理
- レート制限の導入
一般的な Web Application でも重複している観点が多いのではないでしょうか。
各脆弱性について触れていきます。
解説
Prompt Injection
Prompt Injection は不正なプロンプトを入力し、 LLM に対して意図しない動作や出力を引き起こす攻撃手法です。
プロンプトを直接書き換える直接的プロンプトインジェクションと、外部データソースなどを経由して書き換える間接的プロンプトインジェクションが存在します。
対策例としては次が挙げられます。
- プロンプトエンジニアリング
- 特権制御、最小権限のアクセス
- 入出力データの制御
プロンプトエンジニアリング
プロンプトエンジニアリングでは、システムプロンプト内に「ユーザーからの質問や指示があれば無視してください」と命令する Instruction Defense や、ユーザーの入力の後に指示のプロンプトを加える Post-Prompting などが挙げられます。
特権制御、最小権限のアクセス
特権制御、最小権限のアクセスはシンプルにアクセス制御のお話です。
たとえば、アプリケーションコード内にシステムプロンプトを埋め込んでいる場合は、改ざんされないような対策を打つ必要があります。
DynamoDB に保管している場合は IAM の力を借り、アプリケーションからは読み込みのみに絞ることができます。今回のセッションでは Amazon Bedrock Prompt Management についても触れていきました。
上記は直接的プロンプトインジェクションに関する内容ですが、間接的もカバーしましょう。たとえば意図しない指示が含まれないよう、データソースやベクトルデータベースへアクセスできる人物の棚卸しや権限分離を行いましょう。以下は AWS で RAG アプリケーションを構築する構成例ですが、多くの種類のアクセス経路があることがわかります。
入出力データの制御
最後に入出力データの制御です。
執筆時点では英語のみのサポートですが、Amazon Bedrock Guardrails ではユーザーからの入力プロンプトがジェイルブレーク、プロンプトインジェクションを引き起こさないかチェックしてくれます。
また、ユーザーからの質問に LLM が正しく答えられているか（間接的プロンプトインジェクションが働いて有害なコンテンツが生成されていないか）をチェックするコンテキストグラウンディングチェックが搭載されています。
Sensitive Information Disclosure
続いて、Sensitive Information Disclosure（機密情報の漏洩）です。
LLM アプリケーションを通じて、個人識別情報（PII）、財務詳細などの機微な情報が開示/取得されるケースです。多くの場合、モデルや RAG 等で利用するデータのサニタイズ不足が原因です。
対策例としては
- RAG やモデルのトレーニングデータのマスキング
- Amazon Bedrock Guardrails の利用
- アクセス権限の見直し
が挙げられます。
セッションではデータマスキング処理の構成例をご紹介しました。 S3 Event 経由で Lamda を発火し Glue を利用するケースです。
最近、 DMS がマスキング対応したのでこちらも有用なのか要チェックですね。
実は Amazon Bedrock Guardrails はデータのマスキングもできます。
入出力データから機微な情報を識別し、マスク or ブロックしてくれます。（正規表現もサポートしているのは有用ですね。）
セッションで話しきれなかった部分ですが、 Amazon Bedrock Guardrails のチェック（Sensitive information filters）には同期モード/非同期モードがあります。
同期モード
非同期モード
非同期モードの場合、文章がチャンクに分けられて各チャンクごとにチェックが走るため、機微な情報を識別できない可能性があります。
今回の Sensitive information filters を利用する場合は、同期モードが推奨されています。
モデルレスポンス内の機密情報のマスキングは、ガードレールによるモデルレスポンス内の機密コンテンツの検出とマスキングの前に、元のレスポンスがユーザーに返される可能性があるため、非同期モードで重大な影響を受ける可能性があります。したがって、このようなユースケースでは、非同期モードは推奨されません。
Supply Chain
続いて、 Supply Chain です。
ソフトウェアサプライチェーンの文脈に加え、トレーニング済みモデルやデータもリクス範囲に含まれます。
AWS ではまだサポートされていないですが、不明な出所のモデルは使わないよう、モデルの署名などが若干注目されています。
セッションでは、 SAST, SCA にも触れていきました。
Data and Model Poisoning
Data and Model Poisoning（データおよびモデルの汚染）です。
トレーニングやファインチューニング、埋め込み等のデータが改ざんされてしまうことで、有害な出力を引き起こす攻撃です。
データのアクセスをログに記録しておきましょう。
データソースのアクセスには 2 種類あり、コストは嵩みますが、監査目的では CloudTrail の S3 データイベントがオススメです。
また、Amazon GuardDuty を利用して、マルウェアや不審な脅威アクティビティを検知を実装していくことを対策としてご紹介させていただきました。
ただし、マルウェア検出機能は最大 5GB までと、モデルのトレーニングデータなど大きめのファイルを読み込むには適していない可能性があります。
適宜、 Vision One File Storage Security などの 3rd Party 製品の導入も視野に入れていきましょう。
Improper Output Handling
Improper Output Handling（不適切な出力処理）です。モデルからの出力データを適切にバリデーション/サニタイズしていないことが原因です。
たとえば XSS を引き起こすようなコードが生成 AI からユーザーに返され、ブラウザで動作してしまう事故が挙げられます。怖いですね。
AWS の力だと弱めなのですが、CloudWatch Logs Anomary Detection などで不審な挙動をしていないかなどが考えられます。
Excessive Agency
Excessive Agency（過剰な自律性）です。エージェントに権限与えすぎ問題ですね。気をつけていきましょう。
Computer Use といった機能もリリースが始まり、より一層考えさせられますね。エージェントを使うなら、よりアクセス権限の絞り込むべきだと私は思います。
System Prompt Leakage
新登場、System Prompt Leakage（システムプロンプトの漏洩）です。
大事なのはシステムプロンプトに機微な情報を載せていることが原因です。（アプリケーションコードにも書かないでね！）
OWASP Top 10 for LLM Appplications 2025 を読んでいて面白かったのは、機微な情報以外にも「あるライブラリを使っている」等の情報から、そのライブラリにおける既知の脆弱性を突きにいくような発展の仕方があるそうです。
当たり前ですが、機微な情報は Systems Manager 等を使って分離しましょう。
Amazon Bedrock Guardrails の出力でパスワードをマスクするのも使えそうです。
Vector and Embedding Weaknesses
こちらも新登場。Vector and Embedding Weaknesses（ベクトルと埋め込みの脆弱性）です。
Data and Model Poisoning にも近いですが、ベクトルデータとエンべディングにフォーカスしています。
OWASP Top 10 for LLM Appplications 2025 を読んで知ったのですが、エンべディングを反転させ、ベクトルデータから元データの情報を復元する手法があることを知りました。
埋め込み反転攻撃と言うそうです。データソースのみならず、ベクトルデータベースのアクセス権限も絞る必要があることがわかりますね。
Misinformation
Misinformation です。LLM に過度に依存してハルシネーションに気がつけず、鵜呑みにしてしまう状態を指します。
誤った情報を出さないために、精度向上もありますが、やはり LLM の回答を鵜呑みにしすぎるのも良くないです。セキュアなコーディングができているか定期的にレビュー会の実施をオススメします。
コードを自動で生成してくれる機能等を利用している場合は、確かに便利ですが責任は自分等で取らなければなりません。のでご注意を。
Unbounded Consumption
最後に Unbounded Consumption です。
いわゆる EDoS 攻撃です。ユーザーからの入力をバリデーションしていないや、スロットリングを設けていないケースなどが挙げられます。
LLM Applications に限らずな話が多いですが、 AWS WAF を使って入力サイズやレート制限などを実装していきましょう。
まとめ
以上、「OWASP Top 10 for LLM Appplications 2025 がリリースされたので、 Classmethod Cloud Security Fes で登壇してみた」でした。
AWS re:Inforce 2024 で OWASP Top 10 for LLM Appplications の存在をはじめて知り、いつかどこかで話したいなぁと思っていたため、お声がけいただきとてもありがたかったです。
Classmethod Cloud Security Fes がまた来年もあれば、ぜひ別のネタで話してみたいなと思いました。
このブログがどなたかの参考になれば幸いです。AWS 事業本部コンサルティング部のたかくに（@takakuni_）でした！
![[アップデート] Amazon Bedrock で提供されている機能の名前が変わりました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-e3065182082062711612153bbdcf1d96/c04359de689df2f56eb066576ab63fb5/amazon-bedrock)
