【要約】【AWS】Managed Knowledge Baseでの検索フィルターを確認しました [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
RAGを構築する開発者が、ユーザー権限に応じた文書制御を行う際に直面する課題について述べている。検索クエリが機密情報を含む文書をヒットさせてしまうリスクが主な問題である。具体的には以下の懸念がある。
- ・機密情報の漏洩：権限のないユーザーが、適切なクエリを投げることで機密文書を取得できてしまう。
- ・フィルタの偽装：クライアント側でフィルタを書き換え、権限外のデータへアクセスを試みるリスク。
- ・検索精度の低下：アクセス制御用のメタデータをベクトル計算に含めると、検索の関連性が損なわれる懸念。
// Approach
開発者が、API GatewayのInterceptorを用いて検索リクエストを動的に書き換える手法を採用している。ユーザーの権限を強制的に検索条件へ反映させるため、以下のステップを実行する。
- ・メタデータの準備：S3にサイドカーファイルとして、権限を示す'clearance'属性を配置する。
- ・ベクトル計算の分離：'includeForEmbedding'をfalseに設定し、検索精度への影響を防ぐ。
- ・権限の抽出：Interceptor内でJWTをデコードし、Cognitoのグループ情報からロールを特定する。
- ・フィルタの強制注入：クライアントが送ったフィルタ値を検証せず、サーバー側で決定した値でリクエストを上書きする。
- ・ホワイトリスト設定：'parameterOverrides'に'retrievalConfiguration'を登録し、書き換えを許可する。
// Result
検証の結果、ユーザーの権限に基づいた厳格なアクセス制御が実現できることを確認した。権限のないユーザーに対しては、機密文書が検索候補から完全に除外される。具体的な成果は以下の通りである。
- ・不正アクセスの防止：'contractor'ロールに対し、'staff'権限の文書が検索対象から除外されることを確認。
- ・偽装への耐性：クライアントが不正なフィルタを送信しても、Interceptorによる上書きで無効化される。
- ・制約の特定：Gatewayの'parameterOverrides'設定が、リクエスト書き換えの成否を分ける重要な要素であることを特定した。
Senior Engineer Insight
> 実戦的な設計思想である。特に「クライアントの値を検証せず、サーバー側の値で上書きする」というアプローチは、セキュリティ実装における定石だ。検証ロジックの複雑化を避けつつ、偽装を確実に防げる。ただし、'parameterOverrides'の設定漏れはデバッグが困難なエラーを招くため、IaCでの厳格な管理が求められる。また、Interceptorによるレイテンシへの影響も、シビアな現場では評価対象となるだろう。