凭据轮换基础概念
说白了，凭据就是我们系统里的"通行证"——密码、、密钥这些。你想想看，每次你登录数据库、调API、连服务器，背后都是凭据在敲门。
凭据轮换呢，就是定期换掉这些通行证，让旧的失效、新的上岗。我在项目里见过太多人一用就是三年的密钥，真替他们捏把汗。
为什么非要轮换？
先问一个问题：你家大门钥匙多久换一次？如果十年不换，谁捡到都能进来。凭据也一样。
- 泄漏止损：GitHub上误提交密钥的事，我每周都能听到。轮换能把风险窗口从「永远」压缩到「几小时」。
- 合规要求：PCI DSS、SOC2、ISO 27001都在强制要求定期轮换。有一次审计，客户拿出密钥一年没换的记录……嗯，那个整改单写了好长。
- 内部离职：我习惯每季度轮换一次，这样就算前员工还揣着旧，也早失效了。
注意：不要觉得轮换麻烦就不做。我曾经接手一个项目，主库密码用了四年没动过，后来被人扫到了弱口令——一夜之间数据全光。轮换不是开销，是保险。
我们到底在换什么？
凭据类型很多，但常见的有这么几类。我列个表，你看一眼就明白了。
| 凭据类型 | 典型形式 | 轮换周期（我推荐） |
|---|---|---|
| 静态密码 | 数据库密码、SSH密码 | 90天 |
| Access Key / Secret Key | 180天（配合密钥ID回退） | |
| JWT、OAuth2.0 | 短生命周期（分钟/小时级）+ 刷新 | |
| 加密证书 | TLS证书、签名证书 | 1年（Let's Encrypt自动90天） |
| 临时凭证 | STS、IAM Role | 自动过期（通常15分钟-6小时） |
你看，除了临时凭证，其他都需要我们主动轮换。临时凭证本身就是轮换思路的产物——让凭证自己到期，省心。
常见凭据类型详解
静态密码
老古董了，但还是最多。我建议你用工具生成20位以上的随机串，别手打。嗯，这里要注意：用户名密码最好也轮换，别光改密码不改名。
云厂商用的多，比如AWS的Access Key + Secret Key。轮换思路是：生成新密钥 → 更新应用 → 确认旧密钥无流量 → 删除旧密钥。我写过一段Python脚本自动化这个流程：
import boto3
def rotate_access_key(username):
iam = boto3.client('iam')
# 创建新密钥
new_key = iam.create_access_key(UserName=username)
# 应用更新（实际需要更新配置文件）
print(f"新AccessKeyId: {new_key['AccessKey']['AccessKeyId']}")
# 等24小时后删除旧密钥
# iam.delete_access_key(UserName=username, AccessKeyId=old_key_id)
个人经验：轮换时一定要做灰度——先让新密钥上线，确认旧密钥没有报错再删。否则一旦有漏掉的服务，整个挂掉。
（JWT）
JWT天然支持过期时间，我习惯把access_设15分钟，refresh_设7天。refresh_也定期轮换——每次刷新时发一个新refresh_，旧的就失效。这样就算盗了refresh_，也只能用一会儿。
加密证书
证书轮换最怕的就是"证书过期，服务挂掉"。我建议用ACME协议自动续签，或者至少提前30天发告警。有一次我在凌晨两点被叫起来——客户系统的SSL证书过期了半小时，用户直接访问不了。从那以后我再也不敢手动管证书了。
凭据轮换的核心知识体系
下面这张图可以帮你把这一章讲的东西串起来。嗯，看一眼就清楚了。
一句话总结：凭据轮换就是把"一次性泄漏、永远失效"变成"即使泄漏，窗口极短"。核心原则是——能自动就别手动，能短周期就别长周期，能灰度就别一刀切。
我习惯用一句话记：轮换是安全运营的呼吸节奏。不呼吸，系统就憋死了。