現在物聯網很明顯無法達成原先所宣稱在 2020 年有 500 億台連網裝置的目標。問題在哪？就在安全性。IT 管理員對安全問題憂心忡忡，因此要求手動佈建物聯網裝置。這項要求拖慢了安裝速度，OEM、ODM 及雲端平台供應商的收益也隨之減少。解決之道在於物聯網身分辨識存取管理 (IAM)。物聯網身分辨識存取管理日益重要，故 MarketsandMarkets 預估此領域的市場將從 2016 年的 11 億美元，成長到 2021 年的 49.7 億美元。本文將探討：

• 物聯網裝置部署與 IT 部署方法的差異
• 為何裝置佈建速度緩慢會減少收益
• 新的「零接觸」內建平台如何滿足 IT 需求同時達成物聯網要求

可擴充性或安全性

早期的物聯網裝置在安裝到網路上時需仰賴自動探索功能。這項方法對安裝者來說很簡單，卻讓 IT 部門很頭痛。IT 專家都不樂見不安全的裝置在毫無警告的情況下出現在網路上。IT 部門的因應之道，是強制營運部門先確保每台都裝置安全無虞才能將它們連上網路。這可以改善裝置的安全性，但也有礙於快速部署物聯網系統。為了確保每台物聯網裝置都安全無虞，IT 部門已探索多種解決方案的可行性，但每個方案都有重大缺點。其中一個選項是將所有物聯網裝置都以統一的映像呈現，這樣所有裝置都會使用已知的組態。雖然這種解決方案對「一般」電腦來說很好用，但對於差異性相當大的物聯網裝置來說卻非如此。第二項方法是讓營運部門的人聯絡 IT 以取得每台物聯網裝置的獨特金鑰。這種手動佈建方法極易出錯且相當耗時，每台裝置通常需要一小時（圖 1）。

圖 1. 手動佈建物聯網閘道裝置。第三種解決方案是鼓勵物聯網裝置 OEM 和 ODM 預先設定其物聯網裝置以供特定雲端平台供應商使用。如此一來，即可將佈建工作轉由雲端供應商處理。這種做法的問題在於，市面上有許多雲端供應商，包括 Amazon、Microsoft、IBM 和 Honeywell 等等。因此，這種方法讓 OEM/ODM 負擔沉重，現在他們必須驗證、記錄及追蹤每個雲端平台的獨特 SKU。 

動機：營收減少和資料保護

放緩部署物聯網裝置的速度，代表整個物聯網價值鏈體系的營收會跟著減少。這也會影響到雲端平台供應商。「如果物聯網裝置不是採內建方式，則其獲利狀況就會不佳，」，Intel 物聯網事業群 (IoTG) 的資深物聯網安全主管 Jen Gilburg 解釋，「[That’s true] 不管平台供應商的營利是仰賴管理的資料量或裝置數都一樣。」

對 OEM 和 ODM 來說，問題在於銷售量無法預測。Gilburg 用一個典型的情況來說明這點：假設客戶要求 100,000 台裝置。OEM/ODM 準備好要生產，但在先供應 5,000 台裝置後，剩餘的訂單項目因為面臨安全疑慮導致的需求下降而延後出貨，這種情況可能徹底打亂生產排程。

以價值鏈體系為基礎的解決方案

既然原本的問題在於物聯網的部署模型與 IT 部署模型有所差異，因此必須要有新的解決方案，其擴充性要更高並具有自動化安全性。因此 Intel® Secure Device Onboard 應運而生。此內建服務是專為各平台皆適用的快速佈建所設計，其特色為：

• 零接觸內建，外加自動探索與佈建功能
• 開機執行僅需數秒
• 使用 Intel® Enhanced Privacy ID 無需密碼即可驗證
• 單一 SKU 即可支援多個雲端平台
• 可追蹤從製造商到客戶的數位所有權

有了這項新平台，OEM 和 ODM 僅需為自己的裝置建立單一映像。接著安裝者只要初次開機即可完全佈建裝置，並準備好交給後端平台供應商以負責營運（圖 2）。

圖 2. Intel® Secure Device Onboard 可簡化佈建。以下為平台運作方式：

