MQTT 帳密認證夠安全嗎？三層防禦架構完整解析（含 Mosquitto 實戰配置）

47,000 個 MQTT broker 正在裸奔——這個數字其實還是低估

47,000。這是目前公開資料中、被 Shodan 掃出來無認證、可直接連線的 MQTT broker 數量。這數字背後是真實的能源廠、醫院、車隊管理系統、智慧家居中控、甚至監視器影像串流——任何人開個瀏覽器、裝個 MQTT 用戶端，就能即時看到這些裝置在傳什麼資料、甚至下指令叫它們做事。

你開始接觸 ESP32、想把感測器資料丟上雲的那一刻，這個 47,000 就有可能多 1。如果你照著 YouTube 教學影片把 Mosquitto 裝起來、開個 1883 port、設個 admin/admin 帳密就上線，你的裝置會在十幾分鐘內被掃到，真正的原因是自動化掃描工具每秒會掃 36,000 個端點，這是 SonicWall 2026 Cyber Protect 報告 公開的全球資料。

這篇文章想做的事很單純——把「MQTT broker 到底是什麼」「光靠帳密為什麼不夠」「TLS / 認證 / 授權三層防禦怎麼疊」一次講清楚，並附上一份 Mosquitto 最低安全配置可以直接抄。寫這篇是因為一個朋友剛開始碰 IoT，問了我四個問題：

• MQTT broker 是不是像後端 API？

• 光有帳密夠安全嗎？

• broker 連到資料庫會被一路打穿嗎？

• 如果裝置上的私鑰會讓主程式讀到，還算安全嗎？

這四個問題其實就是 IoT 通訊安全的整個地圖。後面三層防禦的拆解，就是在回答這些。讀完這篇，你會知道為什麼 IoT 安全的入場門檻不是「裝個密碼」，以及為什麼有經驗的工程師看到「公網 IP + 1883 + 預設密碼」會直接搖頭。

MQTT broker 到底是什麼？跟後端 API 有什麼差別

把 MQTT broker 理解成「後端服務」其實有點對、又不全對。最精準的比喻是——MQTT broker 是郵局的中繼站，不是業務窗口。它負責收發訊息、按照「主題（topic）」把信件丟給訂閱者，但不處理業務邏輯、不直接接資料庫、也不對訊息內容做判斷。

傳統後端 API 的角色比較像「業務窗口」：你打 POST /orders，後端會驗 token、檢查欄位、寫進資料庫、回應結果，整個流程是同步的、有業務含意。MQTT broker 則是另一個世界——上千台 ESP32 同時 publish 溫度資料到 `factory/line1/temp` 這個 topic，broker 只負責把這份資料複製給所有訂閱了這個 topic 的客戶端，包括你的後端服務、Dashboard、警報系統。

這個結構叫做 publish/subscribe（發布訂閱）。它跟 HTTP request/response 最大的差別有三點：

為什麼這個差別很重要？因為很多人會以為「broker 在那邊就是個服務，跟我的 Node.js / Python API 一樣加個 JWT 就好了」。實際上 broker 的安全模型完全是另一回事：它預設沒有 session 觀念、沒有 CORS、認證機制非常陽春、ACL（存取控制清單）需要另外一個檔案管理。它本質上是「網路中的訊息匯流排」，不是業務伺服器。

純帳密為什麼是安全災難：三大攻擊手法拆解

你問「光是帳號密碼夠安全嗎」，這個直覺其實是對的——大部分情況下不夠。真正的問題在於 MQTT 帳密機制本身少了三個現代 web 應用視為理所當然的東西：傳輸加密、頻率限制、與細粒度權限控制。少了這些，帳密就像是把家裡的鑰匙放在門墊下面——技術上有鎖，但實際上沒擋住任何人。

攻擊手法一：明文嗅探

MQTT 預設用 1883 port，通訊內容完全明文。這代表只要有人能在中間看到網路封包——例如同一個 WiFi、同一個區網、或在 ISP 路由的某一段——就能直接看到：

• 客戶端送出的 username 和 password（CONNECT 封包裡的明文欄位）

• 所有 publish 的訊息內容（溫度、座標、影像 URL、控制指令）

• 所有訂閱的 topic 名稱（揭露你的系統架構）

有研究團隊在 MQTT broker 的安全評估報告 中明確指出：MQTT 服務在 1883/TCP 上是不加密的，因此即使 broker 有設帳密，傳輸過程仍會洩漏。換句話說——沒有 TLS 的 MQTT，帳密本身就是流動的明文。攻擊者抓一次封包就拿到了。

