IoT 安全基礎知識第 5 篇：安全連上 IoT 雲端服務

編者說明：儘管 IoT 裝置數量激增，保護這些裝置的安全問題仍持續受到關注，尤其在工業物聯網 (IIoT) 與關鍵任務應用中，企業和個人資料可能在遭駭時受到竄改，因此安全問題就成為是否決定採用這類連線裝置的障礙點。IoT 應用的保護工作可讓人感到卻步，但實際上，在硬體安全裝置的幫助下，只需幾個相對簡單且直覺的原則，就能建置 IoT 裝置安全。只要遵循完善的安全實務，這些問題即可迎刃而解。此系列文章包含數篇內容，為開發人員提供實用的指南，協助其確保從一開始就遵循最佳做法。第 1 篇探討建構起安全設計的加密演算法。第 2 篇探討私鑰、金鑰管理和安全儲存在安全的 IoT 設計中所扮演的角色。第 3 篇檢驗安全處理器的內建機制，這些機制可用於減輕對 IoT 裝置的其他類型威脅。第 4 篇識別並說明如何在進階處理器中應用安全機制，以協助確保已具備所需的隔離，以減緩對 IoT 裝置執行階段環境所進行的攻擊。第 5 篇 (本文) 說明 IoT 安全性功能如何繼續使用更高等級的安全措施，將 IoT 裝置連線到 IoT 雲端資源。

從 IoT 裝置硬體基礎到本身的執行環境，物聯網 (IoT) 的安全性仰賴其間的多層保護機制。然而，所有連線的裝置都無法免於威脅，而且典型的 IoT 應用雲端連線要求，能使新的攻擊長驅直入 IoT 裝置和雲端服務。為了減緩這些威脅，IoT 雲端供應商採用特定的安全協定和原則，但若使用不當，可讓 IoT 應用容易受到攻擊。藉助預先配置的開發板，開發人員能在驗證連線及授權使用 IoT 裝置和雲端資源上，快速借鏡主要 IoT 雲端服務所使用的安全方法。

本文說明 Amazon Web Services (AWS) 和 Microsoft Azure 兩個主要雲端服務的連線需求，並向開發人員示範如何使用不同廠商的開發套件和相關軟體，快速連接這些服務。

IoT 入口網站在雲端服務所扮演的角色

當 IoT 裝置連線至雲端服務或遠端主機等資源時，就有可能將自身暴露在偽裝成合法服務或伺服器的威脅中，甚至會波及整個 IoT 網路。反之，雲端服務本身幾乎同樣面臨駭客假冒 IoT 裝置交易，企圖滲透雲端服務防護機制的攻擊威脅。為了協助確保 IoT 裝置和雲端資源的安全及保護，雲端服務需要使用特定的安全協定，進行登入身份相互驗證及後續授權，才能確保合法使用服務。許多服務組合一般都包含這些協定，提供 IoT 裝置和雲端資源間一個安全的入口網站。

和其他可用的 IoT 雲端服務平台相同，AWS 和 Azure 均提供 IoT 裝置需要使用的特定入口網站，以便與每個供應商的整套雲端資源互動，包括虛擬機器 (VM) 和「軟體即服務」 (SaaS) 產品。Azure IoT Hub 和 AWS IoT 使用一套功能性類似的機制和功能，為各自的企業雲端產品提供此入口網站。

在最低限度下，這些入口網站和其他 IoT 入口網站會採用特定驗證協定來建立安全連線。這些協定是透過每家供應商的軟體開發套件 (SDK) 進行實作。如果是 AWS，IoT 裝置使用相互驗證與裝置閘道器連線。裝置閘道器使用裝置登錄檔中儲存的資訊，使 IoT 裝置與其他 IoT 支援服務連線。登錄檔可儲存獨特的裝置識別碼、安全憑證和管理 AWS 服務存取所需的其他中繼資料 (圖 1)。在 Azure 中，身份登錄檔具有類似功能。