1. 矽晶片供應商 – 使用 Intel EPID 2.0 開放原始碼 SDK，於製造時在矽晶片的可信賴執行環境 (TEE) 嵌入 Intel EPID 身分辨識功能。
2. 閘道/裝置製造商 – 使用工具組將用戶端軟體插入開機程式碼，以支援與物聯網平台通訊的直接匿名安全查驗通訊管道，其會傳遞裝置 GUID、Intel SDO 服務 URL 及數位所有權憑證。
3. 裝置擁有者 – 在所有權發佈變更後，最終擁有者可自動將其數位所有權收據載入物聯網平台。
4. 物聯網平台 – 使用 API 啟用平台或 VM 市場容器，將裝置註冊到擁有者的帳戶，並啟用多點傳送網域名稱服務通訊協定，以共用目的地 IP 位址。
5. 裝置啟用 – 開機的裝置會聯絡 Intel SDO 服務以查驗真實性，且其會在遇到佈建的新擁有者時接收 URL。

為了建立平台，Intel 與眾多矽晶片、設備及平台供應商合作（圖 3）。支援平台的第一項設備預計是來自 Intel® 物聯網解決方案聯盟的成員，例如 Nexcom。此外，Intel 與 Open Connectivity Foundation (OCF)、IoTivity 專案及其他物聯網標準組織合作，根據其在現實世界中的內建裝置經驗，提供概念和工具組。

圖 3.  價值鏈體系支援對於全方位的物聯網裝置內建系統來說必不可少。除了安全性，以全球價值鏈體系為基礎的方法也必須支持隱私權考量。對於和歐盟往來的公司而言，這表示其必須遵守新推出的通用資料保護法規 (GDPR)。此法規要求收集任何資料類型的任何公司必須確保資料受到保護且安全無虞。這是 Intel SDO 使用 Intel EPID 的其中一個原因。此驗證方法讓裝置根據其獲准的存取層級來存取系統，而非根據任何像是 MACID 的身分識別資訊進行存取。換句話說，如果驗證了 100 個真實的簽章，驗證者無法判定究竟是驗證了 100 台裝置，或是同一台裝置驗證了 100 次。傳統的數位認證和驗證技術例如公開金鑰基礎架構 (PKI) 無法在授予存取權時保持匿名處理（圖 4）。指定的公開認證包含主要擁有者的名稱和資訊，受保護資訊的所有權就會因此曝光。如果相同的裝置經過多次驗證，則其活動可能受到追蹤，讓駭客透過可能採取的阻斷服務等攻擊手法製作出威脅地圖。

圖 4. 和傳統 PKI 不同的是，Intel® Enhanced Privacy ID 採匿名方式運作，而 Intel EPID 不會收集這類身分識別資料。除了能嚇阻駭客之外，缺少身分識別資料也代表 Intel EPID 不會受到 GDPR 法案影響。「隨著業界開始因應 GDPR 等資料隱私權法規，Intel EPID 會獲得許多額外的使用案例，」Gilburg 說，「接著它會成為業界標準，而不再會只有 Intel 和合作夥伴使用。」

從晶圓廠到最終產品佈建

想要知道所有元素如何相互配合，請參考圖 5 所示情境。Intel EPID 身分辨識功能會在晶片製造過程中燒錄在可信賴執行環境內。

圖 5. 智慧型燈泡可說明典型情境。晶片之後會送往 OEM/ODM，在其主機板上會儲存獨特的識別碼（稱為 GUID）及公開金鑰。公開金鑰含有建立裝置所有權的簽章鏈。主機板一旦安裝到產品上（例如 GUID 為 123 的智慧型燈泡），即會經由各種管道出貨，最後送達終端客戶手中。簽章在每一步驟中都會增加內容。物聯網裝置終於裝好了。此時 Intel SDO 會提供代理服務，它其實就是一個會合點 (通常是 URL)，裝置可在此探索擁有者的 IP 位址。這時裝置和擁有者彼此會向對方證實自己的身分。「Intel 不會實際在雲端驗證可信賴度，」Gilburg 解釋，「我們只是將裝置重新路由到其預定的新擁有者那裡，在新擁有者處透過原始 Intel EPID 簽章進行驗證。一旦雙方接受後，就會在裝置和平台間建立加密安全通道，藉此進行營運佈建。」

佈建是在安全和裝置限制間取得平衡的重要步驟。例如，如果裝置為具有 RTOS 的嵌入式系統，則物聯網平台管理系統必須使用簡單的 RSA 金鑰。如果裝置是具有較大記憶體和處理能力的完整閘道，較可使用較安全的閘道映像。該裝置運作所需的任何項目均由平台管理服務判定。

