V5. 安全な LLM 統合 (Secure LLM Integration)
管理目標
アプリケーションコンポーネントと LLM との間の安全なインタラクションとオペレーションを可能にするコントロールを確立します。
5.1
LLM へのプロンプトが信頼できるサーバーサイドコンポーネントから発行されることを確保します。
✓
✓
✓
5.2
LLM へのプロンプトが、クライアントから直接完全なプロンプトを受け付けるのではなく、サーバーサイドで構築されることを確保します。
✓
✓
✓
5.3
冗長 LLM アカウントとプロバイダの使用を検討して、単一障害点を回避し、アプリケーションの可用性を確保します。
✓
5.4
LLM プロバイダのクレデンシャルが OWASP ASVS のセクション V2.10 「サービス認証」に従って安全に処理されることを確保します。
✓
✓
5.5
LLM から返される出力形式とプロパティが期待される構造とプロパティに一致していることを確保します。特に、レスポンスが JSON で期待される場合、その結果が有効な JSON 形式であるだけでなく、スキーマバリデーションを受けて、期待されるすべての JSON フィールドを含むこと、および不要なプロパティや余計なプロパティを含まないことを確保する必要があります。
✓
✓
✓
5.6
LLM レスポンスの出力言語が期待される言語と一致することを確保します。
✓
✓
5.7
LLM プロンプトにカナリアトークンを使用して、LLM 完了時にカナリアワードを含むかどうかをチェックし、プロンプト漏洩攻撃を検出することを検討します。
✓
5.8
LLM レスポンスのエントロピーをチェックして、カナリアトークンをバイパスするなどの追加チェックを回避することを目的としたエンコードされたデータを検出します。
✓
5.9
LLM 完了時に長さチェックを実行して、レスポンスの長さが期待された範囲内であることを検証します。たとえば、通常の出力の長さより大幅に長いレスポンスは、完了時に追加の予期しないデータを含んでいることを示している可能性があります。
✓
5.10
アプリケーションが LLM とインタラクションする際に例外やエラーメッセージを適切に抑制することを確保します。LLM エラーは不注意にプロンプトを漏洩する可能性があり、クライアントには見えないようにする必要があります。
✓
✓
✓
5.11
適切な LLM ガードを使用して、プロンプトとコンピレーションをスキャンし、潜在的なプロンプトインジェクション攻撃の検出に役立つことを確保します。
✓
✓
5.12
すべてのプロンプトが信頼できないものとみなされ、デプロイされているセキュリティコントロールの対象となることを確保します。保存されたデータ、サードパーティ API からのデータ、以前のプロンプト完了時からのレスポンスを反映すると、間接的なプロンプトインジェクションにつながる可能性があるため、ユーザーからの直接入力を含むプロンプトと同じコントロールの対象としなければなりません。
✓
✓
5.13
LLM 完了時の出力が後続のシステムによって信頼できないとみなされることを確保します。たとえば、SQL クエリ内で LLM レスポンスを使用する場合、クエリは LLM レスポンスのパーツを連結して構築すべきではなく、OWASP ASVS のセクション V5.3.4 に従い、パラメータ化されたクエリを使用する必要があります。
✓
✓
✓
5.14
LLM の呼び出しを行うシステムに適切な API レート制限があり、予期しない過剰な LLM コストが発生する可能性がある LLM への過剰な呼び出しを回避することを確保します。
✓
✓
5.15
LLM プロバイダ構成内でコストアラートがアクティブであり、コストが予想を上回った場合にアラートされることを確保します。
✓
✓
✓
5.16
正常な LLM インタラクションのベースラインを定義して監視し、異常な LLM インタラクションが検出された際にアラートします。
✓
5.17
匿名ユーザーが特性をプレビューできる機能が、必要な特性のみを許可するよう適切に制限されることを確保します。
✓
✓
Last updated