密钥与凭据管理Secret and Credential Management

一套本地或自建部署的凭据面通常不止一个 key：模型 API key、云账号密钥、向量库与数据库口令、CI/CD 里的 token、以及推理服务自己那把访问 key。

OWASP 的密钥管理清单给出四条主线：集中存放并统一格式、自动化管理（含轮换）、按最小权限发放、以及把访问本身记进审计日志；同时明确不要硬编码。

轮换周期是可以查的数字：AWS 的密钥管理服务把「长期不换更容易被攻陷」写在最佳实践里，并把自动轮换的最短间隔给到每四小时一次。

泄漏路径常常不走代码：AWS 专门提醒命令行使用会把敏感参数留在 shell 历史与日志里；本机给工具配的 key，同一台机器上的其他进程也可能读到。

自建服务侧还要多问一句：这把 key 是谁的 key？共享一把意味着事后无法区分哪个团队、哪个应用在调用。

A self-hosted setup rarely has one secret: provider API keys, cloud account credentials, vector-store and database passwords, CI/CD tokens, and the access key for your own inference endpoint.

OWASP's secrets management guidance organises the work into four lines: centralise and standardise, automate management including rotation, issue on least privilege, and audit access itself - while keeping secrets out of code.

Rotation intervals are a checkable number. AWS writes that secrets left unchanged for a long time become more likely to be compromised, and its Secrets Manager can rotate automatically as often as every four hours.

Leaks often never touch the repository: AWS warns specifically that shell history and command logging can capture sensitive CLI arguments, and any key configured for a local tool is readable by other processes on that machine.

On your own service there is one extra question - whose key is it? A shared key makes it impossible later to say which team or which application made a call.