可擴充安全性

「零接觸」內建概念可讓安裝者只要插入裝置並確認其位置，之後即可由網路管理員控制裝置。驗證和安全機制由雲端代理服務建置，該服務連線至許多物聯網雲端平台供應商的其中一家。一旦建立安全連線，就會在雲端服務依使用者的帳戶自動佈建裝置，使用者不需設定密碼、金鑰或獨特的識別碼。最後一點是 Intel 作法重要的與眾不同之處，它能確保裝置的隱私權。潛在的駭客無法藉由追蹤裝置的不同擁有者製作攻擊地圖。Intel EPID 技術可建立匿名安全通道，端點驗證可在此隱藏，而不像傳統的公開金鑰方法（例如 PKI）可供追蹤所有權。簡單來說，Intel 的物聯網裝置內建方法既安全又容易擴充，可快速部署千百萬台裝置。

物聯網明顯有安全需求，而安全性的核心原則眾所週知。但是開發人員通常沒有足夠的時間和資源做好安全防護。上市時程與成本壓力是主要的難處。開發人員通常必須設法說服管理層安全值得投資，但是說服過程真的非常艱難。即使是指出諸如生產線被關閉或是後端網路被入侵等風險可能還不足夠，特別是如果您的公司剛開始使用連網裝置，且缺乏安全問題的直接應對經驗。然而，因為攻擊手法一定會不斷增加，安全最佳實務一定要預先建立，而不能只是亡羊補牢。物聯網的網路也變得越來越複雜。真正的安全不但保護您的裝置免遭受直接攻擊，還可以幫物聯網資料鏈中保護較少的子系統防禦後門攻擊。威脅也是不斷進化。於是，開發人員需要有方法讓安全解決方案安裝最新的修補程式來保持最新狀態。除此之外，擴充性也是一大難題。企業自行研發的安全解決方案無法應付不斷擴大的威脅，但是商用解決方案可能太昂貴且過於龐大，並不適合小型部署。

物聯網服務平台的成本與功能之延展

Amazon Web Services (AWS) 物聯網平台是因應上述挑戰的有趣解決方案。這個平台是完整的端對端服務，使用者可透過平台把裝置連接到 AWS 服務和其他裝置、保護資料和互動過程、處理裝置資料並據以行動，以及讓應用程式與裝置互動，即使在離線時亦然（圖 1）。

圖 1. Amazon Web Services (AWS) 物聯網平台提供端對端安全功能。（資料來源：Amazon Web Services）

它由六個主要元素組成，從左至右分別是：

• 裝置端 SDK，具有連線能力和驗證程式庫
• 驗證與授權服務，限定身分經確認的裝置才可以進行資料交換
• 登錄機碼，為每個裝置建立獨特的身分識別，並追蹤裝置相關中繼資料
• 裝置閘道器，確保一對一和一對多的通訊安全且有效
• 規則引擎，收集、處理和分析全球資料並據以行動
• 裝置陰影，讓使用者為每個裝置建立一個永久性的虛擬版本，又稱「陰影」

AWS 具備各式安全、身分識別與合規產品，可以支援 AWS 物聯網平台。其中包括 SSL/TLS 認證、雲端目錄、金鑰儲存與管理、存取控制和機密資料分類。對於想要加速開發又要確保連線的每個接點皆有驗證和端對端加密的開發人員而言，AWS 物聯網平台具備許多必要的元素。除此以外，它也可以擴充至數十億台裝置及處理數兆則訊息，應該能滿足大部份使用者的需求。

經常有人把物聯網看作是某種魔法。許多企業預期物聯網可改善營運效率、縮短上市時程和降低成本，但是大多不清楚要如何達成這些崇高的目標。如何實現目標的解答可能讓您大吃一驚。試想把 GE 自動化與控制的 Predix 平台（圖 1）結合智慧照明之後可以完成哪些工作。

圖 1. LED 照明是連線的閘道器（資料來源：GE Automation & Controls）

