📚 课程目录第1章零信任安全模型概述

零信任安全模型概述：从边界防御到永不信任

咱们先聊聊一个老问题：为什么传统的安全模型不管用了？

你想想看，传统的“城堡和护城河”模型——公司内网是个大城堡，防火墙是护城河，外面都是坏人，里面都是好人。这个思路在过去二十年里还挺好用。但到了云原生时代，办公地点分散了，移动设备泛滥了，SaaS应用满天飞。护城河还在，可城堡里早就是人山人海了。

我记得2019年帮一家金融公司做安全架构评估。他们自认为安全做得不错，防火墙策略写了几百条，VPN也强制要求了。结果事后发现，一个内部员工的凭证被钓鱼，攻击者从内网横向移动，把整个数据库翻了个底朝天。那个项目让我彻底明白了一件事：信任内部网络，就是个定时炸弹。

零信任的核心思想：不再假设“内网就是安全的”，而是默认任何请求——无论来自哪里——都是不可信的。

说白了，传统安全模型基于“位置”。你在公司局域网里，我就信任你。你在外面，我才怀疑你。零信任把底层逻辑彻底翻转了：信任依据从“位置”变成了“身份 + 上下文”。

我做了个对比表格，方便你看清区别：

嗯，这里要注意：不是说你内网就全是坏人。而是你没法区分谁是好人谁是坏人。与其猜，不如不信任。

这三大原则是骨架，后面的所有实现都围绕它们展开。

每个访问请求都必须经过身份验证、授权评估和加密通道。没有例外。哪怕这个请求来自CEO的办公电脑，也一样要查一遍。

我见过不少项目说“我们实现了零信任”，但实际写策略时偷偷给内网IP段加了豁免规则。避坑指南来了：豁免规则就是零信任的掘墓人。一个例外，整个模型就回到了传统思路。

⚠ 注意：所谓“始终验证”，不是让你每次访问都输密码，而是基于、设备证书、行为分析做持续评估。用户体验和安全，可以兼顾。

每次访问只给最少、够用、临时的权限。不是“你有工程师角色所以可以访问所有微服务”，而是“你这次调试只允许访问order-service的GET /orders接口，并且两小时后自动过期”。

我个人习惯用Just-In-Time（JIT）策略来管理权限。举个例子：

# 模拟一个JIT权限申请
权限申请：
  - 申请人：zhang.san
  - 资源：prod-db.host:3306
  - 操作：SELECT
  - 时限：30分钟  # 超时自动回收
  - 理由：排查线上订单数据异常

权限不是越少越好，是“刚够”最好。多一分是风险，少一分是妨碍。

这个原则有点反直觉。你得问自己：假如攻击者已经在我内网里了，我能怎么办？

基于这个假设设计的架构，天然具备防御纵深。加密传输（防止窃听）、微隔离（防止横向移动）、持续日志审计（方便追踪）、短期凭证（减少凭证泄露面）……都是从这个原则推导出来的。

我曾经在一个医疗项目中踩过坑：当时没做微隔离，以为防火墙就够了。结果一个IoT设备的漏洞被利用，攻击者轻松从IoT子网跑到医疗数据区。后来重建时，我们把所有服务之间的流量都强制走mTLS加密，并且每30分钟轮换一次证书。从那以后，不管哪个设备出了问题，损失都限制在那一小块。

光有原则不够，落地需要框架。目前业界主流是NIST SP 800-207里定义的那一套。我把它梳理成了五层：

这五层不是同步推进的。我建议优先做身份层和应用层，因为这两个回报最快，而且技术路线成熟。

💡 小贴士：零信任落地最怕“大而全”的设计。从最痛的一个业务入手，比如把内部的Admin系统先改造，验证流程再铺开。

好，到这里，零信任的概念、原则和框架都讲完了。下面我专门画一张图，把这些关系串起来——方便你对照着理解。

图里你可以看到：三大原则是上方的大脑，五层框架是下方的骨架。箭头的意思不是流程先后，而是原则指导框架设计。比如“假设已泄露”决定了网络层要做微隔离和全加密，“最小权限”决定了应用层的API级策略。

这一章是零信任的总览。后面的课程，我们会深入每个原则的实现细节——从身份认证、动态访问策略到Secrets管理的零信任实践。但今天先把全景图刻在脑子里，剩下的就是一步步填坑了。