圖 1：如同其他的雲端供應商，AWS 提供開發人員一套專用服務，其設計強化了 IoT 裝置和企業雲端服務間交易的安全性和效率。(圖片來源：Amazon Web Services)

AWS IoT 和 Azure IoT 各自提供一種服務，可在與每個實體 IoT 裝置相關之虛擬裝置中維持狀態資訊。在 AWS IoT 中，裝置影子提供 AWS IoT 這種功能，裝置分身則提供 Azure IoT 類似的功能。

這種安全性入口網站的觀念可延伸至 IoT 邊緣服務，例如 AWS Greengrass 或 Azure IoT Edge。這些邊緣服務產品會將一些雲端服務和功能下放至區域網路，並且在大型部署中，邊緣系統的實體位置鄰近 IoT 裝置和系統。開發人員可以使用 Azure IoT Edge 此類的服務實作應用商業邏輯，或者提供所需的其他功能性能力來縮短延遲，或者提供服務給工業自動化等區域內的操作人員 (圖 2)。

圖 2：為支援邊緣運算，雲端服務供應商提供 Microsoft Azure IoT Edge 之類的專用服務，讓一些 Azure IoT 雲端服務更靠近與 IoT 應用相關的實體裝置。(圖片來源：Microsoft Azure)

應付 IoT 入口網站連接需求

無論是透過邊緣系統，或是直接使用供應商的 IoT 服務來連線，IoT 裝置通常需要滿足一系列要求才能透過供應商 IoT 入口網站連線並使用供應商的雲端服務。儘管細節不同，但 IoT 裝置都至少需要提供一些項目，例如私鑰、X.509 憑證或其他安全性權杖。可在裝置對雲端連線序列的驗證階段中，金鑰、憑證或權杖可為 IoT 入口網站提供有關 IoT 裝置身份的證明或證據。此外，IoT 雲端服務通常會要求一個原則規格，用於定義 IoT 裝置與雲端服務互動的存取權限。

如同其他企業運算要求，需要使用 AWS IoT 和 Azure IoT 此類主要 IoT 雲端服務所指定的特定格式和程序，以提供用於驗證的證明資訊以及用於存取管理的原則資訊。這些服務至少支援憑證式驗證，但也支援使用其他證明形式。例如，開發人員可以在 AWS IoT 中使用基於 JSON Web 權杖 (JWT) 的權杖式驗證法，或者在 Azure IoT 中使用共用存取簽名 (SAS) 權杖。

如前述所示，這些服務使用登錄檔保留每個 IoT 裝置的中繼資料。除了安全性和其他資訊，這些登錄檔也儲存連上 IoT 裝置所需定義的存取權限原則。雖然不同的雲端服務使用不同的指定方式，這些原則的定義均描述不同通訊通道和實體的存取權限。例如，一個簡單的 AWS IoT 存取權限原則可能會使用 JSON 格式來指示：在 AWS IoT 裝置登錄檔中具有特定「事物」名稱的 IoT 裝置，僅能在具有相同關聯事物名稱的通道上進行連線並發佈訊息 (清單 1)。

複製
{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action":["iot:Publish"],
        "Resource": ["arn:aws:iot:us-east-1:123456789012:topic/${iot:Connection.Thing.ThingName}"]
      },
      {
        "Effect": "Allow",
        "Action": ["iot:Connect"],
        "Resource": ["arn:aws:iot:us-east-1:123456789012:client/${iot:Connection.Thing.ThingName}"]
      }
    ]
}

清單 1：開發人員使用 JSON 格式描述自己 IoT 裝置的 AWS IoT 存取權限原則。(程式碼來源：AWS)

具雲端連線能力的開發套件