照明與分析的組合也許比較奇特，但是二者搭配運作可以滿足快速擴充的需求。我們先從照明說起。部署物聯網感測器通常意味著要從頭開始安裝感測基礎架構。但是，更明智的做法是先回頭看看必要的基礎架構中有哪些元素已經安裝過，而且可以再利用，其中處處可見的莫過於電燈插座。由 GE 提供技術支持的 Current 公司推出的智慧照明產品證明了這個觀點。這些照明產品在 LED 燈具內結合各種各樣的感測器，可以部署到現有的基礎架構中。照明產品使用 Zigbee 或其他低功率無線網路介面，與閘道器或其他聚集節點進行通訊，整個設置因此變得極具擴充性且容易部署。在軟體方面，Predix 提供「平台即服務」(PaaS)，所以開發人員只需編寫一次，便可以隨時隨地進行部署（圖 2）。

圖 2. Predix 平台處理所有工作，從資料收集到雲端分析。（資料來源：GE Automation and Controls）

Predix 的主要元素包括：

• Predix Machine：用來收集資料並把資料推送到 Predix 雲端的軟體層。它部署在閘道器、控制器和感測器上，也可以執行本機分析。
• Predix Services：開發人員可以利用這些服務建構、測試和執行工業用網際網路應用程式。它也提供一個微服務市場，讓開發人員可以發佈自己的服務以及使用第三方的服務。
• Predix Cloud：安全的全球雲端基礎架構，符合重要產業（例如醫療和航空）嚴格的法規標準。

為了用範例說明這些元素如何搭配運作，GE 在美國南卡羅萊納州 Greenville 的燃氣渦輪機廠房裝設了智慧燈具。在這個實例中，照明感測器測量一個裝配站附近的空氣溫度，讓工廠工人知道哪個零件溫度已下降，可以安全地增加下個轉子。這項洞察資訊有助於減少缺陷及重做零件的需求。這項獨特設備的好處包括能源用量減少 24%，以及增加了價值數十萬美元的生產力。GE 設備是如何運用現有基礎架構簡化物聯網之網路部署的有趣範例。使用這個方法，搭配收集和分析資料的 Predix 及雲端連線能力，開發人員可以更快實現物聯網的潛力，以便執行預測式分析、降低成本，以及改善程序與系統可靠度。

根據《物聯網的邊緣分析》報告指出，物聯網所產生的資料中，僅有 10% 為組織所用。利用資料進行深入分析的比例更少。要在網路上傳輸所有這些資料是一大問題。頻寬有限意味著大部份物聯網資料無可避免地留在邊緣。這種情況正好是霧運算崛起的機緣。霧運算強調盡可能在最接近資料來源的地方進行分析。這種做法可以在延遲較低的情況下做決定，且不會使用過多的網路頻寬。為了充分利用這個技巧，分析情報必須從雲端再分發到邊緣。這代表處理資源的重新分配，或是感測器與雲端之間的既有資源作雙重用途之應用。儘管其中許多節點例如路由器和閘道器已經擁有進階的處理和記憶體資源，其他節點仍有甚多限制。特別是在網路邊緣的感測器和其他裝置均有成本、電源和空間上的限制。所以，通常第一個可以執行分析的地方就是物聯網閘道器。閘道器之所以扮演這個角色有兩個原因。第一是其提供充足的效能和記憶體。第二，其可將來自多個異質網路的感測器資料合併起來，因此可以依據多種資料輸入和來源進行分析並據以行動。能夠從多個來源提取資料是很了不起的能力。許多物聯網的網路涵蓋了 Modbus、乙太網路、zigbee、Bluetooth、Wi-Fi 和行動網路等。於是，閘道器分析不但要倚賴閘道器的效能，也必須仰仗於建立可管理多個通訊協定的軟體堆疊。

橫跨異質網路的單一來源管理

Greenwave Systems AXON Platform for Analytics 正是為了簡化這個任務而打造的。該平台為獨立完備的分析引擎，可讓 OEM 和企業在網路中任何一處擷取和分析即時效能資料並據以行動。物聯網裝置（例如工業控制器）可以運用稱為 AXON Predict 的版本（圖 1）。這個軟體直接嵌入在裝置上，進行持續監控並依監控情形適當地反應。發生值得注意的事件時，它會傳送文字訊息或直接撥電話給員工，也具備自我修復的功能以預防資產故障。

圖 1. AXON Predict 可持續監控並提供即時的分析資訊。（影像來源：Greenwave Systems）

