淺談分布式日志系統安全接口設計范文

本站小編為你精心準備了淺談分布式日志系統安全接口設計參考范文，愿這些范文能點燃您思維的火花，激發您的寫作靈感。歡迎深入閱讀并收藏。

0引言

在復雜的多系統應用中，日志系統的建立對于日志的分析、查詢有重要作用，多應用系統組成平臺中，一般采用分布式日志系統用于日志的存儲、分析與查詢[1]。采用易于識別和理解的REST日志服務接口是分布式日志系統建立的關鍵[2]，基于REST的日志服務能提供統一接口和資源定位，簡化日志服務接口的設計和實現，降低日志服務接口的復雜性[3]。但是REST本身缺少安全特性，存在著接口易被破解的危險，如果破壞者通過日志服務資源地址進行猜解，獲取了操作某一日志資源的接口并對該日志服務接口進行攻擊，那么很容易造成日志系統數據的破壞。本文針對REST中易于破解的危險性問題，根據復雜的多系統應用平臺在分布式日志系統中需求，探索日志服務的安全接口方法，設計一種基于REST接口安全認證方法。

1REST安全接口設計

一個安全的REST日志服務接口是需要對請求賬戶的認證與授權的鑒定，同時避免日志服務接口被大規模非法調用，出現系統資源的消耗，影響系統的正常訪問，甚至導致系統癱瘓、數據泄露、偽造（篡改）數據、制造垃圾數據等嚴重后果。

1.1安全接口模型

客戶端為第三方應用系統，請求對分布式日志系統增刪查服務。服務端為安全接口認證服務端，第三方應用系統在調用分布式日志REST服務接口之前，需要根據簽名機制為其HTTP請求計算一個簽名（sign），并使用簽名機制后的URL請求分布式日志REST服務接口。REST日志接口服務器在接收到請求時會獲取請求賬戶、請求時間戳、請求的URI，然后根據請求賬戶去數據庫查找對應的密鑰，然后REST日志接口服務端根據簽名機制為請求的參數重新計算簽名，并判斷其簽名值是否與第三方應用傳遞過來的簽名值參數值一致，以此判定客戶端HTTP請求是否被第三者偽造或篡改。

1.2安全接口認證方法

安全接口認證方法是服務端對客戶端做認證授權，包含請求簽名值的生成、防止接口重放攻擊、認證方法三個部分。

1.2.1請求簽名值的生成

教育電子身份號（EducationElectronicIdentity，EEID）已廣泛應用于網絡實名制管理[5]。采用教育電子身份證號作為第三方應用標識（請求賬戶），但是僅僅依靠教育電子身份證號（EEID）作為第三方應用標識做身份認證的憑證還是存在一定的安全隱患，所以采用MD5（信息-摘要算法5）算法根據EEID生成一個安全密鑰（secretKey）。將EEID與安全密鑰作為服務端對客戶端做身份認證。分布式日志系統提供日志服務的過程中，身份憑證是連接客戶端與服務端之間的紐帶，客戶端通過攜帶身份憑證、時間戳、簽名值訪問分布式日志系統資源，為防止身份憑證篡改而防范攻擊，憑證傳遞、時間戳、簽名值傳遞的安全性至關重要。所以為了身份憑證傳遞的安全性，為每一次請求計算一個簽名值，簽名值作為傳遞過程中是否數據的篡改的校驗。請求簽名值的生成方法為：將請求賬戶（appkey）、請求賬戶相對應的密鑰、請求的時間戳（timestrap）、請求的URI（rest_uri）采用一定的規則組成一個字符串，對該字符串采用HMAC-SHA1加密算法得到一個hash值的二進制數組，然后將該二進制數據轉換為十六進制的字符串，該字符串為此次請求的簽名值。

1.2.2防止接口重放攻擊

重放攻擊也成為新鮮性攻擊，即攻擊者通過重放消息或消息片段達到對主體進行欺騙的攻擊行為，在一個開放的空間中，攻擊者利用竊聽到消息進行重放，從而到達破壞消耗系統資源的目的。基于REST日志接口服務端校驗時間戳用來防止重放攻擊，首先服務端獲取客戶端傳遞過來的時間戳和生成服務端的時間戳，比較客戶端傳入的時間戳與服務端生成的時間戳是否在指定超時范圍內，通過校驗后再校驗客戶端簽名值在服務端是否使用，保證簽名值在服務端只能使用一次。只有通過以上校驗過程，日志資源提供服務器才會響應請求資源。

