公告 由于 OSS 私钥外流，导致 Ruby China 备份泄漏...
今天收到 WooYun 的通知，说 Ruby China 的数据库泄漏了... 
这件事情是我的疏忽，Ruby China 有个每日备份（包涵数据库，私密配置文件），定时往 Aliyun OSS 上存放备份的打包文件。
泄漏原因
曾经在 carrierwave-aliyun 的测试里面有个测试用了一个 OSS access_key，当初是用于一个用于开发测试的 Bucket 空间，但不知道什么时候开始，这个 key 有了访问 Ruby China 那个 Bucket 的权限（可能是久了无意中加上了...）
而这个泄漏的 key 是在 2013 年就有了，最初的时候没有太注意，权限过大，而那个 Bucket 几乎没怎么用，也就用于备份，已经都很久没访问过那个 Bucket 的账号了。
于是拿到那个 Key 以后就能下载到 Ruby China 历史上的所有备份文件了。
处理方案
在收到 WooYun 的通知以后，已经在第一时间删除了泄漏的 access_key 对 OSS 空间访问权限，同时清理了历史的备份文件。
接着更换了服务器上的各种私钥文件，包涵：
- config/secrets.yml
- config/config.yml [UpYun, PostMark, GitHub 等私钥]
所幸的是，备份里面没有包含 SSL 证书之类的东西。
重要！
- 关于网站密码，由于账号密码是加密了，问题不大，但存在暴力破解的风险。
- 如果你又在记事本里面存放重要信息，比如密码什么的，请尽快修改。
反思
这件事情的发生，源于私钥访问权限过大而导致的，看似 Ruby China 本身备份用的是另外一个 Key，但泄漏那个 Key 却有足够的权限访问关键的 Bucket。未来应该更细致的管理好这些私钥，不要混用。
刚才确认了一下，早期阿里云 AccessKey 是没有单独管理的，一个 AccessKey 权限是很大的：
云账号 AccessKey 有所有 API 访问权限
aliyun 和度娘普遍实现的都是 STS 鉴权。但另外带一个 Token 没啥必要性，有低权限的 Accesskey/Secret 对就应该足够了。上面说的 RAM 控制还没有普及，但 AWS 最初实现的就是这种，差距就在这里了。
#15 楼 @numbcoder dotenv 是侵入性的。我的意思是，管理 ENV 不该是代码依赖的某个 gem 的责任。当然这仅仅是我个人看法 ;-)