攻擊手法二：暴力破解與字典攻擊

MQTT 的 CONNECT 封包重連成本極低——TCP 三次握手 + CONNECT + CONNACK，整個過程毫秒級。這意味著如果 broker 沒有做失敗次數限制（rate limiting），攻擊者可以每秒嘗試上百次帳密組合。

更可怕的是 IoT 圈有大量公開的「常見預設密碼字典」。Mirai botnet 在 2016 年讓 Netflix、Twitter、GitHub 同時下線，靠的就是 62 組常見預設帳密，掃了上百萬台 IoT 裝置——admin/admin、root/root、user/user 這種。這份字典今天還在被用，而且每年都在更新。如果你的 broker 帳密是「mqtt/mqtt」「user/password123」這種，幾分鐘內會被試出來。

攻擊手法三：權限亂跳（缺乏 ACL）

假設攻擊者真的拿到了一組合法帳密——可能是字典攻擊試出來、可能是某台 ESP32 被偷了拆出 flash、可能是內部員工外洩。沒有 ACL 的話，這組帳密可以對任何 topic 做任何事：

• subscribe 到 `factory/+/control`，看到所有產線的控制指令

• publish 到 `factory/line1/control/shutdown`，下一條停機指令

• publish 到 `cameras/+/firmware/update`，推一個惡意韌體 URL 出去

一台 ESP32 的帳密外洩，等於整個 IoT 系統被打穿。Verkada 在 2021 年發生的監視器入侵事件就是類似的概念——一組超級管理員密碼讓駭客存取了 150,000 台監視器的即時畫面，包含學校、醫院、特斯拉工廠。權限沒有切細的代價，就是這麼大。

三層防禦架構：傳輸加密 + 認證 + 授權

看完上面三個攻擊手法，三層防禦的邏輯就很清楚了——分別擋住「嗅探」「破解」「橫向移動」這三件事。這個架構不是 MQTT 獨有的概念，整個現代 web 安全都是這樣疊的，只是 MQTT 的實作位置不太一樣。

先看一張總覽表：

Layer 1：TLS——把通道封死

TLS（過去叫 SSL）就是 HTTPS 上「掛鎖那個小圖示」背後的技術。對 MQTT 來說，啟用 TLS 後幾件事會同時發生：

• 客戶端與 broker 之間的所有封包加密，中間人抓到也是亂碼

• 客戶端會驗證 broker 的憑證，避免連到偽造的假 broker

• Port 從 1883 換成 8883（業界慣例，非強制）

注意一件事：TLS 不會幫你做「認證使用者」，它只負責「加密通道」。所以 TLS + 弱密碼仍然會被字典攻擊試出來——TLS 只是把暴力破解的成本提高一點點（因為連線稍微慢），擋不住會自動重連的攻擊腳本。下一篇 B2 會專門拆解 ESP32 上 TLS 的實作細節，特別是時間同步、CA 憑證載入、mTLS（雙向驗證）這些容易卡住的點。

Layer 2：認證——broker 怎麼知道你是誰

MQTT 內建的認證有三種主流做法，從弱到強：

這篇先把帳密 + TLS 這條線打好，後面三篇會把進階的方案講透。重點先記住一句話——broker 端永遠要 disable 匿名連線，這是 Mosquitto 預設居然允許匿名的設定，所有教學文章都該明確強調的事。後面 mosquitto.conf 範例會把這條補上。

Layer 3：授權（ACL）——你能對哪些 topic 做什麼

ACL（Access Control List）是 MQTT 安全裡最容易被忽略、卻最重要的一層。它回答的問題是：

• 這個帳號可以 subscribe 哪些 topic？

• 這個帳號可以 publish 到哪些 topic？

• topic 可以用 pattern matching（例如 `factory/+/temp` 但不能 `factory/+/control`）嗎？

好的 ACL 設計遵循「最小權限原則（Principle of Least Privilege）」——每台 ESP32 只能 publish 自己負責的 topic、只能訂閱自己需要的指令 topic。這樣即使單台裝置淪陷，攻擊者也只能影響那一個範圍，不會擴散到整個系統。

Mosquitto 的 ACL 邏輯有個重要的預設值要記住——沒有明確 allow 的 topic，預設是 deny。也就是說 ACL 裡寫一條「user1 可以 read factory/line1/#」，就等於 user1 對其他所有 topic 都不能讀寫。這個 deny-by-default 的設計是好的，但意味著你必須把每一條規則都明確寫出來，漏掉一條就是某個功能壞掉。

