安全是对资产与威胁的约束

软件安全经常被缩写成登录、加密或权限表，但架构首先要回答的是：系统保护什么，谁可能以什么方式破坏它，系统允许承担多大损失。只有把资产、参与者和信任关系说清楚，认证、授权、审计等机制才有明确目标。

从资产和损害开始

资产不只是数据库中的记录。账号控制权、服务连续性、配置密钥、操作日志和组织信誉都可能需要保护。同一种数据还可能具有不同安全目标：公开文章主要要求完整性，未发布稿件同时要求保密性，账户恢复信息则对保密性和不可滥用性有更高要求。

安全分析应描述资产受损后的业务后果，而不是笼统地写成“防止攻击”。例如，编辑权限被冒用可能导致错误内容发布；审计记录被修改会使责任追踪失效；接口被大量调用则会消耗容量并影响合法用户。后果决定投入顺序。

威胁不是一张固定漏洞清单。相同入口面对匿名访客、登录用户、后台管理员或内部服务时，攻击面并不相同。需要说明威胁主体具有什么能力、从哪里接近系统、希望获得什么，以及已有控制措施在哪里生效。

边界处最容易出现假设不一致。浏览器与服务端之间、服务与数据库之间、系统与第三方接口之间都存在信任转换。来自上游的数据即使已经认证，也不等于适合直接执行、展示或写入。每次跨越边界，都应重新校验身份、权限、格式和用途。

认证说明调用者是谁，授权说明这个身份此刻能做什么。一个有效令牌不能代替资源级权限判断。对于内容平台，还要区分查看、创建、修改、审核、发布和删除，避免用单一“管理员”身份覆盖所有高风险动作。

授权规则应落在可信的服务端，并与对象状态结合。草稿是否可见、已发布内容是否允许直接覆盖、操作者能否访问某个租户，都不能依赖前端隐藏按钮。最小权限原则的实际含义，是每个身份只持有完成当前职责所需的能力和时间范围。

“系统是安全的”不能直接测试。可验证的要求应写成场景：某类调用者在特定入口尝试某个动作，系统如何拒绝、记录，并在多长时间内触发告警。OWASP ASVS 将应用安全要求组织为可检查的控制项，适合用来补足认证、会话、访问控制、验证和日志方面的遗漏。

测试还要覆盖失败路径，包括过期凭据、越权资源标识、重复请求、异常输入和依赖服务不可用。日志应能还原关键动作，但不能反过来泄露口令、令牌或敏感正文。安全控制若无法被稳定观察和回归验证，长期维护中很容易悄然失效。

威胁会随功能、部署和依赖变化。新增导入接口可能扩大输入面，接入对象存储会产生新的凭据与访问策略，缓存也可能绕开原有对象授权。架构评审因此需要追踪信任边界和数据流的变化，而不是只在上线前做一次检查。

安全设计的成果应包括明确的资产清单、威胁假设、授权规则、控制位置和验证证据。它们共同限制系统可以接受的行为，并为事故响应提供可追踪的依据。

Carnegie Mellon University Software Engineering Institute：Reasoning About Software Quality Attributes，https://www.sei.cmu.edu/library/reasoning-about-software-quality-attributes/
OWASP Foundation：Application Security Verification Standard，https://owasp.org/www-project-application-security-verification-standard/