AIシステムの脆弱性診断を実施してみた──診断手法の検討から見えたセキュリティ課題とは【セキュア開発技術Blog】

Securityチーム オーナーの松田です。
AIをシステムに組み込んだ「AIシステム」に関するセキュリティ診断の相談が増えてきました。従来のWebアプリケーション診断だけでは、AI特有のリスクを十分に評価しきれない場面があるためです。

本記事では、KDLのData Intelligenceチーム（データサイエンスやAI関連案件を主に担当）が社内向けに開発したシステムに対して、実際にセキュリティ診断を行った事例をもとに、AIシステムに対してどのような観点で診断を進めるべきかを紹介します。

AIシステムで見るべきリスク

AIシステムには、一般的なWebアプリケーションと同じく、認証・認可不備、機密情報の漏えい、権限過大、ログの不足などのリスクがあります。それに加えて、AIシステムでは次のような固有の論点が増えます。

• プロンプトインジェクションにより、想定していない応答やツール実行が誘発される
• RAGの参照元データが汚染され、回答が誘導される
• LLMに対する大量利用で、コスト増大やサービス停止が起こる
• プロンプトや応答、文字起こし結果など、機微なデータがログや履歴として二次保存される

プロンプトインジェクションは代表的な例です。これは、ユーザー入力や参照文書に混入した悪意ある指示によって、開発者の意図しない振る舞いをLLMに引き起こさせる攻撃です。単に「変な回答を返す」だけでなく、Agent連携がある場合は外部システム操作や情報参照の起点になる可能性があります。

こうした論点は、OWASP Top 10 for LLM Applications 2025 でも整理されています。

対象のシステムは

今回テストしたシステムは、社内情報をもとにチャット形式で回答する社内向けAIシステムです。社内規定や開発ルールなどのKDL独自情報を参照するRAG（Retrieval-Augmented Generation / 検索拡張生成）を備えています。

さらに、独自のAI Agentにより、kintoneやBacklogなどの社内システムと連携します。会議音声の文字起こしや要約も扱います。
※顧客情報を除く、社内の一部の情報のみを連携しています。

内部的にはAzure OpenAI Serviceを利用し、その周辺機能はAzure上で独自開発されています。つまり、単純なチャットUIではなく、社内データ、外部SaaS連携、音声処理、履歴保存まで含む複合的なAIシステムです。

システム構成は、このような内容です。

なぜ脅威モデリングから始めるのか

このシステムは社内情報を多く扱います。加えて、ブラウザ、API、LLM、検索基盤、外部SaaS、データベースなど、複数のコンポーネントをまたいでデータが流れます。

例えば会議音声の処理では、ブラウザからApp Serviceを経由してSpeech Serviceで文字起こしされ、その結果がAzure OpenAIで要約され、最終的にPostgreSQLへ保存されます。どこで認可が必要か、どこでログに残るか、どこで機密情報が滞留するかを整理しないままでは、十分な診断項目を設計できません。

そのため、AIシステムでは特に、脅威モデリングで「どの資産に、どこから、どのような脅威が及ぶか」を先に明らかにすることが重要です。脅威モデリングで洗い出したシナリオをもとにテスト設計することで、診断の抜け漏れを減らせます。

データフローダイアグラム

脅威モデリングでは、データフローダイアグラム（DFD）の作成が有効です。守るべきデータがどこを通るのか、どの境界を越えるのかを可視化できるためです。

例えば、このような図になります。

※ 図はMermaidで管理しています。正式なDFD記法そのものではありませんが、レビューしやすく、継続的に更新しやすい形を優先しました。

どのような脅威を洗い出したか

今回はSTRIDEを使って脅威を整理しました。STRIDEは以下の6分類で脅威を洗い出す手法です。

• Spoofing（なりすまし）
• Tampering（改ざん）
• Repudiation（否認）
• Information Disclosure（情報漏えい）
• Denial of Service（サービス拒否）
• Elevation of Privilege（権限昇格）

今回の診断では、例えば次のようなシナリオを対象にしました。

STRIDE	脅威シナリオ	想定影響	主な確認観点
Spoofing	他システムに設定された本システムのAPIキーが漏えいし、正規利用者になりすまして操作される	不正回答生成、不正タスク作成	APIキーの露出状況、利用経路、スコープ
Tampering	RAGの参照元データに悪意ある内容が混入し、回答が誘導される	誤回答、判断ミス	参照データの更新フロー、レビュー有無
Tampering	Agent連携で権限が広すぎ、想定以上の操作が可能になる	データ改ざん、業務影響	MCP/Agentの権限範囲
Repudiation	誰がどのAgentで何を実行したか追跡できない	事後調査困難	監査ログの有無と粒度
Information Disclosure	プロンプトや応答、文字起こし結果が過剰に保存される	機密情報の二次漏えい	ログ設計、保存先、マスキング
Denial of Service	LLMやSpeech Serviceに大量リクエストが送られ、コスト増大や停止が起こる	サービス劣化、コスト増	ユーザー/APIキー単位のレート制限
Elevation of Privilege	プロンプトインジェクションで想定外のツール実行が誘発される	権限逸脱、外部システム影響	ガードレール、実挙動、認可条件

