的WebSphere MQ通道訪問安全問題

Question

考慮以下隊列defintinons：

SET AUTHREC OBJTYPE（QMGR）集團（「MQ-用戶）AUTHADD（INQ，DSP，CONNECT）

SET AUTHREC簡介（SYSTEM.MQEXPLORER.REPLY.MODEL）OBJTYPE（QUEUE）GROUP（ 'MQ-用戶'）AUTHADD（INQ，DSP，GET）

SET AUTHREC PROFILE（SYSTEM.ADMIN.COMMAND.QUEUE）OBJTYPE（QUEUE）GROUP （'mq-user'）AUTHADD（INQ，DSP，PUT）

DEFINE C （$ cname）CHLTYPE（SVRCONN）TRPTYPE（TCP）MCAUSER（'tcs-mq-user'）REPLACE

SET CHLAUTH（$ cname）TYPE（ADDRESSMAP）ADDRESS（*）MCAUSER（'tcs-mq-user 「）

1. 什麼是MCAUSER中都定義了通道和SETCHLAUTH意思？
2. tcs-mq-user應該屬於mq-user組嗎？
3. 這是否意味着只有tcs-mq-user才能以綁定模式訪問隊列管理器？現在，如果我想在綁定模式下訪問另一個用戶，我應該爲該用戶創建另一對DEFINE CHANNEL和SET CHLAUTH命令嗎？
4. 是否可以授予頻道訪問mcs用戶組？

Answer 1

好的，答案已經發售，今天買一送三！ :-)讓我們把這些按順序排列...

1.A.通道的MCAUSER值是執行授權檢查的ID。如果DEFINE CHL() CHLTYPE(SVRCONN)將MCAUSER留空，則客戶端連接可以指定他們希望連接的ID。如果它們未能指定，WMQ客戶端嘗試使用客戶端用戶的ID，如從客戶端應用程序正在運行的工作站所看到的那樣。在通道定義中設置MCAUSER可防止客戶端應用程序指定值。

1.B.ADDRESSMAP規則中的MCAUSER用於根據某些標識條件映射MCAUSER。它說：「IF連接上到達這個通道與指定的IP地址|用戶名| SSL分辨名稱THEN使用這個 ID爲MCAUSER和允許通道運行，如果沒有其他規則塊它。

如果CHLAUTH映射規則被用於通常是設置該建議的信道的MCAUSER到不可能是一個用戶ID，所以它不會運行。通過這種方式，信道默認爲一個安全的狀態，除非一個CHLAUTH的值規則會將MCAUSER重寫爲允許訪問的值MCAUSER以前的價值曾經是nobody，直到Hursley實驗室的WMQ策略師Mark Taylor建議使用一個不能是實際用戶ID的值，例如no#body。從WMQ V7.1開始，值*NOACCESS是一個保留的工作，我現在用於會議演示中。

2.是的。 WMQ基於組進行授權。標準的建議是將您的安全需求解構爲'admin'，'app1'，'app2'，'monitoring'，'anonymous'等角色。然後，對於需要訪問的每個角色，創建一個組。

但訪問請求來自唯一標識的主體，而不是來自組。授權檢查需要一個帳戶進行檢查，以便通道中的MCAUSER是一個ID，而授權是按組存儲的。要將用戶與正確的權限相關聯，請將其註冊到正確的組中。

這是標準的UNIX授權模型，支持職責分離。資源管理員（WMQ管理員）授權組。帳戶管理員分組註冊用戶ID。它需要兩個組來提供訪問權限。在現實世界中，大多數商店不使用職責分離的特徵，但在重要情況下它是強制性的。

3.排序V7.1或更高版本的默認QMgr根本不允許任何遠程連接。這是因爲創建時沒有AUTHREC規則，因此非管理員不被授予訪問權限。管理員被默認的CHLAUTH規則阻止遠程訪問。

根據規定，任何人都可以成功連接到$cname頻道，並將被授權爲tcs-mq-user。如果您希望它們連接爲具有相同權限的其他用戶ID ，則需要將該ID添加到mq-user組，然後設置通道以映射出現的ID。如果您想要強制執行某人連接了哪個ID，因爲您必須通過IP地址指定映射，或者更好地根據其證書專有名稱來指定映射。

4.否如上面＃2所述，訪問請求總是由主體而不是按組進行。 CHLAUTH規則，MCAUSER和專有名稱映射的全部要點是解析該通道用於授權檢查的用戶標識。通道定義的MCAUSER是該ID解析過程中的安全控制，因此它在ID上運行，而不是在組上運行。

如果您還沒有找到該網站，您可能會發現T-Rob.net有用。特別是在鏈接頁面上，我公佈了會議的所有WMQ安全演示文稿以及我和其他作者文章的鏈接。