荫云共享数据库怎样验隔离？PostgreSQL行级安全与角色交付的采购门槛

把多个客户的数据放进荫云候选服务器上的同一套PostgreSQL，实例费可能更好分摊，但新增CPU和内存不会补上漏写的租户条件。行级安全策略可以在数据库内约束普通查询，不过它是否生效取决于应用角色、策略组合和维护入口。采购共享数据库之前，应先证明一个租户通过真实应用连接无法读写另一个租户的数据，再测这层隔离带来的资源开销。

验收先使用应用账号，别让管理员替它通过

PostgreSQL官方文档说明，表启用行安全后，普通行访问需要策略允许；没有策略时使用默认拒绝。不过超级用户与带BYPASSRLS属性的角色总会绕过行安全，表所有者通常也会绕过。所有者可以通过FORCE ROW LEVEL SECURITY让自己受约束，但这不等于约束了超级用户。测试使用了哪一种身份，直接决定结果能否解释应用隔离。

因此，应把迁移建表账号、备份账号与日常应用账号分开核对。应用为了方便直接沿用建表者身份，会让一套看上去存在的策略失去预期保护。“已创建策略”不是通过标准；真实应用角色执行越界访问失败，才是可复核的起点。还要保存角色属性、表所有者与启用状态，防止环境重建后权限回到另一种配置。

业务若使用一个共享登录角色，再通过应用设置租户标识，就需要说明谁有权改变这个标识，以及数据库如何信任它。任意客户端能自己改写的会话值，不会因为被策略引用就自动变成可信身份。连接复用还要验证每次请求的身份初始化和清理，不能把前一个租户的状态留给下一个请求；具体做法需要结合应用认证与连接模式审核。

图中不同颜色物体分处两组空间，只表示租户边界的抽象关系，不是荫云控制台或隔离实测。边界应在真实连接中被验证，而非仅在架构图中出现。测试数据至少包含两个租户各自的已知记录与唯一标识，成功结果既要检查返回数量，也要逐条检查归属，避免“有数据返回”掩盖误读。

读得到哪些行，与允许写成什么行，要分别验

策略里的USING用于确定可见或可操作的现有行，WITH CHECK用于约束插入或更新后允许形成的新行。只测试查询隔离，不足以证明写入不能把数据转给另一个租户。官方CREATE POLICY文档对不同命令支持的表达式有具体定义，实施时应按SELECT、INSERT、UPDATE和DELETE分别核对，而不是把一条能通过的查询扩展成全部权限已经安全。

一个可执行用例是：以租户甲的实际角色读取甲的数据应成功，读取乙的已知标识应得不到该行；再尝试插入归属乙的新记录、把甲的现有记录改成乙、删除乙的已知记录。每次都核对持久结果与受影响行数，不能把应用统一返回的空对象当成数据库已经拒绝。修改测试只在隔离测试库里做，先准备可恢复数据。

表级权限与行策略也不是互相替代。账号没有SELECT权限时，策略允许某些行不会自动补给SELECT权限；有表权限也不代表可以跳过行策略。全表级操作还有边界：官方文档指出TRUNCATE和REFERENCES不受行安全限制。日常应用是否需要这些权限，应单独审计，不能用“查询已隔离”推断维护操作也隔离。

两条允许策略，默认可能扩大可见范围

多个适用的宽松策略默认按OR组合，限制性策略按AND组合。如果原来一条策略只允许本租户，又新增了一条面向同一角色、条件恒真的宽松查询策略，结果可能变成全部可见。策略名称看起来更严格，并不会改变组合语义。发布时应检查实际适用角色、命令类型以及所有策略的组合，而非只审查这次新增的一条。

应保留一组回归用例，在策略增加、角色继承调整和表迁移后重复执行。特别是后台报表为了方便获得更宽权限后，要确认它与公网应用使用不同凭据，凭据没有被打包进同一份部署配置。权限调整造成的越界读写无法靠更快的磁盘抵消，采购验收应把角色交付作为必要项。

把隔离查询带进容量测试