雖然雲端供應商提供了這些格式和程序的詳細規格，但是通常仍會有許多開發人員會因為某些重要小細節而無法執行驗證和存取管理，因而在供應商的論壇中提出許多問題。從安全性角度來看，更糟的情況或許是，不小心誤用證明或不完整的存取原則定義，這會讓 IoT 裝置、網路和應用敞開攻擊的大門。現貨供應的開發套件和隨附軟體套件，可讓開發人員快速導覽這些所有的連線程序，並使用廠商提供的範例快速連上 IoT 雲端。舉例來說，Espressif Systems 的 ESP32-Azure IoT 套件或 Seeed Technology 的 AZ3166 IoT 開發人員套件都包含經過 Azure 認證的開發板，並且能輕鬆連線 Microsoft 雲端。

Microsoft 提供具有完整逐步說明的示範，其中包括受支援開發套件的驗證憑證和存取憑證。以 AZ3166 開發板為例，開發人員只要按下開發板上的按鈕，即能與自己區域內的 Wi-Fi 網路連線。連線之後，就能在適用 Microsoft Visual Studio Code 的 Azure IoT Tools 擴充套件內，使用 Azure IoT Device Workbench 進行開發、除錯，並與 Azure IoT Hub 互動。開發人員使用此工具組和所附的範例程式碼套件，可在 Azure IoT Hub 中建立 IoT 裝置的物件，並使用所提供的檔案來佈建包含憑證和其他中繼資料的相關身份登錄檔，用以將 IoT 開發板連上 Azure IoT Hub (圖 3)。

圖 3：Microsoft Azure IoT Device Workbench 隨附的範例程式碼和憑證，能幫助開發人員完成佈建作業，以便將 Seeed Technology 的 AZ3166 IoT 開發人員套件連至 Azure IoT Hub。(圖片來源：Microsoft Azure)

Azure IoT Device Workbench 提供額外支援軟體和中繼資料，可讓開發人員為 AZ3166 開發板快速載入範例程式碼，並開始將測量結果從開發板的溫度和濕度感測器傳輸至 Azure IoT Hub。

在 IoT 雲端為實體 IoT 裝置建立代表形式以及佈建相關的登錄檔，涉及的所需步驟只是將裝置與 IoT 雲端連線。不過，若想利用雲端服務優勢，Azure IoT Hub 還需要存取權限原則。若要監測來自 AZ3166 感測器的「裝置對雲端」訊息，開發人員只須使用 Azure 的共用存取原則畫面，選取專為快速啟用所需之存取權限而預建的原則 (圖 4)。

圖 4：開發人員可以使用預建的原則，輕鬆授權使用 Azure 雲端服務以及來自 Seeed Technology 的 AZ3166 IoT 開發人員套件的感測器資料。(圖片來源：Microsoft Azure)

使用 AWS IoT 時，開發人員可改採開發套件，如 Microchip Technology 的 AT88CKECC-AWS-XSTK-B 零接觸佈建套件及隨附軟體，快速評估雲端連線能力。此版本是早期 Microchip 零接觸佈建套件的更新版本，已預載驗證憑證。使用此套件額外提供的指令碼，開發人員無需處理私鑰和憑證，即可迅速將開發板連至 AWS IoT (請參閱《採取零接觸方式安全地鎖定 IoT 裝置》一文)。

其他開發套件包括 Renesas 的 RTK5RX65N0S01000BE RX65N 雲端套件和 Infineon Technologies 的 KITXMC48IOTAWSWIFITOBO1 AWS IoT 套件，可透過支援 Amazon FreeRTOS 型應用的加速開發功能，擴大支援 AWS IoT 連線能力。AWS 針對註冊開發板、建立驗證憑證，以及載入所提供的 JSON 原則以連至 AWS IoT 並使用 AWS 服務等主題，提供詳細的指示。

簡化大型 IoT 部署的佈建作業

前述此類的開發套件，可作為有效加速 IoT 應用原型開發並探索 IoT 服務連線需求的平台。但在執行時，開發人員通常會需要採用更進階的方法，以簡化實際應用中 IoT 裝置的佈建作業。無論是 Azure IoT 或 AWS IoT，兩者均廣泛支援各種方法，能讓大型部署中個別裝置或大量 IoT 裝置的佈建更加自動化。