Mosquitto 最低安全配置實戰（可以直接抄）

把上面三層防禦寫成 Mosquitto 設定檔，最低限度長這樣。這份配置適合 development 到小規模 production，不包含 mTLS（那是 B2 的範圍），但已經能擋掉 95% 的常見掃描攻擊。

步驟一：產生 TLS 憑證

用 openssl 自簽憑證，dev 環境足夠用。production 強烈建議用 Let's Encrypt（免費）或內部 CA：

# 1. 建立 CA
openssl genrsa -out ca.key 2048
openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 \
  -out ca.crt -subj "/CN=My MQTT CA"

# 2. 為 broker 產生 server 憑證
openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr \
  -subj "/CN=mqtt.yourdomain.com"
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -out server.crt -days 365 -sha256

# 3. 把憑證放到 mosquitto 目錄
sudo mkdir -p /etc/mosquitto/certs
sudo cp ca.crt server.crt server.key /etc/mosquitto/certs/
sudo chown mosquitto:mosquitto /etc/mosquitto/certs/*
sudo chmod 640 /etc/mosquitto/certs/server.key

步驟二：建立帳號密碼檔

# 建立第一個使用者，會互動式問密碼
sudo mosquitto_passwd -c /etc/mosquitto/passwd factory_sensor_01

# 之後新增使用者不要用 -c（會覆蓋整個檔案）
sudo mosquitto_passwd /etc/mosquitto/passwd dashboard_reader
sudo mosquitto_passwd /etc/mosquitto/passwd backend_writer

步驟三：寫 ACL 檔（最關鍵的一步）

# /etc/mosquitto/acl
# 用最小權限原則：每個帳號只能碰自己該碰的 topic

# 工廠感測器 - 只能 publish 自己的資料
user factory_sensor_01
topic write factory/line1/sensor01/+

# Dashboard - 只能讀，不能寫任何控制 topic
user dashboard_reader
topic read factory/+/+/+
topic deny factory/+/+/control

# 後端服務 - 寫控制指令、讀所有資料
user backend_writer
topic readwrite factory/#

步驟四：mosquitto.conf 主設定檔

# /etc/mosquitto/mosquitto.conf
# === 安全基線：明確 disable 匿名 ===
allow_anonymous false
password_file /etc/mosquitto/passwd
acl_file /etc/mosquitto/acl

# === 關掉明文 1883，只開 TLS 8883 ===
# 注意：不要 listen 1883，否則攻擊者直接走明文
listener 8883
protocol mqtt

cafile /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/server.crt
keyfile /etc/mosquitto/certs/server.key

# require_certificate true 就是 mTLS（B2 會講）
# 這裡先用 false，純 TLS + 帳密
require_certificate false

# === 防 DoS 與資源限制 ===
max_connections 1000
max_inflight_messages 20
max_queued_messages 1000
message_size_limit 8192

# === 記錄 log，事後可追 ===
log_dest file /var/log/mosquitto/mosquitto.log
log_type error
log_type warning
log_type notice
log_type information
connection_messages true
log_timestamp true

步驟五：重啟並驗證

sudo systemctl restart mosquitto
sudo systemctl status mosquitto

# 驗證 TLS 連線是否正常
mosquitto_pub -h mqtt.yourdomain.com -p 8883 \
  --cafile ca.crt \
  -u factory_sensor_01 -P 'your_password' \
  -t 'factory/line1/sensor01/temp' -m '23.5'

# 驗證 ACL 真的有擋（這條應該失敗）
mosquitto_pub -h mqtt.yourdomain.com -p 8883 \
  --cafile ca.crt \
  -u dashboard_reader -P 'your_password' \
  -t 'factory/line1/sensor01/control/shutdown' -m '1'
# 預期：not authorized 或被 broker 默默丟棄

帳密之外還能做什麼？mTLS 與每裝置 PKI 的進階方向

把上面那份 mosquitto.conf 配好，已經擋掉了絕大部分自動化掃描與隨機嘗試。但如果你的場景是工業控制、醫療裝置、車載系統、或任何「裝置被入侵會出人命」的應用，三層防禦只是地基，還需要兩個進階機制——

這三件事會在後續文章拆解：

• B2 篇：ESP32 + TLS 從單向到 mTLS 完整實作（含程式碼）

• B3 篇：MQTT broker → 後端 API → 資料庫 的權限隔離架構

• B4 篇：工業級每裝置 PKI + Secure Element（ATECC608A）完整指南

為什麼要分開寫？因為每一層都有自己的故障模式與部署成本。一篇全塞會變成沒人看得完的天書。先把基礎打穩，後面再依場景升級——這也是大部分 IoT 系統實際走過的路徑。

從 broker 到資料庫：為什麼不能直接打通

回到你問的第二個問題後半——「從 MQTT broker 直後就可以暢行無阻直接進到後端資料庫嗎？」答案是：理論上可以，但實務上不應該。先看兩種架構的對比：

為什麼後者比較安全？因為「broker → API → DB」這個架構讓broker 只負責訊息中繼，後端 API 才是業務閘道。即使 ESP32 帳密被偷，攻擊者最多能丟假資料進來——但後端 API 會驗證資料合理性（溫度怎麼可能 999 度？），會做 rate limiting，會記 audit log，最後決定要不要寫進資料庫。整個攻擊面被壓縮成一個小鎖頭。

這個架構也讓「資料庫的存取憑證」永遠不出後端 API 的環境變數——broker 不知道、ESP32 不知道、攻擊者偷到任何一台裝置都拿不到。實際的雲端部署架構，可以參考我們寫過的 K3s 輕量級 Kubernetes 完整介紹，K3s 跟 IoT 邊緣運算的搭配是目前很主流的組合。如果你想看完整的 Kubernetes 容器編排概念，Kubernetes 是什麼 那篇有講核心架構。

常見錯誤與排查清單

接觸 MQTT 安全配置的前兩週，幾乎每個人都會踩這幾個雷。整理出來方便你對照——出事了先看這張表：

從架構到落地——選 broker、選雲、選團隊的考量

讀到這裡你會發現一件事——MQTT 安全本身不難，難在「整套系統都要做對」才能擋住威脅。實務上有三個選擇會大幅影響你的安全姿態：

選擇一：自架 broker vs 用雲服務

自架 Mosquitto 成本最低（一台 VPS 加一個域名），自由度最高，但所有安全責任都在自己身上——憑證更新、ACL 維護、log 監控、版本升級。雲服務（HiveMQ Cloud、AWS IoT Core、EMQX Cloud）成本高一點，但安全機制是內建的：自動 TLS、自動 rate limiting、有 IAM 整合。

中小規模建議用雲服務，把安全責任部分外包；大規模或有合規需求才自架。如果你的後端已經跑在 PaaS 上，Vercel、Railway、Render、Zeabur、Fly.io 五大 PaaS 平台完整比較 這篇有對應的選型指南，可以參考類似的決策框架。

選擇二：邊緣運算 vs 純雲端

如果裝置數量很多、或網路不穩定，broker 部署在邊緣（工廠內部、店內 Edge Server）會比全部走雲端更穩。這時 K3s 這種輕量化 Kubernetes 是常見選擇——可以同時跑 broker、本地 API、本地 cache，斷網也能繼續運作。

選擇三：自己團隊做 vs 找系統開發合作

純做硬體上雲、感測器資料 dashboard 這類標準需求，自己團隊照著教學摸索就能做起來。但如果要把 IoT 資料整合進 ERP、報價系統、客服系統，整個資料流要設計、權限要切、稽核要做，這是另一個層級的工程。如果你正在評估這類整合需求，可以看 系統開發服務 怎麼處理跨系統資料流；想看 AI 整合到傳產的實際案例，AI 接 ERP 的 4 個關鍵與實作架構 這篇拆解得比較完整。

MQTT 安全常見問題 FAQ

結語：把基礎打穩，後面才走得快

回頭看這篇文章想做的事——把「MQTT broker 是什麼」「光帳密為什麼不夠」「三層防禦怎麼疊」「Mosquitto 怎麼配」一次說清楚。把這些做對，已經能擋掉 95% 的自動化掃描攻擊，是任何 IoT 系統的入場門檻，不是進階要求。

接下來這個系列會繼續往深處走：

• B2 篇 → ESP32 上 TLS 從單向到 mTLS 完整實作，含程式碼與常見排錯

• B3 篇 → broker → 後端 API → 資料庫 的隔離架構與權限設計

• B4 篇 → 工業級 PKI 與 Secure Element，每裝置一把私鑰的完整方案

最後一句話——IoT 安全必須在設計階段就規劃好，等寫完程式才補就來不及了。從第一台 ESP32 開始就把 TLS、ACL、權限隔離做對，比之後出事再回頭補容易十倍。希望這篇 cluster 起點能幫你建立正確的安全直覺，後面三篇會把實作細節一塊塊填滿。