Amazon S3和Swift鉴权机制分析

基于Base64编码的HTTP Basic Authentication由于安全问题，已经不再广泛使用了。在云存储中，数据的安全性一直被广泛关注。亚马逊的AWS S3和Openstack Swift分别采取了不同的算法来对每一个HTTP请求进行鉴权。以下是二者的鉴权过程：
一、AWS S3的HTTP请求鉴权流程
    AWS采取的鉴权算法类似于HTTP基本认证。我们知道Base64只是对字符串进行了一个转换存储，是可以反向解析出源字符串的，因此基本认证中使用Base64编码处理过的用户名和密码可以被截获，一旦用户名和密码泄漏，黑客可以构造任何需要的请求进行数据窃取和改写。AWS采用的是签名认证的思想来解决这一问题。

基本原理：
1.客户端将请求中的通用信息(如：Bucket、Object、请求时间戳和请求方法名等)和Secret ID进行SHA256哈希计算得到一个字符串； 
2.最终在HTTP请求中传输的是该HASH值。其中Access Key在请求中以明文传输； 
3.服务端拿到该请求后，首先提取出Access Key，然后根据Access Key到服务端数据库中查询创建租户时分配给该租户的Secret ID； 
4.服务端从请求中提取通用信息，配合查询得到的Secret ID，使用同样签名计算过程计算一个签名，然后与请求中携带的签名进行比对，二者一致则认为该请求是合法请求，鉴权通过。否则返回403鉴权失败。

    如果整个HTTP请求被截获，黑客虽然能得到该鉴权值，但是无法反解析出用户的Secret ID，因为SHA是不可逆。因此最坏的情况：可以重复发送该请求(不修改请求中任一参数)到服务端，攻击范围非常有限。

    假设，黑客想使用该鉴权值伪造新的请求，那么修改请求中的通用信息，而签名值没有改变，最终鉴权也无法通过。

    那么是不是黑客可以一直使用该鉴权发送该请求呢？也不是的，AWS S3拿到请求后会比对服务端的时间与请求中的时间的差值，如果该请求的发出时间比服务端的时间早15分钟，则认为该请求为非法请求。客户端必须以新的时间戳来重新生成新的HASH值，再发送请求。
    从上面的过程来看，AWS的鉴权算法非常好的解决了**泄漏和每一个请求都能得到鉴权的问题。

二、再来看基于Keystone的Openstack Swift的HTTP请求鉴权流程
    Keystone的原理比较简单，整个系统提供全局唯一的Keystone服务，客户端在发送HTTP请求之前，首先需要向Keystone申请一个Token(定长的字符串)，该Token的有效期由Keystone服务端来指定。申请Token时，需要向Keystone提供用户名和密码，这里可以理解成AWS中的Access Key和Secret ID，Keystone认证通过该用户之后，发放Token给客户端。之后客户端每次发送HTTP请求时都必须携带该Token，Swift拿到该Token和用户名信息后，也会像Keystone查询该Token是否有效。Token有效，则继续处理该业务，Token无效，则返回鉴权失败。具体的流程可以从如下序列图看出：

 
    这样的鉴权过程存在一些问题：
1.相比于AWS的鉴权，这里如果Token泄漏，会造成比较严重的后果，虽然Token有有效期，但是每次都需用用户名和密码去申请，频繁申请也有可能会造成**的泄漏； 
2.每一次请求都需要Swift与Keystone之间作一次交互，性能可能存在问题。

    事实上，Openstack就发生过多次Token永久有效的bug，导致数据被破坏。当然这样的架构也有其优点，Keystone可以在多个服务间共享，将鉴权逻辑集中管理，做到了服务级的重用，而AWS必须在每一个服务中解析和生成签名，只能做到模块或者代码级别的重用。
--------------------- 
作者：HeyManLeader 
来源：CSDN 
原文：https://blog.csdn.net/sinat_27186785/article/details/52060264 
版权声明：本文为博主原创文章，转载请附上博文链接！