到網路的較高層級處，物聯網閘道器可以使用 Predixion RIOT One，不需要太多組態和設定即可連接數千部裝置。RIOT One 因此預先整合了適用於 Wind River Helix Device Cloud 的連接器，提供簡易的雲端連線能力。Greenwave 的 AXON Platform for IoT 解決了連線的問題，把多種裝置的通訊轉譯成為通用的 IP 型語言，藉此彌補該公司分析解決方案的不足。此外，它可進一步為網路上多種裝置或功能提供單一來源管理，包括進階無線閘道器、Wi-Fi 路由器、遙控器、電源插座和啟用感測器功能的燈具、喇叭或是在場感測器。透過 AXON Platform for Analytics 及 AXON Platform for IoT，如今在網路的每一個層級都可能新增情報功能，協助解決代價高昂的問題，例如非預期的停機時間，以及利用即時的分析資訊賦予最終使用者和製造商更多能力。

行動應用程式是控制物聯網裝置理所當然的選擇。既有直覺化的介面，又有隨身攜帶的便利性，讓行動應用程式成為最容易管理連線設備的方法。但是開發行動應用程式卻不容易。應用程式的設計需要使用獨特的程式語言，需要 UX（使用者體驗）的專業，也需要其他專門的技能。嵌入式設備的工程團隊可能完全沒有這些必要技能。儘管有可能在團隊的各項專業技能之中再添加上行動應用程式設計這一項，但這麼做卻可能耗時且成本高昂。最終應用程式開發若未正確執行，成果更可能令人失望。另一種方法則是將專案委外。不過根據應用程式開發公司 Savvy Appa 指出，應用程式開發成本通常最低約 $50,000 美金，最高價格則甚至超過 $500,000 美金。如此負擔，使得許多連線裝置製造商均卻步不前。

製作行動應用程式：基礎知識

為理解其中挑戰，首先為讀者介紹一個典型的工作流程：

• 開發物聯網解決方案的行動應用程式第一步驟，即是辨識使用案例與需求的大方向。
• 其後，由設計團隊建立 UX 流程概略描述顧客將如何與其連線產品進行互動。
• 完成設計後，再把需求與文件交給開發人員，由他們著手實作成為行動應用程式。

除此之外，因為 iOS 和 Android 的開發完全不同，需要不同的技能，也使得這項任務更加複雜。iOS 應用程式使用 Objective C 和 Swift 語言，而 Android 應用程式則使用 Java。這就形成了開發物聯網裝置行動應用程式最初的挑戰，因為 OEM 必須依據目標使用者客群而決定應支援哪一個平台，或兩者均支援。此決定切不可輕率，因為一旦選定平台，就必須在連線裝置的整個部署生命週期提供支援。

額外需求：應用程式基礎架構

行動應用程式還需要另外兩個基礎架構要素：韌體（就此例而言，即指實際於物聯網邊緣裝置上執行的程式本身）以及雲端。行動應用程式要有效果，目標物聯網裝置上執行的韌體就必須與雲端上的後台以及行動應用程式進行連線，才能夠提供狀態更新和遠端管理功能。這通常是透過整套 API 和程式庫達成，而這些則應使用的處理器及其他硬體而變。視應用程式需求，例如所產生的資料量與產生頻率、安全功能或隱私考量等，行動應用程式部署的雲端部分可選擇於公有雲或就地部署伺服器中執行。當然，兩者在成本和工程資源方面也就各有取捨。

連線考量

開發行動應用程式也必須考量連線。工程師必須顧及使用者將如何連線物聯網裝置、連線目的，以及連線頻率。例如，Wi-Fi 是連線網際網路的標準方法，可藉此連線雲端，讓伺服器能夠從遠端與裝置互動。但是在特定情況下，當使用者緊鄰裝置且無需龐大頻寬時，則可選用如藍牙等其他連線技術。

拖放式開發應用程式能夠瞬間提升物聯網 UX

OEM 若想要為物聯網裝置迅速增添一套可作用的行動應用程式，則這許多要素均可能導致現有資源不敷使用。所幸還有另一種做法：範本式的應用程式工具。這些專為物聯網所設計的工具能夠提供拖放式的開發體驗，節省時間也壓低成本。例如 Blynk Inc. 的 Blynk 軟體平台就是一個很好的例子（圖 1）。這套原生的行動應用程式建構工具適用於 iOS 及 Android，讓開發人員只要按幾個按鈕即可輕鬆建立品牌化的應用程式，並將其發佈至 App Store 或 Google Play。

圖 1. Blynk 提供行動裝置原生的物聯網軟體平台。（資料來源：Blynk Inc.）