1.2.3認證方法

安全接口認證方法是服務器校驗客戶端是否正常請求的過程。客戶端在調用分布式日志REST服務接口時攜帶簽名值，基于REST日志接口服務端校驗時，獲取請求參數和數據庫中請求賬戶對應的密鑰，重新計算簽名，并判定服務端計算的簽名值與客戶端傳遞過來的簽名值參數值是否一致，以此對傳輸過來的身份憑證是否有效性進行驗證。

2REST安全接口實現

分布式日志系統REST安全接口認證方法實現分為客戶端與服務端的實現。客戶端為分布式日志系統接口調用方，即日志的生產者方。服務端為分布式日志系統接口提供方，即日志的儲存和分析平臺方。

2.1請求賬戶申請

在客戶端與服務端實現前，需要進行請求賬戶申請。請求賬戶申請首先在賬戶管理平臺上申請請求賬戶，管理員對請求賬戶申請進行審核與資源授權，賬戶管理平臺自動根據EEID生成應請求賬戶是根據教育電子身份證號（EEID）生成第三方應用標識碼作為請求賬戶，而EEID生成第三方應用標識碼可以保證請求賬戶的唯一性。密鑰生成采用MD5（信息-摘要算法5）生成做為密鑰的基礎算法，從申請賬戶計算MD5值做為密鑰較容易，同時任意長度申請賬戶計算出密鑰的值長度是固定的，同時申請賬戶的數據任意改動，得到密鑰的值有很大區別，有很大的抗修改性。簡單的MD5生成做為密鑰是不安全的，在MD5散列的過程中，加入足夠長的salt（即干擾字符串）生成MD5，而加干擾字符串后的MD5生成出密鑰是無法看到MD5具體的處理過程，即實現了申請賬戶對應唯一的密鑰，同時根據申請賬戶是不能偽造出密鑰的。

2.2客戶端實現

客戶端根據簽名機制算法計算簽名值，并使用簽名機制后的URL請求資源。初始時，在請求賬戶管理平臺上得到請求賬戶和請求賬戶相對應的密鑰；然后將請求賬戶、請求賬戶相對應的密鑰、請求的時間戳、請求的URI通過簽名機制算法得到簽名機制后的URL；最后通過HTTP方法請求簽名機制后的URL。

2.3服務端實現

基于分布式日志系統中REST的安全接口設計中服務端考慮所有的客戶端HTTP請求，都需要經過身份認證后才能進入后端業務邏輯，固采用MVC攔截器注入的方式，這樣業務邏輯和身份認證邏輯可以解耦。在攔截器中preHandle預處理回調方法中，實現服務端身份認證邏輯。服務端身份認證得到客戶端HTTP的請求中獲取請求賬戶、時間戳、簽名值和請求的URI，進行傳入參數的校驗、時間戳的檢驗、重放攻擊的防止、請求賬戶狀態的校驗、簽名的校驗、請求資源的鑒權等一系列身份認證通過后，然后進入請求對應的資源并返回。

3測試

目前國內外有效可行的Web服務安全性測試技術研究甚少，更加缺少對于Web服務安全性全面系統性的測試方法。本文采用httpclient和apache-jmeter-2.12作為模擬應用系統端對分布式日志系統REST安全接口進行性能測試，并對比分布式日志系統不采取安全接口與采取分布式日志系統設計REST安全接口的安全性與性能。性能測試中以不采取計安全接口中系統能承受最大并發線程數800，間隔時間1秒，循環次數為10。

4結束語

本文研究了基于教育電子身份號的REST接口安全認證方法，設計了分布式日志系統中日志服務安全接口，并對該安全接口進行測試。測試結果表明，該安全接口既能夠有效地對請求做身份認證，又能實現請求過程中數據的防止篡改、防止重放攻擊和能夠對請求資源進行鑒別的功能，對于復雜的多系統中接口的安全設計有一定的推廣作用。