OSS 数据安全
当前 OSS 保证数据安全的方式参考的方式有如下几种方式
1、 OSS 要设置为私有的避免公共读，或者公共读写。
2、尽量不要使用传统的 AccesskeyID （AK）、AccesskeySecret （SK），改用 STS token 的方式替代原来的教研方式；
3、可以采用 OSS 内容加密，在鉴权的基础上双重加密，使用 KMS 对内容进行加密，但操作过程略微复杂；
使用场景
服务端存储 AKSK
用户自己有服务器，部署一套签名代码，使用 AK SK 生成鉴权的 signature 返回给客户端，端上利用 signature 构造 http 的请求头的方式来验签；
服务端生成 STS token
此类场景多用在移动端使用，客户端通过一个 https 地址请求到用户服务器，服务器上部署一个生成 STS token 的程序，收到移动端请求后请求 RAM 服务端生成 STS 信息。获取到 RAM 服务端返回的 STS.AK STS.SK STS.token 信息后，再返回给移动端使用；
需要注意用户服务器上也是用 AK SK 去申请的 STS，所以需要用户将生成一个子账号，然后配置好角色，将角色和权限绑定后，再通过子账号进行调用角色去生成 STS 信息；
移动端请求用户服务器尽量使用 HTTPS 协议，避免明文被劫持；服务端也可以针对移动端的请求做二次校验，比如客户端请求时携带一个 token，服务端校验通过再返回 STS 信息；
客户端拿到鉴权签名如何防泄露
header AK SK 签名
1、服务端通过 header + AK SK 签名方式生成 signature 后，可以对 header 签名做二次加密。比如客户端请求服务端时携带设备号和时间戳信息，服务端通过设备号和时间戳对 signature 做加密，再返回给客户端；
2、客户端拿到加密后的 signature ，通过约定的解密算法将 signature 解析出来，这样可以避免 signature 被别人抓到，或者被反编译出来；
3、通过客户端和服务端的传输可以用 https 方式避免被旁路劫持干扰；
4、header 签名拿到后，有效期是 15min ，超过 15min 没有使用，signature 失效无法继续使用；
header STS 签名
1、服务端通过 header + STS 签名方式生成 signature 后，在生成 STS 时可以限制只允许当前携带了设备号的 IP 来获取 signature ，如果设备号和 IP 不匹配的情况，即便是其他客户获取到了 STS token 也无法上传；
2、 当STS 暴露后，用户可以在 RAM 产品上将这个 STS 用的角色删除掉，重新配置一个角色即可，可以最小化降低影响；
3、生成 STS 时的 有效时间尽量不要那么长，控制在 900 - 3600s 之内，如果每个 STS token 都是 3600s 失效时间会带来一定的业务风险；
