第3章：安全设计四大原则，项目里我是这么用的

安全设计原则不是挂在墙上的标语。我个人习惯把它们当成"代码审查清单"来用。每次评审架构，我都会拿这几条原则过一遍。你不是在写，你是在为系统植入"免疫力"。

这套原则我拆成四个维度来讲。你想想看，它们覆盖了权限、防御纵深、默认状态和隐私保护。每一个都踩过坑，也补过天。

3.1 最小权限原则：不仅适用于用户

我在项目中遇到过好几次：一个运维脚本为了省事，直接用了数据库的 root 账号。结果 SQL 注入一打，整个库被拖走。你说冤不冤？

最小权限的核心是：

• 按需分配：只给完成工作所需的最小权限
• 动态回收：权限用完立刻降级或收回
• 临时提升：需要高权限时，申请临时令牌，用完即焚

举个例子。我之前管一个支付系统，DBA 要查线上日志。我给他开了个只读账号，只给 SELECT 权限，连表结构都不让看。他很恼火，说"不方便"。我说，方便和安全从来都是 trade-off。后来有一次生产故障，有人直接删了一条关键记录。但那个只读账号根本删不了。你想想看，这时候方便还重要吗？

3.2 纵深防御：别指望单层防线

我记得有一次看一个团队设计的数据管道。他们把所有的安全信心都压在"内网隔离"上。我说，万一内网被突破了？他们沉默了。

纵深防御不是让你堆砌安全产品，而是让每一层都独立承担"万一前面失守"的责任。真正的分层是这样的：

1. 网络层：防火墙、VPC、网络 ACL。第一道门
2. 应用层：输入校验、认证授权、API 网关。业务逻辑把关
3. 数据层：加密存储、脱敏、审计日志。即使前面全失效，数据还是安全的

3.3 默认安全：让"安全"成为出厂设置

什么是默认安全？就是用户不做什么配置，系统也是安全的。说白了，不要让用户去"记得"开启安全选项。

我之前参与设计一个云存储服务。最初的设计是：默认允许所有公网 IP 访问，用户需要手动配置安全组来"缩小范围"。我说这个不对。后来我们改成：默认为私有网络，用户需要主动开启"公网访问"。

这个简单的改动，直接让客服的工单量下降了 40%——因为用户不会因为忘关端口被黑了。

默认安全的关键实践：

• 默认拒绝：所有 API 端点默认返回 403，只有显式声明了 @PermitAll 才开放
• 默认加密：传输层 TLS，存储层 AES-256，不需要用户勾选"启用加密"
• 默认最小日志：不记录敏感字段，用户需要主动选择"我需要记录更多"
• 默认无调试：生产环境默认关闭 debug 模式、堆栈信息

3.4 隐私设计：GDPR 不是唯一理由

隐私设计（Privacy by Design）最早是 90 年代提出的。很多人以为是为了过 GDPR 合规。其实它最核心的一条是"数据最小化"——你不该存的数据，干脆不要碰。

嗯，这里要注意。隐私设计不只是一个 checkbox。它要求你在数据流设计阶段就问：

• 我真的需要用户的真实手机号吗？还是只存一个哈希就够了？
• 日志里能不能不要记录完整的身份证号？
• 用户想要注销的时候，我能不能在一小时内彻底删除所有关联数据？

我曾在项目里遇到一个经典场景：产品经理要求记录用户的所有浏览历史，说是"为了推荐算法"。我说可以，但要求在数据管道里做三层处理：

1. 脱敏：入库时去掉用户 ID，换成内部标识
2. 聚合：分析层只给聚合后的行为标签，不给原始日志
3. 定时清理：超过 30 天的原始数据自动删除

产品经理一开始觉得"太麻烦"。但后来有一次数据泄露事件，隔壁团队因为没有做脱敏，被罚了 200 万欧元。这时候他就感谢我了。

3.5 四个原则的协同效应

这四个原则不是独立的。你仔细看会发现：

• 最小权限 和 纵深防御 一起用，能让攻击者即便拿到了一个权限，也无法横向移动
• 默认安全 和 隐私设计 共同保证了系统"从盒子里拿出来就是安全的"
• 纵深防御 为 默认安全 提供了一个兜底层

我经常把这张图贴在团队的白板上。每次讨论架构，大家先过一遍这四条。有不匹配的地方，立刻停下来讨论。久而久之，这就变成了团队的"安全直觉"。