龔建華

(武漢科技大學 城市學院,武漢 430083)

1 引言

消息中間件是大型系統(tǒng)中的重要組件,它具有松耦合、異步消息、流量削峰、可靠投遞、廣播、流量控制、最終一致性等一系列功能,已經成為異步RPC的主要手段之一.目前常見的消息中間件有ActiveMQ、RabbitMQ、Kafka、RocketMQ 等[1].消息中間件在大型系統(tǒng)和分布式系統(tǒng)中應用非常廣泛[2-18],因此消息中間件應用的安全性應該得到足夠重視.

2 共享響應隊列安全風險分析

面對分布式應用的信息安全問題,ActiveMQ 采取了一些必要的安全措施,主要有兩種安全訪問策略[19],一是簡單認證策略,二是Java 認證與授權(JAAS)策略.由于消息中間件在多用戶應用中通常采用共享響應隊列應用模式,導致上述ActiveMQ 安全措施仍然不能防止合規(guī)用戶的越界訪問和違規(guī)獲取信息.

2.1 簡單認證策略及其安全風險

簡單認證策略中,需要在ActiveMQ 服務器的activemq.xml 文件中配置允許訪問消息隊列的用戶,具體說就是在簡單認證插件(SimpleAuthenticationPlugin)中配置用戶名、密碼和分組.然后在客戶端建立到消息隊列連接時,填寫用戶名和密碼即可.這種策略的本質是經過授權用戶的可以使用消息隊列,類似于用戶名/密碼的登錄機制.

這種策略的優(yōu)點是使用起來比較方便簡單,但也存在安全風險,合法用戶對消息隊列的操作沒有限制,可以管理、讀、寫任何消息隊列.在此策略基礎上,如果采取常用的共享請求隊列(即各客戶端的請求發(fā)送到一個隊列中)或共享響應隊列模式,合法用戶可以利用第三方工具軟件從共享請求隊列中或共享響應隊列中非法讀取他人請求信息.

2.2 Java 認證與授權策略及其風險

Java 認證與授權策略中,也需要配置用戶名、密碼和分組,并將這3 項配置內容分散在3 個文件中[19],如在login.config 文件中配置用戶名密碼管理文件和用戶分組管理文件,在user.properties 文件中設置用戶名和密碼,group.properties 文件中設置分組和用戶名.

與簡單認證策略不同,JAAS 策略中增加授權機制,即每一個隊列只有指定的分組才可以管理或讀或寫,對合法用戶可以訪問的消息隊列進行限制,比如只能向公共請求隊列發(fā)送消息而不能讀取消息,從而保證發(fā)送到公共請求隊列的消息不被合法用戶違規(guī)讀取.在這種授權機制中,上行方向單向應用消息隊列是安全的,即客戶端向服務器端發(fā)送請求信息時采用共享請求隊列可以保證安全性.如果下行方向也采用分組共享響應隊列,不能保證其安全性.

Wireshark 是非常流行的網絡封包分析軟件,可以抓取各種網絡封包,顯示網絡封包的詳細信息.

圖1是利用該軟件分析得到的訪問消息列隊的用戶名和密碼,利用該軟件分析出得到的響應隊列名稱,同樣利用該軟件還可以分析出消息中間件服務器的IP 地址、端口號等,有了這些分析信息,合法用戶可以通過第三方軟件違規(guī)獲取其他用戶的響應信息.

由此可見,雖然JAAS 策略比簡單認證策略有所改進,但是下行方向采用常見的共享響應隊列時仍然存在安全風險.

圖1 利用Wireshark 抓包分析用戶名和密碼

3 基于隨機響應隊列的安全機制

3.1 系統(tǒng)基本架構

消息中間件應用中,共享響應隊列模式是影響系統(tǒng)安全性的關鍵因素,為了提高系統(tǒng)安全性,每個客戶端應該獨立使用一個響應隊列.在ActiveMQ 中,如果給每個客戶端單獨配置用戶名、密碼和響應隊列,當客戶端很多時,配置工作量將會非常大,而且動態(tài)增減用戶時,必須更新配置文件并重啟消息中間件服務器,這會影響系統(tǒng)的連續(xù)運行.

本文提出隨機響應隊列應用模式,既不用大量維護配置文件和重啟服務器,又可以使每個客戶端隱蔽地單獨占用一個響應消息隊列,系統(tǒng)架構如圖2所示.

