引言：靈活認證/授權機制帶來高效安全保障
EMQX 始終十分關注安全性，通過大量開箱即用的安全功能為廣大物聯網用戶提供持續增強的安全保障，包括 MQTT over TLS/SSL、基於國密算法的傳輸加密認證集成方案，以及用戶名/密碼、LDAP、JWT、PSK 和 X.509 證書等多種身份認證功能。
本文將通過對 EMQX 客戶端認證與授權機制以及 5.0 版本中相關優化的詳細解析，為讀者展示 EMQX 進行物聯網安全保障的原理機制，幫助大家更好地使用這一功能構建更加安全可靠的物聯網平台與應用。
EMQX 客戶端認證機制
身份認證是大多數應用程序的重要組成部分，在物聯網應用中也一樣。
MQTT 協議允許客戶端攜帶用戶名/密碼用於身份認證，在此基礎上 EMQX 擴展允許客戶端在密碼中攜帶 Token 實現 JWT 認證。同時，EMQX 完整支持 MQTT 5.0 增強認證功能，能夠通過質詢/響應風格方式實現對客戶端和服務器的雙向認證，實現更強的安全性保障。
三種認證方式密碼認證EMQX 支持最簡單也是使用最多的認證方式，密碼認證要求客戶端提供能夠表明身份的憑據，例如用戶名、客戶端 ID 以及對應的密碼。在某些場景下，用戶可能會選擇將 TLS 證書中的一些字段（例如證書公用名稱）作為客戶端的身份憑據使用。
但不論使用何種身份憑據進行認證，這些身份憑據都會提前存儲到特定數據源（數據庫）中，其中密碼通常都會以加鹽後散列的形式存儲，這也是我們強烈建議的方式。
密碼認證在 EMQX 中的基本運作原理為：在客戶端連接時，EMQX 將使用用戶指定的查詢語句在數據庫中查詢與該客戶端提供的身份憑據對應的密碼散列值，然後與客戶端當前連接密碼的散列值進行匹配，一旦匹配成功，EMQX 將允許該客戶端登錄。
密碼認證流程，使用 PosgresSQL 作為數據源
JWT（https://jwt.io/） 是一種基於 Token 的認證機制，它不需要服務器來保留客戶端的認證信息或會話信息。客戶端可以在密碼或用戶名中攜帶 Token，EMQX 則使用預先配置的密鑰或公鑰對 JWT 簽名進行驗證。
如果用戶配置了 JWKs 服務器，則 JWT 認證器將使用從 JWKs 服務器查詢到的公鑰列表對 JWT 簽名進行驗證。在持有密鑰的情況下用戶可以為客戶端批量簽發認證信息，是最簡便的認證方式。
MQTT 5.0 增強認證MQTT 5.0 增強認證（https://www.emqx.com/zh/blog/mqtt5-enhanced-authentication）是對密碼認證的擴展，它更像是一種認證框架，允許使用各種更安全的認證機制，例如 SCRAM 認證、Kerberos 認證等。目前 EMQX 已支持 SCRAM 認證，並且通過內置數據庫提供了對 SCRAM 用戶管理的支持。
在傳輸層方面，EMQX 支持 TLS 的雙向認證，這在某種程度上能滿足客戶端和服務端之間的身份驗證要求，EMQX 也支持基於 PSK 的 TLS/DTLS 認證，本文不再贅述此部分內容。
認證鏈、超級用戶與權限
EMQX 允許創建多個認證器構成一條認證鏈，認證器將按照在鏈中的位置順序運行，如果在當前認證器中未檢索到身份憑證，將會切換至鏈上的下一個認證器繼續認證，所有認證器都沒有查找到數據則客戶端認證失敗。
EMQX 允許在認證階段為客戶端設置超級用戶角色以及預設權限列表，用於後續的發布訂閱權限檢查。
EMQX 授權機制
EMQX 授權是指對客戶端的發布和訂閱操作進行權限控制。與客戶端認證一樣，客戶端權限列表同樣需要提前存儲到特定數據源（數據庫、文件）中，更新對應的數據即可實現權限的運行時動態更新。
授權機制在 EMQX 中的基本運作原理為：在客戶端發布或訂閱時，EMQX 將使用特定的流程或用戶指定的查詢語句從數據源中查詢該客戶端相關的訪問控制列表（ACL），與當前操作進行匹配並根據匹配結果允許或拒絕當前操作。
緩存、授權鏈與權限優先級大量的客戶端訂閱和發布將會對授權數據後端產生訪問壓力， 因此 EMQX 引入了緩存機制。
EMQX 允許創建多個授權檢查器構成一條授權鏈，授權檢查將按照在鏈中的位置順序運行，如果在當前授權檢查器中未檢索到權限數據，將會切換至鏈上的下一個檢查器繼續檢查，所有檢查器都沒有查找到數據則客戶端根據 no_match 配置（https://www.emqx.io/docs/zh/v5.0/security/authz/authz.html#no-match）默認允許或拒接操作。
如果客戶端在認證階段設置了超級用戶角色，則後續的發布訂閱操作不會再觸發授權檢查；如果設置了權限列表，則優先匹配客戶端權限數據。三者匹配關係如下：
認證與授權數據源
EMQX 為密碼認證、授權提供了與多種後端數據庫的集成支持，包括 MySQL、PostgreSQL、MongoDB 和 Redis。
同時 EMQX 也支持用戶將身份憑證和權限列表存儲到內置數據庫（基於 Mnesia）中，這種方式提供了非常簡單的配置流程和用戶管理接口。用戶可以通過 REST API 或 Dashboard 管理認證數據，或從 CSV 或 JSON 文件批量導入用戶。
除此之外，EMQX 還可以通過 HTTP 方式對接用戶自己開發的服務，藉此實現更複雜的認證與授權邏輯。
移除認證授權插件
EMQX 5.0 中我們將認證授權功能從插件遷移至內置功能，原認證授權插件不再內置。
除了配置文件的方式外，EMQX 允許通過 Dashboard 與 REST API 配置認證授權功能，選擇需要的認證方式，選擇擅長的數據源，填入參數即可啟用連接認證和授權檢查功能，為客戶端提供最重要的安全防護。REST API 的配置方式能夠在實現將配置一次性分發並生效至集群所有節點中，這種熱配置的方式大大提升了易用性，能夠更快的上手使用。
相比於 4.x 版本，使用內置數據時 EMQX 5.0 還在 Dashboard 提供了數據管理頁面，用戶在瀏覽器上即可完成數據的導入/添加與管理，真正實現開箱即用零開發能力。
內置的認證授權本身也是通過掛載鈎子的形式實現控制的，用戶仍然可以使用 EMQX 4.x 中開發的認證授權插件，或基於 EMQX 5.0 開發新的插件，此時插件與內置功能將以鈎子掛載順序確定執行優先級。
以下是認證與授權功能掛載的鈎子信息，更多信息請參考：https://www.emqx.io/docs/zh/v5.0/advanced/hooks.html
移除匿名認證機制
* 我們建議用戶務必在生產環境中禁用匿名認證以避免數據庫列表之外的客戶端連接至 EMQX。
EMQX 沒有配置任何認證器時，此時允許所有客戶端連接
EMQX 配置認證器後：
所有認證器禁用：允許客戶端連接
任意認證器啟用：查找身份憑證進行認證，如果全部啟用的認證器中都沒有找到身份憑證，則禁止客戶端連接
EMQX 5.0 認證鏈示意圖
調整認證器與授權檢查器順序
用戶可以創建多個認證器和授權檢查器組成鏈實現鏈式認證，儘管我們不推薦這麼做，但某些場景下這是有益的：比如客戶端數量多、發布訂閱速率很高的極端場景下，用戶可能使用 Redis 作為鏈中的第一個授權檢查器，與 HTTP 授權檢查服務搭配使用，藉助 Redis 高性能、自帶 TTL 優勢提供緩存層以實現更高性能的授權檢查能力。
此前鏈上檢查器執行的順序是通過對應插件加載順序決定的，並沒有對應的配置接口，這會帶來幾個問題：
EMQX 初次啟動時需要手動去每個節點執行插件加載操作，確保插件加載順序符合業務需求
EMQX 重啟後會自動加載上次啟動時已加載的插件，插件加載順序會被打亂
後續的維護使用中無法感知鏈的順序
EMQX 5.0 針對以上問題進行了優化：按照配置順序從上到下依次加載並執行認證器與授權檢查器，用戶可以從配置層面實現順序的控制。
同時我們提供了 Dashboard 與 REST API，允許通過拖拽、上下移動的方式調整認證器和授權檢查器的順序，確保符合業務需求。
實現認證授權可觀測性
EMQX 5.0 提供了認證授權統計指標，可以分別統計集群總和以及單個節點上認證器和授權檢查器的執行情況，包括以下數據：
成功數：認證或授權檢查通過數
失敗數：認證或授權檢查失敗數
不匹配：沒有找到用戶憑證或權限列表的次數
當前速度：當前執行速度
通過認證授權統計指標，用戶可以及時發現如大量的失敗認證/授權檢查，及時感知安全系統的異常情況。
為監聽器配置另外一種認證方式
默認情況下 EMQX 所有監聽器接入的客戶端都使用同一種認證方式，從同一個認證數據源中讀取數據。
但在同時接入多個服務的 EMQX 集群中，用戶可能需要根據業務不同為每種接入方式配置不同的認證方式，比如：
通過 MQTT over WebSocket 接入的客戶端不會頒發永久的用戶名密碼憑證，而是使用具有時效性的 JWT 進行認證以確保業務安全；
通過 MQTT TCP 接入的硬件設備會在初始化時燒錄用戶名密碼或客戶端證書，該認證憑證在整個生命周期中不會變化，可以使用密碼認證；
用於後端服務連接的監聽器不需要認證檢查，此監聽器通常監聽於內網地址有足夠的安全性。
EMQX 5.0 允許為指定監聽器設置另外一種認證方式，或者關閉某個監聽器的認證檢查，以便靈活的適應各類認證需求。
全局共用一個認證方式能夠滿足絕大多數場景的客戶端認證需求，對於大多數用戶監聽級別的認證設置是無感的，有需要的用戶只需在監聽器中配置即可。
結語
留言列表