引言：多種防護機制保障物聯網安全

全球物聯網發展至今，網絡環境日益龐大和複雜，物聯網系統與服務的安全性面臨着更加嚴峻的挑戰。同時，各企業物聯網業務的快速擴張，也要求底層的基礎設施服務具有極高的穩定性與可靠性。

作為全球領先的物聯網 MQTT 消息服務器，EMQX 針對物聯網安全擁有完整的解決方案，通過開箱即用的功能、符合行業和國家安全及質量標準的設計、針對企業安全場景需求的電信級產品架構和獨有安全技術，助力用户構建安全健壯的物聯網平台與系統。

本文將對 EMQX 5.0 所採用的各類安全保障機制與功能進行詳細介紹，幫助用户瞭解 EMQX 如何保障物聯網安全。

SSL/TLS 體系保障通信安全

作為消息中間件，保證通信的安全性是最基本也是最核心的問題。傳統的 TCP 通信因為使用明文通信，信息的安全性很難得到保證，面臨以下風險：

• 竊聽： 信息以明文傳播，攻擊者可以直接獲取敏感信息
• 篡改： 攻擊者截獲信道後，可以隨意篡改通信內容
• 偽造： 同上，攻擊者可能會將偽造的數據隱藏在真實的數據之中，危害更加隱蔽
• 冒充： 攻擊者假冒身份，與另一方進行通信

SSL/TLS 的出現很好的解決了通信中的風險問題，其以非對稱加密技術為主幹，混合了不同模式的加密方式，既保證了通信中消息都以密文傳輸，避免了被竊聽的風險，同時也通過簽名防止了消息被篡改。

EMQX 提供了豐富和完善的 SSL/TLS 支持，包括：單向、雙向、X.509 證書、負載均衡 SSL、TLS-PSK 等多種認證方式，用户可以根據自己的實際場景選擇合適的方式進行接入。通過 SSL/TLS 技術，EMQX 能夠確保客户端數據傳輸、集羣節點間通信、企業系統集成的數據傳輸安全。

EMQX 還支持將國密算法用於傳輸過程加密。國密 SSL 在提供更高安全性能的情況下，能夠保持較低的資源開銷和更快的傳輸速度。EMQ 提供了基於國密算法的傳輸加密認證集成方案，可應用於車聯網、金融銀行、教育、通信、國防工業等各類重要領域的物聯網信息系統中。詳情請見《國密在車聯網安全認證場景中的應用》。

SSL/TLS 介紹

TLS/SSL 協議下的通訊過程分為兩部分。

第一部分是握手協議，握手協議的目的是鑑別對方身份並建立一個安全的通訊通道。握手完成之後雙方會協商出接下來使用的密碼套件和會話密鑰。

第二部分是 record 協議，record 和其他數據傳輸協議非常類似，會攜帶內容類型、版本、長度和荷載等信息，不同的是它所攜帶的信息是已加密的。

下圖展示了 TLS/SSL 握手協議的過程，從客户端的 "hello" 一直到服務器的 "finished" 完成握手。

自簽名證書單向認證配置

數字證書體系當中除了通訊雙方，還有一個頒發證書的受信第三方 CA，一個真正受外界信任的證書需要到證書服務提供商進行購買。

而在內部通信時，可以使用自簽名的證書。而在大多數場景下，單向認證的安全性是足夠可靠的，且部署更加方便。在 EMQX 5.0 中使用自簽名證書配置客户端 SSL/TLS 進行單向認證連接的步驟如下：

證書準備

為自簽名的 CA 證書準備一份私鑰。

openssl genrsa -out ca.key 2048

通過這份私鑰來生成一份 CA 證書。

openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 -out ca.pem

有了 CA 證書後，我們需要通過該證書對服務器/域名進行認證，同樣先準備服務器私鑰。

openssl genrsa -out emqx.key 2048

然後準備一份證書請求配置，用於生成證書請求文件。

[req]
default_bits = 2048
distinguished_name = req_distinguished_name
req_extensions = req_ext
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
countryName = CN
stateOrProvinceName = Zhejiang
localityName = Hangzhou
organizationName = EMQX
commonName = CA
[req_ext]
subjectAltName = @alt_names
[v3_req]
subjectAltName = @alt_names
[alt_names]
IP.1 = 127.0.0.1

生成請求文件。

openssl req -new -key ./emqx.key -config openssl.cnf -out emqx.csr

最後通過之前生成的 CA 私鑰、證書和該請求文件，對我們的服務器進行簽名。

openssl x509 -req -in ./emqx.csr -CA ca.pem -CAkey ca.key -CAcreateserial -out emqx.pem -days 3650 -sha256 -extensions v3_req -extfile openssl.cnf

配置 EMQX

將生成好的 emqx.key、emqx.pem、ca.pem 拷貝到 EMQX 的 etc/certs 目錄內，然後將 emqx.conf 中的 ssl 配置修改如下：

listeners.ssl.default {
  bind = "0.0.0.0:8883"
  max_connections = 512000
  ssl_options {
    keyfile = "etc/certs/emqx.key"
    certfile = "etc/certs/emqx.pem"
    cacertfile = "etc/certs/ca.pem"
  }
}

使用 MQTT X CLI 測試

啓動 EMQX，然後使用 MQTT X CLI 進行連接測試：

# 使用服務器證書中的地址和端口進行連接
mqttx-cli conn -l mqtts -h 127.0.0.1 -p 8883 --ca ca.pem
# Connected
# 使用非法的地址進行連接
mqttx-cli conn -l mqtts -h 0.0.0.0 -p 8883 --ca ca.pem
# Error [ERR_TLS_CERT_ALTNAME_INVALID]: Hostname/IP does not match certificate's altnames: IP: 0.0.0.0 is not in the cert's list: 127.0.0.1

