基于Base64編碼的HTTP Basic Authentication由于安全問題，已經(jīng)不再廣泛使用了。在云存儲(chǔ)中，數(shù)據(jù)的安全性一直被廣泛關(guān)注。亞馬遜的AWS S3和Openstack Swift分別采取了不同的算法來對(duì)每一個(gè)HTTP請(qǐng)求進(jìn)行鑒權(quán)。以下是二者的鑒權(quán)過程：
一、AWS S3的HTTP請(qǐng)求鑒權(quán)流程
????AWS采取的鑒權(quán)算法類似于HTTP基本認(rèn)證。我們知道Base64只是對(duì)字符串進(jìn)行了一個(gè)轉(zhuǎn)換存儲(chǔ)，是可以反向解析出源字符串的，因此基本認(rèn)證中使用Base64編碼處理過的用戶名和密碼可以被截獲，一旦用戶名和密碼泄漏，黑客可以構(gòu)造任何需要的請(qǐng)求進(jìn)行數(shù)據(jù)竊取和改寫。AWS采用的是簽名認(rèn)證的思想來解決這一問題。

基本原理：
1.客戶端將請(qǐng)求中的通用信息(如：Bucket、Object、請(qǐng)求時(shí)間戳和請(qǐng)求方法名等)和Secret ID進(jìn)行SHA256哈希計(jì)算得到一個(gè)字符串；?
2.最終在HTTP請(qǐng)求中傳輸?shù)氖窃揌ASH值。其中Access Key在請(qǐng)求中以明文傳輸；?
3.服務(wù)端拿到該請(qǐng)求后，首先提取出Access Key，然后根據(jù)Access Key到服務(wù)端數(shù)據(jù)庫中查詢創(chuàng)建租戶時(shí)分配給該租戶的Secret ID；?
4.服務(wù)端從請(qǐng)求中提取通用信息，配合查詢得到的Secret ID，使用同樣簽名計(jì)算過程計(jì)算一個(gè)簽名，然后與請(qǐng)求中攜帶的簽名進(jìn)行比對(duì)，二者一致則認(rèn)為該請(qǐng)求是合法請(qǐng)求，鑒權(quán)通過。否則返回403鑒權(quán)失敗。

????如果整個(gè)HTTP請(qǐng)求被截獲，黑客雖然能得到該鑒權(quán)值，但是無法反解析出用戶的Secret ID，因?yàn)镾HA是不可逆。因此最壞的情況：可以重復(fù)發(fā)送該請(qǐng)求(不修改請(qǐng)求中任一參數(shù))到服務(wù)端，攻擊范圍非常有限。

????假設(shè)，黑客想使用該鑒權(quán)值偽造新的請(qǐng)求，那么修改請(qǐng)求中的通用信息，而簽名值沒有改變，最終鑒權(quán)也無法通過。

????那么是不是黑客可以一直使用該鑒權(quán)發(fā)送該請(qǐng)求呢？也不是的，AWS S3拿到請(qǐng)求后會(huì)比對(duì)服務(wù)端的時(shí)間與請(qǐng)求中的時(shí)間的差值，如果該請(qǐng)求的發(fā)出時(shí)間比服務(wù)端的時(shí)間早15分鐘，則認(rèn)為該請(qǐng)求為非法請(qǐng)求。客戶端必須以新的時(shí)間戳來重新生成新的HASH值，再發(fā)送請(qǐng)求。
????從上面的過程來看，AWS的鑒權(quán)算法非常好的解決了密鑰泄漏和每一個(gè)請(qǐng)求都能得到鑒權(quán)的問題。

二、再來看基于Keystone的Openstack Swift的HTTP請(qǐng)求鑒權(quán)流程
????Keystone的原理比較簡(jiǎn)單，整個(gè)系統(tǒng)提供全局唯一的Keystone服務(wù)，客戶端在發(fā)送HTTP請(qǐng)求之前，首先需要向Keystone申請(qǐng)一個(gè)Token(定長的字符串)，該Token的有效期由Keystone服務(wù)端來指定。申請(qǐng)Token時(shí)，需要向Keystone提供用戶名和密碼，這里可以理解成AWS中的Access Key和Secret ID，Keystone認(rèn)證通過該用戶之后，發(fā)放Token給客戶端。之后客戶端每次發(fā)送HTTP請(qǐng)求時(shí)都必須攜帶該Token，Swift拿到該Token和用戶名信息后，也會(huì)像Keystone查詢?cè)揟oken是否有效。Token有效，則繼續(xù)處理該業(yè)務(wù)，Token無效，則返回鑒權(quán)失敗。具體的流程可以從如下序列圖看出：

?
????這樣的鑒權(quán)過程存在一些問題：
1.相比于AWS的鑒權(quán)，這里如果Token泄漏，會(huì)造成比較嚴(yán)重的后果，雖然Token有有效期，但是每次都需用用戶名和密碼去申請(qǐng)，頻繁申請(qǐng)也有可能會(huì)造成密鑰的泄漏；?
2.每一次請(qǐng)求都需要Swift與Keystone之間作一次交互，性能可能存在問題。

????事實(shí)上，Openstack就發(fā)生過多次Token永久有效的bug，導(dǎo)致數(shù)據(jù)被破壞。當(dāng)然這樣的架構(gòu)也有其優(yōu)點(diǎn)，Keystone可以在多個(gè)服務(wù)間共享，將鑒權(quán)邏輯集中管理，做到了服務(wù)級(jí)的重用，而AWS必須在每一個(gè)服務(wù)中解析和生成簽名，只能做到模塊或者代碼級(jí)別的重用。
---------------------?
作者：HeyManLeader?
來源：CSDN?
原文：https://blog.csdn.net/sinat_27186785/article/details/52060264?
版權(quán)聲明：本文為博主原創(chuàng)文章，轉(zhuǎn)載請(qǐng)附上博文鏈接！

總結(jié)

以上是生活随笔為你收集整理的Amazon S3和Swift鉴权机制分析的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。