RAG 的權限模型：多租戶與文件級授權

三種常見模型

• 租戶隔離：不同客戶的資料完全分開，最好用實體隔離（不同索引或不同集合）。
• 角色式（RBAC）：文件標記可存取的角色，使用者持有角色清單。
• 屬性式（ABAC）：依部門、職級、專案等屬性動態判斷，彈性最高但也最複雜。

索引時寫入 ACL

{
  "text": "...",
  "meta": {
    "tenant_id": "acme",
    "acl_roles": ["hr", "manager"],
    "acl_users": [],                 // 個別授權，通常為空
    "classification": "internal"     // public | internal | confidential
  }
}

查詢時強制過濾

def build_filter(user):
    return {
        'tenant_id': user.tenant_id,                    # 租戶：絕對條件
        '$or': [
            {'acl_roles': {'$in': user.roles}},
            {'acl_users': {'$in': [user.id]}},
            {'classification': 'public'},
        ],
    }

# 檢索函式不接受「不帶 filter」的呼叫
def search(q, user, **kw):
    return index.query(q, filter=build_filter(user), **kw)

把過濾封裝在檢索函式內部，讓它不可能被忘記。程式碼審查時，任何直接呼叫底層索引的地方都應該被擋下。

快取的隔離

快取是權限外洩的常見破口。快取鍵必須包含租戶與使用者的權限指紋，否則 A 的答案會被回給 B。

perm_fp = hashlib.sha256(
    json.dumps({'t': user.tenant_id, 'r': sorted(user.roles)},
               sort_keys=True).encode()).hexdigest()[:12]
cache_key = f'{perm_fp}:{query_hash}'

可稽核性

• 記錄每次檢索的使用者、套用的 filter、回傳的 doc_id 清單。
• 記錄權限變更事件，與檢索日誌可對照。
• 定期跑自動化的權限測試：用各種角色的測試帳號查詢敏感文件，斷言結果為空。

權限變更的即時性

使用者離職或轉調後，權限必須立即生效。若你的系統把角色快取在 session 裡，就會有一段空窗期。敏感場景應該每次檢索都向授權來源確認，或把快取存活時間壓到極短。