俄羅斯：將審查iPhone等外國公司設備 保數據安全
iPhone和特斯拉都屬于在各自領域領頭羊的品牌，推出的產品也也都是數一數二的，但對于一些國家而言，它們的產品可靠性和安全性還是在限制范圍內。近日，俄羅斯聯邦通信、信息技術
大家好，我是君哥。
我們在使用消息隊列時，經常關注的是消息隊列收發消息的功能。但好多時候需要對客戶端有一定的限制，比如只有持有令牌的客戶端才能訪問集權，不允許 Producer 發送消息到某一個 Topic，或者某一個 Topic 只能給固定 Consumer 消費。
為了能對客戶端有一定限制，需要對消息隊列進行認證和鑒權，今天我們就來聊一聊主流消息隊列是怎么做認證和鑒權的。
認證是指通過一定手段，對訪問用戶身份進行校驗，只有校驗通過的用戶，才允許訪問。
默認情況下，主流消息隊列是不開啟認證的，這也意味著只要網絡能通，客戶端就可以訪問 Broker 集群，可以說集群處于“裸奔”的狀態，有很大的風險。
消息隊列的認證，是指對客戶端進行身份確認，只有認證通過的客戶端才可以訪問 Broker 集群資源。
常見的認證的方式有很多，主流消息隊列一般會定義一個認證框架來制定認證規則，然后通過實現這個框架來定義具體認證方式。
SSL(Secure Sockets Layer)是為網絡通信提供安全及數據完整性的一種安全協議，消息隊列基于 SSL 的認證是指 Broker 和客戶端的認證，可以是單向認證，也可以是雙向認證。
消息隊列為了提升吞吐量，降低延遲，一般都是基于 TCP/IP 協議構建的，SSL 協議位于應用層和傳輸層之間。
使用 SSL 進行通信前，客戶端和 Broker 都需要引入各自的證書，并且引入對應編程語言的 SSL 庫。通信時，客戶端攜帶對應的證書和公鑰信息，與 Broker 建立連接，Broker 則對客戶端進行認證，認證成功后，客戶端才能進行下一步操作。
Kafka 在早期的 0.9 版本引入了 SSL。
SSL3.0 版本后改名成 TLS，TLS 是 SSL 的升級版本。Pulsar 和 RabbitMQ 這 2 個消息隊列支持 TLS。
SASL 全稱是 Simple Authentication and Security Laye，是一種標準化的 C/S 身份認證協議，客戶端和服務器基于這個協議交換身份信息，驗證成功后才可以建立連接。
SASL 其實是一中認證框架，基于這個框架我們可以實現多種認證機制，比如用戶名密碼、Kerberos、NTLM、OAuth等。
Kafka 0.9.0.0 版本開始支持 SASL，并且基于 SASL 實現了多種認證插件。如下圖：
RocketMQ 基于 AK/SK 實現認證方式，通過對稱加密來驗證客戶端身份，保證認證密碼不會以明文在網絡上傳輸，提升認證安全。
客戶端發送請求時，使用加密算法對請求參數進行加密，然后生成數字簽名，在請求中發送用戶名和簽名信息。Broker 收到請求后，首先查詢用戶名是否在本地庫(不存在則認證失敗)，如果存在，則用相同的算法對請求進行加密和簽名，然后比較簽名結果跟客戶端請求中的簽名信息是否一致。
RabbitMQ 和 Pulsar 都提供了自定義、可插拔的身份認證框架，然后基于框架的接口來實現各種認證插件，在配置文件中指定要使用的認證插件。
Pulsar 內置的認證插件包括 JWT、OAuth2.0、Athenz、Kerberos 等。
RabbitMQ 實現的認證插件包括 AMQPLAIN 和 PLAIN。
總結：認證框架的選擇很多，Kafka 選擇的 SASL 機制更加完善，功能更加強大，實現起來也更加復雜。而自定義的機制則實現更加簡單，同時也能滿足消息隊列的認證需求。
下面對主流消息隊列使用的認證方式總結如下：
消息隊列 | 認證方式 |
Kafka | SASL：GSSAPI、PLAIN、SCRAM、OAUTHBEARER、Delegation Token |
RocketMQ | AK/SK |
RabbitMQ | AMQPLAIN、PLAIN |
Pulsar | JWT、OAuth2.0、Athenz、Kerberos |
客戶端通過認證后，就跟 Broker 建立了連接，但是并不是每個客戶端都可以操作所有的集群資源，比如銀行里面的不同業務數據不能給所有客戶端訪問。這就需要對客戶端做資源訪問限制。
授權是指對客戶端賦予一定的權限，比如允許客戶端從某一個 Topic 拉取消息。
消息隊列對于資源的操作分為兩種，一種是運維相關操作，比如創建 Topic、創建用戶等，權限一般分配給運維人員。另一種是數據相關操作，包括生產消費消息，權限一般分配給業務系統客戶端。
要實現資源控制，一般分成兩種方式，下面詳細介紹一下。
如果分開兩條鏈路來操作集群資源，一條鏈路由運維人員來通過 HTTP 來操作集群資源，另一條鏈路由業務系統客戶端通過 TCP 來收發消息，這樣實現權限控制就非常容易，成本很低。
主流消息隊列 Pulsar 和 RabbitMQ 就是這種方式實現的。
這種方式也有一個問題，就是集群中需要開啟兩個 Server 來服務兩個鏈路。
跟兩條鏈路相對應的是，運維操作和業務客戶端操作都通過一條鏈路來實現。
一條鏈路的方式集群不用啟動兩個 Server，但是需要根據用戶來分配權限，需要在代碼層面實現集群的資源控制，實現難度較大。主流消息隊列中的 Kafka 和 RocketMQ 就是用的這種方式。
無論是兩條鏈路還是一條鏈路，都無法細粒度地控制集群資源。比如運維操作要限制某個用戶只能添加 Topic 而不能刪除 Topic，業務系統客戶端只被允許從某一個 Topic 發送和消費消息。
想要細粒度的控制集群資源，就需要引入鑒權模型，常見的鑒權模型如下：
主流的消息隊列都是基于 ACL 來實現鑒權的。要實現 ACL(Access Control List) ，首先需要定義好集群中有哪些資源或哪些操作需要做鑒權。
主流消息隊列中，Kafka 的資源或操作定義非常細致，資源包括：Topic、消費者組、Broker 集群等，操作則包括：讀、寫、創建、刪除、修改、訂閱等。Kafka 對資源的操作定義成不同接口(比如創建 Topic)，通過接口來做鑒權控制。見官網 KIP-11 下面鏈接。
https://cwiki.apache.org/confluence/display/KAFKA/KIP-11+-+Authorization+Interface
Kafka 實現了可插拔的授權機制，該機制把所有 ACL 項保存在 ZooKeeper，Zookeeper 創建 /kafka-acl 節點進行保存。Kafka 提供了 kafka-acls 腳本，可以動態修改 ACL 配置項，并且可以立即生效。在 server.properties 中加入下面配置，就可以開啟 ACL 鑒權：
authorizer.class.name=kafka.security.auth.SimpleAclAuthorizer其中 SimpleAclAuthorizer 是 Kafka 自帶的鑒權實現類，這里也可以配置自定義的鑒權實現類。
RabbitMQ 的架構相對簡單，定義的資源主要包括：Exchange、Queue 等，操作則包括讀、寫、配置。因為 RabbitMQ 的集群配置是通過 HTTP API 操作，所以并沒有提供接口維度的權限控制。
Pulsar 的鑒權包括生產、消費、Lookup、Function、Source(從數據源讀取數據)、Sink(數據存入下游)、Packages(保存用戶代碼包)。鑒權信息保存在 Zookeeper 的 /admin/policies/[namespace] 目錄下。Pulsar 也支持可插拔的授權框架，默認實現類是 PulsarAuthorizationProvider。
RocketMQ 中的 ACL 提供了 Topic 資源級別的用戶訪問控制。用戶在使用 RocketMQ 權限控制時，可以在 Client 客戶端通過 RPCHook 注入 AccessKey 和 SecretKey 簽名，同時將對應的權限控制屬性（包括 Topic 訪問權限、IP 白名單和 AccessKey 和 SecretKey 簽名等）設置在 distribution/conf/plain_acl.yml 的配置文件中。
RocketMQ 對 Topic 資源訪問權限控制定義了四種，下面表格來自官網 ，
https://rocketmq.apache.org/zh/docs/4.x/bestPractice/04access/
權限 | 含義 |
DENY | 拒絕 |
ANY | PUB 或者 SUB 權限 |
PUB | 發送權限 |
SUB | 訂閱權限 |
權限定義的關鍵屬性參考 distribution/conf/plain_acl.yml 配置文件。
RocketMQ 的用戶分為普通用戶和管理員用戶，跟普通用戶相比，管理員用戶具有更新或創建主題、更新 Broker 配置、刪除主題、更新或創建訂閱組信息、刪除訂閱組信息等權限。
消息隊列的超級用戶能夠訪問集群中所有的資源，對集群運維非常方便。比如分配出去的用戶密碼被惡意修改了，集群無法訪問，這時超級用戶可以把密碼再改回來。超級用戶可以讓運維人員方便地執行緊急性、臨時性地操作。
超級用戶一般固定在配置文件中，客戶端對集群進行訪問控制的時候，集群對用戶是否是超級用戶進行判斷。
Kafka 和 Pulsar 都有超級用戶的機制，RabbitMQ 則沒有超級用戶。
默認情況下，主流消息隊列都是不開啟認證和鑒權的。但在復雜的業務架構中，為了保證隊列中數據安全性，必須開啟認證和鑒權。消息隊列的認證機制有很多，鑒權則主要是通過 ACL 來實現。希望本文能對你理解消息隊列的認證和鑒權有所幫助。
本文鏈接：http://www.tebozhan.com/showinfo-26-91375-0.html聊聊主流消息隊列的認證和鑒權！
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號