2. 密钥边界概念：密码学边界与信任边界
搞安全的朋友都知道，密钥不能裸奔。但到底怎么界定“安全区域”？我早年在一个金融项目里，就因为边界划得太模糊，导致日志记录里密钥操作和普通请求混在一起，复盘时根本分不清谁碰过密钥。说白了，你得先搞明白两个核心边界：密码学边界和信任边界。
2.1 密码学边界
密码学边界，我习惯叫它“加密操作的黑盒壳”。所有密钥的生成、存储、加解密运算都必须在这个壳里完成。壳外面的人只能通过接口输入明文、输出密文，永远看不到钥匙本身。
举个例子，你用过 openssl 的 ENGINE 接口吧？调用 HSM 时，密钥句柄传到引擎层，但真实的 RSA 私钥只在 HSM 内部。这就是典型的密码学边界。
关键特征：边界内密钥不得以明文形式离开；边界外只能使用句柄或引用。
我在项目中遇到过最典型的翻车案例——有人把密码学边界设到了应用进程的堆内存里，美其名曰“软 HSM”。结果一个 core dump 就把私钥全泄了。记住：凡是不在硬件安全模块（HSM/TEE）里的密钥操作，都不算真正的密码学边界。
2.2 信任边界
信任边界比密码学边界大一圈。它定义的是“谁可以接触密钥生命周期中的哪些环节”。比如在云环境里，你信任 KMS 服务吗？信任底层虚拟化层吗？这就是信任边界的决策。
我曾经帮一家创业公司做审计整改，他们把所有服务器都划在同一个信任边界里。结果开发人员能 SSH 到密钥生成结点，虽然没直接拿到明文，但日志里能看到密钥版本和校验值——这已经越界了。
注意：信任边界通常比密码学边界脆弱。你信任的操作系统、容器运行时，甚至内部人员，都可能成为边界突破点。审计日志必须记录跨信任边界的每一次密钥访问。
我个人的经验：画信任边界时要问三个问题——谁有权调用密码学接口？调用时传输了什么凭证？调用结果（日志）是否暴露了密钥指纹？
2.3 两种边界的对比
| 维度 | 密码学边界 | 信任边界 |
|---|---|---|
| 核心目标 | 防止密钥明文泄露 | 防止未经授权的操作 |
| 典型载体 | HSM、TEE、安全芯片 | IAM 角色、网络隔离、审计策略 |
| 控制粒度 | 密钥生命周期（生成→销毁） | 调用者身份+操作类型 |
| 日志关注点 | 密钥句柄的创建/使用/注销 | 哪个主体在什么时段跨过了边界 |
| 常见突破方式 | 物理攻击、侧信道 | 配置错误、凭证泄露、内部威胁 |
设计审计方案时，我建议把密码学边界内的日志设为最高优先级——因为这里每一条记录都可能对应真正的密钥操作。信任边界的日志可以用来做异常行为分析，比如一个服务账号突然在凌晨调用了密钥导出接口。
2.4 边界交叉与审计日志
现实系统不是单层边界。你会遇到这样的架构：底层有 HSM（密码学边界），中层有 KMS 服务（信任边界），上层应用只见过加密后的密钥。
我画了一张全景图，你看看就清楚了：
看到了吗？信任边界包裹了服务层和应用层，密码学边界只锁在硬件层。两者的审计日志必须分开存储并做关联分析。我习惯在采集点①记录调用者IP、时间戳、操作类型；在采集点②记录密钥ID（句柄）、算法模式、返回状态。这样一旦发现异常，我能快速定位是越界调用还是硬件内部故障。
注意：不要把信任边界的日志级别设得和密码学边界一样高。我见过有人把所有密钥操作日志打到同一个索引里，结果每天几亿条，想查一个违规调用要扫描三天。建议分开索引，且密码学边界的日志保留周期更长。
最后分享一个我踩过的坑：
有一次我们设计了一个密钥分发系统，前端应用通过REST API向密钥管理服务请求加密密钥。我们把密码学边界划在密钥管理服务内部，信任边界划到了整个集群。结果运维人员因为误操作在管理平面执行了key_migrate命令，把密钥材料直接暴露到了日志里。事后复盘发现，审计日志里虽然记录了迁移操作，但日志本身没有标记“跨边界”——导致告警规则没触发。
从那以后，我要求每个密钥日志条目必须带三个字段：boundary_type（密码学/信任）、cross_boundary（true/false）、edge_id（边界标识符）。嗯，小改动，大作用。
下一阶段你可能会问：边界怎么映射到实际的系统模块？别急，先消化掉这里的两层概念——密码学边界管密钥安全，信任边界管人机授权。后面的章节会给你一套完整的关联设计模板。