Metapi 安全实践：凭证加密存储、自托管数据隐私与 8 项必改配置完整清单
【免费下载链接】metapi把你在各处注册的 New API / One API / OneHub / DoneHub / Veloera / AnyRouter / Sub2API 等站点， 汇聚成 一个 API Key、一个入口，自动发现模型、智能路由、成本最优项目地址: https://gitcode.com/cita-777/metapi
Metapi 是一个自托管的 AI API 聚合网关，把散落在 New API、One API、OneHub、DoneHub、Veloera、AnyRouter、Sub2API 等站点的模型能力汇聚成"一个 API Key、一个入口"。正因如此，它经手两类高敏感资产：你各站点账号的凭证（API Key、Session Cookie、密码）和下游客户端的密钥。本文梳理 Metapi 的凭证加密存储机制、自托管带来的数据隐私优势，以及一份开箱即改的安全配置清单，帮助新手快速把实例变成"防偷窥"的形态。
为什么 AI API 网关必须重视安全？
Metapi 处在"下游客户端 ↔ 上游站点"的中间位置，相当于一个凭证保险柜加流量调度台：
- 上游凭证集中存放：你各站点的 API Key / Cookie 都交给 Metapi 保管，一旦泄露，等于所有账号同时失守；
- 下游密钥统一出口：
/v1/*统一代理端点由 Metapi 鉴权，密钥管理不善会被滥用刷量； - 日志里可能残留敏感信息：代理日志、调试追踪若保留不当，会放大泄露面。
所以 Metapi 的安全设计围绕三个问题展开：存得安全、看得模糊、进得有限。
凭证加密存储：AES-256-GCM 静态加密
在数据库中，账号密码等敏感凭证不以明文落盘，而是静态加密存储。核心实现在 accountCredentialService.ts：
- 算法为AES-256-GCM（带完整性校验的对称加密），每次加密使用随机 IV，密文带认证标签，篡改会被直接识别；
- 加密密钥由
ACCOUNT_CREDENTIAL_SECRET派生，未显式配置时回退到AUTH_TOKEN（见 config.ts）。给凭证加密单独配置一个独立、足够长的密钥，是本文清单里的重点项——这样即使数据库文件被拷走，攻击者拿不到管理后台令牌也无法解密凭证。
界面层的"脱敏显示"
加密是底线，界面上的掩码展示是第二道防线。Metapi 在返回 token 列表时统一走掩码函数（见 accountTokenService.ts）：sk-开头的密钥显示为sk-ab***尾4位的形态，界面与接口都不会完整回显密钥，避免"误截图""误分享"造成泄露。
上游站点若只返回掩码后的 token（如sk-abc***xyz），Metapi 也会将其标记为masked_pending占位状态，拒绝把不完整的占位值当成可用密钥启用——这是防止"半个密钥"被误用进路由的小而关键的设计。
自托管数据隐私：数据不出你的服务器
Metapi 是完全自托管的方案，这本身就是最强的隐私保证：
| 隐私维度 | Metapi 的表现 |
|---|---|
| 账号凭证 | 只存储在你自己的数据库（默认 SQLite，生产推荐 MySQL/PostgreSQL） |
| 对话与用量数据 | 代理日志、用量统计均落在你的DATA_DIR，不经过第三方 |
| 部署位置 | 云服务器、NAS、家用主机均可，数据边界由你控制 |
日常数据都写在DATA_DIR（默认./data）目录下，官方也建议在生产环境改用 MySQL/PostgreSQL 并定期备份该目录（参见 deployment.md）。注意两点：
- 数据库自身要用强凭证保护，不要开放公网端口；
.env文件包含AUTH_TOKEN、PROXY_TOKEN等机密，切勿提交进代码仓库，也不要粘贴进日志或 issue。
必改配置清单：8 项安全加固步骤
以下配置项均可通过环境变量（首次启动）或管理后台「设置」页完成（详见 configuration.md），前 4 项优先级最高：
| # | 配置项 | 说明 | 建议 |
|---|---|---|---|
| 1 | AUTH_TOKEN | 管理后台登录令牌，默认值是公开的占位符，不修改等于裸奔 | 设为 24 位以上随机强口令，后续可在后台「设置」中随时更换 |
| 2 | PROXY_TOKEN | 下游客户端调用/v1/*的全局 Bearer Token | 更换为独立强随机值；需要更细粒度控制时，改用后台「下游密钥」按项目下发 |
| 3 | ACCOUNT_CREDENTIAL_SECRET | 凭证加密密钥 | 独立于AUTH_TOKEN的长随机串，避免"一钥两用" |
| 4 | ADMIN_IP_ALLOWLIST | 管理接口 IP 白名单，支持 CIDR（如192.168.1.0/24） | 只放行家庭/办公网段，后台「会话与安全」中可视化配置 |
| 5 | HTTPS 反代 | 生产环境走 TLS 反向代理 | 令牌与凭证在传输层也要加密，明文 HTTP 仅建议内网使用 |
| 6 | HOST/ 防火墙 | 默认监听0.0.0.0:4000 | 用防火墙限制 4000 端口来源，或收窄HOST |
| 7 | .env与日志纪律 | 令牌不进仓库、不进日志 | 截图分享前检查是否包含完整 Key |
| 8 | 数据目录备份 | DATA_DIR是你的全部资产 | 定期备份，备份文件同样按机密管理 |
前 4 项对应的鉴权逻辑可以直观看到：管理接口先校验 IP 白名单、再校验 Bearer Token（见 auth.ts），任何一步不通过即返回 403，双层防线缺一不可。
密钥最小化：给每个项目发自己的 Key
比"改默认值"更进一步的做法是不给下游项目用全局PROXY_TOKEN。Metapi 的「下游密钥」支持按项目（如 OpenClaw、Claude Code）单独签发 Key，并可叠加模型白名单、限额、路由策略（参见 downstream-keys 页面）：
- 某个 Key 泄露 → 只影响该项目，一键禁用即可止损，无需全局换钥；
- 不同项目按策略隔离模型与额度，滥用面更小、审计更清晰。
发现安全问题怎么报告？
如果你发现 Metapi 的安全漏洞，请按 SECURITY.md 的流程走私密渠道（GitHub Security Advisory 或官方邮箱），不要直接发到公开 issue。报告请包含：漏洞描述、影响、受影响版本、复现步骤和概念验证（务必抹掉敏感信息）。官方承诺 3 个工作日内确认、7 个工作日内给出初步评估，修复后会发布带[SECURITY]标记的安全更新。
小结
Metapi 的安全模型可以概括为三层：静态加密（AES-256-GCM 存储凭证）→ 显示脱敏（界面永不回显完整密钥）→ 访问收敛（IP 白名单 + 强令牌 + 分项目 Key）。配合自托管带来的"数据不出户"，你只需要在上手时完成上面的 8 项配置，就能让这座"API 保险柜"真正上锁。
【免费下载链接】metapi把你在各处注册的 New API / One API / OneHub / DoneHub / Veloera / AnyRouter / Sub2API 等站点， 汇聚成 一个 API Key、一个入口，自动发现模型、智能路由、成本最优项目地址: https://gitcode.com/cita-777/metapi
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