在這個演示中，客户端通過 CA 證書對服務器的證書進行驗證，只有服務器證書合法可靠的情況下，雙方才會建立加密通信信道，保證了通信的安全性。

如果需要更高的安全性，確保客户端和服務器都是可信的，建議使用可靠的 CA 機構對客户端和服務器都部署證書，通信時進行雙向認證，詳情可以參考 EMQX 啓用雙向 SSL/TLS 安全連接

認證授權

通信安全只是整個系統安全保障中的第一步。大多數情況下，一個能夠通過雙向認證的受信客户端，並不一定滿足登錄條件，即使滿足登錄條件，某些場景下可能也需要對其行為進行限制。

針對這些複雜的認證和授權需求，EMQX 提供了易於使用和部署的、開箱即用的解決方案。特別是在最新發布的 EMQX 5.0 中，內置實現了客户端認證授權功能：用户通過簡單配置，無需編寫代碼即可對接各類數據源與認證服務，實現各個級別與各類場景下的安全配置，以更高的開發效率獲得更安全的保障。

詳細內容請見：《靈活多樣認證授權，零開發投入保障 IoT 安全》

過載保護

在 EMQX 4.x 中，出於系統穩定性的考慮，當某個會話的負載達到了設置的閾值後，EMQX 會主動踢掉該會話。這部分功能在 5.0 版本中得到了延續和加強。

用户如果希望修改強制關閉的策略，可以在 emqx.conf 中增加如下配置:

force_shutdown {
  enable = true
  max_message_queue_len = 1000 # 會話進程消息隊列的最大長度
  max_heap_size = "32MB" # 會話進程的最大堆內存大小
}

另外在 EMQX 5.0 中，我們引入了過載保護的概念，當 EMQX 判斷系統處於高負載時，會通過關閉部分功能(具體見下面的配置示例)的方式，來維持服務的整體可靠性。

過載保護功能默認關閉，用户如果需要可以在 emqx.conf 中添加如下配置：

overload_protection {
  enable = true
  backoff_delay = 10 # 過載時，不重要的任務將會被延遲 10s 處理
  backoff_gc = true # 過載時，允許跳過強制 GC
  backoff_hibernation = true # 過載時，允許跳過休眠
  backoff_new_conn = true # 過載時，停止接收新的連接
}

速率控制

EMQX 5.0 引入了一套精度更高的、全新的分層速率控制系統，分別支持從節點、監聽器、連接三個層級 來控制資源的消耗速度，能夠確保系統按照用户預期的負載運行。

連接層級

連接級的速率限制針對的是單個連接，假設需要限制通過 1883 端口接入的每個會話的消息流入速度為每秒 100 條， 則只需要在 emqx.conf 中將 1883 端口配置修改如下:

listeners.tcp.default {
  bind = "0.0.0.0:1883"
  max_connections = 1024000
  limiter.client.message_in {
    rate = "100/s"
    capacity = 100
  }
}

監聽器級

監聽器級針對的是通過某個端口接入的所有會話的總和速率限制，比如希望所有通過 1883 端口接入的會話， 在每秒產生的消息輸入總和不超過 100 條，則可以將配置修改如下：

listeners.tcp.default {
  bind = "0.0.0.0:1883"
  max_connections = 1024000
  limiter.message_in {
    rate = "100/s"
    capacity = 100
  }
}

節點級

節點級控制的是當前節點上的資源消耗速度，假如希望限制當前節點每秒流入的消息數量不超過 100 條，則 可以在 emqx.conf 中加入如下配置：

limiter.message_in.rate = "100/s"

注：因為節點級影響範圍最廣，目前的設計比較保守，只會影響到設置了速率限制的監聽器，如果監聽器上沒有速率相關設置，則不受該配置影響。

黑名單系統

在某些情況下，一些客户端可能因為網絡或者認證問題，出現不斷重複的 “*登錄-斷開-重連*” 這種模式的異常行為。對此 EMQX 提供了簡單的異常登錄防禦，支持自動封禁這些被檢測到短時間內頻繁登錄的客户端，並且在一段時間內拒絕這些客户端的登錄，以避免此類客户端過多佔用服務器資源而影響其他客户端的正常使用。

此功能默認關閉，用户可以在 emqx.conf 配置文件中添加如下配置進行開啓:

flapping_detect {
  enable = true
  # 客户端最大離線次數
  max_count = 15
  # 檢測的時間範圍
  window_time = "1m"
  # 封禁的時長
  ban_time = "5m"
}

不停機熱更新/升級

得益於 Erlang/OTP 的原生熱加載支持，以及 EMQX 設計良好的熱更新流程，在大多數情況下，EMQX 都可以做到無縫、平滑、不停機、不暫停業務的實時熱更新，在保證系統安全的修復 Bug 的同時，也確保了服務的穩定性和可靠性。

結語

本文簡單介紹了 EMQX 內部保障通信、系統運行等功能的安全基礎組件，這些組件不僅設計優良，還具有足夠的深度和延展性，為用户打造可靠、可信、安全且健壯的物聯網系統奠定了良好的基礎。

未來 EMQX 依然會持續關注物網絡安全問題，從實際應用場景出發，不斷優化和增強各個安全組件，為物連網生態發展提供有力的安全保障。

版權聲明： 本文為 EMQ 原創，轉載請註明出處。

原文鏈接：https://www.emqx.com/zh/blog/how-to-ensure-the-security-of-the-iot-platform