クラウドインテグレーション部クラウドソリューション1課の沖本です。
AWS Summit Japan 2024 1日目（6/20）にオフラインで参加してきました。
本記事は私が参加したセッションについてのレポートです。
セッション名：「生成AIでセキュリティ強化！×生成AIの脅威分析」
Level 200： 初級者向け
テーマ：生成 AI・セキュリティ
長谷 有沙 氏
アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 エンタープライズ技術本部 ストラテジック製造グループ中・西日本ソリューション部 ソリューションアーキテクト
生成AIのセキュリティ分野への活用について、以下の2つのテーマに沿ってセッションが進められた。
以下、順番に紹介する。
（1）生成AIの活用方法
ログの分析・レポートの作成や脅威トレンドの要約等の単純なタスクにかける時間を削減し、より本質的な意思決定に注力したい。
→セキュリティアシスタントとしての生成AIの活用がデモとして紹介。
デモでは、生成AIにIAM権限についての質問を入力すると、一般的なIAMのベストプラクティス（ロールやグループを利用、最小権限の原則など）が返答されていた。
具体的なアーキテクチャは、Amazon BedrockとRAGとしてAmazon Kendra、Amazon OpenSerach Serverlessを利用したチャットボットで構築。
デモで利用したモデルは、こちらのGitHub上で公開されている。
（2）生成AI活用時の注意点
生成AI利用時の注意点として、以下が挙げられた。
この中でも「ハルシネーション」対策のコスト効率の良い手段として検索拡張生成（RAG）が紹介された。
検索拡張生成（RAG）とは、「事前に定めた信頼できる知識ベースを参照し、LLM（大規模言語モデル）への質問のインプット情報として利用する」もの。
→既存の基盤モデルを利用することから、構築コストがファインチューニング、事前学習といった手法に比べ低く、またプロンプトエンジニアリングよりは効果が高い。
AWS上でのRAGの構築には以下のサービスが利用可能。
今回のデモのモデルはRAGによって、ユースケースに沿ったインプットがなされている。
1. のまとめ
生成AI自体に対するセキュリティのアプローチには以下の2つのアプローチが存在する。
(1)リスクベースアプローチ
→対象のシステムに対して、脅威モデリング等の手法を用いてセキュリティリスクを分析する。
(2)ベースラインアプローチ
→既存の基準に準じてセキュリティ項目を策定、実施する。
生成AIではまだ基準となるルールが確立されていないため、新しい分野であってもリスク対策が可能な「リスクベースアプローチ」を採用すべき。
今回はその中でも「脅威モデリング」を用いた手法を紹介。
脅威モデリングとは、「脅威を可視化し、セキュリティ対策を実施するための手法」。
異なる脅威についても同様のフレームワークで脅威を比較可能となる。
脅威モデリングを用いて仮想の環境を想定し検討デモを行った。
検討順は以下の通り。
①開発対象のプロダクトを理解する
→ドキュメントやアーキテクチャ図を参照し、守るべき情報の保管場所を検討・確認する。
②①と脅威に関する参考情報を元に、脅威リストを作成する
参考情報にはSTRIDE等の脅威フレームワークとOWAPSが提示している脅威インテリジェンスが紹介。 今回は、OWAPSから悪意あるプロンプトによるデータの詐取（プロンプトインジェクション）のシナリオを検討した。
今回の脅威ステートメントは以下のフォーマットで作成する。（[]内を具体的に置き換える）
ア [前提条件]を備えた[脅威ソース]が、（アクターの特定）
イ [脅威のアクション]を実行しうるため、（アクションの特定）
ウ [脅威のインパクト]につながる可能性があり、（脅威のインパクトの特定）
エ [影響を受ける資産]の[目標]に悪影響を及ぼす（ビジネスへの影響の特定）
これを今回のシナリオに合わせて以下のように編集する。
ア [パブリックなアプリケーションにアクセスできる]を備えた[外部の脅威アクター]が、（アクターの特定）
イ [既存のシステムプロンプトを上書きする悪意のあるプロンプト]を実行しうるため、（アクションの特定）
ウ [他社の医療履歴の情報回答]につながる可能性があり、（脅威のインパクトの特定）
エ [医療情報を保有するデータベース]の[機密性]に悪影響を及ぼす（ビジネスへの影響の特定）
作成したシナリオを元に脅威に対する対策を作成するために、攻撃のステップを整理する。
今回のシナリオでは以下の表のように整理できる。
| 攻撃ステップ | プロンプトを無制限に受け入れる | プロンプトはJJMからLogicへそのまま渡す | LLMはプロンプトを使用してSQLクエリを作成 | SQLクエリ結果はLLMのレスポンスに渡される |
|---|---|---|---|---|
| 対策例 | プロンプトを許容可能な範囲で制限 | 既知のパラメータをサニタイズ | 許容可能なSQLステートメントを定義 | 出力をユーザ関連に限定 |
最後に対応する優先度、STRIDEを設定し脅威リストは完成。
③対処の評価
完成した脅威テストに対しペネトレーションテストorモデリングプロセスの検証（レビュー）によって評価を行う。
2. のまとめ
生成AI×セキュリティという非常に需要のありそうな組み合わせで、とてもワクワクする内容でした。
とくに脅威モデリングのフレームワークは丁寧に例示していただいたおかげで、かなりイメージが付きました。 （そしてやはり既存システムの理解が重要です。。。）
また、RAGという言葉自体は何度か聞いたことはありましたが、他の精度向上方法との違いや具体的な手法のイメージはまったく分かっていなかったので、今回のセッション内で丁寧に説明いただき非常に助かりました。
デモで用いたアーキテクチャはGitHub上でも公開されており、手軽に生成AI環境を構築できると紹介されていたため、生成AI初学者の私ですがぜひ試してみたいと思います。
今後は生成AIとどう付き合っていくかが大きな課題になると思うので、その点でも非常に有意義なセッションでした。