📚 课程目录第2章凭据类型与分类

凭据类型与分类：对称密钥、非对称密钥、证书、令牌、API Key、临时凭据

凭据管理这件事，说白了就是搞清楚「谁用什么来证明自己」。我在不少项目里见过一种通病——把所有的密钥、令牌、证书全塞在一个配置中心里，美其名曰「统一管理」。结果呢？一旦泄露，攻击者拿到的是万能钥匙。

所以，咱们得先把凭据分门别类。每种凭据的用途、生命周期、存储方式都不一样。你想想看，把 API Key 当证书用，或者把临时凭据当永久密钥存，这不出事才怪。

核心原则：凭据分类不是学术游戏，而是安全策略的基石。每种凭据都有它最适合的战场。

对称密钥，就是加密和解密用同一把钥匙。AES、SM4、HMAC 都属于这一类。它的优点是快——硬件加速下，AES-256 加解密能达到 GB/s 级别。我在做支付网关时，核心链路上必须用对称密钥，因为非对称算法根本扛不住那个吞吐量。

但对称密钥有个致命弱点：分发。你想想看，通信双方怎么安全地拿到同一把钥匙？如果通过网络传输，密钥本身就可能被截获。我见过一个项目，直接把对称密钥写在配置文件里，用 Git 管理——嗯，这基本等于把家门钥匙贴在门框上。

我的习惯：对称密钥只用于内部系统通信，或者通过密钥协商协议（如 Diffie-Hellman）派生。绝对不要在公网上直接传输对称密钥。

非对称密钥包含公钥和私钥。私钥自己留着，公钥可以公开。RSA、ECC、SM2 都是典型代表。它的核心价值在于：不需要预先共享密钥就能建立安全通道。

我记得有一次做物联网设备认证，设备端只存私钥，服务端存公钥。设备上线时用私钥签名一个随机数，服务端用公钥验签——整个过程不需要传输任何秘密信息。这就是非对称密钥的魅力。

但代价是性能。RSA-2048 签名比 AES-256 加密慢三个数量级。所以实际场景中，我们通常用非对称密钥来交换对称密钥（比如 TLS 握手），然后用对称密钥加密后续数据。

我曾经踩过的坑：有人把私钥和公钥一起存到同一个 Vault 路径下，美其名曰「方便管理」。结果一个实习生误操作把私钥当公钥发到了日志里。记住：私钥必须单独保护，访问权限要比公钥严格至少一个数量级。

证书本质上是一个「带签名的公钥」。X.509 证书里包含了公钥、持有者信息、颁发者信息、有效期，以及 CA 的数字签名。它的作用是解决「你怎么知道这个公钥真的是 Bob 的？」这个问题。

证书链是这里的关键。根 CA 自签名，中间 CA 由根 CA 签名，终端证书由中间 CA 签名。客户端只需要信任根 CA，就能验证整个链上的所有证书。我在做微服务 mTLS 时，就是靠证书链来建立服务间的双向信任。

令牌（Token）是当前分布式系统中最常用的凭据形式。JWT（JSON Web Token）是典型代表——它把用户身份、权限、过期时间等信息编码成一个自包含的字符串，服务端不需要查数据库就能验证。

我建议你注意 JWT 的签名方式。用 HS256（对称签名）时，签发和验证用同一个密钥，适合内部系统。用 RS256（非对称签名）时，签发用私钥，验证用公钥，适合跨系统场景。我在做开放平台时，必须用 RS256，因为第三方只需要拿到公钥就能验证令牌真伪。

关键点：令牌一旦签发，在过期之前无法撤销。所以过期时间一定要短——我个人习惯 Access Token 设 15 分钟，Refresh Token 设 7 天。如果担心泄露，可以用黑名单机制，但那会牺牲无状态的优势。

API Key 就是一个随机字符串，用来标识调用方身份。它简单直接，适合服务端到服务端的认证。但 API Key 本身不是安全令牌——它通常不包含签名，也不绑定请求内容。

我见过最糟糕的用法：把 API Key 直接放在 URL 参数里，或者放在 HTTP Header 的明文里。更离谱的是，有人把 API Key 硬编码在移动 App 的源码里——反编译一下就能拿到。

避坑指南：API Key 必须配合 HTTPS 使用，并且要支持轮换。我曾经在一个项目中，API Key 用了三年没换过，直到一次安全审计才发现 Key 已经出现在多个第三方日志里。从那以后，我强制要求所有 API Key 每 90 天轮换一次。

临时凭据是近年来安全领域最重要的进步之一。AWS STS（Security Token Service）就是典型——它允许你为某个角色生成一个临时令牌，有效期从几分钟到几小时不等。过期后自动失效，不需要手动撤销。

我在做云原生架构时，所有 Pod 都通过 Service Account 获取临时凭据来访问云 API。每个 Pod 的权限范围精确到「只能读自己的 Bucket」，凭据有效期只有 1 小时。即使某个 Pod 被攻破，攻击者拿到的也只是一把「限时钥匙」。

临时凭据的核心价值在于：缩小攻击面。你想想看，如果所有服务都用同一个长期密钥，一旦泄露就是灾难。而临时凭据即使泄露，攻击者也只有很短的时间窗口可以利用。

我的建议：能用临时凭据的地方，就不要用长期凭据。对于云服务、微服务间调用、CI/CD 流水线，优先使用 STS 或类似机制。长期凭据只保留在根账户或紧急备用场景。

在实际项目中，我通常会根据以下几个维度来选择凭据类型：