今日目標

學習如何將 RAG 系統從原型升級為企業級 SaaS，構建滴水不漏的安全堡壘。核心目標包括：

• 多層次權限控制架構：從租戶到文件，實現細粒度的訪問控制（RBAC + ABAC/PBAC）。
• 數據保護與合規：掌握數據加密、脫敏、審計日誌、備份刪除策略。
• 性能與安全的平衡：理解如何在保障安全的同時，優化檢索性能與用戶體驗。
• RAG 特有風險防護：防止 Prompt Injection、Data Exfiltration 及跨租戶資料洩露。

一、為什麼安全是 RAG 的生死線？

企業知識庫是公司的核心資產，包含高度敏感的資訊：

• 法律合規數據：GDPR、HIPAA 等法規下的個人資料。
• 商業機密：產品藍圖、財務數據、客戶名單。
• 人力資源數據：員工薪資、績效評估、個人身份資訊（PII）。

⚠️ 任意數據外洩或越權存取都可能導致巨額罰款，甚至摧毀企業與客戶的信任。因此，安全必須從架構設計初期就嵌入系統核心。

二、權限控制架構：從租戶到文件

權限控制需要分層設計，確保不同租戶、不同用戶、不同文件之間的隔離與可控性。

1. 租戶層級（Tenant-Level）

• 概念：多租戶 RAG 的第一道防線。
• 實作：API 請求與向量資料庫查詢必帶 Tenant ID 作為 Pre-filter。
• 高敏需求：提供獨立索引或資料庫 Schema 的「硬隔離」方案，避免任何跨租戶數據接觸。

2. 角色層級（RBAC）

控制 誰可以做什麼操作，通常透過 OAuth2/OIDC 進行身份驗證，JWT Token 內包含角色資訊，服務端驗證 API 權限。

3. 文件層級（ABAC/PBAC + Metadata）

• 概念：RAG 系統獨有的細粒度控制，確保部門或機密等級隔離。
• 實作方法：
  1. 在向量嵌入時加入 權限元數據（department=HR、access_level=Confidential、region=EU 等）。
  2. 用 ABAC（Attribute-Based Access Control）或 PBAC（Policy-Based Access Control） 引擎（如 OPA/Rego）做動態策略決策。
  3. 檢索時，系統自動將使用者屬性與策略過濾條件合併到 Metadata Filter 中。
• 舉例：HR 用戶查詢 (department=HR OR access_level=Public)，無法訪問工程部門或財務機密。

三、數據保護：守住資料生命週期

1. 加密（Encryption）

• 傳輸中：TLS/SSL
• 靜態存儲：資料庫、文件、向量索引全加密
• 進階：
  • 客戶自管金鑰（CMK/BYOK/HYOK）
  • 金鑰輪換與 HSM 保護
  • 備份、快照也需加密並控制訪問

2. 數據脫敏與 PII 處理

• 輸入端：上傳文件前使用 NLP 模型識別 PII，進行 脫敏或權杖化（tokenization）。
• 檢索/生成端：RAG 回答前檢查並脫敏，防止意外外洩。
• 附加防護：蜜罐文件或金絲雀 token，可偵測內部濫用或 API key 被盜。

3. 審計日誌（Audit Logging）

• 記錄內容：Who、When、What、Where、Result
• 存儲方式：WORM 或簽章鏈/Hash-chain，確保不可篡改與可追溯
• 覆蓋範圍：檢索請求、命中文件、過濾條件、最終回答

4. 備份與被遺忘權

• 挑戰：備份是 WORM，直接刪除困難
• 解法：
  1. Operational Plane 即時刪除：原檔、元數據、向量索引同步刪除
  2. 備份加密與 Crypto-Erasure：刪除金鑰即可使舊快照無法解密
  3. 到期自動刪除 + 刪除證明（可稽核）

四、RAG 特有風險防護

• Prompt Injection / Data Exfiltration：檢索—生成間加入白名單/紅名單檢查，避免模型被誘導讀取或外傳敏感資料。
• 上下文隔離：不同租戶上下文絕對隔離，避免 few-shot 或 embedding 泄露。
• 工具/Function 調用策略閘：防止 LLM 將結果導出或操作外部服務。

五、性能優化與實務解法

六、合規框架

想想看

1. 文件 ACL 過濾降低檢索速度時，你會選擇多索引分區還是兩階段檢索？理由為何？

2. 在 RAG SaaS 環境下，客戶要求「被遺忘權」時，你會如何設計備份數據刪除策略，既合法又安全？

3. 如何利用 ABAC/PBAC 策略引擎，管理跨部門、跨機密等級的文件權限，同時保證檢索效率？

4. 在防止 Prompt Injection / Data Exfiltration 時，你會設計哪些檢查與隔離策略？