工廠資料不想上雲，但主管又想在外面看，這個矛盾怎麼解？

工廠鬼話

業務： 使用我們的雲端，不用怕資料不見，而且傳輸很快。

客戶主管： 但我們不想把工廠資料放在網路上。

業務： 別擔心，我們有加密。資料雖然存在雲端，但沒有人看得到貴公司的資料。

客戶主管內心： 我當然知道檔案放哪裡不一定是我的問題。最好放雲端，我也不用管主機、備份和維護。問題是老闆很傳統，根本說服不了他。

客戶老闆： 不行。產線資料不能放在雲端，也不能放在別人的儲存裝置上。你們能 100% 保證嗎？出事有保險嗎？

客戶老闆內心： 用你們雲端，不能 100% 保證，還要每年收費。資料放越久，不就越離不開你們？

業務： 這部分我回去再跟公司談一下方案。

客戶老闆： 另外，我既然用了這套系統，我人在外面，或是廠長人在外面，也要能收到通知。這你們能做到嗎？

業務內心： 如果不要雲端，那就是本地；可是純本地又要怎麼讓外面收到？

業務： 我回去跟 RD 確認一下。

整合商或系統供應商幾乎不可能替客戶的工廠資料做無限責任保證。若真的要把資料遺失、外洩或服務中斷做成保險，那會變成另一套商業合約、資安稽核與成本分攤，不是簡單一句「資料有加密」就能解決。

所以 CH20 要處理的不是「雲端好不好」，而是另一個更現實的問題：工廠資料不想放到雲端倉庫，但外部 APP 和通知仍然要找得到本地系統。 CloudOwl 的價值就在這裡：它不是倉庫，而是外部連線的路由入口。

課程地圖

圖解：本章在 LocalNest 架構中的位置

圖解：外網 APP 查本地歷史資料的往返路徑

20-1 本地優先的外網困境

工廠廠長出差，想在手機上看設備狀態，或希望人在外面時仍然收到 APP 通知——這個需求不合理嗎？完全合理。

但如果 LocalNest 是純本地方案，手機在 5G 網路上，完全進不去工廠的區域網路，什麼 APP 都沒用。

集團底下三個廠，分別在不同縣市，各有一台 LocalNest。

總部 IT 需要統一看三個廠的設備狀態——純本地方案沒辦法跨廠聚合資料。

這些不是邊緣案例，是製造業的日常。

本地優先系統必須有辦法處理外網需求，否則只是把雲端鎖定換成了本地孤島。

20-2 CloudOwl 的角色：路由，不是倉庫

本章只處理一件事：本地優先系統為什麼仍然需要一個雲端路由層。

連線型態矩陣會在 CH21 整理；帳號可見範圍與跨站查詢，

會留到 CH22 與 CH23 再完整展開。

傳統雲端依賴型系統，是指設備資料先集中送到雲端，APP 再查雲端資料庫。

這類架構不是不能用，現代雲端平台也通常很穩定；

問題在於很多工廠不希望生產資料、設備資料或能耗資料長期離開現場。

這一點要回扣 ch02 2-5「資料庫放在哪裡，責任就在哪裡」：不是雲端一定不可靠，

而是資料主權、內網隔離、保密制度與客戶 IT 政策不一定允許所有資料都上雲。

CloudOwl 的職責被刻意限縮到兩件事：連線路由（讓外網 APP 找得到 LocalNest）和授權狀態溝通。

授權機制會在 CH24 再展開；本章先知道它不是資料倉庫，也不是把 LocalNest 變成雲端資料庫。

CloudOwl 不存歷史資料，它是「路」，不是「倉庫」。

20-3 不需要固定 IP、不需要開對內連線

工廠要讓外網能存取內部設備，傳統做法都有問題：

申請固定 IP（有費用也要 IT 配合）、
VPN（使用者端要裝連線工具）、
通訊埠轉發（Port Forwarding，把外部連線導進工廠內部）。

CloudOwl 的答案是利用 MQTT 特性做反向連線。

LocalNest 啟動後先連到 CloudOwl；

這條連線建立後，雙方可以在同一條持續連線上收送訊息。

白話說，不是外面的 APP 直接敲工廠內部的大門，而是工廠內的 LocalNest 先打電話到 CloudOwl；這通電話接通後，CloudOwl 才能沿著同一條線把外部 APP 的請求轉回 LocalNest。

外網 APP 不需要直接打進工廠內部，而是先連到 CloudOwl，

再由 CloudOwl 透過已建立的 MQTT 通道把請求轉給 LocalNest。

這裡先不深入 MQTT 的協定細節，也不把原生程式的 topic 寫進主線。

讀者先抓住一件事就好：反向連線不是魔法，而是把「誰先建立連線」和「訊息如何在既有通道上往返」設計清楚。

MQTT 的基本理解可至 EX02 查看；若要對照 LocalNest 原生 topic 與實作範例，可至 SP01 查看。

這裡要先定義兩個網路方向：

• 對外連線：工廠內的 LocalNest 先連到 CloudOwl。
• 對內連線：外部網路主動打進工廠內部設備。

CloudOwl 的關鍵是讓 LocalNest 主動往外連到 CloudOwl 的 9102 通訊埠。

工廠防火牆只需要允許這條對外連線，不需要讓外部網路主動打進 LocalNest。

外網 APP 連的是 CloudOwl 的固定入口，LocalNest 的 IP 不需要直接暴露到外部。

兩端都不需要固定 IP：

• LocalNest 端：它是先建立對外連線的一方；CloudOwl 從 MQTT client ID 取得 LocalNest 的 T_U_UUID，並對照 CloudOwl 的授權名單，不靠來源 IP。授權流程會在 CH24 再展開。
• APP 端：APP 連的是 CloudOwl 的固定 IP，APP 自己的 IP 不重要

CloudOwl 在這條路徑負責 MQTT 連線、授權名單與訊息轉送；使用者帳號、密碼與 Token 驗證由 LocalNest 的 ExpandEntrance 與 SystemInformationManager 處理。

只有 CloudOwl 服務端需要固定入口。CloudOwl 要架在哪個雲端平台，不是 LocalNest 架構綁死的事：

可以放 AWS、Microsoft Azure、Google Cloud、客戶自己的雲端主機，

也可以放在系統供應商代管的雲端環境或客戶自管機房。

選哪一種，要看客戶的資安政策、維運能力、地區網路品質與成本。

20-4 工廠老闆最在意的安全論點

工廠老闆或管理者最在意的，通常不是雲端技術本身，

而是：「我的生產資料、設備狀態、能耗資料會不會被 CloudOwl 長期保存成另一份雲端資料庫？」

答案是不會。CloudOwl 不持久化這些歷史資料。

外網查詢時，APP 的請求與 LocalNest 從本地資料庫取出的回應仍會經過 CloudOwl 轉送；差別在於 CloudOwl 不把回應資料累積成自己的歷史資料庫，正式資料保存責任仍在 LocalNest。

即使 CloudOwl 暫時中斷，本地資料收集、歷史統計、警示判斷等現場功能仍然在 LocalNest 內繼續運作，受影響的是外網 APP 暫時連不進來。

這個論點通常比「雲端服務很安全」更容易讓工廠接受，

因為它回到老闆真正關心的事：生產資料、設備資料與能耗資料不需要長期放到外部雲端倉庫。

20-5 加密責任邊界

CloudOwl 和外部架構解決的是「外網怎麼找到本地 LocalNest」以及「資料主權仍在現場」的問題，不代表所有企業資安要求都已經自動滿足。

系統可以設計成兩端加密：LocalNest 回應 APP 查詢時，先把回傳資料加密後再送出；APP 端收到後再解密。也就是說，

歷史查詢資料不一定只能用明文傳輸，導入時可以依客戶資安要求啟用或強化這一層保護。

但這和「整條網路通道已經符合企業級加密政策」不是同一件事。

LocalNest / CloudOwl 預設主線仍以 MQTT 與本地網路架構說明為主；

若案場要求更高的資安等級，導入方仍要依現場 IT 規範補強：

• MQTT 是否要啟用 TLS 加密、帳號密碼或憑證驗證。
• REST API 是否要改走 HTTPS，也就是設定 SSL/TLS 憑證。
• 防火牆規則是否只允許必要來源、必要通訊埠、必要方向。
• 憑證到期、金鑰輪換、Log 留存與稽核責任由誰維護。

簡單說：CloudOwl 解決外網入口問題；資料加密、憑證、通道加密、金鑰輪換與稽核，要依每個現場的 IT 規範另外設計。
這不是系統不重視安全，而是資安要求會跟客戶內網、雲端平台、憑證政策、法規與維運能力綁在一起，不能用一套固定設定假裝全部適用。