先在已经通过权限测试的配置上测业务查询，才有可用的采购结果。管理员绕过策略跑出来的响应时间，不能直接作为普通租户请求的容量。应保留实际执行计划、扫描行数、结果行数与响应期限，并覆盖小租户和大租户。数据明显倾斜时，一个平均租户的样本可能看不到最大客户的成本。

行策略若只依赖当前行的值，通常更容易理解和优化；若策略需要查询其他表或调用函数，官方文档提醒要考虑权限与并发竞争问题。选择更复杂的策略之前，应说明新增查询是否产生额外访问、索引是否匹配，以及并发变更授权记录时会出现什么结果。测一次空库请求很快，不能证明数据增长后仍能守住期限。

容量预算可以先写为：实例可承受的实际业务负载，应在启用最终权限与策略的状态下验收。把预期峰值请求持续回放，并同时执行正常后台维护，记录最慢一组租户是否超时。若瓶颈来自不匹配的查询或逐行重复访问，先比较查询与策略改写，再测试更大规格；若证据表明工作集和CPU确实不足，扩容才有明确目标。

小门与不同物体表示准入范围，不能用来量化数据库性能。资源与准入是两份条件：算力富余不证明权限正确，权限正确也不保证请求及时完成。部署记录需要同时保留越界用例结果和真实业务容量，避免安全测试与性能测试使用了两套不同账号和策略。

备份必须完整，恢复之后还得重新验证角色

官方文档专门提醒，备份时如果行策略静默滤掉数据，会产生严重缺失风险。row_security设为off并不是绕过策略，而是在查询结果将被策略过滤时抛错，方便发现问题。不能把这个参数的名字理解成“关闭所有隔离，备份自然完整”；应使用明确受控的备份身份，并核对恢复后的租户范围与记录数量。

恢复测试应在独立环境检查表结构、策略和角色关系，随后使用原先的甲乙租户用例重跑。一份备份能恢复数据，不代表部署人员已经恢复了相同角色属性；相反，简单地把应用改为管理员账号让系统先跑起来，会直接改变边界。故障应急预案要写清谁能使用越权凭据、何时撤回、如何审计，不能在实例采购中省略这项维护成本。

唯一约束、主键及外键的完整性检查会绕过行安全以维护数据完整性，错误反馈也可能暴露其他行存在与否。对高敏感多租户业务，应把错误信息和数据模型一起评估。行安全是一层数据库控制，不能替代应用认证、网络权限和运维人员的访问审计；若业务要求更强隔离，应比较分库或独立实例的管理代价与边界。

荫云只能作为候选，交付范围要先补齐

渠道通本轮实时返回荫云的云主机推广记录，但官方网站访问403，未取得当前CPU、内存、磁盘、价格、可用地区和退款细则。本篇不据采集描述推断托管数据库能力，也不把页面受阻解释成商家停服。配图全部是生成示意，不含真实控制台或未发生的测试结果。

适合共享部署的前提，是团队能够维护角色与策略、愿意承担共享故障影响，并且实测资源足以覆盖各租户高峰。若客户合同要求物理隔离、独立管理员边界，或没有人员负责策略回归，先比较独立实例方案。省下的实例费需要和角色管理、备份验证、审计及事故处置工时一起核算，不能只按用户数量平均分摊。

付款前向商家确认是否允许自建PostgreSQL和长期后台写入、共享CPU与磁盘限制怎样约定、快照是否具有应用一致性、能否导出完整备份，以及平台和客户分别承担什么恢复责任。通过荫云候选配置核对入口（推广链接）查看实际可售订单，本站可能获得推广收益，未核实的条款应先获得书面答复。

订单验收附上真实应用角色的读写矩阵、最终策略下的峰值请求结果，以及一次独立恢复后的复验记录。三份材料必须对应同一个配置；任一项缺失，就无法判断这次共享部署到底省下了成本，还是只把隔离责任留到了上线以后。

核验资料

PostgreSQL官方行安全策略
PostgreSQL官方访问策略命令