重要なのは、「AI特有の脅威だけ」を見るのではなく、「従来のWebセキュリティ」と「AI特有の挙動」を一体で診ることです。実際、今回もAPIキー管理、アクセス制御、ログ設計、レート制限など、一般的なWebアプリケーションの論点が多く含まれていました。

AIシステムではグレーボックス診断が有効

今回の診断では、設計確認、設定確認、実装確認、ヒアリング、疑似攻撃試験を組み合わせるグレーボックス型で進めました。

AIシステムでは、ブラックボックスだけでは見えにくい部分があります。たとえば、Agentがどの権限で外部SaaSを呼ぶか、APIキーのスコープがどのように解釈されるか、監査ログに何が残るか、といった点は、画面操作だけでは把握しづらいです。

一方で、実装や設定だけ見ても十分ではありません。プロンプトインジェクション耐性や認可の実効性は、実際にリクエストを送って動作を確認する必要があります。

このため、AIシステムでは「脅威モデリングで論点を定め、グレーボックスで確かめる」という進め方が相性の良いアプローチだと考えています。

診断で見えた主なポイント

今回の診断では、多数の脅威シナリオに対して確認を行い、重大な脆弱性は一つも発見されませんでしたが、その中でも以下の点は重要な結果でした。

1. APIキーの露出は優先対応事項だった

連携システムからのAPI経由で、チャットタスクを作成できますが、一部でAPIキーが参照可能な状態になっておりました。取り扱いとして注意が必要でした。

APIキーにはアクセス制限がされておりましたので、リスクは最小化されてましたが、この状態では、キーの所有者になりすましてAPIを呼び出される可能性があります。

AIシステムでは、モデル自体の安全性に注目が集まりがちですが、実運用ではこのような認証情報の取り扱いが先に問題になることも少なくありません。

連携システムには、APIキーに対して、適切なシークレット管理を実施いただくよう修正いただきました。

2. Agent権限とレート制限は「今すぐ破綻」ではないが改善余地があった

AIシステムから他システムへ連携では、MCPツールセットの権限が広く、連携先の権限次第では操作範囲が大きくなり得ることがわかりました。直ちに重大事故が再現したわけではありませんが、権限最小化の観点では改善余地があります。

また、ユーザー単位やAPIキー単位のレート制限は十分ではなく、OpenAIやSpeech Serviceの利用量増大によるコスト上振れや、可用性低下のリスクが確認されました。AIシステムでは、脆弱性そのものより先に「使われすぎること」が事故になるケースもあります。

対象システムでは、業務に合わせて最小になるような権限設定、ユーザー単位のレート制限を導入いただきました。

3. 良い実装も多く確認できた

診断では問題点だけでなく、既に有効に機能している対策も確認できました。

例えば、CSVダウンロードについては他人が生成したファイルにアクセスできないことを確認できました。また、Agent実行やCSV生成に関するログも残っており、少なくとも今回の確認範囲では、追跡性は確保されていました。

さらに、プロンプトインジェクションに関しても、今回実施したテスト範囲では重大な不正動作は確認されませんでした。もちろん、これで将来の攻撃可能性が完全に否定できるわけではありませんが、少なくとも「AIを使っているから即危険」という単純な話ではなく、個別機能ごとに実証的に確認することが大切だとわかります。

---

KDLでは、開発者全員がシステム開発段階から脆弱性を作りこまないための「セキュア開発トレーニング」を受講しています。そのため、重大な脆弱性は一つも発見されませんでした。特に、ログの必要性については、トレーニングの中でもよく取り上げる内容なので、トレーニングの効果を実感できました。

※本記事で紹介している診断事例は、実際のセキュリティ診断プロセスを説明するために掲載しています。診断により確認された脆弱性や改善事項については、記事公開時点ですべて対応済みであり、現在は適切な対策を講じた状態で運用しています。

この事例から言えること

今回の事例では、AI固有の論点としてはプロンプトインジェクション、RAG汚染、LLM利用量、文字起こしデータの扱いなどを確認しました。一方で、実際に優先度が高くなったのは、APIキー管理のような、より基本的なセキュリティ設計の部分でした。

これはAIシステム診断でよくあるポイントです。AI特有の脅威を理解していることは重要ですが、それだけでは不十分で、認証、認可、秘密情報管理、監査ログ、レート制限といった従来のセキュリティ観点も同時に押さえる必要があります。

つまり、AIシステムの診断では次の両方が必要です。

• LLM、RAG、AgentなどAI特有の挙動を理解した観点
• WebアプリケーションやAPI、クラウド構成に対する従来の診断観点

まとめ

AIシステムは、Webアプリケーションの延長として見ればよい部分と、AI特有の観点を追加で見なければならない部分が混在しています。そのため、一般的なWeb診断だけでは十分でない場合があります。

特に、RAGやAgent、外部SaaS連携、APIキー連携などを含むシステムでは、脅威モデリングで論点を整理し、その結果に基づいてグレーボックスで検証する進め方が有効です。

Proactive Defenseでは、AIシステムに対して、脅威シナリオの整理からテスト設計、実装・設定確認、擬似攻撃試験までを組み合わせたセキュリティ診断を提供しています。AIシステムの導入や運用に不安がある場合は、ぜひご相談ください。