Blynk 讓開發人員從各有不同功能的許多小工組中選擇，直接「組裝」成一套行動 UI（圖 2）。例如，可將燈光開關的按鈕、可視覺化呈現感測器資料的圖表、可由特定事件觸發的推送通知等小工具。而這一切均可直接從智慧型手機上進行開發。

圖 2. 不限定硬體的拖放式小工具讓開發人員快速輕易添增功能。在韌體方面，Blynk 提供各種程式庫與 API 可將任何 MCU 或單板電腦連線至 Blynk Cloud。這些程式庫與 API 負責建立連線、傳送和接收資料。由於這些均以小段的程式碼方式封裝，因此亦同時能夠預留充足記憶體容量供其他重要裝置功能使用。目前 Blynk 支援超過 400 種硬體與連線模組。這些包括各種以 Intel® 技術為基礎的單板電腦 (Single-Board Computer，SBC)，如 ADI Engineering, Inc. 的 MinnowBoard Turbot 和 SECO 的 UDOO X86（圖 3）。

圖 3.  SECO UDOO X86 是總計超過 400 種支援平台當中的一種。（資料來源：SECO）

在後台方面，開放原始碼的 Blynk Cloud 提供安全、輕量級的伺服器，可供 Blynk 平台所有使用者免費使用。Blynk Cloud 公有雲目前每個月處理超過 330 億條訊息。另外視應用程式需求，也能夠於私有平台執行 Blynk Cloud。Blynk 應用程式的另一個特點就是提供了 HTTP API，能夠整合其他物聯網雲端的資料。如此一來，物聯網應用的 OEM 就能夠開發全方位的行動應用程式，將其他業務系統及合作夥伴的資訊整合，進而提升易用性與 UX。為更佳服務企業客戶，Blynk 平台也已著手添增連接器以整合 Microsoft Azure、Amazon AWS IoT、IBM BlueMix 以及其他各大雲端平台。目前市面上已有數千款物聯網產品使用 Blynk 開發平台，包括智慧家庭、農業、機器人、醫療和精密設備監控等各種領域。若要搶先一步瞭解行動應用程式能提供的深入見解、UX 和 ROI，請參閱 Blynk 網站所提供的教學和展示應用程式。

若論裝置完整性、資料保護和裝置管理，自己動手做 (DIY) 的安全方案並不足夠，就算您是經驗豐富的工程師亦然。最近物聯網裝置被惡意攻擊的事件就是最佳的證據。最近發現超過 50 億台藍牙裝置無力抵擋 藍牙惡意軟體攻擊。駭客們只需等待藍牙裝置開啟，接著便可以注入惡意程式碼，而且在某些情況下，還可以攔截 Windows PC 傳入和傳出的網路流量並任意修改。這並不是單獨的事件。一次快速搜尋便會招來數十次攻擊。由於製造商採用預設密碼和不必要的開放連接埠，致使物聯網裝置門戶大開，這些裝置可能被利用來攻擊整個物聯網堆疊。這就是物聯網安全攻擊如此嚴重的原因：犯罪者不但竊取資料並中斷服務，而且從裝置到雲端的資料流之中隨處對設備和使用者造成傷害。是的，設計師可以下載一些開放原始碼的傳輸與加密程式碼，並把它內建到應用程式內。但是，這肯定會有缺口，讓駭客有機可乘。儘管現在市面上的商用安全平台無法完全摒除風險，但一定有辦法降低風險。要達到最佳的安全狀態，這些解決方案必須與平台緊密整合，而不是等到產品設計都要交到客戶手上前才加裝。

物聯網安全與傳統安全比較

物聯網安全與相對傳統的安全措施之間有若干重大差異。傳統安全功能假設 IT 可以在隔離式網路上控管裝置和資料的存取，且裝置和資料兩者皆存在於已定義的實體環境中。端點必須具備相當高的運算能力，才能執行保護這些裝置和資料的解決方案，例如防毒軟體、防火牆和入侵偵測/預防系統 (IDS/IPS)。若需要更新安全方案，可在裝置上輕鬆下載和安裝最新的修補程式。另一方面，物聯網安全則比較不受管束。裝置一般都在相對開放的網路上運作，通常是在缺乏實體防護的地方。運算能力有限，尤其用電池供電的裝置，發佈軟體更新的能力亦然。物聯網系統的端點可能沒有多餘空間可以安裝安全軟體。因此物聯網安全必須先驗證邊緣裝置才能進行通訊，並一路保護資料從終端裝置傳送到雲端。所以這意味著裝置出貨前必須內建安全功能，而不是在裝置都售出後再加裝套用。