以使用 AWS IoT 為例，開發人員可使用自舉法佈建憑證。在此範例中，智慧型產品於出貨時即包含自舉憑證，該憑證具備可要求提供並存取新憑證所需的最低存取權限 (圖 5)。

圖 5：AWS IoT 支援在 IoT 裝置中佈建自舉憑證的方法。(圖片來源：DigiKey，基於 Amazon Web Services 的原始資料)

使用自舉憑證時，裝置連至雲端 (圖 5 的「1」)，要求新憑證 (「2」)，然後接收 AWS 無伺服器 Lambda 函式產生之憑證的 URL (「3」)，最後擷取來自 AWS Simple Storage Services (S3) 貯體的憑證 (「4」)。使用該新憑證時，裝置即登回至 AWS IoT (「5」)，以繼續進行正常操作。

AWS 還提供其他雲端服務，以透過使用 AWS Lambda 函式之類的執行資源，來動態佈建驗證權杖。舉例來說，一項汽車應用可能需要一系列短暫連線，在此情況下，使用權杖是更務實且更安全的方法。在此範例中，在 IoT 驗證和授權的 AWS 模組在核准權杖要求後，AWS Security Token Service (STS) 隨即產生一個傳遞至車輛系統的權杖。透過使用該權杖，那些系統可存取需要由 AWS Identity and Access Management (IAM) 服務驗證的 AWS 服務 (圖 6)。

圖 6：主要雲端服務供應商支援這類驗證的其他證明形式，例如 AWS Security Token Service (STS) 動態產生安全性權杖之類的程序。(圖片來源：Amazon Web Services)

針對動態指派存取權限，AWS 提供類似功能。此時，其他的 AWS Lambda 函式會指派一套與有效權杖相關的原則 (圖 7)。

圖 7：開發人員可使用雲端服務來實作動態指派存取權限，這對於需要短暫連線或短暫操作的應用來說特別實用。(圖片來源：Amazon Web Services)

其他的 IoT 雲端服務能讓開發人員更有效率地處理大型部署的佈建。例如，AWS IoT 提供車隊佈建功能，其中包括支援前述自舉法類型的更大型部署。Azure IoT 的裝置佈建服務提供群組註冊功能，可支援對大量共用相同 X.509 憑證或 SAS 權杖的 IoT 裝置進行佈建。

共同負擔安全性責任

IoT 雲端供應商提供許多有效的方法，來增強 IoT 應用中的端對端安全性。雖然如此，IoT 開發人員不能假設那些方法能夠承擔自己特定 IoT 應用全部的安全性要求。事實上，雲端服務供應商透過 AWS 共用責任模型等特定模型，謹慎地設定自己在 IoT 應用安全性上所扮演的特定角色和所承擔的責任 (圖 8)。

圖 8：如同其他主要雲端供應商，AWS 描述本身與雲端使用者共同承擔的責任：一方面保護雲端基礎架構，另一方面則保護客戶的應用。(圖片來源：Amazon Web Services)

AWS 和 Microsoft Azure 均提供共同責任文件，當中描述和解釋在保護資源、資料和應用上供應商本身的角色，以及客戶的角色。在其文件中，Microsoft 綜整了一些共有安全性與合規性要求之間的關係。最終，雲端供應商還承擔雲端安全性責任，客戶則承擔在雲端中使用之應用、資料和資源的責任。

結論

在加密和安全金鑰儲存方面，IoT 應用仰賴以硬體式機制建置的多層安全性。如同任何連線的產品，當 IoT 裝置連至雲端服務時，任何互動形式的行為都會有安全性威脅。為了保護自己和客戶，IoT 雲端供應商在驗證和存取權限管理上會指定特定的要求。雖然供應商會針對那些要求及相關規格提供詳細的文件，開發人員會發現自己雖努力實作安全連線功能，有時仍會讓資源遭到暴露，或反而變成無法存取。使用開發板和相關軟體，開發人員可快速連至雲端服務，並加速開發具備端對端安全性之 IoT 應用的原型。