AI agent Secret Rotation Policy：密钥多久轮换一次，才不至于让旧凭证继续跑在生产环境

为什么密钥轮换如此重要？

2024 年 9 月，某金融科技公司的安全团队发现一个令人不安的事实：他们的生产数据库密码已经 18 个月没有轮换了。更糟糕的是，这个密码曾在 6 个月前被一位离职工程师分享到 Slack 的一个公开频道中，虽然很快删除了消息，但无法确定是否有人已经保存了这个密码。

幸运的是，这次是内部安全扫描发现的，而不是外部攻击者利用了这个漏洞。但这种情况并不罕见。根据 Verizon 2025 年数据泄露调查报告，34% 的数据泄露事件涉及被盗用的凭证，其中大部分是因为凭证长期未轮换或轮换不及时。

对于 AI agent 系统来说，密钥轮换的挑战更大：

• 凭证数量多：一个 agent 可能需要访问 OpenAI、Anthropic、数据库、向量存储、外部 API 等十几个服务。
• 依赖关系复杂：轮换一个凭证可能影响多个 agent、多个环境、多个下游系统。
• 自动化难度高：手动轮换容易遗漏，自动化轮换又担心出错导致服务中断。

Secret Rotation Policy（密钥轮换策略）就是为了解决这些问题而设计的系统性方案。它不是简单的"定期改密码"，而是提供轮换节奏、自动化流程、失败降级、紧急撤销和监控告警的完整框架。

不同凭证的轮换节奏

核心原则：风险与成本的平衡

轮换频率不是越高越好。过于频繁的轮换会带来：

• 运维成本增加：每次轮换都需要测试、验证、更新配置。
• 服务中断风险：如果轮换过程中出现错误，可能导致服务不可用。
• 开发者体验下降：频繁更换凭证会影响开发和调试效率。

但轮换频率也不能太低，否则：

• 泄露窗口期长：凭证一旦泄露，攻击者可以长期使用。
• 合规风险：某些行业标准（如 PCI DSS）要求至少每 90 天轮换一次密钥。
• 审计困难：长期不变的凭证难以追踪使用情况。

最佳实践是根据凭证类型、使用场景和风险等级，制定差异化的轮换节奏。

推荐轮换节奏表

注意：这些是通用建议，具体节奏应根据你的业务场景调整。例如：

• 金融行业：可能需要更短的轮换周期（如 API Key 30 天、Database Password 7 天）。
• 初创公司：可以适当延长轮换周期，优先保证开发效率。
• 合规要求严格的行业：必须遵循行业标准（如 PCI DSS、HIPAA、SOC 2）。

特殊场景的轮换策略

场景一：凭证泄露后的紧急轮换

触发条件：

• 检测到凭证在代码仓库、日志文件或公共论坛中泄露。
• 收到安全厂商或云服务商的泄露通知。
• 发现异常的凭证使用模式（如来自未知 IP 的大量请求）。

响应流程：

1. 立即撤销：在 Vault 或云控制台中立即吊销泄露的凭证。
2. 生成新凭证：创建新的凭证并部署到所有使用该凭证的服务。
3. 验证功能：确保新凭证正常工作，服务恢复正常运行。
4. 影响评估：检查泄露期间是否有异常操作或数据泄露。
5. 根本原因分析：找出泄露原因，修复流程漏洞。
6. 事后复盘：更新轮换策略，防止类似事件再次发生。

时间目标：从发现泄露到完成轮换，应在 1 小时内完成。

场景二：员工离职时的凭证清理

触发条件：

• 员工离职或转岗。
• 员工的访问权限发生变化。

响应流程：

1. 权限审查：列出该员工有权访问的所有凭证和服务。
2. 凭证轮换：轮换该员工知道的所有共享凭证（如团队共用的 API Key）。
3. 个人账户禁用：禁用或删除该员工的个人账户和 Service Account。
4. 审计日志检查：检查该员工最近的操作记录，发现异常行为。
5. 通知相关方：告知团队成员凭证已轮换，更新本地配置。