圖2 隨機響應隊列系統(tǒng)架構

在系統(tǒng)架構中,消息中間件服務器中有1 個共享請求隊列和n個隨機響應隊列.各個客戶端對共享請求隊列有寫權限無讀權限,服務端對共享請求隊列有讀權限無寫權限.服務端對所有n個客戶端響應隊列有寫權限無讀權限,各個客戶端對所有n個客戶端響應隊列有管理和讀權限無寫權限.

在設置系統(tǒng)配置文件時,給所有客戶端配置共同的用戶名和密碼,能夠管理和讀取某個固定前綴(如USER.response)的響應隊列.為了保證客戶端i響應隊列只被客戶端i讀取,而不被其他客戶端讀取,將客戶端i響應隊列的名稱設置為：“固定前綴+用戶名+隨機碼”,例如USER.response.useri-xdWE2qUsz4,加入“固定前綴”可以確保所有客戶端都可以創(chuàng)建類似的隊列,加入“用戶名”可以保證隊列名不同重復,加入“隨機碼”可以保證隊列名不可預知從而保證隊列名稱的隱蔽性.雖然各客戶端理論上可以讀取這個隨機響應隊列中的信息,但是由于這個響應隊列名稱的隨機性且只有創(chuàng)建它的客戶端知道,因而事實上這個響應隊列只能被創(chuàng)建它的客戶端使用,從而保證安全性.為了讓服務端也知道這個隨機響應隊列的名稱,客戶端給服務端發(fā)送請求時,只需要附帶這個隨機響應隊列名稱即可.

為了完成上述任務,activemq.xml 文件需要增加如下配置[19]：

3.2 系統(tǒng)運行過程

在隨機響應隊列系統(tǒng)架構中,共享請求隊列是固定的,由消息中間件服務器創(chuàng)建.客戶端i發(fā)送請求和獲得響應的完整閉環(huán)過程如下：

(1)客戶端i啟動時,動態(tài)創(chuàng)建客戶端i響應隊列,如USER.response.useri-xdWE2qUsz4.

(2)客戶端i通過共享請求隊列發(fā)送請求,請求信息除了業(yè)務信息外,還需要附帶客戶i響應隊列名稱,如,textMessage.setStringProperty("queueName","USER.response.useri-xdWE2qUsz4"),以便告知服務端響應信息發(fā)送到哪個隊列.

(3)服務端從請求隊列接收消息,解析queueName,如,textMessage.getStringProperty("queueName"),并將業(yè)務響應結果發(fā)送到USER.response.useri-xdWE2qUsz4響應隊列中.

(4)客戶端i監(jiān)聽USER.response.useri-xdWE2qUsz4響應隊列,當發(fā)現(xiàn)新消息時,從響應隊列中讀取消息,完成業(yè)務請求-響應閉環(huán).

(5)客戶端i退出時,刪除隨機響應隊列USER.response.useri-xdWE2qUsz4.

3.3 系統(tǒng)安全性分析

在隨機響應隊列系統(tǒng)架構下,假定合規(guī)客戶i想要非法獲取其他客戶端請求和響應信息,在客戶端i啟動時,在本地使用抓包軟件進行分析,他只能獲取消息中間件服務器的IP 地址、端口號、共享請求隊列的名稱、客戶端i響應隊列的名稱等.共享請求隊列是只寫的,因此他不能通過讀取請求隊列的內容,也無法通過此途徑違規(guī)獲取有關信息.由于不能獲得客戶端i響應隊列之外的其他隊列的名稱,因此也無法訪問其他響應隊列,無法違規(guī)獲取其他客戶有關信息.雖然能夠獲取客戶端i響應隊列的名稱,也可以獲取客戶端i響應隊列的內容,但是此內容已在他自己的客戶端中可以展現(xiàn),再用第三方軟件抓取已經沒有實際意義.經上述分析,在獨立響應隊列系統(tǒng)架構下,可以保證消息隊列中的信息安全.

消息中間件服務器的安全防護不是本文的研究內容,用戶非法直接攻擊消息中間件服務器,非法獲取或篡改配置信息不在本文研究范圍之內,本文假定消息中間件服務器本身已經采取了防攻擊措施.

4 性能分析

