基于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?
版權聲明：本文為博主原創文章，轉載請附上博文鏈接！

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。