云存储密钥安全：只存服务端 settings 的边界设计

学完这篇你能搞清楚：在 Clara BBS 里，云存储的 AccessKey / SecretKey 到底该放在哪一层，哪些位置绝对不能出现，以及怎么花五分钟做一次自查。

第一步：先分清「凭证」和「配置」

很多人把云存储的一堆参数混成一坨，这是边界失守的起点。先分类：

• 凭证（必须保密）：AccessKey ID、SecretKey、签名串。拿到它就能以你的身份读写整个 Bucket。
• 配置（可以公开）：Bucket 名称、区域（Region）、访问域名、路径前缀。这些出现在 URL 里很正常，泄露不了什么。

只有把这两类分开，后面的「放哪、不放哪」才有判断标准。

第二步：密钥只落到服务端 settings

Clara BBS 的云存储配置入口在后台「系统设置 → 云存储」。在这里填写的参数保存在服务端，实际的签名、上传、读文件动作都由服务端 PHP 完成，浏览器拿到的是处理后的结果，不是你的密钥本身。

保存即生效，不需要清缓存，也不用改任何文件。

注意：不要为了「调试方便」把 SecretKey 直接写进模板文件或前端 JS 里。输出转义和 CDN 缓存都挡不住这个——等于把钥匙贴在门上，谁打开 F12 都能拿走。

第三步：前端只应该拿到「结果」或「临时凭证」

合法的前端可见内容有两类：

1. 公开读的直链：Bucket 设为公共读时的图片地址。
2. 有有效期的临时签名：比如限时下载链接、直传用的临时 token。

判断标准很简单：有效期必须是短的，且不能反过来推出长期密钥。私有读的 Bucket 连读取也要走签名，不要图省事改成公共读——上传目录一旦公共可写，被塞脚本只是时间问题。

第四步：别把密钥硬编码进插件

Clara BBS 的插件放在 content/plugins 目录，走运行时钩子加载，保存即生效。正因为改起来太方便，有人会直接在插件文件里写死 AK/SK。

注意：插件一旦分享、备份到网盘、或者仓库公开，密钥就跟着走了。正确做法是让插件去读系统设置里的云存储配置，而不是自己存一份。

同理，备份数据库时也要意识到：settings 里是有密钥的，备份文件的保管级别要等同于密钥本身。

第五步：五分钟自查清单

按顺序做完这几条：

1. 打开网站首页 → 查看网页源代码，搜索 SecretKey、AccessKey、SecretAccessKey、sk- 等关键词，一篇都搜不到才算过关。
2. 打开 F12 → Network，发一个带图帖子，看上传请求里有没有裸密钥参数。
3. 回后台「系统设置 → 云存储」确认配置项没有被谁改成公共读写。
4. 到云厂商控制台确认这个 AK 是子账号，权限只覆盖对应 Bucket，而不是主账号密钥。
5. 检查 content/plugins 下的插件代码里有没有硬编码的密钥字符串。

顺带一提：排查上传失败时（白名单扩展名、PHP 的 upload_max_filesize / post_max_size、目录可写权限这三步），如果要把配置截图发到群里求助，先把密钥字段涂掉再发。

第六步：怀疑泄露了怎么办

顺序别搞反：先去云厂商控制台禁用或轮换这把 AK，再回后台把新密钥填进去。只删后台配置不吊销旧密钥是没用的——旧密钥在别人手里照样能用。轮换完之后翻一下云存储的访问日志，看有没有异常来源的读写。

小结

• 凭证和配置要分开，前者永不进前端，后者随便看。
• 密钥唯一落点是后台「系统设置 → 云存储」，由服务端发起签名与上传。
• 前端只拿直链或短时效临时签名，私有读的桶不要改成公共读写。
• 插件读系统设置，别硬编码；数据库备份要按密钥级别保管。
• 自查三处：网页源码、F12 请求、插件目录。
• 出事第一动作是吊销，不是改配置。