RAGワークフローをセキュアに保護する方法

検索拡張生成（RAG）ワークフローは、AIシステムをエンタープライズナレッジベースに接続するため、検索認可がパイプラインにおいて最も重要なセキュリティ上の決定となります。有効な認証情報を持つエージェントは、要求元のユーザーがアクセスを許可されていないドキュメントを、従来型のアクセスコントロールフラグをトリガーせずに表示させる可能性があります。データとモデルの防御は必要ですが、どちらか一方だけでは検索認可を管理できません。エージェントを認証し、クエリ時に認可を実施し、すべての検索ホップでユーザーコンテキストを伝播することで、アイデンティティ制御プレーンに基づいたIdentity Security Fabricは、RAGワークフローのセキュリティを強化するのに役立ちます。

RAGセキュリティの3つのレイヤー

RAGワークフローは、3つの異なるレイヤーでリスクをもたらします。セキュリティに関するガイダンスでは、そのうちの2つに焦点が当てられることがよくあります。

データレイヤーとモデルレイヤーは不可欠ですが、どちらもRAGの中核的な疑問、つまりこのアイデンティティ（人間またはエージェント）は、この情報を取得して操作する権限があるかどうかには答えていません。多くの環境において、エージェントが持つ技術的なアクセス権と、実際にアクセスを要求しているユーザーの権限は異なる場合があります。そのギャップこそが、RAGセキュリティにおけるアイデンティティに関する根本的な問題です。

RAGのセキュリティ脅威モデル、OWASP LLMトップ10にマッピング

OWASP Top 10 for LLM Applicationsは、AIシステムにおけるセキュリティリスクを特定するための広く参照されているフレームワークです。上位のリスクの多くは、RAGアーキテクチャにおいて直接的なアイデンティティの側面を持っています。

IDガバナンスは、これらのリスクそれぞれにおいて重要な要素となります。権限を超える動作をするエージェントや、ユーザーのエンタイトルメントが**ダウンストリーム**で強制されないまま放置されると、これらの脆弱性のいずれもがデータ漏洩インシデントに変わる可能性があります。

RAGワークフローを段階的に安全に保護する方法

データおよびモデルレイヤーには、成熟したプレイブックが用意されています。以下の手順では、ほとんどのRAGアーキテクチャで依然としてギャップが残っているアイデンティティレイヤーに焦点を当て、データおよびモデルの制御について簡単に説明します。

1. データレイヤーの保護：取り込み、ベクトルストア、および取得

ソース検証は、信頼できないオリジンからのドキュメントがベクターストアに到達する前に、それらのドキュメントを除外します。データ分類タグは、取り込み時に機密レベルごとにコンテンツを分類し、ダウンストリーム認可の決定を可能にします。PIIフィルタリングは、個人情報が組み込まれてインデックス化されるのを防ぎ、検索許可が評価される前に情報漏洩のリスクを軽減します。

このレイヤーには、性質の異なる2つの脅威が存在するため、それぞれに対する防御が必要です。データポイズニングは、悪意のあるソースドキュメントや改ざんされたソースドキュメントを介して、取り込み中に知識ベースを破損させます。間接的なプロンプトインジェクションは、一見正当なコンテンツに指示を組み込み、推論時にエージェントの動作をハイジャックするものであり、ステップ5のモデルレイヤーで取り上げられています。アイデンティティ制御は、間接的なプロンプトインジェクションに対する効果的なアップストリームチェックとなります。アクセス ポリシーによってドキュメントが制限されている場合、エージェントはそのコンテンツに関係なく、ドキュメントを取得することはありません。

ベクターストアでは、保存時および転送中の暗号化が基本となります。テナントのセグメンテーションにより、マルチテナントアーキテクチャにおいて、テナント間で埋め込みが分離されます。

暗号化とフィルタリングにより、データが外部から保護されます。正当なエージェントが、リクエストしているユーザーがアクセスすべきでないデータを取得することを阻止するものではありません。それは認可の問題です。

