簡體   English   中英

Websphere MQ主題和SSL

[英]Websphere MQ Topic and SSL

我試圖了解業界對MQ主題的使用有多常見。 和MQ與SSL?

謝了,兄弟們

發布/訂閱
在WMQ第7版之前,Pub / Sub既可以作為WMQ的單獨組件,也可以作為WebSphere Message Broker功能的一部分。 現在在v7中,pub / sub是WMQ的組成部分,允許主題級安全性。 發生了一定數量的pub / sub采用,因為它現在作為本機功能被納入WMQ。

另一個影響WMQ pub / sub采用的因素是通過WMQ File Transfer Edition接觸更多人。 WMQ FTE使文件傳輸的狀態可用作出版物,許多使用此產品的人正在編寫監視這些主題的應用程序,以提供各種自定義功能。 一旦他們開始使用pub / sub,許多這些商店開始看到它的其他用途。

Pub / Sub還解決了一些常見的消息傳遞問題,例如當前正在寫入隊列的應用程序,並且出現了一個新要求,以便將該消息的副本發送給另一個消費者。 在v7之前,將應用程序從寫入隊列切換到寫入主題是有點侵入性的,需要對JMS應用程序進行配置更改或對其他類型的代碼進行代碼更改。 解決該問題的最簡單方法是使用將副本寫入兩個或多個隊列的應用程序或出口攔截消息。 從v7開始,為隊列編寫的應用程序可以提供有關主題的別名。 制作人仍然認為它正在寫入隊列,但WMQ正在將消息發布到主題。 然后,消費者可以直接訂閱,或者在需要隊列的遺留代碼的情況下,管理訂閱可以使主題上的消息被傳遞到隊列。 我看到很多人在pub / sub上采用這些要求來解決這些問題。

還有一些情況,其中pub / sub是適當的解決方案,僅憑這個原因就可以使用它。 過去,對單獨組件,管理技能或WMB許可證的要求是采用的障礙,導致某些部分的pub / sub應用程序被重新設置為點對點。 隨着pub / sub內置到WMQ中,這些障礙被消除或至少顯着減少,這導致更多的吸收,因為它是針對手頭問題的正確架構。

總的來說,我會說WMQ pub / sub已成為v7的主流。 自從v6報廢於2011年9月宣布以來,今年將大規模遷移到v7,隨后更多地采用pub / sub。

SSL / TLS
至於SSL,WMQ安全性正在接近主流。 我不會說SSL是常態 - 只是 - 但在過去的兩三年里,我在IMPACT和歐洲WebSphere技術會議上的WMQ實踐安全實驗室會議有足夠的需求。 最近寫了 ......

術語“可信賴的內部網絡”被用來區分內部網絡的這一部分與防火牆之外的目的地。 但是在這種情況下使用的術語“可信任”是相對的。 它不應該暗示內部網絡是隱式信任的,只是它比防火牆之外的東西更可靠。 不幸的是,該術語有時被解釋為非常字面。 我的客戶非常認真地告訴我,我們相信“可信賴的內部網絡”上的所有內容,這就是我們稱之為的原因。 當然,這誇大了這種情況,因為即使信任內部網絡的最堅定的信徒仍然強制執行基於密碼的登錄服務器,數據庫和應用程序。 因此內部網絡是可信的,但只有一點,甚至在內部網絡上的身份驗證和授權都是必不可少的。

雖然SSL(實際上是TLS)通道會加密,但它們也會進行身份驗證。 隨着越來越多的人意識到他們需要在“可信”內部網絡上驗證WMQ連接,SSL已經成為實現這一目標的常用方法。 當然,對於內部和外部連接的WMQ通道上的隱私(加密)和完整性服務的需求也在增長,這也推動了WMQ SSL通道的采用。

現在SSL更常見,當人們不完全理解WMQ安全性時,會出現許多次要挑戰。 這些現在是WMQ listserveMQSeries.net上的常見主題這一事實證明了SSL的采用水平。 其中一些次要問題是在QMgr的密鑰庫中包含未使用的證書頒發機構根證書,或缺少QMgr通道設置,如SSLPEER(按專有名稱過濾連接)或MCAUSER(將授權映射到特定用戶帳戶)。 人們經常啟用SSL,但忽略了其中一個或多個其他設置,並沒有達到他們預期的安全級別。 既然你必須為這些東西啟用SSL才能提出問題,那我的朋友就是“奢侈品問題”。 受SSLPEER設置挑戰比完全不應用SSL要好得多。

綜上所述...
所以我想這兩個問題的簡短答案是在WMQ中使用pub / sub和SSL是很常見的。 兩者現在都處於急劇上升的趨勢,如果我正在編寫新的應用程序,我肯定會使用SSL,並且會毫不猶豫地使用所需的WMQ pub / sub。

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM