雲端時代的IoT(物聯網)

現今IoT裝置已充斥在我們的生活周遭了，Gartner預估到了2030年，全球將有300億個IoT裝置。而這麼多的裝置將會產生非常大量的資料。我們將如何管控這麼多的IoT裝置還要接收並處理這一類大量的資料呢?幸運的是多數的雲端供應商(以下簡稱CSP)提供了這一類的解決方案，不用讓企業從頭建立起這一類的IoT管理平台。本文將介紹這一類的解決方案與IoT中重要的元素，如網路連接與資安等。

本文介紹的重點如下:

• 選擇正確的IoT平台
• IoT系統的監控
• 設計連接到雲端的網路
• IoT的網路— IPv6, LoRA與5G

選擇正確的網路平台

現在的裝置本身只要有網路元件(藍芽、Wi-Fi、4/5G等)可以連接上網的都可以稱做IoT設備。這一類的設備可以是機器或是裝置本身帶有UID(Unique Identifier)的，並且有不需要人類介入能自動傳輸資料的。在技術文獻中這被稱為M2M(machine-to-machine)。不論是甚麼IoT裝置，它都需要靠IP(Internet Protocol)來與外面通訊。

這一切是怎麼運作的呢？ IoT是很大量的裝置。 所有這些裝置都使用網際望路來傳輸資料。 通過感應器收集資料，並通過IoT gateway邊緣運算連接到網際網路。 資料收集在中心化資料平台中並進行分析。 下圖顯示了 IoT 環境的高階架構。

圖一

然而，IoT的保護若不足的話可能會導致人命的損失。想想IoT用在智慧城市的各個面向，如交通號誌、基礎設施(瓦斯，水電等)。所以IoT的資安也是非常重要的面向，因為IoT可是駭客的金礦。因為一旦入侵到一個IoT裝置，哪就可以能串連到所有相關的IoT裝置，甚至入侵到系統內。

然而要保護這麼大量的裝置對企業而言是重大的挑戰。怎麼管理、監控、追蹤數以百萬計的裝置?幸好，這一些議題，CSP提供了現有的解決方案給企業使用。

Azure IoT Hub

這個方案提供了IoT裝置的連接、IoT裝置接收跟處理資料、管理、報告。這是一組Azure的服務組合起來的。例如，裝置的update(package-based與image-based)跟整合，靠的是Event Grid, IoT Edge還有Azure Logic Apps, Azure ML, Azure Stream Analytics。

企業也可以客製化自己的IoT應用程式 — IoT Central。這一個服務讓企業自己的應用程式在這裡進行開發與管理 — 一種Application PaaS，可以大大的減少人力資源與成本。還使用UI的方式讓我們連接裝置，監控裝置的狀態，建立管理規則等行動。

IoT central 如何將系統變更傳達給一群裝置以及在這些裝置上運行的應用程式？ 作為消message hub，IoT central允許與設備進行雙向通訊。 此外，Azure IoT Hub 與Event Grid，允許超過 500 個service endpoints路由events。 Event Grid是一種serverless broker，能夠將event傳遞到裝置。 一個例子是更改應用程式的配置。

另外一個是IoT Edge。這是讓資料的運算盡量地靠近這些裝置與資料來源。這用的是容器技術，讓容器運行在IoT Edge的設備中。有些系統以及AI等應用程式的運作現在都可以在邊緣設備上執行。 IoT Edge 還用於將配置發送到特定的裝置群。 然後將這些裝置連接到特定的邊緣設備。 下圖為其高階架構圖。

圖二

Azure IoT central將裝置管理作為一項標準功能，並提供一整套服務，包括與 Sentinel 的 Defender for IoT 等安全套件的整合。Defender for IoT 是 IoT 的安全端點解決方案，現已整合到 Sentinel 中，Defender for IoT提供所有OT(Operational Technology)的可見性(visibility) 和IoT裝置和網路連接，從而可以快速偵測和回應整個IoT生態系統中的潛在漏洞。

AWS的IoT解決方案

關於AWS的解決方案，可參閱本部落格AWS 的 IoT解決方案 — Part 1一文。

GCP的IoT解決方案

GCP的IoT Core, goolge已宣布不玩了，所以不需要介紹。這也是告訴我們在使用雲端服務時要考量其退出策略。

IoT系統的監控

由上一節的敘述來看，很顯然的，資安應該是雲端架構師與企業最關注的一個層面。以下我們將使用OWASP(Open Web Application Security Project)列出的一些風險，我們將討論以下5個風險與IoT有關的:

• Weak passwords
• Poorly protected network services
• Poorly secured interface
• Lack of update mechanisms for security rules and patches
• Use of outdated components

不過，最大的風險是缺乏裝置管理及資料傳輸不受監控。 我們需要知道

• IoT裝置的位置
• IoT裝置正在做什麼
• IoT裝置正在收集什麼類型的資料
• IoT裝置如何收集資料

故可觀察性(Observability)是任何IoT架構都必須遵守的關鍵原則。而以上這些需要知道的資訊其實是整個IoT生態系最大的挑戰，因為裝置群可能有數以百萬計而每個裝置可能同時產生不同維度的資料，例如車輛。

這裡需要回答的問題是：企業是否需要監控每一個感測器？ 或者是否需要決定真正需要監控的內容，而不是監控和回應感測器的每個錯誤或故障？ 所有感測器收集的資料必須準確且相關，以決定整個系統是否按設計和預期的運作。 換句話說，資料分析是監控IoT的關鍵。

IoT裝置除了收集資料，它們也產生資料。所以監控資料也是同時監控裝置本身的狀態(就像OS會產生系統日誌檔一樣)，包括裝置的安全態勢。以下是在業務層面中，企業需要監控整個IoT系統的需求:

• IoT硬體 —
  基本上跟監控一般電腦一樣，CPU/Memory/disk需要監控。監控硬體是如期、如質的運作。
• IoT的軟體與應用程式 —
  監控從OS到應用程式到功能面的運作是否如期、如質。
• 資料 —
  IoT裝置收集和傳輸資料。 裝置必須能夠將資料發送到IoT系統。 另一方面裝置也要能接收資料，例如更新和補丁。 不間斷的 資料流對於IoT裝置的最佳運行至關重要。 通過監控裝置與裝置之間以及裝置與系統之間的資料流來監控網路連接性是監控工具的一個重要面向。 我們需要能夠及時偵測到有中斷的狀況發生。
• 安全態勢 —
  IoT裝置必須得到保護和強化(hardened)。 強化是1.)禁用冗餘功能和(或)降低安全風險以及啟用加密連接的過程。 這是為了使攻擊者盡可能難以存取系統。 就算攻擊者已經有的存取權限的情況下，也應該盡可能讓攻擊者難以使用所取得的資料。

當所設定的安全態勢被突破時，監控工具要能夠及時發送通知。IoT裝置通常是一個讓攻擊者連接到我們系統的一個大門。所以，佈署一個IoT監控系統可以幫助企業克服以下挑戰:

• 可觀察性(Observability) —
  因為整套的IoT平台，包含了數以百萬計的裝置。我們需要一個能夠見樹也見林的整體視角。
• 偵測與回應 —
  我們需要能夠及時偵測到整套的IoT平台的效能與安全態勢的問題，以防止問題散佈到整體平台中讓問題擴大。
• 整合 —
  隨著時間的推移，IoT裝置會來來去去(新加入的，壞掉的)。這些來來去去的裝置要能自動的整合到整個平台中，包含監控。尤其是資安的部分，因為這些新裝置需要套用現行的資安政策。

哪麼CSP在IoT解決方案中可以幫企業哪些呢?答案是，整套的平台方案，包含我們上述講的這些內容。企業使用操作與使用就可以了，這些解決方案市即起即用，而且可以自動擴展規模大小。這些主要CSP的IoT方案幫助企業:

• 在網路中自動探索IoT裝置
• 集中式的遠端裝置監控，包含告警
• IoT資安的集中式監控與管理
• 網路連接的集中式監控與管理

一個問題是：IoT系統的架構要求是什麼？ 首先，我們需要確保裝置可以相互連接並連接到我們選擇的公有雲(IoT系統)。

設計連接到雲端的網路

