安全与权限 · 实作指南
公司资料隔离，需要测试地图而不只一栏公司编号
沿着查询、档案、背景工作与汇出，检查公司之间的资料边界。
清单正确不代表其他入口安全
假设某客户平台的请求清单已按公司筛选，但附件下载只相信浏览器传来的纪录编号；画面看来隔离，档案入口却未必。建议建立租户测试地图，列出资料可被读取或修改的每条路径：详情、搜寻、汇出、预览、背景工作、模型检索和支援工具。每条路径都要根据已登入身份作权限决定，不能只依靠前端隐藏按钮或猜不到的编号。
让资料库成为第二道边界
PostgreSQL 行级安全可限制资料列，但执行角色的设定同样重要。建议先有应用程式授权，再按架构加入资料库检查；检视执行角色是否能绕过政策，以及连线池如何设定公司脉络。请求内的公司栏位不能自行成为授权依据。管理维护通道应分开，记录使用目的，不要为了方便而让一般背景工作也使用拥有者或超级使用者权限。
流程一览
建立容易混淆的测试资料
准备两家虚构公司，故意使用相似文件名称和重叠员工姓名。只获其中一家公司授权的人，逐一尝试地图中的入口，再测试同时属於两家公司的员工切换脉络。快取结果、旧背景任务内容和支援人员查询也要涵盖。过於不同的测试资料容易掩盖假设；相似资料反而能检验系统是否真正依权限而不是凭名称作分隔。
保留证据，也承认边界
把应允许或拒绝的结果写进测试，权限或储存方式改动後再执行。API 已拒绝仍不足够，若旧下载连结仍可使用，就要继续追查。相关路径出现隔离失败应阻止发布。这种检查并不让共用基础设施等同专用部署；维运存取、备份和支援程序仍需要按客户要求另行约定，不能用通过几项测试来承诺完全隔离。
追踪权限变化
测试地图应与授权政策一起维护；新增角色、快取或汇出时，确认是否多出新的资料路径。否则功能团队可能不知道自己需要租户测试。每条路径指定负责人和发布检查，避免依靠某位安全专家的记忆。也要列出刻意由管理员跨公司操作的例外，要求有目的和纪录，让正常例外不会变成无人察觉的全面存取。
来源与延伸阅读
- Row Security PoliciesRow Security PoliciesPostgreSQL · 官方文件 ·
- Authorization Cheat SheetAuthorization Cheat SheetOWASP · 官方文件 ·
编辑原则
本系列以 AI 辅助原创撰写，并对照连结的公开来源。实作建议与假设情境属编辑分析，并非客户实绩。来源发布日期及产品细节可能与本系列整理日期不同。