时间目标：员工离职当天完成所有凭证轮换。

场景三：合规审计前的集中轮换

触发条件：

• 即将进行 SOC 2、ISO 27001、PCI DSS 等合规审计。
• 内部审计发现部分凭证超过轮换周期。

响应流程：

1. 凭证盘点：列出所有超过轮换周期的凭证。
2. 分批轮换：按优先级分批轮换，避免一次性轮换过多导致服务中断。
3. 文档更新：更新凭证管理文档和审计报告。
4. 证据收集：保存轮换记录作为合规证据。

时间目标：审计前 2 周完成所有过期凭证的轮换。

自动化轮换架构

方案一：Vault Agent 自动轮换

HashiCorp Vault 提供了内置的自动轮换功能，适合大多数场景。

工作原理：

1. Vault Agent 以 Sidecar 或 DaemonSet 形式运行在每个节点上。
2. Agent 定期向 Vault Server 请求 renew lease（续期租约）。
3. 如果租约即将过期，Agent 自动获取新凭证并更新本地文件。
4. Agent 通过信号通知应用程序重新加载配置。

配置示例：

# vault-agent.hcl
auto_auth {
  method "approle" {
    config = {
      role_id_file_path = "/etc/vault/role-id"
      secret_id_file_path = "/etc/vault/secret-id"
    }
  }
  
  sink "file" {
    config = {
      path = "/home/vault/token"
    }
  }
}

listener "tcp" {
  address = "127.0.0.1:8100"
  tls_disable = true
}

cache {
  use_auto_auth_token = true
}

template {
  destination = "/etc/secrets/openai-api-key.txt"
  contents = <<EOH
{{ with secret "secret/data/openai/api-key" }}
{{ .Data.data.value }}
{{ end }}
EOH
  
  # 每 1 小时渲染一次（即轮换一次）
  wait {
    min = "1h"
    max = "2h"
  }
  
  # 渲染完成后发送信号给应用程序
  command = "kill -HUP $(cat /var/run/my-app.pid)"
}

优点：

• 完全自动化，无需人工干预。
• 支持动态凭证，Vault 自动生成新凭证。
• 与 Kubernetes、Consul 等基础设施深度集成。

缺点：

• 需要部署和维护 Vault Agent。
• 应用程序需要支持热重载配置（接收 SIGHUP 信号）。

方案二：AWS Secrets Manager 自动轮换

如果你使用 AWS，可以利用 Secrets Manager 的内置轮换功能。

工作原理：

1. 在 Secrets Manager 中启用自动轮换，指定轮换周期（如 30 天）。
2. AWS Lambda 函数定期执行轮换逻辑（由 AWS 托管）。
3. Lambda 函数调用 RDS、Redshift 等服务的 API 生成新密码。
4. 新密码更新到 Secrets Manager，并通知应用程序。

配置示例：

// Lambda 轮换函数示例（AWS 提供的模板）
import { SecretsManagerClient, RotateSecretCommand } from "@aws-sdk/client-secrets-manager";

export const handler = async (event: any) => {
  const client = new SecretsManagerClient({ region: "us-east-1" });
  
  // Step 1: 创建新密码
  const newPassword = generateRandomPassword();
  
  // Step 2: 设置新密码到数据库
  await setDatabasePassword(event.SecretId, newPassword);
  
  // Step 3: 更新 Secrets Manager
  await client.send(new RotateSecretCommand({
    SecretId: event.SecretId,
    ClientRequestToken: event.ClientRequestToken,
  }));
  
  // Step 4: 验证新密码可用
  await verifyDatabaseConnection(event.SecretId, newPassword);
  
  // Step 5: 完成轮换
  console.log("Secret rotation completed successfully");
};

启用自动轮换：

aws secretsmanager rotate-secret \
  --secret-id prod/database/password \
  --rotation-rules AutomaticallyAfterDays=30 \
  --rotation-lambda-arn arn:aws:lambda:us-east-1:123456789:function:SecretsManagerRotation

优点：

