安全與權限 · 實作指南
公司資料隔離，需要測試地圖而不只一欄公司編號
沿著查詢、檔案、背景工作與匯出，檢查公司之間的資料邊界。
清單正確不代表其他入口安全
假設某客戶平台的請求清單已按公司篩選，但附件下載只相信瀏覽器傳來的紀錄編號；畫面看來隔離，檔案入口卻未必。建議建立租戶測試地圖，列出資料可被讀取或修改的每條路徑：詳情、搜尋、匯出、預覽、背景工作、模型檢索和支援工具。每條路徑都要根據已登入身份作權限決定，不能只依靠前端隱藏按鈕或猜不到的編號。
讓資料庫成為第二道邊界
PostgreSQL 行級安全可限制資料列，但執行角色的設定同樣重要。建議先有應用程式授權，再按架構加入資料庫檢查；檢視執行角色是否能繞過政策，以及連線池如何設定公司脈絡。請求內的公司欄位不能自行成為授權依據。管理維護通道應分開，記錄使用目的，不要為了方便而讓一般背景工作也使用擁有者或超級使用者權限。
流程一覽
建立容易混淆的測試資料
準備兩家虛構公司，故意使用相似文件名稱和重疊員工姓名。只獲其中一家公司授權的人，逐一嘗試地圖中的入口，再測試同時屬於兩家公司的員工切換脈絡。快取結果、舊背景任務內容和支援人員查詢也要涵蓋。過於不同的測試資料容易掩蓋假設；相似資料反而能檢驗系統是否真正依權限而不是憑名稱作分隔。
保留證據，也承認邊界
把應允許或拒絕的結果寫進測試，權限或儲存方式改動後再執行。API 已拒絕仍不足夠，若舊下載連結仍可使用，就要繼續追查。相關路徑出現隔離失敗應阻止發布。這種檢查並不讓共用基礎設施等同專用部署；維運存取、備份和支援程序仍需要按客戶要求另行約定，不能用通過幾項測試來承諾完全隔離。
追蹤權限變化
測試地圖應與授權政策一起維護；新增角色、快取或匯出時，確認是否多出新的資料路徑。否則功能團隊可能不知道自己需要租戶測試。每條路徑指定負責人和發布檢查，避免依靠某位安全專家的記憶。也要列出刻意由管理員跨公司操作的例外，要求有目的和紀錄，讓正常例外不會變成無人察覺的全面存取。
來源與延伸閱讀
- Row Security PoliciesRow Security PoliciesPostgreSQL · 官方文件 ·
- Authorization Cheat SheetAuthorization Cheat SheetOWASP · 官方文件 ·
編輯原則
本系列以 AI 輔助原創撰寫，並對照連結的公開來源。實作建議與假設情境屬編輯分析，並非客戶實績。來源發布日期及產品細節可能與本系列整理日期不同。