IoT既然稱為物聯網，哪麼網路連線能力當然是重中之重。這裡，CSP提供了Gateway與邊緣運算(edge computing)做為解決方案。

我們無法將可能是數以百萬計的IoT裝置一一連接到雲端的IoT系統。 首先，每個網路連線本身都會帶來入侵風險，進而帶來安全漏洞的風險。 解決方案是在IoT裝置的傳送到雲端中的IoT系統之前，讓所有網路連線連到一個雲端中類似Proxy的系統。

IoT Gateway就是這樣的系統。它是介於IoT後端系統與位於網際網路的IoT裝置之間的橋樑。所以它不只管理IoT裝置的網路連線，同時兩邊的資料傳輸也必須透過它。如同我們在圖一中看到的那樣。

IoT Gateway的位置處於雲端(也就是CSP的資料中心)，而邊緣運算則靠近IoT裝置更多一些。邊緣運算的出現是因為在IoT裝置的這一邊有一些服務要求資料的處理要有更低的網路延遲性。或者有一些法規法令的要求，不希望一些資料傳送到雲端，所以需要先其過濾。

當然邊緣運算也可以作為Gateway的功能(靠近裝置端的)。但較多的原因是IoT裝置大都是很小的，意味著電能也不會很大。哪就表示裝置通常無法"持續性"傳送資料到遠距離的雲端機房。

現行有兩家CSP提供這樣的解決方案。分別是AWS Outposts與Azure Stack Edge:

• AWS的Outposts是一種全部都安裝好相關軟硬體的1U/2U機器或是整個42U的機櫃。企業可以在上面直接操作AWS的相關雲端服務，當然包含IoT相關的解決方案 — 邊緣運算與IoT Greengrass。
• Azure Stack Edge的做法等同於AWS。Stack edge一共有四種版本，分別是 32vCPU(Pro)或40 vCPU(Pro 2)。1U的機器可以有4.2TB的儲存容量，還可以搭載GPU。

IoT的網路 — IPv6, LoRA與5G

IoT的網路協定有好幾種，會產生這的結果是因為IoT裝置的數量跟型態有非常多種，所以也必須透過不同的方式來進行網路連結。以下是一些IoT的網路標準:

• 6LoWPAN(IPv6 over Low-Power wireless Personal Area Networks) —
  這是由IETF制定的標準，能夠讓低功率的IoT裝置連結到網路上。這個標準包含了 804.15.4(BLE — Bluetooth Low Energy)，還有Z-Wave。
• Zigbee —
  這可能是最為人熟知的IoT標準，主要用作工業環境中的低功耗、小量資料速率無線網絡。 Zigbee 基於 IEEE 的通用 802.15.4 標準。
• OneM2M —
  這是 M2M 通訊的全球標準，嵌入設備的軟體和硬體中。 即時M2M 通訊的另一個標準是DDS(Data Distribution Service)，由Object Management Group開發。
• AMQP(Advanced Message Queuing Protocol) —
  這個開放標準用於橫跨各種應用程式的非同步加密資訊傳遞。 該協議廣泛用於IoT裝置管理，幾乎所有的IoT解決方案都有支援。
• CoAP(Constrained Application Protocol) —
  這個網路協定是由 IETF 設計，用於定義無線感測器等受限的低功耗設備如何在網路中進行通訊。 它使用非常簡單的語法進行訊息傳遞。 最小的 CoAP 訊息只有 4 bytes。
• LoRaWAN(Long-Rang Wide Area Network) —
  這是設計用來支援龐大網路的IoT網路環境，如智慧城市。

另外要提到的另一項技術是5G/LTE（Long-Term Evolution）。 我們在上述中提到的 LoRaWAN 網路適用於不定期連線到網路的IoT裝置。 對於必須保持續連線與需要高速網路頻寬的網路，LTE-M和L4G M2M是更好的解決方案。

5G 網路的導入和推出是下一階段，具有加速IoT發展的巨大潛力。 5G 的最大優勢是網路延遲超低，回應時間極快，適合IoT上的服務與快速移動的車輛之間的通訊。而AWS與Azure也推出它們自己的5G專往，如AWS的Wavelength與Azure的Netowkr Function Manager。