• 零运维，AWS 完全托管轮换逻辑。
• 与 RDS、Redshift、DocumentDB 等 AWS 服务无缝集成。
• 支持自定义 Lambda 函数，满足特殊需求。

缺点：

• 仅支持 AWS 生态，多云环境不适用。
• 自定义轮换逻辑需要编写和维护 Lambda 函数。
• 按轮换次数收费，高频轮换可能增加成本。

方案三：Cron Job + 自定义脚本

对于小规模团队或特殊场景，可以使用 Cron Job 定期执行自定义轮换脚本。

工作原理：

1. 编写轮换脚本，实现凭证生成、更新、验证逻辑。
2. 配置 Cron Job，定期执行轮换脚本（如每月 1 号凌晨 2 点）。
3. 脚本执行成功后，发送通知给团队；失败则发送告警。

示例脚本：

#!/bin/bash
# rotate-openai-key.sh

set -e

# 配置
VAULT_ADDR="https://vault.example.com"
VAULT_TOKEN="${VAULT_TOKEN}"
SECRET_PATH="secret/data/openai/api-key"
NOTIFICATION_CHANNEL="#security-alerts"

# 生成新 API Key（调用 OpenAI API）
NEW_KEY=$(curl -s -X POST https://api.openai.com/v1/api-keys \
  -H "Authorization: Bearer ${ADMIN_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{"name": "production-key-'$(date +%Y%m%d)'"}' \
  | jq -r '.key')

# 更新 Vault
curl -s -X PUT ${VAULT_ADDR}/v1/${SECRET_PATH} \
  -H "X-Vault-Token: ${VAULT_TOKEN}" \
  -d "{\"data\": {\"value\": \"${NEW_KEY}\"}}"

# 验证新 Key 可用
RESPONSE=$(curl -s -o /dev/null -w "%{http_code}" \
  https://api.openai.com/v1/models \
  -H "Authorization: Bearer ${NEW_KEY}")

if [ "$RESPONSE" != "200" ]; then
  echo "ERROR: New API key verification failed with status ${RESPONSE}"
  # 发送告警
  curl -X POST ${SLACK_WEBHOOK_URL} \
    -H 'Content-type: application/json' \
    --data "{\"text\": \"❌ OpenAI API Key rotation failed! Status: ${RESPONSE}\"}"
  exit 1
fi

# 通知团队
curl -X POST ${SLACK_WEBHOOK_URL} \
  -H 'Content-type: application/json' \
  --data "{\"text\": \"✅ OpenAI API Key rotated successfully at $(date)\"}"

echo "Secret rotation completed successfully"

Cron 配置：

# 每月 1 号凌晨 2 点执行轮换
0 2 1 * * /usr/local/bin/rotate-openai-key.sh >> /var/log/secret-rotation.log 2>&1

优点：

• 简单直接，易于理解和维护。
• 灵活定制，可以满足特殊业务需求。
• 成本低，只需支付服务器费用。

缺点：

• 需要自己处理错误重试、告警通知、幂等性等问题。
• 缺乏 Vault 的动态凭证、租约管理等高级功能。
• 安全性依赖于脚本的实现质量，容易出错。

失败降级策略

问题：轮换失败了怎么办？

即使设计了完善的自动化轮换流程，仍然可能遇到各种失败场景：

• 网络故障：Vault Server 不可达，无法获取新凭证。
• 权限问题：轮换脚本没有足够的权限更新凭证。
• 依赖服务故障：OpenAI API 暂时不可用，无法生成新 Key。
• 配置错误：轮换脚本有 bug，导致新凭证格式错误。

如果处理不当，轮换失败可能导致：

• 服务中断：旧凭证过期，新凭证未生效，服务无法访问依赖的资源。
• 数据丢失：数据库密码轮换失败，应用无法连接数据库。
• 安全风险：轮换失败后未及时告警，旧凭证继续使用，增加泄露风险。

策略一：旧凭证保留期（Grace Period）

原理：在生成新凭证后，不立即删除旧凭证，而是保留一段时间（如 24 小时），让应用程序有时间切换到新凭证。

实现：

async function rotateSecret(secretId: string) {
  // Step 1: 生成新凭证
  const newCredential = await generateNewCredential(secretId);
  
  // Step 2: 将新凭证写入 Vault，标记为 "active"
  await vault.write(`${secretId}/active`, newCredential);
  
  // Step 3: 将旧凭证标记为 "deprecated"，设置 24 小时后过期
  const oldCredential = await vault.read(`${secretId}/active`);
  await vault.write(`${secretId}/deprecated`, {
    ...oldCredential,
    expires_at: Date.now() + 24 * 60 * 60 * 1000, // 24 小时后过期
  });
  
  // Step 4: 通知应用程序重新加载配置
  await notifyApplications(secretId);
  
  // Step 5: 等待 24 小时后，删除旧凭证
  setTimeout(async () => {
    await vault.delete(`${secretId}/deprecated`);
    console.log(`Old credential for ${secretId} has been removed`);
  }, 24 * 60 * 60 * 1000);
}

应用程序端：

async function getCredential(secretId: string) {
  // 优先使用 active 凭证
  try {
    const active = await vault.read(`${secretId}/active`);
    return active.data;
  } catch (error) {
    // 如果 active 凭证不可用，尝试使用 deprecated 凭证（降级）
    console.warn(`Failed to get active credential for ${secretId}, falling back to deprecated`);
    const deprecated = await vault.read(`${secretId}/deprecated`);
    
    // 检查是否已过期
    if (deprecated.data.expires_at < Date.now()) {
      throw new Error("Deprecated credential has expired");
    }
    
    return deprecated.data;
  }
}

优点：

• 即使轮换过程中出现问题，服务仍可使用旧凭证继续运行。
• 给应用程序足够的时间切换到新凭证，避免服务中断。

缺点：

• 旧凭证在保留期内仍然有效，增加了泄露风险。
• 需要应用程序支持双凭证逻辑，增加了复杂度。

策略二：告警机制与人工干预

原理：轮换失败时立即发送告警，通知 on-call 工程师手动介入处理。

实现：

async function rotateWithAlerts(secretId: string) {
  const startTime = Date.now();
  
  try {
    await rotateSecret(secretId);
    
    // 轮换成功，发送成功通知
    await sendNotification({
      channel: "#security-alerts",
      message: `✅ Secret rotation succeeded for ${secretId}`,
      level: "info",
    });
  } catch (error) {
    const duration = Date.now() - startTime;
    
    // 轮换失败，发送紧急告警
    await sendNotification({
      channel: "#security-alerts",
      message: `🚨 Secret rotation FAILED for ${secretId}\nError: ${error.message}\nDuration: ${duration}ms`,
      level: "critical",
      pagerduty: true, // 触发 PagerDuty 告警
    });
    
    // 记录失败指标
    metrics.increment("secret_rotation.failures", { secret_id: secretId });
    
    // 抛出错误，阻止后续流程
    throw error;
  }
}

告警升级策略：

• T+0 分钟：轮换失败，发送 Slack 告警到 #security-alerts 频道。
• T+5 分钟：如果未确认告警，发送 PagerDuty 告警给 on-call 工程师。
• T+15 分钟：如果仍未处理，升级告警给安全团队负责人。
• T+30 分钟：如果问题仍未解决，启动应急响应流程，召集相关人员开会。

优点：

• 快速发现问题，减少服务中断时间。
• 明确的责任分工和升级路径，避免无人处理的情况。

缺点：

• 依赖人工干预，可能在非工作时间响应延迟。
• 频繁的告警可能导致告警疲劳，忽略真正重要的问题。

策略三：手动紧急撤销

原理：当自动化轮换失败且无法快速修复时，提供手动紧急撤销凭证的能力。

实现：

#!/bin/bash
# emergency-revoke.sh

set -e

SECRET_ID=$1
REASON=$2

if [ -z "$SECRET_ID" ] || [ -z "$REASON" ]; then
  echo "Usage: $0 <secret-id> <reason>"
  exit 1
fi

echo "⚠️  Emergency revoking secret: ${SECRET_ID}"
echo "Reason: ${REASON}"
echo "Operator: $(whoami)"
echo "Timestamp: $(date -u)"

# 确认操作
read -p "Are you sure you want to revoke this secret? (yes/no): " confirm
if [ "$confirm" != "yes" ]; then
  echo "Operation cancelled"
  exit 0
fi

# 撤销凭证
curl -s -X DELETE ${VAULT_ADDR}/v1/${SECRET_ID}/active \
  -H "X-Vault-Token: ${VAULT_TOKEN}"

# 记录审计日志
echo "$(date -u) | ${SECRET_ID} | REVOKED | ${REASON} | $(whoami)" >> /var/log/emergency-revocations.log

# 通知团队
curl -X POST ${SLACK_WEBHOOK_URL} \
  -H 'Content-type: application/json' \
  --data "{\"text\": \"🚨 Emergency revocation executed for ${SECRET_ID}\\nReason: ${REASON}\\nOperator: $(whoami)\"}"

echo "✅ Secret revoked successfully"

使用场景：

• 检测到凭证泄露，需要立即撤销。
• 自动化轮换失败，且旧凭证已过期，服务中断。
• 员工离职，需要立即禁用其访问权限。

注意事项：

• 紧急撤销操作必须记录审计日志，包括操作人、时间、原因。
• 撤销后应立即生成新凭证并部署，避免服务长时间中断。
• 定期进行紧急撤销演练，确保流程畅通。

监控与告警

关键指标

监控以下指标，及时发现轮换问题：

仪表盘示例

{
  "dashboard": "Secret Rotation Health",
  "panels": [
    {
      "title": "Rotation Success Rate (Last 7 Days)",
      "type": "time_series",
      "query": "sum(rate(secret_rotation_success_total[1h])) / sum(rate(secret_rotation_total[1h]))"
    },
    {
      "title": "Credentials Expiring Soon",
      "type": "table",
      "query": "credential_age_days > (rotation_period_days * 0.8)"
    },
    {
      "title": "Rotation Failures by Secret",
      "type": "bar_chart",
      "query": "sum by (secret_id) (increase(secret_rotation_failures_total[24h]))"
    }
  ]
}

告警规则

groups:
  - name: secret_rotation
    rules:
      - alert: SecretRotationFailure
        expr: increase(secret_rotation_failures_total[1h]) > 0
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Secret rotation failed for {{ $labels.secret_id }}"
          description: "Rotation failed {{ $value }} times in the last hour"
      
      - alert: CredentialExpiringSoon
        expr: credential_age_days > (rotation_period_days * 0.8)
        for: 1h
        labels:
          severity: warning
        annotations:
          summary: "Credential {{ $labels.secret_id }} is expiring soon"
          description: "Credential will expire in {{ $value | humanizeDuration }}"
      
      - alert: UnusedCredential
        expr: increase(credential_usage_total[7d]) == 0
        for: 24h
        labels:
          severity: info
        annotations:
          summary: "Credential {{ $labels.secret_id }} has not been used in 7 days"
          description: "Consider removing this unused credential"

FAQ

Q1: 密钥轮换会影响正在运行的服务吗？

A: 如果实施得当，不会影响。关键是要做到：

• 平滑切换：使用旧凭证保留期（Grace Period），让服务有时间切换到新凭证。
• 热重载：应用程序支持在不重启的情况下重新加载配置。
• 健康检查：轮换后立即验证新凭证可用，确认服务正常运行。

但如果轮换过程中出现错误（如新凭证格式错误、权限不足），仍可能导致短暂的服务中断。因此，建议在测试环境充分验证轮换流程，并在低峰期执行生产环境的轮换。

Q2: 轮换失败了怎么办？

A: 参考上文"失败降级策略"部分，主要有三种方式：

1. 旧凭证保留期：保留旧凭证 24 小时，让服务有时间切换。
2. 告警机制：立即发送告警，通知 on-call 工程师手动介入。
3. 紧急撤销：提供手动紧急撤销凭证的能力，应对泄露等紧急情况。

Q3: 如何知道哪些服务还在用旧凭证？

A:

• 审计日志分析：查询 Vault 审计日志，查看哪些 Actor 在最近访问了该凭证。
• 应用程序注册表：维护一个服务注册表，记录每个服务使用的凭证列表。
• 主动探测：轮换后监控服务健康状态，发现异常时快速定位受影响的服务。
• 标签系统：在 Vault 中为凭证添加标签（如 used_by: customer-support-agent），便于查询。

Q4: OAuth Token 刷新和轮换有什么区别？

A:

• OAuth Token 刷新：Access Token 过期后，使用 Refresh Token 获取新的 Access Token。这是 OAuth 协议的正常流程，通常由 SDK 自动处理，不需要人工干预。
• OAuth Token 轮换：定期更换 Refresh Token 本身，或者更换用于获取 Token 的 Client Secret。这是安全策略，需要主动执行。

简单来说，刷新是"续期"，轮换是"换锁"。

Q5: 轮换频率越高越安全吗？

A: 不一定。轮换频率需要在安全性和可用性之间找到平衡：

• 过于频繁：增加运维成本、服务中断风险、开发者负担。
• 过于稀疏：增加泄露窗口期、合规风险。

最佳实践是根据凭证类型、风险等级、业务场景制定差异化的轮换节奏，而不是一刀切地追求高频轮换。

Q6: 如何实现零停机轮换？

A:

• 双凭证并行：在轮换期间，同时保留新旧两个凭证，服务可以任选其一。
• 渐进式切换：先将一部分流量切换到新凭证，验证无误后再切换全部流量。
• 蓝绿部署：部署新版本的应用程序（使用新凭证），验证通过后切换流量，然后下线旧版本。
• Canary 发布：先在少量实例上测试新凭证，逐步扩大范围。

Q7: 轮换后如何验证新凭证有效？

A:

• 健康检查：调用依赖服务的健康检查接口，确认新凭证可以正常访问。
• 功能测试：执行一个简单的操作（如查询一条记录、发送一条消息），验证功能正常。
• 监控指标：观察错误率、延迟等指标，确认没有出现异常。
• 自动化测试：在 CI/CD 流水线中加入凭证验证步骤，轮换后自动运行测试。

Q8: 历史凭证需要保留多久？

A: 这取决于合规要求和业务需求：

• 审计要求：SOC 2、PCI DSS 等标准通常要求保留 1-7 年的审计日志，包括凭证轮换记录。
• 故障排查：保留最近 30-90 天的凭证历史，便于回溯问题。
• 法律要求：某些行业（如金融、医疗）可能有更严格的保留要求。

建议：

• 将历史凭证存储在安全的归档系统中，与活跃凭证隔离。
• 设置自动清理策略，超过保留期限的凭证自动删除。
• 确保归档系统的访问权限严格控制，只有授权人员可以访问。

延伸阅读

• NIST SP 800-57: Recommendation for Key Management
• OWASP Secret Management Cheat Sheet
• AWS Secrets Manager Automatic Rotation
• HashiCorp Vault Dynamic Secrets

Checklist

在实施 Secret Rotation Policy 之前，请确认以下事项：

• 已制定差异化轮换节奏表，覆盖所有凭证类型
• 已选择自动化轮换方案（Vault Agent / AWS Secrets Manager / Cron Job）
• 已实现旧凭证保留期（Grace Period）机制
• 已配置告警规则，轮换失败时立即通知
• 已编写紧急撤销脚本，并进行过演练
• 已设置监控仪表盘，跟踪轮换成功率、凭证年龄等指标
• 已在测试环境充分验证轮换流程
• 已制定轮换失败的手动干预流程
• 已记录历史凭证轮换日志，满足合规要求
• 已组织团队培训，确保所有开发者了解轮换流程

下一步行动：阅读 AI agent Operation Audit Trail，了解如何记录每次工具调用、状态变更和人工干预，留下不可篡改的审计日志。