overview

P2（数据 & 风险）
├── 数据脱敏平台
├── 安全平台（风控 / 入侵检测）
├── 访问风控 / 风险引擎

P3（零信任 & 密钥）
├── Zero Trust 平台
├── HSM / KMS
├── Secrets 管理

零信任

那我们就换个话题，继续这么随便聊。不讲密码学原理，也不拆标准，就当是在聊一个平时很少被注意，但一出问题就特别致命的东西——HSM / KMS。

大多数系统一开始，对“密钥”这件事都挺随意的。

配置文件里放一个，环境变量里塞一个，能跑就行。反正也没人天天盯着看。

直到有一天，你被问了一句：

“这个密钥，是怎么保护的？”

你突然不知道该怎么回答。

KMS 通常就是在这个时候被引入的。

不是因为你想做得多规范，而是你发现： 密钥已经成了系统里最脆弱的一环。

代码可以审，权限可以控，日志可以查，但密钥一旦泄露，前面这些基本都没意义。

你平时跟管家打交道，真正的钥匙，锁在保险柜里。

KMS 更多解决的是“怎么用”。

这些事如果靠人记，迟早会出问题。

而 HSM 解决的是 “你根本拿不到钥匙本身”。

密钥生成在里面，使用也在里面，就算你把系统翻个底朝天，也看不到原始密钥。

这层“物理隔离”，在某些场景下是非常值钱的。

我见过一些系统， KMS 做得很漂亮，权限、审计都齐全。

但密钥最终还是以明文形式落在应用内存里。

从安全角度看，这其实是一个很尴尬的状态。

当然，不是所有系统都真的需要 HSM。

大多数业务， KMS 已经能解决 80% 的问题。

HSM 通常是在你被明确要求 “必须这样做”的时候才会出现。

比如金融、支付、证书、根 CA。

还有一个容易被忽略的点。

HSM / KMS 其实是在替团队扛责任。

当你能说清楚：

很多问题就不用靠“相信大家不会犯错” 来支撑。

HSM / KMS 最像的是 公司印章。

你不是不能用，但一定要有流程；你不是拿不走，而是根本拿不到。