预发布环境不是生产环境：给它独立的访问边界

预发布环境看起来像测试系统，直到你注意到它里面放着复制的生产数据库、仍然有效的邮件凭据和支付密钥。到了那一刻，标签上的名字已经不重要，真正的问题是这次部署能触达什么、谁又能触达它。前门的一层 VPN 回答不了这个问题，因为它只约束进入系统的一条路径，而对系统出去时能做什么一无所知。请从受众出发，再向外展开。

从受众出发，而不是从 URL 出发

三类受众对应三种不同的设计。私有工程环境需要身份和通路；客户验收测试需要能代表客户的账号；公开演示需要刻意的暴露和配套的控制。先把受众写下来，可以避免预览 URL 悄悄变成永久地址这种常见的漂移。评审中其余的一切都取决于这个答案。

如果没人说得出受众是谁，这应当算作第一个发现，而不是文档缺口。

走过前门，也看清它背后的各个面

先解析域名，再相信别人给你的 URL，然后直接索要管理路径。

dig +short staging.example.com
curl -sS -o /dev/null -w "%{http_code}\n" https://staging.example.com/
curl -sS -o /dev/null -w "%{http_code}\n" https://staging.example.com/admin

额外的解析记录常常暴露一个绕过 CDN 或 VPN 入口的直连源站地址，这会让原本设想的控制变成可选项。重定向会告诉你应用认为自己住在哪里，而意外的协议或主机名值得追查。探测一个可能存在的管理路由，得到的应该是拒绝而不是页面。未认证的管理路径返回 200，正是整场评审要找的那个发现。

检查环境能做什么，而不只是它展示了什么

需要登录的页面同样带着后端权限上线。要问工作负载以哪个身份运行，然后读它绑定的策略。

aws sts get-caller-identity

那次调用会报告环境实际使用的账号和主体，而这就是之后每一个权限问题的起点。从这里出发，检查该身份能否发邮件、动钱、读生产密钥或写生产数据。把共用的生产凭据换成权限受限的预发布身份，并在有供应商沙箱时优先使用。一个能刷真实卡片的测试账号，就是一台换了主机名的生产系统。

评审结束后仍要维持边界

环境不是靠一次审计保住的，而是靠能扛住人员变动的归属关系。指定谁负责回收权限、重置测试数据、让部署退役，并给预览设一个必须有人续期的到期时间。隔离只在被隔离的东西仍被维护时才有效。下一次发布后重新检查同样的路径，因为一个功能开关或一次新集成，正是被拒绝的路由变成敞开大门的典型方式。

用一个被允许的流程和一个被拒绝的流程来验收这套设计。两者都按文档表现，边界才存在；只测了顺利路径，那只是希望。