2. 取得時のきめ細かい認可の実施。

きめが粗いRBACは、予測可能な職務を持つ人間のユーザー向けに設計されました。RAGワークフローでは、ユーザーがフォルダーに対するエンタイトルメント（権限）を持っていても、そのフォルダーに含まれるすべてのドキュメントに対するエンタイトルメントを持つとは限りません。ロールレベルのゲートは、粒度が粗すぎます。ドキュメントレベルのアクセスコントロール、および一部の保証レベルが高いアーキテクチャにおけるチャンクレベルの制御では、よりきめ細かいポリシーモデルが必要になります。確立された2つのFGAアプローチがRAG検索に適用されます：

• ReBAC（Relationship-Based Access Control：関係性ベースのアクセス制御）は、リソースに対するユーザーの関係性（プロジェクトのメンバーシップ、所有権、組織階層など）に基づいてアクセスを許可します。
• ABAC（属性ベースのアクセス制御）は、ユーザー、リソース、およびコンテキスト属性を評価します。これは、データ分類タグに応じて判断が必要な場合に役立ちます。

重要な区別として、ベクトルストア内のメタデータフィルタリングはポリシー実行ポイント（PEP）ですが、ポリシー決定ポイント（PDP）はアイデンティティコントロールプレーンに配置する必要があります。ベクターストアは、ポリシーエンジンによって発行された決定事項を適用するものであり、決定を下すものではありません；認可は、エージェント自身のシステム認証情報を使用するだけでなく、ユーザーの代わりに委任された権限で動作するリトリーバーによって評価される必要があります。PDPをPEPに、またはリトリーバー自身の認証情報にまとめることは、一般的なアーキテクチャ上の失敗です。

3。AIエージェントのアイデンティティを確立する

AIエージェントは、エンタープライズIdentity Security Fabric内で非人間アイデンティティ（NHI）として扱う必要があります。集中型のIdentity Governanceがない場合、RAGパイプラインとそれを提供するエージェントが、インベントリ、所有権、またはアクセスコントロールなしにチーム全体に拡散し、シャドーAIを生み出す可能性があります。非人間アイデンティティ（NHI）を管理するには、そのディスカバリーとポスチャ管理が前提条件となります。インベントリされていないエージェントに対して、最小権限を強制することはできません。すべてのエージェントは、共有 APIキーや過剰なスコープのサービスアカウントではなく、固有のアイデンティティを必要とします。

エージェントがどのように認証を行うかによって、侵害された認証情報が引き起こす可能性のある損害の範囲が決まります。OAuth 2.0のクライアント認証情報とmTLSはどちらも、保存されたシークレットまたは証明書を必要としますが、両方ともローテーションをサポートしています。ワークロード・アイデンティティ連携は、長期にわたって保存されるシークレットを不要にします。プラットフォームは、署名付きのアイデンティティアサーションを発行します。エージェントは、このアサーションをスコープ指定された有効期間の短いアクセストークンと交換します。適切に実装およびローテーションされていれば、これらのアプローチはそれぞれ、共有キーや スタンディング サービスアカウントよりも強力なセキュリティ特性を提供します。

4. OAuth 2.0トークン交換によるユーザーコンテキストの伝播。

エージェント型RAGにおいて、Confused Deputy（混乱した代理）問題は、有効な認証情報を持つエージェントが要求元ユーザーに許可されていないデータを取得する場合に発生します。OAuth 2.0 Token Exchange（RFC 8693）は、標準化されたレスポンスの1つです。RFC 8693に基づき、ユーザーのアイデンティティトークンはサブジェクト、エージェントのアイデンティティはアクターとなり、検証可能な委任チェーンが確立されます。

