有些系统的残酷之处在于：发布之后，修改成本极高。
它可能运行在大量客户端里，可能依赖第三方集成，可能承载关键业务流程，也可能因为合规、审计或部署环境限制，不能像普通 Web 服务那样随手热修。
这种系统的安全策略不能建立在”先上线，出问题再补”上。你需要把更多工作前置到设计、评审、测试和验证阶段。
先定义不可变边界
不是所有东西都应该不可变。
真正值得固定下来的，通常是那些一旦改变就会影响信任关系的部分：
- 数据格式和版本兼容规则。
- 权限模型和关键操作路径。
- 状态迁移规则。
- 外部接口的语义承诺。
- 审计日志和证据链。
反过来，容易变化的策略、阈值、展示逻辑和实验功能，应该留出可配置空间。不可变不是逞强，而是把系统里最核心的承诺稳定下来。
最小权限不是口号
权限问题最常见，也最无聊。但安全事故往往就喜欢从无聊的地方钻出来。
最小权限至少要落到三个层面：
- 调用权限：谁能触发关键动作。
- 数据权限：谁能读取或修改敏感数据。
- 运维权限：谁能发布、回滚、改配置、看密钥。
只在代码里写一个管理员判断是不够的。真正可靠的权限体系需要配合审计日志、双人复核、权限过期、环境隔离和紧急开关。
如果一个权限拿到之后永不过期，它迟早会变成系统里的长期债务。
状态更新要防重入和重复执行
很多安全问题本质上不是”黑客魔法”，而是状态更新顺序不严谨。
一个典型原则是：先验证，后更新内部状态，最后调用外部依赖。
外部依赖包括数据库外的服务、消息队列、第三方 API、插件系统，甚至同进程里的回调。只要外部逻辑能反过来影响当前流程，就要考虑重入、重复执行和部分失败。
工程上的防御方式包括：
- 幂等键。
- 状态机约束。
- 乐观锁或版本号。
- 请求去重表。
- 超时和补偿任务。
- 明确的事务边界。
很多事故不是因为没有高级算法，而是因为”扣减成功、通知失败、重试又扣一次”这种朴素问题没有处理好。
升级能力本身也是攻击面
不可变系统经常会保留某种升级能力，比如插件、规则引擎、配置中心、远程策略或灰度开关。
这不是坏事。问题在于：升级通道本身也必须被当成高危入口。
需要重点检查：
- 谁能提交升级。
- 谁能审批升级。
- 升级包是否可验证。
- 失败后如何回滚。
- 新旧版本的数据结构是否兼容。
- 用户或调用方能否感知语义变化。
很多系统表面上很安全，最后出问题的却是”临时开放的配置入口”。临时方案如果没有过期机制，就会慢慢长成永久漏洞。
测试要覆盖恶意路径
普通功能测试验证的是”用户按预期使用时能不能跑通”。
安全测试还要问另一组问题：
- 用户重复提交会怎样？
- 请求顺序被打乱会怎样？
- 外部服务卡住会怎样？
- 权限刚被撤销时还有没有缓存窗口？
- 输入字段极大、极小、为空、重复、乱序时会怎样？
- 日志里会不会泄露敏感信息？
这些不是偏执，而是对真实环境的基本尊重。
最后
不可变系统的安全工程，核心是把”修”的压力变成”证”的能力。
你越难在事后改，就越要在事前证明它足够简单、边界清楚、权限收敛、状态可追踪、失败可恢复。
安全不是某个 checklist 的最后一项，而是设计从第一天就要付的成本。越晚付，利息越高。