前面分析系統(tǒng)的架構、運行過程和安全性,還需要進一步分析系統(tǒng)在點對多點分布式應用中的性能,從定量角度分析探索哪些因素是制約系統(tǒng)運行性能的關鍵因素.在客戶端/服務器計算模式中,系統(tǒng)響應時間是一項重要的指標,可用經典排隊論模型對系統(tǒng)性能進行分析.

系統(tǒng)時間模型如圖3所示,系統(tǒng)運行時間為客戶端發(fā)送業(yè)務請求到收到請求響應所經歷的時間,設客戶端i的請求到達共享請求隊列的傳輸時間為t1,該請求在共享請求隊列中等待的時間為t2,該請求從共享請求隊列傳輸?shù)椒斩说膫鬏敃r間為t3,該請求在服務端業(yè)務處理時間為t4,響應從服務端傳輸?shù)娇蛻舳薸響應隊列的時間為t5,響應在隊列中等待時間為t6,響應從隊列到達客戶端的時間為t7.

圖3 系統(tǒng)時間模型

(1)設信息在系統(tǒng)中的傳輸時間t傳,則t傳=t1+t3+t5+t7,t傳與系統(tǒng)網絡硬件環(huán)境有關,因此隨機響應隊列應用模式不會改變t傳的大小.

(2)設信息在系統(tǒng)中的等待時間t等,則t等=t2+t4+t6,由于客戶端i響應隊列為客戶端i獨享,因此t6=0,最終t等=t2+t4,與系統(tǒng)中的客戶端數(shù)量、單位時間內客戶端發(fā)送的請求數(shù)量以及服務端的處理能力有關,與客戶端i響應隊列無關.

綜上所述,系統(tǒng)運行時間主要受系統(tǒng)網絡硬件環(huán)境、客戶端數(shù)量、單位時間內客戶端發(fā)送的請求數(shù)量以及服務端的處理能力有關,采用隨機響應隊列模式不會影響系統(tǒng)運行時間或性能.下面著重討論為保證服務質量應當采取的相關措施.

假設客戶端發(fā)送請求為簡單流(泊松流),單位時間內,客戶端平均發(fā)送 λ次請求,則單位時間內發(fā)送次數(shù)服從分布為X～P(λ)[20].

對于n個相互獨立的客戶端,設每個客戶端單位時間平均發(fā)送 λi次請求,則到達業(yè)務請求隊列的請求次數(shù)服從分布為：

假設服務端完成業(yè)務處理的時間服從負指數(shù)分布,且在單位時間內平均完成μ 條業(yè)務處理,則概率密度為：

假設消息隊列長度不受限制,請求響應服從M/M/1[20]排隊系統(tǒng)模型,則平均系統(tǒng)逗留時間為：

為簡便起見,設λi=λ,則：

式(4)中,nλ 表示總的請求強度,只有μ ＞nλ時,業(yè)務請求隊列的平均隊長才是一個有限值,請求逗留時間才是一個有限值,否則平均隊長會越來越大趨于無限,使得等待時間也趨于無限,最終請求應答不可完成.

根據條件的限制,當服務端的業(yè)務處理能力一定時,即μ一定時,必須滿足nλ ＜μ,也就是說,如果n比較大,那么 λ必須足夠小,其表示物理意義是,如果客戶端數(shù)量較多,那么每個客戶端的請求強度不能太高；反過來,如果 λ比較大,那么n必須很小,其表示的物理意義是,如果每個客戶端的請求強度比較大,則客戶端的數(shù)量不能太多.

當μ ＞＞nλ 時,wq比較小,當μ →nλ 時,wq迅速增大,假定用戶對逗留容忍的值為Wmax,用戶的操作習慣決定了請求強度為 λ,服務器的性能決定了服務能力為μ,μ和 λ 通過樣本均值統(tǒng)計得到,那么系統(tǒng)可允許的客戶端數(shù)量為為了保證服務質量,在線用戶數(shù)達到nmax服務端應該拒絕為新用戶提供服務,確保已在線用戶可以得到滿意的服務在質量.

5 結論

圍繞消息中間件安全應用問題,本文提出了基于隨機響應隊列的應用模式,給出了系統(tǒng)架構和運行過程.通過定性分析,隱蔽的隨機響應隊列可以有效防范非法獲取響應信息；通過時間模型分析,隨機響應隊列應用模式不會影響系統(tǒng)運行性能；通過理論計算表明,在請求強度和服務能力確定的情況下,為保證服務質量,在線用戶規(guī)模應控制在以下.