この委任の方向性は、混乱した代理問題を軽減するのに役立ちます。エージェントは、ユーザーに許可されている範囲を超えて動作することはできません。有効なアクセスは、リクエストを行うユーザーのエンタイトルメントによって制限され、さらにエージェントの認可されたスコープによって制約されます。両者が合わさることは決してありません。その制約こそが、すべてのホップにおける認可のギャップを埋めるものです。

5. プロンプト層と出力層を防御する。

入力サニタイズ、出力フィルタリング、ガードレール、およびツール呼び出しの検証は、システムプロンプトと、外部コンテンツがコンテキストウィンドウに入力されるすべてのポイントで適用されます。間接的なプロンプトインジェクションは、優先的に対応すべきRAG固有のリスクです。取得ステップは、信頼できないコンテンツがモデルに到達するための認可された経路です。OWASP Top 10 for LLM Applicationsは、このレイヤーに対して広く採用されている実装ガイドラインを提供します。

6. すべてのエージェントの操作を監視、ログ記録、監査します。

すべての検索、プロンプト、ツール呼び出し、および応答は、エージェントのアイデンティティコンテキスト（どのエージェントが、誰の委任の下で、何にアクセスしたか、いつアクセスしたか）とともにログに記録される必要があります。コンプライアンス監査では、認可制御が構成されただけでなく、実際に適用されたことを確認できます。SIEM/SOARの連携により、RAGテレメトリをより広範なセキュリティ監視スタックに取り込むことができます。取得パターンにおける異常検知は、侵害されたエージェントの兆候を早期に発見できます。これには、通常の範囲外のアクセス、開始ユーザーの権限と一致しない量、確立された行動ベースラインからの逸脱などが含まれます。

7. RAGワークフロー全体にゼロトラストを適用する。

RAGにおいて、ゼロトラストは主にネットワーク境界だけでなく、検索レイヤーにおけるアイデンティティを認識した認可によって実現されます。決して信頼せず、常に検証を行います。これには、同じワークフロー内でのエージェント間の呼び出しも含まれます。短期間のトークン、継続的な認可、およびすべてのホップでのポリシー適用は、その原則の運用上の表現です。NIST SP 800-207は、ゼロトラストの基礎となる参考資料を提供します。

RAGがエージェント化されると、セキュリティにはどのような変化が起こるのか

上記の7つの制御は、すべてのRAGワークフローに適用されます。RAGがagenticになると、複数ステップの推論、ツール呼び出し、連鎖的なエージェント委任が導入されますが、各ステップは認可のギャップが拡大する新たな機会となります。アイデンティティコントロールプレーンは、最初のリクエスト時だけでなく、エージェント間やエージェントとApplication （アプリケーション）間の呼び出しを含むすべてのホップで、ユーザーコンテキストを伝播する必要があります。標準規格に準拠した委任パターンは、ダウンストリームコール全体で OAuth 2.0 トークン交換を拡張し、チェーン内のどのエージェントも要求元ユーザーの権限を超えないようにします。

RAGにおける一般的なセキュリティのミス

影響の大きいRAGセキュリティの多くのエラーは、予測可能なアイデンティティのエラーが静かに積み重なって起こります。

• エージェントの許可をユーザーの許可として扱うこと： エージェントは、サービスを提供しているユーザーよりも広範なアクセス許可を持っている可能性があります。リトリーバーがユーザーのエンタイトルメントではなく、エージェントの認証情報に基づいて動作する場合、ユーザーがアクセスを許可されていないドキュメントを返す可能性があります。
• LLMにアクセスコントロールを委ねること：モデルは、ユーザーが何にアクセスすることを許可されているかを判断できません。この決定をプロンプトに移行することで、アイデンティティ制御プレーンから完全に切り離されることになります。
• 広範囲に及ぶ検索用サービスアカウント： 知識ベース全体へのスタンディング読み取りアクセス権を持つ検索ツールは、誰が質問したかに関わらず、意味的に関連するものをすべて返します。
• プロンプトから検索、応答に至るまでの監査証跡がない： すべてのステップで属性が付与されていないと、データ漏洩イベントを調査したり、監査役に説明したりすることができません。
• エージェントの静的で長期的な認証情報：長期的な認証情報を持つ侵害されたエージェントは、長期間にわたり検出されずに動作し、侵害の範囲を拡大させる可能性があります。

