API 凭证管理规范：环境变量、轮换、最小权限、可审计性

目的

审计并强化 API 凭证的处理方式，包括环境变量使用、隔离策略、轮换计划、最小权限原则及可审计性。

适用场景

• 触发条件：

- 为本集成强化凭证配置，将密钥移入环境变量。

- 设计针对这些 API 的密钥轮换计划，实现最小停机时间。

- 审计该服务的最小权限访问情况，并记录每个密钥的具体权限范围。

- 创建环境变量映射表和项目安全的 .env 模板。

- 为开发与生产环境建立凭证隔离机制，并确保具备清晰的审计追踪。

• 不适用情况：

- 试图在未经授权的情况下获取密钥或绕过安全控制。

- 需要法律或合规审批（本技能输出为技术文档，非法律意见）。

输入要求

• 必需：

- 列出所有集成/API 及其当前存储/使用的凭证位置。

- 部署上下文（本地开发、服务器、容器、n8n 等）。

• 可选：

- 当前配置文件或脱敏片段（.env、compose、systemd、n8n 凭证列表等）。

- 组织内部规则（轮换周期、密钥管理工具偏好）。

• 示例：

- “密钥硬编码在 Node.js 脚本中，且存在于 n8n 的 HTTP 请求节点中。”

- “我们有开发和生产两个 n8n 实例，需要实现隔离。”

输出内容

• 凭证映射表（服务 → 环境变量 → 权限范围 → 所属人 → 轮换频率）
• 轮换操作手册（步骤 + 回滚方案）
• 最小权限检查清单与审计日志规划
• 可选：.env 模板（仅含占位符）

成功标准：无敏感信息提交或嵌入代码中，权限最小化，轮换步骤已文档化，可审计性已明确。

工作流程

1. 盘点凭证：

- 明确凭证的存储位置、使用场景及责任人。

1. 定义隔离策略：

- 区分开发与生产环境；区分人工账户与服务账户；划分各集成之间的边界。

1. 将密钥迁移至环境变量或密钥管理器引用：

- 创建环境变量映射表，更新配置方案（代码/工作流中不得出现原始密钥）。

1. 实施最小权限原则：

- 针对每个 API，列出所需操作，按需缩减权限范围或角色。

1. 制定轮换计划：

- 若支持双密钥重叠机制，设计轮换流程以实现最小停机；明确回滚步骤。

1. 建立可审计性：

- 明确记录哪些事件（如认证失败、令牌刷新、密钥使用等）应被日志记录及其存储位置。

1. 暂停并询问用户，当遇到以下情况时：

- 必要操作不明确，

- 密钥注入方式不清楚，

- 轮换周期或责任人未指定。

输出格式

凭证映射表模板：

CREDENTIAL MAP
- Integration: <名称>
  - Env vars:
    - <VAR_NAME>: <用途> (secret/non-secret)
  - Permissions/scopes: <权限列表>
  - Used by: <服务/工作流>
  - Storage: <密钥管理器/环境变量>
  - Rotation: <频率> | <负责人> | <操作流程>
  - Audit: <记录的内容及存储位置>

如提供模板，请输出 assets/dotenv-template.example 文件，仅包含占位符。

安全与边缘情况

• 永远不要输出真实密钥、令牌或私钥，使用占位符代替。
• 默认只读模式；除非明确要求，否则仅提出修改建议而非直接修改文件。
• 除非有书面需求说明，避免使用过宽的权限范围或角色。

示例

• 输入：“n8n HTTP 节点中包含 API 密钥。”

输出：环境变量映射表 + 迁移至 n8n 凭证或环境变量的计划 + 轮换操作手册。

• 输入：“需要实现开发与生产环境的分离。”

输出：两套环境变量映射表 + 命名规范 + 访问边界检查清单。