基于隨機(jī)響應(yīng)隊(duì)列的ActiveMQ安全應(yīng)用①

龔建華

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

1 引言

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

2 共享響應(yīng)隊(duì)列安全風(fēng)險(xiǎn)分析

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

2.1 簡(jiǎn)單認(rèn)證策略及其安全風(fēng)險(xiǎn)

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

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

2.2 Java 認(rèn)證與授權(quán)策略及其風(fēng)險(xiǎn)

Java 認(rèn)證與授權(quán)策略中,也需要配置用戶名、密碼和分組,并將這3 項(xiàng)配置內(nèi)容分散在3 個(gè)文件中[19],如在login.config 文件中配置用戶名密碼管理文件和用戶分組管理文件,在user.properties 文件中設(shè)置用戶名和密碼,group.properties 文件中設(shè)置分組和用戶名.

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

Wireshark 是非常流行的網(wǎng)絡(luò)封包分析軟件,可以抓取各種網(wǎng)絡(luò)封包,顯示網(wǎng)絡(luò)封包的詳細(xì)信息.

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

由此可見,雖然JAAS 策略比簡(jiǎn)單認(rèn)證策略有所改進(jìn),但是下行方向采用常見的共享響應(yīng)隊(duì)列時(shí)仍然存在安全風(fēng)險(xiǎn).

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

3 基于隨機(jī)響應(yīng)隊(duì)列的安全機(jī)制

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

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

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

圖2 隨機(jī)響應(yīng)隊(duì)列系統(tǒng)架構(gòu)

在系統(tǒng)架構(gòu)中,消息中間件服務(wù)器中有1 個(gè)共享請(qǐng)求隊(duì)列和n個(gè)隨機(jī)響應(yīng)隊(duì)列.各個(gè)客戶端對(duì)共享請(qǐng)求隊(duì)列有寫權(quán)限無讀權(quán)限,服務(wù)端對(duì)共享請(qǐng)求隊(duì)列有讀權(quán)限無寫權(quán)限.服務(wù)端對(duì)所有n個(gè)客戶端響應(yīng)隊(duì)列有寫權(quán)限無讀權(quán)限,各個(gè)客戶端對(duì)所有n個(gè)客戶端響應(yīng)隊(duì)列有管理和讀權(quán)限無寫權(quán)限.

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

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

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

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

(1)客戶端i啟動(dòng)時(shí),動(dòng)態(tài)創(chuàng)建客戶端i響應(yīng)隊(duì)列,如USER.response.useri-xdWE2qUsz4.

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

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

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

(5)客戶端i退出時(shí),刪除隨機(jī)響應(yīng)隊(duì)列USER.response.useri-xdWE2qUsz4.

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

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

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

4 性能分析

前面分析系統(tǒng)的架構(gòu)、運(yùn)行過程和安全性,還需要進(jìn)一步分析系統(tǒng)在點(diǎn)對(duì)多點(diǎn)分布式應(yīng)用中的性能,從定量角度分析探索哪些因素是制約系統(tǒng)運(yùn)行性能的關(guān)鍵因素.在客戶端/服務(wù)器計(jì)算模式中,系統(tǒng)響應(yīng)時(shí)間是一項(xiàng)重要的指標(biāo),可用經(jīng)典排隊(duì)論模型對(duì)系統(tǒng)性能進(jìn)行分析.

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

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

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

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

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

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

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

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

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

為簡(jiǎn)便起見,設(shè)λi=λ,則：

式(4)中,nλ 表示總的請(qǐng)求強(qiáng)度,只有μ ＞nλ時(shí),業(yè)務(wù)請(qǐng)求隊(duì)列的平均隊(duì)長(zhǎng)才是一個(gè)有限值,請(qǐng)求逗留時(shí)間才是一個(gè)有限值,否則平均隊(duì)長(zhǎng)會(huì)越來越大趨于無限,使得等待時(shí)間也趨于無限,最終請(qǐng)求應(yīng)答不可完成.

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

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

5 結(jié)論

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