よくある質問（FAQ）

RAGにおける最大のセキュリティリスクは何ですか？

エンタープライズRAGの展開において、最大のリスクは過剰な権限による検索です。これは、エージェントが要求元のユーザーに表示する権限がないデータを返してしまうことです。多くのRAGアーキテクチャはデータとモデルを保護していますが、リクエスト元のユーザーの権限を超えて動作する正当なエージェントから、検索レイヤーを保護していません。

RAGのセキュリティは、従来のApplication （アプリケーション）セキュリティとどのように異なりますか？

RAGは、自律的に動作する非人間アイデンティティ（NHI）、リアルタイムの認可の判断を必要とする検索レイヤー、およびエージェントチェーン全体にユーザーコンテキストを伝播する必要性を導入します。従来のアクセスコントロールモデルは、そのような状況を想定して設計されたものではありませんでした。

RAGのセキュリティにおいて、アイデンティティはどのような役割を果たしますか？

アイデンティティは、RAG防御の3つのレイヤー（データ、モデル、検索）すべてを接続する基盤となるコントロールプレーンです。誰が（人間またはエージェント）、どのような委任された権限の下で何を取得できるかを決定し、それを検証するための監査証跡を提供します。

RAGにおける認可ギャップとは何ですか？

認可ギャップとは、AIエージェントが技術的にアクセスできる範囲と、要求元のユーザーが表示を許可されている範囲との差のことです。これは、エージェントの認証情報がユーザーの許可を超えている場合に最もよく発生します。標準規格に準拠したこのアプローチでは、取得レイヤーでのきめ細かい認可と OAuth 2.0 Token Exchange を組み合わせることで、エージェントの認証情報ではなく、要求元のユーザーのエンタイトルメントに対してすべての取得が評価されます。

RAGワークフローにゼロトラストをどのように適用しますか？

取得、ツール呼び出し、エージェント間のインタラクションはすべて、検証されるまで信頼できないものとして扱ってください。アクションごとに、有効期間が短く、スコープが限定されたトークンを発行します。すべてのホップでポリシーを適用します。RAGにおけるゼロトラストの実践的な表現は、境界防御ではなく、検索レイヤーでの認可です。

Oktaを使用してAIエージェントとRAGを大規模に保護する

認可のギャップを埋めるには、RAGワークフロー全体で、人間のアイデンティティ、AIエージェント、および検索認可を接続するIDコントロールプレーンから始める必要があります。Oktaプラットフォームは、組織がAIエージェントを非人間アイデンティティ（NHI）として管理し、取得レイヤーで詳細な認可を適用し、エージェントワークフロー全体でユーザーコンテキストを伝播し、要求ユーザーから最終的なAI応答までの追跡可能な監査証跡をサポートすることに役立ちます。

詳細を見る

これらの資料は、一般的な情報提供のみを目的としており、法律、プライバシー、セキュリティ、コンプライアンス、またはビジネス上の助言ではありません。

このコンテンツは、最新のセキュリティ、法律、および/またはプライバシーの動向を反映していない可能性があります。このコンテンツの利用者は、自身の責任において、自身の法的および/または専門的アドバイザーから助言を得るものとし、本資料の情報に依存すべきではありません。

Oktaは、本コンテンツに関していかなる表明または保証も行いません。また、これらの推奨事項をお客様が実施した結果生じるいかなる損失または損害に対しても、Oktaは責任を負いません。お客様に対するOktaの契約上の保証に関する情報は、okta.com/agreementsでご覧いただけます。