內部自行開發的安全方案之缺點

要更貼切體會物聯網安全工程的艱鉅程度，可從典型的系統架構著眼：

• 裝置端：包含物聯網裝置、應用程式、資料以及網路交換器/閘道的連線能力
• 網路交換器/閘道：包含一個網路交換器/閘道、路由軟體和其他應用程式，以及裝置端和雲端的通訊
• 雲端：包含伺服器基礎架構、已儲存的資料、原生應用程式，也許可以存取硬體安全模組 (HSM)，以及連接網路交換器/閘道或是裝置的南向通訊機制

要自行開發一套物聯網安全解決方案來因應上述領域的需求，設計團隊必須在範圍、時間和成本之間有所折衷。通常會向內部開發部門和開放原始碼社群借用建構這類解決方案所需的元件，例如 SSL/TLS、OpenSSH、OpenVAS、AES、TrueCrypt 和其他。不幸地，在許多情況下，這些元件早在物聯網還沒出現之前便已開發，因此通常沒有考慮物聯網會延伸到防火牆之外，而且在許多情況下是實際上地超出所有外牆，因為物聯網裝置會懸掛在電線桿和在戶外的其他建築物上。許多無法預見的攻擊都可能從這裡發生（圖 1）。

圖 1. SSL 擁有許多弱點。（資料來源：Centri Technology）

物聯網系統包含多個裝置、設備、服務和軟體套件，把多種安全解決方案拼湊在一起並不是最理想的選擇。一方面，它可能造成一個無法整合的龐大安全解決方案組合。每個單點解決方案必須個別管理，加重了工程支援的負擔。單點解決方案也無法相互分享資料，所以無法全面統整安全狀況，偵測威脅的能力亦有限。複雜度更高也會製造更多磨擦，因為新的應用程式和服務必須與非常多專門的技術相容，而每個都有本身的 API、政策和要求。若是選錯了安全方案，可能嚴重影響敏捷性與上市時程。打造一個緊密整合的物聯網安全解決方案是一個必須耗費數年才能克服的挑戰，並非數小時就能解決。

整合式安全方案

Centri IoT Advanced Security (AS) 平台適合想要從一開始便整合安全功能的設計師（圖 2）。該平台允許開發人員在物聯網解決方案堆疊中整合遵循標準的加密與進階密碼，從晶片到雲端可以進行安全通訊、保護靜置的資料並提供資料鑑識所需的管理主控台。IoTAS 平台的主要元件包括：

• 安全通訊端點：允許開發人員利用裝置的軟體堆疊附帶的小型安全通訊程式庫或代理伺服器用戶端，整合裝置端的安全功能與物聯網應用程式。再與安全通訊服務搭配運作，即可保護傳入傳出雲端的資料。
• 資料保護工具：可以使用 API 從物聯網應用程式呼叫小型的資料保護程式庫來加密資料，然後再傳送到裝置或內部部署的儲存裝置。
• 安全通訊服務：這項工具在現有的應用程式伺服器上執行，保護雲端基礎架構的安全。

圖 2. CENTRI IoTAS 提供端對端保護。（資料來源：Centri Technology）

CENTRI 安全通訊程式庫與安全通訊服務能讓物聯網裝置與雲端基礎架構之間立即執行的加密型單階段交握加速完成。這樣一來，簡化了複雜的認證管理綱要而且不必採用第三方憑證授權單位 (CA) 解決方案。系統也採用無保存庫的金鑰管理技術，在資料中嵌入已加密的金鑰資訊。故不需要 HSM 或是第三方金鑰儲存機制。智慧快取與資料壓縮技術最低可讓安全功能經常超支耗用的資源降低至 1% CPU 使用率，讓資源有限的物聯網裝置能夠使用這個平台。CENTRI IoTAS 的每個元件皆是不限裝置和作業系統均可使用，經驗豐富的開發人員只要一天即可把這些技術與應用程式的程式碼整合。

安全功能：內建與加裝

雖然許多第三方商用安全解決方案提供的保護比自行開發的替代方案更好，但是在設計的後段階段中執行時，卻會產生極高的成本和管理費用。盡早在端點和雲端安裝安全解決方案是更好的做法。兩者皆可降低裝置攻擊和資料外洩的風險，並加速上市時程。