📚 课程目录第2章基础概念

密钥管理、权限模型与审计日志：打好地基

这一章，咱们聊聊三个最基础但也最核心的概念。基础不牢，地动山摇。我在很多项目里看到过，就是因为这几个概念理不清楚，后面整个 SDK 架构就歪了。今天一次捋顺它。

对称密钥与非对称密钥：一把锁 Vs. 两把锁

密钥管理说白了，就是管好你的锁和钥匙。常见的就那么两种：对称密钥和非对称密钥。

对称密钥

特点：加密和解密用同一把密钥。
你想想看，就像你家大门钥匙。你用它锁门，也用同一把开门。谁拿这把钥匙谁就能开门。AES 是业界主流。我个人习惯在敏感数据加密场景，比如加密数据库里的用户手机号，就用 AES-256。

个人技巧：我在项目中遇到过，很多人图省事直接用对称密钥加密通信。这有风险。密钥一旦泄露，所有历史数据都能被解密。所以对称密钥一般用在本地加密，或者配合非对称密钥使用。

// 对称加密（AES）示例代码片段
// 注意：实际生产环境不要硬编码密钥
const crypto = require('crypto');
const algorithm = 'aes-256-cbc';
const key = crypto.randomBytes(32); // 256位密钥
const iv = crypto.randomBytes(16);   // 初始化向量

function encrypt(text) {
  let cipher = crypto.createCipheriv(algorithm, key, iv);
  let encrypted = cipher.update(text, 'utf8', 'hex');
  encrypted += cipher.final('hex');
  return encrypted;
}

避坑指南：我曾经见过一个项目，把 AES 密钥直接写在代码配置文件里，还上传到了 Git 仓库。那个项目后来重写了整个密钥管理系统。切记：密钥和代码必须分开存储，轮换机制必须到位。

非对称密钥

特点：公钥加密，私钥解密；或者私钥签名，公钥验签。
说白了就是两把钥匙。一把公开发，一把自己藏。RSA 和 ECC 是主流。我推荐新项目优先用 ECC（比如 secp256k1 或 P-256），同等安全强度下，密钥长度短、性能好。

我在做 SDK 签名验证的时候，就常用 RSA-2048。为什么？因为很多老旧系统对 ECC 支持不太好，RSA 兼容性更强。你看，这就是经验。

类型	算法举例	密钥长度	主要用途	性能
对称	AES, SM4	128 / 256 bit	数据加密	极快
非对称	RSA, ECC, SM2	2048+ bit / 256 bit	密钥交换、数字签名	较慢

所以实际架构里，咱们经常混合使用。用非对称做密钥协商，用对称做后续数据传输加密。既安全又高效。这就是经典的“混合加密方案”。

权限模型：RBAC 与 ABAC

讲完密钥，咱们看看权限。你给 SDK 定义了密钥，但谁能用这个密钥？用它能做什么？这就是权限模型的事。

RBAC（基于角色的访问控制）

核心思想：用户 -> 角色 -> 权限。
简单直接。用户是什么角色，就有什么权限。比如管理员、操作员、审计员。我建议绝大多数中小型项目，直接用 RBAC。原因？清晰、好理解、运维成本低。

我在项目中遇到的问题：有个客户非要在一片小草地上搞精细权限，结果 RBAC 的角色数量从 10 个膨胀到 50 个，管理起来一团乱麻。后来我帮他们切回了 ABAC 才解决问题。所以 RBAC 适合“用户角色稳定，权限粒度适中”的场景。

ABAC（基于属性的访问控制）

核心思想：根据实体（用户、资源、环境）的属性动态判断。
比如：“允许 main 分支的提交者，在 9:00-18:00 之间，从内网 IP，对生产环境的数据库执行只读操作”。你看，这是 RBAC 做不到的。ABAC 灵活，但也复杂。它需要一套属性引擎和策略语言（比如 XACML 或阿里 OPA 的 Rego）。

// ABAC 策略示例（伪代码）
// 允许的行为：
// 用户 角色 == "开发人员" AND
// 环境 == "预发布" AND
// 时间 >= "09:00" AND 时间 <= "18:00" AND
// 操作 == "读取" AND
// IP 以 "10.0." 开头
// 返回 true

核心对比：
RBAC： 简单、静态、适合角色分明的组织。
ABAC： 灵活、动态、适合需要细粒度控制的场景（比如云原生、微服务）。
我个人的选择思路： 先做 RBAC 能用则用，逼不得已再用 ABAC。别一上来就杀鸡用牛刀。

审计日志：你为什么需要一张“行车记录仪”

最后聊聊审计日志。密钥管理做得好，权限模型建得对，但谁来证明你说到做到了？谁保证没人动过手脚？

审计日志的核心：记录“谁、在什么时间、从哪、干了什么、结果如何”。 而且这些记录必须防篡改、防删除、可追溯。

我记得有一次安全攻防演练： 攻击者拿到了一个低权限的，试图越权访问数据。因为我们 SDK 的权限模型拒绝了它，审计日志完整记录了这次“越权尝试——来源 IP、时间、失败的资源路径”。事后追踪时，这一条日志就是铁证。没有日志，你甚至不知道漏洞在哪儿。

审计日志的三个关键点：

不可抵赖性： 每条日志必须有时间戳（最好是 NTP 同步的）和数字签名。我建议用 HMAC 或 RSA 对日志摘要进行签名，保证日志一旦写入，就不能被篡改。
防丢失： 日志系统要有一定的缓存和重试机制，不能因为日志写入失败就阻塞核心业务。异步写入是常规做法。
可扫描： 日志结构要清晰。我用得比较多的是结构化日志（JSON 格式），字段名规范，方便后期做搜索和统计分析。

现实里的坑： 我曾经接手过一个老系统，审计日志全写在文本文件里，没有签名，没有时间戳。结果一次数据泄露事件中，日志被内鬼删除了一部分。最后根本没法确定到底泄露了什么。那个教训告诉我：没有防篡改的审计日志，等于没有日志。

好，我们来看一张图。这张图把密钥管理、权限模型和审计日志三者串起来了，这就是咱们这个课程后续要实现的 SDK 核心逻辑图。你一眼就能看清数据流转和它们之间的关系。

嗯，这张图就是我们后续所有章节的地图。你看，三个模块相互依赖又各自独立，最终汇聚到 SDK 核心。咱们接下来的章节，会把它一砖一瓦搭建起来。你现在理解了这些概念，后面代码实现就会清晰很多。