第2章：基础概念——密钥管理、访问控制与审计日志

好，咱们进入正题。做密钥权限审计SDK改造，光有热情不够。

得先把地基打牢。我见过不少团队，上来就写代码，结果连密钥怎么存储的都没搞清楚。

项目做到一半，全推倒重来。浪费时间，还打击士气。

所以今天，我们用一节课的时间，把三个核心概念讲透。

说白了就是三大件：密钥管理、访问控制、审计日志。

这三样东西，就像餐馆的后厨、菜单和账本。

你想想看，后厨乱了（密钥泄露），菜单谁都能改（权限失控），账本没记全（审计缺失）——这餐馆早晚出事。

2.1 密钥管理——守护数字资产的看门人

密钥是什么？简单说，就是一把数字锁的钥匙。

它用来加密数据、签名请求、证明身份。

但麻烦的是，密钥本身也要被保护。千万别把密钥硬编码在代码里。

我在项目中遇到过一位老兄，直接把数据库密码写在配置文件中，还上传到GitHub公开仓库……

两天后，整个用户表被人拖走了。血的教训。

2.1.1 密钥的生命周期

一个好的密钥管理系统，要管理密钥从出生到死亡的全过程。

2.2 访问控制——谁可以动谁不可以动

密钥有了，密码有了，但不是谁都能用。

访问控制就是定义：谁能干什么。

嗯，这里要注意一个关键区别：认证（Authentication）和授权（Authorization）。

• 认证：你是谁？（比如：输入密码登录）
• 授权：你能做什么？（比如：只有管理员能删用户）

很多人把这两个混为一谈。你认证成功了，不代表你什么都能干。

2.2.1 主流的访问控制模型

咱们做SDK改造，最常见的是这几种：

1. 基于角色的访问控制（RBAC）
   • 用户 -> 角色 -> 权限
   • 举个例子：小张是“审计员”角色，这个角色只有“读取日志”权限。
   • 优点：管理简单。缺点：角色多了会爆炸。
2. 基于属性的访问控制（ABAC）
   • 根据用户属性、资源属性、环境条件来决策。
   • 比如：只允许上班时间（环境属性），从公司内网（环境属性）访问。
   • 优点：灵活。缺点：规则复杂，性能开销大。
3. 强制访问控制（MAC）
   • 系统层面控制，用户无法修改。
   • 多用在军方、政府系统。

2.3 审计日志——出了问题别想赖账

好，密钥和权限都配置好了。然后呢？

出了安全事件，你能追溯到谁、在什么时候、对哪个密钥做了什么操作吗？

审计日志就是干这个的。它记录所有与安全相关的事件。

说白了，就是一份不可抵赖的操作流水账。

2.3.1 审计日志要包含什么

一条合格的审计日志，至少要包含以下字段：

2.3.2 审计日志的三大守则

• 不可篡改：日志一旦写入，任何人不能修改或删除。常用做法：写入后哈希链式存储，存入只增数据库。
• 全量记录：不要筛选。你觉得无用的日志，可能是取证的关键。
• 实时与归档：既要能秒级查询近期的日志，也要能低成本保存全量历史日志（比如存到对象存储）。

2.4 三者如何协同工作

到这里，你可能会问：这三个东西，跟SDK改造有什么关系？

我画一张图，你看完就明白了。

现在清楚了吧？

• 用户/服务要访问某个密钥或资源。
• 首先经过访问控制这关。你是谁？你被授权了吗？
• 通过后，密钥管理提供密钥给用户使用。
• 这整个过程——谁在什么时候申请了哪个密钥——全部被审计日志记录下来。

你想想看，这三个环节缺一个会怎样？

• 缺密钥管理：密钥泄露了，根本不知道。
• 缺访问控制：所有人都可以随意调用核心密钥。
• 缺审计日志：出了事故，连谁干的都查不到。