课程导学与加密基础
这门课到底讲什么
你可能正面临一个头疼的问题：本地散落着一堆加密库，AES 密钥写在配置文件里，RSA 私钥躺在服务器硬盘上。每次安全审计都心惊胆战。我之前接手过一个项目，所有加密逻辑都封装在一个老旧的 OpenSSL 库版本里，升级一次要改上百个接口。后来我们决定迁移到云 KMS，过程不太顺利，但踩过的坑让我攒了不少经验。
这门课就是帮你理清迁移思路。从加密基础开始，到 KMS 的选型、集成、密钥轮换、审计，再到灰度切换。我会把项目里真实踩过的坑、试过的方案都抖出来。你不需要是密码学专家，只要熟悉一点编程，跟着走就行。
学习路线
整个课程分三大部分：
- 基础篇（第1-5章）：夯实加密概念，对比本地库与 KMS 的差异。
- 实战篇（第6-20章）：手把手教你用云厂商 KMS SDK 替换本地加密调用，包括密钥创建、加密解密、签名验签、密钥轮换。
- 进阶篇（第21-30章）：性能调优、多区域容灾、合规审计、安全复盘。
每章我都会给出一段可跑通的代码，你拿过去改改就能用。说白了，学完就能动手。
加密学基础概念
做迁移前，你得先搞清楚这几个基本概念。别担心，我会用最直白的方式讲。
对称加密
同一个密钥，加密和解密用。速度快，适合加密大批量数据。我常用的有 AES-256-GCM。为什么用 GCM？因为它自带认证，能防篡改。
我见过最夸张的案例：有人把 AES 密钥直接硬编码在代码里，然后传到 GitHub 公开仓库。嗯，后果你懂的。
非对称加密
一对密钥：公钥公开，私钥保密。一般用来加密小数据（比如对称密钥），或者做数字签名。
常见的 RSA-2048 或 ECC P-256。我的习惯是：非对称只用来做密钥交换或签名，大数据加密一定要用对称。
哈希函数
把任意数据变成固定长度的摘要。不可逆。主要用来校验完整性，或者存密码。
常用的 SHA-256、SHA-3。
数字签名
用私钥对哈希值做签名，公钥验证。保证消息是谁发的、没被改过。HTTPS 的证书链就用到了这个。
对称 vs 非对称 —— 一张表看清
| 特性 | 对称加密 | 非对称加密 |
|---|---|---|
| 密钥数量 | 1 个 | 2 个（公钥+私钥） |
| 速度 | 快（MB/s 级别） | 慢（KB/s 级别） |
| 典型算法 | AES, ChaCha20 | RSA, ECDSA |
| 主要用途 | 数据加密 | 密钥交换、数字签名 |
| 密钥分发 | 难（需要安全通道） | 公钥随便发 |
它们是怎么配合的
实际场景往往混合使用。比如 HTTPS 握手时：先用非对称交换一个临时对称密钥，之后用对称加密通信内容。这就是“混合加密”。
避坑指南：KMS 迁移前要确认的事
- 明确密钥用途：是只用来加密还是也需要签名？不同用途要申请不同密钥。
- 密钥生命周期：本地库你可以随便轮换，云 KMS 轮换有延迟，要提前做计划。
- 成本估算：KMS 按 API 调用次数收费，不是按存储。我曾经被账单吓到过一次。
我曾经在迁移前没梳理清楚密钥用途，结果上线那天才发现非对称密钥忘了创建，临时加急申请耽误了两小时。所以，开工前先画一张当前系统的加密调用图。
本章核心知识体系
下面这张图帮你把今天讲的内容串起来：
从中心出发，对称和非对称解决「加密」需求，哈希解决「完整性」，数字签名解决「身份认证」。你迁移到 KMS 后，这些底层概念不变，只是密钥的存储和操作换成了云服务。