資料庫層：行級安全性政策
行級安全性（Row-Level Security, RLS）是資料隔離的基礎。PostgreSQL 的 RLS 讓你在資料庫層面設定政策，使得即使應用層出錯，資料仍被保護。每條記錄都被政策檢查，租戶 A 的使用者無法看到租戶 B 的資料，即使他們繞過了應用層的檢查。
RLS 的核心是租戶政策。在每個表上定義政策，檢查目前使用者或目前租戶的識別是否與記錄的租戶 ID 相符。這是最後一張保險單：不管應用程式有多複雜，資料庫層永遠會拒絕非法查詢。
- 在敏感表上啟用 RLS，例如訂單、客戶、報表
- 為每個角色定義明確的政策：組織管理員、員工、客戶、訪客各自有不同的檢查條件
- 政策的檢查條件寧可保守也不要寬鬆。遺漏一個條件等於一個資料洞
- 定期審計 RLS 政策，資料庫層的疏漏很難從應用層看出
應用層：自動化的租戶過濾
應用層的職責是確保每個查詢都帶著租戶 ID。開發者最常犯的錯誤就是在某個查詢裡忘記加租戶條件，這個錯誤是致命的，可能洩漏整個資料庫的資訊。
解決方法是自動化。不要依靠開發者記住加租戶 ID；在 ORM 或查詢層面自動注入租戶過濾。例如，使用客製化的資料庫抽象層，讓所有查詢自動加上租戶條件。
Venture AI Agency 在實作多租戶儀表板時，就是在應用層面實現了租戶自動化過濾。所有資料查詢都透過一層封裝，租戶隔離發生在應用啟動時，而非靠個別開發者記住。
- 使用租戶感知的查詢層封裝，讓所有 ORM 查詢自動過濾
- 在中介軟體中設定目前使用者和目前租戶的上下文
- 程式碼審查時，檢查查詢是否都帶著租戶 ID
- 寫集成測試來驗證租戶隔離
API 層：端點級別的權限檢查與角色設計
即使資料庫和應用層都設置正確，API 層仍然需要明確的權限檢查。每個端點都應驗證：該使用者是否屬於該租戶？該使用者是否有權限存取這項資源？
權限設計通常採用角色型存取控制（RBAC）。定義清晰的角色階層：組織管理員擁有完全存取權、經理可以檢視和編輯部屬資料、員工只能檢視自己的資料、外部客戶只能檢視指派給他們的項目。
與資料隔離並行的是稽核日誌。記錄誰在什麼時間存取或修改了哪些資料。這不只是合規要求，也是找出隔離漏洞的關鍵。
- 在 API 中使用權限中介軟體檢查用戶身分和租戶成員身份
- 明確定義角色權限矩陣
- 使用 JWT 或會話令牌攜帶使用者身分和角色
- 稽核日誌應記錄所有資料存取和修改，包括失敗的嘗試
常見的隔離漏洞與風險
多租戶系統的安全性取決於層層防守。一層失守就可能導致資料洩露。常見的漏洞包括：查詢忘記租戶條件、API 端點沒有檢查權限、RLS 政策配置不完整、管理員工具允許跨租戶存取。
另一類風險來自資料遷移和備份。如果備份或資料匯出時忘記過濾租戶，可能洩漏整個資料庫。防止這些風險的方法是定期的隔離測試和權限審計。
- 查詢遺漏租戶條件——最常見的漏洞
- API 端點沒有檢查使用者是否屬於該租戶
- RLS 政策不完整或未啟用
- 管理介面允許管理員不受限制地存取任何租戶的資料