第1章 零信任安全模型概述与核心原则
1.1 为什么传统安全边界守不住了？
先聊聊大家最熟悉的「城堡+护城河」模型。
过去，公司网络就是一座城堡。防火墙是护城河，VPN是吊桥。员工在城堡里办公，默认就是安全的。这套模式用了二十年，没什么大毛病。但今天，你想想看，API直接暴露给第三方、员工拿着笔记本在咖啡馆办公、数据散落在SaaS和云端——边界在哪？早就没了。
我记得有一次参与一家电商公司的渗透测试。他们的核心订单API只对内网开放，但某个合作方的系统被打穿后，攻击者直接从合作方内网跳到了订单API。这就是典型的「边界信任」陷阱：一旦防线失守，内网畅通无阻。
说白了，传统模型的核心问题是——它在墙内默认信任一切。而现实是，攻击者可能已经在你墙内了。
1.2 零信任到底是什么？
零信任不是一款产品，也不是一个防火墙策略。它是一种安全思维模式的转变。
NIST SP 800-207 给出了标准定义：零信任是一种安全模型，它取消了对网络位置的隐式信任，要求对每个访问请求都进行显式验证。
用我的话翻译一下：别管请求来自内网还是外网，每个API调用、每条数据读取，都必须证明「你是谁」「你凭什么」「你在哪」「设备安不安全」。
这听起来很严格。但这就是零信任的底色——永不信任，始终验证。
1.3 三大核心原则
零信任的落地可以拆成三条原则。我在项目中见过太多团队只买了零信任产品，却没理解这三条，结果照样被攻破。
-
显式验证
不再因为IP在内网就放行。每个请求必须经过身份、设备、上下文的多维校验。我建议在API网关层强制每30分钟重新校验一次，而不是等JWT过期。 -
最小权限
只给恰好够用的权限，不多给一条记录、一个接口。我在项目中见过一个普通查询API，竟然能通过修改参数ID查到全库用户数据——这就是权限颗粒度太粗。RBAC在这里要细化到「谁+什么角色+什么资源+什么操作」四元组。 -
假设受损
默认网络已经被渗透、某个服务已经被控制。在这个假设下设计权限隔离和接口保护。我曾经处理过一起内部威胁事件，一个实习生用同事留下的遍历了十几万条客户数据。如果当时有「假设受损」的意识，早该绑定设备指纹并限制调用频率。
1.4 零信任与传统安全模型对比
用一张表看清楚它们的区别：
| 对比维度 | 传统边界模型 | 零信任模型 |
|---|---|---|
| 信任依据 | 网络位置（内网=信任） | 身份+设备+上下文（动态评估） |
| 权限粒度 | 粗放（按网段/子网） | 精细（按身份+角色+资源+操作） |
| 访问控制 | 一次认证，长期有效 | 持续验证，令牌短生命周期 |
| 攻击响应 | 被动补丁，依赖边界防御 | 假设已受损，主动隔离 |
| API安全 | 依赖网络ACL和WAF | 基于策略的API级权限隔离 |
你想想看，如果你的API网关是按照零信任的权限模型来设计的，前面提到的内部滥用、合作方跳板攻击，基本都能被挡在门外。
1.5 零信任如何重塑API安全
API是现代应用的「毛细血管」。但API安全有个天然痛点：它不像浏览器有统一的安全沙箱，每个API直接暴露数据和服务。传统的做法是依赖API网关做简单鉴权，但一旦泄露，基本不设防。
零信任给出了三条解决路径：
- API级最小权限：每个接口只暴露必要的schema和字段，不返回多余数据。
- 动态上下文旅游：每次API调用都评估设备指纹、行为画像、请求频率，异常直接阻断。
- 权限隔离：不同角色看到的API资源和数据完全隔离，通过RBAC在API网关层做策略执行。
我个人习惯把零信任的三个原则简化为一个思考框架：每个API调用都是一次「无信任」的交易，需要重新验证身份、权限和环境。在后面的章节里，我们会沿着这个框架，一步步把RBAC和权限隔离落到真实的接口上。